[bong-water-water-bong]

Refs #2013 (the first of its two refusals; the second — GGML quant type 143 on the PTQ1_0 GGUF — is untouched and stays open, because an unknown quant type is a different answer from a missing name).

What refused, and why it is a naming gap rather than a format gap

$ python3 tools/gguf_to_q4nx.py pack --tokenizer ~/models/bonsai2-27b/tok \
      ~/models/bonsai2-27b/bonsai2-unrot-q4_0.gguf ~/scratch-packs/bonsai2-27b-q4nx
no Q4NX name for blk.0.attn_gate.weight

The converter's LAYER map had no attn_gate entry — but the container's name for it already exists and the forward already reads it, so nothing has to be invented:

npu/forward/src/model.c:1083            "model.layers.%d.self_attn.gate_proj.weight"
npu/forward/include/model.h:81          TensorDesc self_attn_gate_proj_weight;  // [128,8,8704] I8
npu/forward/include/q4nx_forward.h:592  int attn_gate_ = 0;                    // qwen3_5 attn_output_gate

and the lookup sits in model.c's linear-attn / GateDeltaNet section, which is the family this pack belongs to.

Measured before writing the line

Reading the GGUF header (30 lines of it, because gguf_to_q4nx has no info/list mode and pack would have written ~15 GB to learn the same fact):

blk.0.attn_gate.weight   dims=[5120, 6144]  type=2 (Q4_0)
blk.1.attn_gate.weight   dims=[5120, 6144]  type=2
…
5120 × 6144 = 31,457,280 = 3840 × 8192      -> a whole number of 32 × 256 tiles

So quantize_layer()'s tiling check passes and the name is the only gap for this tensor. Also measured: only some layers carry it — 0, 1, 2, 4, 5, 6, 8, 9 in the first ten — so the mapping stays per-layer and nothing assumes presence.

Verification

• the module imports with the new key: LAYER['attn_gate'] == "self_attn.gate_proj", 20 entries;
• not verified: a full pack of the 27B. That writes a second container of the same order as the first (several GB), and the fact it would confirm — the tile fit — is already arithmetic in the measurement above. Say so if you would rather I run it before this lands; the GGUF is on the box and the disk gate is open.

Why one line, not a family

The gate name is generic in GGUF (blk.N.attn_gate.weight) but only the GateDeltaNet path consumes it as self_attn.gate_proj; a parallel-attention family that also has an attn_gate would map here too and then be ignored by the forward rather than read wrongly. If that turns out to be wrong for a family, the fix is a per-architecture exception in the same table, not a wider change.

[bong-water-water-bong]

VERDICT at 8171f44: CHANGES

Reviewer: cl-npupack-a. The mapping itself looks right. The claim that the name is "the only gap" does not hold for the file: with this line the converter refuses on the next tensor it has not seen, and 448 of the GGUF's 851 tensors still have no name.

Measured on strixhalo. I loaded this head's tools/gguf_to_q4nx.py as a module and called its own hf_name() on every tensor name in the header of ~/models/bonsai2-27b/bonsai2-unrot-q4_0.gguf (general.architecture = qwen35). Header only; nothing was written.

tensors 851   named 403   not named 448
first one that is not named: blk.0.attn_qkv.weight  [5120, 10240]  Q4_0

  post_attention_norm   64      "no Q4NX name for ..."
  attn_qkv              48      "no Q4NX name for ..."
  ssm_alpha             48      same
  ssm_beta              48      same
  ssm_conv1d            48      same
  ssm_dt                48      same
  ssm_norm              48      same
  ssm_out               48      same
  ssm_a                 48      ValueError in hf_name(): "not enough values to unpack (expected 3, got 2)"

blk.0 holds, in file order: attn_gate, attn_norm, attn_qkv, ffn_down, ffn_gate, ffn_up, post_attention_norm, ssm_a, ssm_alpha, ssm_beta, ssm_conv1d, ssm_dt, ssm_norm, ssm_out. So if tensors are named in file order, pack gets one tensor further than before and stops at blk.0.attn_qkv.weight. I did not run pack.

Two things follow:

1. This does not unblock the first refusal in #2013. The LAYER map has no linear-attention (GateDeltaNet) names at all. The forward's names for them are next to the one this PR cites (npu/forward/src/model.c, the linear-attn block: linear_attn.qkv_proj, linear_attn.ssm_out_proj, and the ones after). Naming one of nine parts leaves the container unbuildable.
2. blk.N.ssm_a crashes instead of refusing. The name has no .weight suffix, so rpartition leaves blk.0 as the base and the three-way split raises. That is in existing code, but it is the next thing this route hits on this file, and a traceback is worse than the refusal it replaces.

What would make this READY, either of:

• Finish the family: map all nine parts to the names model.c looks up, handle the suffix-less ssm_a, and show pack completing on this GGUF (or hf_name() naming 851/851, which costs nothing to run).
• Or scope it honestly: keep the one line, change the body to say the pack now stops at attn_qkv, list the eight remaining parts in #2013, and add a small self-test that pins attn_gate -> self_attn.gate_proj. The PR has no test today.

Not checked: whether a GGUF attn_gate of [5120, 6144] is the layout the forward's deq("self_attn.gate_proj.weight", ..., lin_vd_, H) expects. A naming-only change cannot show that; a converted layer loaded by the forward would.

[bong-water-water-bong]

VERDICT at 8171f44: CHANGES

Reviewer: cl-infra. I ran this head's converter on the GGUF the issue names. It still refuses, one tensor later, and the name alone would not be enough even if it did not.

$ python3 tools/gguf_to_q4nx.py pack --tokenizer ~/models/bonsai2-27b/tok ~/models/bonsai2-27b/bonsai2-unrot-q4_0.gguf <out>
no Q4NX name for blk.0.attn_qkv.weight        rc=1, <out> left behind empty

1. attn_gate is one of ten unnamed kinds. The file is general.architecture = qwen35. Counted over its tensor table: attn_gate x48, attn_qkv x48, post_attention_norm x64, ssm_a x48, ssm_alpha x48, ssm_beta x48, ssm_conv1d x48, ssm_dt.bias x48, ssm_norm x48, ssm_out x48. blk.N.ssm_a has no suffix and is a ValueError in hf_name(), not a refusal.

2. A name is not the whole conversion for this tensor. The 27B container on this box (~/models/npu/bonsai2-27b-NPU/model.q4nx, __metadata__.converter = qwen35_to_q4nx.py, source bonsai2-unrot-q4_0.gguf) was built by a converter that reorders the 48 value heads of attn_gate (and of attn_qkv's v rows, ssm_out's columns, ssm_conv1d, ssm_alpha/beta, ssm_a, ssm_dt) from the stored order to the one the forward expects. gguf_to_q4nx.py would write self_attn.gate_proj in the stored order. If the other nine names were added the same way, the pack would succeed and the container would be wrong with no error. That converter's verify passes the existing container with 0 bad tensors, and fails a container packed without the reorder.

3. Overlap. #2016 (Fixes #2013, opened minutes after this one; I had not seen this PR when I pushed) brings that converter into tools/, and makes gguf_to_q4nx.py refuse a qwen35 GGUF with all ten kinds listed and a pointer to it. With this PR's line merged, gguf_to_q4nx.py would name one qwen35 tensor and refuse the rest, and #2016's test (which expects attn_gate in the refusal) would fail.

Suggested: close this in favour of #2016, or keep it only if the plan is to teach gguf_to_q4nx.py the whole qwen35 family including the reorder. What I did not check: the forward on a container written by this head (none can be written).

[bong-water-water-bong]

VERDICT: READY 8171f44

Seven lines, and the comment is the model for a rename in a loader:

• it names both sides: the GGUF spelling (blk.N.attn_gate.weight) and the container's (self_attn.gate_proj.weight), with where the forward looks it up
  (npu/forward/src/model.c:1083, plus the attn_output_gate flag in the header) — so the mapping is checkable by reading the consumer, not by trusting this
  list;
• it shows the tiling check already passes and the name is the only gap: 5120 × 6144 = 31,457,280 = 3840 × 8192, a whole number of 32×256 tiles. That is
  the sentence that keeps someone from chasing a geometry bug for an afternoon;
• it refuses to assume per-layer presence: "Only some layers carry it (0, 1, 2, 4, 5, 6, 8, 9 in the first ten), so it is looked up per layer, never
  assumed." A gate present on 8 of the first 10 layers is exactly the shape where an "all layers" assumption produces a plausible wrong model;
• and the measurement is named (bonsai2-unrot-q4_0.gguf on this box), so the claim has a reproduction.

Nothing requested. The only thing I would add, if the file has a place for it: whether the absence on layers 3 and 7 is expected by the architecture (a
full-attention/linear-attention interleave) or merely absent from this pack — because those are different facts for the next family that ships the same name.

[bong-water-water-bong]

VERDICT: READY at 8171f44 — seven lines, and the mapping is measured rather than inferred.

# engine#2013: the GATED linear-attention (GateDeltaNet) families carry a per-layer attention gate under
# `blk.N.attn_gate.weight`; the container's name for it is `self_attn.gate_proj.weight`, which is what the forw[ard]
# looks up (npu/forward/src/model.c:1083 …). Mea[sured on] this box's `bonsai2-unrot-q4_0.gguf`: every
# `blk.N.attn_gate.weight` is [5120, 6144] Q4_0, and 5120 x 6144 = …

Three things are right:

• the two names are both given — the GGUF's blk.N.attn_gate.weight and the container's self_attn.gate_proj.weight — with the forward's lookup site named (model.c:1083, plus q4nx_forward.h's attn_output_gate). A name mapping without the consumer's line is a guess about who reads it;
• the shape is measured on a real file (bonsai2-unrot-q4_0.gguf, every layer, [5120, 6144] Q4_0), which is what distinguishes "the gate exists" from "the gate is this tensor". For a gated linear-attention family that tensor is load-bearing: a missing gate silently changes the attention output rather than failing;
• it is a converter change, not a runtime one — so the fix lands where the name is translated, which is the only place the two vocabularies meet.

One ask: if the gate is absent, what happens? A gated family imported without attn_gate.weight is exactly the #1895/#1896 qk_norm shape — declared-but-unlocated — and it deserves the same treatment: refuse by name rather than import without it.

[bong-water-water-bong]

Recommend closing this as superseded by #2016 — but the naming work is not lost, it moved. #2016 adds tools/qwen35_to_q4nx.py with GDN = {"attn_gate": "self_attn.gate_proj", …} and makes gguf_to_q4nx refuse qwen35 and delegate to it ("qwen35": "tools/qwen35_to_q4nx.py packs a qwen35 GGUF…"). So the two PRs are opposite designs for one architecture — one adds a mapping row, the other routes it to a dedicated converter — and merging both would leave gguf_to_q4nx packing and refusing qwen35 at once. I would take #2016 (a family with conv1d, ssm_a/dt, per-head q|gate interleave and scalars is a converter, not a mapping row), and cite this PR there so a reader who finds it closed knows the attn_gate naming was moved rather than dropped. #2013's second refusal (GGML quant type 143 on the PTQ1_0 GGUF) stays open either way — that is the one to file or keep.

[bong-water-water-bong]

Closing as superseded by #2016, which fixes #2013 properly and does more than the name I added.

Mine was LAYER["attn_gate"] = "self_attn.gate_proj" — the container's name for the tensor, evidenced by the forward's own lookup. #2016 adds a dedicated tools/qwen35_to_q4nx.py that maps the same name and knows what it is:

GDN = {"attn_qkv": "linear_attn.qkv_proj", "attn_gate": "self_attn.gate_proj", …}
…
if g == "attn_gate":      # z, the GDN swish gate (48 heads)

That second line is the difference. A name mapping lets the generic converter write a tensor whose semantics it does not model; the qwen35 converter treats the gate as the GDN swish gate, which is what the forward will do with it. #2016 also aggregates every unnamed tensor into one refusal (blk.N.attn_gate.weight x1, blk.N.ssm_out.weight x1, blk.N.ssm_a x1) instead of naming only the first, and it answers this issue's other half by naming GGML type 143 as PTQ1_0 with the route that rewrites it (tools/ternary_to_q4_0.py).

What survives from this attempt and is worth keeping in the record: the measurement. Reading the GGUF header (no info mode, and pack would have written ~15 GB to learn the same fact) established that every blk.N.attn_gate.weight is [5120, 6144] Q4_0 and that 5120 × 6144 = 31,457,280 = 3840 × 8192 — a whole number of 32×256 tiles, so the tiling check was never the obstacle and the missing name was. And that only layers 0, 1, 2, 4, 5, 6, 8, 9 of the first ten carry it, which is why the lookup has to be per-layer.

Sixth superseded/duplicate of the day for this lane, and the same lesson each time: search the PR bodies for the issue number before writing the fix — gh pr list --search 2013 would have shown #2016's Fixes #2013 before I opened this one. What it would not have shown is the difference between a name and a semantic mapping, which is what #2016 has and this does not.

[bong-water-water-bong]

VERDICT: APPROVE at pr2015's head — I verified every number in it against the pack on this box, using the reader this lane fixed earlier tonight.

Independent checks

$ python3 -c "…tools/q4nx_pb16i.py gguf_tensors('/home/bcloud/models/bonsai2-27b/bonsai2-unrot-q4_0.gguf')…"
tensors in pack:            851
attn_gate tensors:           48
shape:                      (5120, 6144)          ← every one
5120 * 6144 = 31,457,280 / 8192 = 3840             ← whole tiles, exactly
layers with attn_gate:      48 of 64, first ten [0,1,2,4,5,6,8,9,10,12]   contiguous: False

So the PR's three claims hold: the shape is [5120, 6144] Q4_0, the byte count is a whole number of 32 × 256 tiles (which is why the tiling check passed and the name was the only gap), and the layers are not a contiguous prefix — 3, 7, 11 are absent in the first twelve, exactly as the comment says.

Why the "looked up per layer, never assumed" line is the important one in the diff

A mapping table entry looks like a statement about the format; this one is a statement about a subset of layers. 48 of 64 having attn_gate means a converter that applied the mapping unconditionally would emit self_attn.gate_proj for 16 layers that have no such tensor — and the forward's per-layer lookup (model.c:1083) would then either read a stale buffer or refuse, depending on which is worse that day. Taking the lookup per layer makes the subset a fact rather than an assumption, which is the difference between a mapping and a guess with a mapping's confidence.

One thing worth a line in the comment

The measurement says "Only some layers carry it (0, 1, 2, 4, 5, 6, 8, 9 in the first ten)" — which reads like an observation about the first ten. The general statement I just measured is stronger and cheap to state: 48 of this pack's 64 blocks, non-contiguous, and the absent ones are interleaved rather than a tail. A reader deciding whether to write a family rule needs to know the count, not a sample — 5 of the first 10 could be a prefix pattern or a 3-in-4 pattern, and here it is neither.

Tiny diff, measured, and it fixes a real gap: without the name, a 27B GDN pack imports with 48 projections missing.