Nanbeige4.2-3B vLLM-stöd är på väg: BOSS Zhipins loopade 3B-agentmodell lämnar sin fork-only-era

Nanbeige4.2-3B — den kompakta agentmodellen som BOSS Zhipins Nanbeige Lab släppte i slutet av juli 2026 — är på väg att bli serverbar på en vanlig vLLM-installation för första gången. En pull request som öppnades den 9 september 2026 lägger till arkitekturen i vLLM:s modellregister via transformers-backend. Om den mergas blir vllm serve Nanbeige/Nanbeige4.2-3B ett standardkommando istället för en leverantörsspecifik fork-ritual. Det är en verklig förändring i vad en self-hostare kan göra: under de sex veckorna sedan modellen släpptes har varje serveringsmotor som dess modellkort listar — vLLM, SGLang, llama.cpp, Ollama — pekat på en Nanbeige-underhållen fork, inte på en omodifierad installation.

Själva modellen är inte nyheten; den har varit nedladdningsbar sedan sista veckan i juli. Nyheten är att fork-only-eran är på väg att ta slut, och den slutar den här veckan. SGLang sammanfogade en inbyggd implementation av Nanbeige4.2 i sin huvudgren den 5 september, och vLLM-pull requesten öppnades fyra dagar senare. Båda är upstream-stöd i standardinstallationen för en arkitektur som varje motor tidigare behandlade som ett specialfall. Nedan är allt märkt: vad pull requestarna faktiskt gör, vad som är verifierat jämfört med vad som fortfarande är öppet, leverantörens benchmark-påståenden och de oberoende siffrorna som sätter dem i sammanhang.

Vad exakt förändrades den här veckan?

vLLM-pull requesten är vllm-project/vllm #56071, "[Model] Add support for Nanbeige4.2 (transformers backend)", öppnad den 9 september av en Nanbeige-ingenjör och fortfarande öppen när detta skrivs. Den är medvetet liten — två filer. Den första lägger till en rad i vLLM:s modellregister som mappar Hugging Face-arkitekturnamnet NanbeigeForCausalLM till TransformersForCausalLM, vLLM:s generiska reservlösning som kör en modell genom transformers-backend. Den andra lägger till en NanbeigeModelArchConfigConvertor, vars enda uppgift är att tala om för vLLM hur många lager som ska budgeteras: den returnerar config:ens num_hidden_layers multiplicerat med num_loops, eftersom Nanbeiges loopade transformer upprepar sin lagerstack och vLLM måste storleksanpassa sina KV-cache- och attention-instanser därefter.

Två detaljer från granskningstråden är viktiga för alla som följer detta. För det första är det registermappningen som gör att modellen automatiskt körs genom transformers-backendet — en vLLM-underhållare noterade att när mappningen väl finns blir den explicita flaggan --model-impl transformers överflödig, och att det återstående arbetet före sammanslagningen är en dokumentationspost och en CI-test av registermappningen. För det andra flaggade granskarna att en nyligen sammanslagen vLLM-ändring (PR #54941) redan kan göra konverteraren för lagerantal onödig, genom att direkt detektera attention-moduler istället för att härleda dem från ett lagerantal. Enkelt uttryckt: korrigeringen kan bli enklare innan den lanseras, inte mer komplicerad.

vLLM-vägen är viktigare på grund av vad den inte är. Detta är inte det första försöket att få in Nanbeige4.2 i vLLM inbyggt. PR #49433, som öppnades av samme ingenjör i slutet av juli som en inbyggd day-zero-implementation, stängdes den 9 september — samma dag som transformers-backend-PR:n dök upp — efter att underhållarna argumenterade att en skräddarsydd modellimplementation innebar mer arbete än vad arkitekturen motiverade och istället pekade på transformers-backend. Slutsatsen för läsarna: upstream vLLM-stöd kommer via kompatibilitetsvägen, inte genom en handjusterad inbyggd implementation, och den skillnaden har verkliga prestandakonsekvenser som diskuteras nedan.

Modellen som behövde all denna speciella hantering

För att förstå varför Nanbeige4.2-3B krossade varje runtimes antaganden hjälper det att veta vad modellen är. Det är en modell med cirka 4 miljarder parametrar, varav 3 miljarder icke-inbäddningsparametrar, släppt under Apache-2.0 på engelska och kinesiska, riktad direkt mot agentiska arbetsbelastningar: kodagenter, kontorsautomation, verktygsanvändning och terminalhantering. Den tekniska rapporten (arXiv 2607.22083, daterad 24 juli 2026) beskriver förträning från grunden på 28 biljoner token följt av ett SFT-plus-trestegs-RL-recept byggt kring interaktion med verkliga miljöer. Kontextfönstret sträcker sig till 262 144 token. Allt detta är verifierbart.

Det som inte är vanligt är arkitekturen. Nanbeige4.2-3B använder en "Looped Transformer": samma stack av 22 transformerlager körs två gånger, så en modell med 3B-parametrar gör ungefär dubbelt så mycket beräkning per token som en konventionell 3B-modell, utan att lägga till några vikter. På så sätt får labbet ett litet antal parametrar att matcha benchmark-påståenden som når över viktklassen — modellen får i praktiken en andra genomkörning av sina egna representationer, och konfigurationen uttrycker den återanvändningen som num_loops på 2 över 22 dolda lager (44 effektiva uppmärksamhetsstadier). Avvägningen är att varje inferensmotor måste få veta hur den ska hantera en lagerstack som används två gånger: hur man indexerar uppmärksamhet för KV-cache och CUDA-grafer, hur man storlekssätter cachen, hur man strömmar vikter. En standardmotor byggd kring transformatorer med ett enda framåtdriv har ingen aning om vad den ska göra med detta, vilket är anledningen till att den anpassade modelleringskoden följer med i repot och kräver trust_remote_code=True i Hugging Face Transformers.

Den där specialskrivna koden är också där modellens råaste kanter finns. En oberoende rapport (arXiv 2608.13987, i mitten av augusti) dokumenterade fem buggar som hindrade den släppta checkpojnten från att laddas direkt i Hugging Face Transformers – bland annat en buffert för rotary-position-embedding som tyst nollställts och anrop till borttagna cache-API:er – och community-inlägg beskrev kringgåenden som use_cache=False innan modellen över huvud taget kunde köras. Det gick att åtgärda, och patchade checkpoints och harnessar cirkulerar nu, men mönstret är poängen: det här är en smart arkitektur som sedan dag ett har fått betala en ovanlig skatt i driftsfriktion.

Siffrorna, leverantör och oberoende

Det huvudsakliga benchmark-påståendet, direkt från den tekniska rapporten, är att Nanbeige4.2-3B överträffar större öppna modeller – Qwen3.5-9B och Gemma4-12B – i agentiska utvärderingar. Flaggskeppssiffran är SWE-Bench Verified på 63,6 mot Qwen3.5-9B:s 53,1 och Gemma4-12B:s 44,2. Rapporten listar också GPQA-Diamond på 87,4, HMMT-Feb-2026 på 82,8, Terminal-Bench 2.0 på 44,1 och SWE-Bench Pro på 46,9. Ingen av dessa har oberoende reproducerats på leverantörens valda testmiljö, och de bör läsas som labbets egen redogörelse för sin modell – samma redogörelse som modellkortet sammanfattar som att modellen toppar Artificial Analysis leaderboard för små modeller.

Det närmaste vi hittills kommit ett oberoende test kommer från en helt annan yta. I en Artificial Analysis × Liquid AI on-device-benchmark som kördes på en iPhone 17 Pro och publicerades i slutet av augusti, hamnade en 4-bitarsversion av Nanbeige4.2-3B på delad första plats med högst genomsnittspoäng bland 33 fungerande modeller under 8 GB vid en kontext på 16K (63, i nivå med LFM2.5-2.6B och före flera modeller i 9B-klassen), och vid en kontext på 64K fick den 65, endast efter Ling 3.0 Tiny:s 66. Dess testprofil var slående: bäst i fältet på MATH-500 (96 %) och stark på funktionsanrop (76 % på BFCL), men en svag 33-procentig icke-hallucinationsgrad på AA-Omniscience – och, avgörande för verklig användning, långsam. Den genererade ungefär 14 tokens per sekund och tog 21,4 sekunder och 4,0 GB för att besvara en prompt på 1 024 tokens; under en 60-sekunders svarstak kollapsade dess genomsnittspoäng från 63 till 18. Med andra ord: kvaliteten som slår 9B-modeller är verklig, och detsamma gäller kostnaden för den loopade arkitekturen som producerar den.

Vad uppströmsstöd faktiskt ger dig

Lägger man ihop de två uppströmshändelserna blir den praktiska bilden för en self-hostare okomplicerad. Kör du SGLang går Nanbeige4.2-3B redan att betjäna från en standardinstallation med det sammanslagna main-branch-stödet — ingen fork, och modellens verktygsanrops- och resonemangsparsers är kopplade till samma qwen3-detektorer som SGLang redan levererar. Kör du vLLM är standardstödet bara en merge bort: registerraden dirigerar modellen till transformers-backend, arkitekturomvandlaren dimensionerar cachen korrekt, och qwen3:s resonemangs- och verktygsanropsparsers återanvänds, vilket är så det OpenAI-kompatibla verktygsanropsgränssnittet fungerar.

Den ärliga brasklappen är att vLLM:s väg är en kompatibilitetsväg, inte en finjusterad sådan. Att köra NanbeigeForCausalLM genom TransformersForCausalLM innebär att vLLM exekverar modellens egen Hugging Face-kod i sitt serveringslager snarare än en nativ implementation med anpassade kärnor och CUDA-grafhantering – skillnaden är precis vad SGLang valde att bygga nativt. För en 3B-modell vars kostnad per token redan är fördubblad av loopen är transformers-backend-vägen osannolikt den snabbaste möjliga serveringsvägen, och historien med fem buggar i den underliggande anpassade koden innebär att vägen ärver de egenheter som finns kvar i den. För agentiska arbetsbelastningar, där korrektheten i verktygsanrop och beteendet vid långa kontexter oftast betyder mer än råa tokens per sekund, kan det vara en acceptabel avvägning; för latenskänslig chatt är det värt att benchmarka innan du satsar en produktionsväg på den. Och två motorer är fortfarande endast tillgängliga som forks: llama.cpp och Ollama pekar fortfarande på Nanbeige-branches, och den medföljande llama.cpp-servern i LM Studio stöder ännu inte arkitekturen.

Vad du ska titta på härnäst

Tre saker skulle var och en förändra bilden. För det första behöver vLLM-pull requesten slås samman och släppas i en version — håll koll på tråden och vLLM:s versionsanteckningar; granskarna har redan påpekat att en dokumentationspost och en CI-checkpointmappning återstår innan den är redo för sammanslagning. För det andra, håll koll på om lagerantalskonverteraren överlever granskningen, eftersom underhållarna anser att PR #54941 kan ha gjort den överflödig — ett tecken på hur mycket av denna kringgående lösning som är stödkonstruktion kring den loopade arkitekturen. För det tredje, håll koll på frågan om värdleverantör: Hugging Face-kortet visar för närvarande ingen inferensleverantör som serverar modellen, och vi är inte värd för den heller, så idag handlar det om självhystning. När en leverantör väl listar den blir routingsidan rutin — ett API över en stor modellkatalog med leverantörens listpriser som förs vidare utan påslag är den friktionsfria vägen att A/B-testa en självhostad Nanbeige4.2-3B mot de hostade modeller som den påstår sig slå. Tills dess är milstolpen att notera den som precis inträffade: sex veckor efter en lansering som varje större runtime mötte med en axelryckning och en fork, serverar nu två av dem Nanbeige4.2-3B från en oförändrad installation.