Meta's omnilingual ASR: 1,693 languages, 17GB of VRAM, and a capacity problem instead of a vendor list

A real-time factor of 0.097 is the figure that reaches a spreadsheet. Transcribing 1,000 hours of recorded audio costs roughly 97 GPU-hours ^[15], or about ten audio-hours per hour of card time ^[16]. That is forecastable, and it prices differently from per-minute vendor billing: the 17GB resident footprint is occupied whether the queue is full or empty ^[6], and the 30GB file pulled on first use is nearly twice that working set ^[18], which is a cold-start problem on autoscaled nodes rather than on one long-lived box.

The input cap does its damage at the joins. An audio hour is at least 90 segments and 89 internal boundaries ^[17], and each boundary is a place where, per the guide, splitting introduces artifacts that may need manual cleanup [c8b]. That cleanup tax scales with archive size, not with how many languages you support.

The tail is where the coverage number gets expensive. Character error rates below 10 for 78% of languages, across 1,693 of them, leaves about 372 languages above that line ^[14], and the guide is blunt that performance there degrades significantly and low-resource cases may produce unusable output ^[5]. Those are also the languages with no commercial alternative to fall back on, which is much of the point of the release ^[19]. Fine-tuning is the normal remedy for a language that lands badly, and the variant that accepts audio longer than 40 seconds, omniASR_LLM_Unlimited_7B_v2, is the one that currently cannot be fine-tuned ^[11]. The hardest material to transcribe is therefore the material where you have the least room to adapt the model and the most stitching to do.

Mechanically, this is a wav2vec2 front end with an LLM-based decoder, handling zero-shot and few-shot transcription without language-specific training ^[4], with an optional language conditioning input for ambiguous audio and support for batched inference ^[13]. The zero-shot property is what removes the per-language procurement step; it does not remove the per-language question, it relocates it.

Worth being precise about provenance. This comes from a beginner's guide to a Replicate deployment maintained by Subformer ^[1], which describes the 7B as Meta's recommended choice where accuracy matters more than speed ^[20] and cites training on more than 1.6M hours of audio ^[12]. The artifact that matters for anyone signing up to accuracy targets is the per-language CER table shipped as a CSV in the README ^[5]. A coverage count of 1,693 is a talking point. A CSV with one error rate per language is a document you can be held to, and reading it is now the diligence step that used to be a vendor's problem.