Skip to main content

Stack target

TechniqueTriggerWinPlan
Streaming chunked synthesisStreaming-capable TTS deploymentsLower time to first byteCore
Same-speaker batchingMulti-request workloadsLess padding waste, higher throughputCore
Throughput bulk batchingBulk synthesis pipelines (narration, audiobooks)Higher sustained throughputCore
F5-TTS sampling-step reductionF5-TTS family with compatible runtimeFaster synthesis with quality guardrailsCore
Planned, not yet available: reference voice embedding cache, KV cache tuning for autoregressive decoders, causal vocoder tuning, and per-voice adaptation. These are research targets for a later TTS quality harness release and are not selectable today.

Quality gates

MetricCeilingSource
Transcript WER deltaUnder 1.5 percentage pointsWhisper-large-v3 transcription of generated speech
MOS proxy scoreAt least 0.85 for serving qualityUTMOSv2-normalized speech quality scoring
Speaker similarityAt least 0.75 for reference-audio clone lab sessions unless overriddenECAPA reference voice comparison
Quality floorAt least 0.85RunInfra ranking gate
Transcript WER verifies what the generated audio says. MOS proxy and speaker similarity verify how the audio sounds and whether it matches the requested voice. RunInfra keeps these evidence paths separate before promotion. TTS serving quality uses the MOS proxy gate. Transcript WER is supporting intelligibility evidence and does not substitute for speech quality. Certification requires an explicit passed MOS/UTMOS quality gate on the optimized artifact; a raw mosProxyScore field alone is not enough. Reference-audio TTS optimization requires a paired reference clip and exact reference transcript. The lab treats those fields as part of the measured request identity, so evidence captured for one reference voice cannot be replayed for a different voice-clone request. When reference audio is present, the live runner asks the Modal measurement path for speaker-similarity evidence before promotion.

Detection, routing, and application

DecisionSelection ruleRuntime behavior
Response formatUser request and deployment supportSelects wav, mp3, pcm, or another supported format
StreamingExplicit ttsTraits.supportsStreaming=trueEnables streaming response mode where available
Same-speaker batchingExplicit ttsTraits.benefitsFromSpeakerBatching=trueGroups compatible requests to reduce padding waste
Reference voice requestDeployment-supported voice, or paired refAudio and refTextSends the voice or clone fixture through the native speech endpoint
TTS family detectionModel architecture, config, and tagsChooses family-specific variants for F5-TTS, CosyVoice, XTTS, Kokoro, Bark, Parler, Qwen3-TTS, and related families
F5-TTS sampling-step reductionExplicit ttsTraits.supportsNfe=trueSends the reduced-step setting only to compatible deployments
When TTS traits are absent or unknown, the optimizer exposes only conservative TTS transcript quality, MOS proxy speech quality, and throughput bulk techniques. It does not infer streaming, same-speaker batching, or F5 NFE from model name text.

Verification

  1. The optimization plan should show the selected TTS technique and why it applies.
  2. The benchmark response should include the effective response format and streaming mode.
  3. Reference-audio clone runs should record the fixture id, reference audio, and reference text on the execution manifest.
  4. Quality checks should compare generated audio against transcript, MOS proxy, and speaker-similarity gates before promotion.
  5. Reference-audio clone sessions should fail promotion if the Modal measurement path cannot return measured MOS proxy or speaker-similarity evidence.
  6. Reference-audio clone certification also requires measured baseline speaker similarity. Missing optimized speaker similarity, a score below the configured floor, or optimized speaker-similarity regression versus baseline blocks promotion.
  7. Production voice certification requires five consecutive passing optimization artifacts from different voice model/modality pairs, each inside the 2x to 4x measured speedup band with measured baseline speech-quality evidence, an explicit passed optimized MOS/UTMOS quality gate, and no MOS/UTMOS or required speaker-similarity regression. Repeated artifacts for the same model do not count as five wins, and any failed voice run resets the streak.
  8. The default voice certification gate also requires passed ASR coverage. Five TTS-only wins do not certify the overall voice model type.
  9. Paid Modal voice-suite readiness requires at least five distinct ready ASR/TTS model/modality sessions and must include both ASR and TTS before paidWorkCanStart=true. Planned but blocked voice-pipeline sessions do not satisfy this paid-start threshold.
  10. Official saved-evidence certification is source-bound. The certification command must include --expected-source-commit-sha <40-character Engine git SHA>, normally derived from RUNINFRA_SOURCE_REVISION by the voice-suite readiness report. Every generated ready session command must also include --source-commit-sha <same Engine git SHA> so the suite-session producer and sandbox provenance stamp matching source revision evidence such as sourceCommitSha or runinfraSourceRevision onto produced Modal artifacts. Missing, malformed, or mismatched source evidence blocks certification.
  11. TTS optimization evidence is Modal-only. Each certifiable win must carry strict Modal call evidence for the measured optimization sweep: fc- plus 26 alphanumeric characters. Handwritten or placeholder fc-* strings are rejected. The optimized winner must also carry winner-bound applied optimizer technique or receipt evidence; run-level optimization metadata alone is insufficient. Baseline, benchmark, measurement, manual, mock, placeholder, RunPod, or generic tool-label evidence is rejected. If baseline and optimized candidates are measured by separate Modal calls, the saved run must bind those calls in run-level modalCallIds; unbound split calls are rejected. When candidate-level model identity, model-revision identity, serving-backend identity, request/reference fixture identity, or hardware/load measurement identity is present, the baseline, optimized, and saved run identities must match exactly, so cross-model, cross-revision, cross-backend, cross-fixture, cross-hardware, and cross-load speedups are rejected. Explicit passed baseline and optimized MOS/UTMOS quality gates must share at least one benchmark identity for the same metric; cross-benchmark quality comparisons are rejected. If a quality gate or nested benchmark result cites explicit Modal call evidence, that call must be strict and bound to the same optimization sweep; unrelated quality-gate Modal calls are rejected. Official TTS suite runs synthesize three prompts by default, and the Modal result must expose num_samples plus MOS proxy sample coverage fields. Partial MOS or speaker-similarity coverage across generated samples blocks promotion. When measured sample counts are present on baseline or optimized latency evidence, each count must meet the minimum certification floor; undersampled speedups are rejected. Artifacts that name RunPod as the optimization provider, target, quality-gate source, or benchmark provenance, including nested benchmark result records, are rejected because RunPod belongs to BYOC deployment and canary validation, not voice optimization certification.
  12. The owner-approved paid streak runner only treats final certification as certified when the final saved report includes summary evidence for at least five tested and passed runs, a longest consecutive pass streak of at least five, at least five unique passed models, passed ASR and TTS coverage, empty blockers, empty missing required modalities, and modalResultVerification with the planned Engine source SHA, no verification failures, and strict verified Modal call ids covering every passed run.

Rollback

constraints.customerOverrides = {
  skipTechniques: ["streaming"],
};

Availability notes

  • F5-TTS sampling-step reduction is available only when model research carries explicit NFE support.
  • Family-specific streaming depends on explicit TTS traits from model research and runtime support.
  • Reference voice cache, autoregressive KV cache tuning, causal vocoder tuning, and per-voice adaptation are planned for a later product release and are not available today.