Ming-3.0-tts-tiny vs VoxCPM2: Two Checkpoints, One of Which Publishes Its Speed

This is the only comparison in the Ming-3.0-tts-tiny series where both sides can actually be run, and that changes what the argument is about. Ming-3.0-tts-tiny, from Ant Group's inclusionAI, is a 7.9-billion-parameter mixture of experts activating about 1.3 billion per token, MIT-licensed, roughly 18 GB on disk, with an H800 named as the recommended card. VoxCPM2, from OpenBMB, is a 2-billion-parameter tokenizer-free model on a MiniCPM-4 backbone, Apache 2.0, about 8 GB at bfloat16, released in April 2026. Neither has a leaderboard row. Neither has a hosted price. When two models are both downloadable and both unscored, the comparison stops being about preference and becomes about arithmetic: hours of audio per GPU-hour, memory per process, and whether you can fine-tune the thing without writing the training code yourself. 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 release histories are worth stating plainly because they explain the maturity gap. VoxCPM2 has been public since April, has accumulated about 847,000 downloads in the last month, and ships training scripts alongside inference. Ming-3.0-tts-tiny's repository was created on September 22, 2026, the weights landed on September 24, and the code to run them did not exist publicly until October 19 at 08:58 UTC, when nine commits arrived in one afternoon. Ant has not announced the model. There is no technical report; the roadmap lists it as an unchecked box, and the model card was edited on October 16 specifically to remove a reference to one. So one of these is a five-month-old project with a user base and the other is a pipeline that is, as of this writing, a week old.

The number one of them publishes and the other does not

VoxCPM2's card quotes a real-time factor of about 0.30 in standard PyTorch on an RTX 4090, falling to roughly 0.13 under Nano-VLLM. Real-time factor is seconds of compute per second of audio, so those two figures mean one GPU-hour buys about 3.3 hours of finished speech in the first case and about 7.7 in the second.

Ming-3.0-tts-tiny publishes no throughput at all. Not a real-time factor, not characters per second, nothing measured on a card. What the release does give you is the environment it was validated in — Python 3.10.15, torch and torchaudio 2.7.1 with CUDA 11.8, transformers pinned to 4.46.3, an H800, and a preflight script that checks your install before you waste a run — plus the architecture: 8,980,964,372 parameters in BF16, 40,096 in F32, a 7.9B-total expert stack with roughly 1.3B active per token.

You cannot borrow the 0.5B sibling's throughput to fill the gap. That model was measured at 42.1 characters per second on an independent harness and occupies 2.96 GB; the tiny model activates about two and a half times as many parameters per token and occupies roughly six times the disk. Sparse routing buys back some of the cost of the larger total, which is the entire point of the architecture, but nobody outside Ant has put a number on how much.

Doing the cost calculation with a hole in it

Because one side publishes its speed and the other does not, the honest version of this comparison is a range rather than a figure. Here is the shape of it.

• VoxCPM2 on an RTX 4090, PyTorch — 0.30 RTF, so 3.3 hours of audio per GPU-hour. A million characters of narration, at a rough 15 characters per second of speech, is about 18.5 hours of finished audio, or roughly 5.6 GPU-hours.

• VoxCPM2 on the same card, Nano-VLLM — 0.13 RTF, so 7.7 hours per GPU-hour, or roughly 2.4 GPU-hours for the same million characters. The serving stack more than doubles output without touching the weights.

• Ming-3.0-tts-tiny — unknown. At a hypothetical 20 characters per second it would need about 14 hours of generation; at 10 characters per second, about 28. Neither number is a measurement and both should be treated as placeholders until someone publishes one.

• Memory — VoxCPM2 quotes about 8 GB at bf16, which fits a 24 GB consumer card with room for batching. Ming-3.0-tts-tiny's 18 GB of weights plus activations and the audio decoder means an 80 GB H800 is the sensible target and a 24 GB card is not.

• Sequence limit — VoxCPM2 caps at 8,192 tokens, which is a real constraint on long-form work and worth checking against your longest paragraph before you commit. Ming-3.0-tts-tiny publishes no equivalent limit; its long-form path is the podcast task, which takes a script rather than a single utterance.

The conclusion that survives the missing number is about utilisation rather than speed. A card that sits idle loses to every hosted API at any price, and a card you already own and keep busy wins on marginal cost no matter which of these two you run. The gap between 0.30 and 0.13 RTF is a factor of 2.3 in cost per hour of audio, which is larger than most teams expect from a serving-stack change and larger than the difference in parameter counts would suggest.

Fine-tuning is where the two stop being comparable

VoxCPM2 documents both full supervised fine-tuning and LoRA on as little as five to ten minutes of audio, with a training script and a configuration for each. That is not a footnote; it is the difference between a model you rent the behaviour of and a model whose behaviour you own.

Ming-3.0-tts-tiny documents inference, not training. The repository is a task cookbook — seed-voice cloning, multilingual, paralinguistic, podcast, basic attributes, emotion, dialect, free-form, voice design, and an "ip" task — wrapped around a single MingTinyTTS.from_pretrained entry point. There is no LoRA recipe, no SFT configuration, and no statement about whether fine-tuning is supported at all. It may well be possible; the checkpoint is a checkpoint. But "possible" and "documented with a working script" are different amounts of engineering, and the second one is what VoxCPM2 ships.

For a brand voice, a regulated domain, or a language neither model handles well out of the box, that is the deciding asymmetry. Five minutes of reference audio and a supplied config is a week of work. Reverse-engineering a training path for a sparse 7.9B model with no reference implementation is a quarter.

Languages, dialects and what "30 languages" buys

• Ming-3.0-tts-tiny — Chinese, English, German, Spanish, French, Korean and Japanese, plus Sichuanese and Cantonese when you supply a reference clip in the dialect. Nine in total if you count the two dialects.

• VoxCPM2 — 30 languages including Cantonese and Sichuanese, and the card notes no language tag is required: you give it text and it infers the language. That is a convenience with a failure mode, since mixed-language text will be resolved by the model rather than by you.

On the languages they share, only one side has published per-language error rates, and it is Ant. German 0.325% character error, Spanish 0.971%, Japanese 3.427%, French 3.470%, Korean 6.000%, all on Ant's own harness, all unreproduced. VoxCPM2 publishes no per-language table, so the breadth advantage cannot be checked against the depth claim. Anyone quoting a winner on language quality here is quoting one vendor's spreadsheet against another vendor's silence.

The Korean figure deserves its own sentence, because it is the clearest defect in Ming-3.0-tts-tiny's record: 6.000% character error, roughly three and a half times the 1.728% its own 0.5B sibling posts on the same language. The card lists Korean among the known weaknesses and offers no mechanism. A sparse-routing explanation is plausible and unmeasured.

The licence question, where the gap is smaller than it looks

Both are permissive for commercial use, which is unusual in this field and worth saying plainly. Ming-3.0-tts-tiny is MIT for weights and code, with a usage note asking you not to impersonate people without consent and to label synthetic audio — a request in the documentation rather than a condition of the grant. VoxCPM2 is Apache 2.0, explicitly free for commercial use, with its own acceptable-use language.

Neither licence forces a legal review that ends the project, and neither has the hosted-service carve-out that makes some open-weight speech releases unusable in production. For a self-hosted deployment the two are close enough that the licence should not be the tiebreaker; the training story, the memory footprint and the speed should be.

Neither of them is on the board, and one number gets borrowed anyway

Artificial Analysis lists a Ming-3.0-tts entry at 1,188 Elo on Provider Voice and 1,069 on Controlled Voice. That is the 0.5B model. Ming-3.0-tts-tiny has no arena row — not ranked, not unranked, not a preview entry — and the GitHub README reproduces the 1,188 and 1,069 figures without saying which checkpoint produced them.

VoxCPM2 has no row at all, on either board, and its Hugging Face page notes that no inference provider deploys it. That absence is not a low score. It means no one has put either of these models in front of a preference panel, so the only quality evidence in this comparison is Ant's own suite on one side and nothing on the other.

If you need a number before you start, the useful substitute is the one VoxCPM2 does publish: real-time factor. It is not a quality metric, but it is measured, it is reproducible on your own card, and it tells you what the model costs to operate. Ming-3.0-tts-tiny's equivalent is a range you will have to produce yourself.

What each one is actually for

Choose VoxCPM2 when the workload is long-form and cost-sensitive, when you need a language outside Ant's nine, when 8 GB of VRAM matters because your deployment is a single consumer card, or when a LoRA on your own five minutes of audio is on the roadmap. The tokenizer-free design and the 48 kHz output through AudioVAE V2's built-in super-resolution are real engineering advantages, and the five months of public use mean the failure modes are documented by strangers rather than by the vendor.

Choose Ming-3.0-tts-tiny when you need the things only it offers: a multi-speaker podcast task in a single pass, 14 inline paralinguistic tags with explicit emotion, speed, pitch and volume controls, a 100-plus Chinese voice cast with five English voices, and a Chinese-first model whose dialect handling was built rather than inferred. Accept in exchange that you will be the first team to benchmark it, that Korean is a published weakness, that fine-tuning is undocumented, and that the whole release is a week old.

OrcaRouter does not route either model, and this piece should not be read as suggesting otherwise — both are reached by downloading them and running them yourself. What sits in the catalogue is the text half of the same pipeline: more than 200 models behind one key at provider list price with no markup added, so a vendor price change reaches you the same day, with automatic failover across providers for the model that writes the script or drives the agent. With both speech options self-hosted and neither carrying a per-character bill, the recurring cost you can actually compare month to month is the text layer, and that is the one worth putting behind a single endpoint.

The comparison ends where it started: two checkpoints, no shared scoreboard, and a decision that comes down to whether you need speed and fine-tuning on modest hardware or Chinese-first control on a large one. VoxCPM2 answers the first with published numbers. Ming-3.0-tts-tiny answers the second with a task cookbook and no throughput figure, which is the single most useful thing Ant could publish next.