[kreuzzelg]

The follow-up you asked for first in #1784 ("keep this a per-layer step and take it to qwen38"): Qwen3.8 Flash Next has the same gated-delta layer as Qwen3.6 (36 layers of 48 value heads), the CUDA trunk from #1424 already places its dnqkv, dnz and dnout, and the CPU still ran the convolution, the recurrence and the gated norm between them -- the round trips of #1784, 36 times per token.

What changes

Backend (same five entry points): coli_cuda_dn_create takes a gate mode -- Qwen3.8's norm multiplies by sigmoid(z) where Qwen3.6 uses silu(z) -- and coli_cuda_dn_step an optional second in_proj tensor: qwen38 keeps qkv and z as two matrices where qwen36 fused them. Loader and fake follow; the fake carries both gates.

Tier: qt_dn_gpu_init_dense joins the layer to three dense handles (the engine's own trunk items) on one device, instead of qwen36's fused dnproj tensor. The step uses the tensors recorded at init on either path.

Engine (Q38_DN_GPU=1, opt-in, beside the Vulkan chain's hooks, which the CUDA tier keeps off): a decode token computes the two gates on the CPU and hands x to the step; conv ring and recurrent state (48 x 128 x 128 per layer, 108 MB) live on the card. The host arrays stay canonical: a prompt, an MTP verify (snap_after takes its snapshot on the CPU path, so a verify forward stays there), a --pin snapshot and the prompt cache pull first; a reset, a pin restore and a rejected draft's rollback invalidate the card's copy; a failing step turns the layer off and the CPU continues from what the card holds.

Measured (RTX 3070, FP8 checkpoint, int8 trunk in VRAM = 553 matrices, cache 224/layer, 100 tokens, two runs each)

	Q38_DN_GPU=0	Q38_DN_GPU=1
DeltaNet ms/forward (decode, 36 layers)	50.1 / 48.5	32.8 / 32.3
expert-read ms/forward	373 / 348	364 / 361
routed experts ms/forward	105 / 95	104 / 102
tok/s (100 tokens, TTFT included)	1.39 / 1.48	1.45 / 1.46
output		byte-identical to =0 (all four runs agree)

The layer gains the same share as on qwen36 (−34 %, 17 ms per token), and on this box that is all it can show: Qwen3.8 is expert-bound here -- 24,576 FP8 experts, 344 resident at 17 % hit rate behind the 4 GB trunk, 350-370 ms of expert reads per 690 ms token -- the R7 finding that the trunk, not the tier, is this model's lever on 8 GB. On a card with room for the experts, or with the int4-g64 sidecar, the 17 ms would be a visible share; not measured here. Unlike qwen36 the output stays byte-identical to the CPU path over 100 greedy tokens (the int8 rows are the same on both paths and no route sat on a tie).

Verified

• tests/test_qwen38_dn_gpu.c (make qwen38-dn-gpu-check, in CI next to qwen38-tier-engine-check): the tiny FP8 fixture's oracle with the whole dense trunk on the fake tier and both DeltaNet layers stepped on the fake card -- 8/8 tokens, cosine 0.99998 -- and the same run on the CPU.
• test_qwen38_tier_engine, every qwen36 tier test and test_qwen36_dn_gpu unchanged and green; the Makefile VK_OBJ and loader-ABI tripwires pass (no new symbols); CPU-only and CUDA builds of both engines and colibri clean.
• Not run on the real container: --pin, prompt cache and MTP drafting under Q38_DN_GPU=1 (the code paths pull or invalidate before touching host arrays; the fake test covers prefill-after-decode).

On the CUDA chain mirroring vk_chain.c: noted, and I will shape its ops like vk_chain.h's (geometry from the caller, one recorder, the engine owning its state) with coli_cuda_dn_step as the DeltaNet op; that is the next piece after this one. And yes to running the staged device-local uploads on the 3070 with the launch VBIOS when the PR is up.

Thanks to Claude Code for the help along the way.