# How much accuracy do you lose when running whisper.cpp with INT8 quantization?

transcribeall.io · September 6, 2026

> Whisper.cpp quantization to INT8 is one of the most commonly asked-about topics in local speech recognition, and the short answer is this: on most...

Whisper.cpp quantization to INT8 is one of the most commonly asked-about topics in local speech recognition, and the short answer is this: on most hardware and for most audio content, INT8 quantization costs you somewhere between 0.5% and 3% in Word Error Rate (WER), which for many transcription workflows is an acceptable trade for a 2-4x speedup and a model file that shrinks by roughly 60-75%. But the picture is more complicated than a single number, and the details matter a lot depending on which Whisper model size you start from, what kind of audio you feed it, and which quantization method you choose. Below is a thorough breakdown of how quantization works in whisper.cpp, what the real-world accuracy impact looks like, and how to decide whether INT8 is right for your use case.

## What Quantization Actually Does to the Model

**Also worth reading:** [Whisper large v3 turbo quantization comparison: which format is best for inference and deployment?](https://transcribeall.io/knowledge/whisper_large_v3_turbo_quantization_comparison_which_format_is_best_for_inference_and_deployment.php) · [Whisper Model Quantization Guide: How to Compress OpenAI’s Speech Model for Faster, Cheaper Transcription?](https://transcribeall.io/knowledge/whisper_model_quantization_guide_how_to_compress_openais_speech_model_for_faster_cheaper_transcription.php) · [Which is better for high-accuracy transcription: Whisper Large V3 or Medium, and when should you choose each?](https://transcribeall.io/knowledge/which_is_better_for_high-accuracy_transcription_whisper_large_v3_or_medium_and_when_should_you_choose_each.php)

Quantization is the process of reducing the numerical precision of a neural network's weights. The original OpenAI Whisper models ship as FP16 (16-bit floating point) weights, meaning each of the hundreds of millions of parameters is stored as a 16-bit number. In an INT8-quantized model, those weights are converted to 8-bit integers. Because an 8-bit value takes half the memory of a 16-bit value, the model file size drops roughly in half, and on many CPUs the integer arithmetic path is faster than the floating-point path, producing inference speedups commonly reported in the 2-4x range depending on the CPU architecture and instruction set support (AVX2, AVX-512, NEON on ARM).

The accuracy loss comes from rounding. When you map a continuous range of floating-point values onto a discrete set of 256 integer levels, small amounts of information are discarded. For most layers, this rounding noise is absorbed by the network's redundancy. For other layers, particularly those with wide dynamic ranges or outliers in activation values, the rounding introduces errors that compound through the network and can manifest as degraded transcription quality, especially on difficult audio.

It is worth noting that whisper.cpp historically emphasized a slightly different approach: Q5 (5-bit, ~3.5 bits per weight after block scaling) and Q8 (8-bit) block quantization schemes built around GGML/GGUF block formats, rather than the classic per-tensor INT8 used in some other inference frameworks. When people say "INT8" in the whisper.cpp context, they often mean the Q8_0 block quantization, which groups 32 weights with a shared scale factor. This block-wise scheme is significantly more accurate than naive per-tensor INT8 and is one reason whisper.cpp quantization tends to outperform naive expectations.

## Realistic Accuracy Numbers: What the Benchmarks Show

The whisper.cpp repository maintains accuracy benchmarks against the OpenAI LibriSpeech evaluation, and community members have run extensive comparisons across quantization levels. The general pattern is consistent across independent tests.

For the small model, the FP16 baseline achieves roughly 3.4% error on LibriSpeech clean. Moving to Q8_0 typically costs around 0.1% or less, essentially within measurement noise. For medium, the clean-set error rises from roughly 2.7% to around 2.8-2.9% at Q8_0. The larger models show similar behavior: the accuracy penalty of 8-bit quantization is usually under 0.5 percentage points on clean speech.

Things get more interesting at lower bit depths. Q5_1 and Q5_0 quantization adds roughly 0.2-0.5 percentage points of error on clean speech, still modest. But dropping to Q4 levels (Q4_0, Q4_1, Q4_K) can add 1-3 percentage points, and on noisy or accented audio the degradation is noticeably steeper. Community testing on the tiny and base models reveals the most important caveat: quantization hurts small models disproportionately. Tiny FP16 sits around 5.3% error on clean speech, but aggressive 4-bit quantization of tiny can push errors past 7-8%, with some users reporting repetition loops and hallucinated filler phrases that never appear in the FP16 version.

The practical threshold most practitioners land on is this: Q8_0 is effectively lossless for all model sizes; Q5 is a good middle ground for medium and large models; Q4 should only be used on large models and only when memory is the binding constraint; Q2 and below on tiny/base models are generally unusable for reliable transcription.

## Comparison of Quantization Levels in whisper.cpp

| Format | Bits/Weight | Approx. Size (large-v3) | Accuracy Impact | Speed vs FP16 | Recommended Use |
| --- | --- | --- | --- | --- | --- |
| F16 | 16.0 | ~3.1 GB | Baseline | 1.0x | Reference quality |
| Q8_0 | ~8.5 | ~1.6 GB | ~0.1-0.3% WER increase | 1.5-2x | Best all-around choice |
| Q5_K_M / Q5_0 | ~5.5 | ~1.1 GB | ~0.3-0.8% WER increase | 2-3x | Memory-constrained systems |
| Q4_K_M | ~4.8 | ~0.9 GB | ~1-2% WER increase | 2-3x | Large models only |
| Q4_0 / Q4_1 | 4.0-4.5 | ~0.8 GB | ~1.5-3% WER increase | 2-4x | Edge cases, high tolerance for errors |
| Q2_K | ~2.8 | ~0.5 GB | Often severe degradation | 2-4x | Rarely advisable |

Note that exact figures vary by model version, evaluation set, and hardware, but the relative ordering is stable across tests. Speed gains depend heavily on CPU vectorization support; on some systems with strong FP16 support (modern Apple Silicon, for example, which uses Metal GPU acceleration), quantization may provide little speed benefit at all, in which case there is little reason not to run FP16.

## Why Model Size Matters More Than Bit Depth

A principle that gets overlooked in quantization discussions is that model size is a bigger lever for accuracy than quantization depth. The Whisper family scales from tiny (39M parameters) through base (74M), small (244M), medium (769M), to large (1.55B). The WER gap between adjacent model sizes is frequently 1-3 percentage points, comparable to or larger than the worst quantization penalties.

This means a quantized medium model will usually outperform an FP16 small model, and a Q8 large model will outperform an FP16 medium model, on most audio. If your goal is the best accuracy per gigabyte of memory, the right answer is often "quantize a bigger model" rather than "avoid quantization on a smaller one." A Q8-quantized medium model fits in roughly 800 MB, comparable to FP16 small, and delivers measurably better real-world transcription on accented speech, domain-specific vocabulary, and multi-speaker recordings.

The counterargument is small-model quantization instability. Tiny and base models have less internal redundancy, so the rounding noise of low-bit quantization has nowhere to hide. If you are forced to run tiny or base (for example, on a microcontroller or very low-power device), staying at Q8_0 or FP16 is the safer bet, and you should avoid Q4 and below entirely.

## The Failure Modes: Hallucinations and Repetition Loops

Not all quantization damage shows up in WER benchmarks. The most damaging failure modes are qualitative: hallucinated text that was never spoken, and repetition loops where the model repeats the same phrase indefinitely. These failure modes are disproportionately triggered by quantization on small models, by low-quality or near-silent audio segments, and by the aggressive quantization levels (Q4 and below).

Community reports and whisper.cpp GitHub issues going back to 2023 document cases where Q4-quantized tiny and base models hallucinate entire sentences during silent passages or background noise, a failure mode present even in FP16 Whisper but materially amplified by quantization. Whisper models are known to be sensitive to non-speech segments, and the quantization noise pushes borderline predictions over the edge more often.

The mitigation strategies are worth adopting regardless of quantization level: enable the entropy threshold and log-probability filters in whisper.cpp (--entropy-threshold and --no-fallback trade-offs, or the newer --suppress-nst flag for non-speech token suppression), split audio with voice activity detection (VAD) so silence is removed before inference, and if you control the pipeline, pre-screen segments where the model's average log probability falls below around -1.0 and re-run them with a larger or unquantized model. These techniques recover a large share of the qualitative failures that raw quantization introduces.

## Practical Steps to Quantize and Validate

Converting a model in whisper.cpp is straightforward. After cloning the repository and downloading the original OpenAI PyTorch weights, you convert them to GGML/GGUF format using the Python conversion scripts in the models/ directory, producing an FP16 GGML file. Then you run the quantization binary: ./quantize models/ggml-large-v3-f16.bin models/ggml-large-v3-q8_0.bin q8_0. The process takes a few minutes for large models on a modern machine.

Validation is the step people skip, and it is the step that matters. Before rolling out a quantized model in production, run it against a representative sample of your actual audio, not just LibriSpeech. Record the WER using the built-in benchmark tooling against the FP16 output as a baseline. A reasonable acceptance threshold for production transcription is a WER delta under 1 percentage point; if the quantized model exceeds that, drop back to Q8_0 from Q5, or to FP16 from Q8. Also spot-check audio types that stress the model: crosstalk, heavy accents, domain jargon, music beds, and silence. Benchmark suites underrepresent these, and they are exactly where quantization damage appears first.

One practical detail: whisper.cpp's mixed-precision quantization allows certain sensitive layers (notably the conv1d stem and some normalization parameters) to remain at higher precision. If you build the model from source, the default conversion handles this reasonably well, but be aware that hand-rolled conversion pipelines that quantize everything uniformly produce worse results than the defaults.

## Hardware Considerations and When Quantization Does Not Help

The speed benefit of quantization depends on your hardware. On x86 CPUs with AVX2 support, Q8_0 inference typically runs 1.5-2.5x faster than FP16. On older or low-power x86 hardware the gap can widen. On Apple Silicon, whisper.cpp uses Metal GPU acceleration by default, and the GPU path performs FP16 very efficiently, so quantization may yield little or no speedup; the benefit there is reduced memory footprint and reduced memory bandwidth, which still matters for battery life and for running larger models than would otherwise fit.

On ARM phones and single-board computers (Raspberry Pi 4/5, for example), quantization shines: memory bandwidth is the bottleneck, so halving the model size translates almost directly into halved processing time. A large model at Q5 is the common configuration for Pi-class hardware where FP16 large would not fit in available RAM at all.

If you have a GPU with abundant VRAM, quantization buys you little. The honest assessment is that quantization is a tool for constrained environments: CPUs, laptops, phones, and edge devices. Cloud-scale GPU inference is usually better served by FP16 or batching optimizations.

## Alternatives and Complementary Optimizations

Quantization is not the only way to make Whisper faster. Distil-Whisper models (distil-large-v3 being the most relevant as of 2025-2026) offer roughly a 6x speedup over large-v2 with a WER penalty of about 1% on long-form audio, and they compress through architecture reduction rather than bit depth, making them compatible with FP16 and often more stable than aggressively quantized originals. For English-only workloads, the English-only .en model variants run faster and slightly more accurately than multilingual equivalents at the same size.

Other complementary optimizations include beam width reduction (greedy decoding versus beam search of 5 saves 10-30% of runtime with minor accuracy cost), faster whisper implementations like Faster-Whisper (CTranslate2-based, often 4x faster than openai-whisper), and VAD-based segment splitting, which both reduces compute and removes the silence-triggered hallucination problem. Many production pipelines stack several of these: VAD preprocessing, a distilled or quantized model, and greedy decoding get you an order-of-magnitude speedup over naive FP16 large-v2.

The trade-off framing matters: quantization affects model memory and per-token compute; distillation changes the model itself; VAD changes what gets fed in. They are independent and stackable, and choosing between them should be driven by which resource (RAM, CPU time, or accuracy floor) is your actual constraint.

## Common Mistakes to Avoid

The most frequent error is quantizing tiny or base models to 4 bits and expecting usable results. The resulting models hallucinate, loop, and drop words at rates that make them unfit for anything beyond rough drafts. The second most common mistake is benchmarking only on clean speech; LibriSpeech clean numbers mask quantization damage that appears on real-world podcasts, phone calls, and meeting recordings with noise and overlapping speakers. Third, people often skip the log-probability and entropy filters, then blame the quantized model for hallucinations that the filters would have caught. Fourth, running quantized models on GPU-equipped machines where FP16 was already fast and accurate, gaining nothing and losing a fraction of a percent of quality. Finally, comparing raw file size and speed across different repositories without holding the decoding parameters constant, which produces misleading conclusions about which quantization level is best.

## When to Use INT8 Quantization, and When Not To

Use Q8_0 quantization if you run Whisper on CPU and want the best speed-to-quality ratio; the accuracy cost is negligible for medium and large models, and the memory savings make bigger models viable on modest machines. Use Q5 if RAM is tight but quality is contractual, for example in customer-facing transcription pipelines on edge hardware. Avoid sub-4-bit quantization for anything beyond experimentation. Keep tiny and base models at FP16 or Q8. On GPU-accelerated setups, question whether you need quantization at all. And regardless of configuration, validate against your own audio before committing, because the one number that matters is the error rate on the material your users actually send you.

## Quick answers

### Does Q8_0 quantization change Whisper transcription quality?

Practically speaking, no, for medium and large models. Benchmarks on LibriSpeech typically show less than a 0.3 percentage point WER increase at Q8_0, which is near measurement noise. Small models show slightly larger degradation, so Q8_0 is also the minimum recommended quantization level for tiny and base.

### Can I use 4-bit quantization for Whisper and still get good results?

Only with large models. Q4 on large-v3 adds roughly 1-2 percentage points of WER, which may be tolerable for drafts. Applying Q4 to tiny or base models often produces hallucinations and repetition loops that make the output unusable.

### Is a quantized medium model better than an FP16 small model?

In most cases, yes. The accuracy difference between adjacent model sizes (1-3 percentage points of WER) is usually larger than the penalty from Q8 or Q5 quantization. If memory forces a choice, a Q8 medium generally outperforms an FP16 small on real-world audio.

### Does quantization make whisper.cpp faster on Apple Silicon?

Not much. whisper.cpp uses Metal GPU acceleration on Apple Silicon, and the FP16 GPU path is already fast, so quantization yields little speedup. The main benefit there is a smaller memory footprint and lower memory bandwidth usage.

### How do I reduce hallucinations in a quantized whisper.cpp model?

Enable the entropy threshold and log-probability filters, use VAD to strip silence before inference, and consider the non-speech token suppression option. Re-running low-confidence segments with a larger or unquantized model recovers most residual failures.

Canonical: https://transcribeall.io/knowledge/how_much_accuracy_do_you_lose_when_running_whispercpp_with_int8_quantization.php
Markdown: https://transcribeall.io/knowledge/how_much_accuracy_do_you_lose_when_running_whispercpp_with_int8_quantization.php/index.md