[jschmied]

Closes #1666 once its base lands. Draft: it carries #1692's two commits and #1839's one until those PRs merge, so the diff shrinks to the last eleven commits (from aa50f38a1 on). Rebased onto main a068484a0: #1672, #1673, #1691 and #1513 (with the names.zig table) are merged now, so their commits are gone from here.

Stacked on:

• xpu: a Gen12LP server builds without the Qwen3.8-27B runner, and nem_prow gets an 8 x 4 image (stacked on #1673) #1692 (Gen12LP without DPAS, 6018304a2), carried here as fe5300709 and 2fcfc2d3e;
• lfm3: the backends share the rope frequencies and the layer schedule #1839 (715e23235, the shared rope frequencies, ring and window): the last commit d9e490cec drops this backend's own copies. B2's 64 tokens are unchanged; two chat replies changed at near-ties (a 0.068 margin, now float64's top-1, and a 1.5e-4 tie);
• ref64.py's numpy path (aa50f38a1), which lfm3 CUDA: serve the block FP8 export weight-only and the MLX 4-bit export as stored (stacked on #1508) #1634 also carries: the checkpoint test reads its float64 dumps.

What it adds

• Kernels without DPAS: the short conv, QK norm with partial RoPE, gated GQA attention over a ring, the sandwich norm and SwiGLU, each with an FP64 op test and a planted control.
• The LFM3 forward on the Intel GPU:
  • prefill in windows, decode, and the conv state and KV rings;
  • weights loaded through names.zig, MLX 4-bit group 64 as stored;
  • a checkpoint test against ref64.py's float64 dumps.
• Serving: xpu-native serves LFM3 through main's lane host (copy_only), with the contract Gemma 4 E4B's engine implements:
  • one sequence per stream;
  • the lane core's context copies verified in windows of up to 16 rows;
  • several streams' windows in one forward;
  • prompt states kept by the prompt cache.
• One adapter line (xpu_nem.zig): the host takes a family's copy_match when its table row declares one. LFM3 declares 8. At the core's default of 4, copies cost a short chat 6 % on Iris Xe.
• Exact speed work:
  • streams share a decode step through N-row matvecs that sum each row as the one-row kernels do (tf-xpu-lfm3_rows-test, bit for bit);
  • window costs are timed at load for 1, 2, 4, 8 and 16 rows and interpolated between (load 8 s instead of 21 s, with the same round plans);
  • decode fuses w1 + w3 + SwiGLU, the four attention matvecs, and RoPE with the KV store;
  • prompts run on nem_prow_gen12 in windows of 128 rows.
• Prompt GEMM (bb38b814b, a different summation order): prompt windows take pgemm (lfm3_mv.cl), which tiles 64 × 64 in SLM as vit_gemm does and dequantizes MLX 4-bit as it loads a weight tile. Each output sums an fma chain per 64-wide k block and adds the blocks in order, so a row's sum doesn't depend on how the prompt is cut. Verified windows, shared rounds and decode keep pdense and qmv, so drafts stay bit-equal to one-row steps.
• Docs: the Iris Xe row in docs/recipes/xpu-arc.md.

Checks (Iris Xe, WSL2)

After the rebase onto a068484a0: B2's 64 tokens on all three prompts, --parallel 1/2/4 equal to solo, cache resume equal to cold, tf-xpu-lfm3_rows-test 28/28, the tgllp images byte-equal to the previous head, and bmg's 14 images byte-equal to main's (lfm3, lfm3_mv and nem_prow_gen12 are the new ones).

• Forward against float64: every layer of 3 prompts is at 0.95–1.05× the bf16 gap. The 64 greedy tokens match the CUDA engine (lfm3 CUDA: serve the block FP8 export weight-only and the MLX 4-bit export as stored (stacked on #1508) #1634, MLX 4-bit) on all 3 prompts, and match again after every speed change, at windows of 128 and 64, with each fusion on and off.

• Streams: at --parallel 1, 2 and 4, 5 concurrent replies are byte-equal to solo, in two runs each. tf-xpu-lfm3_streams-test checks streams in shared forwards, streams freed and joined mid-way, and windows rolled back, each against the stream alone.

• RoPE kernels: these now require sub-groups of 16. Before, the compiled width could change a reply from one process to the next.

• Prompt cache: a resumed second turn is byte-equal to the cold one, at 1k and 8k tokens. TTFT is 0.56 s against 13.25 s at 1k, and 0.80 s against 122.6 s at 8k.

• Speed, server:

  	before the speed work	after
  decode, 1 stream, --no-drafts	14.8–15.8 tok/s	15.6–16.8 tok/s
  decode, 1 stream, copy drafts	–	15.9 (chat) to 26.3 (prose) tok/s
  decode, 4 streams, aggregate	–	25–32 tok/s
  TTFT at 1k	13.1–14.2 s	11.7–12.2 s; with pgemm 4.6–4.7 s
  TTFT at 8k	130.8–131.3 s	116.3–117.7 s; with pgemm 55.4–55.6 s

  With copy drafts on, prose decodes 65 % and code 38 % faster than with --no-drafts. The two chats stay within 2 % of --no-drafts, which is within the session noise. Prompts are timed with --context 16384, decode with --context 4096.

• pgemm against float64: lfm3_pgemm checks it in groups of 64 and 32 (the other size as the planted control) and every row alone equal to the row in a window. lfm3_chunks checks windows of 64, 128, 256 and a ragged cut bit for bit (rows, logits, the next step), with pdense's order as the control. Through the model, per layer against float64: the 750-row prompt, 1k and 8k are the same (≤ 1.002×) or closer (mean −0.3 to −0.7 %). The two short prompts are further: +5.3 % (20 rows) and +2.9 % (19 rows), single layers up to +8 %. At op level on real weights both orders have fp32 error 2e-7 and 0 bf16 flips, and three orders rank differently on each short prompt. B2's 64 tokens are unchanged; two chat replies changed at near-ties (one now float64's top-1, one now 0.075 behind it).

• Spark (GB10), head bb38b814b: lean reports no new findings; zig build test, the contract, golden, security and fuzz steps pass; git diff --check is clean.

Overlaps

atc overlap reports file conflicts with:

• lfm3: add native Metal vision support above the text decoder #1502 (LFM3 vision on Metal, 6 files): both build on the LFM3 series;
• Gemma 4 E4B on the Intel Arc Pro B70 (Xe2) #1552 (Gemma 4 on Arc B70, 4 files): both touch xpu/.

I'll rebase onto whichever lands first.