metal: DSpark drafter working end-to-end (3 ops + 4 continuous/drafter fixes) - #2

Follow-up: we spent the evening root-causing bug 1 (cont prefill nonfinite seed logits at n >= 8 on Metal) and can narrow it considerably for you, though we have not fully killed it. Findings, all on M3 Ultra, q4 + q2 targets:

Where it lives. The cont serving prefill (pos0=0) takes the zero_prefix layer-major branch (ds4.c ~17052-17148 attn / ~17855-17933 indexer → ds4_gpu_compressor_prefill_tensor + metal_graph_refresh_ratio4_compressor_state). The per-seq multiseq emit sites (~16656/16880/17534/18113) never execute at prefill (batch_multiseq_emit is only set by the decode driver and the K-step selftest). First corruption is the first compressed-KV layer (layer 2); dense layers 0-1 stay clean; router expert ids stay sane.

What we ruled out empirically (each with the n=8/n=30 repro):

• Stale Metal backend: transplanting a current-lineage Metal backend (June + Optimize Metal prefill and decode on all Apple Silicon chips  antirez/ds4#555-era, our production one) under the fork's ds4.c reproduces identically → the trigger is in the cont driver's interaction with the backend, not backend age.
• DS4_METAL_MATH_SAFE=1, DS4_CUDA_FP8_KV=0, DS4_CUDA_FP4_INDEX=0: no change.
• Compressor state-store semantics: restoring/verifying the full internal-store compressor_update path: no change (it is not on the zero_prefix path anyway).
• Explicit memoryBarrierWithScope:MTLBarrierScopeBuffers between the score-scratch write (encode_compressor_score_with_ape) and its pool/pack readers inside compressor_prefill_tensor and ..._ratio4_replay_tensor: no change.

Two observations that should localize it for you:

1. With the built-in stage dumps enabled at layer 2 (DS4_METAL_GRAPH_DUMP_*, which insert a synchronize+readback per stage), every dumped stage tensor of the failing pass is finite — including attn_comp_kv_raw/score_raw, KVcompress, states, indexer_scores, kqv_out, attn_out, ffn_* — yet the request still fails with nonfinite seed logits. So whatever goes nonfinite is either (a) a buffer not covered by the dump names, or (b) written after the dump reads by a later host-side write — we suspect a host tensor_write mid-encode clobbering data that already-encoded dispatches read at execution time (per-row substrate/count tables are the obvious candidates; a host write lands immediately while the batch CB is still pending).
2. attn_state_kv reads fully finite while attn_state_score shows exactly half -inf — we verified against the kernels that this is the legitimate fill sentinel (state_kv zero-filled, state_score -INF-filled, only [0, ratio+rem) rows written), and the ratio4 pool kernels handle -inf rows correctly. Red herring; don't chase it.

Separate real bug found on the way (independent of the NaN): on the zero_prefix path, metal_graph_refresh_ratio4_compressor_state (ds4.c ~17112/~17922) overwrites the state that compressor_prefill_tensor already seeded to the CPU-oracle layout, discarding the partial current-window rows whenever n % ratio != 0 — the CPU oracle compressor_finish_prefill_state_cpu preserves rows [0, ratio+rem) and clears only the tail. It happens to agree at rem==0, so it is not the n=8 trigger, but it will corrupt the first decode token after any non-ratio-aligned prefill on Metal.

Happy to run any diagnostic build you want on the M3 Ultra — this box reproduces in seconds.