feat(qwen36): the dense trunk places itself -- COLI_PLACE=auto, priced in bytes saved per byte of VRAM

[kreuzzelg]

Stacked on #1360 (which is stacked on #1344). Until those land, their four commits show in this diff; this PR's own commits are the seven from 9d7c00b to bd6c4c7. I will rebase as each lands.

Why

sehHeiden's measurement series in #1040 (GTX 1660 Ti, 6 GB): the CUDA expert tier reaches 6.6 tok/s warm and the hit rate stops mattering (33 → 95 % hit buys +13 %), while llama.cpp --cpu-moe -ngl 99 does 19.9 on the same box. The mechanism is placement, not the tier: the tier moves the routed experts, which on this hybrid model are the small part of a token (~190 MB of int8 at 81 % hit), and leaves the dense trunk -- attention, DeltaNet projections, shared expert, lm_head, 1.8 GB of int8 read on every token -- on the CPU. llama.cpp places the mirror image.

The hand-written COLI_PLACE list from my fork proved the point (13.84 → 17.11 tok/s on two cards) but nobody running a 6 GB card should have to work out that 1.2 GB of trunk is worth more than 800 experts. The engine knows every size involved, so now it decides.

What this adds

1. COLI_PLACE and two resident trunk components (the two R4 commits, adapted to #1344): lm_head and the fused per-layer DeltaNet projection (qkv ++ z, one GEMV instead of two) as resident int8 tensors on a CUDA device, and a placement table qt_place_of(component, layer) every movable piece consults. Bit-identical to the CPU path.

2. Automatic placement (feat(qwen36): automatic placement of the dense trunk). Before the tier decides its budget, the engine offers each trunk component with its size (qt_trunk_offer: lm_head once, dnproj per DeltaNet layer, sizes from the same dense-i8 entries the uploads use). qt_init prices them against the experts they would displace, in bytes saved on the memory bus per token, per byte of VRAM:

• a dense component is read every token: value 1.0 per byte;
• a routed expert is read with the probability p_e a token routes to it -- its heat share when HEAT_FILE exists, topk / n_experts otherwise -- and the CPU fallback reads the int8 slot, twice the VRAM bytes of an int4 expert: value 2·p_e per byte (1·p_e on an int8 container).

A component goes to the device with the most room if its value beats that of the coldest experts it would push out (the tail of the heat order that still fits). Without heat the tail is worth 2·topk/n_experts per byte (0.06 on the 35B) and the trunk always wins; with heat, a card whose marginal expert is routed on more than every second token keeps its experts -- the R4 case where moving all projections onto one near-full card cost 0.7 GB of hot experts and the 13 ms it had saved.

COLI_PLACE	behaviour
unset or auto	automatic
off	nothing placed: experts only, the behaviour before this PR
a list, e.g. lmhead=0,dnproj=0:20+1:20,experts=0	obeyed as written; the trunk's bytes are now charged to that device's expert budget, which the list never did (the 0.7 GB above was the discovery)

Every decision prints a [place] line with the numbers that made it; qt_stats names the trunk share of VRAM so "used > budget" does not read as an overrun.

3. Tests on the fake backend (tests/test_qwen36_tier_autoplace.c, seven cases, free VRAM is whatever the test says): fits → placed and the budget shrinks by exactly the trunk; too big → CPU; heat verdicts both ways (p_marginal 0.67 keeps the experts, 0.17 places the trunk, with and without a heat file, and room nobody would use always goes to the trunk); an explicit list obeyed and charged; off; two devices greedy by room with per-device budgets; nothing offered → no-op. qwen36_fake_cuda.h gains a counting coli_cuda_matmul stub and a settable free-VRAM figure.

Calibration (Qwen3.6-35B-A3B per-row int4, 200-token decode, same prompt throughout; Threadripper 3945WX, 12 threads)

	off	auto
RTX 3070 (8 GB), cold	44 % hit / 8.64 tok/s	36 % / 9.62	+11 %
RTX 3070, warm	95.0 % / 9.63	90.6 % / 12.92	+34 %
RTX 3070, budget capped at 5 GB (a 6 GB card's share), warm	88.9 % / 9.50	81.2 % / 13.15	+38 %
Quadro RTX 4000 (8 GB), warm	93.6 % / 11.09	88.4 % / 16.55	+49 %
both cards, experts on both, warm	100 % / 10.79	100 % / 14.80	+37 %
reference: Ollama 0.32.5, same model Q4_K_M, same prompt, both cards, 57 % CPU / 43 % GPU	20.3 warm (21.3 cold)

All sixteen runs produced bit-identical text (cmp, full output), across cards, budgets, cold and warm, off and auto. The warm rows are the ones that matter: at 95 % hit rate the marginal expert is as valuable as it gets on an 8 GB card, and the trunk still wins by a third; the hit rate drops only 4.4 points for 796 fewer residents because the displaced experts are the coldest of the heat order -- exactly the ones the placer priced as cheap. The smaller or slower the card, the larger the relative win, which is the shape of sehHeiden's problem.

Against Ollama on the same box the gap closes from 1.5× (August, two cards, hand-placed) to 1.23× on a single 8 GB card, with Ollama holding its dense weights at ~0.56 bytes/weight (Q4_K_M) against this engine's 1.0 (int8) and using both cards.

What this does not settle: two cards

With experts on both cards the second card paces every layer (the slower take() gates the chain), so off on two cards is barely ahead of the Quadro alone (10.79 vs 11.09) despite 100 % hit rate. This version's placer spreads the trunk by free room and leaves the experts on both, reaching 14.80, where the hand-written split -- experts on one card, trunk across both -- reaches 17.11. On two unequal cards the list still wins; the placer's next version has to learn that (experts on one card, trunk on the other, the expert card chosen by a short probe rather than guessed). Said in the docs rather than hidden.

Also known: peak RSS is ~2 GB higher under auto because the host int8 copies stay as the CPU fallback; dnout and attnproj are in the table but not yet offered.

Verified

• six tier tests green (test_qwen36_tier_{int8,multidev,shutdown,invariants,autoplace,int8_engine}), the invariants and autoplace tests clean under ASan+UBSan
• CPU build and CUDA=1 build; the calibration above is the CUDA build on the real container
• the R4 commits arrive without the binaries the fork commit accidentally carried, and with qt_init's device selection resolved against fix(qwen36): three CUDA expert-tier bugs (#1339, #1340, #1341) #1344 (COLI_PLACE devices are folded in after the COLI_GPUS/auto selection)

Thanks to Claude Code.

[kreuzzelg]

Correction to the calibration table: the two card names were swapped. I had taken CUDA ordinal 0 for the Quadro RTX 4000 and ordinal 1 for the RTX 3070; cudaGetDeviceProperties says the opposite on this machine (CUDA orders devices fastest-first, nvidia-smi by PCI bus, and the two disagree here). So the rows labelled "RTX 3070" were measured on the Quadro RTX 4000 and the row labelled "Quadro RTX 4000" on the RTX 3070. The numbers themselves stand; I have edited the table in the description and fixed docs/qwen36-cuda-tier.md in this branch (7841f02). It also removes the odd explanation I gave for the Quadro being the faster card: it was the 3070, as one would expect.

One thing worth knowing beyond my mislabelling: coli plan names devices by nvidia-smi index and exports COLI_GPU=<index>, while the engine's tier selects by CUDA ordinal. On a machine with two unequal cards those can differ, as here, and coli chat --gpu 1 then lands on the other card. Exporting CUDA_DEVICE_ORDER=PCI_BUS_ID in the planner's environment would make the two agree; I can open a small PR for that if you want it.

While re-measuring I also found that the run line in the docs (OMP_PROC_BIND=close without OMP_PLACES) makes libgomp pack the threads onto SMT siblings on this box: 12 threads on 6 cores. With OMP_PLACES=cores the same one-card cold run goes from 11.0 to 14.4 tok/s (+30 %). The calibration numbers above were all taken without it, so they are conservative; I will re-measure the table with it and update the docs in a follow-up rather than mixing the two here.