Dukungan vLLM untuk Nanbeige4.2-3B Segera Hadir: Model Agen 3B Loop milik BOSS Zhipin Meninggalkan Era Khusus Fork

Nanbeige4.2-3B — {{1}}model agentik yang ringkas{{/1}} yang {{2}}dirilis oleh Nanbeige Lab milik BOSS Zhipin pada akhir Juli 2026{{/2}} — {{3}}sebentar lagi akan dapat dilayani pada instalasi vLLM standar untuk pertama kalinya{{/3}}. {{4}}Sebuah pull request yang dibuka pada 9 September 2026{{/4}} {{5}}menambahkan arsitektur tersebut ke registri model vLLM melalui backend transformers{{/5}}. {{6}}Jika digabungkan, vllm serve Nanbeige/Nanbeige4.2-3B menjadi perintah standar, bukan ritual fork dari vendor{{/6}}. {{7}}Itu adalah perubahan nyata dalam hal yang dapat dilakukan oleh seorang self-hoster{{/7}}: {{8}}selama enam minggu sejak model dirilis{{/8}}, {{9}}setiap mesin serving yang tercantum di kartu modelnya{{/9}} — {{10}}vLLM, SGLang, llama.cpp, Ollama{{/10}} — {{11}}menunjuk ke fork yang dikelola Nanbeige, bukan ke instalasi yang tidak dimodifikasi{{/11}}.

Model itu sendiri bukanlah berita; model tersebut sudah dapat diunduh sejak pekan terakhir bulan Juli. Beritanya adalah era khusus-fork akan berakhir, dan berakhir pekan ini. SGLang menggabungkan implementasi asli Nanbeige4.2 ke cabang utamanya pada 5 September, dan permintaan tarik vLLM dibuka empat hari kemudian. Keduanya adalah dukungan hulu dan instalasi standar untuk arsitektur yang sebelumnya diperlakukan setiap mesin sebagai kasus khusus. Di bawah ini, semuanya diberi label: apa yang sebenarnya dilakukan permintaan tarik tersebut, apa yang terverifikasi versus masih terbuka, klaim tolok ukur dari vendor, dan angka independen yang menempatkannya dalam konteks.

Apa yang berubah minggu ini, tepatnya?

Permintaan pull vLLM adalah vllm-project/vllm #56071, "[Model] Add support for Nanbeige4.2 (transformers backend)," dibuka pada 9 September oleh seorang insinyur Nanbeige dan masih terbuka saat tulisan ini dibuat. PR ini sengaja dibuat kecil — dua berkas. Berkas pertama menambahkan satu baris ke registri model vLLM yang memetakan nama arsitektur Hugging Face NanbeigeForCausalLM ke TransformersForCausalLM, fallback generik vLLM yang menjalankan model melalui backend transformers. Berkas kedua menambahkan NanbeigeModelArchConfigConvertor, yang satu-satunya tugasnya adalah memberi tahu vLLM berapa banyak lapisan yang perlu dialokasikan: konverter ini mengembalikan num_hidden_layers dari konfigurasi dikalikan num_loops, karena transformer berulang Nanbeige mengulang tumpukan lapisannya dan vLLM harus menyesuaikan ukuran KV-cache serta instance attention-nya.

Dua detail dari utas tinjauan penting bagi siapa pun yang mengikuti ini. Pertama, pemetaan registry itulah yang membuat model berjalan otomatis melalui backend transformers — seorang maintainer vLLM mencatat bahwa setelah pemetaan tersebut ada, flag eksplisit --model-impl transformers menjadi berlebihan, dan pekerjaan yang tersisa sebelum penggabungan adalah entri dokumentasi dan pemetaan registry uji CI. Kedua, para peninjau menandai bahwa perubahan vLLM yang baru digabungkan (PR #54941) mungkin sudah membuat konverter jumlah lapisan menjadi tidak perlu, karena mendeteksi modul perhatian secara langsung alih-alih menyimpulkannya dari jumlah lapisan. Secara sederhana: perbaikan ini mungkin menjadi lebih sederhana sebelum dirilis, bukan lebih rumit.

Jalur vLLM lebih penting justru karena apa yang bukan jalur itu. Ini bukan upaya pertama untuk memasukkan Nanbeige4.2 ke dalam vLLM secara native. PR #49433, yang dibuka oleh teknisi yang sama pada akhir Juli sebagai implementasi native hari pertama, ditutup pada 9 September — hari yang sama ketika PR backend transformers muncul — setelah para pemelihara berpendapat bahwa implementasi model khusus lebih banyak kerjanya daripada yang layak untuk arsitektur tersebut, dan mereka menunjuk backend transformers sebagai gantinya. Kesimpulan untuk pembaca: dukungan vLLM upstream tiba melalui jalur kompatibilitas, bukan implementasi native yang disetel secara manual, dan perbedaan itu memiliki konsekuensi performa nyata yang dibahas di bawah ini.

Model yang membutuhkan semua penanganan khusus ini

Untuk memahami mengapa Nanbeige4.2-3B melanggar semua asumsi runtime, ada baiknya kita mengetahui apa itu model ini. Model ini memiliki sekitar 4 miliar parameter dengan 3 miliar parameter non-embedding, dirilis di bawah lisensi Apache-2.0 dalam bahasa Inggris dan Mandarin, yang secara khusus ditujukan untuk beban kerja agentik: agen kode, otomatisasi kantor, penggunaan alat, dan operasi terminal. Laporan teknis (arXiv 2607.22083, tertanggal 24 Juli 2026) menjelaskan pelatihan awal dari nol pada 28 triliun token yang diikuti oleh resep SFT-plus-RL-tiga-tahap yang dibangun di sekitar interaksi lingkungan dunia nyata. Jendela konteksnya mencapai 262.144 token. Semua itu dapat diverifikasi.

Bagian yang tidak biasa adalah arsitekturnya. Nanbeige4.2-3B menggunakan "Looped Transformer": tumpukan yang sama dari 22 lapisan transformer dijalankan dua kali, sehingga model berparameter 3B melakukan komputasi per token kira-kira dua kali lipat dari model 3B konvensional tanpa menambah bobot. Dengan cara itulah lab tersebut menyelaraskan jumlah parameter yang kecil dengan klaim benchmark yang melampaui kelas bobotnya — model ini secara efektif mendapatkan lintasan kedua atas representasinya sendiri, dan konfigurasi tersebut mengekspresikan penggunaan ulang itu sebagai num_loops bernilai 2 pada 22 lapisan tersembunyi (44 tahap atensi efektif). Konsekuensinya, setiap mesin inferensi harus diberi tahu cara menangani tumpukan lapisan yang digunakan dua kali: cara mengindeks atensi untuk cache KV dan grafik CUDA, cara menentukan ukuran cache, cara mengalirkan bobot. Mesin standar yang dibangun untuk transformer satu lintasan maju tidak tahu cara menghadapinya, itulah sebabnya kode pemodelan khusus disertakan di dalam repositori dan memerlukan trust_remote_code=True di Hugging Face Transformers.

Kode khusus itu juga tempat hidup sisi-sisi paling kasar dari model ini. Sebuah laporan independen (arXiv 2608.13987, pertengahan Agustus) mendokumentasikan lima bug yang membuat checkpoint yang dirilis tidak bisa dimuat secara langsung di Hugging Face Transformers — antara lain buffer rotary-position-embedding yang di-nol-kan secara diam-diam dan pemanggilan API cache yang sudah dihapus — dan tulisan-tulisan komunitas menjelaskan solusi seperti use_cache=False sebelum model dapat berjalan sama sekali. Itu semua bisa diperbaiki, dan kini beredar checkpoint serta harness yang telah ditambal, tetapi polanya justru inti persoalannya: ini adalah arsitektur cerdas yang sejak awal membayar pajak yang tidak biasa dalam bentuk gesekan penerapan.

Angka-angka, vendor, dan independen

Klaim tolok ukur utama, langsung dari laporan teknis, adalah bahwa Nanbeige4.2-3B mengungguli model terbuka yang lebih besar — Qwen3.5-9B dan Gemma4-12B — di seluruh evaluasi agentik. Angka andalannya adalah SWE-Bench Verified dengan skor 63.6 dibandingkan Qwen3.5-9B yang mencapai 53.1 dan Gemma4-12B yang mencapai 44.2. Laporan tersebut juga mencantumkan GPQA-Diamond sebesar 87.4, HMMT-Feb-2026 sebesar 82.8, Terminal-Bench 2.0 sebesar 44.1, dan SWE-Bench Pro sebesar 46.9. Tidak satu pun dari skor-skor ini yang direproduksi secara independen pada harness pilihan vendor, dan skor-skor tersebut harus dibaca sebagai catatan laboratorium itu sendiri tentang modelnya — catatan yang sama yang dirangkum kartu model sebagai yang menempati posisi teratas di papan peringkat model kecil Artificial Analysis.

Hal yang paling mendekati pemeriksaan independen sejauh ini berasal dari aspek yang sama sekali berbeda. Dalam benchmark on-device Artificial Analysis × Liquid AI yang dijalankan pada iPhone 17 Pro dan diterbitkan pada akhir Agustus, build 4-bit dari Nanbeige4.2-3B berbagi skor rata-rata tertinggi di antara 33 model sub-8GB yang berfungsi pada konteks 16K (63, setara dengan LFM2.5-2.6B dan di depan beberapa model kelas 9B), dan pada konteks 64K ia mencetak 65, hanya kalah dari Ling 3.0 Tiny yang mencetak 66. Profil per-tesnya mencolok: terbaik di bidangnya pada MATH-500 (96%) dan kuat pada function-calling (76% pada BFCL), tetapi tingkat non-halusinasi yang lemah sebesar 33% pada AA-Omniscience — dan, yang menentukan untuk penggunaan nyata, lambat. Ia menghasilkan sekitar 14 token per detik dan membutuhkan 21.4 detik serta 4.0 GB untuk menjawab prompt 1.024 token; di bawah batas jawaban 60 detik, skor rata-ratanya anjlok dari 63 menjadi 18. Dengan kata lain: kualitas yang mengungguli model 9B itu nyata, dan demikian pula biaya arsitektur berulang yang menghasilkannya.

Apa yang sebenarnya Anda dapatkan dari dukungan upstream

Gabungkan kedua peristiwa upstream tersebut, dan gambaran praktis bagi pelaku self-hosting pun menjadi jelas. Jika Anda menjalankan SGLang, Nanbeige4.2-3B sudah dapat dilayani dari instalasi standar berkat dukungan cabang utama yang telah digabungkan — tanpa fork, dengan parser pemanggilan tool dan penalaran model yang terhubung ke detektor qwen3 yang sama yang sudah disertakan SGLang. Jika Anda menjalankan vLLM, dukungan standar hanya berjarak satu penggabungan: baris registry mengarahkan model ke backend transformers, konverter arsitektur mengatur ukuran cache dengan benar, dan parser penalaran serta pemanggilan tool qwen3 digunakan kembali, dan dengan cara itulah permukaan pemanggilan tool yang kompatibel dengan OpenAI bekerja.

Catatan jujurnya adalah bahwa jalur vLLM merupakan jalur kompatibilitas, bukan jalur yang disetel/dioptimalkan. Menjalankan NanbeigeForCausalLM melalui TransformersForCausalLM berarti vLLM mengeksekusi kode Hugging Face milik model itu sendiri di dalam lapisan serving-nya, alih-alih implementasi native dengan kernel kustom dan penanganan CUDA-graph — perbedaan itulah yang justru dipilih SGLang untuk dibangun secara native. Untuk model 3B yang biaya per-tokennya sudah dua kali lipat karena loop, jalur backend transformers kemungkinan besar bukan jalur penyajian tercepat yang mungkin, dan riwayat lima bug pada kode kustom yang mendasarinya berarti jalur tersebut mewarisi segala keanehan yang masih tersisa di dalamnya. Untuk beban kerja agentik, di mana kebenaran panggilan alat dan perilaku konteks panjang biasanya lebih penting daripada token mentah per detik, itu mungkin merupakan trade-off yang dapat diterima; untuk chat yang sensitif terhadap latensi, ada baiknya melakukan benchmarking sebelum Anda mempertaruhkan jalur produksi padanya. Dan dua mesin masih hanya berupa fork: llama.cpp dan Ollama terus menunjuk ke cabang-cabang Nanbeige, dengan server llama.cpp yang disertakan di LM Studio belum mendukung arsitektur tersebut.

Tontonan Berikutnya

Tiga hal akan mengubah gambaran. Pertama, PR vLLM harus digabung dan dimuat dalam sebuah rilis — pantau thread dan catatan rilis vLLM; peninjau telah menandai bahwa entri dokumentasi dan pemetaan checkpoint CI masih tersisa sebelum siap digabung. Kedua, perhatikan apakah konverter jumlah lapisan bertahan dalam peninjauan, karena pemelihara percaya PR #54941 mungkin membuatnya redundan — sebuah tanda betapa banyaknya workaround ini adalah perancah di sekitar arsitektur berulang. Ketiga, perhatikan soal penyedia ter-host: kartu Hugging Face saat ini tidak menunjukkan penyedia inferensi yang melayani model, dan kami juga tidak menghostingnya, jadi hari ini ini adalah cerita self-host. Ketika suatu penyedia mendaftarkannya, sisi perutean menjadi rutin — satu API di seluruh katalog model besar dengan harga list penyedia yang diteruskan tanpa markup adalah cara paling minim hambatan untuk A/B Nanbeige4.2-3B self-host melawan model ter-host yang diklaimnya bisa dikalahkan. Sampai saat itu, tonggak yang perlu dicatat adalah yang baru saja terjadi: enam minggu setelah peluncuran yang disambut dengan angkatan bahu dan fork oleh setiap runtime besar, dua di antaranya kini melayani Nanbeige4.2-3B dari instalasi yang tidak dimodifikasi.