Hy-SimulMT vs Hy-SimulMT-30B-A3B: One Name, Six Files, Two Outputs

Type Hy-SimulMT into Hugging Face and you will not find a repository by that name. You will find six, and every one of them is called Hy-SimulMT-30B-A3B with a suffix attached. That is the entire comparison in a sentence. Hy-SimulMT is the name Tencent Hunyuan put on the announcement on 26 October 2026 — the real-time Chinese↔English interpreter that press coverage described as running about three seconds behind the speaker. Hy-SimulMT-30B-A3B is the name on the artefact you can actually download. There is no smaller sibling under the short name, no dense variant, no plain "base" model hiding behind it. The short name is a project; the long name is a family of six files. What follows is the decision a versus page usually buries: which of those six to run, and why the answer differs for a subtitle overlay and for a meeting feed that only needs audio out.

What Tencent released, and what it decided to call it

Tencent's own repository treats Hy-SimulMT as the project name: "a real-time simultaneous translation model developed by Tencent Hunyuan." The model card files it under the same short label. The collection is titled "Hy Simultaneous Interpretation Model." Nowhere in that material is there a defined hierarchy of a family and its members — no Hy-SimulMT-Small, no Hy-SimulMT-Mini, no dense checkpoint for people without an 80-gigabyte accelerator. Every released weight is the same 30B-class mixture-of-experts architecture.

So the six entries in the collection are not six models in any meaningful sense. They are one model in six packagings:

• Hy-SimulMT-30B-A3B — translation-only output, full precision, safetensors.

• Hy-SimulMT-30B-A3B-Interleave — source transcript plus translation, full precision, safetensors.

• Hy-SimulMT-30B-A3B-FP8 and Hy-SimulMT-30B-A3B-Interleave-FP8 — the same two output shapes in an eight-bit floating-point build intended for single-GPU serving.

• Hy-SimulMT-30B-A3B-GGUF and Hy-SimulMT-30B-A3B-Interleave-GGUF — the same two output shapes quantised for llama.cpp, at Q4_K_M and Q8_0.

The architecture underneath is a 30.4-billion-parameter sparse model with roughly 3 billion parameters active per token: 48 layers, 128 experts with eight routed and one shared per token, and a 24-layer audio encoder that takes 16 kHz audio in 30-second windows. That encoder design is the part worth noticing. The model is built to consume audio while it is still arriving, not to receive a finished file — which is why the latency claim and the benchmark claim are measured on different things, and why neither of them tells you which of the six files produced the number.

The licence is Apache-2.0 and ungated, which is the strongest single fact in the release. No form, no acceptable-use gate, no non-commercial clause. Commercial use, modification and redistribution are permitted, and Tencent has published a training toolkit alongside the inference server so that continued training is an intended use rather than an unsupported one.

The choice that actually matters is output shape

Between the two full-precision checkpoints, the difference is not quality. It is what the model is allowed to say. The base checkpoint emits the translation and nothing else. The Interleave checkpoint emits the recognised source text and then the translation, interleaved as the audio streams.

That sounds cosmetic until you look at where these systems get deployed. A live meeting feed that drives text-to-speech wants the base checkpoint: the transcript is dead weight that costs output tokens, adds latency to every chunk, and leaks the source language into a pipeline whose only consumer is a voice. A subtitling overlay, a compliance capture, a bilingual transcript, or any workflow where a human has to check the translation against what was said wants the Interleave checkpoint, because the alternative is running a separate speech recogniser beside the translator and hoping the two segment the audio the same way. They will not.

Tencent's own one-command deployment example defaults to the Interleave variant:

• bash deploy.sh --install-server --model tencent/Hy-SimulMT-30B-A3B-Interleave

That is a sensible default for a demo, where showing the source text proves the system is listening. It is the wrong default for a voice-only product, and it is the one detail most coverage of this release skips. If you are evaluating the model on token cost or end-to-end latency, you are measuring a different system depending on which checkpoint you loaded.

There is a second-order cost to Interleave that the card implies but does not quantify. Streaming transcripts are mutable. Early output can be revised as more audio arrives, so a client that displays partial text has to be built to accept corrections rather than append-only lines. AlphaSignal's write-up of the release makes this point directly, and it is the kind of integration detail that turns a two-day prototype into a three-week one.

The benchmarks do not say which variant they measured

Tencent publishes four short-form scores and one long-form latency figure, and every row is labelled "Hy-SimulMT" — not Hy-SimulMT-30B-A3B, and certainly not base versus Interleave. That is the honest gap in the release, and it matters more than any single number in it.

• FLEURS — 90.3. Gemini3.5-LiveTranslate scores 92.4, so this is not a category win.

• CoVoST2 — 75.5, behind Qwen3.8-LiveTranslate at 82.1. This is the clearest loss in the table and the one the headline coverage tends to skip.

• ACL6060 — 81.2. Gemini3.5-LiveTranslate scores 82.6.

• RealSI-Sentence — 84.7, the highest in the comparison set.

• RealSI long-form latency — a StreamLAAL of about three seconds, described as the lowest among the systems compared.

All of these are vendor-run. None has been independently reproduced, and the card is explicit that StreamLAAL is not the same measurement as time to first speech output. The demonstration videos are offline replays, so their playback timing is not a live latency reading either. Read the table as a set of claims from the laboratory that built the model, made on a harness it chose, with the variant left unnamed.

That last omission is fixable in an afternoon by anyone with the hardware: run both checkpoints on the same audio and publish the delta. Until someone does, the reasonable assumption is that the published numbers describe the translation-only path, because that is the cleaner measurement — the Interleave variant has to emit more tokens, and more tokens in a streaming decoder is more latency. But it is an assumption, not a disclosure.

Format is the third decision, and the GGUF path has a catch

The full-precision checkpoint is roughly 61 GB in BF16. That puts the practical floor for a comfortable deployment at an 80 GB accelerator, which is the number to budget if you intend to serve the model as shipped. The FP8 build exists precisely to pull that requirement down to a single smaller card, and Tencent positions it that way.

The GGUF route looks cheaper still, and the file sizes are concrete. The Interleave GGUF repository lists Q4_K_M at 19.7 GB and Q8_0 at 33.3 GB. A 19.7 GB quantisation of a 30-billion-parameter model is the difference between "needs a data-centre card" and "fits on a workstation," and it is the version most people will try first.

The catch is that llama.cpp support for this architecture has not been merged into the upstream repository. Tencent ships a bridge that expects an already-running, audio-capable llama.cpp server, with a MODEL_TYPE switch — target_only for the translation-only checkpoint, source_target for the interleaved one — and the documentation advises waiting for an official release. Running the quantised build today means running a vendor bridge on top of a llama.cpp build that does not yet know what this model is. That is a reasonable thing to do for an evaluation. It is a fragile foundation for a product, and the failure mode is a dependency you cannot upgrade independently of the vendor's patch.

For the vLLM path, the requirement is version 0.31 or newer with HYV3ForCausalLM support, plus the simulst package. Multi-GPU deployment is supported through tensor parallelism. The one-command installer brings up the web and API service on port 8080 and the model server on 8800, and it runs in an isolated environment — which means it may reinstall SimulInfer or change dependency versions if you point it at an existing stack. Tencent documents a step-by-step path for exactly that reason.

What it takes to serve, and what the release does not include

Speech output and voice cloning are not properties of the checkpoint. The model produces text. Turning that text into speech in the speaker's voice requires a separately configured TTS service, and every part of that sentence carries a cost: another service to run, another network hop in the latency budget, another vendor's terms to review, and another failure point between the microphone and the listener. The model card is straightforward about this, and it is the single biggest gap between the demo and a deployable interpreter.

There is also no hosted API and no published price. Tencent's consumer surface is the Hy Translate app, which offers a free tier on Android and iOS — the cheapest way to hear what the model does, and useless as a production dependency. For everything else you self-host, which means the cost is the accelerator, the operations time, and the TTS bill, not a per-token rate you can put in a spreadsheet.

Language coverage deserves the same scrutiny. The prose documents bidirectional Chinese and English. The Hugging Face metadata tags the checkpoint with 36 languages. No list of the other 34 is published, and the repository's own examples are all en-zh or zh-en. Treat the tag as inherited metadata until Tencent documents otherwise, and do not plan a 36-language rollout on the strength of a tag.

The claims that need a second source

The human-interpreter comparison is the release's most quoted claim and its least supported one. Tencent reports quality "on par with expert human simultaneous interpreters, while often responding faster," based on 18 newly collected recordings of about six minutes each, drawn from ten domains, evaluated by six experienced interpreters — three holding CATTI Level 1 and three holding Level 2. For each level, the best score among the three interpreters was used.

That last detail is doing a lot of work. Taking the best of three against a single model run is a generous construction, and the card does not publish confidence intervals or a per-domain breakdown. It also publishes no objective speaker-similarity score for the voice cloning, which is the feature most likely to decide whether a deployment feels acceptable to the people in the room. The card's own limitation — that the finding is bounded by its samples, participants and settings, and is not a comprehensive assessment — is the correct reading. Medical, legal, and noisy conversational audio are exactly where an interpreter comparison would need per-domain numbers, and those are the numbers that are missing.

Professional interpreters remain the right choice wherever accountability, expert review, or a high-stakes decision is involved. That is Tencent's framing, not a critic's, and it is worth repeating because the headline version of this release did not.

If you self-host it, put something behind it

Neither checkpoint is in OrcaRouter's catalogue, so we are not a route to either one, and this piece will not pretend otherwise. That does not make a router irrelevant to a self-hosted interpreter — it moves it to the edge. A live translation path is a long chain: audio capture, the model server, an optional TTS service, and the client. Each link can stall, and a stall in a meeting is worse than a slightly worse translation. Putting a hosted text model behind the same endpoint as a fallback for the transcript path — not for the audio path — means a dead model server degrades to a readable transcript instead of silence.

OrcaRouter is one API in front of 200-plus hosted models at 0% markup, provider list price passed through with nothing added, and the routing DSL is how a fallback rule gets expressed without a second integration. Automatic failover is the part that matters here: the rule fires on an upstream failure, not on a human noticing that the subtitles stopped.

Which file, then

The versus framing dissolves once you know what the names refer to, and what is left is a packaging decision with three honest answers.

If you are building a voice product — meeting interpretation, a call-centre overlay, anything where the output is audio — take Hy-SimulMT-30B-A3B, or its FP8 build if a single 80 GB card is the constraint. You do not need the transcript, you do not want to pay to generate it, and the base checkpoint is the cleaner latency path.

If a human will read the output, take Hy-SimulMT-30B-A3B-Interleave. Subtitles, bilingual minutes, compliance capture and review workflows all need the source text, and running a separate recogniser alongside the translator is how you end up with two transcripts that disagree about where the sentence ended.

If you are evaluating rather than deploying, take Hy-SimulMT-30B-A3B-Interleave-GGUF at Q4_K_M, accept the 19.7 GB file and the unmerged llama.cpp dependency, and treat it as a way to hear the model on hardware you already own. Upgrade to the FP8 vLLM path only once you have decided the quality is worth the card.

The open question is not which file is better. It is whether the published scores describe the file you picked. Tencent has the hardware to answer that in a day, and until it does, anyone quoting 90.3 or 84.7 should say which of the six checkpoints they believe produced it.