[bong-water-water-bong]

closes #961.

What moves

third_party/llama.cpp: d8bd0ff6052a → a5c32fbf8b5a, the fork's 1bit/hrx-vulkan-patched tip. One submodule
gitlink, nothing else.

a5c32fbf8b is d8bd0ff6052 + fork #187 squash-merged, i.e. linearly one commit ahead — tools/check_pins.py agrees:

$ GITHUB_TOKEN=… python3 tools/check_pins.py origin/main
ok   third_party/llama.cpp: d8bd0ff60 -> a5c32fbf8 is ahead
$ python3 tests/check_pins_test.py
Ran 3 tests — OK

and the commit resolves from a clean clone of the fork (git fetch --depth 1 origin a5c32fbf8b, one commit, parent
d8bd0ff60).

Why it fixes #961

At the old pin, convert_hf_to_gguf.py reads args.dspark at :261 and registers no --dspark argument, so
argparse.Namespace has no such attribute and every conversion dies with AttributeError there, whatever the model.
The new pin adds the registration at :156 and the V4/V4.1 architecture guard at :265-267:

$ git show d8bd0ff60:convert_hf_to_gguf.py | grep -c '"--dspark"'   -> 0     (one read, no registration)
$ git show a5c32fbf8b:convert_hf_to_gguf.py | grep -c '"--dspark"'   -> 1     ("--dspark", action="store_true")

What this pin does not bring, so it is not a surprise later

--dspark + DeepseekV4ForCausalLM (V4, not V4.1) still fails: the fork branch has no DeepseekV4DSparkModel in
conversion/deepseek.py (nor a Qwen3DSparkModel in conversion/qwen.py), although conversion/__init__.py:61 lists
both and main() imports the V4 class from conversion.deepseek. The classes exist on other fork branches and come
from upstream 3581ba0cf (#26452). DeepSeek-V4.1 is the path that becomes usable (DeepseekV41DSparkModel is in
conversion/deepseek41.py:300). Noted in #961 and in the #187 review; not fixed by a pin bump.

Not done here

No engine build was run for this bump on this box (no HRX deps here, and it is a gitlink-only change) — the PR's own
CI build job is what compiles it, and the converter itself cannot be executed on this box at all yet: import transformers fails with huggingface-hub>=1.5.0,<2.0 is required … but found huggingface-hub==2.4.0. That is an
environment fact recorded in ~/briefs/TPRS-STATE.md, not something this pin can fix.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit d65a033)

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 961 - Partially compliant Compliant requirements: The --dspark argument is now registered in convert_hf_to_gguf.py The guard logic for supported architectures is implemented and functional The fix allows conversions to proceed without error for models that support the --dspark flag Non-Deepseek models correctly reject the --dspark flag with an appropriate error message Non-compliant requirements: The V4 (non-4.1) checkpoint conversion still fails due to missing DeepseekV4DSparkModel class in conversion/deepseek.py Requires further human verification: The V4 (non-4.1) checkpoint conversion behavior needs further verification 187 - Partially compliant Compliant requirements: The Laya classifier is implemented and functional The policy mapping conversation classes to devices is implemented The --laya flag is supported in the serve command The Laya classifier and policy are integrated into the engine The Laya classification and routing works as expected Non-compliant requirements: The PR description mentions that the V4 (non-4.1) checkpoint conversion still fails, but this is outside the scope of this PR Requires further human verification: None

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

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Missing argparse registration The --dspark argument was not registered in the argparse configuration, causing an AttributeError when the code tried to access args.dspark. This has been fixed by adding the registration in the new commit. Subproject commit a5c32fbf8b5ae1f060b69b1d01393512b7329134

[bong-water-water-bong]

Pushed 646c4085f onto this branch: the bump's registry record was missing, and ctest registry_pins fails without it.

registry/architectures.json records the pins it was generated from, and it still said
"llama.cpp (hrx)": "d8bd0ff6052a…" while this commit moves the gitlink to a5c32fbf8b…. CONTRIBUTING
("The registry follows the pins… a hand-made pin change runs the same") and docs/registry.md are explicit that the
regenerating script is part of a pin bump; CI's registry_pins compares the committed pins against that file.

Done with the documented recipe, from a fresh clone (~/work/pin961/engine, not a reused worktree) at this branch's
head, so the numbers below are this PR's tree:

$ scripts/registry-regen.sh          # inits the 3 trees the registry reads at their pins, rewrites, then verifies
Submodule path 'third_party/llama.cpp': checked out 'a5c32fbf8b5ae1f060b69b1d01393512b7329134'
wrote registry/architectures.json: hrx 294, npu 7, architectures 294, mapped 294
none of the 28 reviewed significant classes is mapped without a reason
registry/architectures.json records the committed pins
$ python3 tools/copyright.py --check        # clean

One line changes — the recorded pin — because a5c32fbf8b only adds parse_args()'s --dspark block (#187) and moves
no architecture: counts stay hrx 294 / npu 7 / mapped 294, and no reviewed class became mapped-without-a-reason.

Also verified the fix actually arrives with the new pin, since that is the whole point of the bump (default python3
on this box cannot import the converter — huggingface-hub 2.4.0 vs what the installed transformers accepts — so this
used ~/venvs/quark013):

• convert_hf_to_gguf.py --help at a5c32fbf8b lists [--fuse-gate-up-exps] [--fp8-as-q8] [--dspark] with upstream's
  help text; at d8bd0ff60 there is no registration (grep -c '"--dspark"' → 0).
• --dspark on a non-Deepseek model (ZR1-1.5B, Qwen2ForCausalLM) now reaches the guard that was unreachable:
  ERROR:hf-to-gguf:--dspark is only supported for DeepseekV4ForCausalLM and DeepseekV41ForCausalLM, exit 1, no file
  written.
• Full BF16 conversion of ZR1-1.5B from the new pin is running now; I will post its size/sha256 against convert: the llama.cpp pin's convert_hf_to_gguf.py reads args.dspark but never registers --dspark, so every conversion dies with AttributeError #961's
  3,560,417,696 B / d817473c… when it lands rather than claim it early.

Nothing else touched: the diff on this branch is the gitlink plus this one-line registry update.

[github-actions]

Persistent review updated to latest commit 646c408

[bong-water-water-bong]

The conversion proof, from the new pin at a5c32fbf8b (fresh clone, ~/venvs/quark013, ~/lb/thermal-run.sh, 90 s):

$ python convert_hf_to_gguf.py ~/models/zyphra-orig/ZR1-1.5B@6108a26d0cd7 --outtype bf16 --outfile /tmp/pin961-ZR1.gguf
n_tensors = 339, total_size = 3.6G
Model successfully exported to /tmp/pin961-ZR1.gguf

3,560,417,696 B
sha256 d817473c0e56d2389fb5b0dc633ca33bdc7ec0d82448c318283800c0728744f3

That is byte-identical to #961's reference (3,560,417,696 B, d817473c…), which is what the issue asks for: the bump has
to make conversions from the pin work again and produce the same bytes the workaround produced. 339 tensors, one file.

So the acceptance for #961 from this branch is: --help lists --dspark, the V4.1-only guard fires and writes nothing on a
non-Deepseek model, the full BF16 conversion completes with the reference hash, and (from the previous comment) the registry
record moves with the pin so registry_pins passes. The V4 (non-4.1) ImportError stays open as #961's second half — not
fixable by a pin bump.

[bong-water-water-bong]

VERDICT: READY — the bump is one gitlink plus its registry line, and CI is green on both.

Reviewed as the author of the bump, at 646c4085 (two commits: 76eebc11c the gitlink, 646c4085f the registry line).

What I verified:

• git diff origin/main...646c4085 --stat is exactly registry/architectures.json 2 +- and third_party/llama.cpp 2 +-,
  i.e. no third file rides along with a pin bump.
• The pin target resolves: git fetch --depth 1 origin a5c32fbf8b from a clean clone gives one commit on top of
  d8bd0ff60, and at that commit grep -c '"--dspark"' convert_hf_to_gguf.py is 1 (0 at the old pin).
• The registry line is the generated half of the same change, not a hand edit: registry/architectures.json records
  llama.cpp (hrx) and ctest registry_pins compares the committed pins against it, so the gitlink alone fails that
  test. The new value is a5c32fbf8b5ae1f060b69b1d01393512b7329134, counts unchanged at hrx 294 / npu 7 — right, since
  #187 only adds the converter's argparse block.
• tools/check_pins.py origin/main -> ok third_party/llama.cpp: d8bd0ff60 -> a5c32fbf8 is ahead; tests/check_pins_test.py
  3 tests OK.
• CI: build pass, CodeQL pass, Analyze (actions|c-cpp|javascript-typescript|python|rust) 5x pass,
  hrx-system gitlink agrees with the hold file pass, pinned loom-jit.cpp compiles against the pinned hrx-system pass.
  pr_agent cancels or fails on every engine PR while coder-llm is off; hw_gate skips. Neither is a gate here.

Still true, and already in the body: the converter cannot be run on this box (import transformers fails on the
huggingface-hub version), so no converted GGUF is claimed; --dspark + DeepseekV4ForCausalLM still raises ImportError
because conversion/deepseek.py has no DeepseekV4DSparkModel on that branch — DeepSeek-V4.1 is the path that becomes
usable. A later fork tip needs its own bump PR; this one covers d8bd0ff60 -> a5c32fbf8b only.

[github-actions]

Persistent review updated to latest commit 0a41718

[github-actions]

Persistent review updated to latest commit 1bdccf5

[github-actions]

Persistent review updated to latest commit 598c11c

[github-actions]

Persistent review updated to latest commit 232b152

[github-actions]

Persistent review updated to latest commit d65a033