[jschmied]

Stacked on #1503 (head 550690618); base main. Follows Synthena's suggestion on #1503 (comment 6806587680): one helper all five prompt-stream writes go through, and a host test that fails if a writer skips the wait. The head is ccd047085, one commit; it touches only zig/src/families/lfm2_moe/cuda_backend.zig. Once #1503 lands, this diff is that one file.

What

• Lfm.fenced() (cuda_backend.zig:180) returns the prompt stream after it waits on the device for the keeps' done (cuda_snap.Pages.fence, unchanged).
  • The five writes take their stream from it as an argument, so none can be queued before the wait: the slot clear (opening), a chunk (chunk), a one-row step (queue), a verify round (verify) and a commit (keep).
  • Before, each called Lfm.settle() on the line above and then passed x.s. That helper is gone.
• The test (cuda_backend.zig:532) reads the backend's own source, up to its tests.
  • It finds every fwd.forward(, fwd.commit( and .clearSlot( call and requires the stream argument to be try x.fenced().
  • It also requires exactly five such calls, so a sixth write names itself there.
  • Planted in the same test: each of the five, in turn, put back on x.s without the wait. Each is caught (one unfenced write) and all five are counted.
• fenced() test (cuda_backend.zig:564), with a fake driver:
  • Without a prompt cache it issues no wait.
  • With a keep pending it issues exactly one wait, the prompt stream on done.
  • A second call issues none until the next keep.
• The restore fence stays in snap.restore. lfm2_moe CUDA: attention pages from the shared KV pool, and the prompt cache (stacked on #1492) #1503's ordering test (cuda_snap.zig:340) and its three planted orders are unchanged; cuda_snap.zig isn't touched.

Shared core or LFM2 only: LFM2 only. Every other side stream joins inside the same pass: FlashNext's shared expert (flashnext/cuda_batch_side.zig fork/join), GLM's L2 prefetch (glm/cuda_l2pf.zig), Nemotron's side, and DeepSeek-V4.1's L2 prefetch and overlapped ingests (deepseek_v41/l2pf.zig, dspark_slots_ingest.zig). None leaves work pending for later writers to fence. The other families' keeps (Dory, Gemma 4, FlashNext, GLM, Qwen3.5) copy on the prompt stream. So no second caller exists to share a helper with. If another family moves its keeps to a side stream, Side and fenced would move to core together.

Hot path: no change to launches or kernels.

• Each writer issues the same driver calls in the same order: the wait (only if a keep is pending), then the write. In Zig, the stream argument is evaluated before the call, and the arguments before it are field loads.
• No .cu, .cuh or build file changes, so every fatbin and its SASS is the same build output.
• No speed A/B, per the brief for a hot path that doesn't change.

Proposed CHANGELOG line, under Unreleased: "LFM2.5-24B-A2B on CUDA: every prompt-stream write that a keep reads takes its stream from one helper that waits for the keeps, and a host test fails on a write that doesn't (#NNNN, stacked on #1503)."

Verification (on ccd047085)

• Host tests, GB10: zig build test-lfm2-moe-cuda-host 20/20. zig fmt --check clean.
• Planted control on the real source: in a separate worktree, the verify round is put back on x.s (try fwd.forward(x.m, x.k, x.s, chains, ...)). The test fails at cuda_backend.zig:536 (expected 0, found 1, 19/20). Restored, the head is green as above.
• x86 (10.0.0.8, tfci): zig build -Dfixed-cpu test test-golden test-kernel-contract test-server-security test-pull-security fuzz-cortheon check-release-paths, check-native-cuda-host compile-cuda-tests, zig fmt --check, pr_check with lean: 694/694 steps, 3629 tests (2 more than lfm2_moe CUDA: attention pages from the shared KV pool, and the prompt cache (stacked on #1492) #1503's 3627), lean 386 vs 386 on the base (0 new), pr_check 0 errors (1 warning: the CHANGELOG line is in this body).
• Served gates, GB10, real weights (LFM2.5-24B-A2B MLX4): this head's native ReleaseFast build against main 673a34b3b (lfm2_moe CUDA: attention pages from the shared KV pool, and the prompt cache (stacked on #1492) #1503's base), keeps on. GATES_OK.
  • Multi-turn chats (8 conversations × 4 turns): the cold first turn plus warm turns resumed from keeps (24 hits). Every reply equals main's, greedy and seeded (32 seeded hits); concurrent equals solo; drafted equals plain.
  • The same holds with the cache off, with fixed pages (TENSORFOLD_LFM2_KV_PAGES=0), under pool pressure (8 long concurrent prompts) and with a 0.1 GiB cache. A restarted server's replies are equal too.
  • The after-drain census is clean on every arm.
  • The reply hash d3c46363c6bb8d5d is identical on all five arms to lfm2_moe CUDA: attention pages from the shared KV pool, and the prompt cache (stacked on #1492) #1503's run on 550690618.
• A refusal doesn't apply: no new refusal. Concurrency and seeded rows are in the served gates above. Resume is the warm turns (a restored keep).

[ashhart]

Thanks @jschmied, this is the follow-up we suggested on #1503, and it's done well.

• Lfm.fenced() (zig/src/families/lfm2_moe/cuda_backend.zig:180) is now where all five writes get their stream: the slot clear, a prompt chunk, a one-row step, a verify round and a commit. Each one issues the same driver calls in the same order as before.
• The source test (:532) requires each of those calls to take try x.fenced() and counts them, so a new fwd.forward, fwd.commit or clearSlot call fails it until it's fenced and counted. Putting any one of the five back on x.s is caught.
• The fake-driver test (:564) pins the wait down: no wait without a prompt cache, exactly one on done after a keep, and none again until the next keep.

No kernel or build change, and the served replies hash the same as #1503's run. CI is green and it merges cleanly with main. It lands right after #1503, as one file on top of it.

• Synthena (Ash's Agent)

[ashhart]

@jschmied main moved under this and it conflicted with main in docs/environment.md zig/src/platform/environment.zig zig/src/platform/environment_test.zig (it builds on #1503, rebased first), so the landing train left it out. To save you a round trip we rebased it onto current main and pushed it to your branch: each conflict keeps main's change and yours, and your commits and authorship are otherwise unchanged. The host tests for its files, the serving-pin check and our privacy gate pass on the new head. It goes back in the landing queue once its CI is green. No other asks.

• Synthena (Ash's Agent)