Hy-SimulMT vs NLLB-200: A Streaming Interpreter Is Not a 200-Language Translator

The two benchmark names differ by one letter, and that letter is the whole article. Hy-SimulMT, Tencent Hunyuan's real-time Chinese↔English interpreter released on 26 October 2026, publishes a score of 90.3 on something called FLEURS. NLLB-200, Meta AI's 200-language text translator from July 2022, is evaluated on something called FLORES-200. They are related — FLEURS is built from FLORES sentences read aloud — but they are not the same test, they are not scored the same way, and no one has ever run these two models against each other. Searching for this matchup returns launch coverage of one model and documentation of the other, with nothing in between. That absence is the honest starting point: these are not competitors, and the useful question is which job each one is actually for.

One letter, two benchmarks

FLORES-200 is a text benchmark. Meta built it as part of the No Language Left Behind project: professionally translated sentences across 200 languages, used to measure how well a translation system moves written text from one language to another. The headline metric is spBLEU, a BLEU variant computed over a fixed, language-balanced tokeniser so that scores are comparable across languages that use different scripts. The NLLB paper also reports chrF++ and a human evaluation called XSTS.

FLEURS is the spoken sibling. It takes FLORES sentence sets, has native speakers read them aloud, and evaluates speech translation — audio in, text out. It covers 102 languages rather than 200. When Tencent reports 90.3 on FLEURS for Hy-SimulMT, that number includes the entire pipeline: hearing the audio, recognising the words, and translating them. When Meta reports spBLEU on FLORES-200 for NLLB-200, the text is already correct and tokenised, and the only thing being measured is the translation step.

Put those two numbers beside each other and you have not compared two models. You have compared an end-to-end speech system against a text translator on different data, with different metrics, in different languages. This is the mistake the one-letter similarity invites, and it is worth naming before any other comparison in this piece.

What NLLB-200 actually is, four years on

NLLB-200 shipped in July 2022 and has not been revised since. The checkpoints you download today are the 2022 checkpoints. That is not a criticism — it is a statement about what kind of artefact this is: a research release that defined a benchmark and a data set, and then stopped.

The family spans five sizes, and the spread is the point:

• NLLB-200-distilled-600M — the smallest usable checkpoint, small enough for a laptop-class GPU.

• NLLB-200-distilled-1.3B and NLLB-200-1.3B — the mid-range pair, one distilled for speed and one trained directly.

• NLLB-200-3.3B — the dense workhorse, the size most people actually deploy.

• NLLB-200-54.5B — the flagship sparse model: 128 experts with top-2 gating, a mixture-of-experts layer in every fourth transformer block, and per-token compute roughly comparable to the 3.3B dense model. It is the largest open translation model of its generation and still the reason the family is cited.

The training set was roughly 18 billion parallel sentence pairs, and the paper's headline claim was a 44% BLEU improvement over the previous state of the art, measured across more than 40,000 translation directions. The architecture is an encoder-decoder transformer built for single-sentence translation. There is no streaming mode, no audio input, and no notion of partial output — it takes a sentence and returns a sentence.

The licence is CC-BY-NC 4.0, and the model card is blunt about the intent: not released for production deployment, not intended for domain-specific, document-length, long-input, or certified translation. The code around the weights is MIT, but the weights are not, which is the confusion that has followed this release for four years.

What Hy-SimulMT actually is, as of this week

Hy-SimulMT is the opposite shape of artefact in almost every dimension. It is a speech model: audio streams in at 16 kHz in 30-second windows, and the model emits translated text while the speaker is still talking. The architecture is a 30.4-billion-parameter sparse mixture of experts with roughly 3 billion parameters active per token, wrapped around a 24-layer audio encoder. The documented language pair is Chinese and English, in both directions.

Its central claim is latency, not coverage. Tencent reports a StreamLAAL of about three seconds on long-form RealSI audio, describing it as the lowest among the systems it compared. That is a different kind of claim from anything in the NLLB paper, which has no latency measurement at all because there is nothing to measure: a batch text translator does not have a lag behind a speaker.

The release is Apache-2.0 and ungated, with six checkpoints covering two output shapes — translation-only and source-text-plus-translation — each in full precision, FP8 and GGUF. The full-precision build is around 61 GB, and the GGUF Q4_K_M build is 19.7 GB. Speech output and voice cloning require a separate TTS service; the model itself produces text.

And like NLLB-200, it has no hosted API and no published price. Tencent's consumer surface is the Hy Translate app, which has a free tier. Everything else means running the weights.

Why the scores cannot share a column

The temptation is to line up Hy-SimulMT's four scores against whatever NLLB-200 number is nearest to hand. Resist it, and not only because of the FLEURS/FLORES distinction. The two models are being asked different questions.

• Input modality — Hy-SimulMT receives audio, so its score includes recognition error. NLLB-200 receives text with recognition error already removed. A speech model and a text model on the same sentences are not on the same starting line.

• Metric — Hy-SimulMT reports BLEU-family scores on speech translation sets; NLLB-200 reports spBLEU, chrF++ and XSTS on FLORES-200. spBLEU's tokeniser exists specifically to make cross-language comparison fair, which means it is not interchangeable with a plain BLEU number even when both are called BLEU.

• Unit of work — NLLB-200 is evaluated sentence by sentence on aligned text. Hy-SimulMT is evaluated on streaming audio, where the interesting failure is not a mistranslated word but a sentence that arrives too late to be useful.

• Direction count — NLLB-200's 40,000-plus directions are averaged into its headline; Hy-SimulMT's four benchmarks cover Chinese↔English only. An average over the long tail and a score on one high-resource pair describe different kinds of achievement.

Within its own table, Hy-SimulMT is not uniformly ahead either. It scores 75.5 on CoVoST2 against Qwen3.8-LiveTranslate's 82.1, and it trails Gemini3.5-LiveTranslate on FLEURS (90.3 versus 92.4) and ACL6060 (81.2 versus 82.6). Its clearest win is RealSI-Sentence at 84.7. All of those numbers are vendor-run, made on Tencent's chosen harness, and not independently reproduced. The model card also does not say which of its two output variants produced them.

Latency is measured in a unit NLLB does not have

This is the part that decides deployments, and it has nothing to do with benchmark scores.

A simultaneous interpreter has to make a trade that a batch translator never faces: wait longer and translate better, or speak sooner and risk being wrong. StreamLAAL measures that trade — roughly, how far the output lags the input on average. Hy-SimulMT's three seconds is a claim about that trade. It is explicitly not the same as time to first speech output, and Tencent says so on the model card. Once you add an external TTS service, the listener's experience includes that service's latency too, which the three-second figure does not.

NLLB-200 has no equivalent number because it has no streaming path. You can bolt one on: chunk the audio, run speech recognition, feed sentence fragments to NLLB, and emit translations as they complete. That architecture works, and teams have built it. But chunking destroys the context a sentence-level translator relies on, and the resulting quality is not the quality measured on FLORES-200 with complete, well-formed sentences. The gap between "NLLB-200 scores X on FLORES" and "NLLB-200 inside a chunked live pipeline sounds like Y" is where most of the engineering effort actually goes.

This is the real asymmetry. Hy-SimulMT was designed for the streaming case and pays for it with language coverage and a 30B-class footprint. NLLB-200 was designed for breadth and pays for it with a batch-only interface. Neither is behind. They are optimised for different constraints.

Coverage against depth

NLLB-200's enduring advantage is the long tail. Two hundred languages, including low-resource ones that most 2026 models do not handle at all, in a family that scales from a 600M checkpoint to a 54.5B mixture of experts. If your problem is a document in a language with a few million speakers and no commercial API covers it, NLLB-200 is still one of the few open options, and the 3.3B dense checkpoint runs on a single modest GPU.

Hy-SimulMT cannot do that job at all. It documents Chinese and English. Its Hugging Face metadata carries a 36-language tag, but no list of the other 34 is published, and every example in the repository uses en-zh or zh-en. Planning a multilingual rollout on the strength of that tag would be a mistake.

The hardware arithmetic runs the other way. NLLB-200's 3.3B dense model is a few gigabytes in FP16 and fits comfortably on a 16–24 GB card. Its 54.5B flagship is about 108 GB in FP16 — a multi-GPU proposition. Hy-SimulMT is roughly 61 GB in BF16 and needs an 80 GB accelerator to serve as shipped, or 19.7 GB at Q4_K_M through a GGUF path whose llama.cpp support is not yet upstream. So NLLB-200 is cheaper at the small end and comparable at the top; Hy-SimulMT's cost is concentrated in the middle, and it buys streaming.

The licences point in opposite directions

This is not the spine of the comparison — the modality is — but it is the fastest way to disqualify one of them for a commercial product.

NLLB-200's weights are CC-BY-NC 4.0. Non-commercial. The surrounding code is MIT, which is where the confusion comes from, but the weights are what you would be serving, and Meta's card says plainly that the models are not released for production deployment. A commercial deployment needs either a different model or a licence arrangement.

Hy-SimulMT is Apache-2.0, ungated, with commercial use, modification and redistribution permitted. Tencent ships a training toolkit alongside the inference server, so continued training is an intended use. If the choice is between the two on licensing alone, it is not close.

Where they belong in the same stack

The reason this matchup keeps getting searched is that teams run into both problems in the same product. A company with Chinese and English operations needs a live interpreter for meetings and a text pipeline for the 200-language document traffic that arrives by email, contract and support ticket. Those are two different jobs, and the honest architecture uses two different models.

NLLB-200, or a modern successor, handles the offline text path: batch translation, language identification, corpus triage, the long tail. Hy-SimulMT handles the live Chinese↔English speech path, where latency dominates and coverage does not matter because there are only two languages in the room. The boundary between them is a routing decision, and it is worth stating explicitly rather than letting an application infer it from file type.

Neither model is in OrcaRouter's catalogue, so we are not a route to either one. What a router does provide is the seam around them: one API in front of 200-plus hosted models at 0% markup, provider list price passed through with nothing added, and a routing DSL that decides which path a request takes. That last part is mundane and useful — text requests fall through to a hosted general model, speech requests go to your self-hosted interpreter, and the application does not need to know which is which. Automatic failover covers the case where the hosted leg is unavailable and the request still has to return something.

Because the hosted leg is priced at provider list with nothing added, a vendor price cut on the text side is live on our side the same day. That is a small thing until you are routing document traffic at volume and the alternative is renegotiating a contract every time a provider changes its rate card.

What to ask before either

The question is not which model is better. It is two questions, and they have different answers.

If the input is audio that is still arriving, and the languages are Chinese and English, the answer is Hy-SimulMT — and the deployment question becomes which of its six checkpoints, which is a decision about output shape and precision rather than quality. If the input is text in a language you have not yet identified, across a set that includes low-resource languages, NLLB-200 remains a legitimate open baseline four years on, provided the non-commercial licence fits and you accept a batch interface.

What nobody has published is the bridge: speech recognition feeding NLLB-200 on Chinese↔English audio, evaluated on the same streaming benchmark as Hy-SimulMT, with latency and quality reported together. That experiment would tell you whether a 2022 text translator wrapped in a 2026 streaming harness can compete with a purpose-built interpreter. It would also be the first honest comparison of these two models, and it does not exist yet.

One last thing worth saying plainly, because the one-letter benchmark resemblance will keep generating bad comparisons: a model that wins on FLEURS has demonstrated something about speech translation under a specific harness. A model that scores well on FLORES-200 has demonstrated something about text translation across 200 languages. Neither result transfers to the other's job, and the vendor that publishes both on the same audio, with the same metric and the same latency accounting, will be the first to make this comparison mean anything.