This is a companion to our report on Voxtral 3, which is a strong speech family that — for now — you cannot download. That is a good reason to know what you can run on your own hardware.
This guide is about synthesising speech from text on your own machine, for narration, scratch voiceover, gallery and installation audio, and accessibility. It is not about voice cloning — that has its own ethical terrain and mostly needs someone’s consent, not a tutorial.
Why local, specifically
Your script stays on your machine. For an unreleased film, a client’s copy, or anything under embargo, this is the whole argument. A cloud TTS request is a copy of your text on someone else’s infrastructure.
It is free per character. Narration iterates. If you are re-rendering a ten-minute script forty times while editing, per-character pricing is a tax on revision.
It works offline. Installations in galleries lose Wi-Fi. A piece that needs an API to speak is a piece that goes silent.
It does not get deprecated. A local checkpoint renders the same audio next year. An API endpoint can change its voices, its pricing or its existence — and as Voxtral 3 illustrates, a vendor with a strong open-weights record can still ship the next generation API-only.
What you need
- A machine with 8 GB of RAM for the small models; 6–8 GB of VRAM makes the mid-size ones comfortable
- Python and a working audio output
- Apple Silicon works well for this — the unified memory suits it, and most projects have Metal support
You do not need a datacentre GPU. Speech synthesis is far cheaper than image or video generation; a lot of usable TTS runs on CPU at slower-than-real-time, which is fine for rendering a file.
Choosing a model
Rather than name a leaderboard that will be wrong in a month, here is what to evaluate on — in the order that actually determines whether you can ship the audio.
Licence, first. Check it before you listen to a single sample. Some well-known TTS checkpoints are released under non-commercial terms, which rules them out for client work, and the restriction is in the model card rather than anywhere you would notice. Apache-2.0 and MIT are unambiguous. “Research only” means research only.
Does it do long-form? Many models are trained on short utterances and degrade badly past twenty or thirty seconds — drifting in pitch, losing pace, or simply stopping. If you are narrating, test it on a full paragraph before you judge it on a demo sentence.
Prosody control. Can you influence pace, emphasis and pauses? Some models expose tags or markup; others give you nothing but the text. For narration, control over pausing matters more than raw voice quality.
Voice selection. A handful of good built-in voices beats a cloning feature you will not use.
Streaming or batch. For rendering a file, batch is fine and usually higher quality. Streaming matters only for live or interactive work.
A reasonable approach: install one small model and one mid-size model, render the same paragraph through both, and keep the one that needed fewer retakes.
Writing text a model will read well
This is where most of the quality is, and it is free. A mediocre model with well-prepared text beats a good model fed raw prose.
Spell out anything a human would read aloud differently from how it is written. Numbers, dates, units, currency, abbreviations. Write “nineteen ninety-six” if you want that, not “1996”. Write “three point five metres”, not “3.5m”. Models guess at these, and guess inconsistently within the same render.
Punctuation is your pause control. A comma is a short pause, a full stop a longer one, and a paragraph break longer still. If a pause is in the wrong place, add or move punctuation rather than fighting the model. An em dash often produces a different pause length from a comma — worth testing on your model.
Break long sentences. A thirty-word sentence with three subclauses is where prosody falls apart. Two sentences read better and sound more deliberate.
Render in chunks, one paragraph at a time. Then concatenate. This gives you per-paragraph retakes instead of re-rendering ten minutes to fix one word, and it sidesteps long-form drift entirely. Keep a consistent short silence between chunks so the joins are even.
Keep a fix list. Every model mispronounces particular words — names, technical terms, anything foreign. Keep a text file of find-and-replace respellings for your project. This is the single highest-value habit in local TTS.
Where the seams show
Be clear-eyed about the limits, because they are audible.
Emotion is shallow. Local models do neutral narration well. Ask for sardonic, grief-stricken or genuinely funny and you will get neutral narration with different pacing. If the performance is the point, hire a person.
Consistency across a long piece drifts. Timbre and pace wander over a twenty-minute render, which chunking mitigates but does not eliminate.
Proper nouns are unreliable. See the fix list.
Laughter, breaths and non-speech sounds are mostly absent or bad.
A fair summary of where the line sits today: local TTS is good enough for scratch tracks, documentation, accessibility passes, installation audio and explanatory narration, and not good enough for a performance. Knowing which of those you are making saves a lot of time.
A note on disclosure
If synthesised narration ships in public work, say so. Not because anyone will catch you, but because an audience that discovers it afterwards feels differently about the piece than one that knew. A line in the credits costs nothing.
Sources
- Run Text-to-Speech Locally: Step-by-Step Guide — The Personal AI Architecture on YouTube
- Voxtral 3: Voice Agent SDK & Speech Models in 50+ Languages — Mistral AI