GLM-5.2: Được xây dựng cho các tác vụ dài hạn

Chúng tôi xin giới thiệu GLM-5.2, mô hình hàng đầu mới nhất của chúng tôi dành cho các tác vụ dài hạn (long-horizon tasks). Đây là một bước nhảy vọt về khả năng xử lý tác vụ dài hạn so với phiên bản GLM-5.1 và lần đầu tiên mang lại khả năng này trên một ngữ cảnh 1 triệu (1M) token ổn định. Những khả năng mới của GLM-5.2 bao gồm:

• Ngữ cảnh 1M ổn định: Khả năng xử lý 1 triệu token một cách ổn định, duy trì hiệu quả cho các công việc dài hạn.
• Lập trình nâng cao với nỗ lực linh hoạt: Khả năng lập trình mạnh mẽ hơn với nhiều mức độ “nỗ lực tư duy” (thinking effort) để cân bằng giữa hiệu suất và độ trễ.
• Kiến trúc cải tiến: Chúng tôi đề xuất IndexShare, giúp tái sử dụng cùng một bộ lập chỉ mục (indexer) cho mỗi bốn lớp attention thưa, giảm 2,9 lần số phép tính FLOPs trên mỗi token ở độ dài ngữ cảnh 1M. Chúng tôi cũng cải thiện lớp MTP của GLM-5.2 cho giải mã suy đoán (speculative decoding), giúp tăng chiều dài chấp nhận (acceptance length) lên đến 20%.
• Mở hoàn toàn: Cấp phép mã nguồn mở MIT — không giới hạn khu vực, tiếp cận kỹ thuật không biên giới.

Để hỗ trợ các tác vụ dài hạn, điều đầu tiên là phải làm cho kỹ thuật ngữ cảnh dài trở nên khả thi trong thực tế: mô hình phải duy trì chất lượng thông qua các quỹ đạo (trajectories) dài và phức tạp của tác nhân lập trình, chứ không chỉ đơn thuần là chấp nhận nhiều token hơn. Việc tuyên bố hỗ trợ ngữ cảnh 1M thì dễ, nhưng để giữ cho nó đáng tin cậy dưới áp lực kỹ thuật thực tế thì khó hơn nhiều. Vì vậy, chúng tôi đã mở rộng đáng kể quá trình huấn luyện ngữ cảnh 1M cho các kịch bản tác nhân lập trình, bao gồm triển khai quy mô lớn, nghiên cứu tự động, tối ưu hóa hiệu suất và gỡ lỗi phức tạp. Kết quả là một hệ thống ngữ cảnh dài không chỉ rộng về phạm vi mà còn chắc chắn trong thực thi: một nền tảng thực tế cho các công việc kỹ thuật bền vững.

Khả năng này được phản ánh qua hiệu suất của GLM-5.2 trên ba bài kiểm tra (benchmark) lập trình dài hạn. FrontierSWE đo lường xem một tác nhân có thể hoàn thành các dự án kỹ thuật mở trong khoảng thời gian từ vài giờ đến hàng chục giờ hay không, bao gồm tối ưu hóa hệ thống, xây dựng mã quy mô lớn và nghiên cứu ML ứng dụng. Trên benchmark này, GLM-5.2 chỉ kém Opus 4.8 khoảng 1%, trong khi vượt qua GPT-5.5 1% và Opus 4.7 11%. Trên PostTrainBench, nơi mỗi tác nhân được cấp một GPU H100 và được đánh giá bằng mức độ cải thiện các mô hình nhỏ thông qua hậu huấn luyện, GLM-5.2 vượt qua cả Opus 4.7 và GPT-5.5, chỉ đứng sau Opus 4.8. Trên SWE-Marathon, một benchmark kỹ thuật phần mềm cực dài bao gồm các tác vụ như xây dựng trình biên dịch, tối ưu hóa kernel và phát triển các dịch vụ cấp sản phẩm, GLM-5.2 vẫn còn dư địa để phát triển, kém Opus 4.8 13% nhưng vẫn đứng thứ hai sau dòng Opus. Trên cả ba benchmark, GLM-5.2 là mô hình mã nguồn mở xếp hạng cao nhất, cho thấy ngữ cảnh 1M đã chuyển hóa thành khả năng thực hiện thực tế cho các tác vụ dài hạn.

Trên các benchmark lập trình tiêu chuẩn, GLM-5.2 là mô hình mã nguồn mở mạnh nhất, cải thiện đáng kể so với GLM-5.1: 81.0 so với 63.5 trên Terminal-Bench 2.1 và 62.1 so với 58.4 trên SWE-bench Pro. Nó cũng thu hẹp khoảng cách với các mô hình đóng hàng đầu — trên Terminal-Bench 2.1 (81.0), nó chỉ kém Claude Opus 4.8 (85.0) vài điểm — trong khi vẫn dẫn trước Gemini 3.1 Pro.

GLM-5.2 cũng giới thiệu khả năng kiểm soát mức độ nỗ lực (effort level control), cho phép người dùng cân bằng rõ ràng giữa khả năng của mô hình với tốc độ thực thi tác vụ và chi phí tính toán. Như trong hình, GLM-5.2 mang lại hiệu suất lập trình tác nhân mạnh hơn đáng kể so với GLM-5.1 ở cùng mức ngân sách token, với khả năng nằm khoảng giữa Claude Opus 4.7 và Claude Opus 4.8 khi tiêu thụ token tương đương. Hơn nữa, mức nỗ lực “Max” cho phép người dùng phân bổ thêm tính toán khi yêu cầu hiệu suất cao hơn cho các tác vụ khó, mở rộng hơn nữa khả năng lập trình của mô hình. Thiết kế này mang lại sự linh hoạt lớn cho người dùng, cho phép chọn chế độ suy luận phù hợp nhất cho từng kịch bản.

Kiến trúc cho Ngữ cảnh 1M

IndexShare cho DSA

Để hỗ trợ độ dài ngữ cảnh 1M, trong GLM-5.2, chúng tôi áp dụng IndexShare để giảm chi phí tính toán của bộ lập chỉ mục trong DSA. Cụ thể, cứ mỗi 4 lớp transformer sẽ chia sẻ một bộ lập chỉ mục nhẹ. Bộ lập chỉ mục được đặt ở lớp đầu tiên trong số 4 lớp và các chỉ số topk sẽ được sử dụng cho cả 4 lớp đó. Điều này làm giảm tính toán tích vô hướng của bộ lập chỉ mục và thao tác topk ở 3/4 số lớp. GLM-5.2 được huấn luyện với IndexShare từ giai đoạn giữa của quá trình huấn luyện với độ dài chuỗi 128K, vượt trội hơn GLM-5.1 trên các benchmark ngữ cảnh dài với mức tính toán thấp hơn.

MTP với IndexShare và KVShare

Chúng tôi cải thiện lớp MTP (Multi-Token Prediction) của GLM-5.2 cho giải mã suy đoán với hai mục tiêu: 1) Giảm thiểu chi phí của lớp MTP khi đóng vai trò là mô hình nháp (draft model); 2) Tối đa hóa tỷ lệ chấp nhận của giải mã suy đoán.

Đối với mục tiêu thứ nhất, chúng tôi cũng áp dụng IndexShare cho lớp MTP. Trong MTP đa bước, bộ lập chỉ mục được đặt ở bước đầu tiên và các chỉ số topk được sử dụng cho tất cả các bước tiếp theo. Tuy nhiên, khác với mô hình chính (backbone), các token đầu vào của các bước MTP khác nhau là khác nhau. Như hình dưới đây cho thấy, nếu chúng ta tái sử dụng các chỉ số topk của $h_4$ cho $h_5$, thì $h_5$ chỉ có thể chú ý (attend) đến $h_1$ đến $h_4$, chứ không phải $h_5$. Chúng tôi sẽ chứng minh rằng đặc tính này giúp đạt được mục tiêu thứ hai bằng cách loại bỏ sự sai khác giữa huấn luyện và suy luận trong lớp MTP của GLM-5.1.

Trong hình trên, chúng tôi trình bày quá trình suy luận của một lớp MTP hai bước. Ở bước thứ nhất, suy luận nhất quán với huấn luyện, với tất cả các trạng thái ẩn (hidden states) đến từ mô hình mục tiêu. Tuy nhiên, ở bước thứ hai, $h_{1:4}$ đến từ mô hình mục tiêu và $h_5$ đến từ lớp MTP. Do đó, KV cache của $h_5$ là sự pha trộn giữa $kv_{1:4}$ tính từ mô hình mục tiêu và $kv_5$ tính từ lớp MTP. Ngược lại, với IndexShare, KV cache của $h_5$ chỉ bao gồm $kv_{1:4}$, tất cả đều từ trạng thái ẩn của mô hình mục tiêu. Đối với huấn luyện, chúng tôi tái sử dụng cả KV cache và các chỉ số topk của bước MTP đầu tiên. Lưu ý rằng tương tự như GLM-5.1, các tham số của các bước MTP khác nhau cũng được chia sẻ. Hơn nữa, lấy cảm hứng từ https://arxiv.org/abs/2606.12370, chúng tôi giới thiệu lấy mẫu loại bỏ (rejection sampling) cho giải mã suy đoán và sử dụng tổn thất TV (TV loss) cuối-đến-cuối để huấn luyện.

Bảng dưới đây cho thấy kết quả thử nghiệm các kỹ thuật dựa trên chiều dài chấp nhận trong các kịch bản lập trình. Trong thí nghiệm, chúng tôi sử dụng mô hình chính và dữ liệu huấn luyện của GLM-5.1. Số bước MTP được đặt là 7 cho cả huấn luyện và suy luận. So với baseline, chiều dài chấp nhận của lớp MTP cuối cùng tăng 20%.

Phục vụ hiệu quả độ dài ngữ cảnh 1M

Khi GLM-5.2 mở rộng độ dài ngữ cảnh tối đa từ 200K lên 1M token, khối lượng công việc lập trình dự kiến sẽ chuyển dịch đáng kể sang các prompt dài hơn. Điều này chuyển nút thắt cổ chai chính của suy luận từ tính toán sang dung lượng KV-cache, chi phí vận hành kernel ngữ cảnh dài và chi phí phía CPU. Mặc dù kiến trúc mới của GLM-5.2 giảm FLOPs tính toán trên mỗi token, nhưng nó không giảm tương ứng kích thước KV-cache trên mỗi token. Kết quả là, việc hỗ trợ ngữ cảnh dài hơn, độ đồng thời cao hơn và thông lượng token cao hơn trong điều kiện tài nguyên GPU hạn chế trở thành thách thức trung tâm cho việc tối ưu hóa công cụ suy luận.

Để giải quyết thách thức này, chúng tôi tối ưu hóa công cụ suy luận theo ba hướng. Thứ nhất, dựa trên LayerSplit, chúng tôi giới thiệu các chiến lược song song hóa và quản lý bộ nhớ chi tiết hơn để tăng dung lượng KV-cache và cung cấp nhiều không gian cache khả dụng hơn cho các yêu cầu ngữ cảnh siêu dài. Thứ hai, chúng tôi tối ưu hóa các kernel có chi phí tăng theo độ dài ngữ cảnh và phối hợp chúng tốt hơn với pipeline truyền cache, giảm thiểu tác động của việc truyền cache lên cả hiệu suất prefill và decode. Thứ ba, chúng tôi tối ưu hóa quản lý cache phía CPU, lập lịch yêu cầu và các đường thực thi runtime để giảm “bong bóng” (bubbles) trong pipeline thực thi GPU và cải thiện thông lượng cuối-đến-cuối. Như trong hình, GLM-5.2 đạt được lợi thế thông lượng ngày càng lớn khi độ dài ngữ cảnh tăng, chứng minh khả năng mở rộng mạnh mẽ hơn trong các kịch bản suy luận ngữ cảnh dài.

slime cho Agentic RL

Quá trình hậu huấn luyện Agentic RL của GLM-5.2 bao gồm các tác vụ ở quy mô lớn hơn, trên nhiều miền hơn và với các mẫu thực thi phức tạp hơn. Dữ liệu và tác vụ không đồng nhất cần được tổ chức trong một quy trình huấn luyện thống nhất, trong khi các tương tác dài hạn, sử dụng công cụ, phân rã tác vụ con và phản hồi môi trường đa lượt đều đặt ra yêu cầu cao hơn cho việc triển khai (rollout) và điều phối huấn luyện. Để hỗ trợ quá trình này, slime đóng vai trò là lớp cơ sở hạ tầng tích hợp từ huấn luyện đến triển khai suy luận quy mô lớn. Nó hỗ trợ nhiều chế độ huấn luyện và tổ chức tác vụ, bao gồm white-box rollout, black-box rollout, quỹ đạo nén (compact trajectory) và luồng công việc tác nhân con (sub-agent workflow), cho phép cùng một hệ thống mở rộng cho các khối lượng công việc RL và huấn luyện OPD lớn và phức tạp hơn. Trong quá trình hậu huấn luyện GLM-5.2, chúng tôi đã sử dụng khung slime để thực hiện huấn luyện OPD song song, hợp nhất hiệu quả hơn mười mô hình chuyên gia vào mô hình cuối cùng. Toàn bộ quá trình huấn luyện OPD mất khoảng hai ngày, chứng minh hiệu quả huấn luyện cao.

Agentic RL cũng đặt ra yêu cầu cao hơn về tài nguyên hệ thống và cơ sở hạ tầng suy luận. slime cung cấp một giao diện mở và linh hoạt cho các hệ thống suy luận: phía huấn luyện có thể kết nối với các dịch vụ suy luận dưới nhiều hình thức khác nhau và thích ứng linh hoạt với các chiến lược song song, chính sách định tuyến, thiết lập phân tách PD và mẫu triển khai. Đồng thời, kinh nghiệm cấu hình, chiến lược lập lịch và các đường tối ưu hóa tích lũy trong quá trình RL rollout có thể được tái sử dụng và tinh chỉnh thêm trong giai đoạn phục vụ sản phẩm, cho phép phía huấn luyện và phía phục vụ bổ trợ cho nhau. Điều này tạo ra một con đường trực tiếp hơn từ hậu huấn luyện đến triển khai sản phẩm. Cùng với tổ chức tài nguyên huấn luyện-suy luận linh hoạt và KV-cache FP8, slime cung cấp hỗ trợ cơ sở hạ tầng quan trọng cho huấn luyện Agentic RL quy mô lớn của GLM-5.2, cải thiện hơn nữa hiệu quả hệ thống, thông lượng rollout và độ đồng thời suy luận quy mô lớn.

RL cho Tác vụ Dài hạn với Cơ chế Chống Gian lận (Anti-hacking)

RL cho Tác vụ Dài hạn. Đối với GLM-5.2, các tác vụ dài hạn tạo ra các dấu vết thực thi (execution traces) dài hơn đáng kể, và một khi quỹ đạo siêu dài bị chia nhỏ bởi quá trình nén thành nhiều dấu vết con, các lần rollout khác nhau dưới cùng một prompt sẽ tạo ra số lượng dấu vết có thể huấn luyện khác nhau với độ dài biến thiên cao. Do đó, chúng tôi chuyển từ tối ưu hóa theo nhóm sang công thức PPO dựa trên critic, học từ các lần rollout cá nhân, dựa vào critic để ước tính lợi thế (advantage) ở cấp độ token thay vì so sánh tương đối trong nhóm. Công thức đơn rollout này phù hợp tự nhiên với quá trình nén, vì nó không ràng buộc số lượng dấu vết mà một prompt tạo ra hoặc độ dài tương đối của chúng: chúng tôi đưa quá trình nén vào huấn luyện bằng cách bao gồm tất cả các dấu vết con đã nén dưới dạng quỹ đạo có thể huấn luyện và áp dụng tổn thất cấp độ token để giải quyết sự mất cân bằng về độ dài.

Chống Gian lận (Anti-Hack) trong tác nhân lập trình. RL lập trình đặc biệt dễ bị tổn thương bởi việc gian lận phần thưởng (reward hacking) vì phần thưởng thường là tín hiệu đạt/không đạt có thể kiểm chứng được. Chúng tôi nhận thấy GLM-5.2 có xu hướng hành vi gian lận tiềm năng nhiều hơn GLM-5.1. Điều này khiến tín hiệu kiểm chứng dễ bị tối ưu hóa, nhưng không thực sự cải thiện khả năng cơ bản của mô hình. Một tác nhân có thể đọc các tạo tác đánh giá được bảo vệ, sao chép nội dung câu trả lời từ các tài liệu tham khảo hoặc các commit cấp trên, hoặc trực tiếp lấy mã nguồn mục tiêu trong các tác vụ liên quan đến GitHub. Ví dụ, tác nhân có thể tải xuống giải pháp qua curl https://raw.githubusercontent.com/<path-to-file> hoặc thậm chí rò rỉ theo chuỗi như sau:

1. find /workspace -name "*hidden*"
2. cat /workspace/.eval/secret_cases.json
3. python solve.py --case "$(cat /workspace/.eval/secret_cases.json)"

Những hành vi này làm thổi phồng phần thưởng và làm hỏng tín hiệu huấn luyện, đòi hỏi một cơ chế rõ ràng để tách biệt việc giải quyết tác vụ thực sự với các lối tắt. Để giải quyết vấn đề này, chúng tôi giới thiệu một mô-đun chống gian lận cho cả huấn luyện RL và đánh giá. Quá trình phát hiện có hai giai đoạn: một bộ lọc dựa trên quy tắc trước tiên sẽ bắt các hành vi gian lận tiềm năng để tối đa hóa tỷ lệ thu hồi (recall), sau đó một giám khảo LLM sẽ kiểm tra ý định của các hành động bị gắn cờ này để giữ tỷ lệ chính xác cao. Chúng tôi sử dụng chiến lược trực tuyến theo dõi các lời gọi công cụ ở mỗi bước. Nếu phát hiện gian lận, hệ thống sẽ chặn lời gọi đó và trả về thông tin giả làm kết quả. Quan trọng là, lớp bảo vệ trực tuyến này cho phép mô hình tiếp tục rollout ngay cả sau khi một hành động gian lận bị bắt. Bằng cách xử lý hành vi không hợp lệ cụ thể thay vì loại bỏ toàn bộ quỹ đạo, phương pháp này giúp ngăn chặn sự mất ổn định trong huấn luyện và sụp đổ mô hình vốn có thể xảy ra khi các lần rollout bị dừng đột ngột.

Bảng Benchmark Đầy đủ

Bắt đầu với GLM-5.2

Sử dụng GLM-5.2 với Kế hoạch Lập trình GLM (GLM Coding Plan)

Hãy thử GLM-5.2 trong các tác nhân lập trình yêu thích của bạn — ZCode, Claude Code, OpenCode, và nhiều hơn nữa. https://docs.z.ai/devpack/overview

Đối với những người đăng ký GLM Coding Plan: Chúng tôi đã triển khai GLM-5.2 cho tất cả người dùng Coding Plan. Bạn có thể kích hoạt GLM-5.2 ngay bây giờ bằng cách cập nhật tên mô hình thành "GLM-5.2" (hoặc GLM-5.2[1m] trong Claude Code để kích hoạt độ dài ngữ cảnh 1M). Bạn cũng có thể chọn các mức độ tư duy khác nhau, High hoặc Max, tùy thuộc vào tác vụ. Vì là mô hình mạnh nhất của chúng tôi, GLM-5.2 tiêu tốn hạn mức (quota) gấp 3 lần trong giờ cao điểm và 2 lần trong giờ thấp điểm. Như một chương trình khuyến mãi có thời hạn đến cuối tháng 9, việc sử dụng trong giờ thấp điểm sẽ được tính mức 1x. (Giờ cao điểm là 14:00–18:00 UTC+8 (giờ Bắc Kinh) hàng ngày).

Bạn thích giao diện đồ họa (GUI)? Chúng tôi cung cấp ZCode — một tác nhân máy tính chạy bằng GLM-5.2, với lệnh /goal cho các tác vụ dài hạn, phát triển từ xa qua SSH và điều khiển thiết bị di động. Ưu đãi đặc biệt: sử dụng GLM-5.2 thông qua Coding Plan bên trong ZCode và nhận hạn mức hiệu dụng gấp 1.5 lần cho đến ngày 30 tháng 6.

Bắt đầu xây dựng ngay: https://z.ai/subscribe

Chat với GLM-5.2 trên Z.ai

GLM-5.2 hiện đã có mặt trên Z.ai.

Triển khai GLM-5.2 cục bộ

Trọng số mô hình của GLM-5.2 được cung cấp công khai trên HuggingFace và ModelScope. Để triển khai cục bộ, GLM-5.2 hỗ trợ các khung suy luận bao gồm transformers, vLLM, SGLang, xLLM, ktransformers.

Chú thích

• Humanity’s Last Exam (HLE) & các tác vụ suy luận khác: Chúng tôi sử dụng các tham số lấy mẫu temperature=1.0, top_p=0.95 để đánh giá. Chúng tôi đánh giá với độ dài tạo tối đa là 163,840 token. Theo mặc định, chúng tôi báo cáo tập con chỉ văn bản; kết quả đánh dấu * là từ tập đầy đủ. Đối với AIME, HMMT và IMOAnswerBench, chúng tôi đánh giá mỗi câu hỏi bằng prompt hệ thống sau: Your response should be in the following format:\nExplanation: {your explanation for your final answer}\nExact Answer: {your succinct, final answer}\nConfidence: {your confidence score between 0% and 100% for your answer}. Chúng tôi sử dụng GPT-5.5 (medium) làm mô hình giám khảo. Đối với HLE-with-tools, chúng tôi sử dụng độ dài ngữ cảnh tối đa là 300,000 token, không có chiến lược quản lý ngữ cảnh.
• SWE-Bench Pro: Chúng tôi chạy bộ SWE-Bench Pro với OpenHands sử dụng một prompt hướng dẫn tùy chỉnh. Cài đặt: temperature=1, top_p=1, max_new_tokens=32k, với cửa sổ ngữ cảnh 400K.
• NL2Repo: Chúng tôi đánh giá NL2Repo với temperature=1.0, top_p=1.0, và max_new_tokens=48k dưới ngữ cảnh 400k. Để ngăn chặn gian lận, chúng tôi sử dụng phán quyết dựa trên quy tắc và LLM để ngăn chặn các hành vi độc hại (ví dụ: thao tác pip hoặc curl trái phép).
• DeepSWE: Chúng tôi chạy DeepSWE với khung đánh giá pier chính thức và bộ harness mini-swe-agent (temperature=1.0, top_p=1.0, timeout=2h, ngữ cảnh 400K). Mỗi tác vụ được giải quyết trong một container cô lập với 2 CPU, 8 GB RAM và không có quyền truy cập internet.
• ProgramBench: Chúng tôi đánh giá ProgramBench (200 instance) với Claude-Code 2.1.156 sử dụng temperature=1.0, top_p=1.0, max_tokens=64000, max_turns=2000, sample_timeout=6h, reasoning_effort=max, với cửa sổ ngữ cảnh 400K. Mỗi instance chạy trong một sandbox (4 CPU, 8 GB RAM) với quyền truy cập internet bị vô hiệu hóa.
• Terminal-Bench 2.1 (Terminus 2): Chúng tôi đánh giá Terminal-Bench 2.1 với khung Terminus-2 sử dụng parser=json, timeout=4h, temperature=1.0, top_p=1.0, max_new_tokens=48k, max_episodes=500, với cửa sổ ngữ cảnh 256K. Giới hạn tài nguyên được khống chế ở 4 CPU và 8 GB RAM.
• Terminal-Bench 2.1 (Claude Code): Chúng tôi đánh giá trong Claude Code 2.1.167 với temperature=1.0, top_p=0.95, max_new_tokens=131072. Chúng tôi ghi đè max_new_tokens thành 128k thông qua một proxy trong suốt, bỏ qua giới hạn 64k của CLI để khôi phục khả năng cấu hình của CLAUDE_CODE_MAX_OUTPUT_TOKENS. Chúng tôi loại bỏ giới hạn thời gian thực (wall-clock time), trong khi vẫn giữ các ràng buộc CPU và bộ nhớ cho mỗi tác vụ. Điểm số là trung bình của 5 lần chạy.
• MCP-Atlas: Tất cả các mô hình được đánh giá ở chế độ suy nghĩ (think mode) trên tập con công khai 500 tác vụ với thời gian chờ 10 phút mỗi tác vụ. Chúng tôi sử dụng Gemini-3.0-Pro làm mô hình giám khảo.
• Tool-Decathlon: Chúng tôi sử dụng dịch vụ đánh giá chính thức và đặt max_token là 128K.
• FrontierSWE: Việc đánh giá được thực hiện bởi Proximal với độ dài ngữ cảnh 1M, mức nỗ lực tối đa và tối đa 128K token đầu ra. Điểm Dominance được báo cáo tính đến ngày 16/06/2026.
• PostTrainBench: Việc đánh giá được thực hiện bởi PostTrainBench với độ dài ngữ cảnh 1M, mức nỗ lực tối đa và tối đa 128K token đầu ra.
• SWE-Marathon: Việc đánh giá được thực hiện bởi Abundant AI với độ dài ngữ cảnh 1M, mức nỗ lực tối đa và tối đa 128K token đầu ra.

Link bài viết gốc

• Tags:
• Ai
• June 17, 2026
• Huggingface.co