Tencent Hy-SimulMT and StreamLAAL: what a 3-second translation lag actually measures

Tencent Hunyuan released Hy-SimulMT on October 26 under Apache-2.0: a simultaneous translation model for Chinese to English and English to Chinese, with an FP8 checkpoint named 30B-A3B, a streaming inference stack, and a training toolkit. The headline is a StreamLAAL of approximately 3 seconds on long-form RealSI audio, the lowest of every system in Tencent's comparison, which includes commercial live-translate APIs. The model card adds one sentence that most reposts dropped: StreamLAAL "is not the same as the time to first speech output." If you plan to self-host simultaneous translation, that sentence is the whole job.

What shipped

The FP8 model card lists 30B parameters. The A3B in the name suggests about 3B active per token, but the card does not state it. The model takes speech in and outputs text. Speech output and real-time voice cloning, which the announcement leads with, require a separately configured TTS service. The GitHub repository ships SimulInfer (web page, file upload, WebSocket streaming, optional TTS with cloning) and SimulTrain for continued training, plus BF16, GGUF and Interleave variants, the last of which also emits the source transcript.

Quality claims are partly numeric. On the long-form RealSI test, the GEMBA score beats every compared open-source system and four of five commercial APIs, but the values exist only in a chart. On short-form sets the numbers are mixed: 84.7 on RealSI-Sentence is the best listed, while Gemini3.5-LiveTranslate leads FLEURS (92.4 against 90.3) and Qwen3.8-LiveTranslate leads CoVoST2 (82.1 against 75.5). A human study used 18 recordings of about six minutes each and six professional interpreters, and reports quality on par with them, which is a small sample the card itself scopes carefully.

What StreamLAAL measures

Imagine a speaker finishes a sentence and its translation finishes appearing a few seconds later. LAAL, a variant of average lagging for simultaneous translation, measures that trail: how far the output runs behind the input, with a length correction so a system cannot look faster by padding its output with extra text. The catch is that LAAL needs the sentence boundaries handed to it, and a live meeting never hands you any. StreamLAAL, from the StreamAtt paper by Papi, Gaido, Negri and Bentivogli at FBK, takes the whole continuous output, aligns it to the reference sentences with mWERSegmenter, computes LAAL per segment, and averages over the stream. So Tencent's figure reads as: across a long recording, the translation runs about three seconds behind the speaker on the audio timeline.

Two consequences matter. First, the default StreamLAAL is computation-unaware: it measures the policy's lag against the audio timeline, assuming the model itself takes no time. The paper also defines CA StreamLAAL, which counts real elapsed time. Tencent's card does not say which variant produced the 3 seconds. Second, nothing in it covers TTS synthesis, network hops or audio buffering on the listener's side, which is why it differs from time to first speech.

StreamLAAL tells you how patient the translation policy is. It does not tell you when the listener hears anything.

There is also a behavioral cost that no lag metric shows. An interpreter quoted on the repository describes the system as one that "starts speaking first and makes corrections afterward." Low lag bought with later corrections is a fine trade for a conference stream and a bad one for anything a listener acts on immediately.

Self-hosting it

Say you want it translating next Monday's all-hands. The README's main path is vLLM 0.31 or newer, which carries the HYV3ForCausalLM architecture, on Linux with an NVIDIA GPU. The BF16 weights alone take about 57 GiB before any KV cache, so a 48 GB card is out, and Tencent's answer is a single H200; how much the FP8 checkpoint needs is not stated. Reach for SGLang-Omni instead and you get only the BF16 base checkpoint, partial hypotheses refreshed every 1.6 seconds, a context reset every 30 seconds, and none of SimulInfer's voice activity detection or recovery heuristics, so pauses and false starts get less handling than in Tencent's own stack. llama.cpp is no escape hatch yet: GGUF support sits in an unmerged pull request that runs under llama-mtmd-cli but not llama-server, so there is nothing to put behind an endpoint. And do not time the demo videos with a stopwatch. They are offline replays, and the README says their timing should not be read as live latency.

So the "local" story today is one datacenter GPU and Tencent's own server, not a laptop. If you are planning hardware for voice work, the trade-offs I described in the local voice pipeline piece still apply, and the TTS stage is a second model to budget.

How I would measure it

Report three latencies, not one. Policy lag: StreamLAAL on your own recordings, computed with the same mWERSegmenter alignment, so you can compare against Tencent's figure. Compute lag: CA StreamLAAL on your actual GPU at your actual concurrency, because the gap between the two is your serving overhead. Ear-to-ear lag: timestamp each source word at the microphone and the matching translated word at the speaker output, with TTS on. I would add a fourth number for this model specifically: how many committed words get revised later, since that is what "corrections afterward" costs the listener. The streaming latency architecture notes cover where those milliseconds usually hide.

Before you buy anything, record twenty minutes of your real meetings with your speakers' accents and vocabulary, run them through SimulInfer with TTS enabled, and measure ear-to-ear lag and revision rate. If ear-to-ear sits under about four seconds with few revisions, Hy-SimulMT is a credible self-hosted replacement for a live-translate API. If it does not, the 3-second StreamLAAL was never the number you needed.