Not everything investigated for halo gets adopted, and the reasons why are often more useful than another adoption story. Three items from the recent research pile: two dead ends worth knowing about, and one unfreeze that was pure win.

DwarfStar: real support, wrong backend

DwarfStar (antirez/ds4) is Salvatore Sanfilippo's local inference engine, 22,000+ stars, built primarily for the DeepSeek V4 family. It came onto the radar because of a recollection of impressive Qwen3.8-Flash-Next numbers floating around - and the support turned out to be real: a merged PR adding native qwen4exp support, benchmarks through 262K tokens, actively maintained.

Two catches. First, the backend: at investigation time the model's dedicated kernel graph was documented as Metal-only, and while the engine has since broadened (it now targets Metal, CUDA and ROCm generically, with the Flash-Next path on Metal and CUDA), there is still no ROCm implementation of this model's kernels - and halo is a ROCm/Vulkan box. Second, the packaging: DwarfStar's Flash-Next builds run 137-165 GiB on disk with a 95 GB n-gram table read straight from the GGUF, a fundamentally heavier shape than our ~35 GB quant plus a 4 GB sidecar. A well-built project that simply is not for this hardware yet. Worth a re-check when the backend matrix grows; not before.

The meta-lesson from how this was investigated: the first research pass reported the ds4 PR as "still open, weak numbers". An independent gh pr view showed it had merged the day before, with materially different numbers than reported. Never trust a single research pass on anything that will inform a real decision - a rule this blog has now paid for and been paid by several times.

DiffusionGemma: served by vLLM, not by llama.cpp

DiffusionGemma is Google's experimental text-diffusion take on Gemma-4: the same 25.2B/3.8B-active MoE backbone, fine-tuned into a block-diffusion model. Instead of predicting one token at a time, a causal encoder reads the prompt and a bidirectional decoder iteratively refines a 256-token block, roughly 12 forward passes per block and ~20 tokens per pass - Google cites ~1,500 tok/s on a single H100. Genuinely different decoding economics, which is exactly why it's interesting for this hardware class.

The catch for halo is where the support landed. vLLM serves it natively. llama.cpp does not: support lives in an unmerged draft PR that adds a dedicated llama-diffusion-cli binary, and llama-server - the OpenAI-compatible path this whole box's architecture depends on - fails on the model with an unknown-architecture error on both ROCm and Vulkan. There's even a public failure report from another Strix Halo box hitting exactly that, and the community workaround is a Python proxy that shells out to the CLI. A one-off CLI behind a proxy is a demo, not a route.

So the accurate status: the serving path exists, it just lives in vLLM, and halo's entire stack is llama.cpp. Filed under revisit-when-llama-server-support-lands, which I'd say is the correct amount of enthusiasm for a model this box can build but not serve.

The ROCm 10 unfreeze

The quiet win of the batch. Halo's production ROCm container had been frozen at a six-week-old llama.cpp build since early August, pinned there to dodge a HIP integrated-GPU corruption bug (#25992) whose complete fix never merged. Then kyuz0's toolboxes moved to ROCm 10, where gfx1151 graduates from tolerated to an AMD-packaged, officially supported target, with the workaround baked in.

Evaluated with the usual paranoia before touching production: the corruption symptom exercised directly (8/8 concurrent distinct prompts, no cross-contamination), then a speed A/B against a freshly-taken baseline on the frozen build, not stale historical numbers. Result: prefill +10.8% at 8K depth and +17.5% at 16K, decode flat. For a box whose stated priority is prefill at depth for coding agents, that's the right win in the right place, for free. Adopted; the frozen container stays on disk as rollback.

One migration note for anyone following the same path: the new builds have removed --no-mmap outright in favour of --load-mode, which breaks any script that hardcodes the old flag - including, at time of writing, the strix-halo-optimize bench scripts on this class of toolbox. Flag shims needed; the skill's findings log has the details.

Three investigations, one adoption. The ecosystem moves fast enough that the dead ends of September are worth re-checking by November - which is, I suppose, exactly why the journal exists...