Hy-SimulMT vs NLLB-200: En strömmande tolk är inte en översättare för 200 språk

De två benchmarknamnen skiljer sig åt med en bokstav, och den bokstaven är hela artikeln. Hy-SimulMT, Tencent Hunyuans realtidstolk för kinesiska↔engelska som släpptes den 26 oktober 2026, redovisar en poäng på 90,3 på något som kallas FLEURS. NLLB-200, Meta AIs textöversättare för 200 språk från juli 2022, utvärderas på något som kallas FLORES-200. De är besläktade – FLEURS bygger på FLORES-meningar som lästs in högt – men de är inte samma test, de poängsätts inte på samma sätt, och ingen har någonsin kört dessa två modeller mot varandra. Att söka efter den här matchningen ger lanseringsrapportering om den ena modellen och dokumentation om den andra, med ingenting däremellan. Den frånvaron är den ärliga utgångspunkten: dessa är inte konkurrenter, och den användbara frågan är vilken uppgift var och en faktiskt är avsedd för.

En bokstav, två riktmärken

FLORES-200 är ett textbenchmark. Meta byggde det som en del av projektet No Language Left Behind: professionellt översatta meningar på 200 språk, som används för att mäta hur väl ett översättningssystem flyttar skriven text från ett språk till ett annat. Huvudmåttet är spBLEU, en BLEU-variant som beräknas över en fast, språkbalanserad tokeniserare så att poängen blir jämförbara mellan språk som använder olika skriftsystem. NLLB-artikeln rapporterar också chrF++ och en mänsklig utvärdering som kallas XSTS.

FLEURS är det talade syskonet. Det tar FLORES-meningsuppsättningar, låter modersmålstalare läsa dem högt och utvärderar talöversättning – ljud in, text ut. Den omfattar 102 språk i stället för 200. När Tencent rapporterar 90,3 på FLEURS för Hy-SimulMT omfattar den siffran hela kedjan: att höra ljudet, känna igen orden och översätta dem. När Meta rapporterar spBLEU på FLORES-200 för NLLB-200 är texten redan korrekt och tokeniserad, och det enda som mäts är översättningssteget.

Sätter du de två siffrorna bredvid varandra har du inte jämfört två modeller. Du har jämfört ett end-to-end-talsystem mot en textöversättare på olika data, med olika mått, på olika språk. Det är misstaget som likheten i en enda bokstav lockar till, och det är värt att benämna innan någon annan jämförelse i den här artikeln.

Vad NLLB-200 egentligen är, fyra år senare

NLLB-200 släpptes i juli 2022 och har inte reviderats sedan dess. De checkpoints du laddar ner i dag är checkpoints från 2022. Det är ingen kritik – det är ett konstaterande av vilken typ av artefakt detta är: en forskningsutgåva som definierade ett benchmark och en datamängd och sedan upphörde.

Familjen spänner över fem storlekar, och spridningen är poängen:

• NLLB-200-distilled-600M — den minsta användbara checkpointen, tillräckligt liten för en GPU i laptopklass.

• NLLB-200-distilled-1.3B och NLLB-200-1.3B – mellanklassparet, en destillerad för hastighet och en direktutbildad.

• NLLB-200-3.3B — den täta arbetshästen, den storlek som de flesta faktiskt driftsätter.

• NLLB-200-54.5B — den främsta glesa modellen: 128 experter med top-2-gating, ett mixture-of-experts-lager i var fjärde transformer-block, och beräkning per token ungefär jämförbar med den 3,3B stora täta modellen. Det är den största öppna översättningsmodellen i sin generation och fortfarande anledningen till att familjen citeras.

Träningsdataset bestod av ungefär 18 miljarder parallella meningspar, och artikelns huvudpåstående var en BLEU-förbättring på 44 % jämfört med tidigare state of the art, mätt över fler än 40 000 översättningsriktningar. Arkitekturen är en encoder-decoder-transformer byggd för översättning av enskilda meningar. Det finns inget strömmande läge, ingen ljudinmatning och ingen föreställning om partiella utdata – den tar en mening och returnerar en mening.

Licensen är CC-BY-NC 4.0, och modellkortet är rättframt om avsikten: inte utgiven för produktionsdriftsättning, inte avsedd för domänspecifik översättning, översättning av dokumentlängd eller långa indata, eller certifierad översättning. Koden kring vikterna är MIT, men vikterna är det inte, vilket är den förvirring som har följt den här utgivningen i fyra år.

Vad Hy-SimulMT faktiskt är, från och med den här veckan

{{1}}Hy-SimulMT{{/1}} är i nästan varje avseende artefaktens motsatta form. Det är en talmodell: ljud strömmas in vid 16 kHz i 30-sekundersfönster, och modellen avger översatt text medan talaren fortfarande talar. Arkitekturen är en gles expertblandning med 30,4 miljarder parametrar, med ungefär 3 miljarder parametrar aktiva per token, inramad kring en 24-lagers ljudkodare. Det dokumenterade språkparet är kinesiska och engelska, i båda riktningarna.

Dess centrala påstående är latens, inte täckning. Tencent rapporterar en StreamLAAL på omkring tre sekunder på långformat RealSI-ljud och beskriver det som den lägsta bland de system den jämförde. Det är en annan typ av påstående än något i NLLB-artikeln, som inte har någon latensmätning alls eftersom det inte finns något att mäta: en batchtextöversättare har ingen fördröjning gentemot en talare.

Utgåvan är Apache-2.0 och utan åtkomstbegränsning, med sex checkpoints som täcker två utdataformat – endast översättning och källtext plus översättning – vart och ett i full precision, FP8 och GGUF. Fullprecisionsbygget är cirka 61 GB, och GGUF Q4_K_M-bygget är 19,7 GB. Talutmatning och röstkloning kräver en separat TTS-tjänst; modellen själv genererar text.

Och precis som NLLB-200 har den inget hostat API och inget publicerat pris. Tencents konsumentprodukt är appen Hy Translate, som har en gratisnivå. Allt annat innebär att köra vikterna.

Varför poängen inte kan dela en kolumn

Frestelsen är att ställa Hy-SimulMT:s fyra poäng mot vilken NLLB-200-siffra som helst som ligger närmast till hands. Motstå den, och inte bara på grund av skillnaden mellan FLEURS och FLORES. De två modellerna får olika frågor.

• Indatamodalitet — Hy-SimulMT tar emot ljud, så dess poäng inkluderar igenkänningsfel. NLLB-200 tar emot text där igenkänningsfelet redan är borttaget. En talmodell och en textmodell på samma meningar står inte på samma startlinje.

• Mått — Hy-SimulMT rapporterar poäng i BLEU-familjen på set för talöversättning; NLLB-200 rapporterar spBLEU, chrF++ och XSTS på FLORES-200. spBLEUs tokeniserare finns specifikt för att göra jämförelser mellan språk rättvisa, vilket innebär att den inte är utbytbar mot ett vanligt BLEU-tal även när båda kallas BLEU.

• Arbetsenhet — NLLB-200 utvärderas mening för mening på alignerad text. Hy-SimulMT utvärderas på strömmande ljud, där det intressanta felet inte är ett felöversatt ord utan en mening som anländer för sent för att vara användbar.

• Antal riktningar — NLLB-200:s över 40 000 riktningar slås samman till ett medelvärde i dess huvudresultat; Hy-SimulMT:s fyra benchmarks omfattar endast kinesiska↔engelska. Ett medelvärde över den långa svansen och en poäng på ett enda resursstarkt par beskriver olika typer av prestationer.

I sin egen tabell är Hy-SimulMT inte heller genomgående bättre. Det får 75,5 på CoVoST2 mot 82,1 för Qwen3.8-LiveTranslate, och det ligger efter Gemini3.5-LiveTranslate på FLEURS (90,3 mot 92,4) och ACL6060 (81,2 mot 82,6). Dess tydligaste vinst är RealSI-Sentence med 84,7. Alla dessa siffror är körda av leverantören, gjorda på Tencents valda testramverk och inte oberoende reproducerade. Modellkortet anger inte heller vilken av dess två utdatavarianter som producerade dem.

Latens mäts i en enhet som NLLB inte har

Det här är delen som avgör driftsättningar, och den har ingenting med benchmarkresultat att göra.

En simultantolk måste göra en avvägning som en batchöversättare aldrig ställs inför: vänta längre och översätt bättre, eller tala tidigare och riskera att ha fel. StreamLAAL mäter den avvägningen – ungefär hur långt efter utdata ligger indata i genomsnitt. Hy-SimulMT:s tre sekunder är ett påstående om den avvägningen. Det är uttryckligen inte samma sak som tid till första talutdata, och det säger Tencent på modellkortet. När man lägger till en extern TTS-tjänst omfattar lyssnarens upplevelse även den tjänstens latens, vilket tresekundssiffran inte gör.

NLLB-200 har ingen motsvarande siffra eftersom den inte har någon strömningsväg. Du kan haka på en sådan: dela upp ljudet i bitar, kör taligenkänning, mata in meningsfragment till NLLB och skicka ut översättningar allteftersom de blir klara. Den arkitekturen fungerar, och team har byggt den. Men uppdelningen förstör det sammanhang som en meningsnivåöversättare förlitar sig på, och den resulterande kvaliteten är inte den kvalitet som mäts på FLORES-200 med fullständiga, välformade meningar. Gapet mellan "NLLB-200 får X på FLORES" och "NLLB-200 i en uppdelad live-pipeline låter som Y" är där större delen av ingenjörsarbetet faktiskt går.

Det här är den verkliga asymmetrin. Hy-SimulMT designades för streamingfallet och betalar för det med språktäckning och ett fotavtryck i 30B-klassen. NLLB-200 designades för bredd och betalar för det med ett gränssnitt som endast stöder batch. Ingen av dem ligger efter. De är optimerade för olika begränsningar.

Täckning mot djup

NLLB-200:s bestående fördel är den långa svansen. Tvåhundra språk, inklusive lågresursspråk som de flesta modeller från 2026 inte hanterar alls, i en familj som skalar från en 600M-checkpoint till en 54,5B mixture of experts. Om ditt problem är ett dokument på ett språk med några miljoner talare och inget kommersiellt API täcker det, är NLLB-200 fortfarande ett av få öppna alternativ, och den täta 3,3B-checkpointen körs på ett enda måttligt grafikkort.

Hy-SimulMT kan inte göra det jobbet alls. Det dokumenterar kinesiska och engelska. Dess Hugging Face-metadata har en 36-språkstagg, men ingen lista över de andra 34 publiceras, och varje exempel i repot använder en-zh eller zh-en. Att planera en flerspråkig utrullning på grundval av den taggen skulle vara ett misstag.

Hårdvarumatematiken går åt andra hållet. NLLB-200:s 3,3B täta modell är några gigabyte i FP16 och får plats bekvämt på ett 16–24 GB-kort. Dess 54,5B-flaggskepp är cirka 108 GB i FP16 – ett multi-GPU-upplägg. Hy-SimulMT är ungefär 61 GB i BF16 och kräver en 80 GB accelerator för att kunna köras som levererad, eller 19,7 GB vid Q4_K_M via en GGUF-väg vars llama.cpp-stöd ännu inte finns uppströms. Så NLLB-200 är billigare i den lilla änden och jämförbar i toppen; Hy-SimulMT:s kostnad är koncentrerad till mitten, och den ger streaming.

Licenserna pekar i motsatta riktningar

Detta är inte ryggraden i jämförelsen — modaliteten är det — men det är det snabbaste sättet att diskvalificera en av dem för en kommersiell produkt.

NLLB-200:s vikter är CC-BY-NC 4.0. Icke-kommersiellt. Koden runt omkring är MIT, vilket är där förvirringen kommer ifrån, men det är vikterna du skulle tillhandahålla, och Metas kort säger tydligt att modellerna inte släpps för produktionsdriftsättning. En kommersiell driftsättning kräver antingen en annan modell eller ett licensupplägg.

Hy-SimulMT är Apache-2.0, utan åtkomstbegränsningar, och kommersiell användning, modifiering och vidaredistribution är tillåten. Tencent levererar ett träningsverktygspaket tillsammans med inferensservern, så fortsatt träning är en avsedd användning. Om valet står mellan de två enbart utifrån licensiering är det inte nära.

Där de hör hemma i samma stack

Anledningen till att den här jämförelsen fortsätter att sökas är att team stöter på båda problemen i samma produkt. Ett företag med kinesisk och engelsk verksamhet behöver en live-tolk för möten och en textpipeline för dokumenttrafiken på 200 språk som kommer via e-post, avtal och supportärenden. Det är två olika uppgifter, och en ärlig arkitektur använder två olika modeller.

NLLB-200, eller en modern efterföljare, hanterar den offline-textvägen: batchöversättning, språkidentifiering, korpusgallring, den långa svansen. Hy-SimulMT hanterar den live talvägen kinesiska↔engelska, där latens dominerar och täckning inte spelar någon roll eftersom det bara finns två språk i rummet. Gränsen mellan dem är ett routingbeslut, och det är värt att uttrycka det explicit i stället för att låta en applikation sluta sig till det från filtyp.

Ingen av modellerna finns i OrcaRouters katalog, så vi är inte en väg till någon av dem. Det en router faktiskt erbjuder är skarven runt dem: ett API framför över 200 hostade modeller med 0 % påslag, leverantörens listpris förs vidare utan något påslag, och ett routing-DSL som avgör vilken väg en förfrågan tar. Den sista delen är vardaglig och användbar – textförfrågningar går vidare till en hostad generell modell, talförfrågningar går till din självhostade tolk, och applikationen behöver inte veta vilken som är vilken. Automatisk failover täcker fallet där den hostade delen är otillgänglig och förfrågan fortfarande måste returnera något.

Eftersom den hostade delen prissätts enligt leverantörens listpris utan påslag, slår en leverantörs prissänkning på textsidan igenom hos oss samma dag. Det är en liten sak tills man routar dokumenttrafik i volym och alternativet är att omförhandla ett avtal varje gång en leverantör ändrar sin prislista.

Vad man ska fråga innan något av dem

Frågan är inte vilken modell som är bättre. Det är två frågor, och de har olika svar.

Om indata är ljud som fortfarande anländer, och språken är kinesiska och engelska, är svaret Hy-SimulMT — och driftsättningsfrågan blir vilken av dess sex checkpoints som ska användas, vilket är ett beslut om utdatans form och precision snarare än om kvalitet. Om indata är text på ett språk som du ännu inte har identifierat, i en uppsättning som omfattar lågresursspråk, är NLLB-200 fortfarande en legitim öppen baslinje fyra år senare, förutsatt att den icke-kommersiella licensen passar och att du accepterar ett batchgränssnitt.

Det som ingen har publicerat är bryggan: taligenkänning som matar NLLB-200 med kinesiskt↔engelskt ljud, utvärderad på samma strömningsbenchmark som Hy-SimulMT, med latens och kvalitet rapporterade tillsammans. Det experimentet skulle visa om en textöversättare från 2022 inlindad i ett strömningsramverk från 2026 kan konkurrera med en specialbyggd tolkningsmodell. Det skulle också vara den första ärliga jämförelsen av dessa två modeller, och den finns inte ännu.

En sista sak som är värd att sägas rakt ut, eftersom likheten i benchmarknamnen med en bokstavs skillnad kommer att fortsätta generera dåliga jämförelser: en modell som vinner på FLEURS har visat något om talöversättning under en specifik testrigg. En modell som får bra resultat på FLORES-200 har visat något om textöversättning över 200 språk. Inget av resultaten överförs till den andras uppgift, och den leverantör som publicerar båda på samma ljud, med samma mätvärde och samma latensredovisning, blir den första att göra den här jämförelsen meningsfull.