Text to Speech Models: Capabilities and Selection Guide

Neural and AI-generated voices accounted for 67.90% of text-to-speech market revenue in 2024, according to Sonix's industry-trends report. That measures revenue, not reliability. For a developer choosing text to speech models, the harder question is whether a voice can deliver the names, codes, instructions and emotional dialogue that an application sends.

A pleasant demo doesn't answer that question. Treat model selection as an input-and-output contract, followed by a production-text evaluation. Architecture, voice similarity and average naturalness matter, but none should override a failure that changes what the listener understands.

Table of Contents

• Capabilities, Inputs and Outputs at a Glance
  • Choose the Audio Contract Before the Voice
• Architecture Families and What They Mean
  • Read Model Cards as Pipeline Descriptions
• Voice Cloning, Scale and Language Coverage
  • Separate Similarity From Performance
• Quality Metrics That Go Beyond MOS
  • Define What Your Stopwatch Includes
• Building a Test Set for Difficult Text
  • Include Text That Changes Meaning When Misread
  • Run a Repeatable Comparison
• Matching Models to Your Use Case
  • Apply Hard Gates Before Preferences
• Consent, Disclosure and Safe Voice Use
  • Build Controls Into the Request Path
  • Evaluate Who the System Serves
• Hosted APIs or Self-Hosted Open Models
  • Compare the Whole Operating Cost
  • Test the Serving Path, Not Just the Weights
• Shortlist, Test and Sign Off
  • Keep Integration Convenience Separate From Acceptance
  • Require a Named Release Decision

Capabilities, Inputs and Outputs at a Glance

Standard TTS is the simplest contract: submit text and receive speech. Use it for prepared narration, notifications and passages whose wording is already complete. A downloadable file suits editing and caching; a streamed response can avoid waiting for the entire audio file.

Streaming TTS needs closer inspection. Some services stream audio after receiving a complete text input, while others accept incremental text too. If an assistant generates its reply progressively, confirm that the interface supports the latter rather than assuming that streaming means both directions.

Markup-controlled synthesis adds delivery instructions. SSML, pronunciation controls and proprietary style tags aren't interchangeable, so test the exact syntax your selected model accepts. Unsupported instructions might be ignored, rejected or spoken aloud.

Cloning adds a reference-speaker input, while multilingual synthesis adds language coverage. Neither automatically includes the other: a multilingual preset voice isn't necessarily cloneable, and a cloned voice isn't necessarily reliable in every supported language.

Choose the Audio Contract Before the Voice

WAV is a container; PCM describes an audio representation. Uncompressed PCM, often packaged in WAV, is convenient for editing and processing. Telephony pipelines need the encoding, channel configuration and sample rate their downstream systems expect, not just a file with a familiar extension.

MP3 and Opus are compressed delivery options for browsers and applications, subject to client support. Select a format that your player can decode without an extra conversion stage. Otherwise, your measured synthesis performance won't describe the delay users experience.

Sample rate specifies how frequently audio is sampled. It affects the represented frequency range and, for uncompressed audio with other settings fixed, file size. Raising the output sample rate doesn't repair unclear pronunciation or restore detail that the model never generated.

Before integration, write down the contract:

• Input constraints: Accepted text length, supported markup and incremental-input behavior.
• Voice availability: Required languages, dialects, preset voices and custom-voice access.
• Output requirements: Encoding, sample rate, channels and streaming behavior.
• Failure behavior: How the application handles rejected text, interrupted streams and unavailable voices.

Read the table from left to right: match the input you have to the output you need, then check whether the use case fits. A voice that sounds excellent but requires the wrong interaction pattern belongs outside the shortlist.

Architecture Families and What They Mean

The broad pipeline distinctions are illustrated below.

Concatenative systems assemble recorded units, so their flexibility is bounded by the available recordings and the joins between them. Statistical parametric systems instead predict acoustic properties, then render speech through a vocoder, trading direct reuse of recordings for a more controllable synthesis pipeline.

A milestone arrived with WaveNet in 2016: the WaveNet paper reported a reduction of more than 50% in the quality gap between the strongest existing TTS systems and human speech in its US English and Mandarin Chinese evaluations. That finding established the importance of neural waveform generation, not a universal performance guarantee for every later neural model.

Token-based neural systems predict discrete audio representations that a decoder turns into sound. For buying decisions, distinguish this representation from the service interface: an end-to-end product can still contain several internal processing stages.

Read Model Cards as Pipeline Descriptions

Look for spectrogram, vocoder, codec, audio tokens and speaker-conditioning details. A spectrogram stage followed by a vocoder suggests an acoustic-model pipeline; discrete audio codes suggest token-based generation. Training descriptions help explain the design, but they don't replace output testing.

For constrained devices, compare actual memory, runtime and hardware compatibility rather than assuming older means smaller or newer means cloud-only. In hosted deployment, inspect the delivered latency and controls rather than inferring them from the architecture label.

The boundary also matters for adjacent tasks. A singing voice synthesis guide addresses a different control problem: spoken prosody isn't a substitute for explicit musical timing and pitch.

Practical rule: Use architecture to understand likely constraints and useful diagnostic questions, not to declare a winner before listening.

Voice Cloning, Scale and Language Coverage

Voice cloning separates speaker identity from the words being spoken. Evaluate those dimensions independently: an output can resemble the reference speaker while delivering the sentence with unsuitable emotion.

The main cloning routes differ in how they establish that identity.

Zero-shot cloning conditions synthesis on reference audio without a separate speaker-specific training job. Custom voice training adapts a model using a prepared speaker dataset. The former reduces setup work; the latter adds recording, preparation and training requirements, without making similarity automatic.

Reference quality deserves its own test. Background noise, competing speakers, inconsistent microphone placement and sharply different delivery styles can make it harder to determine what the system should preserve. Compare clean references before attributing a weak result entirely to the synthesis model.

Separate Similarity From Performance

Consider a hypothetical comparison between a short, neutral reference and a longer reference containing several emotional deliveries. Generate the same upbeat marketing line from each. Ask listeners separately whether the speaker sounds recognizable and whether the upbeat delivery sounds appropriate.

Don't assume the longer reference must win. It contains more material, but it also introduces more variation; the useful question is whether the model preserves identity while following the requested performance.

For an audiovisual introduction to the topic, the following video provides another viewing format.

Scale provides context, not sign-off. In its 2024 coverage, TechCrunch reported that BASE-large used 100,000 hours of public-domain speech for training and contained 980 million parameters. Those totals don't establish how a particular accent, speaker or language will perform.

When examining a multilingual TTS model listing, turn the advertised capability into concrete acceptance checks:

• Language coverage: Evaluate each required language and dialect with fluent listeners.
• Identity stability: Compare the speaker across questions, statements and expressive dialogue.
• Fallback readiness: Identify an approved preset voice for unavailable or unsuitable clones.
• Reference provenance: Retain the recording identifier and its associated permission record.

A recognizable voice is only useful when its delivery remains understandable and appropriate across the product's actual messages.

Quality Metrics That Go Beyond MOS

A benchmark can be reproducible without being representative. The LJSpeech dataset contains 13,100 clips totaling approximately 24 hours, recorded by a single English-speaking female narrator. That's useful for controlled comparisons, but success within that scope doesn't establish broader performance across speakers, accents or conversational styles.

Mean Opinion Score, or MOS, measures listener-rated perceived quality. Keep the sentences and listening conditions consistent across models, conceal model identities and define the rating question clearly. A panel asked about pleasantness isn't necessarily evaluating whether a product code was spoken correctly.

Define What Your Stopwatch Includes

For streaming, distinguish first received audio from first audible playback. Network transfer, decoding and player buffering belong to the user experience, even if they occur outside model inference. Record both when diagnosing delay.

For intelligibility testing, compare recognized speech against the intended spoken form, not blindly against raw input characters. An acceptable spoken date won't match its written notation character for character. Manually review errors involving names, numbers and symbols before treating the recognizer as ground truth.

A quality average is a description of a test. It isn't an acceptance criterion until you define which errors the product can tolerate.

Pair automated checks with listening. Pitch measurements alone don't describe rhythm, stress or intensity, and waveform differences don't necessarily mean listeners hear a meaningful change.

Report MOS, intelligibility, time to first audio and real-time factor together. Include the model version, runtime environment, request settings and measurement boundaries so another engineer can interpret the result.

Building a Test Set for Difficult Text

Generic sentences make weak acceptance tests because they omit the text that requires interpretation. EmergentTTS-Eval evaluates six scenarios across 1,645 samples, covering emotion, prosody, intonation and pronunciation; its authors report strong correlation between model-based judging and human preferences.

Use that broader approach without treating an external benchmark as your product's test suite. Your application has its own vocabulary, formatting and consequences for mistakes.

The evaluation categories below help expose failures that easy reading passages won't.

Include Text That Changes Meaning When Misread

• Names and locations: Product names, brands, personal names, addresses and postcodes.
• Compact identifiers: Acronyms, account references, product codes and ambiguous abbreviations.
• Structured notation: Dates, times, URLs, code fragments and mathematical formulas.
• Language changes: Foreign words and mixed-language passages.
• Conversational intent: Questions, reassurance, urgency, disagreement and emotionally loaded dialogue.
• Non-speech cues: Laughter, sighs and other supported performance instructions.

For every item, record the intended reading. A code might require character-by-character spelling, while an acronym might need pronunciation as a word. Without that annotation, listeners can disagree about correctness even when they hear the same output.

Run a Repeatable Comparison

1. Collect representative text. Extract and anonymize production examples, then tag them by category. Include uncommon inputs whose failure would have serious consequences.
2. Generate comparable outputs. Keep format, voice role and delivery instructions equivalent where possible. Save the exact request and model identifier.
3. Use consistent listeners. Ask the same panel to assess intelligibility, pronunciation and prosodic appropriateness separately. Shuffle model order.
4. Capture performance per item. Record first-audio timing and real-time factor alongside the associated text, rather than keeping only a batch average.
5. Repeat after changes. Preserve an approved baseline and investigate regressions when a provider, voice configuration or preprocessing rule changes.

Say a support prompt contains a customer's surname and an appointment date. A beautifully delivered sentence that gets either wrong should lose to a less expressive but accurate alternative.

Report failure rates by category and severity. An aggregate score can conceal the very class of error that should block deployment.

Matching Models to Your Use Case

A model's strongest feature only matters if it supports the job. The following comparison illustrates the different priorities.

For customer support, test the actual phone path rather than reviewing studio-quality downloads alone. For audiobooks, listen across paragraph boundaries, speaker changes and resumed generation, because isolated sentences don't exercise continuity.

Accessibility evaluation should include the people who'll use the output and their preferred playback controls. Dubbing needs a reference performance and timing constraints; education needs subject-matter review of the intended spoken notation.

Apply Hard Gates Before Preferences

If latency defines the interaction, require a suitable streaming interface before ranking voices. A delayed response can fail the interaction design regardless of its eventual quality.

If a specific speaker identity is mandatory, establish permission before creating evaluation clones. Don't make authorization a production-only concern after the team becomes attached to a voice.

If codes and dates carry the message, prioritize their correct reading over pleasantness. Treat critical pronunciation errors as blockers rather than letting strong style scores compensate for them.

Selection principle: Rank acceptable models after applying hard requirements. Don't average a disqualifying failure into an otherwise attractive score.

Write those gates before reviewing results. For example, a course narrator may need reliable technical vocabulary but not conversational streaming, while a voice assistant may need incremental text input but no cloning. That distinction narrows the comparison without relying on a universal leaderboard.

Consent, Disclosure and Safe Voice Use

Voice cloning is a governance decision, not just a synthesis setting. The responsible-TTS guidance describes the FCC's classification of AI-generated robocall voices as artificial voices under the Telephone Consumer Protection Act, making covered calls without the required prior consent unlawful. Don't interpret that as a blanket ban on synthetic narration or as permission for every non-robocall use.

Ordinary synthetic narration and identity-preserving cloning require different operational scrutiny. Selecting a licensed preset voice doesn't establish the right to imitate an identifiable person. For custom voices, documented speaker permission should be a deployment requirement.

Build Controls Into the Request Path

• Record speaker permission: Keep the authorized purpose, permitted channels, scope of use and expiry or review conditions with the voice record.
• Reject unauthorized imitation: Prohibit cloning identifiable people without written permission and provide a way to suspend disputed voices.
• Apply disclosure rules: Label synthetic speech when applicable law, platform policy or the context requires it.
• Preserve auditability: Log the model identifier, voice identifier, request time and authorization reference without unnecessarily duplicating sensitive text.
• Maintain safe alternatives: Approve fallback voices that aren't intended to imitate identifiable individuals.
• Retain model metadata: Store disclosed training-data sources, licenses, usage restrictions and relevant evaluation documentation.

A permission record also needs a revocation process. Decide who can disable a voice, how cached audio is handled and what happens to scheduled content when authorization changes.

Evaluate Who the System Serves

Test accent, dialect and language performance separately. A global average can conceal a poor experience for a particular speaker group, so preserve group-level results where collection and reporting are appropriate.

Governance must follow routing too. If requests can reach different providers, don't assume a voice authorization or processing agreement applies to every destination. Restrict routing to approved combinations of model, voice and processing terms.

This is general operational guidance, not legal advice. Check the laws and contractual requirements that apply to the speaker, audience and deployment location before release.

Hosted APIs or Self-Hosted Open Models

Deployment determines what you control and what you must operate. A hosted API moves model serving to an external operator. Self-hosting gives your team responsibility for the runtime, capacity, updates and access controls.

Open weights don't automatically mean unrestricted commercial use, offline suitability or low hardware requirements. Inspect the license and runtime requirements before investing in integration. Likewise, a hosted endpoint doesn't automatically provide fixed versions or a particular data-residency arrangement.

Compare the Whole Operating Cost

Hosted deployment can suit variable demand and teams that don't want to operate inference hardware. Confirm the billing unit, concurrency limits and how retries are handled before estimating cost. A character-based price alone doesn't describe the full application bill.

Self-hosting can suit offline operation or requirements that prohibit sending text and reference recordings outside controlled infrastructure. It still requires capacity planning, monitoring, security updates and a reproducible release process. A model that runs on a workstation isn't necessarily ready for concurrent production traffic.

Treat the Qwen TTS model listing as a discovery point for a candidate, not proof of its suitability for a particular hosting arrangement. Confirm the actual runtime, license and interface for whichever deployment you evaluate.

Test the Serving Path, Not Just the Weights

Use the same anonymized corpus on hosted and self-hosted candidates. Keep the playback format and test client consistent, then measure under the concurrency and request patterns the application expects.

Record whether the test includes startup, loading, queuing and conversion. Otherwise, a warm local benchmark and a complete remote request aren't comparable.

If your test set contains personal information, review data-handling terms before transmitting it. Remove unnecessary identifiers even when the destination is approved, and restrict access to reference recordings independently from ordinary application text.

Shortlist, Test and Sign Off

A shortlist should express requirements, not brand familiarity. Keep candidates that meet the input contract, required languages, operating constraints and voice-authorization conditions. Exclude models that can't satisfy a hard requirement before spending listening time on them.

Use a release procedure that leaves an inspectable decision record:

1. Select compatible candidates. Document why each model fits the required inputs and outputs. Separate mandatory features from preferences so reviewers know what can be traded off.
2. Run and review the difficult-text suite. Keep raw outputs, listener judgments and timing records. Investigate critical errors instead of accepting an attractive aggregate score.
3. Approve rights and processing terms. Verify the model license, reference-audio authorization and intended use of every custom voice. Assign an owner to unresolved conditions.
4. Freeze the approved configuration. Pin versions where supported, save preprocessing and delivery settings, and require regression testing when the serving configuration changes.

Keep Integration Convenience Separate From Acceptance

UberLLM provides access to Claude, GPT, Gemini, DeepSeek, and image, video and music models through an OpenAI- and Anthropic-compatible endpoint. A common API key and prepaid balance consolidate access, and changing the model identifier supports candidate comparisons without a separate provider integration for each model; model-specific speech parameters still need checking.

Qwen3 0.6B TTS is listed at $0.035 per 1K characters, against a list price of $0.0875 per 1K characters. Confirm current pricing on the provider's listing before budgeting, and compare costs only among candidates that meet the acceptance criteria.

Require a Named Release Decision

Give the sign-off record an owner and preserve the approved audio examples. Record exceptions explicitly, including any text categories that require preprocessing, a fallback voice or human review.

A release decision should remain understandable after the people who ran the evaluation move to another project. The final check is simple: Does the chosen model pass the difficult-text test, and does the consent record cover every cloned voice?

---

UberLLM offers a unified API for comparing and integrating speech alongside other model types. Visit UberLLM to inspect speech candidates, then run your anonymized names, codes and emotional dialogue through the models that meet your input requirements before choosing a production configuration.