Skip to content

docs(fold): CUDA's flash-attention-off KV cells ran at batch 512; the f32 cast is llama.cpp's graph - #401

Merged
glennneuber merged 1 commit into
mainfrom
docs/kv-cuda-batch-caveat
Sep 28, 2026
Merged

glennneuber merged 1 commit into
mainfrom
docs/kv-cuda-batch-caveat

Conversation

@glennneuber

@glennneuber glennneuber commented Sep 28, 2026 •

Copy link
Copy Markdown

This follows up Metal's batch finding on #387 (comment 5863032494) for CUDA, corrected after an adversarial review. It changes the fold record's CUDA KV section, and one line of kv-cache-type-per-model.md.

  • The CUDA flash-attention-off cells ran at batch 512. In kv: production runs an f16 KV cache on every platform, and a cross-host loop test #387's CUDA KV × flash-attention matrix, every flash-attention-off launch ran at -b/-ub 512 with images decoded in pieces. The flash-attention-on arms ran at 2048.
    • The cause is upstream's rule in automaticGenerationBatch (llama-server followups ollama/ollama#16353), not a memory fit. On CUDA, flash attention off never promotes the automatic batch past 512. It drops to 256 when a CUDA device has 8 GiB or less free and the context is above 4096. It returns before gemma4's 2048 image-chunk floor and the fit check (generationBatchFits) apply. So a quiet GPU still gives 512, and only a pinned num_batch compares the two paths at one batch.
    • What follows. Those cells change the batch along with the path, so they are not flash attention's effect alone. The fold and 908 stay byte-identical with flash attention off, since both ran at 512.
    • What else ran at 2048. The loop-rate run and item 8's two CUDA GGUF legs ran at 2048 throughout.
  • The f32 cast is llama.cpp's graph. f32 equals f16 under flash attention because llama.cpp's graph casts K and V (build_attn_mha) on every backend, as Metal found.

#400 carries the related corrections into the KV task record, the skill and ADR 0044.

ai-server/mlx-cuda

🤖 Generated with Claude Code

… f32 cast is llama.cpp's graph

Checked against Metal's batch finding on #387 (2026-09-28), and corrected
after an adversarial review:
- Every flash-attention-off launch in #387's CUDA KV x flash-attention matrix
  ran at -b/-ub 512 with images decoded in pieces; the flash-attention-on arms
  ran at 2048. The cause is upstream's rule in automaticGenerationBatch
  (ollama#16353), not a memory fit: on CUDA, flash attention off never
  promotes the automatic batch past 512 (256 when a CUDA device has 8 GiB or
  less free and the context is above 4096), and it returns before gemma4's
  2048 image-chunk floor and the fit check (generationBatchFits) apply. So a
  quiet GPU still gives 512, and only a pinned num_batch compares the paths
  at one batch. Those cells change the batch with the path and are not flash
  attention's effect alone; the fold = 908 identity with flash attention off
  still holds (both at 512). The loop-rate run and item 8's two CUDA GGUF
  legs ran at 2048 throughout.
- f32 = f16 under flash attention comes from llama.cpp's graph cast
  (build_attn_mha) on every backend, as Metal found, not from CUDA's kernel.
  CUDA's graphs show it: f32 builds 2,764 nodes against f16's 2,704 with
  flash attention on (one K and one V cast in each of 30 layers), and both
  build 2,829 with it off. kv-cache-type-per-model.md said CUDA's and HIP's
  kernels did the conversion; it now says the graph does, and cites #387 for
  Metal's measurement.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@glennneuber
glennneuber force-pushed the docs/kv-cuda-batch-caveat branch from be638b2 to 10f92e9 Compare September 28, 2026 05:20
@glennneuber
glennneuber merged commit 3c3fb7b into main Sep 28, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant