Most TTS decisions are framed as a choice between providers. The more fundamental choice is between architectures: cloud TTS, where audio is generated on a remote server and streamed back over a network, and on-device TTS, where the model runs locally with no external dependency.
The two architectures solve different problems within a product's voice layer, and many products use both within the same application. The right question is not which architecture is better overall, but which one is right for each part of your product's voice surface.
What is cloud TTS and what does it provide?
Cloud TTS sends text to a remote API, which synthesizes audio and streams it back. The model runs on server-side hardware (typically GPU), which allows large, high-quality models to run without any constraint on the client device. Audio arrives over the network as a stream.
The main properties that cloud TTS provides:
Breadth across voices, languages, and content types. A cloud TTS model is not scoped to a specific voice or use case. It handles any input, any voice from a library, any of its supported languages, and any content type from a single endpoint. This flexibility is difficult to achieve on-device, where the model is typically scoped and fine-tuned for a specific deployment.
Real-time streaming with low TTFA. Gradium's cloud TTS API records 155 ms TTFA P50 on the independent Coval production benchmark (benchmarks.coval.ai/tts, May 4, 2026), the lowest of all 9 streaming TTS models tested. This is achievable because server-side GPU inference is fast, and the API streams audio incrementally before synthesis of the full text is complete.
STT, voice cloning, and full pipeline integration. Cloud TTS APIs like Gradium pair with STT, semantic VAD, and voice cloning in the same platform. A complete voice agent pipeline (STT, LLM, TTS) runs on cloud infrastructure with all components accessible from a single API key. On-device models typically cover TTS only.
No client-side compute or storage. The client device does not run inference. Any device with a network connection and audio output can use the API.
What is on-device TTS and what does it provide?
On-device TTS runs the synthesis model entirely on the end-user's device. No text is sent to a server. No audio is received over a network. Generation happens locally and playback can begin immediately.
Gradium Phonon is Gradium's on-device TTS model. At approximately 100 million parameters, it runs at 6x real-time on a single CPU core without GPU acceleration, supports Android, iOS, and browser, and supports voice cloning from a 10-second audio sample across English, French, German, Spanish, and Portuguese (July 2026 multilingual update).
On the Seed-TTS English benchmark (vendor-published, Gradium evaluation):
| Configuration | WER |
|---|---|
| Phonon with voice cloning (May 2026) | 1.00% |
| Phonon with fixed voice (May 2026) | 0.83% |
On the Phonon Multilingual benchmark (Gradium evaluation, July 2026), in comparison to NVIDIA Magpie TTS:
| Language | Phonon WER | Magpie WER | Gap |
|---|---|---|---|
| German | 0.50% | 1.47% | 2.9x lower |
| Spanish | 0.53% | 1.84% | 3.5x lower |
| French | 2.18% | 3.48% | 1.6x lower |
Source: gradium.ai/blog/phonon-multilingual-smaller-clearer-better, July 2026. Phonon produces up to 3.5x fewer word errors than Magpie TTS at 3.6x fewer parameters.
The main properties that on-device TTS provides:
No network dependency. Generation works fully offline. The interaction requires no connectivity.
No round-trip latency floor. Cloud TTS latency has a floor set by network transmission time. On-device synthesis eliminates this floor entirely: the model runs locally and audio can begin playing the moment the first audio chunk is generated.
Fixed cost per device, not per request. Phonon uses a license model. Once deployed, generation is unlimited with no per-call billing.
Full data privacy by design. Text never leaves the device. This is categorically different from cloud deployments with HIPAA BAAs or GDPR agreements, which still involve data transmission.
Which constraints determine the right architecture?
1. Network dependency
If reliable network connectivity cannot be assumed for the use case, cloud TTS is not viable. On-device TTS is the only architecture that works fully offline.
Applications that fall into this category include: consumer apps used on mobile connections in areas with poor coverage, field service tools used in buildings or locations without reliable connectivity, automotive and in-vehicle applications, and consumer devices designed to function in airplane mode.
Decision: if the product must work without a network connection, on-device TTS is required.
2. Data privacy requirements
Cloud TTS requires sending text to an external server. For some products, this is constrained by law, contract, or product commitment. Healthcare applications may not be able to send patient-adjacent text off-device. Enterprise applications may have data residency requirements that prohibit sending certain content to third-party APIs. Consumer hardware products may make local processing a product commitment.
On-device means the data does not leave the device at all. This is categorically different from cloud deployments with HIPAA BAAs or GDPR agreements, which still involve data transmission.
Decision: if text to be synthesized cannot leave the user's device, on-device TTS is required.
3. Cost at scale
Cloud TTS pricing scales with usage. For most products, this is the right model: usage scales with value, and the cost per unit is low enough that it does not create a structural problem.
For high-volume consumer applications with large free user bases, the model changes. A consumer app with millions of free users generating TTS requests at volume incurs cloud TTS costs that scale with engagement, including from users who generate little or no revenue. Phonon's license model replaces per-request pricing with a fixed cost per device and model type. Once deployed, the per-generation cost is zero.
Decision: if per-request cloud TTS pricing does not scale economically for the user base, evaluate on-device TTS as a cost structure change at the product level.
4. Breadth vs scope
Cloud TTS offers breadth: any voice, any of its supported languages, any content type. On-device TTS offers depth within a scope: Phonon is fine-tuned for a specific voice, language, and use case. It handles that context with high quality in a compact model. It does not offer the open-ended flexibility of a cloud API.
If the product's voice surface is well-defined (one branded voice, one language, one content type), on-device is viable and often preferable. If the product needs to serve any input, any speaker, and any content dynamically, cloud TTS is the right architecture.
Decision: if the voice surface is well-defined and scoped, on-device TTS can serve it. If breadth and flexibility are required, cloud TTS is the right choice.
Where does each architecture win?
| Constraint | Cloud TTS | On-device TTS |
|---|---|---|
| Requires network connectivity | Yes | No |
| Text stays on device | No | Yes |
| Cost model | Per request | Fixed license per device |
| Model breadth | Any voice, any content | Scoped per deployment |
| Latency floor | Set by network (155 ms P50 Coval for Gradium) | No network floor |
| STT and voice agent pipeline | Included (Gradium) | TTS only |
| Voice cloning | Yes (10s audio, free tier) | Yes (Phonon, 5 languages) |
| Languages | 5 (Gradium cloud: EN, FR, DE, ES, PT) | 5 (Phonon: EN, FR, DE, ES, PT) |
| Runtime hardware | GPU server (client needs no compute) | CPU on device (~100M params) |
| Access | Available now | Private beta (gradium.ai/on-device-tts) |
Why do many products use both?
The two architectures are not mutually exclusive. Within a single product, different parts of the voice surface may have different constraints, and the right architecture for each part may differ.
A consumer language learning app might use the Gradium cloud API for its interactive conversation feature (real-time agent, any content, breadth of voices) and Gradium Phonon for its daily lesson audio playback (offline mode, high volume, specific scoped content). The conversational agent needs cloud TTS because the inputs are dynamic and the full API feature set is required. The lesson audio benefits from on-device TTS because volume is high, offline access matters, and the content is scoped.
A voice AI product for enterprise deployments might use cloud TTS for most use cases and switch to on-premise TTS deployment for specific clients with data residency requirements that prohibit off-device text processing.
The pattern that emerges: cloud for real-time voice agent interactions where quality and flexibility matter, on-device for high-volume playback, offline modes, or privacy-sensitive text generation.
How does Gradium support both architectures?
Gradium is the only provider in this comparison that offers cloud TTS and on-device TTS from the same underlying model family and the same vendor relationship.
Cloud: Gradium's TTS API runs over WebSocket, delivers 155 ms TTFA P50 on the Coval benchmark (May 4, 2026), includes STT with semantic VAD, voice cloning from 10 seconds of audio, and supports cloud, private cloud, and on-premise deployment.
On-device: Gradium Phonon runs at approximately 100 million parameters on a single CPU core, supports Android, iOS, and browser, achieves 1.00% WER with voice cloning and 0.83% without on the Seed-TTS English benchmark, and now covers five languages (EN, FR, DE, ES, PT) with competitive WER against NVIDIA Magpie at up to 3.5x fewer errors per word.
Each Phonon deployment is scoped and fine-tuned for a specific voice, language, and use case. Delivery takes days to weeks. The resulting binary ships inside the application with no external dependencies.
Phonon is currently in private beta. Apply at gradium.ai/on-device-tts.
Glossary
Cloud TTS
Text-to-Speech synthesis performed on a remote server and streamed to the client over a network. Offers high model quality, breadth across voices and languages, and full API feature sets (STT, voice cloning, pipeline integration). Requires network connectivity and involves transmitting text to an external server.
On-device TTS
Text-to-Speech synthesis performed entirely on the end-user's device with no network dependency. Audio is generated locally. Text does not leave the device. Cost model is typically a fixed license rather than per-request. Scope is typically constrained to a specific voice, language, and use case.
Gradium Phonon
Gradium's on-device TTS model. Approximately 100 million parameters. Runs at 6x real-time on a single CPU core. Supports Android, iOS, and browser. English, French, German, Spanish, and Portuguese with voice cloning. Private beta at gradium.ai/on-device-tts.
TTFA (Time to First Audio)
The elapsed time between sending text to a TTS API and receiving the first streamed audio chunk. For cloud TTS, TTFA has a floor set by network latency. For on-device TTS, TTFA is determined entirely by local inference speed with no network component.
Seed-TTS benchmark
A public academic TTS evaluation benchmark (1,008 English utterances). Used to evaluate Phonon's WER and speaker similarity. Gradium's evaluation uses Whisper large-v3 for transcription and WavLM large for speaker similarity, deliberately avoiding Gradium's own STT to prevent model-sharing bias.