- Qwen3-Coder-Next là mô hình ngôn ngữ mở trọng số được thiết kế cho các tác nhân viết mã và môi trường phát triển cục bộ, dựa trên kiến trúc hybrid attention và MoE
- Mô hình được huấn luyện thông qua tổng hợp tác vụ có thể thực thi ở quy mô lớn, tương tác với môi trường và học tăng cường, nhờ đó sở hữu năng lực lập trình và tác nhân mạnh mẽ ngay cả với chi phí suy luận thấp
- Thay vì chỉ mở rộng tham số đơn thuần, mô hình tập trung vào mở rộng tín hiệu huấn luyện tác nhân, tận dụng các bài toán lập trình có thể kiểm chứng và môi trường thực thi để học trực tiếp từ phản hồi
- Đạt hơn 70% trên SWE-Bench Verified, đồng thời cho thấy hiệu năng có thể cạnh tranh với các mô hình lớn trên SWE-Bench Pro và trong môi trường đa ngôn ngữ
- Dù là mô hình nhỏ, nó vẫn đạt được cân bằng Pareto giữa hiệu quả và hiệu năng, mang ý nghĩa quan trọng đối với việc triển khai tác nhân tiết kiệm chi phí
Tổng quan về Qwen3-Coder-Next
- Qwen3-Coder-Next là mô hình ngôn ngữ mở trọng số dựa trên Qwen3-Next-80B-A3B-Base
- Áp dụng kiến trúc hybrid attention và Mixture of Experts(MoE)
- Được huấn luyện thông qua tổng hợp tác vụ có thể thực thi ở quy mô lớn, tương tác với môi trường và học tăng cường
- Mục tiêu là sử dụng hiệu quả trong tác nhân lập trình và môi trường phát triển cục bộ
- Cung cấp năng lực suy luận và hiệu năng lập trình mạnh mẽ ngay cả với chi phí suy luận thấp
Phương thức mở rộng huấn luyện tác nhân
- Mô hình tập trung vào mở rộng tín hiệu huấn luyện tác nhân hơn là mở rộng số lượng tham số
- Kết hợp các bài toán lập trình có thể kiểm chứng với môi trường có thể thực thi để học trực tiếp từ phản hồi của môi trường
- Các giai đoạn huấn luyện chính
- Tiền huấn luyện liên tục với dữ liệu tập trung vào mã và tác nhân
- Tinh chỉnh có giám sát bằng dữ liệu quỹ đạo tác nhân chất lượng cao
- Huấn luyện chuyên biệt theo từng miền như kỹ thuật phần mềm, QA, web/UX
- Chưng cất nhiều mô hình chuyên gia thành một mô hình duy nhất có thể triển khai
- Cách tiếp cận này tăng cường năng lực suy luận dài hạn, sử dụng công cụ và khôi phục sau lỗi thực thi
Hiệu năng benchmark của tác nhân lập trình
- Được đánh giá trên nhiều benchmark như SWE-Bench (Verified, Multilingual, Pro), TerminalBench 2.0, Aider
- Đạt hơn 70% trên SWE-Bench Verified
- Vẫn duy trì tính cạnh tranh trên SWE-Bench Pro và trong môi trường đa ngôn ngữ
- Dù số lượng tham số kích hoạt nhỏ, hiệu năng ngang bằng hoặc vượt trội so với các mô hình mã nguồn mở lớn hơn
- Ở các tác vụ tác nhân nhiều lượt, việc tăng số lượt của tác nhân được xác nhận là giúp tăng cường năng lực suy luận dài hạn
Cân bằng giữa hiệu quả và hiệu năng
- Qwen3-Coder-Next (3B active) đạt hiệu năng SWE-Bench-Pro tương đương với các mô hình lớn hơn 10~20 lần
- Dù các mô hình độc quyền dựa trên full attention vẫn dẫn trước về hiệu năng tuyệt đối, Qwen3-Coder-Next nằm trên đường biên Pareto vượt trội về hiệu quả theo chi phí
- Điều này cho thấy đây là mô hình phù hợp để triển khai tác nhân tiết kiệm chi phí
Demo và ví dụ ứng dụng
- Là mô hình coder nhỏ gọn, tốc độ cao, có thể được tích hợp vào nhiều môi trường ứng dụng khác nhau
- Được trình diễn trên OpenClaw, Qwen Code, Claude Code, Web Dev, Browser Use, Cline
- Có thể sử dụng qua web tại coder.qwen.ai
Tóm tắt và kế hoạch sắp tới
- Qwen3-Coder-Next chứng minh tốc độ và năng lực suy luận xuất sắc trên các benchmark tác nhân lập trình
- So với các mô hình mã nguồn mở lớn, mô hình vẫn cho thấy hiệu năng cạnh tranh, dù vẫn còn dư địa để cải thiện
- Trong thời gian tới, dự kiến sẽ tăng cường năng lực sử dụng công cụ, giải quyết vấn đề phức tạp, khả năng ra quyết định và
- lên kế hoạch cập nhật nhanh dựa trên phản hồi người dùng cùng hỗ trợ thêm nhiều tác vụ hơn
1 bình luận
Ý kiến trên Hacker News
Mô hình GGUF này có kích thước 48.4GB, nên có thể chạy được cả trên laptop cấu hình cao
Cho đến giờ tôi vẫn chưa thấy mô hình cục bộ nào có thể chạy tử tế một coding agent ở mức Codex CLI hay Claude Code trên chiếc MacBook Pro 64GB của tôi
Không biết lần này có khác không. Xem hướng dẫn của Unsloth thì có vẻ khá hứa hẹn
Chỉ vì nó được nối qua llama.cpp trên cùng một máy thì gọi là local vẫn chưa đủ. Local theo ý tôi là mô hình LAN, tức mức mà tôi có thể chạy inference “miễn phí” trên phần cứng do chính mình kiểm soát
Ví dụ, cấu hình 5090 + Threadripper + 256GB RAM rơi vào khoảng 10 nghìn USD, còn hướng MLX thì khoảng 6 nghìn USD
Kiến trúc bên trong và cách lượng tử hóa của mô hình ảnh hưởng rất lớn đến mức dùng bộ nhớ thực tế, nên việc chỉ so bằng số tham số ngày càng kém ý nghĩa
Vì vậy tôi nghĩ cần một hệ thống benchmark các tác vụ thực tế như tool calling, sinh mã, xử lý tài liệu trên một chuẩn phần cứng được tiêu chuẩn hóa
Dù là một chiếc laptop Razer Blade cũ, nó vẫn hoạt động khá ổn cho đến 64k context
Với các việc như dự án nhỏ, sửa bug hay cải thiện UI thì hoàn toàn dùng được
Tuy nhiên tôi nghĩ tiêu chuẩn “usable” là khác nhau với mỗi người. Đánh giá sẽ thay đổi tùy theo bạn thử loại công việc nào
Có vẻ sẽ khá hữu ích nếu gom các log chạy tốt của bản 120b rồi fine-tune một bản 20b
Khi tăng reasoning_effort thì kết quả khá ổn, nhưng vì giới hạn bộ nhớ 64GB nên cải thiện bản 20b là phương án thực tế hơn
Nó đủ dùng cho các việc như dọn dẹp mã trong một dự án git cũ, viết tài liệu và thêm test
Có thể tiêu chuẩn của tôi hơi thấp, nhưng với vai trò trợ lý lập trình cục bộ thì tôi khá hài lòng
Khi sản lượng GPU hiệu năng cao và bộ nhớ tăng lên, cộng với tối ưu hóa mô hình tiếp tục tiến triển, phần cứng tầm trung cũng sẽ đủ cho hiệu năng tốt
Họ đã đưa Dynamic Unsloth GGUF để triển khai cục bộ lên Hugging Face,
đồng thời cũng viết hướng dẫn để dùng Claude Code / Codex ở môi trường cục bộ
Tôi chạy server llama.cpp trên môi trường dùng Radeon RX 7900 XTX, và nó hoạt động ổn định với thiết lập ctx-size 32768
Cũng có câu hỏi vì sao nên dùng bản Unsloth thay vì bản GGUF mặc định của Qwen3
Tôi đã cài llama.cpp bằng Homebrew và chạy mô hình lượng tử hóa của Unsloth trên máy cục bộ
Tôi có thể bật cùng lúc giao diện CLI và server API tương thích OpenAI, và nó dùng khoảng 28GB RAM
Nếu mô hình này thực sự đúng như tuyên bố thì việc đạt hiệu năng lập trình ngang Sonnet 4.5 với 3B tham số kích hoạt là điều cực kỳ lớn
Ngay cả với bài toán đơn giản cũng có lỗi, và đôi khi còn rơi vào thinking loop
Có thể là bug ở giai đoạn triển khai ban đầu, nhưng hiện tại thì tuyên bố hiệu năng có vẻ bị thổi phồng
Tôi đã thử chạy Qwen3 Coder 30B cục bộ trên Mac M4 Max (36GB)
Dù chậm nhưng nó chạy được, và cho kết quả khá ổn
Tôi chia sẻ video trình diễn và bài blog cách thiết lập
Trên laptop VRAM 6GB, tôi đạt 17 tok/s, và có thể lên tới context tối đa 100k
Dù khá bất ngờ, tốc độ vẫn chậm nên cuối cùng tôi vẫn sẽ tiếp tục dùng cloud inference
Tôi đã chia sẻ [ví dụ cấu hình docker-compose]
Tôi benchmark mô hình FP8 trong môi trường DGX Spark + vLLM 0.15.1
Với một request đơn lẻ, nó đạt khoảng 43 tok/s, còn khi chạy song song thì tối đa lên tới 62 tok/s
Bản lượng tử hóa 4-bit của llama.cpp đạt khoảng 30~35 tok/s, và ngay cả ở 200k context cũng chỉ dùng 50GB RAM
Với 3B tham số kích hoạt, hiệu năng của nó thấp hơn GLM 4.7 một chút, nhưng hiệu suất thì rất ấn tượng
Nó nhanh, và tôi nghĩ nếu dùng một coding agent đơn giản cùng orchestrator thì tốc độ tổng thể có khi còn nhanh hơn
Tôi tự động hóa các tác vụ lặp lại như quét mã, tìm thư viện, và duyệt SourceGraph
Nhờ tính năng Workspace của Mastra mà việc phát triển theo kiểu agent trở nên mạnh hơn nhiều
Tôi đã chạy lmstudio-community/Qwen3-Coder-Next-GGUF:Q8_0 trên Strix Halo,
đạt 32 tok/s và có thể lên tới 128k context. Nó hơi yếu hơn MiniMax M2.1 Q6, nhưng vẫn rất ấn tượng
FP8 dùng tới 110GB nên chỉ chạy được 16k context
Tôi đã thử nó cho việc sinh mã Rust và thấy nó khá có năng lực. Nếu tốc độ được cải thiện thì có vẻ sẽ dùng được trong thực tế
Có lẽ sắp tới các nhà cung cấp API sẽ phục vụ mô hình này với giá rẻ
Tôi muốn biết nguồn nào đáng tin để xem xếp hạng mô hình cục bộ
Tôi cảm giác benchmark bị thao túng quá nhiều, nên review cá nhân có ý nghĩa hơn
Tôi muốn biết có nơi nào tổng hợp các mô hình tốt nhất theo từng lĩnh vực như mã, giọng nói, hình ảnh, tóm tắt, âm nhạc hay không