How to use quality control

Voice cloning models can occasionally hallucinate - producing audio that doesn’t match the input text, drops words, or includes leaked content from the reference clip. The Instant Voice Cloning API includes a built-in quality control (QC) pipeline that catches these issues before returning a response.

What QC checks

QC is off by default. Set enable_qc=true to enable it; the generation is then verified through three checks:

ASR transcription

The generated audio is transcribed back to text using Sarvam’s ASR model.

Character error rate (CER)

The transcript is compared against the input text to compute character error rate. A high CER is flagged, but does not by itself cause the generation to be replaced.

Prompt-leak detection

The output is checked to ensure it doesn’t contain leaked content from the reference clip’s transcript instead of the requested text.

Of these, only a detected prompt leak causes the audio to be regenerated, using a different reference, with bounded attempts. The other checks are advisory.

Default behavior

QC is off by default, so a plain request returns as soon as the audio is generated:

from sarvamai import SarvamAI
client = SarvamAI(api_subscription_key="YOUR_SARVAM_API_KEY")
# enable_qc defaults to false
response = client.voice_cloning.convert(
    voice_id="svc-your-voice-id",
    text="Hello world",
    language_code="en-IN",
)

Enabling QC

Set enable_qc to true to run the verification step:

response = client.voice_cloning.convert(
    voice_id="svc-your-voice-id",
    text="Hello world",
    language_code="en-IN",
    enable_qc=True,
)

Enabling it is appropriate when:

Output reliability matters more than latency

Customer-facing audio you will not listen to before it ships, where a rare malformed generation is worse than a slower response.

When to leave QC off

The default is appropriate when:

You need the lowest possible latency

Skipping QC keeps the ASR and verification step out of the response path. This matters most for interactive and real-time use, and for code-mixed text.

You’re running internal experiments or batch tests

For benchmarking the raw model behavior, you may want to see ungated outputs - including any failures - rather than the post-QC results.

You’re applying your own quality checks downstream

If you have a custom verification pipeline (e.g. domain-specific phoneme matching, custom acceptance criteria), you may not need the built-in QC step.

VAD trimming

Alongside QC, the API trims leading and trailing silence from the generated audio using voice activity detection. This is controlled by enable_vad and also defaults to true. Disable it only when your downstream pipeline expects untrimmed output.

What you’ll see when QC runs

QC is internal - there’s no separate field in the response indicating which generation passed which check. From the caller’s perspective, a successful response simply means a QC-passing audio file was produced.

If QC is enabled and the API can’t produce a passing generation, you’ll receive a 502 or 503 error (code: model_call_error) rather than a successful response. In that case, see the Errors & Troubleshooting guide for next steps - both are safe to retry.

Best practices

Decide QC per use case, not globally

Enable it where a bad generation reaches an end user unreviewed. Leave it off for interactive paths, for code-mixed text, and anywhere you already verify output downstream.

Log request_id values

Every response includes a request_id. Log it alongside your generations so you can reference it when reaching out to support - especially when investigating QC-related failures.

Watch for repeated QC failures on specific text

If certain inputs reliably fail QC (e.g. text with many proper nouns, unusual transliterations, or extreme code-mixing), reformat the input or break it into shorter segments. The model handles concise, well-formed sentences most reliably.

Next steps