CPU TTS Benchmark: Is Kyutai Pocket TTS Worth Using?

1. Here’s the Situation

Recently, someone on Reddit put Kyutai’s newly released Pocket TTS head-to-head against Kokoro, Supertonic, and Inflect-Nano in a pure CPU benchmark. The results were pretty interesting — 180 test runs, six text lengths, and objective UTMOS scoring — essentially answering the question: “Can small TTS models actually run well on CPUs?”

First, some background. Pocket TTS, released by Kyutai at the end of October, is a 100M-parameter streaming LM running on their in-house Mimi neural audio codec. It claims to do real-time synthesis without a GPU and also supports voice cloning. That sounds ambitious, but architecturally it really is different from most TTS systems on the market. Instead of the non-autoregressive vocoder route used by systems like StyleTTS2, it treats audio as a token sequence and generates it chunk by chunk like a language model.

That naturally raises a direct question: can LM-style streaming generation still sustain real-time performance on CPUs? That’s also the most interesting part of this benchmark.

2. Test Environment and Models Compared

The test machine was pretty modest: Intel Xeon 8272CL, 4 cores, 15.6GB RAM, CUDA completely disabled, and ONNX sessions forced onto CPUExecutionProvider. This was not some enthusiast setup — just an ordinary cloud server vCPU.

The contestants:

• Kokoro 82M: Based on StyleTTS2. Both PyTorch and ONNX Runtime versions were tested. A familiar name in open-source TTS.
• Supertonic 3: A flow-matching model built on the Vector Estimator framework, tested in both 2-step and 5-step configurations.
• Inflect-Nano-v1: A 4.6M-parameter FastSpeech-style model designed for extreme lightweight deployment.
• Pocket TTS: Kyutai’s new 100M-parameter streaming LM and the main focus of this benchmark.

The six text lengths ranged from 12 characters all the way up to 1712 characters. Each configuration was run five times per case (excluding one warmup run). Every generated WAV file was scored using UTMOS (utmos22_strong) to produce an objective MOS estimate. This methodology is far more reliable than “it sounds good to me.”

3. Looking at the Numbers

From the aggregated results, here are some key figures (lower RTF is faster; higher UTMOS is better):

| Configuration | Average RTF | UTMOS | |---|---|---| | Supertonic 3 (2-step) | 0.121 | 1.53 | | Inflect-Nano-v1 | 0.145 | 3.48 | | Supertonic 3 (5-step) | ~0.25 | ~1.6 | | Kokoro (ONNX) | ~0.3-0.4 | ~3.9 | | Pocket TTS | Highest among the group | Highest |

(The original Reddit table was truncated; the later rows are approximate values reconstructed from discussion comments.)

First, Supertonic. What does an RTF of 0.121 mean? It only takes 121ms to generate 1 second of audio — absurdly fast. But the tradeoff is a UTMOS score of 1.53, which is basically “recognizable speech but unpleasant to listen to.” Moving from 2-step to 5-step didn’t fundamentally improve quality; it mostly doubled the compute cost for psychological comfort.

Inflect-Nano was the surprise hit of the benchmark. With only 4.6M parameters, it achieved RTF 0.145 and still managed a UTMOS of 3.48. Its parameter count is an order of magnitude smaller than the competition, yet its audio quality significantly outperformed Supertonic. The old FastSpeech architecture remains impressively efficient at tiny scales.

Kokoro remains solid as ever. The ONNX version sits around RTF 0.3–0.4 with UTMOS near 3.9 — the kind of model with no obvious weaknesses. That also explains why Kokoro has been integrated into so many open-source TTS pipelines over the past year: it’s the default option that simply works.

Pocket TTS occupies a more unique position. It achieved the highest UTMOS score, but also the highest RTF among the models tested, especially on short texts. The reason is straightforward: LM-style autoregressive generation has significant startup overhead. The Mimi codec requires a forward pass for every frame, so short sentences don’t benefit much from streaming generation. Longer passages are where the architecture pays off.

4. Is Pocket TTS Actually Usable?

This is the question developers care about most.

The short answer: yes — but it depends on your use case.

If you’re building real-time conversational systems (agents, voice assistants), Pocket TTS’s streaming capability is genuinely valuable. It doesn’t need to finish synthesizing the whole sentence before playback begins; it can stream while generating. A 100M-parameter model doing real-time inference on CPU alone would have sounded unrealistic before this year. According to Kyutai’s technical report, its WER performance is also competitive with F5-TTS, Chatterbox Turbo, and Kokoro. Voice cloning support is another standout feature — among these models, Pocket TTS is the only one with native support.

But if your workload is offline batch synthesis — announcements, audiobooks, and similar tasks — then there’s little reason to tolerate Pocket TTS’s RTF disadvantage. Kokoro is easier to work with, and Inflect-Nano is cheaper to run.

One more detail worth mentioning: this benchmark used a 4-core Xeon. Pocket TTS would likely perform better on Apple M-series chips or desktop CPUs with more complete AVX-512 support. LM-style inference is more sensitive to SIMD instruction sets. Cloud vCPUs represent more of a lower-bound scenario than a typical deployment environment.

5. A Few Easily Overlooked Pitfalls

Anyone who has worked with small TTS systems has probably encountered these:

1. ONNX Runtime version sensitivity. Kokoro’s ONNX version can differ from the PyTorch version by 30%+ in RTF, largely depending on operator fusion coverage. Benchmark it yourself before production deployment instead of trusting the README.

2. UTMOS is not everything. The metric is relatively insensitive to prosody and long-range structure. A sentence might pronounce every word correctly but completely mess up stress and intonation, and UTMOS could still give it 3.8. Human listening tests on bad cases are still necessary before deployment.

3. First-token latency matters more than RTF in streaming TTS. An RTF of 0.3 with 800ms startup latency is a completely different conversational experience from an RTF of 0.5 with 200ms startup latency. This benchmark did not break down first-packet latency in detail, which is a minor disappointment.

4. Chinese-language scenarios need separate validation. Among these four systems, Kokoro supports Chinese but not particularly well. Pocket TTS is currently focused mainly on English and French, and its Chinese capability hasn’t really been validated yet. Domestic deployments should proceed cautiously, or simply use models designed specifically for Chinese such as CosyVoice2 or Fish Speech.

6. Where These Models Sit in the Industry

Looking at the bigger picture, small-model TTS in 2026 has become intensely competitive:

• SiliconFlow is pushing CosyVoice2-0.5B, with 150ms streaming latency and full Chinese dialect support;
• Fish Speech 1.5 reached an ELO of 1339 on TTS Arena, with top-tier multilingual quality;
• IndexTTS-2 focuses on precise duration control and zero-shot voice cloning;
• Alongside the CPU-oriented models discussed here.

The division of approaches is becoming very clear: GPU-side systems compete on quality and emotional expressiveness, while CPU-side systems compete on latency and cost. Pocket TTS is currently the only CPU-oriented example successfully implementing the LM streaming route, and this direction will probably attract more players in the near future — especially as on-device agents become more common and voice generation can no longer rely entirely on cloud APIs.

As a side note, OpenAI Hub currently mainly integrates cloud-based TTS systems from various providers (including OpenAI TTS, Gemini speech synthesis, etc.). If you don’t want to deploy Kokoro or Pocket TTS yourself, you can simply use APIs and access multiple models through a single key, including direct access within China without VPNs. But if your use case is sensitive to privacy, latency, or cost, running these small models locally is still the better solution. These approaches are complementary, not contradictory.

7. Model Selection Recommendations for Developers

To summarize bluntly:

• Need real-time dialogue, voice cloning, and can accept a ~100MB model: choose Pocket TTS.
• Need balanced performance with minimal hassle: Kokoro ONNX is the safe default.
• Extremely resource-constrained environments (edge devices, embedded systems): Inflect-Nano. A 4.6M-parameter model really can fit almost anywhere.
• Need Chinese support, dialect support, and can use GPUs or cloud APIs: pick among CosyVoice2, Fish Speech, or IndexTTS-2.
• Supertonic: unless you only care about RTF and not audio quality, it’s probably skippable.

One final observation. Progress in the TTS space over the past year has been faster than many expected. A year ago, CPU TTS basically forced a choice between “slow” and “bad sounding.” Now we already have systems achieving RTF 0.15 and MOS 3.5+ on a 4-core cloud server. Another year from now, voice output for on-device agents may no longer be a meaningful bottleneck. The pace of development is genuinely exciting.

References

• CPU TTS benchmark with UTMOS MOS scoring (Reddit r/MachineLearning) — Primary source of benchmark data used in this article
• Kyutai Pocket TTS discussion (Reddit r/LocalLLaMA) — Community discussion from the Pocket TTS launch, including end-to-end latency feedback
• Lightweight TTS: Running MeloTTS on CPU for Speech Synthesis (Zhihu) — Reference comparison of CPU TTS solutions in Chinese-language contexts