VibeVoice-ASR-Streaming-7B vs Gemini 3.5 Transcribe Live: One Week, Two Kinds of Streaming Speech-to-Text

The last week of August and the first days of September 2026 produced two streaming speech-to-text systems that look like rivals and are really different answers to the same question. On August 26 Google put Gemini 3.5 Transcribe Live into public preview: a hosted, closed speech-to-text endpoint that returns a finished transcript 0.40 seconds after a speaker stops talking, backed by a measured 4.0% streaming word-error rate from Artificial Analysis and full launch materials. On September 2 Microsoft Research uploaded VibeVoice-ASR-Streaming-7B to Hugging Face under the microsoft namespace: MIT-licensed open weights, no press release, no launch page, and a model card that publishes no word-error rate and no latency figure in readable text at all. Both accept audio while it is still arriving. That is close to the only thing they share.

The evidence on the two sides is not symmetric, so this comparison is written as what-we-know-so-far. Gemini 3.5 Transcribe Live is a Google product with published token prices and third-party measurements, and those are labeled below. VibeVoice-ASR-Streaming-7B is a checkpoint whose every claim is read from the repository itself: the config files, the model card, and Microsoft's streaming documentation in the VibeVoice GitHub repository. Nothing about the Microsoft side has been independently benchmarked yet, and we say so wherever a number would otherwise seem to be doing work.

The release trail: an API launch and a quiet upload

Google shipped Gemini 3.5 Transcribe Live the normal way. The model sits under the Gemini Audio banner with its sibling Gemini 3.5 Transcribe (the pre-recorded Interactions API path), pricing is on the model page, and independent leaderboards picked the Live endpoint up within days — which is where the 4.0% streaming WER and the 0.40-second final latency come from. A free tier exists, with the usual caveat that free-tier content may be used to improve Google products.

Microsoft's streaming release had none of that machinery. The Hugging Face repository microsoft/VibeVoice-ASR-Streaming-7B was created on 2026-09-02 at 15:46 UTC and last touched three minutes later; it holds eight safetensors shards, a tokenizer, and a preprocessor config under an MIT license. The formal record is a news-log line dated September 3 in the microsoft/VibeVoice repository announcing "a unified streaming ASR model that continuously transcribes who said what as speech arrives, with support for customized hotwords and 10 languages," with links to a demo at aka.ms/vibeasr and a streaming technical report. When we checked a day after upload, the checkpoint still showed zero downloads, and no hosted inference provider lists it. The model card says more than the announcement does, and the repository is the source of nearly everything below.

The specs, side by side

• What it is — VibeVoice-ASR-Streaming-7B: open-weights streaming ASR, self-hosted vs Gemini 3.5 Transcribe Live: hosted streaming API, closed weights.

• Streaming shape — emits text in roughly 2.9-second chunks with about 0.5 seconds of lookahead (derived from the checkpoint config) vs a bidirectional WebSocket session with continuous partial transcripts and a final result 0.40 seconds after the speaker stops.

• Accuracy in print — no WER or latency figure published as text vs 4.0% streaming WER and 2.6% on the pre-recorded model, per Artificial Analysis.

• Speakers — claims streaming who-said-what attribution, unverified vs no speaker diarization on the Live endpoint (available on the pre-recorded model, up to three speakers).

• Languages — 10 (en, zh, es, pt, de, ja, ko, fr, ru, it) vs auto-detection across 85+ with mid-stream switching.

• Session length — bounded only by your GPU and memory vs a hard 10-minute cap per Live session.

• Cost — $0 for the weights, about 18 GB of bf16 to self-host vs roughly $0.54 per audio-hour on Live once text output tokens are counted.

What "streaming" means on each side

The word hides a real design difference, and it is worth being precise because the two systems are not even trying to produce the same cadence. Microsoft's preprocessor config makes the VibeVoice rhythm concrete: audio arrives at 24 kHz and is compressed 3,200× into a token stream at about 7.5 frames per second, then the config declares a chunk of 22 frames and a lookahead of 4 frames — about 2.9 seconds of audio per chunk with roughly half a second of future audio to firm it up. The model emits text once per resolved chunk, and context from earlier chunks is preserved through the KV cache, so a long session does not recompute from scratch. The practical transcript grows in roughly three-second increments.

Google's Live endpoint is built for a faster, more interactive loop: audio streams up a WebSocket in 16 or 24 kHz PCM chunks, partial transcripts come back continuously while the speaker is going, and a final formatted transcript lands 0.40 seconds after the end of speech — that number is Artificial Analysis' measurement, cited by Google. The trade-offs are the session cap (ten minutes of audio, after which your application must reconnect and stitch), and the missing extras: no speaker diarization and no word-level timestamps on the Live path, both of which exist on the pre-recorded Gemini 3.5 Transcribe. So the honest summary is that Google's streaming model is faster per utterance, while Microsoft's streaming checkpoint is slower per chunk but claims the speaker attribution Google's live lane drops, at a session length Google does not offer.

Accuracy: measured, versus a blank space

The widest gap in this matchup is a gap in evidence, not necessarily in quality. Artificial Analysis measured Gemini 3.5 Transcribe Live at a 4.0% average word error rate in streaming and 2.6% on the non-streaming model, the latter ranked fifth on its WER leaderboard at launch; Google separately cites 5.50% streaming and 5.04% non-streaming on the FLEURS multilingual set. Read those the way they are labeled: Artificial Analysis is independent of Google, but a one-day-old API's numbers are still early, and the streaming premium over the batch model — 4.0% vs 2.6% — is the usual price of real-time delivery.

VibeVoice-ASR-Streaming-7B has no comparable figure anywhere. The model card ships an evaluation figure as an image, and Microsoft's technical report is a PDF, but neither offers a plain-text streaming WER or latency number that can be quoted or independently checked. The only numeric anchor in the whole family is the batch VibeVoice-ASR model card, which reports a vendor-run average 7.77% WER across eight English test sets and 2.20% on LibriSpeech clean — figures for the non-streaming model, not this one, and streaming models typically trade a little accuracy for the latency win. Until someone runs the streaming checkpoint through a public harness, the fair statement is that one side of this comparison is measured and the other is not.

Cost: a metered API versus a GPU you already budgeted

Google prices Gemini 3.5 Transcribe Live by the token and bills audio at 25 tokens per second. On the published Live rates — $3.50 per 1M audio tokens and $21 per 1M text-output tokens — a blended audio-hour comes to roughly $0.54, about $9 per 1,000 audio-minutes, and the pre-recorded model is cheaper still at roughly $0.30 an hour. Silence is only free if your client does not stream it: reconnects, duplicated audio, and logging all add metered tokens to the real bill.

Microsoft's checkpoint is priced in GPU-hours instead. The bf16 weights alone run to about 18 GB before any KV cache, the documented paths are the Python demos in the microsoft/VibeVoice repository and a vLLM plugin that serves WebSocket and OpenAI-compatible endpoints, and there is no hosted price because no provider hosts the model yet — it is not on Azure AI Foundry the way the batch VibeVoice-ASR has been since March. Self-hosting a 7B-class speech-LLM means budgeting a 24 GB-class GPU and your own operations time; in exchange you get unlimited session length and weights that are yours to keep. The two models are not mutually exclusive, which is the point of the last section.

Keeping the choice cheap

Which you pick depends on whether you need a number or code. Pick Gemini 3.5 Transcribe Live when you want transcription that works today with published accuracy and no GPU to run — and when your audio is not confined to ten languages, or you are prepared to build speaker labeling yourself because the Live endpoint does not provide it. Pick VibeVoice-ASR-Streaming-7B when you self-host, when unbounded session length or the claimed speaker-attributed streaming output matters, and when you are willing to run your own evaluation gate because there is no benchmark to lean on.

Neither choice needs to be permanent, and that is where a routing layer earns its keep — for the models around the transcript, not the transcription itself. OrcaRouter does not route speech-to-text today, and none of the models on this page are in its catalog; what it does is give one API to the 200+ language models that consume a live transcript — the summarizer, the action-item extractor, the voice agent's planner — at provider list prices passed through with no markup, with automatic failover across providers. A vendor price cut on any model in that stack is live the same day because list prices are passed through rather than marked up. The transcription step stays where you put it; the stack that acts on the transcript is exactly the layer where a single key and a fallback route turn a one-week-old, unbenchmarked checkpoint from a bet into a testable option.