ggml-large-v3.bin: the 3.1 GB download, and why bigger is the wrong axis for a voice agent

You searched the exact /resolve/main/ path for ggml-large-v3.bin, so you want one of two things: the actual file, or a straight answer on whether the biggest, most accurate Whisper model is the one to build on. This page gives you both. The download is one line. The second half is the part the download guides skip, because I build a voice-first Mac agent and large-v3's real limit is not the one its accuracy score suggests.

https://huggingface.co/ggerganov/whisper.cpp/resolve/main/ggml-large-v3.bin

# from inside a cloned whisper.cpp checkout
./models/download-ggml-model.sh large-v3
# -> writes models/ggml-large-v3.bin (~3.1 GB)

# or fetch it directly (follow the 302 redirect to the Xet CDN):
curl -L -o ggml-large-v3.bin \
  https://huggingface.co/ggerganov/whisper.cpp/resolve/main/ggml-large-v3.bin

large-v3 in context, with exact byte counts

Everything below lives in the same whisper.cpp model store. The byte counts were read straight from the Hugging Face x-linked-size header on 2026-06-23, so you can sanity-check a download against them. large-v3 is the top row by size and the bottom row by speed.

Quantized large-v3 variants (the q5_0 and q8_0 files) exist in the same repo. They shrink the file on disk, not the underlying accuracy ceiling. Check the Files and versions tab before you hardcode a filename, and read the official models README for the canonical size ranking.

The trap: you reached for the biggest model

Almost everyone who downloads this specific file does it for the same reason. They want a voice interface, large-v3 is the most accurate checkpoint, so it must be the right one. That instinct is correct for batch transcription and wrong for an interactive agent, and the reason is not a small caveat. There are two failure modes where a bigger model actively hurts you, and large-v3 is the most exposed to both.

Failure one: the decode happens after you stop talking

whisper.cpp transcribes a window of audio once that window has closed. You finish a phrase, then the model runs, then text appears. The bigger the model, the longer that gap. With a 3.1 GB checkpoint at roughly 1.55 billion parameters, the forward pass is the slowest of any model in the repo. For dictation into a document, the gap is invisible. For an agent that should begin acting while you are still mid-sentence, the gap is the product.

This is why Fazm does not decode a local Whisper window at all. The relevant configuration is in Desktop/Sources/TranscriptionService.swift: we open a WebSocket to a streaming ASR with interim_results=true, so partial transcript segments come back while you are still speaking. That is a structural property of streaming, not of model size. No amount of accuracy from large-v3 buys it back, because the model never sees a word until the window closes.

Failure two: the biggest model has the loudest hallucinations on silence

Every Whisper checkpoint can invent text when it is handed silence or low-energy, non-speech audio. The decoder latches onto something and emits it with full confidence. A common shape is a single token repeated several times with nothing else, the model looping on itself. large-v3 does not escape this by being accurate; accuracy is about transcribing speech, and there is no speech here to transcribe. In a push-to-talk voice agent, dead air between utterances is exactly the input that triggers it.

The fix is not a bigger model. It is a guard that recognizes degenerate output and throws it away before it reaches the agent. In Fazm that guard is isRepeatedTokenHallucination in the same TranscriptionService.swift. The rule is deliberately blunt: split the segment into tokens, and if there are four or more of them and they are all the same token, drop it. Real dictation is never one word repeated four times with nothing else, so the false-positive risk is near zero, and the caller falls back to the silence state instead of acting on a ghost phrase.

The point is not that this nine-line check is clever. It is that any serious use of large-v3 in a live voice loop needs something like it, and reaching for the most accurate checkpoint does not give it to you. If you wire large-v3 into a push-to-talk flow, budget for the guard layer up front.

When large-v3 actually is the right call

None of this is an argument against the model. It is an argument against the default. large-v3 earns its 3.1 GB in the workloads it was built for. Here is the honest split.

Why Fazm streams Nova-3 instead of decoding large-v3 locally

Fazm is a voice-first agent for macOS: hold a hotkey, talk, and the same Claude Code or Codex agent loop acts on your machine. Voice is the front door, so transcription is on the hot path. You would expect us to ship a local Whisper model, and large-v3 would be the prestige choice. We chose a streaming ASR instead, and the reason is the two failures above, not a dislike of local models.

Concretely: TranscriptionService.swift streams 16 kHz PCM to Deepgram Nova-3 over a WebSocket, takes interim segments back mid-utterance so the agent can react early, runs the isRepeatedTokenHallucination guard on every segment, and applies a spoken-to-written rewrite table (so "dot com" becomes ".com") plus a custom keyterm vocabulary for command and app names. The model tier was never the interesting decision; the streaming and the guard layer were.

That is a real tradeoff, stated plainly: streaming means audio leaves the machine. If your hard requirement is that it must not, then a local model is the correct choice, and large-v3 (or, more sensibly, large-v3-turbo) is where you start, with the guard layer bolted on. We optimized for latency in the agent loop; you may weight privacy higher. Both are defensible, and this is the page that tells you where to get the file either way.