record(MODEL-MATRIX): row the 7 recipe architectures that had none (#609, #610) by localai-bot · Pull Request #625 · mudler/vllm.cpp

localai-bot · 2026-08-13T11:23:27Z

Replaces #620 (same tree, clean history — see "Why a new PR" at the bottom).

Records only. No src/ or include/ change.

An audit of the 157 official model recipes at vllm-project/recipes 86c7777a,
joined to each model's HF config.json architectures and then to
.agents/model-matrix.md, found architecture strings with no row at all.
Seven are added here at INVENTORIED.

Seven, not eight, and not nine

#609 and #610 say two and seven; their own tables enumerate two and six.
Reproducing the audit independently — 157 recipes → 157 config rows → join —
returns exactly eight distinct architectures. The unit is the
architecture, and MossTTSDelayModel alone is reached by four recipes.

Of those eight, Qwen3_5MoeForCausalLM is already rowed by #490 / PR #601
under the identical stable ID MODEL-TEXT-qwen3-5-qwen3-5-moe-for-causal-lm
(verified with gh pr diff 601). Two branches adding the same keyed row merge
with no conflict and define it twice, silently. That row is left to its
owner; seven land here.

Row ID	Architecture	Recipes
`MODEL-TEXT-bailing-moe-v3-bailing-moe-v3-for-causal-lm`	`BailingMoeV3ForCausalLM`	Ling-3.0-flash
`MODEL-MM-moss-tts-moss-tts-delay-talker-for-generation`	`MossTTSDelayModel`	MOSS-TTS, MOSS-TTSD-v1.0, MOSS-SoundEffect, MOSS-VoiceGenerator
`MODEL-MM-moss-tts-moss-tts-realtime-talker-for-generation`	`MossTTSRealtime`	MOSS-TTS-Realtime
`MODEL-MM-qwen3-tts-qwen3-tts-talker-for-conditional-generation`	`Qwen3TTSForConditionalGeneration` (+ Talker alias)	Qwen3-TTS-12Hz-1.7B-CustomVoice
`MODEL-MM-higgs-audio-v3-higgs-audio-v3-talker-for-conditional-generation`	`HiggsMultimodalQwen3ForConditionalGeneration` (+ Talker alias)	higgs-audio-v3-tts-4b
`MODEL-MM-voxtral-realtime-voxtral-realtime-for-conditional-generation`	`VoxtralRealtimeForConditionalGeneration` (target-pending)	Voxtral-Mini-4B-Realtime-2602
`MODEL-MM-bailing-mm-native-bailing-mm-native-for-conditional-generation`	`BailingMMNativeForConditionalGeneration` (target-pending)	Ming-omni-tts-0.5B

Why dropping the Qwen row is right, not just deconflicting

Qwen3_5MoeForCausalLM is neither an alias of
Qwen3_5MoeForConditionalGeneration nor a new port. The class already exists
at our pin (qwen3_5.py:381; main :443) and is exactly what the multimodal
class builds as its own text tower:
self.language_model = Qwen3_5MoeForCausalLM(...) at qwen3_5.py:643 (pin) /
:724 (main). vLLM main only added a registry entry (registry.py:203)
exposing that existing backbone standalone — same module, different class,
different task category, no vision tower, no MM processor.

Which is exactly why registering it, as #601 does, is the correct treatment,
and an INVENTORIED row here would have understated it.

BailingMoeV3ForCausalLM is a new module, not a class rename: V2.5
(bailing_moe_linear.py, 821 lines at the pin) pairs MLA with Bailing linear
attention; V3 (bailing_moe_v3.py, 1495 lines on main) keeps MLA and swaps the
linear arm for Kimi Delta Attention, adds per-projection causal conv1d,
grouped-topk MoE via config.n_group, a clamped SwigluStepAndMul, an fp8
quant-config hook, and refuses a checkpoint without no_kda_lora=True.

The two target-pending rows record what was searched rather than an invented
anchor: the exact config.json strings appear in none of the pinned registry,
any of the ten dictionaries of main's registry.py, vllm-omni's
_OMNI_MODELS, or vllm-omni's supported_models.md. Near misses are named
(VoxtralRealtimeGeneration is registered at the pin and already has its own row;
vllm-omni carries a BailingMM2NativeForConditionalGeneration alias — note the
2) without asserting either is the target.

Counts

Re-derived from the file with the checker's own parser, not by arithmetic:
369 rows — INVENTORIED 321, PARTIAL 20, ACTIVE 9, SPIKE 7, BLOCKED 5,
READY 3, DONE 3, GATING 1, and 48 non-INVENTORIED. Header prose follows:
326 at the pin + 10 beyond = 336, long tail 291, engaged 45 unchanged.
check-agent-record's MODEL pin 362 → 369.

The at-the-pin model inventory is unchanged (324/373/356/310/261): none of the
seven is at the pin, so like the MuseGlimmer, KimiK3 and MiniMaxH3DiT rows they
spell module and class as separate fields instead of the colon-pair form
check_model_invariants counts. Existing convention — no checker expectation
was widened.

One pre-existing error corrected while the block was open: the caption read
"the 49 non-INVENTORIED rows" where the file has, and had, 48.

Mutation evidence (`pr-size` contract)

Two tests added. What each catches was measured, not assumed; tree restored
byte-for-byte after each mutation.

Mutation	Caught by
A. Delete a pinned row + bump the count to hide it	Both new tests; none of the 49 pre-existing. Also the CLI — but via the roadmap dangling-reference check, not the ratchet, and only because that row is intake-linked
B. Give an out-of-repo row an at-the-pin colon-pair anchor	New inventory test and the CLI's own `check_model_invariants`. No pre-existing test
C. Delete an unpinned new row (Higgs — not intake-linked, not named by the ratchet test) + bump the count	ONLY `test_beyond_pin_rows_stay_out_of_the_at_pin_model_inventory`. CLI prints `agent record OK: ... MODEL=368`; every pre-existing test passes. `check-model-checklist` still catches it via the rollup

Stated plainly: B is a third pin on something the CLI already defends (as its
Windows precedent also is). C is a defect only the new test catches.

Evidence

$ python3 scripts/check-model-checklist.py
OK: architecture-support checklist matches the detailed row states.

$ python3 scripts/check-agent-record.py
agent record OK: ENGINE=152 MODEL=369 QUANT=82 KERNEL=51 BACKEND=81

$ python3 scripts/check-pr-size.py --base origin/main --head HEAD ...
OK: every explicit path class is within its review budget.

$ python3 scripts/check-doc-checkpoint.py --base origin/main --head HEAD
OK: public documents match the claims this change makes.

scripts/agent-preflight.sh --staged → exit 0, 71 gates ok, zero failures.

Why a new PR instead of pushing to #620

#620's first commit changed a feature_surface without docs/FEATURES.md in
that same commit. check-doc-checkpoint is per-commit by design and has no
exemption mechanism ("that is precisely how the old gate grew six hardcoded
escape hatches"), so no later commit could clear it — I verified that directly.
The only remedies were rewriting published history or clean history on a fresh
branch. This protocol takes no force variant, so: fresh branch. The tree here
is byte-identical to the verified #620 head.

Also filed #618 — test_cpu_x86_llamacpp_floor's contended-leg case went red at
loadavg 63 and green at 21.9 on the same tree; it races the quiet-window gate and
fails toward a verdict on whatever diff is in flight. Filed, not fixed here.

Closes #609.
Closes #610.

, #610) FOLLOWING_AGENTS_PROTOCOL The matrix claims exhaustive coverage. An audit of the 157 official model recipes at vllm-project/recipes 86c7777a, joined to each model's HF config.json architectures and then to this file, found eight architecture strings with no row. Seven of them are added here at INVENTORIED; the eighth is left to the branch that already owns it. Records only: no src/ or include/ change, and no mark claims more than its row backs. SEVEN, NOT EIGHT, AND NOT NINE. The issues say two and seven; their own tables enumerate two and six. Reproducing the audit independently -- 157 recipes -> 157 config rows -> join against this file -- returns exactly eight distinct architectures, because the unit is the ARCHITECTURE and MossTTSDelayModel alone is reached by four recipes. Of those eight, Qwen3_5MoeForCausalLM is already rowed by #490 / PR #601 under the identical stable ID MODEL-TEXT-qwen3-5-qwen3-5-moe-for-causal-lm, verified with `gh pr diff 601`. Two branches ADDING the same keyed row merge with NO conflict and define it twice, silently, so that row is left to its owner and seven land here. That exclusion is worth its reasoning, because the row looked cheap. Qwen3_5MoeForCausalLM is neither an alias of Qwen3_5MoeForConditionalGeneration nor a new port: the class already exists at our pin (qwen3_5.py:381; main :443) and is exactly what the multimodal class builds as its own text tower -- `self.language_model = Qwen3_5MoeForCausalLM(...)` at qwen3_5.py:643 (pin) / :724 (main). vLLM main only added a REGISTRY entry at registry.py:203 exposing that existing backbone standalone: same module, different class, different task category, no vision tower, no MM processor. Which is precisely why REGISTERING it, as #601 does, is the right treatment and an INVENTORIED row here would have understated it. BailingMoeV3ForCausalLM succeeds BailingMoeV2_5ForCausalLM but is a new module rather than a class rename: V2.5 (bailing_moe_linear.py, 821 lines at the pin) pairs MLA with Bailing linear attention, whereas V3 (bailing_moe_v3.py, 1495 lines on main) keeps MLA and swaps the linear arm for Kimi Delta Attention, adds per-projection causal conv1d, grouped-topk MoE via config.n_group, a clamped SwigluStepAndMul, an fp8 quant-config hook, and refuses a checkpoint without no_kda_lora=True. Line anchors are on the row. The six #610 rows follow the MiniMaxH3DiTModel precedent, the one vllm-omni architecture already rowed. Four resolve in vllm_omni/model_executor/models/registry.py @ bbe6ccc5. Two do not resolve anywhere: VoxtralRealtimeForConditionalGeneration and BailingMMNativeForConditionalGeneration are the literal config.json strings of their recipes and appear in none of the pinned registry, any of the ten dictionaries of vLLM main's registry.py, vllm-omni's _OMNI_MODELS, or vllm-omni's supported_models.md. Both are recorded target-pending with what was searched and the near misses named -- VoxtralRealtimeGeneration is registered at the pin and already has its own row here, and vllm-omni carries a BailingMM2NativeForConditionalGeneration alias, note the 2 -- but no anchor is asserted for either. COUNTS, re-derived from the file with the checker's own parser rather than by arithmetic: 369 rows, INVENTORIED 321, PARTIAL 20, ACTIVE 9, SPIKE 7, BLOCKED 5, READY 3, DONE 3, GATING 1, 48 non-INVENTORIED. Rollup and header prose follow: 326 at the pin plus 10 beyond = 336, long tail 291, engaged 45 unchanged. check-agent-record's MODEL pin moves 362 -> 369. The at-the-pin model inventory (324 rows / 373 memberships / 356 architectures / 310 targets / 261 modules) is deliberately UNCHANGED. None of the seven is at the pin, so like the MuseGlimmer, KimiK3 and MiniMaxH3DiT rows before them they spell module and class as separate fields instead of the colon-pair form that check_model_invariants counts, and contribute nothing. Existing convention, not a relaxation: no checker expectation was widened to make this pass. One pre-existing error in the header block is corrected while it is open: the caption read "the 49 non-INVENTORIED rows" where the file has, and had, 48. MUTATION EVIDENCE. check-pr-size classifies scripts/check-agent-record.py as a governance checker and requires companion evidence in tests/scripts/test_agent_record.py for ANY edit, count bumps included. Two tests are added, and what each actually catches was MEASURED, not assumed: test_recipe_backfill_rows_are_inside_the_model_ratchet mirrors the existing test_windows_release_row_is_inside_the_engine_ratchet, naming two of the seven rows the bump was taken for. test_beyond_pin_rows_stay_out_of_the_at_pin_model_inventory pins the convention above. Nothing tested it: setUpClass never calls check_model_invariants at all. Three mutations, tree restored byte-for-byte after each: A. Delete a pinned row AND bump the count to hide it. Caught by both new tests; by none of the 49 pre-existing ones. Also caught by the check-agent-record CLI, but through the roadmap dangling-reference check rather than the ratchet, and only because that row is intake-linked. B. Give an out-of-repo row an at-the-pin colon-pair anchor, row count unchanged. Caught by the new inventory test AND by the CLI's own check_model_invariants. No pre-existing test catches it. C. Delete an UNPINNED new row (the Higgs one -- neither intake-linked nor named by the ratchet test) and bump the count to hide it. Caught ONLY by test_beyond_pin_rows_stay_out_of_the_at_pin_model_inventory. The CLI prints "agent record OK: ... MODEL=368" and every pre-existing test passes. A different checker, check-model-checklist, still catches it via the rollup. So B is honestly a third pin on something the CLI already defends, as its Windows precedent also is; C is a defect only the new test catches. Supersedes PR #620, whose first commit changed a feature_surface without docs/FEATURES.md in that same commit. check-doc-checkpoint is per-commit by design and has no exemption mechanism, so no later commit could clear it and the only remedies were rewriting published history or clean history on a fresh branch. This protocol takes no force variant, so this is the fresh branch; the tree is byte-identical to the verified #620 head. Also files #618: test_cpu_x86_llamacpp_floor's contended-leg case went red at loadavg 63 and green at 21.9 on the same tree -- it races the box's quiet-window gate, so it fails toward a verdict on whatever diff is in flight. Filed, not fixed here: it changes a test's semantics. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]

FOLLOWING_AGENTS_PROTOCOL `test_model_row_ratchet_is_load_bearing`'s docstring still read "the eight recipe architectures ... took it 362 -> 370". Both numbers are from the pre-correction revision of this branch: seven rows landed, the constant is 369, and the new test's own docstring one screen below already said 362 -> 369. So the file stated two different bumps for the same change. That is worse than a typo because of where it sits. The docstring IS the prose explanation of why the ratchet exists, and AGENTS.md is explicit that keeping two descriptions in sync is the failure mode this protocol was built to remove -- a ratchet whose explanation contradicts its own constant is the exact drift it is there to catch. The next person to re-pin the count reads the docstring, not the constant. Verified by grep rather than by eye. Across every line this branch ADDS, the only remaining occurrence of 370, 322, 337, 292 or "eight" is the deliberate "SEVEN, not eight: the audit's eighth architecture" sentence in the checker comment, which is load-bearing -- it records why the audit's eighth architecture is left to #490 / PR #601. The corrected numbers appear consistently: 369 x5, 336 x2, 321, 291, seven x6. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]

localai-bot · 2026-08-13T11:34:22Z

Finding accepted and fixed in `d6cdd88b2` — added as a commit, no history rewrite (fast-forward `cbace19bc..d6cdd88`).

You were right that this was more than a typo. `test_model_row_ratchet_is_load_bearing`'s docstring is the prose explanation of why the ratchet exists, and it contradicted its own constant one screen above the new test that already said `362 -> 369`. The next person to re-pin reads the docstring.

Grep results, both files, as asked — not eyeballed.

Before:

$ grep -n "370" tests/scripts/test_agent_record.py
260:        eight recipe architectures that had no row at all took it 362 -> 370
$ grep -ni "eight" tests/scripts/test_agent_record.py
260:        eight recipe architectures that had no row at all took it 362 -> 370
$ grep -n "370" scripts/check-agent-record.py
(none)

After:

$ grep -n "370" tests/scripts/test_agent_record.py        -> (none)
$ grep -ni "eight" tests/scripts/test_agent_record.py     -> (none)
$ grep -n "370" scripts/check-agent-record.py             -> (none)
$ grep -niE "\beight\b" scripts/check-agent-record.py
52:    # of an invented anchor. SEVEN, not eight: the audit's eighth architecture

That last one is deliberate and load-bearing — it records why the audit's eighth architecture is left to #490 / PR #601. The bare `grep -ni eight` on the checker also matches substrings inside `weight`/`weighted` on lines 62/94/111/135/144/165, which is why the whole-word form is the honest check.

I also swept every line this branch adds rather than just those two files, since a stale number could have hidden in the matrix or roadmap:

$ git diff origin/main -- <the 5 changed files> | grep -E "^\+" | grep -nE "\b370\b|\b322\b|\b337\b|\b292\b|\beight\b"
46:+    # of an invented anchor. SEVEN, not eight: the audit's eighth architecture

One hit, the intended one. The corrected values appear consistently across added lines: `369` x5, `336` x2, `321`, `291`, `seven` x6. Both docstrings now agree:

260:        seven recipe architectures that had no row at all took it 362 -> 369
286:        """The #609/#610 rows and the 362 -> 369 bump are one semantic change.

Gates re-run afterwards under the exact CI invocations:

$ python3 scripts/check-pr-size.py --base origin/main --head HEAD --branch row/model-matrix-recipe-backfill-clean --pr-number 625
OK: every explicit path class is within its review budget.

$ python3 scripts/check-agent-record.py
agent record OK: ENGINE=152 MODEL=369 QUANT=82 KERNEL=51 BACKEND=81

$ python3 scripts/check-doc-checkpoint.py --base origin/main --head HEAD
OK: public documents match the claims this change makes.

$ python3 scripts/check-model-checklist.py
OK: architecture-support checklist matches the detailed row states.

$ python3 tests/scripts/test_agent_record.py
Ran 51 tests in 10.423s
OK

`scripts/agent-preflight.sh --staged` -> exit 0, 71 gates ok, zero failures.

…622) FOLLOWING_AGENTS_PROTOCOL NOW.md said "all 362 archs have rows". That number is owned by model-matrix.md, whose rollup is CI-enforced, and #625 moves it to 369 -- so the line was about to be wrong, as it had been before. Bumping it would be the wrong fix. AGENTS.md is explicit: never store a measurement of one file inside another, because a number that moves on every edit couples every PR to lines it does not own. NOW.md is authored at operator cadence and is "never a per-row lifecycle write", so a row-adding PR could not satisfy both rules at once -- it had to leave NOW.md wrong or touch a file outside its scope. That is a records defect, not a stale line, and it is #622. The claim survives without the figure: "every arch in the pinned registry has a row" is what the sentence was actually asserting, and it stays true as rows are added. The count is one link away in the file that owns it. Removing the number removes the failure mode instead of guarding it -- and nothing checks NOW.md's figure against the matrix, deliberately, since that would be the second description this protocol exists to avoid. NOW.md stays inside budget: 73 lines / 3,822 chars against 100 / 6,000. scripts/agent-preflight.sh --staged: exit 0. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]

…nd record the literal-scanning trap (#606) Two things the next person on this row would otherwise re-derive, so the spec's Now section states them. The PR cannot go fully green, and not because of this change. windows-msvc-cpu and windows-msvc-vulkan fail with test_openai_api_server.exe exiting -1073740791, which is 0xC0000409, STATUS_STACK_BUFFER_OVERRUN, already tracked as #584. Attributed rather than assumed: #625 fails with the byte-identical exit status while touching no src/ or include/ path at all, so a records-only PR reproduces it. test_openai_api_server is not a consumer of this seam either -- it never calls ParseArgs. And the trap this change walked into. check-windows-portability.py scans the shipped server sources with comments stripped but STRING LITERALS INTACT, and its POSIX-call pattern matches a bare `open` before a parenthesis, so prose in a user-facing message was reported as an unguarded POSIX call reaching Windows. The gate is Windows-only and is not part of scripts/agent-preflight.sh, which means an all-green local preflight says nothing about it. That is the part worth writing down: the failure mode is not the rule being wrong, it is a gate the local preflight does not cover. Record only. No product code, no test, no checker touched. scripts/agent-preflight.sh --staged: exit 0, all gates green. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]

…610) FOLLOWING_AGENTS_PROTOCOL main advanced while this branch was open (#489, plus the four recipe-sweep PRs that landed ahead of it), and roadmap_v1.md's Open-issues table conflicted. That table is a KEYED RECORD, so AGENTS.md forbids resolving it by automatic three-way merge -- "merging two such edits cleanly is worse than conflicting, because it applies both". Resolved as the rule prescribes instead: took main's roadmap_v1.md WHOLESALE, then reapplied this branch's three scoped rows (#618, #610, #609), each anchored beside its row-ID sibling. Verified rather than asserted: the resulting diff against main is +3 lines and -0. Zero removals is the check that matters -- it proves no key of main's was dropped or rewritten by the resolution. Every other conflicted path auto-merged in non-keyed regions and was left to git. scripts/agent-preflight.sh --staged: exit 0, all gates green. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]

localai-bot mentioned this pull request Aug 13, 2026

record(MODEL-MATRIX): row the 8 recipe architectures that had none (#609, #610) #620

Closed

This was referenced Aug 13, 2026

The recipe sweep could not read 20 of 157 configs, so its architecture counts are a floor presented as a total #626

Open

feat(SERVE-RECIPE-ARGS): accept two inert recipe flags so a published vllm serve line reaches model load (#606) #624

Merged

This was referenced Aug 13, 2026

spec(SAMPLE-REASONING): W3 runs before W2, on measured recipe demand (#605) #616

Merged

spec(SERVE-RECIPE-ARGS): a published recipe command must reach model load (#606) #613

Closed

localai-bot merged commit eba6ab7 into main Aug 13, 2026
18 of 20 checks passed

localai-bot deleted the row/model-matrix-recipe-backfill-clean branch August 13, 2026 14:28

Navigation Menu

record(MODEL-MATRIX): row the 7 recipe architectures that had none (#609, #610) - #625

record(MODEL-MATRIX): row the 7 recipe architectures that had none (#609, #610)#625
localai-bot merged 3 commits into
mainfrom
row/model-matrix-recipe-backfill-clean

localai-bot commented Aug 13, 2026

Uh oh!

localai-bot commented Aug 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

localai-bot commented Aug 13, 2026

Seven, not eight, and not nine

Why dropping the Qwen row is right, not just deconflicting

Counts

Mutation evidence (pr-size contract)

Evidence

Why a new PR instead of pushing to #620

Uh oh!

localai-bot commented Aug 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Mutation evidence (`pr-size` contract)