…ily (#480)
* serve: the placement report covers every graph, not just the warmup
--placement-report passed GGML_HRX_REPORT=1, and the backend's 1 is the
first graph only, so serve printed a clean report for a model that leaves
nodes on the CPU in later graphs: the 20 Oct census found LFM2 --parallel 4
(20 nodes, 5 splits) and ZAYA1-8B (1-3 nodes) reading "all nodes on HRX".
Ask for every graph (2), keep the worst one instead of the last, and print
serve's line again whenever a graph is worse than every graph before it,
with the graph count. --strict-device reads the same worst graph. Without
--placement-report serve keeps 1, so no log volume is added by default.
tests/hrx_placement_test.cpp covers a clean warmup followed by a par4 graph
and a later clean graph.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* serve: --strict-device reads the report it needs
--strict-device only passed GGML_HRX_STRICT=1 to the backend. It did not pass GGML_HRX_REPORT=2 and it
did not add the -lv 4 that lets llama-server's log level carry the placement report through, so the graph
that would have been refused was never reported and serve fell through to "the backend printed no
placement line" while starting normally. Both flags are now treated the same way: GGML_HRX_REPORT=2 and
-lv 4 whenever either is set, so the refusal reads the same worst graph that --placement-report prints.
Found on device: `1bit serve ... --strict-device --parallel 4` (LFM2-1.2B) answered requests instead of
refusing, with that "no placement line" message in its log.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* serve: --parallel on qwen35 / qwen35moe / qwen3next
These architectures were refused with "--parallel on --device hrx does not run <arch> yet (no
multi-sequence gated delta-net on HRX)". That was true when the HRX gated-delta-net matchers held
kMaximumSequences 3; they hold 8 now (llama.cpp 1bit/hrx-gdn-multi-sequence), and a four-sequence run keeps
every node on the device.
Measured on Qwen3.8-27B UD-Q4_K_XL, `--parallel 4`, four concurrent chats: 4 of 4 answered, placement "all
3655 nodes on HRX, 1 graph splits", zero error lines. The forced `-np 1` for these architectures when
--parallel is not given stays: llama-server's own default opens several slots, and that is a different
question from the explicit flag.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Pin llama.cpp cefbfc07 (fork #117, G9) and gpu-kernels 421d7a4e (G7 #11, G8 #12); --parallel on qwen35 family
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* registry: regenerated at llama.cpp cefbfc07
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Pin llama.cpp dcf8c1ec (fork #118: narrower GDN claim) and gpu-kernels 449a809e (#13: v_f16 ABI + f16-V read fixes)
Fixes this PR's first hw-gate run (ops 618/649, Coder-30B HTTP 500).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* registry: regenerated at llama.cpp dcf8c1ec
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: bcloud <bcloud@localhost>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: bcloud <bcloud@1bit.local>
Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg>
Next step of Zyphra-family support.
third_party/llama.cpp-vulkan→1bit/vulkan-upstreamf6261222(the currentee6e4e0d+ one commit of ours): model: BlackMamba (Zyphra/BlackMamba-1.5B, -2.8B), our code insrc/models/blackmamba.cpp/conversion/blackmamba.py.ggml_geglu_erf_split; the config saysswiglubut the activation isF.gelu).{"model": state_dict}, config.json withoutarchitectures), soconversion/base.pyroutes onmamba_moe_layers(next to the existingssm_cfgcase) and the converter uses the built-in GPT-NeoX vocab.Registry:
BlackMambaForCausalLM → vulkan. It is a base model, so there is no registry_check row (that check asks a chat question).🤖 Generated with Claude Code