Skip to content

Gemma 4 on CUDA: prompts in the shared KV store with TF_KV_SHARE (part of #1657) - #1883

Merged
ashhart merged 2 commits into
mainfrom
lead/gemma4-kv-share
Nov 2, 2026
Merged

ashhart merged 2 commits into
mainfrom
lead/gemma4-kv-share

Conversation

@ashhart

@ashhart ashhart commented Nov 2, 2026 •

Copy link
Copy Markdown
Owner

Part of #1657.

Gemma 4 on CUDA uses the off-by-default TF_KV_SHARE adapter that Spark 2.5 uses (#1756): global layers' prompts are the KV pool's pages in the shared prompt store, sliding-window tails are kept per stream in order, and the MTP assistant's pages are bound to its cache, with graphs invalidated when they move. Unset, nothing changes.

Host: 59 cache-oracle tests pass; three planted production-source controls fail as intended. On a GB10 with Gemma 4 31B (4-bit), against main: GREEN, 56 cells within +/-0.5%, prompt tokens identical, 64K recall the same. An independent review found the unset path identical and no page reused for the wrong stream or position.

Use the existing prompt_radix adapter behind TF_KV_SHARE for global cache
pages and pool-owned sliding-ring snapshots. Preserve the original path
when the switch is unset, keep the prompt grid, and bind MTP reads to the
target page table after discarding captures of relocated cache addresses.

Cover resumed and concurrent cache equality, MTP cache bindings, forced
snapshot eviction, cancellation and allocation accounting with host
regressions and planted faults. Checkpoint token fidelity remains a device
gate. Image reuse, DFlash and shared cache owners are excluded in this mode.

Refs #1657
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