[rwkeyes]

Problem and result

You asked me to calibrate Q2_0. Attempting it turned up the actual bug, which is better than the calibration: the Q2_0
arm could not start because --expert-profile pointed at data/expert-profile-mine.bin — 48×256, the profile of the
pruned coder model (GSQ-RCO Coder keeps 256 of 512 experts). The Q2_0 pack declares 48×512, and the tree already
ships data/expert-profile.bin at exactly that shape. With it, Q2_0 served with no calibration at all.

real tokens	Q2_0 read	Q2_0 refill	slots	per slot	IQ1_M read	IQ1_M refill
128	1,075 ms	75.2 ms	313	0.240	252 ms	71.7 ms
458	1,556 ms	81.6 ms	365	0.224	432 ms	82.6 ms
1,610	2,055 ms	160.9 ms	726	0.222	1,245 ms	188.2 ms

The mechanism reproduces on different weights — same phase, same position between the read and prompt done, same
scaling with lent slots, at 0.22–0.26 ms/slot against IQ1_M's 0.319. The magnitudes are not comparable and are not used:
Q2_0 is the unpruned 512-expert model (19,208 of 24,576 slots resident, 6,761 experts mirrored in 8.70 GiB of pinned host
memory) and its dense shard sits on the cold disk.

Calibration itself is blocked, three ways, each logged: serve + --dump-routing writes a 0-byte file on the SYCL
device path; serve + STRATA_USAGE_DUMP writes nothing; the documented one-shot collector dies with --spec needs the device residency table, and where it did prefill, 37 tokens took 80.3 s at 0.5 tok/s.

This also corrects the claim I published yesterday that the cross-weight check was blocked. It was not; the profile
shape was wrong.

Related discussion

• [Docs] The ~165 ms is the expert-slot refill: 0.319 ms per lent slot, on the TTFT path #19 — §9, whose cross-weight subsection this rewrites
• serve: honour conv_route_batch_after from the config, not only the flag #16 — the other config-vs-binary mismatch found this week (conv_route_batch_after)

Approach

1. Diagnosed the three startup refusals in order (duplicate split shard → IQ pack needs --native → wrong profile
   shape), instead of treating the first one as the answer.
2. Read tools/make_profile.py's docstring, which names the pruned variant (--n-expert 256), and compared the two
   profiles' headers: 48×256 against 48×512.
3. Served Q2_0 on the shipped full profile and ran the same ladder and the same trace parser.
4. Then attempted the calibration three ways (serve --dump-routing, serve STRATA_USAGE_DUMP, the one-shot collector)
   and recorded each outcome rather than reporting only the failures that were easy to explain.

Validation

Passed:

• Q2_0 serves: /v1/status answered 0.1.59, 12 ladder samples, and the engine log shows profile … 24576 ranked pairs, built for 24576 slots — the shape matches.
• The refill reproduces at three sizes on a second weight set, with the same ordering in the trace and a
  per-slot rate consistent within itself (0.222–0.240).
• Each calibration attempt has its own log in trace/q2_0/: 12 and 13 prompts served with no output file, and the
  collector's rc 2 with the 80.3 s prefill line.
• Production verified by a real request: the one-shot on :8095 returned a completion and loaded: true
  afterwards — the loaded: false I first saw is the idle state after a restart, not a fault.

Failed:

• Calibration produced no profile, for the three reasons above. Q2_0 still runs on the shipped full profile.
• --ple-gguf doubled as the native shard's sibling on the first attempt (duplicate split shard number); the
  working config lets the engine resolve the sibling instead.

Not run:

• No Q2_0-specific profile, so no ranking study on the second weight set — only the mechanism check.

Limits

• The Q2_0 numbers are one run, 4 samples per size, with ~27 % of experts off-card: fine for "is the phase there", not
  for a magnitude.
• Its dense shard is on the spinning disk, so its read is inflated by I/O this inventory does not separate.