Ming-3.0-audio-tiny vs VibeVoice-ASR-Streaming 1.5B: Five Dashes Against a Speaker-Attributed Stream

Open the recognition image inside Ming-3.0-audio-tiny's Hugging Face repository and scroll to the bottom. Five rows — speaker diarization and concatenated minimum-permutation error for AISHELL-4, AliMeeting and AMI — carry a dash in the tiny column. Not a bad number. A blank. The vendor measured its larger sibling on all five and declined to measure the small one. Now open the model card for VibeVoice-ASR-Streaming 1.5B and read the first bullet: it transcribes who said what, continuously, as the speech arrives. That is the same five rows, inverted. One model publishes almost everything except speaker attribution; the other exists mainly to publish it. The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

Neither has been independently scored. That matters less here than usual, because this matchup is decided by a design decision rather than a number: what happens when the audio never stops arriving. Ming-3.0-audio-tiny is a file model with a large window and an optional speech output. VibeVoice-ASR-Streaming 1.5B is a stream model that emits text roughly every three seconds and labels each segment with a speaker. If your workload is a recording, they compete. If your workload is a room, only one of them is trying.

What "streaming" costs in the config

Microsoft's repository is unusually legible about its own latency budget, which makes the trade-off checkable rather than marketing. The acoustic and semantic tokenizers are causal and run at 3,200× compression against a 24 kHz input, so the token stream is about 7.5 tokens per second of audio. The streaming wrapper batches 22 token frames per chunk with 4 frames of lookahead: 22 divided by 7.5 is roughly 2.9 seconds per emission, and 4 divided by 7.5 is about half a second of future audio the model is allowed to see before committing.

• Emission cadence — about 2.9 seconds; the lookahead is the part that buys accuracy at the cost of latency.

• Backbone — a Qwen2-family decoder, 28 layers, 1,536 hidden, 12 heads with 2 key-value heads, 64,000-token window.

• Size — three safetensors shards totalling 5.63 GB. That is not 1.5B parameters; 5.63 GB at bf16 works out nearer 2.8 billion, and the 1.5B in the name is best read as the language backbone rather than the whole stack.

• Languages — ten: Chinese, English, French, German, Italian, Japanese, Korean, Portuguese, Russian, Spanish.

• Extras — customised hotwords passed as context, and a speaker label attached to each emitted segment.

• Dating — repository created 2 September 2026 at 15:51 UTC, last modified the following morning. Announced only by a news line in the VibeVoice GitHub README, which is to say barely announced at all.

That 64K window is the number to hold against Ming's 131,072. It sounds like half the capacity, but it is not the same kind of capacity. A streaming model does not need to hold an hour, because it has already written down the last fifty-nine minutes. The window is working memory for the current chunk plus whatever dialogue context the model carries forward. Ming's 131K is the opposite bet: keep everything live and reason over it.

Ming's bet, and what it buys

The tiny model's selling point is not recognition accuracy — on inclusionAI's own tables it is 0.34 points behind its bigger sibling on Chinese (3.79 against 3.45 character error) and 0.89 behind on dialects (10.29 against 9.40). The selling point is that one checkpoint does recognition, comprehension, reasoning and speech in the same forward pass, over a window long enough that "what did she say in the first ten minutes" is a question you can ask.

Its audio-intelligence numbers are respectable for the size and are the reason to prefer it over a pure transcriber: MMAU 75.90, MMAR 67.70, MMSU 73.06, BigBenchAudio 99.20, MuchoMusic 58.07 for music. Those are all vendor-run with asterisks on the self-evaluated rows, and the card discloses that comparison models were reproduced under inclusionAI's own prompts and decoding. Read them as a design brief.

What the tables will not tell you is who spoke. That is the gap the five dashes mark, and it is structural rather than accidental. A model that answers questions about a recording does not need per-speaker segmentation to answer them; a model that produces a transcript for a meeting does. Ming can probably be prompted into something like speaker labelling, and the card's highlight about "multi-speaker recordings" suggests it was trained near the problem. But "probably" is doing the work of five unpublished rows.

Two pipelines, drawn honestly

Picture the same ninety-minute recording going through each.

With VibeVoice-ASR-Streaming 1.5B, audio arrives in chunks of about three seconds and text leaves in the same rhythm, each segment carrying a speaker. You can display it live. The cost is that every decision is local-ish: the model saw half a second ahead and whatever context it retains, so a speaker who pauses for four seconds may come back labelled differently, and a name introduced at minute two is only recoverable through the hotwords mechanism, which you supply. Cross-chunk consistency is the thing to test and the thing the card does not quantify.

With Ming-3.0-audio-tiny, the file lands, the whole thing is in context, and the answer arrives when it arrives. Cross-chunk consistency is not a risk because there are no chunks — up to the window. The cost is that nothing is available until the model has finished, and the memory reservation is sized for the full window: the reference ASR profile holds 0.92 of a card with a 32,768-token batch. You can lower max_model_len; you cannot make it stream, because there is no streaming path in the repository.

• Latency shape — VibeVoice: continuous, ~3 s behind. Ming: one answer at the end.

• Attribution — VibeVoice: per segment, by design. Ming: unpublished.

• Context — VibeVoice: 64K working window plus its own transcript. Ming: 131,072 positions, roughly three hours of audio by arithmetic on the encoder, if the processor feeds one continuous stream.

• Output — VibeVoice: text. Ming: text, or text plus synthesised speech through an optional Talker on a second GPU.

• Hardware — VibeVoice: a 5.63 GB checkpoint, so a single commodity card. Ming: 17.74 GB of Thinker, one card for text, two for speech.

The licence and the paperwork are the same, and that is unusual

Both are MIT. Both are quiet releases. Both put the weights up before the documentation caught up, and both lean on a GitHub repository that is not named after the checkpoint: Ming's deployment profiles live in inclusionAI/Ming-3.0-audio-flash, and VibeVoice's usage instructions live in microsoft/VibeVoice alongside the 7B sibling.

The differences are in what each repository tells you. Microsoft ships a technical report — arXiv 2609.02812 — and a results figure in the card, which is an image rather than a table, so the numbers are not extractable and no per-language error rate is stated in text. inclusionAI ships three benchmark images, also images, plus a card that names its own weaknesses only implicitly, by leaving cells blank. Neither vendor gives you a number you can paste into a spreadsheet without transcribing it by hand.

One asymmetry is worth flagging for anyone doing procurement: Ming's Hugging Face repository contains no LICENSE file, only a link in the card's metadata to a licence in the other repository. VibeVoice's card states MIT in the metadata and the repository carries the licence file. Both claims are true; only one is inside the artefact.

What a router is and is not for here

OrcaRouter serves neither model. Ming-3.0-audio-tiny is a checkpoint and VibeVoice-ASR-Streaming 1.5B is a checkpoint; neither is in our catalogue, and nothing in this piece is an offer to host them. The router's place in a pipeline like this is downstream of the transcription and upstream of the decision: summarising the call, extracting the commitments, classifying whether the segment needs a human, translating the parts that were not in the working language. Those calls are text, and one endpoint for more than 200 models at 0% markup — provider list price passed through, so a vendor price change lands on our side the same day — removes a contract per vendor from the build. Automatic failover is the specific feature that matters when a two-hour transcription job has to hand its output somewhere reliable at 2 a.m.

What a router will not do is reconcile two speaker labels that disagree, or decide whether Ming's missing diarization rows are a real weakness or an unmeasured one. That is a job for your own audio.

The test that separates them in an afternoon

Record twenty minutes with three people, one of whom talks over the others twice and one of whom is on a laptop microphone. Run it through VibeVoice-ASR-Streaming 1.5B with the hotword list populated with the three names, because that is the mechanism the model provides for exactly this. Run the same file through Ming-3.0-audio-tiny using the validated prompt that asks for the language label, a tab, then the transcription — and then ask it, in a second turn, to attribute each sentence.

Score four things: how many speaker changes the first model got right, whether any speaker label flipped mid-recording, whether the second model's attribution was stable across the file, and which output you could correct faster by hand. The last one is not a benchmark and will predict your production experience better than either vendor's figures.

And keep the dashes in mind while you do it. A vendor that publishes a dialect table to two decimal places and leaves five diarization cells blank has told you something specific about where its confidence ends. Microsoft, for its part, has published a figure instead of a table and left you to read the picture. Neither has given you a number a stranger checked.

Where each one actually belongs

Live captions, call-centre monitoring, meeting assistants that need a name beside each line: VibeVoice-ASR-Streaming 1.5B is built for that shape, and at 5.63 GB it runs on hardware you probably already have. Compliance review of an archive, "find every mention of the settlement across these forty recordings", anything where the question comes after the audio rather than during it: Ming-3.0-audio-tiny's single large window and its comprehension scores are the better fit, and the missing diarization rows stop mattering if nobody asked who spoke.

The mistake would be to pick Ming for a streaming job because 131,072 is twice 64,000, or to pick VibeVoice for a reasoning job because 1.5B sounds cheaper than 9.3B. Both numbers describe something other than what the sentence assumes, which is the most reliable thing this comparison has established.