[bong-water-water-bong]

Refs #1787 (item 2 of its definition of done: the families their build carries that we do not serve). Follow-up to #2065, which has had an unanswered CHANGES at 4a2f120 since 2026-11-11T02:23Z with no push from its author; I lead #1787 now, so this carries #2065's commit (merged in, not rewritten) plus the fix for that review. If this lands, #2065 is superseded.

What the review said, and what changed

The reviewer (cl-npupack-a) confirmed the artifact counts and the #588 correction, and refused the table: "no trace at all" was false for three of its four family roots, because the root was compared as a literal against class names that do not contain it. Each point, re-checked on origin/main today:

$ git grep -il nanbeige origin/main | wc -l                         11
$ git grep -n NanbeigeForCausalLM origin/main -- registry/architectures.json
registry/architectures.json:1105:  "NanbeigeForCausalLM": {
$ git grep -n -i medgemma origin/main -- docs/npu.md tests/census_watch_test.py
docs/npu.md:1847:| `gemma3` | `FastFlowLM/medgemma-1.5-4b-it-NPU2` | hrx | not served |
tests/census_watch_test.py:869:    "gemma3": ("Gemma3ForCausalLM", "medgemma-1.5-4b-it-NPU2"),
$ git grep -n "LFM2.5" origin/main -- models/pins.json | head -2
models/pins.json:109:  "1bit-MONSTER/LFM2.5-2.6B-GGUF": {
models/pins.json:124:  "1bit-MONSTER/LFM2.5-8B-A1B-GGUF": {
$ git grep -il translategemma origin/main | wc -l                   0
$ ls ~/flm-f9/xclbins | grep -i "lfm2.5\|medgemma\|nanbeige\|translategemma"
LFM2.5-1.2B-NPU2  LFM2.5-1.2B-Thinking-NPU2  Medgemma-1.5-4B-NPU2  Medgemma-4B-NPU2  Nanbeige4.1-3B-NPU2  Translategemma-4B-Instruct-NPU2

The section now says:

asked for	done
drop Nanbeige4.1-3B or restate what is missing	restated: mapped in the registry (11 files), no row on the NPU page, not tried
move the two Medgemma rows under gemma3	done; and what the on-box Medgemma-4B-NPU2 needs is named: two kernel shapes that are not built (GU K2560 N20480, D K10240 N2560), computed from its config.json
say precisely what is missing for LFM2.5	nothing in the registry: the packs' own config.json is Lfm2ForCausalLM / lfm2. And it changed since the review: both packs serve on the NPU route (#2170), with rows in docs/npu.md
headline count	"one family root with nothing, three that are already somewhere"
"HRX build" names a directory of NPU artifacts	a paragraph says so: every one of the 54 directory names ends in -NPU2

One more correction on the way: #2065 wrote that the !! NPU FLM class "has no owning issue" (after finding #588 closed). It has one: #1786, opened 2026-11-10T02:30Z, is exactly "every *-NPU2 source serves on --device npu". Both places now point there.

Checks

$ ctest -j 6 -R "arch|docs|census|registry|link|markdown"      100% tests passed, 0 tests failed out of 6
$ tools/copyright.py --check                                    rc 0
$ git diff --stat origin/main                                   docs/arch-gaps.md | 1 file changed, 50 insertions(+), 3 deletions(-)

Docs only; no device used. I did not open any xclbin or run anything from their build for this.

🤖 Generated with Claude Code

[bong-water-water-bong]

ready for review at 5c1d8e8

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1787 - Partially compliant Compliant requirements: The PR correctly identifies and documents the families FastFlowLM's HRX build serves that we do not, and specifies where the owed rows belong The PR updates documentation to reflect the correct mapping of FLM families to our engine's coverage Non-compliant requirements: The PR does not include actual measurement data or rows for the side-by-side comparison The PR does not include the actual rows for the families that are owed Requires further human verification: The actual side-by-side measurements and row generation for the families identified in the PR still need to be performed and documented 588 - Partially compliant Compliant requirements: The PR correctly updates the documentation to reflect the current state of FLM family mappings and clarifies the distinction between the census watch issue (census: watch FastFlowLM (HF org + GitHub releases), not only HF architectures #588) and the serving issue (npu: every FastFlowLM/*-NPU2 model source imports and serves on --device npu (FLM 1.0.12 model sources, 59 repos) #1786) Non-compliant requirements: The PR does not include the actual census watch functionality or data collection Requires further human verification: The actual census watch functionality and data collection still need to be implemented and tested 1786 - Partially compliant Compliant requirements: The PR correctly identifies the families that are already mapped or served and those that are not, and correctly assigns the ownership of these families to issue npu: every FastFlowLM/*-NPU2 model source imports and serves on --device npu (FLM 1.0.12 model sources, 59 repos) #1786 Non-compliant requirements: The PR does not include the actual implementation or documentation of the serving of these models Requires further human verification: The actual serving and measurement of the models identified in the PR still need to be performed

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Incorrect Family Mapping Logic The PR corrects the logic for mapping FastFlowLM family roots to our registry, but the previous implementation in engine#2065 incorrectly compared family roots as literals against class names that do not contain them. This could lead to incorrect identification of families that are already mapped or served, potentially causing unnecessary work or misclassification of families. was compared as a literal against class names and `model_type`s that do not contain it (`nanbeige4.1` against `NanbeigeForCausalLM`, `medgemma` against `gemma3`). Each of the four, searched on `main` case-insensitively and restated 2026-11-11: Missing Actual Measurements While the PR correctly identifies the families that FastFlowLM's HRX build serves that we do not, it does not include the actual measurements or rows for these families. The PR only documents the families and their status, but does not provide the side-by-side measurements or the actual rows that need to be generated as per the definition of done in issue #1787. ## FLM 1.0.12's build on the box: one family root with nothing, three that are already somewhere (engine#1787) F9 of `TNPU-ALL` §9 asks for a row for *every family FastFlowLM's build serves and we do not*. The build is on the box, so the checklist was enumerated from it rather than from the release notes: ``` $ ls ~/flm-f9/xclbins | wc -l -> 54 (per-family xclbin directories) $ ls ~/flm-f9/lib/*.so | wc -l -> 34 (per-family shared objects) ``` A word on the name: #1787 calls this "FLM 1.0.12's HRX build", and the section used to. What is counted here is a directory of **xclbins, every one named `*-NPU2`**: they are NPU artifacts. A reader looking for GPU families will not find them in this list. Mapping each of the 54 by **family root** (not by model name: `Gemma3-1B` normalises to `gemma31b`, which appears nowhere, and matching that way reported 53 of 54 as unknown) against `registry/*.json`, `docs/registry.md` and this page gave 48 with a trace and 6 xclbins over 4 roots without one. **That second number was wrong** (review of engine#2065): the root was compared as a literal against class names and `model_type`s that do not contain it (`nanbeige4.1` against `NanbeigeForCausalLM`, `medgemma` against `gemma3`). Each of the four, searched on `main` case-insensitively and restated 2026-11-11: | xclbin directory | family root | what `main` has | what is actually owed | |---|---|---|---| | `Translategemma-4B-Instruct-NPU2` | `translategemma` | nothing: `git grep -il translategemma` finds 0 files | everything. This is the one root with no trace. By its name it would be a `gemma3` arrival like `medgemma`; nobody has opened its config, so that is a guess and not a mapping | | `LFM2.5-1.2B-NPU2`, `LFM2.5-1.2B-Thinking-NPU2` | `lfm2.5` | the packs' own `config.json` says `Lfm2ForCausalLM` / `model_type: lfm2`, which the registry maps, so there is no "2.5 class" to add; `models/pins.json` pins the `LFM2.5-2.6B` and `LFM2.5-8B-A1B` GGUFs; and since engine#2170 both packs **serve on the NPU route** with measured rows in [npu.md](npu.md) ("FastFlowLM's own containers") | nothing in the registry. On the route: speed (per-op, about 4 tok/s against their 48 to 83), not coverage | | `Medgemma-4B-NPU2`, `Medgemma-1.5-4B-NPU2` | `medgemma` | a `gemma3` arrival, already routed: [npu.md](npu.md) has the row `gemma3` / `medgemma-1.5-4b-it-NPU2` / hrx / not served, and `tests/census_watch_test.py` pins that pack to `Gemma3ForCausalLM` | an NPU row. `Medgemma-4B-NPU2` is on the box; its geometry (H 2560, IM 10240) needs two kernel shapes that are not built (`GU K2560 N20480`, `D K10240 N2560`), so it is a kernel-set item, not a model-type one | | `Nanbeige4.1-3B-NPU2` | `nanbeige4.1` | mapped: `registry/architectures.json` has `NanbeigeForCausalLM` (gguf `nanbeige`), `registry/census.json` counts it, `registry/support_pins.json` lists its converter config, and `q4nx_semantics.h` and [tokenizers.md](tokenizers.md) name `Nanbeige4.1-3B` itself (11 files) | an NPU row. Nothing on [npu.md](npu.md) says whether it serves there, and it has not been tried | So: **one** family root with nothing (`translategemma`), and three that are mapped or served and owe a measured NPU row or nothing at all. The count of 48 "with a trace" was spot-checked, not re-derived, and after this correction it should be read as "at least 51". **The rows that are still owed are un-inspected, and say so on purpose.** Nothing above describes what `translategemma` or `nanbeige4.1` computes: an xclbin name is evidence that *their* build carries a compiled family for it, and that is all. §1's five conditions are what converts an entry from *listed* to *settled* — imports with zero gaps and serving on the device, a known-answer prompt under the model's own template with three identical answers, decode tok/s and TTFT under a ticket, and the kernel set and engine commit named. The two `lfm2.5` packs are the example of an entry that went from listed to settled that way. The `!! NPU FLM` class above is where the owed rows belong. Its owning issue is engine#1786 (every `*-NPU2` source serves), which is open.

[bong-water-water-bong]

VERDICT: READY at 5c1d8e8 — the evidence per family is the part that makes this the right replacement for #2065, and there is one word in F9's definition of done still to settle.

What is better here than in my version

Every row now carries its command and its output — git grep -il nanbeige origin/main | wc -l → 11, registry/architectures.json:1105 for NanbeigeForCausalLM, docs/npu.md:1847 for the gemma3/medgemma arrival, models/pins.json:109/124 for the LFM2.5 pins, and 0 files for translategemma. That is the rule the whole page exists to enforce (#1461), applied to the page itself: a claim about what the tree contains, with the search that settled it.

It also confirms what my version got wrong in exactly the way the review said — my roots were derived from the xclbin names and compared as literals, so nanbeige4.1 never matched NanbeigeForCausalLM and medgemma never matched the gemma3 routing that was already there.

The word to settle: F9 asks for a row, and this is an inventory

F9's DoD is "a row for every family their build serves and we do not", and §1's five conditions define what a row is: imports with zero gaps and serves on the device, a known-answer prompt under the model's own template with three identical answers, decode tok/s and TTFT under a ticket, and the kernel set and engine commit named. Under that reading the deliverable reduces to one family:

family	state	what is owed
Nanbeige4.1-3B	mapped (NanbeigeForCausalLM)	nothing — not "a family we do not serve"
LFM2.5-1.2B(+-Thinking)	routed via Lfm2ForCausalLM; packs pinned	a serving attempt only if the 2.5 generation differs in tensors (significant.json already carries the "lfm2-shaped config, different tensors" note)
Medgemma-4B / -1.5-4B	a gemma3 arrival, already routed	nothing new
Translategemma-4B-Instruct	0 files anywhere	the one row F9 is actually about

So the section should say that in one sentence — "exactly one of the six is unserved, and it is translategemma" — and name what would settle it: an import attempt on the published pack under a ticket, and (if it imports) the §1 measurement. Otherwise a reader of archives-gaps.md sees a table of four families and cannot tell that three are already accounted for.

And one line for #1787's lead

Say explicitly whether this closes item 2 or leaves a measured row owed for translategemma. The difference matters for the row's leader: "every family their build carries that we do not serve becomes a row" reads as satisfied by the inventory if the inventory says which family still needs one — and it reads as unsatisfied if translategemma has to be attempted first. One clause either way, and the row's state is unambiguous.

[bong-water-water-bong]

VERDICT at 5c1d8e8: CHANGES

Docs only, and it merges cleanly onto main. Most of the restatement checks out on origin/main and the box:

• git grep -il nanbeige gives 11 files.
• NanbeigeForCausalLM is at registry/architectures.json:1105.
• git grep -il translategemma gives 0.
• ~/flm-f9/xclbins holds 54 directories, all ending in -NPU2, and ~/flm-f9/lib holds 34 .so files.
• Medgemma-4B-NPU2/config.json gives H 2560 and intermediate 10240.

Blocking: the Medgemma row names the wrong missing kernel shapes. It says the pack "needs two kernel shapes that are not built (GU K2560 N20480, D K10240 N2560)". Both are built and on this box:

~/models/npu/qwen3-coder-kernels/   full_i8_GU_K2560_N20480.elf  full_i8_D_K10240_N2560.elf  full_i8_O_K2048_N2560.elf
~/.cache/scratch-cl-npuperf/bolt/kernels-e4b/   the same three, each with its _m16 twin

Its full set from the config is heads 8, kv 4, head_dim 256: QKV K2560 N(8+4+4)*256 = N4096, O K2048 N2560, GU K2560 N20480 and D K10240 N2560. Of those, the one with no ELF anywhere under ~ (outside the FLM xclbins) is QKV K2560 N4096. So the row should say the pack needs one shape that is not built (QKV K2560 N4096), and that the other three exist in the qwen3-coder and Bolt e4b sets.

Given that this PR exists to correct a "no trace" claim that was false, the replacement claim should be the one that survives a find. One line to change. Everything else is READY as far as I can see.

Non-blocking:

• "The count of 48 'with a trace' was spot-checked, not re-derived" is honest, but "at least 51" is then an estimate too. Either derive it or say "48 spot-checked, plus the three restated here".
• CI build at 5c1d8e8 failed in Tools for checkout and the build. That is the runner DNS outage, not this tree.

[bong-water-water-bong]

VERDICT at 5c1d8e8: READY

The PR is docs only (docs/arch-gaps.md, +50/-3) and merges clean onto origin/main. I re-ran its claims on origin/main and the box:

• Build on the box: ~/flm-f9/xclbins has 54 entries and ~/flm-f9/lib/*.so has 34.
• translategemma: git grep -il translategemma finds 0 files. It is the one root with nothing.
• nanbeige4.1: 11 files match nanbeige, and registry/architectures.json:1105 is NanbeigeForCausalLM. Nanbeige4.1-3B is named in q4nx_semantics.{h,c}, q4nx_forward.{h,cpp}, docs/tokenizers.md and tests/data/tokenizers/Nanbeige4.1-3B-NPU2.json.
• medgemma: docs/npu.md:1847 is the gemma3 / medgemma-1.5-4b-it-NPU2 / hrx / not served row.
• lfm2.5: docs/npu.md:1848/1903 record LFM2.5-1.2B-NPU2 served on the per-op route at 3.5 to 4.6 tok/s, and :1962 records the Thinking pack loading. That matches "about 4 tok/s".
• census: watch FastFlowLM (HF org + GitHub releases), not only HF architectures #588: closed 2026-10-27T08:49Z, and its title is about watching FastFlowLM's releases. npu: every FastFlowLM/*-NPU2 model source imports and serves on --device npu (FLM 1.0.12 model sources, 59 repos) #1786 is open, opened 2026-11-10T02:30Z, and covers every *-NPU2 source serving. The re-pointing is correct.
• Links: npu.md and tokenizers.md both exist under docs/ on this head.

Not checked: the Medgemma-4B kernel shapes (GU K2560 N20480, D K10240 N2560). I did not find that pack's config.json under ~/flm-f9. The shapes agree with Gemma3-4B's H 2560 / IM 10240 (gate and up fused gives 2 × 10240).

The section says outright that the owed rows are un-inspected, which is the right way to word it. It does supersede #2065.

[bong-water-water-bong]

Folded into #2190 at f381a01f (the lane cap of two open PRs, orchestrator 16:45Z): this branch is merged there unchanged. Closing this one.