新的推論引擎Gufo 速度可比Halogen 還開源

dardeaw feng

除了高併發更強還開源，實質好處看起來更省VRAM，整個載入只需98GB

基本資料

項目	內容
Repo	`gufo-org/gufo`（github.com/gufo-org/gufo）
建立	2026-08-11；v0.1.0 於 9/28（昨天），v0.1.1 今天
規模	352 stars / 34 forks / 32 open issues，C++20，MIT
目標硬體	只支援 Strix Halo（gfx1151 + 128GB UMA），R9700 沒份
技術棧	直編 HIP kernel（無 Python/Triton/MIOpen）、hipBLAS/rocWMMA、Nix 可重現構建、Podman、OpenAI 相容 API `:8080`
設計參考	llama.cpp + 3 個 Strix Halo fork、vLLM（continuous batching）、shisa-ai hipEngine、antirez 的 ds4

模型吃啥格式（重點）

模型	權重格式	具體檔案	附掛 sidecar
Qwen3.8 27B	GGUF `UD-Q4_K_XL` 或 `UD-Q8_K_XL`	Unsloth `Qwen3.8-27B-GGUF`（pin revision `4ca72078`）	DFlash2 draft：z-lab `Qwen3.8-27B-DFlash2-Q4_K_M.gguf`
Qwen3.8 Flash-Next	GGUF `UD-Q4_K_XL`（多 shard）	Unsloth `Qwen3.8-Flash-Next-GGUF`（pin `38bb39ee`）	MTP：同 repo 的 `mtp-Qwen3.8-Flash-Next-shared-Q8_0.gguf`
DeepSeek V4 Flash	GGUF `IQ2XXS`（w2Q2K + AProjQ8/SExpQ8/OutQ8, imatrix）	antirez `deepseek-v4-gguf` 0731 版	DSpark：同 repo `DeepSeek-V4-Flash-DSpark-support-0731.gguf`
Qwen3-ASR 1.7B	BF16 safetensors	`Qwen/Qwen3-ASR-1.7B`	—
Qwen3-TTS 1.7B	BF16 safetensors	`Qwen/Qwen3-TTS-12Hz-1.7B-{CustomVoice,VoiceDesign,Base}`	—
Qwen-Image-2.1	BF16 完整 pipeline	`Qwen/Qwen-Image-2.1`	進行中
MiniMax H3	BF16（FL2VA）	`MiniMaxAI/MiniMax-H3`	進行中（文生影片/音訊）

跟 halogen 的關鍵差別：

	gufo	halogen-flash
吃的格式	標準 GGUF 直接吃（Unsloth 的 Q4_K_XL 就行）	要轉 `.hgn`（或吃特定 GGUF，n-gram 表還限定 IQ4_NL）
準備成本	`hf download` 兩個檔就開跑	要跑 `convert` 轉檔（~10 分鐘、106GB）
draft/MTP 來源	z-lab DFlash2 Q4_K_M、Unsloth MTP Q8_0	自家 draft head 烤進 checkpoint

效能（gufo 自報，對照 llama.cpp b11069）

Flash-Next Q4_K_XL，單用戶

深度	gufo pp	llama pp	gufo tg (MTP 混合)	llama tg
0	1628	490	32.2	31.7
32k	1422	301	31.0	25.4
131k	1292	145	34.2	14.6

8 用戶併發（MTP）

	gufo	llama.cpp
混合文本	106.5	61.9
重複文本	157.2	58.1

其他

項目	gufo	llama.cpp
載入到 HTTP ready	15.5 s	117.8 s
記憶體佔用	85.6 GiB	84.8 GiB（打平）

跟 halogen-flash 0.14.2 對決

項目	gufo	halogen	贏家
Prefill @32k	1422 t/s	~1227–1417 t/s	gufo（略勝）
單用戶 decode（混合）	32–36 t/s	46–52 t/s（0.14.0 新 draft head）	halogen（+40~60%）
8 用戶併發 + 投機	157 t/s	投機與 batch 互斥	gufo（唯一能做）
1M context	未驗證（262k）	有完整實測（994s/1M）	halogen
開源	MIT 全開	閉源引擎	gufo
權重準備	GGUF 直接吃	要轉 .hgn	gufo
迭代深度	2 個 release（昨天/今天）	40+ 個 release、一年坑都踩過	halogen

結論

多 agent 併發（8 個 subagent 同跑）→ 只有 gufo 做得到
單用戶最順 → halogen 0.14.2 的 decode 還贏一截
長 context（>262k） → halogen 有實測，gufo 未知
注意：gufo 標題的 59.41 t/s 是重複文本 peak，混合文本實際 32–36；數字全自報，還沒第三方複現；太新（兩個 release）
門檻最低：Unsloth GGUF 下載下來直接 gufo serve，不用轉檔 — 值得先裝來跑跑看
我等這幾天迭代穩定後再裝來實測，有人有興趣可以先玩看看

Xiaote

项目定位很明确：只服务 Strix Halo（gfx1151 + 128GB UMA），RDNA4/R9700 不在支持列表里，对独显玩家主要是「看方向」。补两点：

「整机只加载 98GB」不能直接折算成 dGPU 的显存预算——Strix Halo 是 UMA，权重、KV、runtime、系统都从同一块 128GB 里分。换到 32G/48G 独显，要按权重 + KV + runtime 三块分开算，别把 UMA 的数字当单卡容量上限。
项目很年轻（2026-08-11 建库，9/28 才 v0.1.0，v0.1.1 隔天出，32 个 open issues，目标硬件只有一档），先当实验项目跑，别放进生产链路。

它「省 VRAM / 高并发」的底子是直编 HIP kernel（绕开 Python/Triton/MIOpen）+ continuous batching + 可复现构建，这个思路值得跟；但「速度可比 Halogen」要等第三方在相同硬件、同模型同量化下复现再下结论。

terry

有这么神吗？怎么似乎没人关注

dardeaw feng

@terry 開源的代碼拿來研究看能不能改給RDNA3/4測看看

dardeaw feng

為了讓這類專用推論引擎能移植到RDNA家族，這是我啃了它十五個 kernel 後。gufo 快不是一個絕招，是十層疊起來的「零浪費」哲學：

讓它快的關鍵（按影響排序）

1. Dequant 永遠不落地（最大的一塊）
權重以 int8 進 WMMA，scale 只在最後乘一次——fp16 權重從不存在於記憶體。llama.cpp 系是先解量化成 fp16 再算（頻寬翻 2~4 倍）。這就是為什麼 Q3_K_M 跑出 310GB/s 有效頻寬：它真的只讀了 13GB。

2. 什麼都 fuse

RMSNorm＋量化 activation：一遍搞定（FusedRMSNormQuantizeQ8_1）
SwiGLU：gate＋up＋激活函數一個 kernel（BlockedSwiGLUFp32）
Attention：QK^T＋softmax（online 跑 max/sum）＋P×V 全在 LDS 裡轉完，S 矩陣不出片
每 fuse 掉一次就省一整輪 VRAM 讀寫——decode 這種 memory-bound 場景直接變速度

3. 一個形狀一種 kernel，不做通用

small batch、prefill、wave64 是三套獨立 kernel（small_batch_wave64、prefill_quant、w8a8），不是一個 kernel 加 if。這就是它目錄爆炸的原因，也是它快的原因——每個 kernel 的 tile、occupancy、swizzle 都是為那個形狀手調的
全 constexpr＋static_assert：head_dim、GQA 數全是編譯期常數，runtime 零分支

4. WMMA 玩到極致

hand-written wave32/wave64 fragment，LDS swizzle 避 bank conflict（LoadSwizzled 那套），launch bounds 壓 occupancy——我在移植時看到的每個常數都是調過的
整數 dot 走 wmma.i32（Q8 累加 32 位，精度還比 fp16 好）

5. 零框架稅
沒 torch、沒 ggml graph dispatch——C++ 直接 launch kernel，權重一次 hipMalloc 常駐，scratch 重用，session 預分配。llama.cpp 的 graph 開銷在它這裡是零。

6. 推測解碼雙保險（qfn 有 ngram.cpp＋MTP）：n-gram Lookup＋小模型 draft 兩路並行，decode 少跑好幾次大模型。

7. Strix 紅利（不可移植）：gfx1151 調校＋128GB 統一記憶體零拷貝——這部分是作弊，換硬體就沒了。

哪些概念能搬去別的引擎

概念	可搬性	說明
dequant-in-register（永不落地）		任何 memory-bound 引擎吃了都快，llama.cpp 最該抄
norm+quant+GEMM fuse		純工程活，無硬體依賴
online softmax＋S 不出片		FlashAttention 已在做，gufo 版更激進
形狀特化 kernel（小 batch 獨立路徑）		要維護成本，llama.cpp 的 `mmpq` 方向類似但沒這麼絕
speculative 雙 draft		n-gram 表那套很便宜，人人可抄
WMMA fragment 手調		綁架構（我現在手上有 gfx1151＋gfx1201 兩套 mapping，要的拿去）
統一記憶體假設		別學，會死（問我怎麼知道的）

一句話總結

gufo 的哲學是：把「通用」當成敵人——通用格式、通用 kernel、通用框架，每個通用都收稅；它一個個手寫收回來。這套在它能覆蓋的模型上無敵，代價就是新模型新架構要重寫一遍。

抡锤者