Gradium's Phonon Beats 552M Models at Speech Quality With Just 100M Parameters
Gradium's 100M-parameter on-device TTS model hits 1.00% WER on Seed-TTS, beating models up to 5x its size while adding int8 quantization and removing latency-killing input padding.

- 1.00% WER achieved: Gradium's Phonon hits 1.00% WER on Seed-TTS English, beating NeuTTS Air (552M), KaniTTS2 (450M), and NeuTTS Nano (229M) at just 100M parameters.
- 0.83% WER in fixed-voice mode: With voice cloning disabled, Phonon outperforms Kokoro (82M, 0.90%) and NVIDIA's Magpie (357M, 0.89%).
- Padding removed: The 100-token minimum input padding is gone, dramatically reducing time-to-first-audio for short conversational replies.
- int8 quantization added: No audible quality loss, lower memory usage, and faster on-device inference.
- Runs on a single CPU core: 6x real-time on a MacBook, in-browser and on mobile with no GPU required.
- Private beta: Partners can request access; model ships as a self-contained binary with no external runtime dependencies.
On-device text-to-speech has long been a game of painful tradeoffs: shrink the model enough to fit on a phone, and quality craters. Gradium's latest Phonon update is making a strong case that this tradeoff is no longer inevitable. The company's 100M-parameter model now reaches 1.00% Word Error Rate (WER) on the Seed-TTS English benchmark, outperforming every on-device competitor it was tested against, all of which are significantly larger.
A benchmark that actually matters for edge deployment
WER, in this context, measures how accurately synthesized speech can be transcribed back to the original text. Lower is better. Results are reported on the Seed-TTS English test set, with generated audio transcribed using Whisper large-v3 and compared to input text using jiwer with text normalization. Speaker similarity is measured as the cosine distance between WavLM-large embeddings of the reference and generated audio. This is the same evaluation protocol used across the broader TTS research community, making comparisons meaningful.
Seed-TTS-Eval is an objective benchmark for zero-shot TTS and voice conversion evaluation, using out-of-domain English and Mandarin samples from Common Voice and DiDiSpeech-2, with the official evaluation focusing on intelligibility and speaker consistency. Passing it well, at 100M parameters, is a different kind of achievement than passing it with a 1.5B model running on a data center GPU.
The numbers, and why size is the real story
Phonon now reaches 1.00% WER on the Seed-TTS English benchmark with voice cloning enabled, outperforming NeuTTS Air (552M), KaniTTS2 (450M), and NeuTTS Nano (229M). With voice cloning disabled and a fixed high-quality voice, Phonon drops to 0.83% WER, ahead of Kokoro and Magpie.Here is how the full comparison looks with voice cloning enabled:
| Model | Parameters | WER | Speaker Similarity |
|---|---|---|---|
| Phonon (May 2026) | ~100M | 1.00% | 59.51% |
| Phonon (April 2026) | ~100M | 1.48% | 56.37% |
| NeuTTS Nano | 229M | 1.71% | 40.15% |
| NeuTTS Air | 552M | 2.18% | 47.51% |
| KaniTTS2 | 450M | 4.97% | 40.73% |
Parameter count determines where a model can actually run, which makes it as important as quality scores in the on-device context. A model with excellent benchmark scores that requires 500M+ parameters is not deployable on most mobile devices. Phonon's 100M footprint is not a compromise here, it is the entire point.
What changed since April
This is not a minor polish update. Four concrete things improved:
- WER dropped from 1.48% to 1.00% with voice cloning, and from an unspecified baseline to 0.83% in fixed-voice mode
- Speaker similarity jumped from 56.37% to 59.51%, meaning the cloned voice sounds more like the reference speaker
- 100-token input padding removed: short phrases no longer need artificial filler before generation starts
- int8 quantization now supported with no audible quality loss, reducing memory footprint and speeding up inference
The padding removal deserves more attention than it might get. The removal of the 100-token minimum input padding reduces time to first audio for short inputs, which is exactly what fills real-world voice agent conversations: quick confirmations, short replies, single-sentence answers. Every one of those used to require the model to pad its way to 100 tokens before generating anything. Now it does not.
How it works under the hood
Phonon is based on Continuous Audio Language Models with flow-matching for waveform generation. This is worth unpacking. Most audio language models work by first compressing audio into discrete tokens using a codec (think of it like lossy MP3 compression), then training a language model to predict those tokens. The problem is that audio language models have emerged as the dominant paradigm by representing audio as sequences of discrete tokens, but unlike text tokens, audio tokens are extracted from lossy codecs with a limited bitrate, meaning increasing audio quality requires generating more tokens, imposing a tradeoff between fidelity and computational cost.
Continuous Audio Language Models (CALM) sidestep this entirely. CALM models instantiate a large Transformer backbone that produces a contextual embedding at every timestep, with this sequential information conditioning an MLP that generates the next continuous frame of an audio VAE through consistency modeling. By avoiding lossy compression, CALM achieves higher quality at lower computational cost than discrete counterparts. Flow-matching, the waveform generation technique layered on top, is a way of learning to transform random noise into a target audio distribution along a smooth, efficient path, similar to diffusion but typically faster at inference time.
One architectural choice that quietly matters: Phonon runs inference on a single CPU core at 6x real-time on a MacBook, and supports voice cloning from a 10-second reference audio sample. No GPU required. It is small enough to run in a browser and on mobile devices without GPU acceleration. That is a meaningful constraint to satisfy while still beating 552M-parameter models on quality.
Another subtle advantage: Phonon uses a standard text tokenizer rather than a phonemizer-based approach like Kokoro and Magpie. Phonemizers convert text to phonetic representations before synthesis, which can break on unusual spellings, proper nouns, or out-of-distribution text. A standard tokenizer handles these more gracefully.
Where it fits and where it does not
Phonon extends the voice stack into deployment contexts where cloud TTS is not the right architecture: high-volume consumer applications where per-request cost becomes a structural constraint, products that need to function offline, and use cases where data privacy requires that text never leaves the device. Concretely, that means:
- Voice agents in vehicles or remote hardware where network connectivity is unreliable
- Healthcare and consumer devices where audio cannot be sent to a cloud endpoint
- Game NPCs requiring real-time, low-latency speech generation at scale
- High-volume consumer apps where per-request API costs compound quickly
- Browser-based applications that need TTS without a backend call
The limitations are real too. The current model was trained on 10-second reference audio segments, and where the Seed-TTS reference audio is shorter than 10 seconds, Gradium extended it by looping. Speaker similarity scores are expected to improve when Phonon adds support for variable-length reference audio. The benchmarks are also self-reported by Gradium, which is worth noting even if the methodology is transparent and reproducible.
Availability and access
Phonon is currently in private beta. Partners apply to define the scope (language, voice, target devices), and receive a fine-tuned model artifact in days to weeks. The model ships as a self-contained binary inside the partner's application with no external runtime dependencies. You can request access on the Gradium website. No pricing has been publicly disclosed for the on-device offering.
The broader implication here is worth sitting with. The assumption that on-device TTS means accepting lower quality is being systematically dismantled. A 552M parameter model has limited deployment viability on mid-range mobile hardware, while a 100M parameter model runs on a single CPU core, fits in mobile memory, and runs in-browser. When a 100M model beats the 552M model on accuracy too, the calculus for anyone building voice products changes significantly.