# FlashKDA bridge status (candidate only)

The candidate bridge now builds successfully in the isolated
`sm_121a` tree. It keeps the fast BF16 FlashKDA output path but recomputes the
terminal recurrent state with the exact FP32 K3 recurrence. The state-update
kernel caches each token's K and gate row once per block, rather than rereading
and exponentiating those rows for every state column.

The standalone K3-shaped numeric gate passed:

```text
FLASHKDA_K3_BRIDGE_NUMERIC N=2 max_out=0.0013569 max_state=9.31323e-09
```

The serving binary includes an opt-in diagnostic marker. Start a candidate
with `GGML_CUDA_K3_FLASHKDA=1` and
`GGML_CUDA_K3_FLASHKDA_DIAG=1`; a real compatible prefill must emit:

```text
K3_FLASHKDA_ACTIVE T=<tokens> H=<heads> N=<sequences> state=fp32-carry
```

The stable recipe remains the default. Do not promote the bridge based on a
successful build or numeric unit test alone: workers must be reachable, the
marker must appear during a real prompt, and cold/warm prefill, TTFT, decode,
greedy identity, and quality must be compared against the stable FP16-K
profile while every rank retains at least 1.5 GiB.

## Real probe result

On the four-way candidate with internal `10.10.10.x` worker endpoints and a
16K context, a 5,308-token natural prompt measured **74.66 tok/s** prompt
evaluation. The log did **not** contain `K3_FLASHKDA_ACTIVE`, so this result is
ordinary KDA execution and is not attributed to the bridge. The candidate was
stopped after the probe; no production recipe was changed.

The likely dispatch reason was the bridge's former `cache == nullptr` guard:
the probe used `--cache-reuse 256`, which can route through the fused recurrent
cache object. The candidate bridge has now been rebuilt to accept the K==1
fused-cache destination (K>1 snapshot semantics remain excluded), so future
probes can test the faster path without giving up warm-prefix caching. The
candidate launch still uses `--cache-reuse 0` for an unambiguous first A/B;
cache-enabled and no-cache results must be reported separately.

A cache-enabled 4K-context reload was stopped at about 157 GB read when the
head reached roughly 3 GiB immediately free. It did not reach readiness, so
there is no cache-enabled bridge timing to report. This is a load-memory gate,
not a quality or throughput result; do not claim that the bridge works with
warm-prefix caching until a lower-memory loading strategy is tested.