Nanbeige4.2-3B: è in arrivo il supporto vLLM — il modello agente looped 3B di BOSS Zhipin lascia l'era del solo fork

Nanbeige4.2-3B — il modello agentico compatto che il Nanbeige Lab di BOSS Zhipin ha rilasciato a fine luglio 2026 — sta per poter essere servito per la prima volta su un'installazione vLLM standard. Una pull request aperta il 9 settembre 2026 aggiunge l'architettura al registro dei modelli di vLLM tramite il backend transformers. Se viene accettata, vllm serve Nanbeige/Nanbeige4.2-3B diventa un comando standard invece di un rituale di fork del fornitore. Questo è un vero cambiamento in ciò che un self-hoster può fare: per le sei settimane da quando il modello è uscito, ogni motore di serving elencato nella sua model card — vLLM, SGLang, llama.cpp, Ollama — ha puntato a un fork mantenuto da Nanbeige, non a un'installazione non modificata.

Il modello in sé non è la notizia; è scaricabile dall'ultima settimana di luglio. La notizia è che l'era dei soli fork sta finendo, e sta finendo questa settimana. SGLang ha integrato un'implementazione nativa di Nanbeige4.2 nel suo ramo principale il 5 settembre, e la pull request di vLLM è stata aperta quattro giorni dopo. Entrambi sono supporto upstream, da installazione standard, per un'architettura che ogni motore in precedenza trattava come un caso speciale. Di seguito, tutto è etichettato: cosa fanno realmente le pull request, cosa è verificato rispetto a ciò che è ancora aperto, le affermazioni sui benchmark del fornitore e i numeri indipendenti che le contestualizzano.

Cosa è cambiato questa settimana, precisamente

La pull request di vLLM è vllm-project/vllm #56071, "[Model] Add support for Nanbeige4.2 (transformers backend)", aperta il 9 settembre da un ingegnere di Nanbeige e ancora aperta al momento della stesura. È volutamente piccola — due file. Il primo aggiunge una riga al registro dei modelli di vLLM che mappa il nome dell'architettura Hugging Face NanbeigeForCausalLM su TransformersForCausalLM, il fallback generico di vLLM che esegue un modello tramite il backend transformers. Il secondo aggiunge un NanbeigeModelArchConfigConvertor, il cui unico compito è dire a vLLM quanti livelli prevedere: restituisce il num_hidden_layers della config moltiplicato per num_loops, perché il transformer a loop di Nanbeige ripete la propria pila di livelli e vLLM deve dimensionare di conseguenza la propria KV-cache e le istanze di attenzione.

Due dettagli dal thread di revisione contano per chiunque stia seguendo la questione. Primo, la mappatura del registro è ciò che fa eseguire il modello automaticamente attraverso il backend transformers — un maintainer di vLLM ha notato che una volta esistente la mappatura, il flag esplicito --model-impl transformers diventa ridondante, e che il lavoro rimanente prima del merge è una voce nella documentazione e una mappatura del registro di test per la CI. Secondo, i revisori hanno segnalato che una modifica vLLM recentemente integrata (PR #54941) potrebbe già rendere superfluo il convertitore del numero di layer, rilevando direttamente i moduli di attenzione invece di dedurli da un conteggio di layer. In termini semplici: la correzione potrebbe diventare più semplice prima di essere pubblicata, non più complicata.

Il percorso vLLM conta di più per ciò che non è. Non è il primo tentativo di integrare Nanbeige4.2 in vLLM in modo nativo. La PR #49433, aperta dallo stesso ingegnere a fine luglio come implementazione nativa day-zero, è stata chiusa il 9 settembre — lo stesso giorno in cui è apparsa la PR del backend transformers — dopo che i maintainer hanno sostenuto che un'implementazione su misura del modello comportasse più lavoro di quanto l'architettura giustificasse, indicando invece il backend transformers. Il messaggio per i lettori: il supporto vLLM a monte sta arrivando tramite la via della compatibilità, non attraverso un'implementazione nativa ottimizzata a mano, e questa distinzione ha conseguenze reali sulle prestazioni, discusse più avanti.

Il modello che necessitava di tutta questa gestione speciale

Per capire perché Nanbeige4.2-3B ha infranto le assunzioni di ogni runtime, aiuta sapere cos'è il modello. È un modello di circa 4 miliardi di parametri, con 3 miliardi di parametri non di embedding, rilasciato sotto licenza Apache-2.0 in inglese e cinese, pensato appositamente per carichi di lavoro agentici: agenti di codice, automazione d'ufficio, uso di strumenti, operazioni da terminale. Il rapporto tecnico (arXiv 2607.22083, datato 24 luglio 2026) descrive un pre-addestramento da zero su 28 trilioni di token, seguito da una ricetta SFT-più-RL-in-tre-fasi costruita attorno all'interazione con ambienti reali. La finestra di contesto arriva a 262.144 token. Tutto questo è verificabile.

La parte non ordinaria è l'architettura. Nanbeige4.2-3B usa un "Looped Transformer": lo stesso stack di 22 layer transformer viene eseguito due volte, quindi un modello da 3 miliardi di parametri svolge all'incirca il doppio del calcolo per token di un 3B convenzionale senza aggiungere pesi. È così che il laboratorio concilia un numero ridotto di parametri con risultati benchmark che superano la sua categoria di peso: il modello ottiene di fatto un secondo passaggio sulle proprie rappresentazioni, e la configurazione esprime questo riutilizzo come num_loops di 2 su 22 layer nascosti (44 stadi di attenzione effettivi). Il compromesso è che ogni motore di inferenza deve essere istruito su come gestire uno stack di layer usato due volte: come indicizzare l'attenzione per la cache KV e i grafi CUDA, come dimensionare la cache, come trasmettere i pesi. Un motore standard costruito attorno a transformer a passaggio unico in avanti non ha idea di cosa farne, ed è per questo che il codice di modellazione personalizzato è incluso nel repository e richiede trust_remote_code=True in Hugging Face Transformers.

È anche in quel codice personalizzato che si annidano gli spigoli più grezzi del modello. Un rapporto indipendente (arXiv 2608.13987, metà agosto) ha documentato cinque bug che impedivano al checkpoint rilasciato di caricarsi senza interventi in Hugging Face Transformers — tra cui un buffer di rotary-position-embedding azzerato silenziosamente e chiamate ad API della cache rimosse — e i resoconti della community descrivevano soluzioni alternative come use_cache=False prima che il modello potesse funzionare. Erano problemi risolvibili, e ora circolano checkpoint e harness patchati, ma il pattern è proprio il punto: è un'architettura ingegnosa che ha pagato una tassa insolita in termini di attrito di deployment fin dal primo giorno.

I numeri, il fornitore e indipendente

Il benchmark di punta dichiarato, direttamente dal report tecnico, è che Nanbeige4.2-3B supera modelli open più grandi — Qwen3.5-9B e Gemma4-12B — nelle valutazioni agentiche. Il numero di punta è SWE-Bench Verified a 63.6 contro il 53.1 di Qwen3.5-9B e il 44.2 di Gemma4-12B. Il report elenca anche GPQA-Diamond a 87.4, HMMT-Feb-2026 a 82.8, Terminal-Bench 2.0 a 44.1 e SWE-Bench Pro a 46.9. Nessuno di questi è stato riprodotto in modo indipendente sull'harness scelto dal fornitore, e vanno letti come la descrizione che il laboratorio fa del proprio modello — la stessa descrizione che la scheda del modello riassume come posizionata in cima alla classifica dei modelli piccoli di Artificial Analysis.

La cosa più vicina a una verifica indipendente finora arriva da un ambito completamente diverso. In un benchmark on-device di Artificial Analysis × Liquid AI eseguito su un iPhone 17 Pro e pubblicato a fine agosto, una build a 4 bit di Nanbeige4.2-3B è arrivato primo a pari merito per il punteggio medio più alto tra 33 modelli funzionanti sotto gli 8 GB con un contesto di 16K (63, alla pari con LFM2.5-2.6B e davanti a diversi modelli di classe 9B), e con un contesto di 64K ha totalizzato 65, secondo solo ai 66 di Ling 3.0 Tiny. Il suo profilo nei singoli test era sorprendente: il migliore in campo su MATH-500 (96%) e forte nel function-calling (76% su BFCL), ma con un debole tasso di non-allucinazione del 33% su AA-Omniscience — e, fattore decisivo per l'uso reale, lento. Ha generato circa 14 token al secondo e ha impiegato 21,4 secondi e 4,0 GB per rispondere a un prompt di 1.024 token; con un limite massimo di risposta di 60 secondi, il suo punteggio medio è crollato da 63 a 18. In altre parole: la qualità che batte i modelli da 9B è reale, e lo è anche il costo dell'architettura a loop che la produce.

Cosa ti offre realmente il supporto upstream

Mettendo insieme i due eventi upstream, il quadro pratico per un self-hoster è semplice. Se usi SGLang, Nanbeige4.2-3B è già servibile da un'installazione standard basata sul supporto della main-branch unita — nessun fork, con i parser di tool-calling e reasoning del modello collegati agli stessi rilevatori qwen3 che SGLang già include. Se usi vLLM, il supporto standard è a una sola fusione di distanza: la riga di registro instrada il modello verso il backend transformers, il convertitore arch dimensiona correttamente la cache, e i parser qwen3 per reasoning e tool-call vengono riutilizzati, ed è così che funziona la superficie di chiamata degli strumenti compatibile con OpenAI.

Il monito onesto è che la via di vLLM è un percorso di compatibilità, non uno ottimizzato. Eseguire NanbeigeForCausalLM tramite TransformersForCausalLM significa che vLLM esegue il codice Hugging Face del modello stesso all'interno del suo livello di servizio, piuttosto che un'implementazione nativa con kernel personalizzati e gestione dei grafi CUDA — la differenza è esattamente ciò che SGLang ha scelto di costruire nativamente. Per un modello da 3B il cui costo per token è già raddoppiato dal loop, il percorso basato su transformers difficilmente sarà il percorso di servizio più veloce possibile, e la storia di cinque bug nel codice personalizzato sottostante fa sì che il percorso erediti qualsiasi stranezza rimanga. Per carichi di lavoro agentici, dove la correttezza delle chiamate agli strumenti e il comportamento a contesto lungo di solito contano più dei token grezzi al secondo, questo può essere un compromesso accettabile; per la chat sensibile alla latenza vale la pena fare benchmark prima di scommetterci un percorso di produzione. E due motori sono ancora solo fork: llama.cpp e Ollama continuano a puntare ai rami Nanbeige, con il server llama.cpp incluso in LM Studio che non supporta ancora l'architettura.

Cosa guardare dopo

Tre cose cambierebbero il quadro. In primo luogo, la PR di vLLM deve ricevere il merge e uscire in una release — segui il thread e le note di rilascio di vLLM; i revisori hanno già segnalato che mancano una voce nella documentazione e una mappatura dei checkpoint CI prima che sia pronta per il merge. In secondo luogo, osserva se il convertitore del numero di layer sopravvive alla revisione, dato che i maintainer ritengono che la PR #54941 possa averlo reso ridondante — un segno di quanto questo workaround sia un'impalcatura attorno all'architettura a loop. In terzo luogo, segui la questione dei provider hosted: la scheda Hugging Face attualmente non mostra alcun provider di inferenza che serve il modello, e nemmeno noi lo ospitiamo, quindi oggi è una storia di self-hosting. Quando un provider lo inserirà nel catalogo, il lato routing diventerà routine: un'unica API su un ampio catalogo di modelli, con i prezzi di listino del provider trasferiti senza markup, è il modo a basso attrito per mettere a confronto in un test A/B un Nanbeige4.2-3B self-hosted con i modelli hosted che dichiara di superare. Fino ad allora, il traguardo da annotare è quello appena raggiunto: sei settimane dopo un lancio che ogni runtime importante ha accolto con un'alzata di spalle e un fork, due di essi ora servono Nanbeige4.2-3B da un'installazione non modificata.