AI Technical Articles
SOV-Transcribe-1: Local Audio, Vocabulary and Limits
Keeping audio private is a deployment decision, not a model label. Salesforce’s SOV-Transcribe-1 is interesting because it puts vocabulary hints and transcript instructions inside a system you can run on your own infrastructure.
The useful question is whether that extra control survives the full workflow: audio storage, model execution, logs and exported text. Here is how to evaluate that boundary and test whether terminology hints improve the transcript.
What makes SOV-Transcribe-1 different?
Automatic speech recognition (ASR) converts spoken audio into written text.
The model’s prompt guide lets an instruction accompany the recording. It can request verbatim text, which preserves spoken fillers and repetitions, or a cleaned-up version. Supplying likely names or specialist vocabulary is called context biasing: extra clues that help resolve ambiguous sounds. The hints apply to the request; this is not permanent training of the model.
Context terms are hints to the recognition model, not guaranteed search-and-replace rules. Salesforce’s Contextual Earnings-22 test used 15-second earnings-call clips. Keyword F1, a score balancing recovered terms against false matches, rose from 71.9 without hints to 96.8 with clip-relevant keywords; a full-call list containing distractors scored 94.0. That vendor result suggests testing both relevance and list size on your own audio.
A technical team might therefore test an instruction along these lines:
Transcribe verbatim, retaining filler words. Context: project names are Helios and Northwind; speakers may mention PostgreSQL and Kubernetes.
That is an illustrative test prompt, not a Salesforce benchmark prompt.
For example, a reference to a project named “Helios” could otherwise become an ordinary phrase that sounds similar. A hint narrows the possibilities, but an irrelevant project list could pull recognition toward a word nobody said. Check the audio rather than treating a supplied term as evidence that it was spoken.
Local deployment improves control, but does not guarantee privacy
“Open weight” needs careful interpretation.
Salesforce distributes the weights under Apache 2.0. Weights are the learned numerical values that a runtime loads to perform transcription. Downloading them makes self-hosting possible; the license does not specify where your application stores audio.
Privacy depends on the entire system around it: where recordings are stored, whether the inference environment makes outbound network connections, what the runtime logs, where transcripts are written, and how temporary data is retained. Those are deployment properties rather than guarantees supplied by an open-weight license.
As checked November 14, 2026, the documented Transformers setup loads repository code with trust_remote_code=True; the vLLM route uses a plugin for version 0.32.0 while native integration is being upstreamed. These are software components to review and pin to a known version. The card also supplies a self-contained function; copying it still requires reviewing its code and dependencies.
A practical boundary check starts with a synthetic recording containing a unique test phrase. Run it through the complete workflow and inspect outbound connections, temporary files, logs and the export destination. If the phrase appears in an external monitoring service, keeping the model on your server has not kept the entire transcript there. This is a proposed deployment check, not a test performed for this article.
This is a large model for recorded audio
The model summary lists 26.6 billion total parameters and 4.6 billion active parameters. A mixture-of-experts design selects only part of its computation for each step; inactive weights still have to be stored or moved when needed. The smaller active count is not a promise of a small memory footprint.
For a weights-only estimate, assume two bytes per parameter: 26.6 billion × 2 is about 53.2 GB in decimal units. That excludes higher-precision components, working memory, runtime overhead and optional models. It is not a minimum graphics-memory requirement. The card’s published serving measurements use a 96 GB graphics processor; that configuration is evidence of one tested setup, not a hardware budget for every workload.
SOV-Transcribe-1 processes recordings rather than a live stream. The card lists 16 kHz input (16,000 audio samples per second) and recordings up to 30 minutes as tested, with English, French, German, Spanish, Italian, Portuguese and Dutch support. A 31-minute file is outside that stated evidence; it is not automatically proven to fail.
There is also a separate serving limit: the documented vLLM transcription endpoint accepts 600 seconds (10 minutes) by default. Its audio-duration setting must be adjusted for a longer request. Model-tested duration and server request limits are different constraints. Check for output truncation as well as input acceptance.
The card does not document built-in speaker diarization (separating speech by speaker) or word-level timestamps. Treat those as additional requirements to verify, rather than assumed output features.
How to test whether context biasing actually helps
A controlled pilot on the intended workload is more informative than a leaderboard position.
Choose recordings that represent the real deployment conditions: the expected microphones, accents, background noise, names, identifiers, numbers and technical terminology. For the first evaluation, keep individual recordings within Salesforce’s documented 30-minute tested range and use the model’s documented 16 kHz input format. Use one audio channel (mono), as in the supplied preprocessing example.
Create a human-checked reference transcript for each recording. Keep the formatting instruction and decoding settings fixed, and transcribe each file under these conditions:
- the same fixed instruction, with no terminology list;
- the same instruction plus a short list of relevant names and specialist terms.
Optionally add a third run with a realistic longer list containing unused terms. Changing both formatting and keywords at once would confound the comparison: you could not tell which change helped.
This tests the question that matters: does context improve recognition of important terminology without degrading the rest of the transcript?
Measure the errors that matter
A standard metric is Word Error Rate (WER). NIST defines it as the total number of deletion, insertion and substitution errors divided by the number of words in the human reference transcript.
WER = (substitutions + deletions + insertions) / reference words
For example, if the human reference has 1,000 words and the generated transcript contains 20 substitutions, 10 deletions and 5 insertions under consistent scoring rules:
(20 + 10 + 5) / 1,000 = 3.5% WER
Lower is better.
But overall WER can conceal exactly the failure that prompted the test. A largely accurate transcript that repeatedly corrupts a customer’s name, medication, part number or database technology may still be unusable.
A useful pilot should therefore record at least:
- overall WER under consistent normalization and scoring rules;
- exact accuracy for high-value names, identifiers and numbers;
- processing time and peak memory on the hardware being considered for production;
- whether every required transcript feature, such as speaker labels or timestamps, is actually available.
NIST’s evaluation framework similarly treats time and memory as relevant resource measurements alongside WER, which is a useful model for evaluating a self-hosted system rather than accuracy alone.
Treat launch benchmarks as snapshots
Salesforce’s November 12, 2026 announcement reported a 2.28% Artificial Analysis WER and said SOV-Transcribe-1 ranked first among open-weight models and seventh overall on the non-streaming speech-to-text leaderboard as of that date.
That qualification matters. Leaderboards change as new models and evaluation versions appear. Artificial Analysis’s methodology describes its AA-WER v2 evaluation and normalization rules. The current board displays SOV-Transcribe-1 at a rounded 2.3% as checked November 14. A dated launch rank is not a permanent property of the model.
Salesforce also reports separate results for entity recognition, accents, noisy speech, style steering and context biasing. Those measurements are useful evidence of the capabilities the company designed and evaluated, but they do not establish performance on an organization’s own terminology and audio conditions.
The deployment benchmark that ultimately matters is therefore the controlled test on representative recordings.
When is SOV-Transcribe-1 worth evaluating?
SOV-Transcribe-1 is most compelling when four conditions coincide:
- the workload consists primarily of recorded rather than live audio;
- keeping recordings on controlled infrastructure is important;
- uncommon names or specialist vocabulary materially affect transcript usefulness;
- the organization can support the engineering and compute requirements of evaluating a large self-hosted model.
It is a weaker fit when live captions are mandatory, when an application depends on undocumented features such as built-in speaker diarization or word-level timestamps, or when infrastructure cost must be predictable before a technical evaluation begins.
Evaluate it when controlled deployment and terminology recognition justify the engineering work. Choose using correction effort, resource use and the verified data boundary on your own workload, rather than the launch rank alone.