VoxCPM2: 900,000 Downloads a Month, and Transformers Still Can't Load It

Hugging Face's metadata for VoxCPM2 lists its library as voxcpm — not transformers. That single field explains a strange gap in the open-source speech world right now: OpenBMB's 2B-parameter text-to-speech model pulled 900,282 downloads in the last thirty days, spawned 25 public finetunes, 10 quantizations, 7 adapters and over 100 Spaces, and still cannot be loaded by the library almost every other model on that site loads with. The pull request to fix that was opened on 4 August 2026 and is still open as of today.

That gap is worth understanding before the fix lands, because it shapes what integrating this model costs you this week versus next quarter. And it sits on top of a more interesting question, which is whether VoxCPM2 is actually as far ahead as the coverage suggests. Everything below is read off three primary sources: the openbmb/VoxCPM2 model card and repository metadata, the OpenBMB/VoxCPM GitHub README, and the VoxCPM2 Technical Report (arXiv:2606.06928, submitted 5 June 2026). Every benchmark figure in this article is OpenBMB's own, run by OpenBMB, and — as the paper itself states for its main comparison table — the competing numbers in it were copied from other papers rather than re-run on matched conditions. As far as we can find, no independent lab has published a reproduction of any of it.

The spec sheet, in one screen

VoxCPM2 was released in April 2026 (the Hugging Face repository was created 3 April, last touched 16 April) as the third generation of the VoxCPM line. Against its immediate predecessor:

• Size — 2B parameters vs VoxCPM1.5's 0.8B and VoxCPM-0.5B's 0.6B backbone.

• Languages — 30 plus 9 Chinese dialects, vs Chinese and English only in both earlier versions.

• Audio — accepts a 16 kHz reference, emits 48 kHz, vs VoxCPM1.5's symmetric 44.1 kHz in and out.

• Backbone — MiniCPM-4-1B (28 layers, width 2048) as the text-semantic language model, up from MiniCPM-4-0.5B (24 layers, width 1024).

• Sequence budget — 8192 tokens at a 6.25 Hz language-model-side token rate, which works out to roughly 20 minutes of audio in one context.

• Cost of a second of speech — real-time factor 0.30 in plain PyTorch and 0.13 through Nano-vLLM on one RTX 4090, at about 8 GB of VRAM. VoxCPM1.5 managed 0.15 at 0.8B and 6 GB.

• Licence — Apache-2.0 on the weights, the finetuning code and the inference tooling. No gate, no acceptable-use rider, commercial use permitted.

• Training data — "over 2 million hours" of multilingual speech, with no corpus named and no provenance statement.

Read the RTF line twice, because it runs the wrong way. VoxCPM2 is roughly twice as slow per second of generated audio as the 0.8B model it replaces, and needs a third more VRAM. The 2B did not buy throughput; it bought languages and control, and it charged latency for them. If you are running a real-time agent, that trade is the first thing to price.

What PR #47756 actually changes

Today, running VoxCPM2 means installing OpenBMB's own package — pip install voxcpm, Python 3.10 to 3.12, PyTorch 2.5 or newer, CUDA 12 or newer — and loading the model through a VoxCPM.from_pretrained call that has nothing to do with the Transformers API. Everything downstream of that decision is bespoke: your own batching, your own serving glue, your own handling of the five generation modes.

The in-flight work would change that. Issue #47695, "Add native support for OpenBMB VoxCPM2," was filed on 31 July. PR #47756, "support for VoxCPM2," followed on 4 August and was last updated on 5 August. It carries the "New model" label and adds a modular config and modeling implementation, a custom tokenizer and processor, AudioVAE encode and decode with streaming, reference-voice conditioning, prompt-audio continuation, auto-class registrations and a text-to-waveform pipeline entry — with 64 model tests reported passing. It is stacked on PR #47736, which adds MiniCPM4 itself; the text backbone has to land before the speech model that wraps it can.

Two details deserve weight, and both cut against optimism. First, all three items — the issue and both pull requests — were opened by the same individual community contributor, not by OpenBMB and not by a Hugging Face maintainer. There is no vendor commitment behind this and therefore no timeline you can plan against. Second, a two-PR stack with 203 commits touching a new modality is not a fast review. New-model PRs in Transformers routinely take weeks of maintainer round-trips, and this one has four comments on it so far.

The practical reading: if a native Transformers class is load-bearing for your architecture — because you standardise on AutoModel, or because your serving layer only speaks Transformers — VoxCPM2 is not ready for you, and no date exists. If you can live inside the voxcpm package, the model is fully usable today, and the ecosystem has clearly voted that this is tolerable: 900,282 downloads happened without native support existing at all. There is also a middle path that most coverage misses. OpenBMB ships a vLLM-Omni integration exposing an OpenAI-compatible /v1/audio/speech endpoint, plus a llama.cpp-omni build with GGUF weights that runs on CPU, Metal, CUDA or Vulkan with no Python dependency at all. If what you actually wanted from Transformers was a standard serving surface rather than the class itself, that already exists.

"Tokenizer-free" does not mean unquantized

The phrase in every headline about this model is the one most often misread. VoxCPM2 has no external discrete audio codec — there is no learned vocabulary of speech tokens sitting between the language model and the waveform, the way there is in the CosyVoice or Moshi lineages. That is the claim, and it is true.

There is still quantization inside the model. The backbone runs a differentiable semi-discrete bottleneck based on Finite Scalar Quantization, and the paper is explicit about its role: the text-semantic language model produces hidden states, FSQ scalar-quantizes them per dimension into a "semantic skeleton," a residual acoustic language model recovers the fine detail FSQ discarded, and a local diffusion transformer turns both conditioning streams into the next continuous latent patch by flow matching. The four stages you see abbreviated as LocEnc, TSLM, RALM and LocDiT are exactly that chain.

The distinction that matters in practice is not "quantized versus not." It is that the bottleneck is trained end-to-end with everything around it, rather than frozen in advance as a separate codec with its own loss. That is what removes the usual failure mode where a language model learns to predict tokens a codec cannot faithfully decode. VoxCPM2 widened that FSQ bottleneck from 256 to 512 dimensions and replaced the old element-wise sum feeding the residual model with a learnable concatenation-projection — small changes, and among the few in the report backed by a stated mechanism rather than a benchmark delta.

The 48 kHz output is partly invented, and that is the design

"48 kHz studio-quality output" is the model's most quotable spec and its most widely misunderstood one. AudioVAE V2 is asymmetric: the encoder operates at 16 kHz, the decoder reconstructs at 48 kHz. The paper calls this "implicit super-resolution," which is an honest name for what it is.

Follow the consequence. A 16 kHz encoder has an 8 kHz Nyquist ceiling, so nothing above 8 kHz in your reference audio ever reaches the model. Every bit of energy in the top two octaves of the output — the air in a voice, sibilance, cymbal-edge brightness — is generated by the decoder from a plausible prior, not carried over from the speaker you cloned. For most narration and agent work this is invisible or an improvement, because a good learned prior beats a hard 8 kHz shelf. For anyone whose job is fidelity to a specific recorded voice, it is a fact to design around, and it is not something a listening test on your laptop speakers will reveal.

The paper's justification is the most credible engineering argument in the report, and worth restating because it is not marketing: keeping the encoder at 16 kHz lets OpenBMB reuse the original VoxCPM 16 kHz training corpus wholesale, eliminates latent mismatch between sources recorded at different sample rates, and avoids the sequence-length explosion a higher input rate would force on an autoregressive loop. Lifting only the decoder buys output fidelity without paying for it in the expensive part of the model. That is a good trade, made deliberately. It also means VoxCPM1.5 users are moving from a 44.1 kHz encoder to a 16 kHz one — an input-side downgrade sold inside an output-side upgrade. OpenBMB's own reconstruction table shows the shape of that: VoxCPM1.5's codec still posts the best full-band mel-distance of the three generations, 1.139 against AudioVAE V2's 1.335, because it operates natively at a high sample rate instead of reconstructing up to one.

Reading OpenBMB's scoreboard the way OpenBMB wrote it

Competitive, not first

On Seed-TTS-Eval, the standard zero-shot voice cloning benchmark, VoxCPM2 reports 1.84% word error rate with 75.3% speaker similarity on the English set, 0.97% character error rate with 79.5% similarity on Chinese, and 8.13% CER with 75.3% similarity on the hard Chinese subset. The paper's own word for this is "competitive," and the table supports that word rather than the stronger ones circulating.

Among open-source systems in that same table, Fish Audio S2 posts a better error rate on all three subsets (0.99 / 0.54 / 5.99). Qwen3-TTS beats it on English WER at 1.23. And LongCat-Audio-DiT sweeps it outright on five of six cells — 1.50 WER and 78.6 similarity on English, 81.8 similarity on Chinese, 6.04 CER and 79.7 similarity on hard Chinese. Where VoxCPM2 does stand out is the balance: it is one of very few systems that is simultaneously near the top on similarity and respectable on intelligibility, and it is the only one on that list that also does natural-language voice design. But "state-of-the-art" is not what its own headline table shows, and the honest framing is that this is a strong generalist, not a benchmark leader.

3.3x the parameters bought almost no intelligibility

The most useful row in that table is the one nobody quotes. VoxCPM-0.5B, the 0.6B first generation from September 2025, scores 1.85% English WER and 0.93% Chinese CER. VoxCPM2, at 2B, scores 1.84% and 0.97%. Within noise on English, and slightly worse on Chinese.

What the extra parameters actually delivered is visible in the similarity columns and nowhere else: English SIM rose from 72.9 to 75.3, Chinese from 77.2 to 79.5. Everything else the 2B bought is off this benchmark entirely — 28 more languages, voice design from a text description, style-controllable cloning, 48 kHz output. That is a lot, and it is the honest case for the upgrade. But if your workload is English or Chinese cloning and you are choosing on error rate, VoxCPM2 gives you nothing the 0.6B model did not already give you, at three times the weights and twice the latency. Curiously, VoxCPM1.5 is the worst of the three on this benchmark (2.12 / 1.18), which makes the family's progression look less like a ladder and more like three different products.

One model, two evaluations, an order of magnitude apart

Here is where care is required, because the two multilingual results in this report disagree violently and both are quoted as if they settle the matter.

The headline is an average error rate of 1.68% across 30 languages. That comes from a test set OpenBMB built itself — 500 utterances per language — and graded with Gemini 3.1 Flash Lite as the recogniser. On it, VoxCPM2 posts English 0.42, Chinese 0.92, Hindi 0.79, Arabic 1.23.

The report also runs MiniMax-MLS-Test, a third-party 24-language set scored with Whisper-large-v3. Same model. There, VoxCPM2 posts Hindi 19.70 and Arabic 13.05 — twenty-five times and ten times worse respectively than its own benchmark says, on languages it officially supports. Also in that column: Cantonese 38.58, Czech 24.13, Romanian 21.58, Ukrainian 6.32.

Three things reconcile most of this, and they are worth separating because the widely-shared version of this story gets them wrong:

• Czech, Romanian and Ukrainian are not supported languages. Check the repository's own language tags: 30 codes, and none of them is cs, ro or uk. Criticising VoxCPM2 for 24% Czech WER is criticising it for a language it never claimed. Cantonese plausibly falls under the "9 Chinese dialects," but every system in that column is above 30% on it, which points at the recogniser rather than any of the models.

• Arabic and Hindi are supported, and are the real finding. These are the two languages where OpenBMB claims coverage and its two evaluations differ by an order of magnitude. The paper's own explanation is that these languages have "relatively limited data volume" in the training corpus and that "part of the higher WER may stem from the recogniser's limited accuracy." That is a fair hypothesis and an untested one. If you are shipping Arabic or Hindi speech, the published range for this model is 0.79% to 19.70% and neither end is independently verified. Budget a day of your own measurement; do not budget on either number.

• The metrics are not even the same unit. Hindi is scored as character error rate on the internal set and word error rate on MiniMax-MLS. Those are not comparable quantities, which is one more reason the 25x gap is not a clean indictment — and one more reason the 1.68% average should not be read as a like-for-like score.

The same caution applies to the claim doing the most numerical work in coverage of this model: that VoxCPM2 beats ElevenLabs on speaker similarity, 85.4% to 61.3% on English, winning 22 of 24 languages. That is genuinely what the table says. It is also a table the paper assembles partly from previously reported results, and one where ElevenLabs' intelligibility column contains 73.94% WER on Thai, 73.42% on Vietnamese and 16.03% on Chinese. Those are not the numbers of a functioning commercial product; they are the signature of a scoring or configuration mismatch. A table that broken in one column does not become trustworthy in another because the result flatters the model you are reading about.

Five modes from one backbone — and the recipe that moves your numbers

The cleanest idea in the architecture is that VoxCPM2 does not have separate models or heads for its capabilities. All five modes are the same parameters with the input sequence arranged differently, which is why a single 2B checkpoint covers what usually takes a small fleet:

• Basic TTS — text in, audio out.

• Voice design — a parenthesised description is simply prepended to the text, so "(a tired middle-aged man, gravelly, speaking slowly)" and the line itself go through the same language model with no extra module. No reference audio at all.

• Reference cloning — an isolated reference clip conditions speaker identity, with no transcript required.

• Controllable cloning — reference clip plus a style description, so you can clone a voice and then ask it to sound rushed or amused.

• Continuation cloning — reference clip paired with its transcript, treated as an audio prefix the model continues, which is the highest-fidelity mode.

Buried in the report is a knob most write-ups skip, and it is the one most likely to change your results. The two conditioning pathways — isolated reference and continuation prefix — can be used separately or together, and they trade against each other. In OpenBMB's own ablation, using both together gives the best speaker similarity on every subset. Dropping the continuation prefix and passing only the isolated reference gives the best intelligibility on hard Chinese text, 6.85% CER against 7.44%, while giving up about five points of similarity. The paper's explanation is sensible: without a temporal audio prefix pinning the prosody, the model has more freedom to choose a delivery that survives difficult text.

So the default is a choice, not a ceiling. Voice-matching work wants both pathways; hard or unusual text wants reference-only. One honest wrinkle: the absolute figures in that ablation table do not reconcile with the headline table for the recipe the paper says it used throughout, which in a preprint is more likely a bookkeeping slip than anything sinister — but it is a third reason to treat every number here as a direction to test rather than a value to quote.

Voice design: more obedient than it is natural

Voice design is the feature that makes this release interesting rather than incremental, and it is the one where the vendor's own numbers are most revealing about a real trade-off.

On InstructTTSEval, VoxCPM2 scores 84.2 on acoustic-parameter specification, 83.2 on descriptive-style directives and 71.4 on role-play for English — that last figure the best in the table, ahead of Qwen3-TTS-1.7B-VD at 68.4 and Gemini-TTS-Pro at 67.2. On Chinese it is weaker and the ordering flips: 85.2 / 71.5 / 60.8, against Gemini-TTS-Pro's 89.0 / 90.1 / 75.5. So the strongest claim available is that VoxCPM2 leads on English role-play and is behind a closed frontier system nearly everywhere else in instruction-following.

The human listening panel — 50 listeners, randomised and double-blind, per the report — sharpens it. On controllable generation, VoxCPM2 takes instruction-following at 4.50 against Qwen3-TTS-VD's 4.41, and loses naturalness at 4.48 against 4.61. On plain zero-shot cloning it wins speaker similarity (4.74 against 4.69) and ties or trails on naturalness (4.78 against Qwen3-TTS's 4.80, confidence intervals overlapping).

The pattern is consistent enough to plan around: VoxCPM2 does what you tell it and sounds slightly less human doing it, while Qwen3-TTS sounds slightly better and follows instructions slightly less closely. Which one is right depends entirely on whether your product's value is precise control or effortless delivery. OpenBMB flags the corollary itself in its limitations, and it is the sort of thing vendors usually leave out: voice design and controllable cloning "may produce variable results between runs," and getting the voice you want can take several attempts. Build a retry into your pipeline and, if the voice matters, a human listening gate.

What it costs to run, and when renting is the right call

There is no hosted VoxCPM2 anywhere. Hugging Face's own sidebar states it plainly — "This model isn't deployed by any Inference Provider" — and that includes us: OrcaRouter does not serve VoxCPM2, and no amount of wanting to changes that a 2B TTS model with no inference partner is weights you host or nothing.

Which makes the cost question a GPU question, and the arithmetic is clean. At the Nano-vLLM real-time factor of 0.13 on a single RTX 4090, one GPU-hour produces roughly 7.7 hours of audio, so your cost per audio-hour is your hourly rate for one 24 GB card divided by about 7.7. In plain PyTorch at RTF 0.30 that falls to about 3.3 hours of audio per GPU-hour. Both figures are OpenBMB's, measured on their hardware with their text, and both will move on yours — batch size, text difficulty and how many retries your quality gate forces are all multipliers the RTF number does not contain. The retry rate is the one people forget: a model the vendor tells you may need several attempts to hit a target voice does not cost what its RTF implies.

The comparison people want at this point is against a rented API, and the honest answer is that the two do not convert cleanly. openai/tts-1-hd bills at $30.00 per million tokens in and out — that is the provider's list price passed straight through on OrcaRouter, since we take 0% markup, so the number on our model page is the number OpenAI charges. But tokens are not seconds, and no published rate converts one to the other reliably enough to build a spreadsheet on. Anyone showing you a clean per-hour comparison between a self-hosted open-weights TTS model and a token-billed API has made an assumption they did not show you.

What is worth saying is where the line falls architecturally. Self-hosting VoxCPM2 makes sense when you need a specific cloned voice, when audio volume is steady enough to keep a GPU busy, when data cannot leave your infrastructure, or when you intend to LoRA-finetune it — and it supports that on 5 to 10 minutes of target audio, which is genuinely cheap. Renting makes sense when volume is spiky, when you cannot staff a GPU, or when the voice is interchangeable. Most real voice products are two systems, not one: a synthesis layer and a language model doing the reasoning between the ears. The reasoning half is the part worth putting behind one key with automatic failover across providers, so that a model swap is a string change rather than a procurement cycle; that is the shape OrcaRouter is for, across 200+ models. The synthesis half, when it is a specific voice you own and finetune, belongs on your own hardware. VoxCPM2 is squarely in that second category, and the fact that nobody serves it is a consequence of what it is rather than an oversight.

What OpenBMB tells you not to expect

The limitations section is unusually candid for a release with this much momentum, and it is short enough to take seriously:

• Cloning quality is a misuse surface. The card says so directly: the model produces speech realistic enough for impersonation and fraud, and AI-generated audio should be labelled. Apache-2.0 puts no restriction on this whatsoever — unlike the licences on several competing open-weight voice models, there is no acceptable-use clause to hide behind. Your consent and disclosure policy is your own to write.

• Run-to-run variance is expected on the two control features, not a bug to file.

• The 30 languages are a real boundary. Anything outside them may work and is untested; expect to finetune.

• Style-control consistency is described as still under development by the people who built it.

And the gaps the card does not name: no training-corpus disclosure at all, so an Apache-2.0 licence on the weights settles the code question and nothing about data provenance. No independent evaluation of any figure in this article. No published latency in milliseconds — RTF is a throughput ratio, and a voice agent lives or dies on time-to-first-audio, which appears nowhere in the report.

Three questions the model card doesn't settle

Should I move off VoxCPM1.5 or VoxCPM-0.5B?

Only for the new capabilities, and only after measuring. If you need languages beyond Chinese and English, voice design, or style-controllable cloning, the upgrade is the whole point and there is no alternative within the family. If you are running English or Chinese cloning today and are happy, the case is weak on its face: the same benchmark shows VoxCPM-0.5B matching VoxCPM2 on error rate, and you would be paying twice the latency and a third more VRAM for about 2.4 points of speaker similarity. There is also a migration detail that is easy to miss — if you were feeding VoxCPM1.5 44.1 kHz reference audio, VoxCPM2's encoder takes 16 kHz, so your reference pipeline changes and the top of your source material stops mattering.

Can I actually ship a commercial voice product on this?

Legally, the licence is about as permissive as they come: Apache-2.0, no gate, no use restrictions, commercial use explicitly permitted, weights and finetuning code both covered. The open question is not the licence text but what is missing behind it. OpenBMB names no training corpus, which means nobody can tell you whose voices are in the 2 million hours. For a model whose headline feature is reproducing a specific person's voice, that is a question for your own counsel and not for a model card — and it is the same question every open-weight voice model currently ducks. Practically, the harder blockers are operational: no native Transformers class yet, no hosted endpoint anywhere, run-to-run variance on the control features, and no time-to-first-audio figure if you are building anything conversational.

Is it good enough to replace a paid TTS vendor?

For English and Chinese narration, prerecorded content, and any workload where you control a specific voice and can batch the work: yes, on the evidence available, and the licence makes trying it nearly free. For real-time conversational agents: measure time-to-first-audio yourself before committing, because nobody has published it and RTF will not tell you. For Arabic, Hindi, or any language in the long tail: the vendor's own two evaluations disagree by an order of magnitude, so treat the model as unproven there regardless of which number you saw quoted. And for anything where a mispronunciation is a business incident rather than an annoyance, note that VoxCPM2 is not the intelligibility leader even in its own table — Fish Audio S2 and LongCat-Audio-DiT are ahead of it there, and they are open-weights too.

What to watch

Two things, on different clocks. The near one is PR #47756 and the MiniCPM4 PR beneath it. If they merge, VoxCPM2 becomes an AutoModel call and the integration cost for everyone standardised on Transformers drops to nearly nothing overnight — and given 900,282 downloads a month already happen the hard way, that is a meaningful unlock. If they stall, the answer for those teams stays "use OpenBMB's package or the vLLM-Omni endpoint," and the community contributor carrying both PRs has no leverage to change that.

The slower one is whether anybody outside OpenBMB ever publishes a number. Four months after release, with 900,000 monthly downloads, 25 finetunes and more than 100 Spaces built on it, every performance figure in circulation still traces back to one technical report written by the people who trained the model. That is not a knock on OpenBMB, who documented their work more thoroughly and more honestly than most — the report volunteers its recogniser choices, its data-volume weaknesses and its own instability. It is a knock on the rest of us. The single most valuable thing anyone in the open-source speech community could publish this month is a Whisper-scored Seed-TTS-Eval and MiniMax-MLS run of VoxCPM2, Qwen3-TTS, Fish Audio S2 and LongCat-Audio-DiT under identical conditions. Until that exists, the fair summary of VoxCPM2 is that it is the most capable open-weights voice model per checkpoint that anyone has shipped, that it is not the most accurate one, and that both halves of that sentence rest on the vendor's word.