Repository navigation
core: strip the ds4 route (DwarfStar) — antirez's CUDA kernels through a HIP shim + hipBLAS, not our HIP kernels; HRX serves those models #749
Description
Owner decision (orchestrator relay, 2026-11-01 06:09 AST): the ds4 route leaves the release and the core. It runs
antirez's CUDA kernels through a HIP shim plus hipBLAS — not our HIP kernels — so it does not belong in an engine whose
whole point is the HRX runtime, our HIP kernels and the NPU. HRX serves those models.
This reverses #306 strip 7 ("DwarfStar, HIP only: always its HIP backend for gfx1151") one step further: #306 removed
the CUDA/ROCm/Vulkan builds and kept DwarfStar; now DwarfStar goes too. Owner lane: pi-release — the build/config
side lands for c19, the code strip happens after the release.
Why now, in its own numbers
The route is already half-maintained out of tree, by chasing upstream CUDA: config/ds4-hold.config holds
third_party/ds4 because the HIP port is two upstream CUDA entry points behind, and the hold's own text names them —
ds4_deepseek41_cuda.cuh:796 calls ds4_gpu_attention_output_low_q8_rows_exact_tensor and
ds4_gpu_matmul_q8_0_kslice_rows_tensor, neither of which exists in the fork, so DS4_TEST=1 scripts/build-ds4.sh
fails linking tests/test_mxfp4_rocm. A route we hold, whose kernels are somebody else's CUDA, is not our core.
Stage A — c19 (config only; no code strip, reversible in one commit)
| where | now | c19 |
|---|---|---|
CMakeLists.txt:272 |
option(ONEBIT_DS4 … OFF) |
already OFF — the engine default is right; nothing to change |
scripts/weekly.sh:146 |
-DONEBIT_DS4=${ONEBIT_DS4:-ON} |
default OFF (or drop the flag) — this is the line that puts ds4 into every release build |
scripts/weekly.sh:600,608 |
preflight hard-fails without a hipcc for DwarfStar | must not gate the release build on the ds4 toolchain |
scripts/weekly.sh:192 |
bump-ds4/*) DS4_TEST=1 guard … |
arm removed with the workflow (stage B) |
scripts/weekly.sh:48 |
SUBMODULES=(hrx-system llama.cpp lemonade ds4 tokenizers) |
keep the pin in the list while the submodule exists; drop with stage B |
With ONEBIT_DS4=OFF, --device ds4 still parses and default_ds4() falls back to ds4-server on PATH
(app/serve.cpp:316-325) — so stage A must also make that path fail loudly ("this build has no ds4 route; use
--device hrx"), not silently look for a binary that is not shipped.
Stage B — after the release (the strip)
- Build/config:
CMakeLists.txt:272-284(option, custom target,ONEBIT_DS4_SERVERdefine). - CLI and routing (
app/serve.cpp):default_ds4():316-325,onebp_file():309-314 and theautoroute that
sends a 1BP package to ds4 at :1628-1631, the--ds4flag,--ssd-streaming(ds4-only, :937), the ds4 arms of the
three "works on the llama.cpp devices (hrx, cpu)" guards (:1072, :1098, :1117), the argv build at :1053-1055, :1639,
:2776, :2911; andapp/main.cpp:18's mention.--device ds4becomes a hard error naminghrx. - Scripts and packaging:
scripts/build-ds4.sh(delete),scripts/package-linux.sh:56,129,
scripts/pack-elf.sh:36,os/v2/mkdebs.sh:98,os/v2/debian/1bit-engine/control:10,os/v2/README.md:62,177,
os/README.md:90(ds4:rocmcontainer),NOTICE:108-111(the antirez/ds4 attribution goes with the code). - Pin machinery:
third_party/ds4+.gitmodules,scripts/weekly.sh:48,tools/weekly_changes.py,
config/ds4-hold.config,.github/workflows/bump-ds4.yml, and the two places that test the hold
(tests/bump_workflow_report_test.py:40WORKFLOWS,:146-152the hold assertions). - Docs:
docs/dwarfstar.md(delete),docs/serve.md:497-498and every--device ds4/--ds4row,
docs/hrx.md,docs/architecture.md,docs/lemonade.md,docs/releases.md,docs/os-v3.md,README.md,
context7.json:22,.pr_agent.toml:43,.github/ISSUE_TEMPLATE/bug_report.yml:45and
model_request.yml:44(dropds4from the device lists). - Route mapping → hrx: the models ds4 claims today — DeepSeek V4 Flash, V4.1 Flash and PRO, GLM 5.2/5.3 Flash,
Qwen3.8-Flash-Next (docs/dwarfstar.md's table) — are HRX's to serve, and two of them are already board rows:
HRX: Qwen3.8-Flash-Next prefill is 287 tok/s on UD-IQ4_XS vs 1,679 for gufo on the same box (and 500-2,400 across published Strix Halo engines) #572 (Qwen3.8-Flash-Next prefill, 287 vs 1,679 tok/s) and HRX route pins ~107 GiB outside process RSS on a 217 GiB mmap (DeepSeek-V4.1 UD-IQ1_S), independent of -ngl/ubatch/prefetch #669 (DeepSeek-V4.1 UD-IQ1_S residency). The strip
does not create that work; it removes the alternative and makes those rows the only path.
1BP packages go with DwarfStar and this issue should say so out loud: they are ds4's format
(app/serve.cpp:309-314, docs/dwarfstar.md), HRX/llama.cpp cannot read them, and after the strip the engine no longer
claims them. Anyone holding a 1BP file needs the ds4 fork as a separate tool, or a conversion, decided separately.
Acceptance
- Stage A (c19): the c19 build produces no
ds4-server/ds4/ds4-bench(scripts/package-linux.sh's
pack_require_toolsdoes not ask for them),weekly.shpreflight is green on a box with no ds4 hipcc, and
1bit serve --device ds4prints the removal message and exits non-zero. - Stage B:
git grep -li "ds4\|dwarfstar"finds nothing outside this issue's own history and the changelog entry;
third_party/ds4,config/ds4-hold.configandbump-ds4.ymlare gone (andtests/bump_workflow_report_test.py
passes with a 4-workflow list); build + ctest green with the submodule uninitialised; NOTICE no longer attributes
antirez/ds4; and one HRX serve of Qwen3.8-Flash-Next (or DeepSeek-V4.1) runs from the same release that dropped ds4 —
the models are not orphaned by the strip.
Related
- Core engine: HRX + HIP + NPU only (strip Vulkan, ROCm, ZINC, CUDA, ComfyUI; move site and kernel out) #306 (closed) — the core strip whose strip 7 kept DwarfStar; this is the follow-on.
- the ds4 pin hold:
config/ds4-hold.config(andbump-ds4.yml's "held" path) — the hold ends with this strip,
which also ends the CUDA-chasing maintenance that caused it. - HRX: Qwen3.8-Flash-Next prefill is 287 tok/s on UD-IQ4_XS vs 1,679 for gufo on the same box (and 500-2,400 across published Strix Halo engines) #572, HRX route pins ~107 GiB outside process RSS on a 217 GiB mmap (DeepSeek-V4.1 UD-IQ1_S), independent of -ngl/ubatch/prefetch #669 — the two HRX rows that inherit these models.
Activity
core: strip the DwarfStar (ds4) route - HIP kernels only (#749)
core: strip the DwarfStar (ds4) route - HIP kernels only (#749)
core: strip the DwarfStar (ds4) route - HIP kernels only (#749)
core: strip the DwarfStar (ds4) route - HIP kernels only (#749) (#770)
bong-water-water-bong commentedon Nov 1, 2026
Reopening and re-scoping to stage B: #770 (
616849a2e, 23:03:34Z) auto-closed this 1 s later via its own reference, and by its own body that PR is stage A only —ONEBIT_DS4defaultOFF, the preflight no longer failing a release for a missinghipcc, and the#ifndefguards that make--device ds4say "this build has no DwarfStar route (built with ONEBIT_DS4=OFF) … run on --device hrx" instead of hunting aPATHbinary.Stage A, as recorded: verified CPU-side only (the box's GPU was down that hour):
bash -nonweekly.sh,app/serve.cppcompiled against the c19 build's own-DONEBIT_DS4_SERVER-less flags. Its artifact half — "c20 ships no ds4 binaries, preflight green without ds4's hipcc" — is proven by the next release build, not by this merge;weekly.sh:52(export ONEBIT_DS4=${ONEBIT_DS4:-OFF}) andCMakeLists.txt:292(option(ONEBIT_DS4 … OFF)) are inmain, so a plain run is ds4-free from here.Stage B — the strip itself — is untouched at
main, checked just now rather than assumed:CMakeLists.txt:292-300(theONEBIT_DS4target +ds4-serverbyproduct)scripts/build-ds4.sh.gitmodules'third_party/ds4entry +config/ds4-hold.config+.github/workflows/bump-ds4.ymlweekly.sh:48)NOTICE:113-116(DwarfStar's notice)docs/dwarfstar.md(+ references indocs/{serve,hrx,architecture,lemonade,releases,os-v3}.md,README.md,.pr_agent.toml,app/main.cpp)app/serve.cpp's ds4 surface (onebp_file(), the--ds4/--ssd-streamingflags, the 1 BP auto-route, the guards)#ifndefsSo "the ds4 route is stripped" is not true yet: it is out of the release path, which is stage A. Stage B is the deletion pass, and the issue body carries the full file list. Keeping this issue as its vehicle rather than letting the auto-close hide it.
bong-water-water-bong commentedon Nov 2, 2026
Closing on stage A, per the owner (2026-11-01 20:30). The deletion pass is split out as #792, sequenced after c20 (bucket C), so nothing is lost by this close.
Stage A shipped:
#770→616849a2e, with#756(packaging keyed onONEBIT_DS4),#736(rebuild/reuse knobs) and#757(docs) ahead of it.ONEBIT_DS4isOFFby default —scripts/weekly.sh:52(export ONEBIT_DS4=${ONEBIT_DS4:-OFF}) andCMakeLists.txt:292(option(ONEBIT_DS4 … OFF)); a plain release run is ds4-free from here.hipcc, and says which knob to use instead;PATHbinary: "--device ds4: this build has no DwarfStar route (built with ONEBIT_DS4=OFF). DeepSeek V4.x, GLM 5.x and Qwen3.8-Flash-Next run on --device hrx", and the same for a1BPpackage that used to route itself to ds4 and fail with "no such file";bump-ds4/*arm stays, commented, because1bit-MONSTER/ds4remains as the reference — it is simply no longer on the release path.What stage A was verified by, stated honestly: CPU-side only —
bash -nonweekly.sh, andapp/serve.cppcompiled against the c19 build's own flags, which is a no-ONEBIT_DS4_SERVERconfiguration, i.e. exactly the path the new#ifndefguards cover. The box's GPU was down that hour, so the artifact half of the acceptance — "the next release build ships no ds4 binaries" — is settled by that build, not by this merge. The c19 packaging half was already there via#756.What did not happen here (all of it now #792): the route is still in the tree —
CMakeLists.txt:292-300,scripts/build-ds4.sh, the.gitmodulesthird_party/ds4entry,config/ds4-hold.config,.github/workflows/bump-ds4.yml,NOTICE:113-116,docs/dwarfstar.mdandapp/serve.cpp's ds4 surface behind the#ifndefs. So "the ds4 route is stripped" is true of the release, not yet of the source.1BP packages go with the strip, which #792 states out loud: they are ds4's format, HRX/llama.cpp cannot read them, and the engine will stop claiming them.
bong-water-water-bong commentedon Nov 2, 2026
Owner decision (orchestrator, 2026-11-01 20:30): stage A closes this issue; the strip itself moves to a new stage-B issue, sequenced after c20. This issue is closed as stage A.
What stage A was, and where it landed: the config/service side merged as #770 → main
616849a2e.scripts/weekly.shnow defaults and exportsONEBIT_DS4=OFF(so build, preflight andpackage-linux.shagree — the packaging break found in review),package-linux.shrequires no ds4 tools, and withONEBIT_DS4=OFFthe--device ds4path no longer quietly hunts for an unshippedds4-server:app/serve.cppanswers "this build has no DwarfStar route (built with ONEBIT_DS4=OFF) … use --device hrx". The release ships HIP kernels only, and c20 asserts it at the artifact (nods4/in the build tree, the refusal string in1bit, nods4entries in the packed tarball).Stage B — the code strip — is now #793, marked post-release, bucket C, blocked until c20 is published. Its body carries the full list you enumerated here (build/config, CLI and routing, scripts and packaging including
NOTICE, pin machinery includingbump-ds4.ymlandconfig/ds4-hold.config, docs, the 1BP statement, and the route mapping to #572/#669), plus your acceptance criteria verbatim in substance — so nothing is lost between the two issues and nothing is re-derived.Reason for the sequencing, as given: c20 is the first candidate that carries the hardware boot + install gate, and nothing may move under it.