Local TTS on CPU: Pocket TTS and Kokoro
A few years ago, realistic local speech generation sounded like a fantasy. You wanted a neural voice? Pick a cloud API, send your text, hope the latency held. The good ones charged by the million characters. The free ones were robotic. Trying to run a quality model on the same machine you were already using for everything else was a non-starter.
That case has collapsed pretty hard over the last year. Two small open weight models, Pocket TTS from Kyutai and Kokoro-82M from the hexgrad project, can both generate realistic speech on a plain CPU. No GPU. No server farm. No per-character bill. One fits in 100 million parameters, the other in 82 million. Both are faster than real time on consumer hardware you probably already own. The fact that this is even a sentence I can write is the interesting part.
Pocket TTS, the one with voice cloning
Kyutai launched Pocket TTS on January 13, 2026. The repo is at github.com/kyutai-labs/pocket-tts, MIT licensed, 6,254 stars as I write this, Python 3.10 through 3.14, PyTorch 2.5 and up, and the README is explicit about something most TTS projects hedge on: you do not need the GPU build of PyTorch. CPU-only is the path.
100 million parameters. The CPU footprint is two cores. Two. On a MacBook Air M4 the README claims around 6x real time and a 200 millisecond time to first audio chunk. That second number is the one that matters for anything interactive. A 200 ms first-chunk latency is low enough to feel like a voice is talking to you, not like a model is preparing to talk to you.
The thing that makes Pocket TTS stand out, more than the speed, is voice cloning. You hand the model a short wav file of someone talking, and it produces new speech in that voice. The voice embedding step is not cheap, but once you have it you can export to a safetensors file and reload fast. So the slow part happens once, and the fast part happens forever after.
The streaming behavior is worth dwelling on. A lot of TTS systems generate the whole clip and then hand it back. Pocket TTS hands back chunks as it computes them, so the user hears the beginning of the sentence before the model has finished synthesizing the end. For chat-style applications, for screen readers, for anything where the user is waiting on the speech to begin, that is the difference between feeling responsive and feeling laggy.
The CLI is one line. uvx pocket-tts generate writes tts_output.wav with the default voice. pocket-tts serve boots a local HTTP server with a web interface at localhost:8000. The Python API is short enough to fit in a cell.
from pocket_tts import TTSModel
import scipy.io.wavfile
tts_model = TTSModel.load_model()
voice_state = tts_model.get_state_for_audio_prompt("alba")
audio = tts_model.generate_audio(voice_state, "Hello world, this is a test.")
scipy.io.wavfile.write("output.wav", tts_model.sample_rate, audio.numpy())There is one gap in the README that I appreciate the honesty of. They tried running Pocket TTS on the GPU and saw no speedup over CPU, because they are using batch size 1 and the model is so small. That is not a failure to optimize, that is a model small enough that the GPU overhead does not pay for itself. Worth knowing before you bolt a GPU to a project that does not need it.
Kokoro, the older sibling
Kokoro-82M is the project Pocket TTS gets compared to, and the comparison is fair. The model is at huggingface.co/hexgrad/Kokoro-82M. Apache 2.0, 82 million parameters, 8 languages including English, Mandarin, Hindi, and a handful of European ones. The v1.0 release landed January 27, 2025, a full year before Pocket TTS shipped. Total training cost was about a thousand dollars of A100 GPU time, which puts it in the "a determined individual can afford to build this" tier.
The architecture page credits StyleTTS 2 by Li et al (github.com/yl4579/StyleTTS2) as the root. That lineage matters because it explains why a model this small can sound this good. StyleTTS 2 was built specifically to get high quality from small parameter counts, by decoupling style from content. Kokoro takes that design and trains it on a quietly substantial corpus. The combination is the whole pitch.
An independent writeup at ariya.io ran Kokoro through a short test paragraph on three different CPUs. The numbers are reproduced below. These are not vendor figures. They were measured by a third party running the Kokoro-FastAPI container on bare metal.
The Intel chip in that list is twelve years old. It produced audio in 4.7 seconds, which is still faster than the spoken duration of the paragraph. That is the part to keep. Twelve-year-old silicon, full pipeline, no GPU, faster than real time. The conclusion the article draws, "if that ancient CPU can do the job just fine you know that this is a highly capable TTS system," is one of those rare sentences from a benchmarks writeup that holds up without overstating.
Kokoro does not have built-in voice cloning like Pocket TTS. You pick from a catalog of prebuilt voices, around 50 for English, slightly fewer for the other languages. For most applications that is fine, and it means one less trust and consent surface to manage. Voice cloning is a capability with a real social cost, and "the model can copy any voice from a 5 second clip" is a sentence that gets scarier the more you think about it.
The in-browser ports are where this gets strange
This is the part of the story that surprised me. Pocket TTS is small enough that the community has already wrapped it to run inside the browser. The README lists four in-browser implementations:
wasm-pocket-ttsby LaurentMazare: a Rust port using XN, with a live demopocket-tts-onnx-exportby KevinAHM: the model exported to ONNX and run in ONNX Runtime Webpocket-ttsby babybirdprd: a Candle (Rust) build with WebAssembly and PyO3 bindingsjax-jsby ekzhang: using the jax-js ML library for the web
Four independent ports, four different runtime strategies, all of them working in a browser tab. That tells you something I did not expect when I started writing this. Speech synthesis has crossed the threshold where you can degrade-gracefully your way out of the server entirely.
There are also non-browser ports worth flagging. pocket-tts-mlx by jishnuvenugopal is an MLX backend tuned for Apple Silicon. pocket-tts-xn by LaurentMazare is the Rust/XN build I keep seeing pop up. PocketTTS.cpp by VolgaGerm is a single-file C++ runtime on ONNX Runtime with a CLI, an HTTP server, and an FFI C API, which is the kind of single-file project I find quietly impressive. There is even a Home Assistant integration via the Wyoming protocol for voice assistant setups.
What you actually trade off
It would be dishonest to write this without naming the costs. Small TTS models are not free.
Quality, for one. The best open-weight models here are very good. They are not at the level of ElevenLabs in its highest quality mode, which is what you would expect given a 100x parameter gap and a 1000x dataset gap. Kokoro and Pocket TTS are the projects that make you reconsider whether you need the top of the line for your particular job. They are not the projects that win every comparison.
Expressiveness, for two. These models produce natural single-voice speech. They do not do the dramatic variety, the breath control, the conversational turn-taking that the biggest proprietary models are starting to ship. If your use case is "read this article to me in a steady voice" you are fine. If your use case is "act out a dialogue with emotional beats" you are going to notice the gap.
Consent, for three. The Pocket TTS voice cloning feature presumes that you have the right to clone the voice you are cloning. The README acknowledges this by pointing at a per-voice license page. The community has been responsible enough not to make this frictionless, but the capability exists and the trust model is "you handle it."
Hardware variance, for four. The Kokoro numbers above show a 3x swing between a high-end modern AMD chip and a decade-old Intel one. Both work. Both are faster than real time. Both will feel different. There is no way to know how your exact machine will land without trying it.
Where I think this goes
The two trends worth watching are running together. Small models are getting good enough to be the default for a lot of jobs, and the WebAssembly tooling to ship them into a browser tab is getting good enough that "the model lives on my page" stops being exotic.
If you are building a documentation tool, a chat interface, a local screen reader, a kiosk, an offline-first app, a privacy-sensitive workflow where the text never leaves the user's device, you should be trying one of these two models this week. Not because they are perfect, but because the cost of finding out they are good enough rounds down to zero.
If you are doing enterprise-grade IVR, audiobook narration at scale, or anything where you need the absolute best expressive quality, the gap is still real. You are still paying per character for the hosted thing. The gap is smaller than it was. It is not closed.
Kyutai's README has a line I keep coming back to. They note they support additional languages only if they get clean enough data, and that "additional languages may be added in the future." Read that as: this is an active research lab shipping a thing, not a company trying to win the TTS market. The fact that they shipped a model this good with this small a parameter count and put an MIT license on it is the kind of move that bends the price floor for the whole category. Whatever you were paying for TTS last year, you are paying too much this year.
The repos are at github.com/kyutai-labs/pocket-tts and huggingface.co/hexgrad/Kokoro-82M. Both have live demos. Click through. Listen to the output on your hardware. That is the only honest way to decide whether your specific use case fits through the door these two opened.