Audar-ASR-V1: Arabic-first speech recognition with Flash and Turbo tiers

What Audar-ASR-V1 solves, and who it is for

Most speech-recognition toolkits treat Arabic as one language among many, and dialectal Arabic as a rounding error. Audar-ASR-V1 inverts that. It is a family of Arabic-first generative speech-recognition models from AudarAI, aimed at teams whose audio is Gulf/Emirati, Egyptian, Levantine or Maghrebi, and at teams whose calls switch between Arabic and English mid-sentence. The README states that the models cover Modern Standard Arabic, every major Arabic dialect, code-switched Arabic-English, and English, with 30 languages in total.

The pitch rests on a specific claim: the Turbo tier posts the lowest average WER and CER of any system evaluated on the Open Universal Arabic ASR Leaderboard, rank #1 of 36, at 24.78 average WER. The 0.78 B Flash tier sits at #11 with 33.31 average WER, described as the strongest small model on the board. Those numbers come from the project's own benchmark table, run with the same harness and normalizer as the public board and calibrated within 0.03 pp according to the README. Treat them as the vendor's reported figures rather than an independent audit, but the leaderboard is public and the comparison is checkable.

The audience is narrow on purpose. If your audio is English-only and your latency budget is generous, the Arabic-first design buys you nothing over a general model. If your audio is Arabic and dialectal, that is exactly the gap this project is built to fill.

Audio encoder into Qwen3 decoder: the actual architecture

Audar-ASR-V1 does not use a CTC or transducer objective. The README describes transcription as audio-conditioned next-token prediction over a unified text vocabulary, decoded by a language-model head. Concretely, both tiers share one architecture: a Whisper-style 128-mel audio encoder feeding a Qwen3 decoder, with a 30-second context window. The Flash tier totals 0.78 B parameters (0.60 B decoder plus 0.19 B encoder); Turbo totals 2.35 B (2.03 B decoder plus 0.32 B encoder).

The adaptation is where the work sits, and AudarAI is explicit that the foundation is not theirs: the models build on a permissively-licensed open-weight audio-LLM foundation, then are adapted in-house through 300,000+ hours of labeled audio, primarily Arabic plus English, using a four-stage curriculum that ends in KTO preference alignment from native Arabic annotators.

Because both tiers share one prompt interface, the README says you can develop against Flash and scale to Turbo without code changes. That is the single most useful design decision in the repository for anyone planning a deployment: the tier choice becomes a runtime and cost decision rather than a rewrite.

One architectural detail deserves attention. The audio projector, distributed as mmproj in the GGUF path, must stay BF16 because its ClippableLinear is numerically sensitive, while the decoder GGUF quantizes normally across Q4_K_M, Q8_0 and BF16. Quantizing the wrong component is a real way to degrade output while believing you have saved memory.

Installing Audar-ASR-V1 and running a first transcription

The Python path is the shortest. The repository ships an examples directory with a requirements file and a transcribe script; weights download automatically from the Hugging Face repos. Install the example dependencies, then run the script on a clip. The README gives both an Arabic auto-dialect invocation and an English one with an explicit language flag.

pip install -r examples/requirements.txt
python examples/transcribe.py clip.wav            # Arabic (auto-dialect)
python examples/transcribe.py english.wav --lang en

The first command installs what the examples need. The second transcribes an Arabic clip with dialect detection left to the model; the third forces English. Clips must be 30 seconds or shorter on this path.

If you prefer to call the reference helpers from your own code, the README shows the load_model and transcribe functions. The model argument accepts either a Hugging Face repository id or a local path, which matters if you keep weights on an internal volume.

from audar_asr import load_model, transcribe
model, proc = load_model("audarai/Audar-ASR-V1-Flash")   # HF repo id or local path
print(transcribe(model, proc, "clip.wav"))               # <= 30 s clip

The GGUF route targets CPU, GPU and edge devices through llama.cpp. You need a recent llama.cpp build with Qwen3-ASR support, then the helper script takes a clip and a tier name. The README shows the underlying llama-mtmd-cli invocation with the model, the mmproj projector, the audio file, an Arabic system prompt, and temperature zero.

./examples/gguf_infer.sh clip.wav turbo     # or: flash

./build/bin/llama-mtmd-cli \
  -m       Audar-ASR-V1-Turbo-Q8_0.gguf \
  --mmproj mmproj-Audar-ASR-V1-Turbo.gguf \
  --audio  clip.wav \
  -sys     "فرّغ الكلام العربي التالي." \
  --temp 0

For GPU serving, the vLLM helper builds an audio-enabled image and serves on port 8000. The stock vLLM image omits audio codecs, so the helper adds av, librosa and soundfile. Turbo serves a 4-bit W4A16 compressed-tensors build from the vllm-w4a16 folder in its model repo, roughly 2.6 GB with near-BF16 accuracy and about +1 pp CER. Flash serves directly from its bf16 safetensors, roughly 1.6 GB, lossless. Once the server is up, transcription goes over the OpenAI-compatible endpoint.

./examples/vllm_serve.sh turbo    # or: flash — builds an audio-enabled vLLM image + serves on :8000

curl -s http://localhost:8000/v1/audio/transcriptions \
  -F model=audar-asr-v1-turbo -F file=@clip.wav -F temperature=0

For anything longer than 30 seconds, the repository provides a long-form script that chunks at 30 seconds, and a streaming script that emits incremental output using a LocalAgreement-2 policy: a word is committed only once two consecutive sliding-window decodes agree on it, so committed text is stable and never rewrites. That is the local reference policy; the README says Audar's production engine serves the same policy with sub-250 ms latency over an OpenAI-Realtime-compatible WebSocket.

python examples/transcribe_long.py meeting.wav   # arbitrary length (30 s chunking)
python examples/stream.py long.wav               # LocalAgreement-2 incremental output

Where Audar-ASR-V1 fails or is the wrong choice

The licence split is the first constraint, and it is not a small print issue. The repository code is Apache-2.0, but the model weights are not. Flash ships under the AudarAI Open v1.0 licence and Turbo under the AudarAI Community v1.0 licence, both linked from the README to audarai.com rather than included as text in the repository. If your legal review requires an OSI-approved permissive licence for the weights themselves, this project does not offer one, and the Apache-2.0 badge on the code does not transfer to the models.

The Flash tier has an output quirk worth planning for. The README states that Flash prefixes raw output with a language tag of the form language <Lang><asr_text>, and that you should strip it client-side with a regular expression. Any downstream parser that assumes clean text will need that step. Turbo does not carry the same warning in the README.

Quantization is a trap if approached casually. The decoder quantizes normally, but the mmproj projector must stay BF16 because of numerical sensitivity in ClippableLinear. Teams optimizing aggressively for memory may quantize both and get worse output without an obvious error.

Finally, the 30-second context is a hard boundary on the simple paths. Long audio requires the chunking script or the streaming script, and chunk boundaries are a known source of word errors in any chunked ASR system. The README does not document a rollback or fallback strategy for chunk-boundary failures. If your workload is English-only, or dominated by languages outside the supported set, the Arabic-first adaptation is overhead you are paying for without return.

How it compares with Whisper and NVIDIA NeMo

Whisper is the obvious reference point, and the architectural difference is the interesting part. Whisper is an encoder-decoder trained with a sequence-to-sequence objective across a very broad multilingual mix. Audar-ASR-V1 keeps a Whisper-style 128-mel encoder but swaps the decoder for a Qwen3 language model and trains the pair as audio-conditioned next-token prediction, then adapts on 300,000+ hours of mostly Arabic audio with KTO preference alignment from native annotators. The result is a narrower model with a sharper focus: 30 languages rather than Whisper's broader set, but with dialect coverage the README presents as the differentiator.

NVIDIA NeMo takes a different route entirely. It is a training and deployment framework where you assemble and fine-tune your own ASR models, with CTC and transducer recipes among the options. Audar-ASR-V1 is not a framework. It is two fixed model tiers with published weights, a shared prompt interface, and reference inference scripts. If you want to own the training pipeline end to end, NeMo is the more appropriate starting point. If you want a model that already handles Gulf or Maghrebi Arabic and you would rather not run a fine-tuning project, Audar-ASR-V1 is the shorter path.

The runtime story is a genuine advantage over both. GGUF builds for llama.cpp and a vLLM path with an OpenAI-compatible endpoint mean the same weights run on a laptop CPU, an edge device, or a GPU server. The README notes that vLLM implements the Qwen3-ASR architecture natively, so no custom serving code is required.

Maintenance, licence exposure and upgrade cost

The repository is not archived, and its last push was on 2026-08-22. That is recent enough that the codebase reflects the current model tiers, but the README does not describe a release cadence, a deprecation policy, or a versioning scheme for the weights. No GitHub releases were retrieved, so there is no changelog to read before upgrading. Plan on treating a weight update as a re-evaluation event: rerun your own test set rather than assuming the API is stable.

The practical upgrade surface is small. Both tiers share one architecture and one prompt interface, so moving from Flash to Turbo is a model-id change in the same code path. The vLLM helper takes a tier argument, and the GGUF helper takes flash or turbo. That symmetry is the main reason the upgrade cost is low.

Licence implications are the larger exposure. Code is Apache-2.0. Weights are under the AudarAI Open v1.0 and AudarAI Community v1.0 licences, hosted on audarai.com rather than in the repository. The README does not summarize their terms, and this article cannot either. If you intend to redistribute the weights, embed them in a product, or use them in a commercial service, read both licence texts directly and route them through your own review. The distinction between the two tiers matters: Flash and Turbo are not under the same licence.

Editorial conclusion

Adopt Audar-ASR-V1 if you transcribe dialectal Arabic, Arabic-English code-switching or English and want an open-weight stack you can run locally through Transformers, llama.cpp or vLLM. Skip it if you need a permissive OSI licence for commercial redistribution of the weights, since both model tiers ship under AudarAI's own licences rather than Apache-2.0, which covers only the code. Before committing, verify the current licence terms at the URLs in the README, confirm your llama.cpp build carries Qwen3-ASR support, and check whether the Flash output tag needs stripping in your pipeline.

Frequently asked questions

Official sources

1. AudarAI/Audar-ASR-V1 on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README