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 [[https://github.com/rhasspy/piper\]](https://github.com/rhasspy/piper%5D). 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 [[https://github.com/hexgrad/kokoro\]](https://github.com/hexgrad/kokoro%5D). 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 parameter counts and real-time-factor figures for models like Piper, Kokoro, MeloTTS, and Parler-TTS tend to 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 for Kokoro, MeloTTS, and Piper are not uniformly available in peer-reviewed form.Where published evaluation data exists, it should be cited with methodology noted, though comprehensive MOS scores with documented evaluation methodology are not consistently available across Kokoro, MeloTTS, and Piper.. In the absence of that 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 priced per character or per million characters. AWS Polly and Google Cloud TTS both use this model.The live figures should be checked at the time of your evaluation, because cloud TTS pricing can change over time..
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 property. The marginal cost of an additional synthesis request, once infrastructure is running, trends toward the cost of electricity. 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 such floor. Inference time is the whole story.
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: more stars, more commit activity, more integration packages appearing in ecosystems that didn't acknowledge open TTS as production-ready two years ago.A fresh snapshot of these figures should be pulled within a week of publication, as the numbers move quickly..
I want to be precise about what I'm claiming here. 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 is 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. None of these are research previews. They're deployable today.
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.
Twenty years in, 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 correct for 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. 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, the easier path and the better path have converged. That doesn't happen often enough to ignore when it does.
