There's a version of this conversation where I spend the first three paragraphs explaining what text-to-speech is and why it matters. I'm not going to do that. If you're reading this, you're already building something, evaluating something, or questioning a cloud bill that's quietly grown too large. Let's get to the part that's actually useful.
The assumption baked into most production decisions around TTS is that quality costs scale. That if you want a voice people don't wince at, you pay for a large hosted model, per character, with the meter running. I think that assumption is wrong, and the engineering reality has been wrong about it for a couple of years now. The deployment patterns are just catching up.
When I say small TTS models, I mean architectures designed to run inference on modest hardware without a network call. Piper is the clearest example of this design philosophy: it was built with Raspberry Pi and low-power devices explicitly in mind, and the project documentation says exactly that. Kokoro has drawn genuine attention from the community for producing natural-sounding output at a parameter count that would have seemed implausible a few years ago. MeloTTS and the Parler-TTS family round out the set of models worth watching seriously.
Specific parameter counts and real-time factor figures for each model are available on their respective GitHub repositories and Hugging Face model cards. I'd encourage you to pull those numbers fresh at the time you're making a decision, because figures for models like Piper, Kokoro, MeloTTS, and Parler-TTS can shift as new releases land.
What unites these projects isn't a single architecture. It's a shared design constraint: inference must be fast and cheap enough that running it locally makes more sense than calling out to an API.
The version of this argument that loses credibility fast is the one that pretends quality is no longer a variable. It is. If you're producing premium long-form narration where nuance and emotional range are part of the product, the largest hosted models still hold an edge. I'd be doing you a disservice to say otherwise.
But that's a narrow use case. For notification audio, IVR systems, conversational interfaces, accessibility tooling, and embedded voice in applications, the small models clear that bar comfortably, in my experience building and evaluating these systems. The quality gap has narrowed to the point where it's simply no longer the deciding variable for most production workloads.
Formal MOS evaluations with consistently documented methodology are not uniformly available across Kokoro, MeloTTS, and Piper. Where published evaluation data exists, it should be read in the context of its methodology. In the absence of directly comparable data, I'd say the honest test is a listening session with your actual use case audio rather than a benchmark score from a different context.
Cloud TTS is commonly priced according to usage, often per character or per million characters. Services such as AWS Polly and Google Cloud Text-to-Speech use usage-based pricing models, although the live figures should always be checked at the time of evaluation because pricing can change.
The structural point doesn't depend on the specific number: every request you send to a cloud endpoint has a billable unit attached. At low volume, that's invisible. At scale, it compounds in ways that aren't always apparent from an initial cost estimate. I've seen teams build reasonable-looking unit economics at pilot stage and then face a very different conversation six months later when usage grew.
Self-hosted inference doesn't have that same relationship between usage and price. Once the infrastructure is running, the marginal cost of additional synthesis is primarily the compute and infrastructure required to serve it rather than a per-character API charge. That's not a minor difference in pricing model; it's a different structural relationship between usage and cost. Whether that trade-off makes sense for your situation depends on your volumes, your operational maturity, and frankly how much you trust your usage forecast. But I'd argue it deserves a proper analysis rather than being skipped because "cloud is easier to start with."
It usually is easier to start with. In my experience, that instinct quietly builds a liability for teams whose usage grows faster than their budget assumptions accounted for.
There's a physics floor on latency to any cloud endpoint. Round-trip time across a network has an irreducible minimum set by distance and routing, and no amount of engineering on either side closes that gap. For applications where voice response is part of an interactive loop, that floor matters. A local model running on the same hardware as your application has no network round-trip component. Inference time and local processing become the main parts of the latency budget.
For notification systems where audio is generated ahead of time, this is a non-issue. For conversational agents where a user is waiting, it's a genuine design constraint. I'd flag this not because cloud TTS can't be made fast enough for most cases, but because the architectural implications differ and that difference should be a conscious choice rather than a default.
Repository signals for Piper, Kokoro, MeloTTS, and Parler-TTS have been moving in one direction: growing community interest, continued development, and more integrations appearing in ecosystems that didn't treat open TTS as a serious production option a few years ago. The exact repository figures move quickly, so a fresh snapshot should be pulled when evaluating any of these projects.
Let me be clear - this is my reading of available signals, not a confirmed industry measurement. The adoption curve looks like a maturity threshold has been crossed. Adoption is moving from enthusiast projects and edge deployments toward production workloads at companies with real users and real uptime requirements. The tooling has matured to the point where self-hosting a competent voice can be roughly a weekend of work for a developer who's done it before, and a short but learnable project for one who hasn't.
That's a meaningful shift. It wasn't true in the same way three years ago.
I'd flip the default. Instead of starting with a cloud TTS integration and switching later if cost becomes a problem, I'd start by evaluating whether a small local model meets your quality bar. If it does, you've saved yourself a migration conversation down the road. If it doesn't, you have a clear and specific reason to use hosted infrastructure, and that clarity is worth having.
The models worth starting with are Piper for low-resource and embedded contexts, Kokoro if naturalness is your primary quality signal, MeloTTS if you need multilingual coverage, and Parler-TTS if controllability matters to your use case. These are models you can download and experiment with today rather than technologies that exist only as research concepts.
On the question of how long integration takes and what it costs to build: these are answerable questions, but they depend on your stack, your existing infrastructure, and whether you're integrating into something already built or making decisions at the start of a new build. I'd be wary of any estimate that doesn't account for those specifics. The right build partner, whether in-house or external, should be able to give you a scoped estimate against your actual requirements rather than a generic range.
After spending years working with technology, I'm more convinced than ever that depth beats breadth. Understanding the architectural trade-offs of a decision matters more than moving fast to the obvious answer. Small TTS models are architecturally well-suited to a wide class of production problems. That's not a prediction about where the technology is heading. It's a description of where it already is.
The question worth asking isn't whether these models are good enough in the abstract. It's whether the teams evaluating them are giving them a serious look, or defaulting to the familiar vendor because the procurement path is easier. In my view, for a growing number of use cases, the easier path and the better path are beginning to converge. That doesn't happen often enough to ignore when it does.
