DwarfStar from our fork: 1BP packages; bump-ds4 rebases our commits

[bong-water-water-bong]

DwarfStar now comes from our fork, 1bit-MONSTER/ds4, which reads 1BP packages.

Submodule: third_party/ds4 moves from antirez/ds4 0aaea5a to 1bit-MONSTER/ds4 1bit/main a7f2e1e. That is upstream main 0aaea5a plus ds4#1:

• 1BP v5, which adds a GGUF-encoded metadata block and 64-byte alignment to 1BP;
• its reader, hooked into model_open();
• gguf-tools/gguf_to_1bp.py, which converts a local GGUF or an hf:// one read with range requests;
• gguf-tools/check_1bp.py.

bump-ds4.yml now works like bump-llama-vulkan.yml. When upstream main moves, it rebases our commits onto it, tags the old tip ds4-main-<sha12> and opens the pin PR. A commit that no longer applies stops the bump for a hand rebase. The secret HRX_BUMP_TOKEN needs Contents read/write on 1bit-MONSTER/ds4 too.

1bit serve recognises a 1BP package by its first four bytes and serves it on ds4, with --device auto too. Other devices refuse it with a message.

Docs: a 1BP section in docs/dwarfstar.md; NOTICE credits the fork.

Checked on Strix Halo (ROCm, gfx1151):

• DeepSeek V4 Flash Q2 (antirez/deepseek-v4-gguf rev f71f23d5, 81 GiB), converted from hf:// (1,328 tensors, 62 metadata keys): ds4-server gives the same answers and completion-token counts on the .1bp as on the GGUF, for three prompts at temperature 0 (256 tokens each).
• Qwen3-0.6B's package passes check_1bp.py: all 310 tensors and 32 metadata keys identical.
• The engine builds with -DONEBIT_DS4=ON from the fork.
• 1bit serve on a .1bp with no --device: see the comment below.

🤖 Generated with Claude Code

[context7]

Docs7 for 1bit-monster/engine

Result	Status	Action
Deployment	➖ Not used	—
Content review	➖ Did not run. This site has no agent runs available this month. Wait for the monthly reset or check your Docs7 plan.	—

Commit 10f99ca

[bong-water-water-bong]

Review: the code side looks fine. The fork is one commit ahead of the old pin (fast-forward), our new fork files carry the Apache notice, NOTICE is updated, and the force-push is guarded (--force-with-lease plus a ds4-main-* backup tag). Hold on merging for one process reason: bump-ds4.yml widens what the HRX_BUMP_TOKEN secret must be able to do. It gains Contents write on a second repo (1bit-MONSTER/ds4), and the workflow force-pushes that fork's 1bit/main. Per the 2026-09-26 lockdown rules, workflow permission changes go through an RFC in Discussions first, and the owner has to widen the token scope by hand anyway. Suggest: open the RFC (or link it here if one exists), let the owner decide on the token, then merge. The serve/docs parts could merge separately if you split them out.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1 - Partially compliant Compliant requirements: Implement GGUF reader for v2/v3 formats Implement F32/F16/BF16/Q8_0 dequantization Implement model config from GGUF metadata Implement thread pool Implement Qwen3 decoder in fp32 Ensure loading fails on any missing, misshaped or unused tensor Add GGUF and dequant unit tests on synthetic data Add golden test against HF transformers fp32 logits Document the CPU reference implementation Non-compliant requirements: None Requires further human verification: None

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

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Potential Resource Leak in onebp_file() The onebp_file() function opens a file stream but does not explicitly close it before returning. While the std::ifstream destructor will close the file, relying on destructors for resource management in performance-critical code paths can be suboptimal. It's better to ensure explicit resource management for clarity and to avoid potential issues in future modifications. bool onebp_file(const std::string& model) { std::ifstream f(model, std::ios::binary); char magic[4] = {}; return f.read(magic, 4) && std::memcmp(magic, "1BP\0", 4) == 0; } Inconsistent Error Handling for 1BP Files The error handling for 1BP files in serve_child() function is inconsistent with the handling of other file types. It throws an exception when the device is not 'ds4', but does not provide a clear error message for the case when the model is a 1BP file and the device is 'auto'. This could lead to confusion for users who are trying to use the default device. if (onebp_file(o.model)) { // DwarfStar (our fork) is the engine's 1BP reader if (o.device == "auto") o.device = "ds4"; if (o.device != "ds4") throw std::runtime_error(o.model + " is a 1BP package: it runs on --device ds4 (docs/dwarfstar.md)"); if (o.laya_auto || !o.laya_model.empty()) throw std::runtime_error("--laya routes among devices; a 1BP package runs on ds4 only"); }

[bong-water-water-bong]

Checked on Strix Halo with this branch (engine built with -DONEBIT_DS4=ON from the fork):

• 1bit serve -m DeepSeek-V4-Flash-Q2.1bp --ctx-size 8192, with no --device, logs 1bit serve: DeepSeek-V4-Flash-Q2 on ds4 (build/ds4/rocm/ds4-server) and answers "The capital of France is Paris."
• 1bit serve -m DeepSeek-V4-Flash-Q2.1bp --device vulkan is refused: "… is a 1BP package: it runs on --device ds4 (docs/dwarfstar.md)".

A first run showed that 1bit serve rejected anything other than a .gguf before routing. It now lets a 1BP package through (same commit, amended).

🤖 Generated with Claude Code