Nanbeige4.2-3B sắp được hỗ trợ bởi vLLM: Mô hình Agent 3B dạng vòng lặp của BOSS Zhipin thoát khỏi kỷ nguyên chỉ chạy trên fork

Nanbeige4.2-3B — mô hình agentic nhỏ gọn do Phòng thí nghiệm Nanbeige của BOSS Zhipin phát hành vào cuối tháng 7 năm 2026 — sắp có thể được phục vụ trên một bản cài đặt vLLM tiêu chuẩn lần đầu tiên. Một pull request mở vào ngày 9 tháng 9 năm 2026 bổ sung kiến trúc này vào registry mô hình của vLLM thông qua backend transformers. Nếu được hợp nhất, lệnh vllm serve Nanbeige/Nanbeige4.2-3B sẽ trở thành lệnh tiêu chuẩn thay vì nghi thức fork từ nhà cung cấp. Đó là một thay đổi thực sự về những gì người tự lưu trữ có thể làm: trong sáu tuần kể từ khi mô hình được phát hành, mọi engine phục vụ mà thẻ mô hình liệt kê — vLLM, SGLang, llama.cpp, Ollama — đều trỏ đến một fork do Nanbeige duy trì, chứ không phải bản cài đặt chưa sửa đổi.

Bản thân mô hình không phải là tin tức; nó đã có thể tải xuống từ tuần cuối của tháng Bảy. Tin tức là kỷ nguyên chỉ dành cho fork đang kết thúc, và nó kết thúc trong tuần này. SGLang đã hợp nhất một bản triển khai gốc của Nanbeige4.2 vào nhánh chính vào ngày 5 tháng 9, và pull request của vLLM được mở bốn ngày sau đó. Cả hai đều là hỗ trợ upstream, cài đặt tiêu chuẩn cho một kiến trúc mà trước đây mọi engine đều coi là trường hợp đặc biệt. Dưới đây, mọi thứ đều được ghi nhãn: pull request thực sự làm gì, điều gì đã được xác minh so với điều gì vẫn còn bỏ ngỏ, các tuyên bố benchmark của nhà cung cấp, và những con số độc lập đặt chúng trong bối cảnh.

Chính xác thì điều gì đã thay đổi trong tuần này?

Pull request của vLLM là vllm-project/vllm #56071, "[Model] Thêm hỗ trợ cho Nanbeige4.2 (backend transformers)", được một kỹ sư của Nanbeige mở vào ngày 9 tháng 9 và vẫn đang mở tại thời điểm viết bài. Nó được chủ ý giữ nhỏ — chỉ hai tệp. Tệp đầu tiên thêm một dòng vào sổ đăng ký mô hình của vLLM để ánh xạ tên kiến trúc Hugging Face NanbeigeForCausalLM sang TransformersForCausalLM, cơ chế dự phòng chung của vLLM để chạy mô hình qua backend transformers. Tệp thứ hai thêm một NanbeigeModelArchConfigConvertor, có nhiệm vụ duy nhất là báo cho vLLM biết cần dự trù bao nhiêu lớp: nó trả về num_hidden_layers của config nhân với num_loops, vì transformer vòng lặp của Nanbeige lặp lại ngăn xếp lớp của nó và vLLM phải định cỡ bộ đệm KV và các instance attention cho phù hợp.

Hai chi tiết từ chuỗi đánh giá quan trọng đối với bất kỳ ai đang theo dõi vấn đề này. Thứ nhất, ánh xạ đăng ký (registry mapping) chính là thứ khiến mô hình tự động chạy qua backend transformers — một người duy trì vLLM lưu ý rằng khi ánh xạ tồn tại, cờ --model-impl transformers tường minh trở nên thừa, và công việc còn lại trước khi hợp nhất (merge) là một mục tài liệu và một bài kiểm tra CI cho ánh xạ đăng ký. Thứ hai, các nhà đánh giá đã chỉ ra rằng một thay đổi vLLM được hợp nhất gần đây (PR #54941) có thể khiến bộ chuyển đổi số lớp (layer-count convertor) không còn cần thiết, bằng cách phát hiện trực tiếp các mô-đun attention thay vì suy ra chúng từ số lớp. Nói một cách đơn giản: bản sửa lỗi có thể trở nên đơn giản hơn trước khi ra mắt, chứ không phức tạp hơn.

Con đường vLLM quan trọng hơn vì chính ở điều nó không phải. Đây không phải lần thử đầu tiên đưa Nanbeige4.2 vào vLLM một cách nguyên bản. PR #49433, do chính kỹ sư đó mở vào cuối tháng 7 như một bản triển khai nguyên bản ngay từ ngày đầu, đã bị đóng vào ngày 9 tháng 9 — cùng ngày PR backend transformers xuất hiện — sau khi những người bảo trì cho rằng việc triển khai mô hình chuyên biệt tốn nhiều công sức hơn mức kiến trúc xứng đáng và thay vào đó chỉ sang backend transformers. Điểm mấu chốt cho độc giả: hỗ trợ vLLM thượng nguồn đang đến theo lộ trình tương thích, chứ không phải bằng bản triển khai nguyên bản được tinh chỉnh thủ công, và sự khác biệt đó có những hệ quả hiệu năng thực tế sẽ được thảo luận bên dưới.

Mô hình cần tất cả sự xử lý đặc biệt này

Để hiểu vì sao Nanbeige4.2-3B đã phá vỡ mọi giả định của các runtime, cần biết mô hình này là gì. Đây là mô hình có khoảng 4 tỷ tham số với 3 tỷ tham số phi nhúng, được phát hành theo giấy phép Apache-2.0 bằng tiếng Anh và tiếng Trung, nhắm thẳng vào các khối lượng công việc tác tử: tác tử mã nguồn, tự động hóa văn phòng, sử dụng công cụ, vận hành thiết bị đầu cuối. Báo cáo kỹ thuật (arXiv 2607.22083, ngày 24 tháng 7 năm 2026) mô tả việc tiền huấn luyện từ đầu trên 28 nghìn tỷ token, tiếp theo là công thức SFT kết hợp học tăng cường ba giai đoạn được xây dựng dựa trên tương tác với môi trường thực tế. Cửa sổ ngữ cảnh lên tới 262.144 token. Tất cả những điều đó đều có thể kiểm chứng.

Phần không bình thường nằm ở kiến trúc. Nanbeige4.2-3B sử dụng một "Looped Transformer": cùng một chồng 22 tầng transformer được chạy hai lần, do đó một mô hình 3B tham số thực hiện lượng tính toán trên mỗi token gần gấp đôi so với mô hình 3B thông thường mà không thêm trọng số nào. Đó là cách phòng thí nghiệm dung hòa số lượng tham số nhỏ với các tuyên bố benchmark vượt trên tầm cỡ của mình — mô hình thực chất có một lượt xử lý thứ hai trên chính các biểu diễn của nó, và cấu hình thể hiện sự tái sử dụng đó dưới dạng num_loops bằng 2 trên 22 tầng ẩn (44 giai đoạn attention hiệu dụng). Cái giá phải trả là mọi inference engine đều phải được chỉ dẫn cách xử lý một chồng tầng được sử dụng hai lần: cách đánh chỉ số attention cho KV cache và CUDA graphs, cách định cỡ cache, cách stream trọng số. Một engine tiêu chuẩn được xây dựng quanh mô hình transformer một lượt truyền xuôi hoàn toàn không biết phải làm gì với nó, đó là lý do mã mô hình tùy chỉnh được đóng gói sẵn trong repo và yêu cầu trust_remote_code=True trong Hugging Face Transformers.

Đoạn mã tùy chỉnh đó cũng chính là nơi chứa đựng những góc cạnh thô nhất của mô hình. Một báo cáo độc lập (arXiv 2608.13987, giữa tháng 8) đã ghi nhận năm lỗi khiến checkpoint được phát hành không thể tải trực tiếp trong Hugging Face Transformers — trong số đó có một bộ đệm rotary-position-embedding bị zero một cách âm thầm và các lời gọi tới những API cache đã bị gỡ bỏ — và các bài viết từ cộng đồng mô tả các giải pháp tạm thời như use_cache=False trước khi mô hình có thể chạy được. Những lỗi đó có thể khắc phục được, và các checkpoint cùng harness đã vá hiện đang được lưu hành, nhưng điều cốt lõi nằm ở khuôn mẫu lặp lại: đây là một kiến trúc thông minh nhưng đã phải trả một khoản thuế bất thường dưới dạng ma sát khi triển khai ngay từ ngày đầu.

Các con số, nhà cung cấp và độc lập

Tuyên bố điểm chuẩn nổi bật, trích thẳng từ báo cáo kỹ thuật, là Nanbeige4.2-3B vượt trội các mô hình mã nguồn mở lớn hơn — Qwen3.5-9B và Gemma4-12B — trong các bài đánh giá agentic. Con số chủ lực là SWE-Bench Verified đạt 63,6 so với 53,1 của Qwen3.5-9B và 44,2 của Gemma4-12B. Báo cáo cũng liệt kê GPQA-Diamond ở mức 87,4, HMMT-Feb-2026 ở mức 82,8, Terminal-Bench 2.0 ở mức 44,1 và SWE-Bench Pro ở mức 46,9. Không con số nào trong số này được tái lập độc lập trên bộ công cụ đánh giá mà nhà cung cấp lựa chọn, và chúng nên được hiểu là phần tự đánh giá của phòng thí nghiệm về mô hình của mình — cũng chính là phần mà thẻ mô hình tóm tắt là đứng đầu bảng xếp hạng mô hình nhỏ của Artificial Analysis.

Điều gần nhất với một cuộc kiểm tra độc lập cho đến nay đến từ một bề mặt hoàn toàn khác. Trong một bài benchmark trên thiết bị của Artificial Analysis × Liquid AI chạy trên iPhone 17 Pro và được công bố vào cuối tháng 8, một bản build 4-bit của Nanbeige4.2-3B đã đồng hạng về điểm trung bình cao nhất trong số 33 mô hình dưới 8GB hoạt động được ở ngữ cảnh 16K (63, ngang bằng với LFM2.5-2.6B và vượt trước một số mô hình lớp 9B), và ở ngữ cảnh 64K, nó đạt 65, chỉ đứng sau mức 66 của Ling 3.0 Tiny. Điểm số theo từng bài kiểm tra của nó rất nổi bật: dẫn đầu lĩnh vực ở MATH-500 (96%) và mạnh về gọi hàm (76% trên BFCL), nhưng tỷ lệ không ảo giác yếu ở mức 33% trên AA-Omniscience — và, yếu tố quyết định cho việc sử dụng thực tế, là chậm. Nó tạo ra khoảng 14 token mỗi giây và mất 21.4 giây và 4.0 GB để trả lời một prompt 1.024 token; với giới hạn trả lời 60 giây, điểm trung bình của nó đã sụp đổ từ 63 xuống 18. Nói cách khác: chất lượng đánh bại các mô hình 9B là có thật, và chi phí của kiến trúc vòng lặp tạo ra nó cũng có thật không kém.

Hỗ trợ từ upstream thực sự mang lại cho bạn điều gì

Ghép hai sự kiện upstream lại với nhau, bức tranh thực tế cho người tự host trở nên rõ ràng. Nếu bạn chạy SGLang, Nanbeige4.2-3B đã có thể được phục vụ từ bản cài đặt mặc định nhờ hỗ trợ từ nhánh chính đã được hợp nhất — không cần fork, với các bộ phân tích gọi công cụ và suy luận của mô hình được kết nối với cùng các bộ dò qwen3 mà SGLang đã tích hợp sẵn. Nếu bạn chạy vLLM, hỗ trợ mặc định chỉ cách một bước merge: dòng registry định tuyến mô hình tới backend transformers, bộ chuyển đổi kiến trúc tính toán kích thước bộ đệm một cách chính xác, và các bộ phân tích suy luận và gọi công cụ qwen3 được tái sử dụng — đó là cách giao diện gọi công cụ tương thích OpenAI hoạt động.

Điểm cần nói thẳng là hướng đi của vLLM là một đường tương thích, không phải đường đã được tinh chỉnh. Chạy NanbeigeForCausalLM thông qua TransformersForCausalLM nghĩa là vLLM thực thi mã Hugging Face của chính mô hình bên trong lớp phục vụ của nó thay vì một triển khai gốc với kernel tùy chỉnh và xử lý CUDA-graph — điểm khác biệt này chính là thứ SGLang đã chọn để xây dựng một cách thuần bản địa. Với mô hình 3B có chi phí mỗi token vốn đã tăng gấp đôi do vòng lặp, đường backend transformers khó có thể là đường phục vụ nhanh nhất, và lịch sử năm lỗi của mã tùy chỉnh bên dưới có nghĩa là đường này sẽ thừa hưởng mọi trục trặc còn sót lại trong đó. Đối với các tác vụ agentic, nơi tính chính xác của lời gọi công cụ và hành vi ngữ cảnh dài thường quan trọng hơn token thô mỗi giây, đó có thể là một sự đánh đổi chấp nhận được; còn với chat nhạy cảm độ trễ, bạn nên chạy benchmark trước khi đặt cược đường vận hành sản xuất vào nó. Và hai engine vẫn chỉ có bản fork: llama.cpp và Ollama vẫn trỏ vào các nhánh Nanbeige, trong khi máy chủ llama.cpp đi kèm trong LM Studio chưa hỗ trợ kiến trúc này.

Xem gì tiếp theo

Có ba điều sẽ làm thay đổi bức tranh. Thứ nhất, PR vLLM cần được merge và phát hành trong một bản release — hãy theo dõi thread và ghi chú phát hành của vLLM; các reviewer đã chỉ ra rằng còn thiếu một mục tài liệu và một ánh xạ checkpoint CI trước khi nó sẵn sàng để merge. Thứ hai, hãy theo dõi xem bộ chuyển đổi số lớp có vượt qua vòng review hay không, vì các maintainer tin rằng PR #54941 có thể đã khiến nó trở nên dư thừa — một dấu hiệu cho thấy workaround này phần lớn là giàn giáo xung quanh kiến trúc vòng lặp. Thứ ba, hãy theo dõi câu hỏi về nhà cung cấp lưu trữ: thẻ Hugging Face hiện không hiển thị nhà cung cấp inference nào phục vụ mô hình, và chúng tôi cũng không lưu trữ nó, nên hiện tại đây là câu chuyện self-host. Khi một nhà cung cấp niêm yết mô hình này, phần định tuyến sẽ trở nên đơn giản — một API duy nhất trên một danh mục mô hình lớn với giá niêm yết của nhà cung cấp được chuyển qua không thêm phí là cách ít rào cản để A/B test Nanbeige4.2-3B tự lưu trữ so với các mô hình lưu trữ mà nó tuyên bố vượt trội. Cho đến lúc đó, cột mốc đáng chú ý là cột mốc vừa xảy ra: sáu tuần sau một buổi ra mắt mà mọi runtime lớn đều đón nhận bằng một cái nhún vai và một bản fork, hai trong số chúng hiện phục vụ Nanbeige4.2-3B từ một bản cài đặt không chỉnh sửa.