Eval bug: Metal fails mixed quantized KV on Apple Silicon when Flash Attention is unavailable, while q4_0/q4_0 and f16/f16 work

[bostdiek]

Name and Version

/opt/homebrew/bin/llama-server
version: 8660 (d00685831)
built with AppleClang 17.0.0.17000604 for Darwin arm64

Installed from Homebrew ggml 0.9.11.

Operating systems

Mac

GGML backends

Metal

Hardware

Apple M1 Pro with 32 GB unified memory

Models

• unsloth/gpt-oss-20b-GGUF:F16
• unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF:Q4_K_XL
• LiquidAI/LFM2.5-1.2B-Instruct-GGUF:Q4_K_M
• LiquidAI/LFM2.5-VL-1.6B-GGUF:Q4_0

Problem description and steps to reproduce

I am seeing a reproducible Metal backend failure pattern with quantized V cache.

Observed behavior:

• q4_0/q4_0 KV works
• f16/f16 KV works
• q8_0/q4_0 fails
• the failure is reproducible even when context is reduced
• this does not appear to be simple memory exhaustion, because the same model and large context work with f16/f16 KV

The failure appears tied to Flash Attention availability on Metal. When the failing configuration is used, startup or request handling reports that quantized V cache requires Flash Attention.

Reproduction 1

Model:
gpt-oss-20b

Known working configuration:

llama-server \
  -m /path/to/model.gguf \
  --ctx-size 131072 \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --flash-attn on

This loads and serves requests.

Also working:

llama-server \
  -m /path/to/model.gguf \
  --ctx-size 131072 \
  --cache-type-k f16 \
  --cache-type-v f16 \
  --flash-attn on

This also loads and serves requests.

Failing configuration:

llama-server \
  -m /path/to/model.gguf \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q4_0 \
  --flash-attn on

This fails with the quantized V cache / Flash Attention error.

The same mixed configuration also failed for me at larger contexts.

Reproduction 2

Model:
Qwen3-Coder-30B-A3B-Instruct

Working configuration:

llama-server \
  -m /path/to/model.gguf \
  --ctx-size 32768 \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --flash-attn on

This loads and serves requests.

Failing configuration:

llama-server \
  -m /path/to/model.gguf \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q4_0 \
  --flash-attn on

This fails with the same quantized V cache / Flash Attention error.

Reproduction 3

Models:

• LFM2.5-1.2B-Instruct
• LFM2.5-VL-1.6B

For both models:

• mixed q8_0/q4_0 KV failed
• the failure message was the same quantized V cache / Flash Attention requirement
• reverting to the prior working KV layout resolved the issue

Relevant log output

For the failing mixed KV path, I consistently hit:

quantized V cache was requested, but this requires Flash Attention

In one larger gpt-oss-20b run, Flash Attention dropped out during reserve and the process then attempted a very large Metal allocation before crashing.

Expected behavior

If q8_0/q4_0 is unsupported on this Metal path, I would expect a clear early rejection without partial initialization or crash behavior.

If it is intended to work, then I would expect it to behave consistently with the working q4_0/q4_0 and f16/f16 cases.

Actual behavior

On Apple Silicon / Metal:

• q4_0/q4_0 works
• f16/f16 works
• q8_0/q4_0 fails
• failure is reproducible across multiple models
• reducing context did not make the mixed q8_0/q4_0 configuration work in my tests

Why this seems backend-specific rather than memory-only

For gpt-oss-20b, f16/f16 KV worked at the same 131072 context where q8_0/q4_0 failed. That suggests the main issue is backend support or Flash Attention path selection, not just available memory.

Possibly related

• Bug: Quantized kv cache caused performance drop on Apple silicon #8918
• Misc. bug: Unsupported op "CPY" / Segmentation fault on Metal #10976
• Eval bug: GLM 4.7 Flash not working with flash attention on #19307
• Eval bug: Gemma 3 extremly slow prompt processing when using quantized kv cache. #12352

[bostdiek]

Adding the exact local gpt-oss-20b repro output for the Metal reserve/allocation path.

Environment:

/opt/homebrew/bin/llama-server
version: 8660 (d00685831)
built with AppleClang 17.0.0.17000604 for Darwin arm64
Homebrew ggml 0.9.11

Command that reproduces the large-allocation crash at 131072 context:

llama-server -hf unsloth/gpt-oss-20b-GGUF:F16 \
  --ctx-size 131072 \
  --jinja \
  -ub 2048 -b 2048 \
  -ngl 99 \
  -fa auto \
  --cache-type-k q8_0 \
  --cache-type-v q4_0

Relevant output:

llama_context: n_ctx         = 131072
llama_context: flash_attn    = auto
llama_kv_cache: size = 1248.00 MiB (131072 cells,  12 layers,  4/1 seqs), K (q8_0):  816.00 MiB, V (q4_0):  432.00 MiB
sched_reserve: reserving ...
sched_reserve: layer 0 is assigned to device MTL0 but the Flash Attention tensor is assigned to device CPU (usually due to missing support)
sched_reserve: Flash Attention was auto, set to disabled
sched_reserve: resolving fused Gated Delta Net support:
sched_reserve: fused Gated Delta Net (autoregressive) enabled
sched_reserve: fused Gated Delta Net (chunked) enabled
ggml_metal_buffer_init: error: failed to allocate buffer, size = 65536.00 MiB
zsh: segmentation fault

Command that reproduces the same backend path at 32768 context:

llama-server -hf unsloth/gpt-oss-20b-GGUF:F16 \
  --ctx-size 32768 \
  --jinja \
  -ub 2048 -b 2048 \
  -ngl 99 \
  -fa auto \
  --cache-type-k q8_0 \
  --cache-type-v q4_0

Relevant output:

llama_context: n_ctx         = 32768
llama_context: flash_attn    = auto
llama_kv_cache: size = 312.00 MiB ( 32768 cells,  12 layers,  4/1 seqs), K (q8_0):  204.00 MiB, V (q4_0):  108.00 MiB
sched_reserve: reserving ...
sched_reserve: layer 0 is assigned to device MTL0 but the Flash Attention tensor is assigned to device CPU (usually due to missing support)
sched_reserve: Flash Attention was auto, set to disabled
sched_reserve: resolving fused Gated Delta Net support:
sched_reserve: fused Gated Delta Net (autoregressive) enabled
sched_reserve: fused Gated Delta Net (chunked) enabled
sched_reserve:       MTL0 compute buffer size = 16754.57 MiB
sched_reserve:        CPU compute buffer size =   321.12 MiB
sched_reserve: graph nodes  = 1758
sched_reserve: graph splits = 50
sched_reserve: reserve took 9.85 ms, sched copies = 1
ggml_metal_free: deallocating
llama_init_from_model: failed to initialize the context: quantized V cache was requested, but this requires Flash Attention
common_init_result: failed to create context with model '/Users/bryanostdiek/.cache/huggingface/hub/models--unsloth--gpt-oss-20b-GGUF/snapshots/d449b42d93e1c2c7bda5312f5c25c8fb91dfa9b4/gpt-oss-20b-F16.gguf'
common_init_from_params: failed to create context with model '/Users/bryanostdiek/.cache/huggingface/hub/models--unsloth--gpt-oss-20b-GGUF/snapshots/d449b42d93e1c2c7bda5312f5c25c8fb91dfa9b4/gpt-oss-20b-F16.gguf'
zsh: segmentation fault

This is the same machine where gpt-oss-20b works with --cache-type-k q4_0 --cache-type-v q4_0 and also works with --cache-type-k f16 --cache-type-v f16 at 131072 context.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[FelixIsaac]

Confirmed this exact pattern on M3 Ultra 96GB with Gemma 4 31B Q4_K_M (llama.cpp build b9649):

• q8_0/q8_0: Works, 100% NIAH, 192 tok/s @ 32K ✅
• q5_0/q5_0: Works, ~141 tok/s @ 32K ✅
• q4_0/q4_0: Loads/serves but 20× slower than q8_0 @ 32K (13 vs 192 tok/s on llama-bench). Dequant bottleneck dominates.
• q8_0/q4_0: Fails with the same quantized V cache / Flash Attention requirement ❌

The practical impact: any 4-bit KV cache quantization is effectively non-viable on Metal for production inference. Even the pure q4_0/q4_0 config that "works" has a performance cliff that makes it unusable at real context lengths (32K+). We are using q8_0 as baseline with q5_0 as a usable middle ground.

Would love to see this resolved — better Metal KV cache quantization would unlock significantly more memory headroom for long-context workloads on Apple Silicon.