# Half a second off the lag, and 2.7 points on
> Satyajit Ghana — Head of Engineering @ Inkers Technology
> canonical: https://ai.thesatyajit.com/articles/qwen-livetranslate
> date: 2026-09-19
> tags: explainer, speech, audio, multimodal, benchmarks, architecture
Simultaneous interpretation has one hard constraint and everything else is
engineering around it. You cannot translate a verb-final sentence well without
waiting for the verb. Japanese, Korean and Turkish put the thing that decides
the clause — including whether it is negated — at the end, so a system that
starts speaking early is guessing, and a system that waits is late. Every
latency number in this field is a claim about how much guessing you are willing
to buy.
Which is why a latency number on its own is not a result. You can have any lag
you like if you are allowed to be wrong.
[Qwen3.8-LiveTranslate](https://qwen.ai/blog?id=qwen3.8-livetranslate), released
on 18 September, is being quoted everywhere as *average lagging down from 2.8
seconds to 2.3 seconds*. Apart from a language count, it is the only measurement
anywhere in the post's prose. It is also the least interesting number in the
post, because the figure it comes from publishes the quality score beside it —
and the quality went **up**.
**Receipts.** The headline "LAAL 2.8s → 2.3s" is one column of a four-column figure, and the baseline is Qwen's own previous generation, not a competitor. Read across the row instead: Qwen3.8-LiveTranslate moved half a second of lag and 2.7 points of translation quality in the same direction at the same time, which is the opposite of how the simultaneous-interpretation trade normally runs.
| system | xCOMET-XXL ↑ | LAAL s ↓ | ASR WER % ↓ | UTMOS ↑ | weights |
| :--- | ---: | ---: | ---: | ---: | :--- |
| Qwen3.8-LiveTranslate | 85.7 | 2.3 | 6.6 | 4.0 | API only |
| Qwen3.5-LiveTranslate (the 2.8s baseline) | 83.0 | 2.8 | not shown | 3.9 | API only |
| Seed LiveInterpret 2.0 | 79.4 | 2.8 | 7.0 | 3.0 (26/70 dirs) | API only, paper published |
| Gemini 3.5 Live translate | 73.5 | 2.5 | 11.4 | 3.4 | API only |
| GPT-Realtime-Translate | 65.2 | 3.1 | not shown | 3.4 | API only |
Each cell is a single number aggregated over all 70 directions. No per-language or per-direction breakdown was published, so the spread — which is where a verb-final source language such as Japanese, Korean or Turkish would show up against a verb-medial one — is not recoverable from the release. Qwen does disclose one uneven denominator, against its own interest: Seed LiveInterpret 2.0's UTMOS covers only the 26 directions it supports while every other system covers all 70. The release does not state whether LAAL was measured on the emitted text stream or on the synthesized audio, and for a speech-to-speech system those are different numbers.
> method: Every figure transcribed from the FLEURS panel published in the Qwen3.8-LiveTranslate release post on 2026-09-18. Qwen states the evaluation covers 19 languages (zh, en, ja, ko, ar, cs, de, es, fr, id, it, ms, nl, pl, pt, ru, th, tr, vi) and 70 directions. 70 is exactly the number of directions into and out of English and Chinese among 19 languages (18×2 into the two pivots, 18×2 out of them, minus the en↔zh pair counted twice); all 342 ordered pairs would be the alternative, so no direction in this evaluation has a non-pivot language at both ends.
> source: https://qwen.ai/blog?id=qwen3.8-livetranslate
> captured: 2026-09-19
> data: https://ai.thesatyajit.com/articles/qwen-livetranslate/data/fleurs.json (5 rows)
Read the top two rows. Half a second of lag removed and 2.7 xCOMET points added,
same benchmark, same 70 directions, one generation apart. That is not how this
trade usually runs, and it is the actual claim worth checking.
So let us check it, along with everything around it — because the evidence gets
noticeably thinner the further you get from that one figure.
## What LAAL actually measures
LAAL is not a vibe. It is
[Length-Adaptive Average Lagging](https://aclanthology.org/2022.autosimtrans-1.2/),
proposed by Papi, Gaido, Negri and Turchi in 2022, and it has a formula.
Start with the intuition: **how far behind the speaker is the system, averaged
over the words it emits?** The trick is defining "behind". You need something to
be behind *of*, so the metric invents an oracle — an interpreter perfectly in
sync with the speaker, who starts the instant the speech starts and spreads the
translation evenly across the utterance.
Write the source audio as `X = [x₁ … x₍|X|₎]` where each `xⱼ` lasts `Tⱼ`
seconds, the reference translation as `Y*`, and the model's output as `Y`. The
delay at which the model emits its `i`-th target word is
$$d_i = \sum_{j=1}^{J(i)} T_j$$
— the amount of source audio that had been consumed when word `i` came out. The
oracle's delay for the same word is a straight line:
$$d^*_i = (i-1)\cdot\frac{\sum_{j} T_j}{\max\{|Y|,\ |Y^*|\}}$$
and the metric is the mean of `dᵢ − d*ᵢ` over the words emitted before the source
ends. That is the whole thing: **the average vertical gap between two
staircases.**
The `max{|Y|, |Y*|}` in the denominator is the "length-adaptive" part, and it
exists because of a specific way of cheating. Plain Average Lagging divides by
`|Y*|`, the reference length. A system that over-generates — emits more words
than the reference — then gets credited with an oracle that is slower than it
should be, and its lag is discounted for free. Papi et al. checked and found
real systems doing exactly this, so LAAL takes whichever of the two lengths is
longer, per sentence. Neither under-generating nor over-generating buys you
anything.
Two properties of LAAL matter for reading Qwen's number, and neither is
mentioned in the release.
**It is defined on words, not on audio.** `dᵢ` is when target *word* `i` was
emitted. LAAL was built for simultaneous speech-to-*text* translation. Qwen3.8-LiveTranslate
is a speech-to-speech system: a Thinker writes text and a Talker synthesizes it.
Those are two different clocks, and the release does not say which one it
measured. For comparison, ByteDance's
[Seed LiveInterpret 2.0](https://arxiv.org/abs/2507.17527) — the closest
competitor here, and one that published an actual paper — is explicit about
which clock it is on: *"slashing the average latency of cloned speech from
nearly 10 seconds to a near-real-time 3 seconds."* Qwen's own figure puts that
same system at 2.8 LAAL. Both can be true; they are measuring different things.
Anyone comparing Qwen's 2.3 to Seed's 3.0 across the two announcements is
comparing a text clock to an audio clock.
**Its oracle is a fiction the paper admits to.** From the limitations section:
the oracle "emits only one word at each time step, each one with a fixed word
duration", which assumes reference words are uniformly distributed through the
utterance. Real speech has pauses, hesitations and varying rate. The authors say
so themselves — "the latency scores obtained can still largely differ from the
latency experienced by the user" — and call for something more human-centric.
Four years later the field is still quoting LAAL.
## The trade, plotted
Here is why the quality column is the story and the latency column is not.
Look at Gemini 3.5 Live translate. At 2.5s it is **faster than Qwen's previous
generation and faster than Seed** — and it scores 73.5 xCOMET against their 83.0
and 79.4. That is the trade doing exactly what it always does: latency bought
with quality. If Gemini had announced "2.5 seconds" and stopped there, the
number would have been true and worthless.
Qwen3.8 is alone in the top-left corner, and getting there from the previous
generation moved both axes the right way at once. Whatever the Interleave
architecture is, that is the result it has to explain.
### Name the denominator
The figure's own footnote does most of this work, which is to Qwen's credit, and
the rest is arithmetic.
**Nineteen languages, not sixty.** The evaluation covers zh, en, ja, ko, ar, cs,
de, es, fr, id, it, ms, nl, pl, pt, ru, th, tr, vi. The model is documented as
supporting 60 — which
[Alibaba Cloud's own docs break down](https://www.alibabacloud.com/help/en/model-studio/qwen3-5-livetranslate-flash-realtime)
as 29 with audio-and-text output plus 31 text-only, and 29 + 31 = 60 exactly. So
**41 of the 60 supported languages have no published number at all**, including
every one of the text-only 31. The widely-repeated framing "LAAL reduced across
60 languages" is a misreading: the blog says the lag dropped, and separately says
the model builds on support for 60 languages. Those are two sentences.
**Seventy directions, all of them through English or Chinese.** Nineteen
languages admit 19 × 18 = 342 ordered pairs. The evaluation uses 70. Seventy is
exactly the count of directions into and out of `en` and `zh` among those 19:
18 into each pivot, 18 out of each, minus the `en↔zh` pair counted twice. No
direction in this evaluation has a non-pivot language at both ends — there is no
Thai→Turkish number here, and none published anywhere else.
**One number per system, and the hard case is 9% of it.** Each cell is a single
aggregate over all 70 directions. Of those 70, exactly **six** have a canonically
verb-final source language — `ja→en`, `ja→zh`, `ko→en`, `ko→zh`, `tr→en`,
`tr→zh` — and 58 have a verb-final language at neither end. The one linguistic
situation that makes this task hard is under a tenth of the average that is
supposed to demonstrate the task got easier. No per-language or per-direction
breakdown was published, so the spread — the thing that would tell you whether
2.3s means 2.3s everywhere or 1.8s in French and 3.4s in Japanese — is not
recoverable from the release.
**And FLEURS is the easy case.** FLEURS is read speech: three speakers per
language reading isolated Wikipedia sentences from FLoRes-101, roughly twelve
seconds each. One speaker per clip, clean audio, no disfluencies, no overlapping
talk, no cross-sentence context, and a clean sentence boundary for `τ'(|X|)` to
land on. It is a reasonable place to compute LAAL and a poor proxy for a
conference room — and note what it structurally cannot test: a single-speaker
corpus of isolated sentences cannot evaluate speaker diarization or long-context
disambiguation, which are the two headline features of this release.
## The Interleave architecture
This is what the release is named after, so it is worth being precise about how
much of it is disclosed.
Here is the entire technical description, quoted in full:
"Qwen3.8-LiveTranslate adopts a Hybrid-MoE-based Thinker–Talker two-module
design, connecting streaming understanding, text output, and speech generation
through interleaving. Here, the Thinker arranges video, audio, source text, and
translation into a single causal sequence — interleaved in temporal order and
produced end to end — so that understanding and translation happen within one
sequence; the Talker then combines the translation and the source audio to
synthesize the translation into speech that preserves the original speaker's
timbre."
And the diagram:
That is all of it. There is no paper, no technical report, and no weights. The
Qwen organisation on Hugging Face lists 465 models; not one of them has `live`,
`translate` or `interpret` in its name, in this generation or either of the two
before it — while the adjacent speech stack *is* open, including
[Qwen3-ASR-1.7B](https://huggingface.co/Qwen/Qwen3-ASR-1.7B-hf) and its 0.6B
sibling. LiveTranslate has been API-only since the first release in September
2025. So the mechanism has to be read off two sources: that paragraph, and the
API.
### What "interleaved" is doing, to the extent it is disclosed
There are actually **two** interleavings being claimed, and the post runs them
together.
The first is in the Thinker's sequence. A classical cascade is three models in
series — ASR, then MT, then TTS — and each one is a boundary where the
downstream stage cannot start until the upstream stage has committed something
it is confident about. That commit latency is paid three times, and information
that does not survive the text bottleneck (prosody, emphasis, speaker identity)
is gone at the first hand-off. The claim here is that video frames, source audio,
source text and translation tokens all live in **one** causal sequence, laid down
in temporal order, so a translation token can be written between two audio tokens
with no boundary to cross.
The second is between Thinker and Talker: the strip of alternating tokens in the
diagram, labelled *Interleaved Text & Speech Generation*. The Thinker's text
output and the speech tokens it is being converted into are interleaved in one
stream, rather than the Talker waiting for a complete text unit.
Everything past the previous two paragraphs is not disclosed. How many audio
frames sit between writes; what decides when to write (a fixed wait-`k`, a
learned policy, a detector); the chunk size; how many experts, how many layers,
how many parameters; what the Talker's speech tokenizer is; how any of it was
trained. The ribbon above is the *shape* of the claim drawn from Qwen's own
sentence, not a trace of a real sequence. If you need to reimplement or verify
the mechanism, this release does not let you.
### The one mechanism change you *can* read off the API
Buried in the Model Studio docs is the most concrete architectural fact in the
whole release:
"The VAD and Manual configurations below apply to `qwen3.5-livetranslate-flash-realtime`.
For `qwen3.8-livetranslate-flash-realtime`, the default turn detection
configuration is `audio.input.turn_detection.type = speaker_detection`; send
audio continuously and receive server-generated responses."
The previous generation segmented on **silence**: voice-activity detection fires
`speech_started` / `speech_stopped`, the buffer commits, translation triggers. The
new one segments on **speaker**. That is a different unit of work, and it is the
same change that delivers diarization — you cannot attribute a sentence to a
speaker unless speaker identity is what bounds the sentence. It also removes a
structural reason to wait: a VAD-bounded system has an incentive to sit through a
pause to see whether the utterance is really over, and a speaker-bounded one does
not.
Is that where the half second came from? Unknown — Qwen publishes no ablation,
and there is nothing in the release that separates the turn-detection change from
the architecture change from ordinary scaling. It is the only moving part that is
documented at all, which is a reason to notice it and not a reason to believe it.
On the verb-final problem, the docs claim a specific mechanism carried over from
the previous generation: *"Predicts semantic units to resolve cross-language word
order differences."* They predict the verb rather than wait for it. That is the
honest answer to the hard constraint, it is what a human interpreter does too, and
no evidence for it is published beyond the aggregate xCOMET score.
## Diarization, and the benchmark that was not released
The second figure is the multi-speaker evaluation, and it contains the release's
single most impressive number.
**DER 9.7% while streaming, against 18.0% and 26.7% for systems running
offline.** Diarization gets substantially easier when you can see the entire
recording before deciding who spoke when — you can cluster globally instead of
committing to a speaker identity in real time. Qwen labels which systems had that
advantage, which is the right thing to do and makes the number stronger rather
than weaker. Against the one genuinely comparable system, Seed-asr-2.0-streaming
at 30.6%, it is a three-fold gap.
The conciseness panel is worth reading properly, because "outperforms across four
dimensions" flattens it. Against Seed, Qwen3.8 wins 20.3% of pairwise comparisons
and loses 9.7% — with **70.0% ties**. A dimension where seven comparisons in ten
are indistinguishable is a dimension that barely discriminates, and reporting it
as a win alongside an 87.2% fluency win puts two very different results under one
sentence.
And then there is the evidence itself. The release links
[Omnilingua-MSpeaker](https://github.com/QwenLM/Omnilingua-Bench) as the
evaluation set. That repository is real, is public, and ships a version tag. I
cloned it and parsed all 297 rows.
**Receipts.** The release links Omnilingua-MSpeaker as the evidence for its speaker-attribution and translation-quality wins. The public release of Omnilingua-MSpeaker cannot produce those numbers: it contains no translation references, no Chinese or English audio, and no quality metric. The benchmark that was cited and the benchmark that was released are not the same artifact.
| | as cited in the release post | as released in the repo (measured) |
| :--- | :--- | :--- |
| task | translation — faithfulness, fluency, conciseness + DER | speaker_attributed_asr, 297/297 rows |
| language directions | 14 directions over 8 languages (zh, en, es, fr, ja, ko, ru, th) | 0 translation directions; every row has source == target |
| languages present | 8, including Chinese and English | 6 — es (50), fr (47), ja (50), ko (50), ru (50), th (50). No zh, no en. |
| metrics defined | faithfulness, fluency, conciseness, DER | tcpWER, cpWER, DER — no quality metric of any kind |
| reference fields | — | segments[] of {media_id, start_sec, end_sec, speaker_id, text, language}; 21,046 segments, no translation field |
| scale | "multi-speaker long-audio evaluation set" | 297 items, 105 distinct videos, 26.27 h; 2 speakers median, 20 maximum |
| media | — | none shipped — source_url plus start/end offsets into public social-media video, CC BY-NC 4.0, research only |
The 14 directions the figure claims fit one construction exactly: the six released source languages (es, fr, ja, ko, ru, th) each into English and Chinese, plus en→zh and zh→en. 6×2+2 = 14. So the evaluation looks like the public audio set re-annotated with translation references and extended with a zh/en pair — a reasonable thing to build, and none of it is in the repository. Separately, "% of pairwise comparisons" is a judge-scored preference eval, and the release does not say who or what the judge was.
> method: Cloned github.com/QwenLM/Omnilingua-Bench at v202609 and computed every figure in the right-hand column directly from Omnilingua-MSpeaker/Omnilingua-MSpeaker_v202609_public.jsonl — 297 rows parsed, task and track counted, source/target language pairs tallied, media durations summed, source_url values de-duplicated, reference keys enumerated. The left-hand column is what the release post and its figure state.
> source: https://github.com/QwenLM/Omnilingua-Bench
> captured: 2026-09-19
> data: https://ai.thesatyajit.com/articles/qwen-livetranslate/data/eval-gap.json (7 rows)
The public release of Omnilingua-MSpeaker cannot produce the numbers in that
figure. Every one of its 297 rows has `task: "speaker_attributed_asr"` and
`source == target` — it is monolingual transcription with speaker labels. There
are no translation references anywhere in the file; the reference schema is
`segments[]` of `{media_id, start_sec, end_sec, speaker_id, text, language}` and
that is the complete list of fields across all 21,046 segments. The repo's own
README names the metrics as tcpWER, cpWER and DER, with no quality metric of any
kind. It covers six languages — es, fr, ja, ko, ru, th — and contains no Chinese
or English audio at all, while the figure claims eight languages including both.
The 14 directions fit one construction exactly: the six released languages each
into English and Chinese, plus `en→zh` and `zh→en`. 6 × 2 + 2 = 14. So the
evaluation is almost certainly the public audio re-annotated with translation
references and extended with a zh/en pair. That is a perfectly reasonable thing
to build. None of it is in the repository, and the release does not say so.
The DER column is the part that *is* checkable against the public data, since DER
is a metric the released set defines. The faithfulness, fluency and conciseness
columns are not — and those are "% of pairwise comparisons", which means a judge
scored them. **The release does not say who or what the judge was.** Not human
interpreters, not an LLM, not which one, not how many comparisons. A pairwise
preference win rate from an undisclosed judge on an unreleased extension of a
benchmark maintained by the same organisation is the weakest kind of evidence in
this release, and it is carrying three of the four panels.
## Voice cloning, and what is not said about it
The Talker clones the speaker's voice from the live input audio. The API makes
the mechanism plain:
```json
"session": {
"enable_voice_clone": true,
"voice_clone_options": { "frequency": "always" },
"voice": "default"
}
```
`frequency` takes three values. `never` uses a voice profile cloned in advance.
`once` clones from the input audio at session start and reuses it. `always`
re-clones **before every response**, which the docs describe as "dynamically
adapting to speaker changes. Best for multi-speaker conversations" — this is the
mechanism behind "more stable voice cloning" in a diarized setting, and it is how
each speaker in a meeting keeps their own timbre in the translated output.
There is no enrollment step and no reference sample to provide. The source of the
voice is whatever audio arrives on the socket.
On safeguards, the factual position is short. **Across the release post, the model
page and the Model Studio documentation, there is no mention of watermarking,
synthetic-audio labelling, consent capture, authorisation to clone a given voice,
impersonation restrictions, or any misuse policy specific to voice cloning.** The
only content restriction anywhere in the adjacent voice-cloning documentation is
a line telling you that sensitive material in the *recording script* will cause
cloning to fail. That is a statement of what I found, not an accusation: such
terms may exist in Alibaba Cloud's general service agreement or in a
jurisdiction-specific policy. They are not in the technical documentation for
this product, and a reader evaluating it for deployment would have to go looking.
## The features nobody measured
Two of the three headline capabilities have no number attached anywhere.
**Long-context disambiguation** — "reads the present in light of what came
before, making names and terminology more precise" — is not evaluated. FLEURS is
isolated sentences; MSpeaker is transcription. There is no benchmark in the
release that tests whether a name introduced in minute three is still spelled
right in minute forty.
What *is* documented is its budget. The context window is 53,248 tokens, split
49,152 input and 4,096 output, and audio bills at 7 tokens per second of input.
That gives a hard ceiling:
```
49,152 tokens ÷ 7 tokens/second = 7,022 seconds = 117 minutes of audio
```
So "conversation history" is bounded at about one hour fifty-seven minutes of
speech — before any video frames, which bill at 0.5 tokens per 32 × 32 pixels and
come out of the same budget. That is a real and generous number for a meeting and
a short one for a conference day.
The shipped mechanism for the specific problem of names and terminology is not
the context window at all. It is a manual dictionary:
```json
"translation": {
"language": "en",
"corpus": { "phrases": { "人工智能": "Artificial Intelligence" } }
}
```
Hotwords, supplied per session by the caller. Which works, and is the opposite of
letting the model figure it out from history.
**Synchronized bilingual display** is a protocol feature and an honest
simplification. Previously you enabled source-language output by pointing
`input_audio_transcription.model` at a separate ASR model —
`qwen3-asr-flash-realtime` — and paid for a second model's output. Now, per the
release, "the server returns the speaker identifier and the source-language text
alongside the translation, with no need to call a separate ASR interface". One
model, one stream, source and translation aligned because they were generated in
the same sequence. That is a genuine consequence of the interleaved design, and
it is the cleanest thing the architecture claim actually buys.
## What it costs
Worth stating, since this is an API-only product and the price is a first-class
property of it. From the published billing: 7 tokens per second of input audio at
`$7.50` per million, 12.5 tokens per second of output audio at `$30.00` per
million.
```
input 7 tok/s × 3600 × $7.50/1M = $0.189 per hour
output 12.5 tok/s × 3600 × $30/1M = $1.350 per hour
─────────
$1.539 per hour of continuous interpretation
```
Roughly a dollar fifty an hour, plus text output if you want the source
transcript. Against a human simultaneous interpreter that is not a close
comparison, and it is also not the same product.
## What the release is, and what it is not
Three things here are good and under-credited:
The **quality number was published next to the latency number**, on the same
benchmark, with the previous generation in the same figure. Most latency
announcements do not do this, and an 83.0 → 85.7 xCOMET move alongside a 2.8 →
2.3 LAAL move is a real result that the "18% lower latency" headlines throw away.
The **uneven denominator was disclosed** — Seed's UTMOS measured on 26 of 70
directions, marked in the footnote, on the panel where Seed's bar is lowest.
That is a lab labelling a caveat that works against the impression its own chart
makes.
The **streaming/offline distinction was labelled** on the diarization panel, and
a benchmark repository was published at all, with a version tag, a schema
validator and a license — even if the version used for the figure is not the
version in it.
And three things are missing: no weights, no paper, no ablation. The mechanism
the model is named after is disclosed at a level that permits a diagram and
nothing else, and the strongest quality claims rest on an unreleased eval scored
by an unnamed judge. ByteDance shipped a paper for the competing system. Qwen
shipped a blog post and a price list.
The numbers are probably right. There is just no way to check them, which in a
field where the entire contribution is a trade-off between two quantities is
more of a gap than it would be somewhere else.
LAAL as defined by Papi et al. takes `dᵢ` to be the emission time of target *word* `i`, and the release never says otherwise. Publish the same 70-direction evaluation with the clock started at the first audio sample of word `i` leaving the Talker. If the number stays at 2.3s, the Talker adds no measurable delay and I am wrong about which clock this is; if it rises, every comparison against a system that reported speech latency needs redoing in one direction.
Enumerate the directions into and out of English and Chinese among Qwen's 19 listed languages and the six are `ja→en`, `ja→zh`, `ko→en`, `ko→zh`, `tr→en` and `tr→zh`; 58 of the 70 have a verb-final language at neither end. Publish per-direction LAAL and xCOMET. If those six sit within a few hundred milliseconds of the 2.3s mean, the aggregate is representative and the objection dissolves. If they sit a second above it, "2.3 seconds" describes verb-medial language pairs and the hard case was averaged away.
Every row in the published `v202609` file has `source == target` and `task: speaker_attributed_asr`, with no translation reference field and no zh or en audio, while the figure claims 14 translation directions over 8 languages. Release the translation references and the zh/en audio index — or point at the version that has them — and this is just a citation that outran its repository. If a translation split already exists under a tag I did not check, the claim is simply wrong.
The release says "% of pairwise comparisons" and names no judge. Name it. If those bars are human interpreters scoring blind pairs, they become the strongest evidence in the release rather than the weakest, and I have this exactly backwards — so the fix is one sentence and it is worth Qwen's while to write it.
This is an inference from one line of API documentation and nothing else. Run `qwen3.8-livetranslate-flash-realtime` with `turn_detection.type` forced back to VAD on the same FLEURS directions. If LAAL stays near 2.3s, the turn-detection change is not where the half second went and the credit belongs entirely to the architecture or to scaling.