feat(MODEL-MM-dots3-note): W2 — the whole 38006-tensor index, with the towers named as deferrals (#699)

[localai-bot]

W2 of the dots3-note row (#699). W1 accounted 1614 tensors over a four-layer
slice of the released shard index and left the other 36392 unread. This reads
the index in full and joins it to the safetensors header of all 133 files it
names.

What changed

The accounting is 38006 / 38006: 35381 language, 2195 vision, 430 audio,
zero unaccounted, zero missing, zero duplicated, zero invented. Every case that
touches the buckets states all three by number.

That polarity is the point of the brick. "Nothing was left over" is also true of
a classifier that counts the two towers as language, which is the mutation the
#1805 review found passing (M15). At W1's scale it was a latent hole. At this
scale it would make "100% accounted" cover 2625 weights nobody loads.

A deferral is now a record rather than a counter. Dots3NoteDeferredTowers()
names the prefix, the one file each tower ships in, the brick that owes it and
what it is; AccountDots3NoteTensors dispatches on that table instead of on two
prefix literals; and the load refusal prints the table, so an unknown tensor is
distinguishable from a deferred one in the message a user gets.

Why the change is needed

Spec §6.4 records that this row has no oracle on any host we own, so there is no
token gate downstream of these assertions. A weight nobody loads reads as zeros
and renders. The name map is the only instrument that says the port knows what
the checkpoint contains.

Three things the slice could not reach

1. The backbone has exactly four distinct layer shapes. {0} dense + full
   at 19 tensors, the 12 full + MoE layers {1, 5, ... 45} at 789, the 33
   sliding + MoE layers at 784, and {46} at 18. W1 recorded "the remaining 42
   backbone layers repeat layers 1/2 exactly" as a claim about a checkpoint
   nobody had read. It holds, and a fifth class would have meant the port was
   reading some layer with the wrong map.

2. The full/sliding split read off the weights matches config.layer_types
   exactly. The DSA indexer ships only on the full class, so the shipped
   indexer.wk names give the schedule independently of the config. Two
   independent released artifacts agreeing is stronger than either alone.

3. The checkpoint carries 62 F32 tensors in two families, not one. The 45
   language mlp.gate.e_score_correction_bias W1 predicted, and 17
   vision_encoder.blocks.{25..41}.mlp.router_bias its language-only slice
   could not see. Their widths are the vision pyramid's own routed-expert
   counts: fp32 learned router statistics inside an otherwise BF16 tower. The
   census closes at 37944 BF16 + 62 F32 with no third dtype anywhere.

   This is not spec R5, which an earlier draft of this description claimed.
   R5 and §2.4 are the FP32 dynamic activation scales in
   note_vision_fused_moe_fp8, and the bf16 checkpoint ships no scale tensors
   at all — every one of its 38006 entries is a named parameter. R5 stays wholly
   owed by W6.

And one finding

The index's metadata block declares indexer_rope_layout: "leading" and
indexer_rope_converted_from: "tail". git grep indexer_rope_layout over vLLM
origin/main returns nothing, so upstream reads neither key. It agrees with
what upstream's code does anyway, and it is not spec §4 trap 2: trap 2 is
about which pairs the rope rotates, this is about which half of the 128-wide
index head it rotates. Both are numerically silent on a row with no oracle.

W2 pins both values in an assertion and consumes neither, because W2 writes no
maths. #1846 owns it and W3 owes the slice.

How a reviewer can verify it

cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug \
      -DCMAKE_CXX_FLAGS_DEBUG=-O0 -DCMAKE_C_FLAGS_DEBUG=-O0 \
      -DVLLM_CPP_BUILD_EXAMPLES=OFF -DVLLM_CPP_SERVER=OFF
ninja -C build test_dots3_note_scaffold
./build/tests/test_dots3_note_scaffold

Observed: test cases: 26 | 26 passed, assertions: 110821 | 110821 passed,
exit 0, about 170 s at -O0 of which roughly 135 s predates W2. CPU-only. No
GPU lease was taken and none was needed.

The fixture is reproducible from the release. The committed
config.json was re-fetched at the same revision and is byte-identical, sha256
99b7de680dd456111c36efb8749f8ae7177328e97b65a3e39a6700cbc1173833. The index
is sha256 95a364b468a93ccad6adcb9c3aa110cb7a1411c2575c334c39022f9f84d456e1.

No tensor byte was downloaded. The fixture is a headers-only projection:
266 HTTP Range requests over the 133 shard headers, 4770592 bytes in total,
against a checkpoint of 576886825984 bytes.

The mutation table is spec §4.4: fifteen rows, every one applied to the tracked
source or the committed fixture, rebuilt, run and reverted with the tree
verified byte-for-byte, and every one RED with compile_err=0 printed beside
it. Two rows are worth reading rather than counting. One guard came back GREEN
— an AccountDots3NoteTensors VT_CHECK that no input can reach — and it was
DELETED rather than kept, with M12b replacing it by injecting the defect it was
meant to catch. One row exited 135 with no doctest summary while the box sat
at 92% disk; re-run alone it compiled clean and went red on 5 cases, and both
readings are on record, because a crash is not a red test.

What the fresh review changed

The review returned PASS with one MEDIUM and four LOW, and all five are fixed on
this head.

F1, MEDIUM, and it corrected a recorded measurement. TempConfig and
TempCheckpoint built their /tmp paths from a per-process static int counter, so two concurrent runs of this binary shared one directory: each
constructor rewrote a file the other had mmapped through
SafetensorsFile::Open, and each destructor removed the other's. That is the
exit 135 this spec first blamed on disk pressure, and the cause was wrong. Both
paths are now process-unique, and the RED-before pair is measured here rather
than inherited — two concurrent runs at 45 GB free and 34 GB of free RAM:

arm	compiler exit	run A	run B	summary printed
UniqueTempDir (fixed)	0	exit 0	exit 0	both
static int counter (RED)	0	exit 1	exit 135, Bus error (core dumped)	neither

Neither RED process printed a summary, which is the hazard: SIGBUS kills a
block-buffered doctest, so the mode is no result, and no result reads like a
run still in progress. The RED arm needed [[maybe_unused]] to compile, because
a mutation that fails to build reads as a passing test. getpid is not used —
MSVC spells it _getpid behind another header. The same shape in five other
test files is #1860 and is not touched here.

F2, LOW. Dots3NoteAccounting::deferred() had no production caller and its
second check was unreachable by exactly the argument that deleted the M12 guard,
so it is deleted rather than staged.

F3, LOW. The classifier ended else ++acc.audio, so a third registered
tower would have been counted as audio. It now dispatches on the table index and
reports a counter-less tower as unaccounted, so the load refuses naming it.

F4, LOW. The mapper anchor cited multimodal.py:53-62, which is W1's line at
c205726108. At 185cada36b, the revision W2 says it re-read, it is :70-78.
Corrected in the source comment and in the porting inventory.

F5, LOW. The test docblock still described W1 only. It now describes what the
file gates.

The review also ran a mutation this branch's own table lacked — deleting the
production call site of AccountDots3NoteTensors in LoadDots3NoteWeights —
and it came back RED, so the map is reached through the registry rather than
only exercised by helpers. That row is recorded in spec §4.4.

What remains unverified or out of scope

The forward still refuses by name, and so do GGUF and every arm past the name
map. No maths, no attention, no MoE execution, no towers, no MTP: those are
W3 to W10.

The row stays SPIKE. Reading a weight map is not porting a model.

Every number owed under spec §6.4 option B stays owed: no throughput, latency
or memory axis is claimable for this model, because the oracle does not run on
any host this project owns.

The full 599-test ctest suite was not run locally for this change and
therefore stands unreproduced here, in either direction. scripts/agent-preflight.sh
passed clean, check-commit-trailers and check-commit-style both pass over
origin/main..HEAD on a rebased branch, and test_dots3_note_scaffold is the
only target this change can affect. CPU-only: no CUDA, Vulkan, Metal or
sanitizer build ran here, and CI owns those lanes.

CI

Green after the rebase onto c14fee79b, except the two Windows lanes, and
neither is this change.

build-test-cpu passes, which is the lane that runs the whole
ctest --test-dir build --output-on-failure, so the full suite IS reproduced
green on x86. build-newest-gcc, build-test-cpu-arm64, build-test-vulkan,
cuda-fat-build, both sanitize-cpu arms, device-leakage, agent-record,
documentation-checkpoint and commit-protocol-tag all pass.

windows-msvc-cpu and windows-msvc-vulkan fail, and the log names the cause:
test_openai_api_server.exe exited with status -1073740791, which is
STATUS_STACK_BUFFER_OVERRUN. That is #584, and it is not attributable to this
branch — PR #1776 shows the byte-identical failure on a run from 2026-08-23,
before W1 landed any dots3 code at all. Every .vcxproj in the log links, so
the compile defect these lanes carried until this morning is gone: that one was
the [[noreturn]]-on-a-non-void-ForwardDevice declaration W1 landed, #1840
fixed it on main at c14fee79b, and the rebase picks the fix up. What is left
is the runtime crash #1840's own body predicted would be unmasked.

Refs #699. Closes nothing: #699 tracks the whole row.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]