Sci-Fi Labs · Field notes

Local TTS on 16 GB — the voice quality gap

The model answers. The hand goes to mute. Why "it works" is not the same as "it sounds human" on a 16 GB laptop.

A 27B model answers on this laptop. Whisper hears you. Chat streams. Then the voice starts talking, and the hand goes to mute. That is the day. Not "does it run." Does it sound like someone you would keep talking to.

Knowledge Graph is a private spatial canvas — photos, conversations, and time on a machine you own. The chat stack was being rebuilt by hand: streaming, retries, auth, audio plumbing. Today that stopped. Open WebUI already had it — same SvelteKit frontend language, same FastAPI backend, built-in Whisper, a real tool and RAG layer. Pointing it at the existing Bonsai-27B llama.cpp server was almost out of the box. The model layer worked on the first try. The part that was supposed to be easy was easy. Then came the voice.

TTS options that fit 16 GB

The 16 GB budget is unforgiving. Right now, writing this on an M2 Pro: 12.6 GB spoken for, 2.7 GB left. Bonsai has the weights. Brave and VS Code are the real tax. There is no spare room for a second large model. The full process list sits under the scoreboard. "It runs" on a clean machine is a lie.

On paper, Kokoro JS is the right starting point. Open WebUI ships with it as the default local TTS: the 82M model, in the browser, no extra RAM on the backend. The first download did not land. Default voice, half-wired audio, a system-voice first impression. That sent the day into Piper, XTTS, Bark, and a server-side Kokoro pipeline. All of that was chasing a setup problem. Once Open WebUI was actually running Kokoro JS, it was a voice you can leave on. That is what shipped.

Piper was the next try. It is fast, CPU-friendly, and designed for exactly this class of machine. Response time was excellent. The popular Lessac voices were intelligible and stable, but still synthetic in a way you notice within a few sentences.

Coqui TTS (XTTS-v2) was the heavier attempt — roughly 470M parameters, around 5 GB of RAM during model loading, and another 2 GB of VRAM on top. On a machine already running Bonsai, Whisper, Open WebUI, Brave, VS Code, and a coding agent, that load does not fit.

Bark was worse. A generative model that wants roughly 12 GB of VRAM with all three sub-models loaded, or 8 GB with the small flag, or 2 GB only by offloading to CPU where it crawls. A Bark experiment ended in a hard restart.

Why the voice is still the bottleneck

The model can reason. The transcription can be perfect. The latency can be instant. If the voice sounds synthetic, the conversation never starts. People do not talk to tools. They talk to voices that sound like they belong to someone.

This is not aesthetics. You can understand every word and still want it to stop inside a minute. The brain treats natural speech as signal and synthetic speech as noise. That is the gap between "it works" and "it is used."

Frontier models get this right because they spend the compute. A 16 GB laptop does not have that room. Local LLM inference has improved faster than local TTS quality at the same memory budget. A 1-bit 27B model can reason and tool-call inside a few gigabytes of weights. A voice that does not sound like a 2018 assistant still looks, on paper, like it wants more compute, more VRAM, or a cloud API.

The surprise was not a bigger engine. It was the first Open WebUI download. Kokoro JS was already there. It did not work on first contact, so the day became a gauntlet. Piper was fast and still synthetic. XTTS did not fit. Bark forced a restart. Server-side Kokoro with af_heart sounded fine and spent RAM the machine does not have. Then the JS path started working. Same 82M weights. No Python TTS process. The mute instinct did not trigger. The wild goose chase was a bad first setup.

That is the bar: not "intelligible," but "kept on." Kokoro JS, once the install is actually running it, clears it without a second model in RAM.

For Knowledge Graph and the wider Sci-Fi Labs stack, the design constraint stays the same: everything that touches private memory stays on hardware you control. Cloud TTS is a temporary convenience, not the architecture. The honest state today is: chat works, STT works, TTS works. The first install is not the last word.

This is the machine right now, everything open. A user does not close their browser to talk to their AI.

The scoreboard is every option that was actually tried, with the official sample from each project so you can hear the class of voice. Footprints are CPU RAM unless a GPU floor is required. The highlighted row is the one that shipped.

Official samples from each project, not recordings from this laptop. Sources: Kokoro samples, Piper Lessac, Coqui XTTS-v2, Bark.

What shipped

I now have a working Open WebUI instance talking to Bonsai. Whisper hears. Kokoro JS speaks. Full conversations, all on this machine.

Next step is not another engine. Swap the chatbot window for the Knowledge Graph UI I already built. Same models. The canvas, not the bubbles.

What you want out of a personal AI model is the conversation experience you get out of frontier models, but running on a 16 GB laptop. Tall order.