Ming-3.0-audio-tiny vs Voxtral 4B TTS: One Is a Listener With a Voice Attached, the Other Sells Nothing Else

If you want to generate speech and nothing else, this matchup should take about thirty seconds. Voxtral 4B T​TS is a text-to-speech model: text in, 24 kHz audio out, twenty preset voices, nine languages, a published latency table, and licence terms that stop you selling the result. Ming-3.0-audio-tiny is an audio-language model that happens to include a speech generator — a 1.4 GB Talker bolted onto a 17.74 GB Thinker, with three named voices and a cloning path, sitting inside a repository whose evaluation section never once measures synthesis. If speech is the product, the comparison is over before it starts. 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.

The interesting version of the question is the other one: you are building something that has to understand audio and speak back, and you are deciding whether to buy one model that does both or wire a listener to a dedicated voice. That is where the thirty seconds become an afternoon, because the two options fail in different places and only one of them comes with a number you can plan against.

The licence decides more than the benchmark

Start with the thing that no amount of evaluation can fix. Voxtral 4B T​TS is CC BY-NC 4.0 — non-commercial — inherited from the reference-voice datasets the model was built with: EARS, CML-T​TS, IndicVoices-R and an Arabic natural-audio set. Mistral states this plainly on the card and points commercial users at its API. So the weights are open for research and personal use, and the commercial route is a rate card rather than a download.

Ming-3.0-audio-tiny is MIT in the card's metadata and in the LICENSE of the GitHub repository it points at. Worth knowing: the Hugging Face repository itself contains no LICENSE file, and the two bundled reference voices carry no separate terms of their own. MIT is a genuinely permissive claim here, but it is a claim in metadata rather than a file in the artefact, and procurement will notice.

• Commercial use — Ming: yes, MIT, weights and code. Voxtral: not from the weights; the vendor API is the sanctioned path.

• Voices included — Ming: three named, two of them shipped as reference WAVs with transcripts. Voxtral: twenty presets.

• Languages — Ming: Chinese and English for the model overall, with no separate Talker language list. Voxtral: English, French, Spanish, German, Italian, Portuguese, Dutch, Arabic and Hindi.

• Output — Ming: whatever the Talker produces; the card specifies neither sample rate nor container. Voxtral: 24 kHz, WAV, PCM, FLAC, MP3, AAC or Opus.

• What you run — Ming: the Thinker, 17.74 GB, plus a 1.4 GB Talker and 1.6 GB VAE on a second device. Voxtral: one BF16 checkpoint on a single GPU with at least 16 GB.

• Published speech quality — Ming: none. Voxtral: none either, but a latency and throughput table instead, which is more than nothing.

That last row is the honest summary of this comparison's evidentiary base. Neither vendor has published a naturalness score, a speaker-similarity figure, or a word error rate on synthesised speech. Mistral has published how fast it goes; inclusionAI has published how well the model listens. Nobody has published how good either one sounds.

What Mistral's numbers actually say

The Voxtral table is a serving benchmark, and reading it correctly matters. Measured on a single NVIDIA H200 with vLLM-Omni 0.18.0, a 500-character input and a ten-second reference clip:

• Concurrency 1 — 70 ms latency, real-time factor 0.103, about 119 characters per second per GPU.

• Concurrency 16 — 331 ms, RTF 0.237, about 879 characters per second.

• Concurrency 32 — 552 ms, RTF 0.302, about 1,431 characters per second.

Two things follow. First, RTF rises with concurrency — 0.103 to 0.302 — so the throughput gain from batching is real but sublinear; you get roughly twelve times the characters for about eight times the real-time factor. Second, 70 ms to first audio at concurrency 1 is the number that decides whether a voice agent feels alive, and it is a number Ming-3.0-audio-tiny does not have. Not a worse one. None.

Mistral labels all of this unreproduced and vendor-run, which it is. But it is at least a claim with a method attached: named hardware, named runtime version, named input length, named reference length. You could rebuild the harness.

The thing Ming's speech path cannot answer

The tiny model's speech output is described in the card in three sentences: built-in voices or a reference voice, three named voices, cloning from a reference clip plus its exact transcript. The deployment guide adds the operational detail — the Talker runs as a second stage at 0.18 of a second card, capped at one output token with temperature 0.0 because it is not generating text.

Nowhere in the repository is there a sample rate for the synthesised output, a naturalness measure, a similarity measure to the reference clip, or a statement about whether the three voices are the same voice in different registers or genuinely different speakers. The evaluation images cover recognition, audio intelligence and text. Speech generation is the one capability the vendor advertises in its highlights and does not evaluate at all.

That is not a scandal, but it is a planning constraint. With Voxtral you can size a deployment before you hear it: one card, 16 GB, 119 characters per second at concurrency 1, and a rate card for the commercial path. With Ming you size the hardware (two cards, the second at 0.18 utilisation) and then find out about the voice by generating something.

When the combined model is the right answer anyway

There is a real case for the Talker, and it is not "cheaper T​TS". It is that the same model heard the audio and is now speaking about it. Ming-3.0-audio-tiny accepts audio plus a text instruction and returns text, or text plus speech. A question about a recording, answered out loud, in one pass, with no transcript serialised into a second model. No "the ASR said 'their', the T​TS read it wrong" failure, because there is no second model and no intermediate text to corrupt.

That matters for spoken question answering, for an assistant that listens to a room and replies, and for anything where the answer is a sentence about something it just heard. It does not matter for narration, audiobooks, dubbing or any workload where the text came from somewhere else — and those are exactly the workloads Voxtral was built for, with twenty voices and nine languages against Ming's three and two.

• Same-model continuity — Ming: yes, one forward pass from audio to speech. Voxtral: text in, so the listening half must come from somewhere else.

• Voice variety — Ming: three named plus cloning. Voxtral: twenty presets plus reference-voice adaptation.

• Streaming — Ming: not offered; the Talker is a stage, not a stream. Voxtral: the card advertises streaming and batch inference, and the vendor's own API demo is the reference implementation.

• Multilingual speech — Ming: Chinese and English. Voxtral: nine languages, with dialects noted.

• Cost shape — Ming: fixed hardware, two cards, no per-character meter. Voxtral: weights free for non-commercial use, API priced per character for everything else.

What a router adds to a voice product, and what it does not

OrcaRouter serves neither of these. Ming-3.0-audio-tiny is a checkpoint you run and Voxtral 4B T​TS is reachable through Mistral's own API; neither is in our catalogue, and this piece is not an offer to host either. The router's place in a voice product is the text that surrounds the voice: generating the script, translating it into the nine languages Voxtral supports, writing the summary of what the caller said, deciding whether a segment needs a human. Those are ordinary text calls — more than 200 text models behind one key at provider list price with 0% markup added, with automatic failover so a batch of ten thousand clips does not stall because one upstream had a bad afternoon.

That is a real saving in a dubbing pipeline and a rounding error in a single-model demo. It also does not touch the question this article is about, which is whether the voice is any good.

How to choose without hearing either one first

If the product is speech, choose Voxtral and budget for the licence: run the non-commercial weights to evaluate, then move to the API for anything you ship, at whatever the current per-character rate is. You get a latency table, twenty voices, nine languages and a runtime that has been tested with vLLM-Omni. You give up the right to self-host commercially, which for many teams is the actual decision.

If the product is understanding that occasionally speaks, choose Ming-3.0-audio-tiny, budget two GPUs, and treat the Talker as an unmeasured feature — build the fallback first. Generate twenty sentences across all three voices, listen, and keep the option of swapping in a dedicated T​TS model later. The architecture supports that swap cleanly because the Thinker returns text anyway; the Talker is an attachment, not the spine.

And in both cases, write down what you measured. Neither vendor has, and the first team to publish a naturalness or similarity figure for either model will be doing the field a favour — including the vendors.

The thirty-second answer, revised

The short version at the top of this piece said the comparison was over in thirty seconds. It is over in thirty seconds if speech is your product and you are willing to pay for a licence. It takes longer if you are building something that listens and then talks, because the two options are not substitutes: one is a voice with no ears, the other is ears with a voice that has never been graded. The thirty seconds gets you to the question. The rest of the piece is the part where you find out which of those you actually need.