Best Local TTS Without a GPU: Real-Time on CPU

Short answer: Piper is the default, at ~63 MB per medium voice and one install command; Kokoro-82M is the quality upgrade at 86-92 MB as an int8 ONNX export but wants a desktop-class core; and every autoregressive engine — XTTS-v2, Bark, Orpheus, IndexTTS-2, VoxCPM — is out of the running on CPU no matter how you quantize it. That last point is the one that saves you a weekend.

Most "best local TTS" roundups benchmark on a 4090 and then rank by naturalness. If your target is a NAS, a mini PC, a Raspberry Pi or a laptop with integrated graphics, that ranking is close to useless — the models at the top of it are the ones that will never keep up on your hardware. This page ranks by the constraint instead.

One thing up front, because it changes how you should read everything below: we are not publishing our own real-time-factor table here. We do not have a fixed CPU-only lab box and a Pi 5 sitting on a bench producing repeatable numbers, and an invented RTF table is worse than no table. What we do publish is every spec we could verify against the official repos and model cards, the architectural rule that predicts CPU behaviour better than any single benchmark, and a two-minute recipe to get the RTF for your box — which is the only number that actually decides your project.

---

The Rule That Decides Everything

One property predicts CPU speech performance better than parameter count, quantization or RAM: whether the model is autoregressive.

There are three classes here, and they are separated by orders of magnitude, not percentages.

Non-autoregressive neural TTS — Piper (VITS), Kokoro-82M (StyleTTS2; its ONNX config.json reports "model_type": "style_text_to_speech_2"), Kitten TTS, and the VITS and Matcha voices shipped through sherpa-onnx. These run one forward pass over the phoneme sequence and produce the whole waveform. Compute scales with how long the sentence is, and it parallelises across cores. This is the class that can beat real time on modest CPUs.

Autoregressive, LLM-style TTS — XTTS-v2, Bark, Orpheus, IndexTTS-2, VoxCPM. These emit discrete audio tokens one step at a time, each step a full transformer decode that depends on the previous one. A second of speech costs dozens to hundreds of sequential steps. Sequential steps do not parallelise, and quantization reduces the cost per step without reducing the number of steps. On a GPU this is fine. On four low-power cores it is not, and it is not a tuning problem.

Formant synthesis — espeak-ng. No neural network at all: rules and filters. It runs in microseconds on anything with a CPU, in more than a hundred languages, and it sounds exactly like what it is. It is the floor, and the floor is genuinely useful for accessibility, alerts and embedded work.

If you remember one thing from this page, make it this: before you download a TTS model, find out whether it decodes audio tokens autoregressively. That single fact tells you more about how it will behave on your NAS than any leaderboard score.

---

The Shortlist

Every number in this table came from the official repository, model card or package index on August 18, 2026 — not from a benchmark we ran. Star counts and push dates are from the GitHub API on that date; file sizes are from the Hugging Face file listings.

Two things in that table are worth stopping on, because neither shows up in the usual roundups.

Silero is non-commercial. The LICENSE file in snakers4/silero-models is Creative Commons Attribution-NonCommercial-ShareAlike 4.0. It is a fine engine and it is frequently recommended for low-resource setups, but if there is any revenue attached to your project, it is disqualified before you measure anything. GitHub reports its license as "Other", which is why this keeps catching people.

espeak-ng's last tagged release is 1.52.0 from December 2024, even though the repository was pushed on 2026-08-10. Active development, infrequent releases. If you install from your distro's package manager you are probably on something older still — check with espeak-ng --version.

---

Piper: Still the Default, But Not Where You Think

The repo with 11,280 stars is an archive. The README at rhasspy/piper is now exactly one line: "Development has moved: https://github.com/OHF-Voice/piper1-gpl".

That is the single most useful thing on this page for anyone who has been following a tutorial. The active repository, OHF-Voice/piper1-gpl, has 5,162 stars — fewer than half — so search results, Stack Overflow answers and half the blog posts still send you to the frozen one. Two consequences you need to know about:

• The license changed. The old repo was MIT. piper-tts 1.7.0 on PyPI is published as GPL-3.0-or-later, and the new repo is GPL-3.0. For internal tools, self-hosting, research and open-source projects this changes nothing. If you were planning to embed Piper inside closed-source software because you remembered it as MIT, re-read the license before you build on it.
• The Open Home Foundation is asking for help. The README carries a "Looking for Maintainers" section: "The Open Home Foundation is looking for maintainers for Piper! If you're interested, please send a message to voice@openhomefoundation.org". That is not a reason to avoid Piper — it is the default TTS in Home Assistant and NVDA uses it — but it is honest context for a long-lived deployment.

Install and first sentence, from the current docs:

pip install piper-tts

# List everything available, then fetch one voice
python3 -m piper.download_voices
python3 -m piper.download_voices en_US-lessac-medium

# Synthesize to a file
python3 -m piper -m en_US-lessac-medium -f test.wav -- 'This is a test.'

Do not benchmark the CLI. The Piper docs say it plainly: the command-line interface "can be slow, however, because it needs to load the voice model each time. For repeated use, the web server is recommended." If you time the CLI on a Pi you are mostly timing ONNX model loading, and you will conclude Piper is far slower than it is. Run the bundled HTTP server for anything steady-state, and see our Piper TTS setup guide for the full install across Linux, macOS, Windows and Raspberry Pi.

There is a --cuda flag, which requires the onnxruntime-gpu package. On the machines this page is about, you will never use it.

---

Voice Quality Tiers: What x_low, low, medium and high Actually Mean

The official catalogue holds 174 voices across 55 language codes, and 120 of them are medium — the tier is the default for a reason. These figures come from voices.json in the rhasspy/piper-voices repository, read on August 18, 2026.

Sample rates were read from the voice .onnx.json configs (en_GB-alan-low reports 16000, en_GB-alan-medium and en_GB-cori-high both report 22050). The tiers also differ in phoneme vocabulary: low/x_low configs declare 130 symbols, medium/high declare 256.

The practical reading:

• medium is the answer unless you have measured a problem. 22.05 kHz, ~63 MB, and two thirds of the catalogue.
• low is the real lever on weak hardware — 16 kHz halves the number of audio samples you have to generate, and the models are often the same size or smaller. If a Pi 4 is struggling on medium, this is the first thing to try, before you switch engines.
• x_low is a trap for English speakers. There are only 14 of them and, verified against the catalogue, not one is English. If you are building an English voice assistant, x_low is not an option you have.
• high is inconsistent — the size range runs 63 MB to 137 MB, so "high" tells you about the training recipe, not a fixed model size. Only 14 voices exist.

Only 38 of the 174 voices are English, incidentally. If you need Catalan, Welsh, Greek or Farsi, Piper's coverage is the reason to pick it over anything else on this list.

---

Kokoro on CPU: The Quality Upgrade, With a Caveat

Kokoro-82M is small enough to be a serious CPU candidate — 92.4 MB as model_quantized.onnx, 86.0 MB as model_q8f16.onnx — but the only speed claim its maintainers publish is "near real-time on macOS M1".

That claim is from the kokoro-onnx README, and the honest way to read it is as a ceiling, not a floor. An M1 performance core is a long way above a Pi 5 core or an Intel N100. "Near real-time" on the fast end of that range means "not real-time" somewhere on the slow end. Where exactly is precisely the thing you have to measure yourself.

What is not in doubt is popularity: hexgrad/Kokoro-82M has 12.39M downloads on Hugging Face, and the ONNX community export another 1.66M. It is Apache-2.0, so there is no licensing obstacle. The full ONNX ladder from onnx-community/Kokoro-82M-v1.0-ONNX:

Start at model_q8f16.onnx or model_quantized.onnx on a CPU box; fp32 buys you nothing but page faults on a 2 GB Pi. Our Kokoro local setup guide covers the install, and Kokoro vs XTTS vs Chatterbox covers the quality comparison that this page deliberately does not repeat.

If 86 MB is still too much, Kitten TTS is a single 23.8 MB ONNX file under Apache-2.0 — the smallest credible neural option here, and we cover it on its own page rather than re-explaining it.

---

sherpa-onnx: The One With No Python At All

If your target has no Python runtime — an Android app, an embedded board, a C++ service — sherpa-onnx is the answer, and it is the most actively developed project on this list (14,227 stars, pushed the same day this page's research was done, latest release v1.13.6).

sherpa-onnx is not a model, it is a runtime. It loads VITS voices (including Piper's), Kokoro and Matcha models as ONNX and runs them through onnxruntime from C++, with bindings for a long list of languages and prebuilt Android APKs. It is Apache-2.0, which makes it the least legally awkward option in this whole comparison.

The reason it belongs on a no-GPU page: it removes the Python interpreter, the virtualenv and the PyTorch dependency chain from the equation entirely. On a 512 MB embedded board, that is not a convenience — it is the difference between shipping and not shipping.

---

Measure Your Own Real-Time Factor

Real-time factor is wall-clock synthesis time divided by the duration of the audio produced. Below 1.0 means faster than speech; 0.3 means you generated three seconds of audio per second of compute. For a voice assistant you want comfortably below 1.0, because RTF is not the only latency in the loop.

Here is the whole measurement, with no dependencies beyond Piper itself:

# 1. Install and fetch a voice
pip install piper-tts
python3 -m piper.download_voices en_US-lessac-medium

# 2. Synthesize a reasonably long, fixed sentence
time python3 -m piper -m en_US-lessac-medium -f out.wav -- \
  'The quick brown fox jumps over the lazy dog, and then it does so again, at some length, so that the measurement is not dominated by startup cost.'

# 3. Read the audio duration back out
python3 -c "import wave; w = wave.open('out.wav'); print(w.getnframes() / w.getframerate(), 'seconds of audio')"

RTF is the real time from step 2 divided by the seconds from step 3. Four things to control for, or your number will be meaningless:

1. Model load dominates short runs. The Piper docs warn about this explicitly. Use a long sentence, or better, run the HTTP server and time requests against a warm process. The gap between cold-CLI and warm-server RTF is large enough to reverse a verdict.
2. Pin the cores you actually have. On Linux, taskset -c 0-3 python3 -m piper ... restricts the process to four cores, which is how you simulate a Pi or a low-power mini PC on a desktop before you buy anything.
3. Vary the thread count. onnxruntime will happily use every core it can see, and throughput does not scale linearly. The 2-thread number is the one that matters if this is going to share a box with Home Assistant or a media server.
4. Test the tier you will ship, and the same text. low at 16 kHz versus medium at 22.05 kHz is a real difference in samples generated per second of speech, and a one-word sentence measures startup, not synthesis.

Run the same recipe against Kokoro and Kitten by swapping the synthesis command. The comparison you get in ten minutes on your own hardware beats any table we could publish about ours.

---

What Will Never Keep Up

Autoregressive TTS on a CPU is not a tuning problem, so do not spend a weekend on it. That covers XTTS-v2, Bark, Orpheus, IndexTTS-2 and — the one people keep asking about — VoxCPM.

VoxCPM specifically, since it is currently the most-starred TTS project on GitHub at 35,789 stars: the official README states the requirements as Python ≥ 3.10 (< 3.13), PyTorch ≥ 2.5.0 and CUDA ≥ 12.0, and its own configuration table lists VRAM around 5-8 GB depending on setup. The package does accept --device cpu among auto, cpu, mps, cuda and cuda:N, so it will technically run — but the project publishes no CPU throughput figure at all, and its serving story is built around vLLM and multi-GPU deployment.

There is a real CPU path, and it is worth naming precisely because readers will ask: the README points at llama.cpp-omni (VoxCPM2 GGUF on CPU / Metal / CUDA / Vulkan), VoxCPM.cpp (GGML/GGUF for CPU, CUDA, Vulkan) and VoxCPM-ONNX (ONNX export for CPU inference). Those are third-party ports listed in the official ecosystem table. We have not tested any of them and none publishes an RTF we could verify, so the honest verdict is: a CPU path exists, it is community-maintained and experimental, and it is not something to build a voice assistant on this quarter. If you want expressive cloning, the pragmatic answer is still to do it offline on a GPU box and cache the audio.

The same reasoning applies to the whole cloning tier — see best local TTS models for the quality-first roundup, which is a different question from this one.

---

Pick One

Match the engine to the weakest machine it has to run on, not the machine you develop on.

Wiring the result into an actual assistant is the next step — our local voice assistant walkthrough pairs Whisper for input with Piper for output, and running LLMs on CPU only covers the other half of a GPU-free stack. If the target really is a Pi, LLMs on the Raspberry Pi 5 has the hardware reality check. And if you have been fighting Coqui, our Coqui TTS Python guide explains where that project now stands.

---

Honest Limitations

Three things this page does not do, stated plainly:

• No RTF table of our own. Every performance claim above is either architectural reasoning, a maintainer's own published claim (clearly attributed), or a figure from our existing hands-on guides. We would rather hand you a measurement recipe than a fabricated benchmark.
• No audio samples hosted here. Piper's official sample site and each project's demo pages are the right place to judge quality with your own ears, and they are linked from the repositories above.
• No claim about Kokoro or Kitten on a Pi. Neither project publishes an RTF for low-power ARM, we have not measured it, and the honest answer is "run the recipe in the measurement section and find out in ten minutes."

---

Sources

All figures read on August 18, 2026:

• OHF-Voice/piper1-gpl — active Piper repo, README, CLI docs, "Looking for Maintainers" notice
• rhasspy/piper — archived repo whose README is the one-line redirect
• rhasspy/piper-voices — voices.json voice catalogue and per-voice .onnx.json configs
• piper-tts on PyPI — version 1.7.0, GPL-3.0-or-later
• onnx-community/Kokoro-82M-v1.0-ONNX and hexgrad/Kokoro-82M — export sizes, config, downloads
• thewh1teagle/kokoro-onnx — the "near real-time on macOS M1" claim
• k2-fsa/sherpa-onnx — runtime, v1.13.6, Apache-2.0
• KittenML/kitten-tts-nano-0.1 — 23.8 MB ONNX, Apache-2.0
• snakers4/silero-models — LICENSE file (CC BY-NC-SA 4.0)
• espeak-ng/espeak-ng — release 1.52.0
• OpenBMB/VoxCPM — CUDA requirement, device options, third-party CPU ports

---

FAQ