[bong-water-water-bong]

Reads a Ryzen AI 1.9 OGA NPU pack's Token .fconst through the 1.8 reader, and imports the lm_head that a 1.9 pack carries only in the .fconst tail.

What actually differs in a 1.9 pack

Measured by whole-file diff against the 1.8 pack of the same model, and confirmed on three models (Qwen2.5-0.5B, SmolLM2-135M, Qwen3-1.7B):

• a 4*NH-byte header is inserted after the q/k/v bundle — the four bytes 00 00 7f ff, repeated once per head (14 groups on Qwen2.5-0.5B, 32 on Qwen3-8B, 9 × 36 B on SmolLM2-135M, 16 × 64 B on Qwen3-1.7B). Its length being the head count is what makes it a test rather than a magic number;
• the q/k/v bundle is stored q,k,v where 1.8 stores k,q,v.

Everything else in a block is verbatim, the stream after the header reads at -4*NH, and the tail is identical — the entire file difference is layers × 4*NH bytes (24 × 56 = 1,344 on Qwen2.5-0.5B).

The tile shape cannot be derived from the pack (it is not a subset sum of the pack's own const sizes — checked exhaustively), so the parameters are a measured table keyed by hidden/heads/layers, and a 1.9 pack outside that table is refused by name rather than decoded on a guess. That is the same rule this importer applies everywhere else: a confident parse of the wrong offsets is the worst failure mode.

How it is read

The normalised bytes are written once and the rest of the importer is unchanged — geometry, norms, attention payload, MLP section and tail all read one set of offsets, and the 1.8 path costs nothing (a 1.8 pack comes back as itself, no copy).

lm_head: a 1.9 pack has no host-side MatMulNBits head at all. The tail opens with the same 1,856-byte envelope the final norm sits in, then the head's own 64-row tiles at K = hidden, and 1,856 + (vocab/64) × tile(hidden) must equal the tail length to the byte or the head is refused by name.

Evidence (Qwen2.5-0.5B-Instruct, rai_1.8.0_npu_4K vs rai_1.9.0_npu)

• 24/24 layer blocks normalise byte-identically to the 1.8 .fconst, and the 82,655,040-byte tail is identical — the whole file;
• the 1.9 import lands 291 tensors / 67,088 tiles, the same counts as the 1.8 import, with 768/768 attention tiles and 2,160/2,160 MLP groups surviving decode->encode, 48/48 RMSNorm anchors found, and the final norm read from the tail envelope;
• the two resulting containers are then payload-identical: all 291 tensor blobs compare equal, as do the manifest's attention payload, MLP section and parameter census — including lm_head, whose tail tiles therefore decode to exactly the same Q4 as the 1.8 pack's host-side initializer;
• the remaining difference between the two containers is metadata only (pack name, and the packs' own quantization_config version strings, 0.12rc4 vs 0.13).

Testing

ctest -j6: 128 of 129 pass. The one failure, npu_runtime_option, is pre-existing and unrelated — it fails identically on a clean tree (it is a CMake-configure probe whose expected refusal message does appear).

Scope

Qwen2.5-0.5B 1.9 is the verified entry in the table. Other 1.9 packs are refused with a message naming their hidden/heads/layers until their shape is measured against the 1.8 twin of the same model — which is the only thing that can establish it.

[bong-water-water-bong]

VERDICT: READY at d3050b75.

Both of the "could mis-parse rather than fail" paths are strict, and I checked them at the condition level rather than the summary level.

(1) Detection — fconst19_detect requires all three of the things you said, and refuses otherwise:

if (heads <= 0 || layers < 2) return false;                 // no degenerate geometry
… full-pattern std::memcmp (not just the 00 00 7f ff prefix) …
if (int(runs.size()) != layers) return false;               // EXACTLY `layers` runs
const int64_t s = runs[1] - runs[0];
if (s <= int64_t(pat.size())) return false;                 // a stride that can hold a block
for (k) if (runs[k+1] - runs[k] != s) return false;         // UNIFORM spacing, every gap

A wrong head count makes pat the wrong length (no match), a wrong layer count fails the run count, and any non-uniform spacing fails the last loop — so the
three ways a 1.9 file could look right and not be are all refused. The byte-wise comparison (rather than an integer read) is the right call and your comment
says why: the little-endian value of the same bytes is 0xff7f0000.

(2) The table is one measured row, {896, 14, 24, 16, 34816, 2}, matched on the exact hidden/heads/layers triple, and anything else is refused by
name with its geometry and the reason ("its block shape has not been measured for hidden …, heads …, layers …"). Refusing rather than generalising is
correct given the stated justification — the tile shape is not a subset sum of the pack's own const sizes — and it is the same discipline as #1409's rule
(b): an unmeasured geometry is a named refusal, not a best-effort decode.

(3) The tail read asserts the arithmetic before touching a tile, and names both numbers:

const int64_t want = kTailNorm + rows * tile;   rows = V / kTileRows;  tile = attn_tile_bytes(H)
const int64_t have = int64_t(fc.size) - tail_off;
if (V % kTileRows != 0 || want != have)  → refuse, quoting have, want and "1856 + rows x tile"
else → read tiles

and it runs only when onnx.matmuls.empty() (no host-side head at all), so 1.8 packs are untouched.

The evidence has an independent cross-check that I can confirm from my own record: the 1.9 import landing 291 tensors / 67088 tiles is exactly what
#1412's 1.8 import of the same model produced — I recorded "291 tensors / 67088 tiles / 0.994548" reviewing that PR. Two different parse routes agreeing on
the tensor and tile counts, plus payload-identical blobs across all 291, is the strongest available confirmation of the tail layout: a wrong offset would
change the tile count or the bytes, not both silently.

Two small things to fix while you are here (neither affects this pack):

1. kTailNorm = 1856 encodes hidden 896 — [2 eps][62 pad][1792 norm], and 1792 = 2 x 896. The table is keyed generally but this constant is not, so
   the day a second row is measured the tail assertion would be silently wrong for it. Either derive it (64 + 2 * rule->hidden) or assert
   rule->hidden == 896 where it is used, so a second row fails loudly instead of mis-parsing — which is the principle the rest of this PR follows.
2. kFconstHidden = 896 is declared and never used (one occurrence in the file, the declaration). Dead const, and a -Wunused-const-variable candidate.

Merge-order note: the branch predates #1480's merge (b00845ad8 is not an ancestor), so ~21 of the +238 lines are that PR's q4nx_designs guard arriving
again. They drop on an update-from-main — no correctness issue, just a smaller diff when it lands.

[bong-water-water-bong]

VERDICT: CHANGES at d3050b75 — the table carries one geometry while the body claims three are confirmed, and the byte
counts in the body read wrong. The mechanics themselves check out as far as I can verify them without an NPU build.

1. "Confirmed on three models" vs a one-row table — so two of the three are refused in practice

The body says the 1.9 shape was "confirmed on three models (Qwen2.5-0.5B, SmolLM2-135M, Qwen3-1.7B)", and the code says a
1.9 pack outside the table "is refused by name rather than decoded on a guess". The table in this head has exactly one
row:

constexpr Fconst19Rule kFconst19Rules[] = {
    // Qwen2.5-0.5B-Instruct: normalises to its 1.8 twin byte for byte, whole file, all 24 blocks.
    {896, 14, 24, 16, 34816, 2},
};

A SmolLM2-135M or Qwen3-1.7B 1.9 pack therefore lands in the refusal path, which makes "confirmed" read as "supported" when
it is not yet. Either the two measured rows belong in the table (if the tile/tile-size came out of the same whole-file diff),
or the body should say plainly that only Qwen2.5-0.5B imports today and the other two are the next rows to measure. As
written the PR's own discipline is right and the description is a step ahead of the code.

2. The header byte counts in the body read as 4× too large

4*NH-byte header … the four bytes 00 00 7f ff, repeated once per head (14 groups on Qwen2.5-0.5B, 32 on Qwen3-8B,
9 × 36 B on SmolLM2-135M, 16 × 64 B on Qwen3-1.7B)

4*NH for those two models is 36 B (9 heads) and 64 B (16 heads) in total; "9 × 36 B" and "16 × 64 B" read as 324 B
and 1024 B, i.e. as if the group size were 36/64 B. The comment above the table (4*NH-byte header … once per head) is
correct — it is only the model list in the description that can be misread, and this paragraph is the one a future reader will
use to decide whether their pack is in the family. Suggest "36 B (9 heads × 4)" / "64 B (16 heads × 4)".

3. The arithmetic I could check, checks out

24 layers × 4 × 14 heads = 1,344 B total difference on Qwen2.5-0.5B, which matches the table row ({896, 14, 24, …}) and the
body's own figure. The q,k,v → k,q,v reorder plus the -4*NH read offset are internally consistent in the two places the diff
touches them (fconst19_header, the header test), and the q4nx_designs config field is written by the importer with the same
ROLE:KxN shape the forward compares against — a drift there fails loudly, which is the right direction for a check whose
alternative is silently wrong text.

4. No test for a byte-layout parser with a refusal table

Two files changed, no test. The behaviours worth pinning are exactly the ones that cannot be eyeballed in review: fconst19_header
detection (counts layers headers, evenly spaced, else "not a 1.9 form"), the refusal message for an out-of-table geometry, and
the q4nx_designs round-trip (importer writes it, forward compares it, a mismatch refuses). The repo has precedent for unit tests on
parsers; a fixture built from the 1.9 twin's first block plus the 1.8 one would cover all three without an NPU.

Not claimed: no build or run of this PR from me, and I have not re-derived any measurement — the review is the table/claim gap,
the byte-count wording, the arithmetic cross-check and the missing test.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

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

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Potential Incorrect Assumption on Tile Shape Derivation The code assumes that the tile shape for Ryzen AI 1.9 packs cannot be derived from the pack itself and must be measured empirically. While this is stated as a design choice, it introduces a potential point of failure if the measured rules do not cover all possible configurations or if new models are introduced without corresponding measurements. This could lead to a refusal to process valid packs that fall outside the known rules. struct Fconst19Rule { int hidden, heads, layers, n_tiles, tile, rot; }; constexpr Fconst19Rule kFconst19Rules[] = { // Qwen2.5-0.5B-Instruct: normalises to its 1.8 twin byte for byte, whole file, all 24 blocks. {896, 14, 24, 16, 34816, 2}, }; Risk of Incorrect Header Detection The fconst19_detect function relies on detecting a specific pattern (00 00 7f ff) repeated per head to identify the header. If the pattern is not consistently applied or if there are false positives in the detection logic, it could incorrectly identify a 1.8 pack as a 1.9 pack, leading to incorrect processing and potential runtime errors. bool fconst19_detect(const Fconst& fc, int heads, int layers, int64_t* hdr_off, int64_t* stride) { if (heads <= 0 || layers < 2) return false; const std::vector<uint8_t> pat = fconst19_header(heads); std::vector<int64_t> runs; for (size_t i = 0; i + pat.size() <= fc.size;) { if (fc.map[i] == pat[0] && fc.map[i + 2] == 0x7f && fc.map[i + 3] == 0xff && std::memcmp(fc.map + i, pat.data(), pat.size()) == 0) { runs.push_back(int64_t(i)); i += pat.size(); } else { ++i; } } if (int(runs.size()) != layers) return false; const int64_t s = runs[1] - runs[0]; if (s <= int64_t(pat.size())) return false; for (size_t k = 0; k + 1 < runs.size(); ++k) if (runs[k + 1] - runs[k] != s) return false; *hdr_off = runs[0]; *stride = s; return true; } Inconsistent Handling of lm_head in 1.9 Packs The code handles the lm_head differently for 1.9 packs compared to 1.8 packs by reading it from the tail of the .fconst file. If the arithmetic to determine the tail offset or the tile layout is incorrect, it could lead to reading invalid memory or refusing valid heads, which might cause import failures. if (onnx.matmuls.empty()) { const int64_t tail_off = int64_t(p.dims.layers) * g.stride; const int64_t tile = attn_tile_bytes(H); const int64_t rows = V / kTileRows; const int64_t want = kTailNorm + rows * tile; const int64_t have = int64_t(fc.size) - tail_off; if (V % kTileRows != 0 || want != have) { late.push_back("lm_head.weight: the .fconst tail is " + std::to_string(have) + " B, not the " + std::to_string(want) + " B its envelope and head tiles would take (" + std::to_string(kTailNorm) + " + " + std::to_string(rows) + " x " + std::to_string(tile) + " B), so the head's offsets are not established"); } else { std::vector<TileW> tiles; tiles.reserve(size_t(rows)); bool exact = true; for (int64_t i = 0; i < rows; ++i) { const uint8_t* src = at(fc, tail_off + kTailNorm + i * tile, tile); tiles.push_back(decode_tile(src, int(H))); const std::vector<uint8_t> back = encode_tile(tiles.back()); if (std::memcmp(back.data(), src, size_t(tile)) != 0) exact = false; } if (!exact) { late.push_back("lm_head.weight: the .fconst tail's tiles do not survive decode->encode, " "so their fields are not understood"); } else { Q4 q = q_from_tiles(tiles); std::vector<uint8_t> tiled; long long pinexact = 0; tile_q4_1_f32(q, tiled, &pinexact); r.codes_total = q.codes.size(); r.zero_exact_pct = 100.0 * double(q.scale.size() - pinexact) / double(q.scale.size()); const int64_t head_tiles = int64_t(tiled.size() / kImportTileBytes); r.tiles += head_tiles; w.add("lm_head.weight", "I8", {head_tiles, kImportTileBytes}, std::move(tiled)); ++r.tensors; } } }