This is the exact real terminal output from your ./run_full_yaqa.sh "$NEW" --n-calibration 4 --incoherence none --correct-mtp --reuse-cached-fallback run, broken into its real sections, each one explained in plain language directly underneath — including the one question you asked directly: why does the log show a naive MTP build before the YAQA correction. Read 01_ZERO_TO_EXPERT_REDO.html first if you haven't — this page reuses "effective rank," "H_I/H_O," and "Hessian" without redefining them.
Your log really does show two steps for the MTP sidecar: a naive build, then a YAQA correction that overwrites it. That's deliberate, and it's spelled out in the actual code (05_full_model_quantize.py, lines 1597–1636):
Step A (runs always, reused code): reattach_vision_and_mtp() attaches the MTP sidecar using — in the code's own words — "the exact same real, already-trusted mechanism 08_gptq_apply_plan.py uses". That mechanism is a plain, naive mx.quantize at whatever bit-width the plan says (Q4/G64 here). This is old, already-tested code being reused, not new logic — it exists independently of YAQA and was never meant to be the final answer on its own.
Step B (runs only when you pass --correct-mtp): correct_mtp_sidecar() then reloads the model fresh from the file Step A just wrote to disk — the code's own comment explains why: "the honest, unambiguous way to guarantee MTP is calibrated against exactly what will actually ship, not an in-memory object." It then runs the real YAQA correction and overwrites the same optiq/mtp.safetensors file with the corrected version.
So: the naive file is real, but it's a scaffold that exists for a few seconds mid-run. The file that's actually still on disk when the script finishes is the YAQA-corrected one. Your intended design — trunk YAQA-corrected, MTP also YAQA-corrected — is exactly what you got. The log just shows you the real two-step mechanics of building it, which happen to reuse an older naive-build step as the scaffold.
run_full_yaqa.sh is the one command that runs this project's entire correction pipeline end to end. Each flag is a real, separate choice:
--n-calibration 4 — use 4 real text samples per "domain" (code, prose, agent conversation, etc.) when building calibration data for this run's own steps. (The Hessian data itself was already built earlier, separately, at N=24 — this flag controls calibration for this run's own fresh measurements, like the MTP correction later in the log.)--incoherence none — don't apply a Hadamard rotation to the weights before quantizing. (Rotation is a separate technique this project tested and is not using for the live model — see RESEARCH_Hadamard_Blowup.html for why.)--correct-mtp — the flag from Section 0 above: run the real YAQA correction pass on the MTP sidecar, not just the trunk.--reuse-cached-fallback — if a tensor was already corrected in a previous run and cached, use that cached result instead of recomputing it from scratch.resume is a folder where every real tensor's correction result gets saved as it's computed, so a multi-hour run can be safely stopped and picked back up without redoing finished work.
The "plan" is the real bit-allocation JSON produced earlier by the MILP/Pareto solver (the tool that decided which tensor gets how many bits, from the isolated-KL sensitivity sweep). bits=4 means: every weight number in that tensor gets compressed down to 4 bits instead of the original 16 (BF16). bits=16 (not shown in this excerpt, but present for 134 tensors) means: leave this tensor at full original precision, don't compress it at all — reserved for the most sensitive tensors.
group_size=64: quantization doesn't give every single weight number its own personal scale factor — that would need too much extra storage. Instead, weights are chopped into groups of 64 numbers, and each group of 64 shares one scale/bias pair (the "decoder key" from 01_ZERO_TO_EXPERT_REDO.html, Section 3). Smaller groups are more accurate but cost more storage for the extra scale/bias numbers; 64 is this project's chosen real trade-off.
363 tensors need real compression out of the full model — the rest (embeddings, norms, and a few protected tensors) stay at bits=16.
Correcting every one of the 362 real tensors (lm_head is handled separately, hence 362 not 363) needs the model to actually run — a real forward pass — on real calibration text, to see how each tensor actually behaves. Doing this for the whole ~27-billion-parameter model at once would need more memory than the machine has. So the tensors are split into 42 smaller groups ("batches"), each one sized to fit in an 8GB memory budget, and each batch gets its own real forward pass. This is purely a memory-management step — it doesn't change the math, just how much of it happens at once.
All 363 tensors that needed correction got one, and none of them crashed or produced invalid (NaN/Inf) numbers. "Ran without rotation" means the Hadamard-rotation option from the launch flags wasn't used (matches --incoherence none above). The second line is the real headline result: for 362 out of 363 tensors, YAQA's corrected version genuinely has less real, Hessian-weighted error than plain naive quantization would have — only 1 tensor (the known exception, lm_head, excluded from two-sided correction for memory reasons and handled by its own separate GPTQ pass instead) isn't counted in that 362.
This is Step A from Section 0 — the naive scaffold. The MTP ("multi-token prediction") module is a small, separate extra piece of the model that guesses several tokens ahead at once, to speed up generation. It has 15 real tensor pieces. This step just compresses those 15 tensors down to 4-bit with plain, uncorrected quantization (the norms and one combining layer, mtp.fc.weight, are left at full BF16 — they're small and not part of what gets YAQA-corrected). This creates a real, valid, loadable 299.7MB file — but it's about to be overwritten in Step B below.
Before Step B can measure how sensitive the MTP tensors really are, it needs real text to run through the model. "Stratified" means the text is deliberately pulled evenly from 6 different real kinds of writing this model actually sees (agent transcripts, code, instructions, prose, reasoning/"thought," and tool calls) — 4 separate 128-token windows from each of the 6 domains, 24 windows total. This matters because a calibration set that's accidentally all one kind of text (e.g. only code) would measure sensitivity that doesn't represent the model's real, varied use — this is the same "N=24 stratified" data you've been asking about elsewhere in this investigation, just built fresh here specifically for MTP.
This is the densest, most jargon-heavy part of the log. Below is the complete, real block for one tensor — mtp.layers.0.self_attn.q_proj — with every field explained against the actual safety_gate() code in yaqa_core.py.
Exactly the same effective-rank idea from 01_ZERO_TO_EXPERT_REDO.html Section 2, computed fresh for this MTP tensor: H_I's real risk concentrates in about 1.7 effective directions out of 5,120 possible; H_O in about 2.9 out of 12,288. Both close to 1 — a narrow, concentrated weak spot, same interpretation as before.
Before YAQA can use a Hessian matrix to compute a correction, that matrix has to be numerically "factored" in a stable way — the real algorithm used is called block LDL decomposition. Raw Hessians can be near-singular (numerically unstable to work with directly), so a small amount of regularization (sigma_reg, starting at 1.0) is added to stabilize the math before factoring. "Succeeded on attempt 1" means the gentlest regularization already worked — the code would automatically try progressively stronger values only if attempt 1 failed, and it didn't need to here.
Straight from yaqa_core.py's own safety_gate() function, checked against 4 real, independent conditions before any corrected tensor is accepted:
| Condition | What it checks | This tensor |
|---|---|---|
| 1. finite | No NaN/Infinity in the corrected weights | True |
| 2. beats_weighted | Real Hessian-weighted error is lower than naive quantization's | weighted=0.0041× naive → True |
| 3. within_frob | Raw (unweighted) magnitude of the change stays ≤1.25× naive's own raw change — a sanity check so condition 2 can't be gamed by a numerically extreme correction | frob=1.019× naive → True (1.019 ≤ 1.25) |
| 4. within_magnitude | No single corrected weight balloons past 2× the largest original weight | not printed in the short line, but confirmed True below |
weighted=0.0041x naive is the standout number: this tensor's real, Hessian-weighted rounding error after YAQA correction is only 0.41% of what naive rounding would have produced — a ~244x reduction in real, curvature-weighted error, for this one tensor. SAFE=True means all 4 conditions passed, so this corrected version is the one that actually gets used.
This is the same tensor's complete safety-gate record, hand-verifiable:
weighted_err (YAQA's real error) = 0.0000015066, vs naive_weighted_err (plain rounding's real error) = 0.0003672 — YAQA's is smaller, so beats_weighted = True. (0.0000015066 / 0.0003672 = 0.0041, matching the "0.0041x naive" from the short line above.)frob = 11.9165 vs naive_frob = 11.6912. Check: is 11.9165 ≤ 1.25 × 11.6912 (=14.614)? Yes → within_frob = True.max_abs_hatW (largest weight after correction) = 0.4791 vs max_abs_W (largest original weight) = 0.4746. Check: is 0.4791 ≤ 2.0 × 0.4746 (=0.9492)? Yes → within_magnitude = True.safe = True, exactly matching SAFE=True in the short summary line.The file from Step A (Section 5) is overwritten here with the real, YAQA-corrected version. "29 tensors" is everything in the MTP module (the 7 correctable linear projections you saw decoded above, plus norms, the combining layer, and other small pieces that don't go through YAQA correction). "7 real corrected" are specifically self_attn.{q,k,v,o}_proj and mlp.{gate,up,down}_proj — the same 7 tensor types the trunk's own DecoderLayer uses, confirming the MTP module really is architecturally one more decoder layer, corrected the same way as all 362 trunk tensors above it.
05_full_model_quantize.py, yaqa_core.py) · not yet promoted to the live site