Hy-SimulMT vs NLLB-200: un interprete in streaming non è un traduttore per 200 lingue

I due nomi dei benchmark differiscono di una lettera, e quella lettera è l'intero articolo. Hy-SimulMT, l'interprete in tempo reale cinese↔inglese di Tencent Hunyuan rilasciato il 26 ottobre 2026, pubblica un punteggio di 90,3 su qualcosa chiamato FLEURS. NLLB-200, il traduttore testuale in 200 lingue di Meta AI di luglio 2022, viene valutato su qualcosa chiamato FLORES-200. Sono correlati — FLEURS è costruito da frasi FLORES lette ad alta voce — ma non sono lo stesso test, non vengono valutati allo stesso modo e nessuno ha mai messo a confronto questi due modelli. Cercando questo confronto si ottengono i materiali di lancio di un modello e la documentazione dell'altro, senza nulla nel mezzo. Quell'assenza è il punto di partenza onesto: non sono concorrenti, e la domanda utile è a quale compito serva effettivamente ciascuno.

Una lettera, due parametri di riferimento

FLORES-200 è un benchmark testuale. Meta lo ha realizzato nell'ambito del progetto No Language Left Behind: frasi tradotte professionalmente in 200 lingue, utilizzate per misurare quanto bene un sistema di traduzione trasferisce testo scritto da una lingua all'altra. La metrica principale è spBLEU, una variante di BLEU calcolata su un tokenizzatore fisso e bilanciato per lingua, in modo che i punteggi siano confrontabili tra lingue che utilizzano sistemi di scrittura diversi. Il paper NLLB riporta anche chrF++ e una valutazione umana denominata XSTS.

FLEURS è la controparte parlata. Prende i set di frasi FLORES, fa leggere ad alta voce a parlanti nativi e valuta la traduzione vocale — audio in ingresso, testo in uscita. Copre 102 lingue anziché 200. Quando Tencent riporta 90,3 su FLEURS per Hy-SimulMT, quel numero include l'intera pipeline: ascoltare l'audio, riconoscere le parole e tradurle. Quando Meta riporta spBLEU su FLORES-200 per NLLB-200, il testo è già corretto e tokenizzato, e l'unica cosa misurata è il passo di traduzione.

Metti quei due numeri uno accanto all'altro e non hai confrontato due modelli. Hai confrontato un sistema vocale end-to-end con un traduttore di testo su dati diversi, con metriche diverse, in lingue diverse. È l'errore che la somiglianza di una singola lettera invita a commettere, e vale la pena nominarlo prima di qualsiasi altro confronto in questo pezzo.

Che cos'è davvero NLLB-200, a quattro anni di distanza

NLLB-200 è stato rilasciato a luglio 2022 e non è stato più revisionato da allora. I checkpoint che scarichi oggi sono quelli del 2022. Non è una critica — è un'affermazione su che tipo di artefatto sia: un rilascio di ricerca che ha definito un benchmark e un set di dati, e poi si è fermato.

La famiglia copre cinque taglie, e la varietà è il punto:

• NLLB-200-distilled-600M — il checkpoint utilizzabile più piccolo, sufficientemente piccolo per una GPU di classe laptop.

• NLLB-200-distilled-1.3B e NLLB-200-1.3B — la coppia di fascia media, uno distillato per la velocità e uno addestrato direttamente.

• NLLB-200-3.3B — il cavallo di battaglia denso, la dimensione che la maggior parte delle persone distribuisce davvero.

• NLLB-200-54.5B — il modello sparso di punta: 128 esperti con gating top-2, uno strato mixture-of-experts in ogni quarto blocco transformer e un calcolo per token all'incirca paragonabile a quello del modello denso da 3,3B. È il più grande modello di traduzione aperto della sua generazione ed è ancora il motivo per cui questa famiglia viene citata.

Il set di addestramento era composto da circa 18 miliardi di coppie di frasi parallele, e l'affermazione principale del paper era un miglioramento del 44% in BLEU rispetto al precedente stato dell'arte, misurato su più di 40.000 direzioni di traduzione. L'architettura è un transformer encoder-decoder progettato per la traduzione di singole frasi. Non esiste una modalità di streaming, né input audio, né alcuna nozione di output parziale — prende una frase e restituisce una frase.

La licenza è CC-BY-NC 4.0, e la model card è schietta riguardo all'intento: non rilasciata per la messa in produzione, non destinata alla traduzione specifica per dominio, di documenti lunghi, con input lunghi o certificata. Il codice attorno ai pesi è MIT, ma i pesi non lo sono, ed è questa la confusione che ha accompagnato questo rilascio per quattro anni.

Che cos'è realmente Hy-SimulMT, a partire da questa settimana

Hy-SimulMT è un artefatto dalla forma opposta in quasi ogni dimensione. È un modello vocale: l'audio arriva in streaming a 16 kHz in finestre da 30 secondi e il modello emette testo tradotto mentre l'oratore sta ancora parlando. L'architettura è una miscela sparsa di esperti da 30,4 miliardi di parametri, con circa 3 miliardi di parametri attivi per token, avvolta attorno a un encoder audio a 24 livelli. La coppia linguistica documentata è cinese e inglese, in entrambe le direzioni.

La sua affermazione centrale è la latenza, non la copertura. Tencent riporta uno StreamLAAL di circa tre secondi su audio RealSI di lunga durata, descrivendolo come il più basso tra i sistemi confrontati. Si tratta di un tipo di affermazione diverso da qualsiasi cosa contenuta nel paper NLLB, che non presenta alcuna misurazione della latenza perché non c'è nulla da misurare: un traduttore di testo in batch non ha alcun ritardo rispetto a chi parla.

Il rilascio è Apache-2.0 e senza restrizioni, con sei checkpoint che coprono due forme di output — solo traduzione e testo sorgente più traduzione — ciascuna in precisione completa, FP8 e GGUF. La build a precisione completa è di circa 61 GB, mentre la build GGUF Q4_K_M è di 19,7 GB. L'output vocale e la clonazione vocale richiedono un servizio TTS separato; il modello stesso produce testo.

Come NLLB-200, non dispone di un'API ospitata né di un prezzo pubblicato. Il prodotto consumer di Tencent è l'app Hy Translate, che offre un piano gratuito. Tutto il resto implica eseguire i pesi.

Perché i punteggi non possono condividere una colonna

La tentazione è allineare i quattro punteggi di Hy-SimulMT al numero di NLLB-200 più a portata di mano. Resistila, e non solo per la distinzione FLEURS/FLORES. Ai due modelli vengono poste domande diverse.

• Modalità di input — Hy-SimulMT riceve audio, quindi il suo punteggio include l'errore di riconoscimento. NLLB-200 riceve testo con l'errore di riconoscimento già rimosso. Un modello vocale e un modello testuale sulle stesse frasi non partono dalla stessa linea.

• Metrica — Hy-SimulMT riporta punteggi della famiglia BLEU sui set di traduzione vocale; NLLB-200 riporta spBLEU, chrF++ e XSTS su FLORES-200. Il tokenizzatore di spBLEU esiste appositamente per rendere equo il confronto tra lingue, il che significa che non è intercambiabile con un semplice numero BLEU anche quando entrambi sono chiamati BLEU.

• Unità di lavoro — NLLB-200 viene valutato frase per frase su testo allineato. Hy-SimulMT viene valutato su audio in streaming, dove il fallimento interessante non è una parola tradotta male, ma una frase che arriva troppo tardi per essere utile.

• Numero di direzioni — Le oltre 40.000 direzioni di NLLB-200 sono mediate nel suo risultato principale; i quattro benchmark di Hy-SimulMT coprono solo cinese↔inglese. Una media sulla coda lunga e un punteggio su un'unica coppia ad alte risorse descrivono tipi diversi di risultato.

Anche nella sua stessa tabella, Hy-SimulMT non è uniformemente in vantaggio. Ottiene 75,5 su CoVoST2 contro 82,1 di Qwen3.8-LiveTranslate, e resta indietro rispetto a Gemini3.5-LiveTranslate su FLEURS (90,3 contro 92,4) e ACL6060 (81,2 contro 82,6). La sua vittoria più netta è RealSI-Sentence con 84,7. Tutti questi numeri sono stati prodotti dal fornitore, ottenuti con l'harness scelto da Tencent e non riprodotti in modo indipendente. Inoltre, la scheda del modello non indica quale delle sue due varianti di output li abbia generati.

La latenza si misura in un’unità che NLLB non ha

Questa è la parte che decide i deployment, e non ha nulla a che vedere con i punteggi dei benchmark.

Un interprete simultaneo deve fare un compromesso che un traduttore batch non deve mai affrontare: aspettare di più e tradurre meglio, oppure parlare prima rischiando di sbagliare. StreamLAAL misura questo compromesso — all'incirca, quanto l'output resta indietro rispetto all'input in media. I tre secondi di Hy-SimulMT sono un'affermazione su questo compromesso. Non coincidono esplicitamente con il tempo al primo output vocale, e Tencent lo dice sulla scheda del modello. Una volta aggiunto un servizio TTS esterno, l'esperienza dell'ascoltatore include anche la latenza di quel servizio, cosa che il dato dei tre secondi non fa.

NLLB-200 non ha un numero equivalente perché non ha un percorso di streaming. Puoi aggiungerne uno: suddividi l'audio in blocchi, esegui il riconoscimento vocale, passa frammenti di frase a NLLB ed emetti le traduzioni man mano che vengono completate. Quell'architettura funziona, e i team l'hanno già costruita. Ma la suddivisione in blocchi distrugge il contesto su cui si basa un traduttore a livello di frase, e la qualità risultante non è quella misurata su FLORES-200 con frasi complete e ben formate. Il divario tra «NLLB-200 ottiene X su FLORES» e «NLLB-200 dentro una pipeline live a blocchi suona come Y» è dove va in realtà la maggior parte dello sforzo ingegneristico.

Questa è la vera asimmetria. Hy-SimulMT è stato progettato per il caso dello streaming e lo paga con la copertura linguistica e un footprint di classe 30B. NLLB-200 è stato progettato per l'ampiezza e lo paga con un'interfaccia esclusivamente batch. Nessuno dei due è in ritardo. Sono ottimizzati per vincoli diversi.

Copertura rispetto alla profondità

Il vantaggio duraturo di NLLB-200 è la coda lunga. Duecento lingue, comprese quelle a basse risorse che la maggior parte dei modelli del 2026 non gestisce affatto, in una famiglia che scala da un checkpoint da 600M a una mixture of experts da 54.5B. Se il tuo problema è un documento in una lingua con qualche milione di parlanti e nessuna API commerciale la copre, NLLB-200 resta una delle poche opzioni aperte, e il checkpoint dense da 3.3B gira su una singola GPU modesta.

Hy-SimulMT non è affatto in grado di svolgere quel compito. Documenta cinese e inglese. I suoi metadati Hugging Face riportano un tag per 36 lingue, ma non è pubblicato alcun elenco delle altre 34, e ogni esempio nel repository usa en-zh o zh-en. Pianificare un lancio multilingue sulla base di quel tag sarebbe un errore.

Il calcolo hardware va nella direzione opposta. Il modello denso da 3,3B di NLLB-200 occupa qualche gigabyte in FP16 e sta comodamente su una scheda da 16–24 GB. Il suo modello di punta da 54,5B è di circa 108 GB in FP16 — una questione da multi-GPU. Hy-SimulMT è di circa 61 GB in BF16 e richiede un acceleratore da 80 GB per essere servito nella configurazione fornita, oppure 19,7 GB a Q4_K_M tramite un percorso GGUF il cui supporto da parte di llama.cpp non è ancora upstream. Quindi NLLB-200 è più economico sul fronte dei modelli piccoli e comparabile ai livelli alti; il costo di Hy-SimulMT è concentrato nel mezzo, e in cambio offre lo streaming.

Le licenze puntano in direzioni opposte.

Questa non è la colonna portante del confronto — lo è la modalità — ma è il modo più rapido per scartare uno dei due per un prodotto commerciale.

I pesi di NLLB-200 sono CC-BY-NC 4.0. Non commerciale. Il codice circostante è MIT, ed è da lì che nasce la confusione, ma sono i pesi quelli che serviresti, e la scheda di Meta dice chiaramente che i modelli non sono rilasciati per l'implementazione in produzione. Un'implementazione commerciale richiede un modello diverso o un accordo di licenza.

Hy-SimulMT è Apache-2.0, senza restrizioni di accesso, con uso commerciale, modifica e ridistribuzione consentiti. Tencent distribuisce un toolkit di addestramento insieme al server di inferenza, quindi l'addestramento continuativo è un uso previsto. Se la scelta tra i due si basa solo sulla licenza, non c'è partita.

Dove trovano posto nello stesso stack

Il motivo per cui questo confronto continua a essere cercato è che i team si imbattono in entrambi i problemi nello stesso prodotto. Un'azienda con operatività in cinese e inglese ha bisogno di un interprete in tempo reale per le riunioni e di una pipeline di testo per il traffico documentale in 200 lingue che arriva via email, contratti e ticket di assistenza. Sono due compiti diversi, e un'architettura onesta utilizza due modelli diversi.

NLLB-200, o un suo successore moderno, gestisce il percorso del testo offline: traduzione batch, identificazione della lingua, triage del corpus, la coda lunga. Hy-SimulMT gestisce il percorso vocale live cinese↔inglese, dove la latenza domina e la copertura non conta perché nella stanza ci sono solo due lingue. Il confine tra i due è una decisione di routing, e vale la pena dichiararla esplicitamente anziché lasciare che un'applicazione la inferisca dal tipo di file.

Nessuno dei due modelli è nel catalogo di OrcaRouter, quindi non siamo una via d'accesso a nessuno dei due. Ciò che un router offre è il punto di raccordo attorno ad essi: un'unica API davanti a oltre 200 modelli ospitati con 0% di ricarico, con il prezzo di listino del provider trasferito senza aggiunte, e un DSL di routing che stabilisce quale percorso segue una richiesta. Quest'ultima parte è prosaica e utile: le richieste di testo ricadono su un modello generale ospitato, le richieste vocali vanno al tuo interprete self-hosted e l'applicazione non deve sapere quale sia quale. Il failover automatico copre il caso in cui il ramo ospitato non sia disponibile e la richiesta debba comunque restituire qualcosa.

Poiché il segmento hosted è prezzato al listino del fornitore senza alcun ricarico, un taglio di prezzo del fornitore sul lato testo diventa effettivo anche da noi lo stesso giorno. È una cosa di poco conto finché non si instrada traffico documentale ad alto volume e l'alternativa è rinegoziare un contratto ogni volta che un fornitore cambia il proprio listino prezzi.

Cosa chiedere prima dell'uno o dell'altro

La domanda non è quale modello sia migliore. Sono due domande, e hanno risposte diverse.

Se l'input è audio che sta ancora arrivando e le lingue sono cinese e inglese, la risposta è Hy-SimulMT — e la questione del deployment diventa quale dei suoi sei checkpoint usare, una decisione che riguarda la forma e la precisione dell'output piuttosto che la qualità. Se l'input è testo in una lingua non ancora identificata, all'interno di un insieme che include lingue a basse risorse, NLLB-200 resta una base open legittima a quattro anni di distanza, a condizione che la licenza non commerciale sia adatta e che si accetti un'interfaccia batch.

Ciò che nessuno ha pubblicato è il ponte: il riconoscimento vocale che alimenta NLLB-200 su audio cinese↔inglese, valutato sullo stesso benchmark di streaming di Hy-SimulMT, con latenza e qualità riportate insieme. Quell'esperimento ti direbbe se un traduttore testuale del 2022 avvolto in un'infrastruttura di streaming del 2026 può competere con un interprete progettato appositamente. Sarebbe anche il primo confronto onesto tra questi due modelli, e non esiste ancora.

Un'ultima cosa che vale la pena dire chiaramente, perché la somiglianza di un solo carattere tra i nomi dei benchmark continuerà a generare confronti sbagliati: un modello che vince su FLEURS ha dimostrato qualcosa sulla traduzione vocale in uno specifico ambiente di valutazione. Un modello che ottiene buoni punteggi su FLORES-200 ha dimostrato qualcosa sulla traduzione testuale in 200 lingue. Nessuno dei due risultati è trasferibile all'altro compito, e il fornitore che pubblicherà entrambi sugli stessi audio, con la stessa metrica e lo stesso conteggio della latenza, sarà il primo a rendere questo confronto davvero significativo.