# Generic KDA shared-row cache candidate

The stock K3 KDA CUDA block uses four warps for four state columns, but each
warp rereads the same K row and evaluates the same gate exponentials. The
candidate `gated_delta_net.cu` now caches the K row, `exp(g)` row, and beta once
per block for the actual K3 geometry (`S_v=128`). All four warps then consume
those shared values; Q, V, state updates, and reduction order are unchanged.

This is a candidate-only build and compiles successfully in the isolated
`sm_121a` tree. It should reduce redundant global reads and gate evaluation
during ordinary KDA prefill without requiring FlashKDA or changing cache
format.

Promotion gates:

1. Compare the candidate with the promoted FP16-K launcher on identical cold
   and warm prompts.
2. Check recurrent-state and output parity at token counts 1, 2, 31, 32, 33,
   128, 512, and 2048.
3. Require every rank to retain at least 1.5 GiB and record TTFT, prefill,
   decode, and quality outputs.

No speedup is claimed until the whole-model A/B is complete.

## Bounded whole-model probe (2026-08-02)

The isolated candidate loaded successfully on the four-Spark RPC path with a
4K context and the 1.5 GiB per-rank safety floor preserved. A 2,342-token
natural-language prompt (16-token completion, reasoning off) measured:

| Metric | Candidate |
|---|---:|
| Prompt throughput | 70.28 tok/s |
| Decode throughput | 2.60 tok/s |
| Graphs reused | 15 |
| Load result | Healthy (`/health` = `ok`) |

This is a bounded A/B result, not a production promotion: it is modestly above
the recorded Q8-K/F16-V 600K baseline (67.85 tok/s on a 2,325-token probe),
but it does not establish a FlashKDA win. The candidate service was stopped
after the probe; the promoted FP16-K recipe remains unchanged.

## Production sanity check (2026-08-02)

After the candidate was stopped, the promoted 600K FP16-K/FP16-V service was
reloaded on port 8210 and remained healthy above the 1.5 GiB floor. One cold
natural request measured 1,769 prompt tokens at 61.30 tok/s and 16-token
decode at 2.65 tok/s. A repeated identical request reused 99.2% of the cached
prefix, so its prompt timing is not a new-prompt prefill measurement and is
reported only as a cache-reuse sanity check.

A subsequent unique live probe on the same 8210 service used
`cache_prompt=false`, 3,255 prompt tokens, and a one-token completion. It
measured **75.09 tok/s prompt throughput** (43.35 s total prompt time). This
is the current live prefill reference; graph reuse is reported separately and
must not be confused with prefix-cache reuse.

### FlashKDA deployment blocker

The bridge-enabled CUDA library exists in the isolated head build, but the
three candidate RPC workers still run older `ggml-rpc-server`/CUDA libraries
without the `K3_FLASHKDA_*` symbols or environment. Therefore the bridge was
not active in the earlier candidate probe. Enabling it requires a separate
candidate worker binary and restart on port 50053; production workers and
8210 were intentionally left untouched.