docs/FEATURES.md drift: arch counts say 30 (registry has 35), multimodal-over-HTTP marked ☐ though W1–W3 landed and are wired

[localai-bot]

docs/FEATURES.md drifted from the tree in the places no checker covers. scripts/check-supported-models.py gates the arch table between the supported-arch-table markers, and it is green — every drift below is in prose, in a row the checker does not read, or in a different document. Verified at 616ba9fe.

1. Architecture counts say 30, the registry has 35

check-supported-models.py prints "exactly the 35 architectures registered via REGISTER_VLLM_MODEL", and grep -c REGISTER_VLLM_MODEL over src/ agrees (36 hits, one being the macro definition). The prose disagrees in four places:

• docs/FEATURES.md:28 — "30 registered, 25+ gated"
• docs/FEATURES.md:81 — "Today that is 30 registered architectures"
• docs/FEATURES.md:155 — "25 of the 30 registered text-generation architectures"
• README.md:296 — "all 30 registered architectures"

The gated count needs a real recount, not arithmetic. A first pass off the table: 35 registered − 4 non-text-generation (3× Parakeet + LlamaModel) = 31 text-generation, of which KimiK3ForConditionalGeneration (scaffold), CohereForCausalLM (scaffold), Gemma4UnifiedForConditionalGeneration (no separate oracle gate) and Olmo3ForCausalLM (oracle-blocked) are ungated ⇒ ~27/31. DeepseekV4ForCausalLM and LagunaForCausalLM gate through their CLIs while the registered engine forward is a stub/VT_CHECK, so whoever takes this should decide how those count and say so in the row.

2. Multimodal over HTTP is marked ☐ / "architecturally blocked", but W1–W3 landed and are wired

docs/FEATURES.md:170 marks "Multimodal over the OpenAI server" ☐, :174 calls serving it "the named open gap", and :285 says "Architecturally blocked — Vision tower lives outside the registered engine forward."

That is not what the tree does. ROAD-V1-MM W1–W3 landed (0a8dd58b → 2581a7d4 → 308c312a) and the production server attaches the seam at src/vllm/entrypoints/openai/server_main.cpp:826:

chat.set_multimodal_chat_fn(oai::MakeQwen3VLImageChatFn(
    *mm_image_proc, tokenizer, chat_prompt_fn, std::move(codec)));

docs/STATUS.md:131 already carries the honest state; FEATURES does not project it. The blocker is no longer architectural — it is two named residuals, both stated in the comment at server_main.cpp:780:

1. the model runner has no mm-forward path consuming Request.mm_features;
2. no container-format image codec is vendored, so encoded PNG/JPEG are refused.

The row should read ◐ with those two residuals named, and :285 should stop saying "architecturally blocked". The separate C-ABI row (:258, multimodal input embedder-unreachable) is accurate and should stay.

3. Smaller reconciliations

• ABI version. include/vllm.h:145 is VLLM_ABI_VERSION 17. FEATURES quotes v15 (:254) and v16 (:290). v17 (vllm_server_main, c1716fd0) is absent from the C-ABI capability table.
• Vulkan op count. :224 reads "25 native kernels plus 8 GDN", which parses as 33. src/vt/vulkan/ references 25 unique OpIds in total, and the 8 GDN-family ops are inside that 25 (include/vt/ops.h declares 112 OpIds). Either the sentence double-counts or "25 native kernels" means the 29 shader files — needs one honest number.
• ROCm row. :209 cites only ROCm (AMD GPU) backend #41; the ROCm 6.x build fix (ce134e1d, rocm_matmul_hipblaslt.hip:384:13: error: no matching function for call to 'hipblasGemmEx' #201/ROCm: -O0 RmsNorm triggers a CLR HostcallListener teardown deadlock #132) is not reflected.
• Orphaned table row. docs/FEATURES.md:313 is a | Gemma4 MoE ROCm fused helpers | … | row stranded after the closing prose, belonging to no table. It renders as literal text.

Scope

docs/FEATURES.md + the one README.md:296 count. No src/, include/ or tests/ change; no capability moves, so no BENCHMARKS entry is owed. Per the public-documents rule this is a projection repair, and docs/STATUS.md is already correct.

Why this matters beyond tidiness

Item 2 understates a landed capability and item 1 undercounts the registry by five architectures — both in the direction of making the project look less complete than it is, on the page a reader uses to judge it.

[localai-bot]

Correction to item 3, first bullet, before anyone acts on it: I misread the two ABI mentions. FEATURES.md:254 ("ABI v15") and :290 ("ABI v16") are "this capability arrived at version N" statements, not claims about the current ABI version, and both are accurate. They need no change.

What is genuinely missing there is only the second half of that bullet: ABI v17 (vllm_server_main, c1716fd0) had no row in the C-ABI capability table, even though include/vllm.h:822 declares it and :134 documents it as "RUN THE OPENAI SERVER from the public surface".

Worth noting why the gap was invisible: scripts/check-surface-coverage.py validates rows to the ABI (every row must name a symbol that exists, or be allowlisted as embedder-unreachable). It does not validate the ABI to rows, so a real entry point with no row passes silently. That is a reasonable checker design, not a bug, but it means the table is only as complete as whoever last edited it. Adding the row moves the checker from 12 reachable to 13.

[localai-bot]

Landed on main as 16d5c2ce (merge of fix/features-doc-drift, single commit 5dc4e223).

Fixed

• arch counts 30 -> 35 registered / 27 of 31 text-gen gated (At-a-glance + Model coverage prose)
• multimodal-over-HTTP: box -> partial, "architecturally blocked" removed, replaced with the two real residuals (no mm-forward consuming Request.mm_features; no vendored image codec, raw RGB only)
• Vulkan "25 native kernels plus 8 GDN" -> 25 of 112 OpIds, 8 of them GDN. It was double-counting its own subset: the provider makes exactly 25 RegisterOp(.., DeviceType::kVULKAN, ..) calls and the 8 GDN ops are inside that 25
• added the missing ABI v17 vllm_server_main capability row (check-surface-coverage 12 -> 13 reachable)
• the orphaned Gemma4 MoE ROCm fused helpers row, stranded after the closing prose and rendering as literal pipe text, moved into Not supported yet
• backends ROCm row now cites the ROCm 6.x fix (rocm_matmul_hipblaslt.hip:384:13: error: no matching function for call to 'hipblasGemmEx' #201/ROCm: -O0 RmsNorm triggers a CLR HostcallListener teardown deadlock #132)

NOT fixed, still open, needs a decision. The README counts are untouched and now wrong in four places: README.md:296 "all 30 registered architectures", plus "25+ architectures" in the tagline (:11), the badge (:17) and the feature list (:78).

check-doc-checkpoint.py --staged rejects them in a change of this shape:

changed README.md without touching a landing source (.agents/mission.md, CMakeLists.txt, benchmarks/demo/*.json, examples/cli/main.cpp, examples/server/main.cpp). The README is the landing page; routine checkpoints belong in the purpose-specific docs. Co-edited public projections never justify README churn.

That rule is deliberate and directly tested, so the two ways through are a change that has its own landing-source trigger, or a waiver with an owner and expiry. Editing a landing source purely to unlock the README edit would be gaming the gate, so it was not done. Leaving this issue OPEN for that reason.

Note on the ROCm 6.x citation: it went into the backends table only. The Not supported yet ROCm cell is byte-for-byte unchanged because adding it there pushed the cell past the 220-char budget in check-public-doc-tables.py, and the fact does not need two homes.

[localai-bot]

Worked this top-down against current main 4ba05140. Five of the six items are already fixed; I verified each rather than taking the issue's word:

item	state
arch counts say 30	fixed — FEATURES prose reads 35 at :28, :85, :161; check-supported-models.py green at 35
ABI quotes v15/v16, tree is v17	fixed — vllm_server_main (ABI v17) is in the C-ABI table
Vulkan "25 native plus 8 GDN" double-count	fixed — now "25 natively registered ops of 112 (8 are GDN)", i.e. the 8 are INSIDE the 25, and grep -o 'OpId::k*' src/vt/vulkan/ | sort -u is exactly 25
ROCm row cites only #41	fixed — :219 now cites the ROCm 6.x CLR hostcall fix, #201/#132
orphaned table row at :313	fixed — the Gemma4 MoE ROCm helpers row sits inside a real table
README.md:296 says 30	STILL WRONG, and blocked (below)

The last one is blocked by policy, not by difficulty. README.md:296 still reads "all 30 registered architectures". I made the one-word fix and check-doc-checkpoint correctly refused it:

ERROR: changed README.md without touching a landing source (.agents/mission.md,
CMakeLists.txt, benchmarks/demo/*.json, examples/cli/main.cpp,
examples/server/main.cpp). The README is the landing page; routine checkpoints
belong in the purpose-specific docs. Co-edited public projections never justify
README churn.

That rule is right in general and I am not going to weaken it, nor spend a waiver on a two-character correction — a waiver is visible debt, and this does not warrant it. So I reverted.

Disposition: keep #242 open for this single line. It should ride along with the next change that legitimately touches a landing source (CMakeLists.txt, examples/*/main.cpp, .agents/mission.md, or a benchmarks/demo/*.json). Anyone making such a change: fix README.md:296 30 -> 35 in the same commit and close this.

Worth noting the number is user-visible on the landing page and understates the project by five architectures, so it is worth carrying rather than dropping.