# SOV-Transcribe-1 Setup: Audio Limits, Memory and Transcription Checks

Salesforce's open-weight speech model offers useful formatting controls, but its active parameter count and tested audio length can mislead deployment planning.

By Paras Madan | 2026-11-13

Salesforce released SOV-Transcribe-1 on November 12 for non-streaming speech recognition. It supports instruction-controlled transcription and contextual vocabulary hints under Apache 2.0. Before deploying it, separate three questions: whether the weights fit your machine, whether your serving endpoint accepts the recording, and whether important names and numbers survive transcription.

The [launch announcement](https://huggingface.co/blog/salesforce-sovereign-intelligence/sov-transcribe-1) emphasizes four billion active parameters. The detailed model card counts 26.6 billion total and 4.6 billion active, including the audio encoder. **Active parameters are not the amount of model you need to store.**

## Plan memory around the whole model

A simple calculation puts 26.6 billion parameters at two bytes each at roughly 53.2 GB in decimal units, before runtime allocations. That is an illustrative weight-payload calculation, not a minimum VRAM specification: the checkpoint also uses FP32 routing, and caches, batching and framework overhead change the result.

The distinction matters when comparing this model with a small dense speech recognizer. Sparse activation can reduce computation without making all the remaining weights disappear. Do not book a small GPU based only on the four-billion headline.

The [model card](https://huggingface.co/salesforce-sovereign-intelligence/SOV-Transcribe-1) documents Transformers versions from 5.19 up to, but excluding, 5.23, plus a repository plugin for vLLM 0.32.0 while upstream integration is pending. Use that versioned setup rather than assuming an arbitrary current installation already knows the architecture. Review and pin the repository revision before enabling its custom modeling code.

## Thirty-minute model support is not a thirty-minute endpoint default

The model card reports testing audio up to 30 minutes, but its vLLM transcription endpoint defaults to 600 seconds per request. The documented setting for a 30-minute request is `VLLM_MAX_AUDIO_DECODE_DURATION_S=1800`.

If a 20-minute recording fails while a short clip works, check this request-duration limit before changing the model or increasing concurrency. Then inspect output length separately. Accepting all the audio does not guarantee the generation budget can hold its complete transcript.

For a first evaluation, choose short, consented or synthetic recordings. Increase duration gradually and check the final spoken sentence against the final transcribed sentence. This simple check catches a failure that aggregate accuracy metrics can obscure: a convincing transcript that quietly stops before the recording does.

## Keep style and factual accuracy separate

The model supports verbatim transcription and cleaner written output. Pick the intended style before scoring results. Removing a hesitation may be appropriate for a dictated email and wrong for a transcript intended to preserve exactly what was said.

Here is a suggested evaluation fixture, not an observed model result. Record: “Please send the revised quote to alex underscore lee at example dot com. The order number is seven zero four two.” In your scoring sheet, the critical fields are `alex_lee@example.com` and `7042`. Check them independently from punctuation and filler handling.

Run the same recording first without vocabulary hints and then with a short list of relevant names or terms. Include another recording where a hinted term is absent. Otherwise, a context list that makes the intended example look better could still encourage an incorrect insertion elsewhere.

Keep the instruction, reference transcript and normalization policy with each result. Comparing a cleaned transcript with a verbatim reference can turn a formatting difference into an apparent recognition error. Comparing only cleaned text can hide the loss of a significant repetition or correction.

## Read the benchmarks at the level of the task

Salesforce reports a 76.3% recording-level success rate and 93.4% entity recovery on VoiceCodeBench. Those measures are not interchangeable. A system can recover most entities overall while failing recordings that require every critical field to be correct.

For an order-entry workflow, measure whether every required field matches before allowing the transcript to drive an action. For searchable meeting notes, a different acceptance threshold may be reasonable. The benchmark ranking does not decide that threshold for you.

## Add speculative decoding after the baseline works

A separate DFlash checkpoint is available for faster decoding. The published reproduction protocol disables it, while the serving examples enable it separately. Treat acceleration as another configuration to evaluate, not part of the first troubleshooting step.

Start with one request at a time and record memory, complete output and entity accuracy. Add batching or a draft model only after that baseline is dependable. If several configuration changes arrive together, you will not know which one caused a regression.

The practical value of open weights is the ability to inspect and control this deployment. Use that control to define what a correct transcript means for your product, rather than replacing one headline accuracy number with another.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain model releases, deployment trade-offs and developer workflows clearly.

[Book a 30-minute call](https://cal.com/paras-madan/30min)