From b459026af8cf23cf1acf3217b8d644630884b306 Mon Sep 17 00:00:00 2001 From: Ettore Di Giacinto Date: Thu, 13 Aug 2026 10:27:07 +0000 Subject: [PATCH 1/7] record(intake): place the recipes.vllm.ai sweep and its six issues (#605-#610) FOLLOWING_AGENTS_PROTOCOL The 2026-07-28 feature-gap sweep asked what vLLM has that we lack. This one asks a different question -- can a user run the PUBLISHED recipe for a model we already ship -- and the answers disagree. Read vllm-project/recipes at 86c7777a: 157 model recipes, 70 distinct CLI flags, 15 env vars. Architectures resolved from each model's HF config.json (137/157; the rest are gated repos or diffusion pipelines with no top-level architectures) and joined against model-matrix.md and the registry at the pin. Model coverage is broad -- 79 of the unstarted recipes already have rows, so they are scoped, not missing. The serve surface is where it breaks. vllm-serve aborts on an unknown argument, so an unmapped flag is not a degraded run but no run: --enable-auto-tool-choice (89 recipes) and --trust-remote-code (82) are both no-ops for us and both abort startup. --reasoning-parser resolves 10 of upstream's 28 names, so 61 of 76 recipe uses throw -- including qwen3, the corpus's single most common value, which the published Qwen3.5/3.6 recipes pass to models we gate token-exact. Tool parsers are the healthy axis at 82/90. #605 is placed on SAMPLE-REASONING rather than opening a track: that spec already enumerates these names in W2/W3. What the recipe data adds is the ordering, and it inverts the numbering -- W3 covers 43 of 76 uses, W2 covers 18 and four of its names have zero. #606 and #607 are left as em dashes because no row owns serve CLI recipe compatibility, and a wrong row id in a keyed record is worse than an honest blank. Two things worth recording beyond the issues. --language-model-only, --async-scheduling, --enforce-eager and --mamba-ssm-cache-dtype appear in this repo only in tools/bench/ scripts that drive the ORACLE, so grepping the flag name reads as coverage and is the opposite of it. And taxonomy.yaml carries a dgx_spark_gb10 profile that 8 recipes declare -- upstream has published GB10-validated configurations for our exact gate box, six of them for rows already active, which fixes the honest denominator for us instead of us choosing it. Records only, no product code touched. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code] --- .agents/roadmap_v1.md | 81 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) diff --git a/.agents/roadmap_v1.md b/.agents/roadmap_v1.md index 5fb7978a0..0051b071d 100644 --- a/.agents/roadmap_v1.md +++ b/.agents/roadmap_v1.md @@ -169,6 +169,12 @@ issue is not yet placed. Keyed record: update in place, never append. | [#552](https://github.com/mudler/vllm.cpp/issues/552) | `MODEL-TEXT-deepseek-v4-deepseek-v4-for-causal-lm` | DSA top-k review findings: the `w < topk` guard comment overclaims what it defends, the window clamps and non-positive `topk` are ungated, and `DsaTopkLaunch` swallows its launch error (spec `specs/dsa-topk-bounds.md` §7) | bug | | [#469](https://github.com/mudler/vllm.cpp/issues/469) | — | `test_ops_glue.cpp:190`'s `CHECK_THROWS` is satisfied by the CPU kernel's second guard, not the dispatch guard it names — mutation M8 survives. Behavior is correct; test strength only | bug | | [#558](https://github.com/mudler/vllm.cpp/issues/558) | — | `tests/parity/hf_snapshot.h` has no guard against declaration-order breaks: the C++ build catches them, but the records-only lane that broke it never builds C++, and all 14 TUs that include the header are checkpoint-gated so `ctest` reports the break as `***Not Run`. `fafa16f0f` (#546, #551) fixed the ordering and carried no guard | bug | +| [#605](https://github.com/mudler/vllm.cpp/issues/605) | `SAMPLE-REASONING` | `--reasoning-parser` resolves 10 of upstream's 28 names, so 61 of 76 official-recipe uses abort at startup — including `qwen3` (18 uses), which the published Qwen3.5/3.6 recipes pass to models we already gate token-exact. Reorders the spec's waves: W3 covers 43/76 recipe uses, W2 covers 18 and four of its names have zero | feature | +| [#606](https://github.com/mudler/vllm.cpp/issues/606) | — | `vllm-serve` aborts on `--enable-auto-tool-choice` (89/157 recipes) and `--trust-remote-code` (82/157), both of which are no-ops for us, so a copy-pasted official recipe command never reaches model load. Needs an accepted-and-inert seam with a per-flag reason; no row owns serve CLI recipe compatibility | feature | +| [#607](https://github.com/mudler/vllm.cpp/issues/607) | — | No `--language-model-only`: 43 recipes skip the vision encoder to hand its VRAM to the KV cache and we load the tower unconditionally. The flag appears in this repo only in `tools/bench/run_serve_low.py`, which passes it to the ORACLE — a grep reads as coverage and is not | feature | +| [#608](https://github.com/mudler/vllm.cpp/issues/608) | `TOOLS-PARSER-BREADTH` | Six `--tool-call-parser` names missing (`openai`, `inkling`, `minimax_m3`, `nemotron_json`, `kimi_k3`, `ling3`), closing the last 8 of 90 official-recipe uses; four are portable at the pin, two are post-pin | feature | +| [#609](https://github.com/mudler/vllm.cpp/issues/609) | — | Model matrix is short two recipe architectures that exist in vLLM `main` but not at our pin: `Qwen3_5MoeForCausalLM` (Qwen3.8-2.4T-A95B — a new registry entry for the Qwen3.5-MoE family we already ship gated) and `BailingMoeV3ForCausalLM` (Ling-3.0-flash, successor to the rowed `BailingMoeV2_5ForCausalLM`) | records | +| [#610](https://github.com/mudler/vllm.cpp/issues/610) | — | Seven `vllm-omni` recipe architectures have no model-matrix row, so the TTS / audio-generation modality is entirely unplaced: four confirmed in `vllm-omni`'s supported-models doc, two located in neither core `main` nor omni. Precedent for rowing an omni-repo architecture already exists (`MiniMaxH3DiTModel`) | records | ## Top-level portfolio @@ -546,6 +552,81 @@ reuse). Risks: variable-Q-head + dual-RoPE×partial×YaRN composition (medium), oracle-blocked residual if remote-code is refused (falls back to llama.cpp-only, de-risked by the W1 config check). +## Recipe-surface sweep (2026-08-13, `recipes.vllm.ai`) + +`recipes.vllm.ai` is a front end over **`vllm-project/recipes`**; the audit read +that repo at `86c7777aa699482ef1ebd0c5da9fc540ccc00a40` — **157 model recipes** +under `models/*/*.yaml`, plus `taxonomy.yaml`, `platforms.yaml` and `strategies/`. +Architectures were resolved from each model's HF `config.json` (137/157 — the rest +are gated repos or diffusion pipelines with no top-level `architectures`), then +joined against `model-matrix.md` and checked against vLLM's registry at the pin. + +This is the **user-facing** complement to the 2026-07-28 feature-gap sweep. That +one asked what vLLM has that we lack; this one asks whether a user can run the +published recipe for a model we already ship. The two disagree, and where they do, +this one is the sharper signal: a model gated token-exact whose own recipe command +aborts at argument parsing is not usable, however good the kernels are. + +### What a recipe lets a user tweak + +Six axes: `base_args`/`base_env`, **7 named feature toggles** (`tool_calling` 90, +`reasoning` 76, `spec_decoding` 53, `text_only` 43, `encoder_parallel` 34, +`thinking_always_on`, `video_compression`), **variants** (9 precisions — bf16 151, +fp8 79, nvfp4 50, int4 19, mxfp4 10), **9 parallelism strategies**, +`hardware_overrides`, and the **KV-offload row**. In total **70 distinct CLI flags +and 15 env vars**. + +### Coverage against our serve surface + +`vllm-serve` accepts 65 flags and **hard-errors on an unknown argument** +(`src/vllm/entrypoints/openai/server_main.cpp:440`), so an unmapped flag is not a +degraded run — it is no run at all. + +| Axis | State | Issue | +|---|---|---| +| `--tool-call-parser` | 41 names, **82/90 recipe uses (91%)** — the healthy axis | [#608](https://github.com/mudler/vllm.cpp/issues/608) for the last 8 | +| `--reasoning-parser` | 10 of 28 names, **15/76 uses (20%)**; `qwen3` (18) rejected on our own gate models | [#605](https://github.com/mudler/vllm.cpp/issues/605) | +| `--enable-auto-tool-choice`, `--trust-remote-code` | no-ops for us, yet **abort startup** on 89 and 82 recipes | [#606](https://github.com/mudler/vllm.cpp/issues/606) | +| `--language-model-only` | absent; 43 recipes use it to free encoder VRAM | [#607](https://github.com/mudler/vllm.cpp/issues/607) | +| `--kv-cache-dtype` | not a serve flag; residual on the `KV-FP8` row | — | +| `--speculative-config` | MTP + DFlash land; `eagle`/`eagle3` (7 uses) do not | — | +| TP / EP / multi-node (`--tensor-parallel-size`, `--enable-expert-parallel`, `--mm-encoder-tp-mode`) | absent by scope, not by defect — single-box engine | see the TP W-plan above | +| KV offload | **ahead** — 45 recipes mark `offloading_cpu`/`offloading_fs` verified; we ship `--kv-transfer-config` + `docs/KV-OFFLOAD.md` | — | + +A trap worth recording: `--language-model-only`, `--async-scheduling`, +`--enforce-eager` and `--mamba-ssm-cache-dtype` all appear in this repo **only in +`tools/bench/` scripts that drive the vLLM oracle**. A grep for the flag name reads +as coverage and is the opposite of it. + +### Coverage against the model matrix + +| Matrix state | Recipes | +|---|---:| +| ✅ gated / correctness-complete | 23 | +| 🚧 in progress | 5 | +| 📋 spiked | 6 | +| 🚫 blocked | 13 | +| ⬜ inventoried (row exists, unstarted) | 79 | +| **no row anywhere** | **11** → [#609](https://github.com/mudler/vllm.cpp/issues/609), [#610](https://github.com/mudler/vllm.cpp/issues/610) | +| architecture unresolved (gated / diffusion repo) | 20 | + +The 79 `⬜` are scoped-but-unstarted, not missing — model-inventory coverage is +genuinely broad. The 11 unrowed split cleanly: 2 are pin-lag (present in vLLM +`main`, [#609](https://github.com/mudler/vllm.cpp/issues/609)) and 7 live in +`vllm-omni` ([#610](https://github.com/mudler/vllm.cpp/issues/610)); 2 of that 7 +are in neither and need placing before scoping. + +### GB10 recipes are upstream-authored parity workloads + +`taxonomy.yaml` defines a restricted `dgx_spark_gb10` profile, and **8 recipes +declare it** in `meta.hardware` — vLLM has published GB10-validated configurations +for our exact gate box: **DeepSeek-V4-Flash, Qwen3.6-27B, Qwen3.6-35B-A3B, +Gemma-4-26B-A4B, MiniMax-H3, Muse-Glimmer-30B, Nemotron-3-Super-120B-A12B, +DiffusionGemma-26B-A4B**. Six are already active rows. These are ready-made, +upstream-authored workloads for the every-axis gate and should be preferred over +hand-rolled ones wherever they cover the same model — the recipe fixes the honest +denominator for us instead of us choosing it. + ## Decision rules carried forward - Every perf claim: same-box A/B vs the reference, token-exact gated, fresh From 84beead0eebacc02baa703aa5d3fcc7c099bf8b9 Mon Sep 17 00:00:00 2001 From: Ettore Di Giacinto Date: Thu, 13 Aug 2026 10:37:57 +0000 Subject: [PATCH 2/7] record(intake): place #606 on SERVE-RECIPE-ARGS now that the row exists FOLLOWING_AGENTS_PROTOCOL The em dash was honest when written -- no row owned serve CLI recipe compatibility. The spec PR creates one, so the keyed record is updated in place rather than left understating where the work lives. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code] --- .agents/roadmap_v1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.agents/roadmap_v1.md b/.agents/roadmap_v1.md index 0051b071d..702d4aa16 100644 --- a/.agents/roadmap_v1.md +++ b/.agents/roadmap_v1.md @@ -170,7 +170,7 @@ issue is not yet placed. Keyed record: update in place, never append. | [#469](https://github.com/mudler/vllm.cpp/issues/469) | — | `test_ops_glue.cpp:190`'s `CHECK_THROWS` is satisfied by the CPU kernel's second guard, not the dispatch guard it names — mutation M8 survives. Behavior is correct; test strength only | bug | | [#558](https://github.com/mudler/vllm.cpp/issues/558) | — | `tests/parity/hf_snapshot.h` has no guard against declaration-order breaks: the C++ build catches them, but the records-only lane that broke it never builds C++, and all 14 TUs that include the header are checkpoint-gated so `ctest` reports the break as `***Not Run`. `fafa16f0f` (#546, #551) fixed the ordering and carried no guard | bug | | [#605](https://github.com/mudler/vllm.cpp/issues/605) | `SAMPLE-REASONING` | `--reasoning-parser` resolves 10 of upstream's 28 names, so 61 of 76 official-recipe uses abort at startup — including `qwen3` (18 uses), which the published Qwen3.5/3.6 recipes pass to models we already gate token-exact. Reorders the spec's waves: W3 covers 43/76 recipe uses, W2 covers 18 and four of its names have zero | feature | -| [#606](https://github.com/mudler/vllm.cpp/issues/606) | — | `vllm-serve` aborts on `--enable-auto-tool-choice` (89/157 recipes) and `--trust-remote-code` (82/157), both of which are no-ops for us, so a copy-pasted official recipe command never reaches model load. Needs an accepted-and-inert seam with a per-flag reason; no row owns serve CLI recipe compatibility | feature | +| [#606](https://github.com/mudler/vllm.cpp/issues/606) | `SERVE-RECIPE-ARGS` | `vllm-serve` aborts on `--enable-auto-tool-choice` (89/157 recipes) and `--trust-remote-code` (82/157), both of which are no-ops for us, so a copy-pasted official recipe command never reaches model load. Row and spec landed 2026-08-13 (`SPIKE`, [serve-recipe-args.md](specs/serve-recipe-args.md)); the seam is enumerated, so anything unlisted still aborts | feature | | [#607](https://github.com/mudler/vllm.cpp/issues/607) | — | No `--language-model-only`: 43 recipes skip the vision encoder to hand its VRAM to the KV cache and we load the tower unconditionally. The flag appears in this repo only in `tools/bench/run_serve_low.py`, which passes it to the ORACLE — a grep reads as coverage and is not | feature | | [#608](https://github.com/mudler/vllm.cpp/issues/608) | `TOOLS-PARSER-BREADTH` | Six `--tool-call-parser` names missing (`openai`, `inkling`, `minimax_m3`, `nemotron_json`, `kimi_k3`, `ling3`), closing the last 8 of 90 official-recipe uses; four are portable at the pin, two are post-pin | feature | | [#609](https://github.com/mudler/vllm.cpp/issues/609) | — | Model matrix is short two recipe architectures that exist in vLLM `main` but not at our pin: `Qwen3_5MoeForCausalLM` (Qwen3.8-2.4T-A95B — a new registry entry for the Qwen3.5-MoE family we already ship gated) and `BailingMoeV3ForCausalLM` (Ling-3.0-flash, successor to the rowed `BailingMoeV2_5ForCausalLM`) | records | From a1d56f9d5c6be30e71b952ad268439b0cdd71724 Mon Sep 17 00:00:00 2001 From: Ettore Di Giacinto Date: Thu, 13 Aug 2026 10:52:27 +0000 Subject: [PATCH 3/7] Revert "record(intake): place #606 on SERVE-RECIPE-ARGS now that the row exists" FOLLOWING_AGENTS_PROTOCOL This reverts 84beead0e. The row exists on row/serve-recipe-args, not here, so on THIS branch the placement was a record pointing at nothing -- check-agent-record caught it exactly right, twice over: "dangling link specs/serve-recipe-args.md" and "references unknown stable row SERVE-RECIPE-ARGS". The em dash goes back, and it is not a placeholder for laziness: the table documents that convention precisely because a row id that does not resolve is worse than an honest blank. #606 gets placed once its row lands on main, in a change that can actually see it. Grouping the placement with the intake was the mistake -- two branches, one keyed record, and the ordering between them is not something either branch can assume. python3 scripts/check-agent-record.py: 0 errors. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code] --- .agents/roadmap_v1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.agents/roadmap_v1.md b/.agents/roadmap_v1.md index 702d4aa16..0051b071d 100644 --- a/.agents/roadmap_v1.md +++ b/.agents/roadmap_v1.md @@ -170,7 +170,7 @@ issue is not yet placed. Keyed record: update in place, never append. | [#469](https://github.com/mudler/vllm.cpp/issues/469) | — | `test_ops_glue.cpp:190`'s `CHECK_THROWS` is satisfied by the CPU kernel's second guard, not the dispatch guard it names — mutation M8 survives. Behavior is correct; test strength only | bug | | [#558](https://github.com/mudler/vllm.cpp/issues/558) | — | `tests/parity/hf_snapshot.h` has no guard against declaration-order breaks: the C++ build catches them, but the records-only lane that broke it never builds C++, and all 14 TUs that include the header are checkpoint-gated so `ctest` reports the break as `***Not Run`. `fafa16f0f` (#546, #551) fixed the ordering and carried no guard | bug | | [#605](https://github.com/mudler/vllm.cpp/issues/605) | `SAMPLE-REASONING` | `--reasoning-parser` resolves 10 of upstream's 28 names, so 61 of 76 official-recipe uses abort at startup — including `qwen3` (18 uses), which the published Qwen3.5/3.6 recipes pass to models we already gate token-exact. Reorders the spec's waves: W3 covers 43/76 recipe uses, W2 covers 18 and four of its names have zero | feature | -| [#606](https://github.com/mudler/vllm.cpp/issues/606) | `SERVE-RECIPE-ARGS` | `vllm-serve` aborts on `--enable-auto-tool-choice` (89/157 recipes) and `--trust-remote-code` (82/157), both of which are no-ops for us, so a copy-pasted official recipe command never reaches model load. Row and spec landed 2026-08-13 (`SPIKE`, [serve-recipe-args.md](specs/serve-recipe-args.md)); the seam is enumerated, so anything unlisted still aborts | feature | +| [#606](https://github.com/mudler/vllm.cpp/issues/606) | — | `vllm-serve` aborts on `--enable-auto-tool-choice` (89/157 recipes) and `--trust-remote-code` (82/157), both of which are no-ops for us, so a copy-pasted official recipe command never reaches model load. Needs an accepted-and-inert seam with a per-flag reason; no row owns serve CLI recipe compatibility | feature | | [#607](https://github.com/mudler/vllm.cpp/issues/607) | — | No `--language-model-only`: 43 recipes skip the vision encoder to hand its VRAM to the KV cache and we load the tower unconditionally. The flag appears in this repo only in `tools/bench/run_serve_low.py`, which passes it to the ORACLE — a grep reads as coverage and is not | feature | | [#608](https://github.com/mudler/vllm.cpp/issues/608) | `TOOLS-PARSER-BREADTH` | Six `--tool-call-parser` names missing (`openai`, `inkling`, `minimax_m3`, `nemotron_json`, `kimi_k3`, `ling3`), closing the last 8 of 90 official-recipe uses; four are portable at the pin, two are post-pin | feature | | [#609](https://github.com/mudler/vllm.cpp/issues/609) | — | Model matrix is short two recipe architectures that exist in vLLM `main` but not at our pin: `Qwen3_5MoeForCausalLM` (Qwen3.8-2.4T-A95B — a new registry entry for the Qwen3.5-MoE family we already ship gated) and `BailingMoeV3ForCausalLM` (Ling-3.0-flash, successor to the rowed `BailingMoeV2_5ForCausalLM`) | records | From 3ec9bfbc0533a05846773e65a87393de6222fc19 Mon Sep 17 00:00:00 2001 From: Ettore Di Giacinto Date: Thu, 13 Aug 2026 11:06:03 +0000 Subject: [PATCH 4/7] record(intake): the unit is an architecture, not a recipe -- 8, not 9 (#609, #610) FOLLOWING_AGENTS_PROTOCOL The sweep counted 11 unrowed RECIPES and then reported them as if they were rows. They are not: 11 recipes resolve to 8 distinct architectures, because MossTTSDelayModel alone is reached by four of them (MOSS-TTS, MOSS-TTSD-v1.0, MOSS-SoundEffect, MOSS-VoiceGenerator). #610's headline said seven while its own table enumerated six. A row is an architecture, so 8 is the number that matters, and the issue title is corrected to match its table. Caught by the implementer re-deriving the audit independently rather than taking the brief's count on faith -- which is what the brief asked for and the reason the wrong number did not reach the matrix. The rollup moved 314->322 / 362->370. Also records what this sweep CANNOT see. 20 of the 157 recipe configs were unreadable (gated or 404: Voxtral-4B-TTS-2603, GLM-TTS, IndexTTS-2.5, stable-audio-open-1.0, several meta-llama), so those architectures are unverified and 8 is a FLOOR. And any vllm-omni architecture no recipe references is invisible to a recipe-driven sweep by construction. Stating the blind spot beats letting the number read as a total. python3 scripts/check-agent-record.py: 0 errors. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code] --- .agents/roadmap_v1.md | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/.agents/roadmap_v1.md b/.agents/roadmap_v1.md index 0051b071d..110ee17d2 100644 --- a/.agents/roadmap_v1.md +++ b/.agents/roadmap_v1.md @@ -174,7 +174,7 @@ issue is not yet placed. Keyed record: update in place, never append. | [#607](https://github.com/mudler/vllm.cpp/issues/607) | — | No `--language-model-only`: 43 recipes skip the vision encoder to hand its VRAM to the KV cache and we load the tower unconditionally. The flag appears in this repo only in `tools/bench/run_serve_low.py`, which passes it to the ORACLE — a grep reads as coverage and is not | feature | | [#608](https://github.com/mudler/vllm.cpp/issues/608) | `TOOLS-PARSER-BREADTH` | Six `--tool-call-parser` names missing (`openai`, `inkling`, `minimax_m3`, `nemotron_json`, `kimi_k3`, `ling3`), closing the last 8 of 90 official-recipe uses; four are portable at the pin, two are post-pin | feature | | [#609](https://github.com/mudler/vllm.cpp/issues/609) | — | Model matrix is short two recipe architectures that exist in vLLM `main` but not at our pin: `Qwen3_5MoeForCausalLM` (Qwen3.8-2.4T-A95B — a new registry entry for the Qwen3.5-MoE family we already ship gated) and `BailingMoeV3ForCausalLM` (Ling-3.0-flash, successor to the rowed `BailingMoeV2_5ForCausalLM`) | records | -| [#610](https://github.com/mudler/vllm.cpp/issues/610) | — | Seven `vllm-omni` recipe architectures have no model-matrix row, so the TTS / audio-generation modality is entirely unplaced: four confirmed in `vllm-omni`'s supported-models doc, two located in neither core `main` nor omni. Precedent for rowing an omni-repo architecture already exists (`MiniMaxH3DiTModel`) | records | +| [#610](https://github.com/mudler/vllm.cpp/issues/610) | — | Six `vllm-omni` recipe architectures (reached by ten recipes -- `MossTTSDelayModel` serves four of them) have no model-matrix row, so the TTS / audio-generation modality is entirely unplaced: four confirmed in `vllm-omni`'s supported-models doc, two located in neither core `main` nor omni. Precedent for rowing an omni-repo architecture already exists (`MiniMaxH3DiTModel`) | records | ## Top-level portfolio @@ -607,14 +607,26 @@ as coverage and is the opposite of it. | 📋 spiked | 6 | | 🚫 blocked | 13 | | ⬜ inventoried (row exists, unstarted) | 79 | -| **no row anywhere** | **11** → [#609](https://github.com/mudler/vllm.cpp/issues/609), [#610](https://github.com/mudler/vllm.cpp/issues/610) | +| **no row anywhere** | **11** recipes = **8** architectures → [#609](https://github.com/mudler/vllm.cpp/issues/609), [#610](https://github.com/mudler/vllm.cpp/issues/610) | | architecture unresolved (gated / diffusion repo) | 20 | The 79 `⬜` are scoped-but-unstarted, not missing — model-inventory coverage is -genuinely broad. The 11 unrowed split cleanly: 2 are pin-lag (present in vLLM -`main`, [#609](https://github.com/mudler/vllm.cpp/issues/609)) and 7 live in -`vllm-omni` ([#610](https://github.com/mudler/vllm.cpp/issues/610)); 2 of that 7 -are in neither and need placing before scoping. +genuinely broad. The 11 unrowed recipes resolve to **8 distinct architectures** — +`MossTTSDelayModel` alone is reached by four of them — and split cleanly: 2 are +pin-lag (present in vLLM `main`, +[#609](https://github.com/mudler/vllm.cpp/issues/609)) and 6 live in `vllm-omni` +([#610](https://github.com/mudler/vllm.cpp/issues/610)), of which 2 are in neither +and need placing before scoping. Counting recipes where the unit is an +architecture is what put "seven" in the first draft of #610; the row is the +architecture, so 8 is the number that matters. + +**Caveat on the denominator.** 20 of the 157 recipe configs were unreadable +(gated or 404 — `Voxtral-4B-TTS-2603`, `GLM-TTS`, `IndexTTS-2.5`, +`stable-audio-open-1.0`, several `meta-llama`), so their architectures are +UNVERIFIED and the 8 is a floor, not a total. Several `vllm-omni` TTS +architectures visible in that repo's supported-models doc are also unreached by +any recipe and therefore invisible to this sweep. Closing that hole is its own +audit, not an inference from this one. ### GB10 recipes are upstream-authored parity workloads From ccf289e42c1b2b2770af82c8622cfeeff79882e7 Mon Sep 17 00:00:00 2001 From: Ettore Di Giacinto Date: Thu, 13 Aug 2026 11:07:01 +0000 Subject: [PATCH 5/7] record(intake): drop #609/#610 here -- the rows PR places them in place (#620) FOLLOWING_AGENTS_PROTOCOL This branch appended #609 and #610 to the intake table with em-dash rows, because when it was written neither issue had a row to point at. #620 has since added the eight matrix rows AND placed both issues in place, keyed to MODEL-TEXT-qwen3-5-qwen3-5-moe-for-causal-lm and MODEL-MM-moss-tts-moss-tts-delay-talker-for-generation. Two branches, one keyed record, entries at different line positions: git merges both without a conflict and the table ends up defining #609 and #610 twice. That is the move-plus-add duplicate shape -- it does not announce itself, because a clean merge is exactly what it produces. The append is the weaker of the two (em dash vs a real row), so it goes; #620 owns those keys. This branch keeps #605-#608, which #620 does not touch. Not a merge-order fix: removing the duplicate here is correct whichever PR lands first. python3 scripts/check-agent-record.py: 0 errors. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code] --- .agents/roadmap_v1.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/.agents/roadmap_v1.md b/.agents/roadmap_v1.md index 110ee17d2..06dd2b4b3 100644 --- a/.agents/roadmap_v1.md +++ b/.agents/roadmap_v1.md @@ -173,8 +173,6 @@ issue is not yet placed. Keyed record: update in place, never append. | [#606](https://github.com/mudler/vllm.cpp/issues/606) | — | `vllm-serve` aborts on `--enable-auto-tool-choice` (89/157 recipes) and `--trust-remote-code` (82/157), both of which are no-ops for us, so a copy-pasted official recipe command never reaches model load. Needs an accepted-and-inert seam with a per-flag reason; no row owns serve CLI recipe compatibility | feature | | [#607](https://github.com/mudler/vllm.cpp/issues/607) | — | No `--language-model-only`: 43 recipes skip the vision encoder to hand its VRAM to the KV cache and we load the tower unconditionally. The flag appears in this repo only in `tools/bench/run_serve_low.py`, which passes it to the ORACLE — a grep reads as coverage and is not | feature | | [#608](https://github.com/mudler/vllm.cpp/issues/608) | `TOOLS-PARSER-BREADTH` | Six `--tool-call-parser` names missing (`openai`, `inkling`, `minimax_m3`, `nemotron_json`, `kimi_k3`, `ling3`), closing the last 8 of 90 official-recipe uses; four are portable at the pin, two are post-pin | feature | -| [#609](https://github.com/mudler/vllm.cpp/issues/609) | — | Model matrix is short two recipe architectures that exist in vLLM `main` but not at our pin: `Qwen3_5MoeForCausalLM` (Qwen3.8-2.4T-A95B — a new registry entry for the Qwen3.5-MoE family we already ship gated) and `BailingMoeV3ForCausalLM` (Ling-3.0-flash, successor to the rowed `BailingMoeV2_5ForCausalLM`) | records | -| [#610](https://github.com/mudler/vllm.cpp/issues/610) | — | Six `vllm-omni` recipe architectures (reached by ten recipes -- `MossTTSDelayModel` serves four of them) have no model-matrix row, so the TTS / audio-generation modality is entirely unplaced: four confirmed in `vllm-omni`'s supported-models doc, two located in neither core `main` nor omni. Precedent for rowing an omni-repo architecture already exists (`MiniMaxH3DiTModel`) | records | ## Top-level portfolio From dcbe76932a44bcafbb6e27d05e213108af0d0307 Mon Sep 17 00:00:00 2001 From: Ettore Di Giacinto Date: Thu, 13 Aug 2026 11:12:15 +0000 Subject: [PATCH 6/7] record(intake): 7 rows owed, not 8 -- #601 already owns Qwen3_5MoeForCausalLM FOLLOWING_AGENTS_PROTOCOL The sweep reported 8 unrowed architectures. One of them, Qwen3_5MoeForCausalLM, was already owned by #490 and its open PR #601 -- which does not merely row it but REGISTERS it alongside Qwen3_5ForCausalLM, resolves the backbone prefix, refuses unsupported MoE layouts, and carries CPU 404/404 plus SACRED GPU 315/315, 235/235 and 138/138, reviewed twice over five reproduced mutations. #601 also adds a row this sweep never saw, MODEL-TEXT-qwen3-5-qwen3-5-for-causal-lm. So 7 are owed: BailingMoeV3ForCausalLM plus the six vllm-omni architectures. AGENTS.md says to re-verify a gap against issues AND PRs before claiming. I grepped issue titles with terms that did not match #490's wording and did not check open PRs at all. The verification that should have run first was cheap: diff every open PR against main for each architecture string. Run afterwards, it shows Qwen3_5MoeForCausalLM in two branches and the other seven in one -- which is exactly the answer needed before dispatching anyone. This matters beyond one wasted row. Two branches ADDING the same keyed row merge without a conflict and define it twice; nothing announces it, because a clean merge is the symptom. Same shape as the #609/#610 duplication removed two commits ago, from the same root cause: assuming a keyed record has one writer. Both counting lessons are recorded in the sweep section rather than just fixed, since the next sweep will face both. python3 scripts/check-agent-record.py: 0 errors. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code] --- .agents/roadmap_v1.md | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/.agents/roadmap_v1.md b/.agents/roadmap_v1.md index 06dd2b4b3..99ae1f2e7 100644 --- a/.agents/roadmap_v1.md +++ b/.agents/roadmap_v1.md @@ -610,13 +610,24 @@ as coverage and is the opposite of it. The 79 `⬜` are scoped-but-unstarted, not missing — model-inventory coverage is genuinely broad. The 11 unrowed recipes resolve to **8 distinct architectures** — -`MossTTSDelayModel` alone is reached by four of them — and split cleanly: 2 are -pin-lag (present in vLLM `main`, -[#609](https://github.com/mudler/vllm.cpp/issues/609)) and 6 live in `vllm-omni` -([#610](https://github.com/mudler/vllm.cpp/issues/610)), of which 2 are in neither -and need placing before scoping. Counting recipes where the unit is an -architecture is what put "seven" in the first draft of #610; the row is the -architecture, so 8 is the number that matters. +`MossTTSDelayModel` alone is reached by four of them — of which **7 are owed here** +and 1 is already owned elsewhere: + +- **1 pin-lag**, `BailingMoeV3ForCausalLM` + ([#609](https://github.com/mudler/vllm.cpp/issues/609)). +- **6 in `vllm-omni`** ([#610](https://github.com/mudler/vllm.cpp/issues/610)), of + which 2 are in neither core `main` nor the omni doc and need placing before + scoping. +- **1 already owned:** `Qwen3_5MoeForCausalLM` belongs to + [#490](https://github.com/mudler/vllm.cpp/issues/490) / PR + [#601](https://github.com/mudler/vllm.cpp/pull/601), which registers it rather + than merely rowing it. + +Two counting lessons, both paid for. The row is the ARCHITECTURE, not the recipe — +counting recipes is what put "seven" in the first draft of #610. And a gap is only +a gap after checking open PRs, not just issues: #601 was open before this sweep was +written, and two branches adding the same keyed row merge cleanly and define it +twice. **Caveat on the denominator.** 20 of the 157 recipe configs were unreadable (gated or 404 — `Voxtral-4B-TTS-2603`, `GLM-TTS`, `IndexTTS-2.5`, From 3ab773f2147c0c69c1fb708655344c784ae6cddf Mon Sep 17 00:00:00 2001 From: Ettore Di Giacinto Date: Thu, 13 Aug 2026 11:41:25 +0000 Subject: [PATCH 7/7] record(NOW): drop the arch count -- it lives in the matrix, not here (#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] --- .agents/NOW.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/.agents/NOW.md b/.agents/NOW.md index 4c81af9f7..4aa86ac55 100644 --- a/.agents/NOW.md +++ b/.agents/NOW.md @@ -52,8 +52,9 @@ ENFORCE `agent-start.py` → claim → preflight. Review FAIL loops to a fresh implementer until PASS. Queue: 10 rows; backfill 79, 30 anchored. **Upstream inventory** ([spec](specs/upstream-derived-inventory-2026-08-05.md)): SM060/061/070 below vLLM's floor = OUT-OF-SCOPE; COMP-*/DISTRIBUTED-* are REAL -unported work; **all 362 archs have rows**; llama.cpp's 11 extra devices IN -SCOPE (`ROAD-V1-D6`). +unported work; **every arch in the pinned registry has a row** (the count lives in +[model-matrix.md](model-matrix.md), not here — #622); llama.cpp's 11 extra +devices IN SCOPE (`ROAD-V1-D6`). ## Protocol invariants that bite most often