T-one and GigaAM cascade: a draft of the subtitles during the call, a clean transcript after

The author of a one-on-one meeting service tested whether he could move off the cloud-based Deepgram onto his own server without a GPU and still get both live subtitles and a high-quality final transcript. He built a cascade of two models. During the call, T-one turns speech into a draft with a delay of under 2 seconds. After the meeting, GigaAM proofreads the draft, fixes errors and produces a clean transcript with punctuation. The setup worked, and the measurements took three days. But two results surprised the author more than the models themselves: the quality reference was wrong on every fourth disputed spot, and the popular "second model corrects terms" trick did almost nothing on his calls.

Where the cascade idea came from

In the first part, the author found that the vCPU count says little about performance. A 2013 Xeon without AVX2 handles 6–8 times fewer live streams than a modern processor with a similar core count. His machine B (6 vCPU Xeon E5-2680 v2, 11 GB RAM) handles two meetings at once: T-one returns a phrase 1.08 s (p50) and 1.2 s (p95) after a pause.

T-one has weaknesses. It does not add punctuation, and its word-level accuracy trails both the cloud and GigaAM. GigaAM, in turn, works only on a finished recording. The cascade covers both gaps. The idea came from @pahaz, who published an article the same day about a GigaAM + Parakeet cascade for offline transcription and advised adding Parakeet to the comparison.

The requirements stayed the same: participants' tracks arrive separately, so diarization is not needed; a subtitle phrase must appear within 2 s (p95); and audio does not leave a server in Russia. One requirement is new: a final transcript with punctuation that is no worse than the cloud's, where sums, deadlines and names matter most.

The reference that played favorites

In the first part, Deepgram served as the reference, and the author himself considered that a weak spot. Now he has expanded the sample and proofread the reference by hand. It turned out that the old reference was wrong on every fourth disputed spot and favored the models it was built from. This means that WER measured against such a reference overstates the quality of the "native" systems.

The second finding concerns term correction. For @pahaz, a second model that corrects terms cut WER by 5 percentage points. On the author's work calls, it changed nothing at best and added 7 percentage points at worst. The gain from a cascade depends heavily on the domain and the recording quality.

What exactly was measured

Test data:

• 51 seconds of call-center audio from the T-one package • A 29-minute coaching session • 4 recordings of work calls: 2 h 21 min, 14,970 words

References: agreement between the engines on a sample, Deepgram nova-3 text on the session, and a consensus text from three systems with manual correction of terms and spot-check listening.

The first part compared T-one, GigaAM-v3, Vosk, Deepgram nova-2 and nova-3. The second compares:

• T-one in greedy mode and with a KenLM language model • GigaAM-v3 e2e • Parakeet TDT 0.6B v3 • Deepgram nova-3

Metrics: WER, WERx, errors in numbers, and accuracy of terms and punctuation. Separately, the author looked at what loads the CPU in real time, how to split the work between the two models, and what it costs.

Practical takeaway

Anyone building their own transcription should start with the reference, not the models. If the reference is built from the output of the same systems you are comparing, the numbers will be optimistic. You need manual proofreading of at least the disputed spots, plus listening, especially where sums, dates and names appear.

The second takeaway concerns cascades. Someone else's 5-point gain from a corrector model does not carry over to your conversations automatically, so test on your own recordings. Splitting the roles between two models makes sense given the logic of the task: a fast, rough model for live subtitles and a slow, accurate one for the post-meeting document. For a small service, this means two simultaneous calls on an old six-core Xeon are quite realistic, provided the live part runs on a lightweight model and the heavy work is deferred until after the meeting.