La tabella dei benchmark di Nanbeige4.3-33B invoglia a provarlo. È un modello testuale denso, disponibile, con 33 miliardi di parametri e indicato come Apache-2.0. Lo sviluppatore dichiara 80,9 contro 73,0 di Qwen3.8-27B su Terminal-Bench 2.1 e 65,5 contro 42,5 su DeepSWE. È un buon motivo per metterlo alla prova, non per sostituire stanotte il modello di un agente in produzione. [1]

Nella stessa tabella Qwen ha però un lieve vantaggio su SWE-Bench Pro: 61,7 contro 60,3. Cambiano i compiti, cambia il risultato. Sono numeri dello sviluppatore, non misure mie né una replica indipendente. La scheda afferma che parametri di inferenza e harness sono uguali per i modelli confrontati all’interno di ciascun benchmark, mentre gli harness differiscono tra benchmark. Inoltre, il Qwen3.8-27B del confronto non coincide necessariamente con il modello già in uso altrove. [1]

Un agente non è soltanto un file di pesi

Per i flussi con strumenti su più turni la scheda consiglia preserve_thinking=true, per conservare il ragionamento precedente. Preferisce chiamate agli strumenti in XML, offrendo anche JSON per compatibilità. Pubblicizza fino a 512K di contesto. Nessuna di queste indicazioni dimostra che un server specifico interpreti correttamente le chiamate con una determinata quantizzazione, né che tale contesto sia praticabile entro un budget di memoria e latenza. Pesi, template conversazionale, parser e harness costituiscono insieme l’agente reale. [1]

Molti useranno un derivato GGUF invece dei pesi BF16 originali. AtomicChat ne offre diversi: la sua scheda indica 21,2 GB per AD-Q4_K_M e 35,2 GB per Q8_0. Sono dimensioni dei file, non memoria totale in esecuzione: bisogna aggiungere cache KV, lunghezza del contesto e richieste contemporanee. L’autore della conversione spiega inoltre che il vecchio Q4_K_M semplice è stato rimosso dopo che le alternative imatrix hanno ottenuto risultati migliori nei suoi test. Consigliare ancora esattamente quel file da questo repository significa non aver controllato l’offerta attuale. [2]

La fedeltà del prossimo token non misura il successo del compito

Chi pubblica le quantizzazioni confronta le previsioni del prossimo token di ciascun derivato con BF16 su un proprio banco multilingue. Riporta un accordo sul token più probabile (top-1) dell'89,9% per il vecchio Q4_K_M, del 92,6% per AD-Q4_K_M e del 98,0% per Q8_0. La scheda descrive il test e rimanda ai log grezzi. Sono diagnostiche utili pubblicate dall’autore del derivato, non percentuali di compiti portati a termine. Il 92,6% non significa né che riesca il 92,6% dei lavori, né che il punteggio di coding del modello originale sopravviva intatto alla conversione. [2]

Una differenza di un token può cambiare il nome di uno strumento, un argomento o un delimitatore; può anche non cambiare affatto il risultato. La tabella dei benchmark del modello originale e quella della fedeltà dei derivati misurano cose diverse. Fonderle in una classifica degli agenti sarebbe un errore di categoria. [1][2]

Il test che farei davvero

Partirei da compiti fissi e innocui: modifiche a repository con test, ricerche in più passaggi con controllo delle fonti e chiamate a strumenti con argomenti difficili da codificare. Compiti, strumenti, valutatore e budget di tentativi devono restare uguali tra configurazioni. Registrerei file esatti, hash, impostazioni del template, versioni di server e parser, contesto assegnato e temperatura. Va valutato lo stato finale osservato, non il riassunto sicuro di sé del modello.

Riporterei separatamente successo al primo tentativo e dopo ripetizioni, insieme a latenza, picco di memoria e chiamate agli strumenti non valide. Verificherei inoltre che gli strumenti siano stati effettivamente chiamati e che i risultati siano tornati al modello. Una promessa di contesto lungo va testata alla lunghezza dichiarata, non dopo averla ridotta in silenzio fino a far partire il server. Sono esperimenti proposti: non ho misurato Nanbeige e non pubblico cifre locali su velocità o riuscita.

L’aiuto legittimo alla sicurezza e la franchezza sui fatti vanno valutati separatamente dal rifiuto delle richieste dannose. Rifiutare meno non significa essere più competenti nelle attività di sicurezza autorizzate. Né i benchmark di coding né l’accordo tra token misurano questo comportamento. [1][2]

Il mio verdetto è candidato, non sostituto. La disponibilità dei pesi e l’indicazione della licenza consentono l’esperimento; i risultati dello sviluppatore lo rendono interessante. Le misure del derivato aiutano a scegliere i file per il test, non il vincitore da distribuire. Chi sostiene che una variante quantizzata superi un agente esistente dovrebbe mostrare file, template, parser, tracce grezze e termine di paragone. Altrimenti abbiamo un’ipotesi interessante, non un benchmark dell’agente che useremo davvero.

Fonti

[1] https://huggingface.co/Nanbeige/Nanbeige4.3-33B [2] https://huggingface.co/AtomicChat/Nanbeige4.3-33B-GGUF