Qwen3.8 Flash Next now at 1.2k t/s prefill on Strix Halo
A developer has successfully optimized Qwen3.8 Flash Next on mainline llama.cpp to achieve 1.2k t/s prefill performance on Strix Halo, matching a closed-source solution called Halogen. This improvement involved extensive debugging and optimization, with the developer planning to submit proper PRs to mainline llama.cpp and a community fork. The work also aims to benefit the GLM 5.3 Flash architecture due to similar sparse attention mechanisms.
时间与来源
时间显示为 UTC
显示时区：UTC
本地时区尚不可用，暂时显示 UTC。
发布当时偏移：UTC+02026年9月12日 21:08 UTC
收录当时偏移：UTC+02026年9月13日 15:01 UTC
- 发布
- 2026年9月12日 21:08
- 收录
- 2026年9月13日 15:01
- 来源类型
- 开发者社区
- 档位
- 社区
- 信源状态
- 正常
档位是按信源手工设定的编辑判断，不是逐条打分。
As you all know, Qwen3.8 Flash Next on mainline llama.cpp is still in a pretty experimental stage, but a lot of community forks are trying to get it to work better. There's also a closed-source solution called Halogen (https://github.com/peonist-ai/halogen-flash-server) that boasted 1.2k t/s prefill numbers when the community fork barely reached 400. Since I dislike closed source and I like open source, I decided to take the challenge and bring llama.cpp up to the same performance level and I'm happy to report that after burning through a few evenings and a lot of tokens I got there.
The link contains the (Opus-generated) recap of the entire debugging / optimization journey made, as well as of course the links to the branch, the custom HIP runtime (making a glorious return), a probably-not-working-on-the-first-try installation script and the numbers. I'm trying to also explain the ecosystem - how the mainline, the community forks and custom forks/branches like mine work. Now that I've gotten the result, I'll work on cleaning it up and submitting proper PRs to mainline (will also submit a clean PR to the community fork), this should also help the GLM 5.3 Flash architecture since they use similar sparse attention.