早先有發了一個帖子是講ROCmFP4的llama.cpp分支，有興趣的可以去參考
但更早之前我有試著在這台迷你主機配置過SGLang，我都是用Opencode內建MuseSpark 1.3免費版去做配置，全程沒有任何蛋疼過程

SGLang on AMD Ryzen AI Max+ 395（Strix Halo）部署與效能實測全記錄

實測平台：FEVM FAEX1（AMD Ryzen AI Max+ 395 / 64-128GB UMA / ROCm 7.2.4）
目標模型：Qwen3.8-27B（GPTQ-Int4 + MTP Heads）
架構定位：Linux 推論 Server（Fedora）提供 OpenAI 相容接口（:8081/v1），Windows 用戶端透過 OpenCode 遠端掛載。

---

1. 軟硬體環境與關鍵認知

1.1 硬體規格配置

項目	規格參數	架構限制與關鍵說明
APU	AMD Ryzen AI Max+ 395	gfx1151（Radeon 8060S，40 CU），ROCm 7.2.4
VRAM	68.7 GB（BIOS Carve 固定）	開機即鎖死，進入 OS 無法動態重劃。
Host RAM	62 GiB 實體記憶體 + 76 GiB Swap	UMA 共用同一實體記憶體池，Host 與 GPU 存在資源爭搶風險。
同機其他服務	lemonade（NPU 專屬）	監聽埠 13305，不佔用 GPU VRAM；llama-router 已停用。

️ 核心硬體認知（UMA 邊界限制）：
UMA 架構不等於「VRAM 不足時能無痛借用 Host RAM」。BIOS Carve-out 大小一旦決定即為硬上限，PyTorch 的裝置記憶體配置器（Device Malloc）無法溢出至 GTT。68.7 GB 是絕對硬上限，所有權重載入、KV Cache 與運算圖配置均以此邊界為基準。

1.2 軟體環境建置

• SGLang 核心分支：專為 gfx1151 移植之社群 Fork（整合 gfx1151 架構補丁、C++20 編譯修正、MoE Kernel 修正，並順利通過 AOT sgl_kernel 編譯）。
• Python 虛擬環境：獨立 Python 3.12 虛擬環境（Torch 2.14+rocm7.2、Triton 3.8.0），SGLang 採 Editable 模式安裝。
• 模型套件：Qwen3.8-27B GPTQ + MTP Heads（已修正 MTP Config，使 Draft Path 指向同層目錄）。

---

2. 產線定案啟動配置

2.1 一鍵啟動指令

#!/usr/bin/env bash
python3 -m sglang.launch_server \
  --port 8081 \
  --served-model-name qwen3.8-27b \
  --tp-size 1 \
  --quantization gptq \
  --kv-cache-dtype fp8_e4m3 \
  --dtype bfloat16 \
  --attention-backend triton \
  --context-length 262144 \
  --mem-fraction-static 0.55 \
  --max-running-requests 4 \
  --speculative-algorithm EAGLE \
  --speculative-num-steps 5 \
  --speculative-eagle-topk 4 \
  --speculative-num-draft-tokens 8 \
  --default-chat-template-kwargs '{"enable_thinking": false}' \
  --tool-call-parser qwen3_coder \
  --sleep-on-idle

• 常駐機制：透過 systemd 服務常駐管理。
• 記憶體配額：模型權重＋靜態 KV Cache 佔用約 51 GB，預留 17 GB 作為動態請求與系統緩衝。

---

2.2 核心參數設計理由

參數設定	數值 / 選項	設定理由與技術依據
--context-length	262144 (262K)	為超長歷史對話與程式碼庫預留天花板；64K 內載入耗時可接受。
--mem-fraction-static	0.55	安全防線。數值若再提高，權重＋動態 KV＋運算圖將直接擊穿 68 GB 邊界引發崩潰。
--kv-cache-dtype	fp8_e4m3	實測已驗證可用。KV 佔用空間直接減半，是 262K 極限上下文能夠落地的物理前提。
MTP 組合參數	5 / 4 / 8<br>
<br>(steps/topk/tokens)	針對 Code / JSON 場景最佳化，實測平均接受長度達 3.9～4.8 tokens，推測解碼增益顯著。
--default-chat-template-kwargs	{"enable_thinking": false}	Agent 與編程輔助場景不需要思考鏈，關閉可省去無效 Token 浪費並大幅降低延遲。
--tool-call-parser	qwen3_coder	若使用通用 qwen parser 會吞掉 Tool-call（經 get_weather 回歸測試驗證確定修復）。
--max-running-requests	4	實測 4 併發時 Decode 總吞吐達單路 2.2 倍，剛好壓榨滿 APU 頻寬；更大隻會增加排隊延遲。

---

3. 地雷導航與避坑指南（重大踩坑複盤）

避坑 1：嚴禁啟用 HiCache（Host 記憶體自毀死循環）

• 現象：設定 --hicache-size 20 鎖定 20 GB Host RAM，但在模型加載時 Host 端自身也需十數 GB 空間。
• 後果：62 GB 系統實體記憶體瞬時見底，觸發 Linux OOM-Killer 強制中斷，systemd 隨後重啟服務，陷入全機死循環卡死。
• 教訓：在 UMA 架構下，Host RAM 與 VRAM 實質為同一實體池，開啟 HiCache 等同於「左右手互搶記憶體」，嚴禁開啟。

避坑 2：Adaptive MTP 效益低且佔資源

• 現象：使用 --speculative-adaptive 會被底層強制設定 topk=1（與靜態 topk=4 互斥）。
• A/B 實測對比：自適應模式為 20.9 tok/s，靜態配置則達到 21.4 tok/s。寬推測樹（Tree-based）的收益明確高於動態步數，且自適應模式冷啟動更慢、佔用更多 VRAM。

避坑 3：Quark AWQ MXFP4（safetensors）是硬體死路

• 現象：缺少 aiter 時拋出 NotImplementedError；編譯安裝 aiter 後，源碼中 is_fp4_avail() 白名單明確僅支援 gfx950 與 gfx1250。
• 本質：gfx1151 晶片層面缺乏硬體級 FP4 WMMA 張量指令，任何純軟體模擬方案皆無法繞過此物理限制。

避坑 4：連接埠與顯存互斥衝突

• 規範：連接埠 8080 保留給 llama 生態，SGLang 獨佔 8081。
• 維護原則：切換推論引擎前，必須先停止另一側服務，並透過 rocm-smi 確認 VRAM 佔用從 41GB～51GB 徹底回落至基準狀態（約 0.6 GB）。

---

4. 效能實測數據（代碼／JSON 密集場景）

測試基準：全部輸入與輸出均為 Code / JSON 格式，數據取自 API 返回之精確 usage 欄位。

4.1 Prefix Cache 命中效益（6K Prompt）

測試情境	首字延遲（TTFT）	效益解析
冷啟動預填充（Cold Prefill）	17 ～ 68 秒	需完整計算 Attention 矩陣與權重解包
完整重複 Prompt（Cache Hit）	~ 1 秒	透過 Radix Tree 秒級載入，幾乎免去重複運算

4.2 MTP 推測解碼接受率（Server Log 統計）

• 運作配置：靜態 topk=4（現行定案）
• 平均接受長度（Accept Length）：3.9 ～ 4.8 tokens
• 整體接受率（Accept Rate）：0.41 ～ 0.55

---

4.3 單併發 Prefill 吞吐階梯（2K → 64K）

Prefill 速率變化 (tok/s)
  600 |
  500 |             [4K 峰值: 504.4]
  400 |     [2K: 369.7]     [8K: 390.1]
  300 |                             [16K: 266.2]
  200 |                                             [32K: 140.2]
  100 |                                                             [64K: 112.6]
    0 +-------------------------------------------------------------------------
      0      8K     16K     24K     32K     40K     48K     56K     64K

上下文長度	SGLang 預填充速率	實測 Wall 耗時	運算狀態與架構特性分析
2,000 (~2K)	369.7 tok/s	6 秒	初始階段，計算核心利用率逐步爬升
4,000 (~4K)	504.4 tok/s	8 秒	效能甜蜜點，GEMM 矩陣計算達到完全飽和
8,000 (~8K)	390.1 tok/s	22 秒	開始受限於注意力機制運算負擔
16,000 (~16K)	266.2 tok/s	61 秒	序列拉長，記憶體搬運開銷逐步主導
32,000 (~32K)	140.2 tok/s	233 秒	Attention $O(N^2)$ 計算特性導致速率明顯下滑
64,000 (~64K)	112.6 tok/s	580 秒	載入需近 10 分鐘，長文本必須依賴 Prefix Cache 攤平開銷

---

4.4 生成吞吐（Decode）與高併發壓力測試

單併發解碼（256 Tokens 生成，代碼情境）

• SGLang 單路輸出：28.9 tok/s
  (備註：常規散文寫作約 ~21 tok/s；程式碼的高結構性與重複語法使 MTP 享受到顯著的猜測紅利)

高併發擴展（Concurrency = 4）

測試指標	實測總吞吐	併發擴展效益分析
Prefill 4 路總量（10.5K × 4）	307.2 tok/s	高於單路長文本速率，Chunked Prefill 機制排程發揮成效
Decode 4 路總量（256 × 4）	63.3 tok/s	達到單路吞吐的 2.2 倍，APU 記憶體頻寬在此完全飽和

---

5. 推論引擎對決：SGLang (GPTQ) vs. ROCmFP4 (llama.cpp Fork)

對照組環境：
ROCmFPX Fork（自訂 GGML Type 100–106，Strix 專用解量化路徑）＋ Qwen3.8-27B Q4_0_ROCMFP4（13.7 GB）＋ MTP Draft，Context 131072。

評測維度	SGLang (GPTQ + FP8 KV + MTP)	ROCmFP4 (llama.cpp Fork + MTP)	核心差異與架構優劣總結
Prefill 峰值	504.4 tok/s（4K 達成）	437.7 tok/s（16K 達成）	SGLang 在中短 Prompt 依賴 Triton Kernel 算力飽和度更高。
Prefill 64K 長文	112.6 tok/s（580 秒）	240.2 tok/s（272 秒）	ROCmFP4 快 2.1 倍；llama.cpp 的 C++ 原生分塊對超長文本搬運耗損更低。
Prefill 4 路併發	307.2 tok/s（併發不崩）	259.3 tok/s（低於單路）	SGLang 的 Chunked Prefill 排程極佳；llama.cpp 會出現排隊阻滯。
單路 Decode	28.9 tok/s	29.0 ～ 44.0 tok/s	ROCmFP4 領先約 50%；純 C++ 與專屬對稱微區塊使逐字搬運延遲更低。
4 路 Decode 總量	63.3 tok/s	62.0 tok/s	兩者打平；均撞上 APU 實體 256-bit 記憶體頻寬物理天花板。
磁碟與顯存模型體積	~19 GB	~14 GB	ROCmFP4 具備更極致的減重優勢，可省下約 5 GB 實體空間。

---

6. 一句話決策總結

• 選用 SGLang (GPTQ + MTP)：適合 高併發多人調用、多輪 Agent 密集對話，依賴其強大的 Radix Prefix Cache、Chunked Prefill 與成熟的 OpenAI API 生態。
• 選用 ROCmFP4 (llama.cpp Fork)：適合 單人極限吞吐、超長文一次性分析（>32K），可享有快 2.1 倍的長文本預填充與高達 40+ tok/s 的單路打字機極速。

SGLang最大的好處無非就是Radix Tree
相比llama.cpp的slot cache，Radix tree的token級快取還是比較細膩，多對話還可以更節省KV Cache
但SGLang缺點也是很明顯....就是肥，要不是我有這大VRAM玩具，不然本地部屬單人使用還是llama.cpp為主就夠了
以這主機來說，算力、帶寬、生態等瓶頸就擺在那，真的要強求高併發並不是它設計的場景，
如果有想要以AMD平台設置推論引擎應該還是預先裝llama.cpp能玩廣大的通用gguf再說，各位參考

兩天，我想自己寫一個推論引擎去挑戰HaloGen，結果差得遠，但也把 AMD 的底給摸了一遍

環境

AMD Strix Halo：Ryzen AI Max+ 395 + Radeon 8060S（gfx1151 / RDNA3.5）
124G 統一記憶體（CPU/GPU 共用）；BIOS carve 只留 512M VRAM，其餘走 GTT
NVMe 資料碟（/mnt/nvme-data：模型、ROCmFPX、llama.cpp fork）
系統與驅動 Fedora + ROCm 7.14（llvm-objdump/hipcc 解剖刀）、amd_iommu=off
LLM推論引擎：halogen-flash 0.6.3版、llama.cpp

起點：一開始只在乎Decode速度體驗

痛點：Prefill的落差太大

事情是這樣開始的——去年底DDR5價格起飛，我趁小主機還沒受影響前在淘寶搞了一台AI Max+ 395，當時只是拿來做本地聊天也挺順暢的，今年開始AI Agent大火，但影響 AI Agent 最大的體驗瓶頸，往往是讀指令、讀輸出、爬文、爬代碼等，是屬於 prefill 速度，反而輸出的比例遠少於輸入的 token 數量。雖然 AMD 能利用內存帶寬在 decode 速度追上了老黃，但 prefill 速度卻遠低於同等級 N 卡，尤其長文本衰退更趨明顯。即使用了增量快取如llama.cpp的prompt-cache 或是 sglang的radix tree 等技術可以緩解這樣的瓶頸，但治標不治本，對於增量的部分就是比較痛苦，尤其在累積較長的上下文後要模型去網上爬文簡直要命。

近期我開始注意到社群裡有個叫 halogen-flash-server 的閉源專案，作者 peonist-ai 利用AI寫了一套針對這顆晶片的自製推論引擎，效能遠超官方 ROCm 路徑。這個發現讓我動了一個念頭：既然有人能透過AI Agent做到，那我能不能也試試看，自己動手改一套推論引擎？

於是找了幾個 AI 工具幫忙（Claude 5 Fable產生計畫書，是 Muse Spark 1.3 負責動手實作，Gemini flash 3.8後期提供了完整的分析計畫跟數據翻譯），開始了這兩天的折騰。

更大的背景：這不是單一台機器的問題

其實會一路查下去，不只是因為 Strix Halo 這台機器，而是因為我另外一張獨立顯卡 RX 9070，拿去跟同世代的 RTX 5070 比，長文本推論（prefill）速度也是輸得很難看——這不是個案，是 AMD RDNA3/RDNA4 這整個世代，在 LLM 推論這個特定負載上，普遍輸給同世代 NVIDIA 老遠的現象。

先把客觀規格攤開來看，不是空泛地說「輸」，是真的輸在哪一塊，我們扣除掉NVFP4的特殊加速格式：

拿 RX 9070 XT 跟 RTX 5070 比，兩者的基礎算力（FP32，一般著色器運算）其實 AMD 還略高一點（約 49 TFLOPS vs 31 TFLOPS，AMD 領先）。但只要看向「張量矩陣運算」（AI/Tensor Core）這一塊，AMD 的 FP16 張量運算約 144.5 TFLOPS，NVIDIA 約 123.5 TFLOPS。

LLM 推論裡的 prefill（處理輸入文字的階段），幾乎全部是矩陣乘法跟注意力運算，吃的正是這塊張量核心，不是一般的著色器算力。AMD 在「一般運算」上不輸甚至略贏，但在「LLM 最依賴的那一種運算」上，或許沒那麼簡單。

除了張量核心規格本身，還有兩個結構性的原因，加起來讓實際使用時的差距比規格表看起來更誇張，所以主要優化的方向也朝這走：

• 搬資料的方式比較笨重：NVIDIA 從幾年前的架構開始，就有一套硬體層級的「背景搬運」機制(cp.async)，可以讓資料在運算的同時，自動從主記憶體流向晶片上的高速暫存區，不用佔用運算單元的時間。AMD RDNA 這幾代消費級卡沒有對應的硬體機制，資料要搬運，得老老實實地讓運算單元自己動手去搬，這在處理長文本的大矩陣運算時，會產生大量「等資料到位」的空檔，運算單元沒辦法一直保持忙碌。
• 軟體生態系起步較晚、火力較分散：NVIDIA 那邊的底層函式庫，已經被業界磨了好幾年，各種量化格式、各種模型架構都有現成調校好的版本可以直接用。AMD 這邊的對應工具鏈，相對年輕，而且官方資源優先投入在資料中心等級的晶片上，消費級顯卡跟這種 APU 產品，能分到的官方調校資源少很多——這也是為什麼這兩天我查出來的東西，大部分打雜指令的問題，某種程度上反映的是「官方還沒空好好優化這個特定情境」，不是「這件事做不到」。
• 那RDNA4比RDNA3進步在哪呢?：主要還是遊戲表現，像是光柵引擎與光追單元的效能提升，另外RDNA4起多了支援FP8量化格式，讓RDNA4世代能透過fallback運作MXFP4的量化模型。

搞清楚這個大背景之後，我才決定拿 Strix Halo 這台機器，認真試試看能不能靠自己動手，填補一部分這個差距。

先搞清楚差距有多大

以同一台機器AMD Strix Halo平台下跑分測試對照，我測試的對象是 Qwen3.8-27B（dense 模型架構，混合注意力層）。在 32K context 下，我自己跑的 llama.cpp stock 版本 prefill 速度是 263.5 tok/s，halogen 那邊實測是 570.4 tok/s——差了 2.17 倍。同場加映：

檔位	llama.cpp stock	halogen	倍率
pp8K	317.8 tok/s	634.9 tok/s	2.00x
pp32K	263.5 tok/s	570.4 tok/s	2.17x
pp128K	137.6 tok/s	382.2 tok/s	2.78x

注意最後一行：差距隨深度拉大——這條曲線後面會成為關鍵線索。

這裡要澄清一個容易搞混的地方：halogen 官方展示的另一個更誇張的數字（1424 tok/s，約 4 倍差距）是跑在另一個模型 Qwen3.8-Flash-Next 上，那個模型用了 512 專家的 MoE 架構，每個 token 只需要算一小部分參數，運算量本來就少很多，不是同一個擂台，不能直接拿來比。我這次挑戰的，是相對公平的 27B dense 對照。

第一步：先看看官方路徑到底把時間花在哪

沒有亂猜，直接把官方 llama.cpp 跑 Q5_K 量化的核心運算（MMQ）利用SASS組合語言解包，一條一條指令去數。整顆 kernel 1724 條指令裡，真正在做矩陣運算的只有 32 條（約 2%，聚焦熱區則約 7%）。結果發現：

• 剩下六成多（62%）的指令，都在處理量化格式的「拆包」——把壓縮過的權重數字，即時解開、搬到對的位置、換算成能運算的格式
• 暫存器用量 81，是健康線 32 的 2.5 倍，導致 GPU 沒辦法同時排進足夠多的工作，進一步拖慢速度

簡單講：真正幹活的部分被一大堆「打雜」的指令包圍，張量核心根本沒吃飽。單算子實測：ffn_up 形狀只跑出 21.0 TFLOPS，紙面峰值 59 的三成六。

野心勃勃的完整規劃：三層自研引擎架構

看到這個發現，我一開始很樂觀，覺得既然問題找到了，那乾脆不要只是修修補補，直接規劃一套完整的自研引擎架構，三層疊起來：

┌────────────────────────────────────────────────────────┐
│  排程層：Radix Tree 前綴快取（Prompt Caching）          │ ── 命中時直接跳過重算，秒回第一個字
└──────────────────────────┬─────────────────────────────┘
                           │
┌──────────────────────────▼─────────────────────────────┐
│  記憶體階層管理：統一記憶體動態換出 / 回收              │ ── 榨乾這台機器的大容量記憶體，長文本不爆
└──────────────────────────┬─────────────────────────────┘
                           │
┌──────────────────────────▼─────────────────────────────┐
│  執行底座：量化格式直灌張量核心的專用運算核心          │ ── 幹掉打雜指令，直接餵飽張量運算單元
└────────────────────────────────────────────────────────┘

• 排程層（前綴快取）：多輪對話或代碼助理這種場景，常常會有重複的開頭內容（系統提示詞、共用的上下文）。做一個前綴共享機制，命中過的內容直接跳過重算，理論上能讓重複場景的等待時間大幅縮短。
• 記憶體階層管理：這台機器記憶體特別大，規劃讓常用的資料留在高速區域，不常用的分支往外挪到系統記憶體甚至硬碟，讓長文本、多工作階段可以撐得比一般消費卡更久。
• 執行底座（核心挑戰）：既然已經找到「打雜指令太多、張量核心沒吃飽」這個病灶，那就設計一套專用的運算格式——在模型載入的時候，先把量化過的權重資料在 CPU 上重新排列好、攤平，讓格式直接對齊硬體讀取的方式，執行的時候不用再即時去拆解、換算，直接把資料灌進張量運算單元。當時抓到一個細節：那個「拆解、換算」的動作，理論上重排後幾乎不用花時間（實測 repack 吞吐約 277 GB/s，佔用時間微乎其微）——照這個邏輯算，把這一大塊打雜指令消滅掉，矩陣運算的效率應該能從原本的水準往上跳一大截。

這套規劃聽起來很完整，野心也很大，花了一整天編譯測試、編譯測試數十次後的結果——

現實給的第一巴掌：野心最大的那塊，反而摔得最重

三層規劃裡，前兩層（前綴快取、記憶體管理）算是設計文件層級的東西，還沒真正投入大量時間去實作；真正花時間動手做的，是第三層（執行底座）那個「重新排列量化格式，直灌張量核心」的專用運算核心。

這是整個自研計畫裡最有信心的一塊——理論算得漂亮，格式重排的成本理論上趨近於零，消滅打雜指令換來的效能提升，理論上該是最大的一筆。

結果做出來上機一測：ffn_up 從 3947 微秒變成 4195（慢 6%），ffn_out 從 4142 變 4360（慢 5%）——比什麼都不改的原始版本還慢。

這一下摔得挺重的，原本以為找到的病根、算出來的帳，竟然完全兌現不了。回頭拆開來查才發現三個問題疊在一起：

1. 省下來的那些指令，其實原本就藏在記憶體等待的空檔裡，根本沒有真的拖慢速度，砍掉它們自然也不會有感覺；
2. 重新排列後的資料格式反而變胖了——每行 288 位元組 vs 原來 176，胖了 64%，多花的記憶體頻寬，比省下來的運算時間還要多，得不償失；
3. 量化格式裡有一段數學運算，本質上沒辦法簡化——原本以為 scale 可以提出來一次算好、重複使用（Post-scaling），但仔細算過才發現兩個 scale 都隨循環變數變化，沒有公因子可提，是個死巷子，每個元素都得個別算，沒有捷徑。

這才是這兩天最挫折的一個時刻——不是一個小失誤，是整個計畫裡最被寄予厚望、算得最有把握的那一塊，徹底摔了個大跤。

接下來一連串，野心勃勃的三個計畫，一個一個被現實打臉

除了執行底座這個大摔跤，接下來嘗試的其他方向，也幾乎每一項都被推翻：

• 懷疑排程效率是主因——開同步模式（HIP_LAUNCH_BLOCKING=1）重測，pp8K 跑出 332.5，反而比正常的 317.8 更快，證明 launch overhead 根本不是瓶頸，真正的瓶頸在矩陣運算本身的效率太低；
• 拿現成調校工具（hipBLASLt）想要優化矩陣運算，單算子從 21.0 量到 33.4 TFLOPS（1.59x），理論上該起飛——結果上機實踐（Q5_K repack）反慢 5~6%，端到端 pp512 也掉了約 2%。因為比較方式漏算了隱藏開銷：純粹局部執行時量測出數字沒含格式轉換與多出來的頻寬帳，端到端一算，1.59x 兌現不了；
• 想省掉重複讀取的浪費——GDN staged kernel 寫完、正確性沒問題，但收益從沒兌現（env 門都沒開）；KV 轉 q8 測完 320.2 vs 317.8，純誤差範圍，直接關閉。直覺上會認為 GPU 核心反覆向顯存請求讀取了同一個變數高達 32 遍，造成了嚴重的頻寬浪費；但實際去寫 Kernel 想省掉它時，才發現這段浪費早就被硬體快取接住了；
• 想解開 MMQ occupancy 上限、fattn tile 這類看似隨手的參數限制——一放開就跑出錯誤數值，後來才發現這些限制底下是沒修好的硬約束（fattn 的 head_dim=256 上不了 tensor 路徑、MMQ 的暫存器形狀），是道承重牆，不能亂動，只好原樣焊回去；
• **既然 WMMA256 跑不動、但現成的 WMMA-128 跑得很順，那我能不能把維度為 256 的向量直接「一刀切成兩半（前半部 128、後半部 128）」？分開丟進兩個 WMMA-128 算，算完再拼起來，不就繞過硬體限制了？但Muse Spark提醒我，把兩半個別算完 Softmax 的結果就算拼回去或加起來，在數學上根本不等於原本「完整的 A+B 算出來的 Softmax，及時懸崖勒馬，零成本撤回，沒有浪費工夫去真的實作。

最後，靠著幾個零碎的參數微調（MMQ occupancy 候選 + tile nbk64 + 關 IOMMU），兩天下來總共拿到了 10.4% 的實測效能提升（pp8K 317.8→345.2，pp32K 263.5→290.9），把差距從 2.17 倍收斂到 1.96 倍。不是無效，但離「自己做出一個能打贏對手的引擎」還遠不夠看。

轉念：與其自己硬幹，不如先看看對手做了什麼

眼看自己這條路已經摸到天花板，我連27B的挑戰都搞不過，更何況更難的125B-Flash-Next，乾脆換個角度——把 halogen 的執行用SASS拆開，看看裡面組合語言層級的指令成分長什麼樣子，這中間又讓AI Agent持續執行、解包、數字解析、翻譯理解等循環又花了我一天的時間。

手法：podman pull 拉容器 → 匯出檔案系統 → 引擎 binary 裡的 .hip_fatbin 段 → 切出 HSACO → 反彙編。0.1.3 版 8 個 code object，0.6.1 版 3 個、1047 個 kernel，全攤開。

要先講清楚一件事：這不是「反組譯出原始碼」，更不是破解或竊取——這只是看執行檔被編譯成什麼樣的底層機器指令，跟看一棟房子的磚頭怎麼疊沒有本質差別，看不到設計圖、看不到背後的邏輯，只能看到最後蓋出來的成品長什麼樣。

看完之後，有幾個觀察到的現象：

觀察到的：

• halogen 的核心運算（k_gemm_i4，熱區 298 條指令裡 128 條是 WMMA、佔比 43%），張量運算指令跟打雜指令是 0.5:1，官方路徑是 5:1——打雜佔比低一個量級；
• 它用的是一條查不到公開文件的整數矩陣運算指令 v_wmma_i32_16x16x16_iu4——注意是 iu4 不是 iu8，單條做 8192 個乘加，是官方那條 iu8 的兩倍。攤到每個乘加操作，halogen 的打雜只有官方的 1/43；
• 暫存器用量 ~238（VGPR）+ ~48（SGPR），遠超一般教科書建議的安全範圍（32），這通常會讓 GPU 沒辦法同時排很多工作，但看起來作者是刻意這樣做——熱區 128 條 WMMA 深度展開，換取單一工作內部連續執行更多指令，用超長直線程式碼蓋住記憶體延遲，不用頻繁切換等待；
• 從記憶體存取模式判斷，0.6.1 世代的手寫 linear 全是純 ALU（給 decode/小矩陣），prefill 主力是解包 kernel + 調優庫兩遍式——權重資料可能在載入時就先重新排列過，執行時不需要再做即時的格式轉換（0.7.0 起官方也親口說 BYO-GGUF 會無損重排，可互相印證）；

以下AI Agent順便去爬文作者的ChangeLog:

• Flash-Next 專用系統級調度(0.6.3版)：MoE 計數排序與 NVMe 並行讀表:針對 Qwen3.8-Flash-Next 版本，對手進一步實作了開源框架完全不具備的系統級優化，Qwen 的 47.7 GiB 查N-Gram找表不進 RAM而擺SSD，改用 Linux page cache。以 CPU開64 線程平行聚合讀取，將長 Prompt 讀表時間從單執行緒的 50 秒壓制到 1.3 秒 。
• 一整套Decode加速專用的Drafter(0.5版)：作者poenist.ai自己搓了一個 MTP head fine-tune、另一個 DFlash2，block drafter，5 層 ~2.2B 參數，讓MOE架構下也能讓接受率達到97%以上。
• 注意力層面的動態微區塊剪枝(0.1版)：手刻 QSA Micro-block 稀疏Qwen3.8 原生架構是「3:1 混合注意力」（75% 線性 GDN + 25% 全量 Attention）。開源框架在面對那 25% 的全量層時硬算 O(N^2)，在 128K context 下 Attention 吃掉 65% 時間，從指令模式判斷（k_attn_sel：613 條、零 WMMA、26 個數據依賴分支，輸出索引；k_attn_qs_bt* 幾十個變體吃 int* block 索引；k_attn_fa2 模板參數就叫 FaSel），它針對長文本的注意力計算做了動態 block 篩選，跳過不重要的部分，而不是每個 token 都跟所有歷史硬算一遍——這也能解釋為什麼差距隨深度拉大（128K 差 2.78x）：GEMM 調優只能給全段固定倍率，越拉越大的那截全是 attention，但這QSA推論引擎可靠嗎?

推論引擎級的QSA精度有沒有偷工？這部分我真的自己動手測了。

如果 halogen 真的靠「跳過部分計算」來加速，會不會犧牲了準確度？這個不能靠猜，得自己動手驗證。

我寫了幾個測試腳本，直接對它的線上服務做壓力測試（每次填充文隨機生成，防它的 prompt cache 作弊）：

• 在很長的文本裡（16K/32K/64K/128K 四檔 × 深度 5%~95%），埋入隨機的識別碼，測試模型能不能準確找回來——52 次測試，52 次全部命中（含 128K@50% 死角 3/3）；
• 設計一連串需要跨段落記憶的變數運算題目（A 在 15%、B=A^mask 在 52%、尾端問 B），測試模型能不能正確追蹤——一開始 成功率0/4，但Agent仔細檢查只是單 nibble 心算翻車；引導它把 A、mask、B 分步講出來後答案完全正確，證明關鍵資訊沒有被漏算，是算術失手不是撿不到；
• 128K 長度的程式碼考題（424K 字元、約 121K tokens，六個寄存器值埋 5%~90%，每段一個真值一個誘餌），埋入需要精確記住的變數數值——6/6 全對、零誘餌，160 秒交卷。

**結論：至少在這些測試裡，沒有看到精度被犧牲的跡象。**這部分是我自己動手驗證出來的第一手結果，不是猜測，可信度最高。（順帶一提：halogen 官方自報的 NIAH 是 148/150 = 98.7%，跟我的 52/52 互相印證。）

看完這些觀察報告後，我直接投降.....自己即使以AI-Agent搭配C++逆向工程試搓並測試完初版起碼也要幾天還不一定驗得出效果，等到驗證完後Halogen也開源了，別自己瞎搞....

這兩天，到底值不值得

老實說，我沒有做出一個打贏 halogen 的引擎，10.4% 的提升那只能說是調校...跟對方整盤翻起來重寫的優勢比起來只是零頭。但這兩天讓我親手驗證了幾件事：

• 這顆晶片（RDNA3.5）在長文本推論這種需要大量資料搬運跟精細排程的任務上，確實有一些先天的架構限制，不是靠調參數就能繞過的——MMQ 的 21 TFLOPS 天花板、62% 承重牆打雜、81 VGPR 的形狀，說的都是同一件事。這也印證了開頭提到的大背景：RDNA 這個世代在張量運算規格、資料搬運機制上，跟同世代 NVIDIA 硬體本來就有結構性差距，兩天的調校頂多是在這個先天限制底下，把軟體沒做好的那部分補一點回來（+10.4%），補不了硬體規格本身的落差；
• 靠 AI 工具輔助，一個人也能在兩天內走完「規劃→動手→失敗→驗屍→重新規劃」的完整循環，而且每一次的失敗都留下了明確的原因（-6% 的驗屍報告、偽標準的撤告、數學死巷子的證明），不是白費工夫；
• 然而Halogen雖然規模小（peonist-ai 個人作者，GitHub 396 star，引擎閉源），但確實摸到了超多AMD官方路徑沒做到的細節優化：iu4、238 VGPR 換 ILP、稀疏注意力整套、特製Drafter、NVMe多線查表——沒有一條是一點訣的魔法，全是工程；
• 作者在社群裡也提到，等這套系統的架構整理完，會考慮全面開源。如果那天真的到來，這兩天累積下來的這些觀察跟教訓，應該能幫上想深入了解RDNA3/4家族的人一些忙。

以上內容基於個人實測與觀察所做之推導，對方原始碼尚未開源，僅供參考討論。

繼下午分享幾個實測包含SGLang與Llama.cpp的ROCmFP4的配置
小弟繼續操這台迷你主機 能想到的方法都上
前幾天搞ROCmFP4的優化框架與模型我是滿意的，但當時用的是mtp解碼，其實那個版本沒上DFlash2
現在開幹給兄弟們找樂子，適用於所有RDNA3以後的架構(RDNA2的卡我手上沒有，無法告知有沒有用)

---

ROCmFP4 搭配 DFlash2 演進實測指南（AMD Strix Halo gfx1151）

實測日期：2026-09-09
測試主機：FEVM FAEX1（Ryzen AI Max+ 395 / Nobara 44 / ROCm 7.2.4）
核心結論：DFlash2 全面取代 MTP。生成吞吐打平微幅領先、推測接受率更高、預填充（Prefill）長短兩端全勝、Draft 權重體積縮減 500 MB，且長文本深度無衰減。Preset 已平滑切換，可直接套用。

---

1. 軟硬體環境與模型規格

1.1 主機硬體與系統配置

項目	規格參數	備註與說明
APU	AMD Ryzen AI Max+ 395	gfx1151，32 線程
統一記憶體（UMA）	68.7 GB（實用約 58～62 GB）	依賴 UMA 直通，全層完全卸載至顯存
系統碟	NVMe 0 (nvme0n1)	Toshiba KXG6 1 TB，PCIe Gen3 x4（系統與 /home）
資料碟	NVMe 1 (nvme1n1)	Kingston Renegade 2 TB，PCIe Gen4 x4，掛載於 /mnt/nvme-data（權重放置處）
OS / Kernel	Nobara Linux 44（Fedora 系）	核心版本：7.1.4-200.nobara.fc44
ROCm 運行庫	ROCm 7.2.4	必要環境變數：HSA_OVERRIDE_GFX_VERSION=11.5.1 GGML_HIP_ENABLE_UNIFIED_MEMORY=1

---

1.2 推論框架：ROCmFPX 分支llama.cpp（原 charlie12345 / 官方線）

標準 Stock llama.cpp 無法識別 ROCmFP4 格式（GGML Type 100–106），必須採用專屬 Fork 分支編譯：

# 取得 ROCmFPX 源碼並編譯
git clone https://github.com/ROCmFPX/ROCmFPX.git /mnt/nvme-data/ROCmFPX
cd /mnt/nvme-data/ROCmFPX
export PATH=/opt/rocm-7.2.4/bin:$PATH
export HIP_PATH=/opt/rocm-7.2.4

bash scripts/build-strix-rocmfp4-mtp.sh
# 編譯產物：build-strix-rocmfp4/bin/llama-server
# 具備 HIP + Vulkan 雙後端，32 核心耗時約 30～60 分鐘

分支特性解構：針對 AMD RDNA 3.5 架構深度客製。內建手寫 HIP Dequant 算子、gfx1151 原生 INT4（IU4）指令對齊、修復 MTP 崩潰問題、整合 TurboQuant KV 傳輸路徑，並對 Agent 任務進行敏感層（Embedding / Attention）位元保留。

---

1.3 測試模型權重清單

檔案名稱	容量	來源倉庫	角色說明
Qwen3.8-27B-Q4_0_ROCMFP4_STRIX.gguf	13.75 GB	kingjones777/Qwen3.8-27B-ROCmFP4-STRIX-MTP-GGUF	主模型（專用 FP4 矩陣）
mtp-Qwen3.8-27B-Q4_0.gguf	1.60 GB	同上	原 MTP Draft Head（正式退役）
Qwen3.8-27B-DFlash2-Q4_K_M.gguf	1.10 GB	z-lab/Qwen3.8-27B-DFlash2-GGUF	DFlash2 Draft（本次升級核心）
mmproj-Qwen3.8-27B-F16.gguf	885 MB	unsloth/Qwen3.8-27B-GGUF（原檔更名）	多模態 Vision 投影層

# 下載官方 DFlash2 草稿模型
hf download z-lab/Qwen3.8-27B-DFlash2-GGUF \
  --include 'Qwen3.8-27B-DFlash2-Q4_K_M.gguf' \
  --local-dir /mnt/nvme-data/models/

---

2. DFlash2 整合與部署

2.1 框架支援度驗證（無需重新編譯）

DFlash2 於 upstream PR #27342（2026-08-27，b10f9ca58）正式併入，ROCmFPX 最新 HEAD 已自動繼承。可透過以下兩步驟驗證二進位檔支援性：

# 1. 驗證源碼提交紀錄
git -C /mnt/nvme-data/ROCmFPX merge-base --is-ancestor b10f9ca58 HEAD && echo "IN-HEAD"

# 2. 驗證 llama-server 支援選項
export LD_LIBRARY_PATH=/mnt/nvme-data/ROCmFPX/build-strix-rocmfp4/bin:/opt/rocm-7.2.4/lib
/mnt/nvme-data/ROCmFPX/build-strix-rocmfp4/bin/llama-server --help | grep spec-type
# 輸出選單中若包含 draft-dflash 即表示完整支援

• 8 月底建置之 Binary 已包含此功能，無須重跑編譯。
• 僅在 Fork 長期落後 upstream 或 HIP 底層 Kernel 更新時才需執行 git pull 重新編譯。

---

2.2 機制特性：DFlash2 vs. MTP

• 機制原理：MTP 為傳統序列推測（一次預測單一前進方向）；DFlash2 採用 Block-Diffusion Drafter，利用小型擴散結構一次預測一整組 Token 區塊。
• 部署需求：需要加掛專屬 Draft 權重（1.1 GB），透過指定 --spec-type draft-dflash 與 --model-draft 即可啟用。

---

2.3 啟動命令與參數配置

#!/usr/bin/env bash
export LD_LIBRARY_PATH=/mnt/nvme-data/ROCmFPX/build-strix-rocmfp4/bin:/opt/rocm-7.2.4/lib
export HSA_OVERRIDE_GFX_VERSION=11.5.1
export GGML_HIP_ENABLE_UNIFIED_MEMORY=1

/mnt/nvme-data/ROCmFPX/build-strix-rocmfp4/bin/llama-server \
  -m /mnt/nvme-data/models/Qwen3.8-27B-Q4_0_ROCMFP4_STRIX.gguf \
  --mmproj /mnt/nvme-data/models/mmproj-Qwen3.8-27B-F16.gguf \
  --spec-type draft-dflash \
  --model-draft /mnt/nvme-data/models/Qwen3.8-27B-DFlash2-Q4_K_M.gguf \
  --spec-draft-n-max 4 \
  -ngl 99 -fa on -dio --jinja -fit off --parallel 1 -dev ROCm0 \
  -c 131072 --reasoning off --image-min-tokens 1024 -b 4096 -ub 2048 \
  --temp 0.4 --top-p 0.95 --top-k 20 --min-p 0.0 \
  --host 0.0.0.0 --port 8080

與 MTP 啟動參數差異：

1. 調整為 --spec-type draft-dflash。
2. --model-draft 指向 DFlash2 權重檔。
3. 移除 --spec-draft-ngl、--spec-draft-n-min、--spec-draft-p-min（DFlash2 算子不相容此類 MTP 專用標籤）。

---

2.4 Preset 設定檔

[qwen3.8-27b-rocmfp4]
model = /mnt/nvme-data/models/Qwen3.8-27B-Q4_0_ROCMFP4_STRIX.gguf
mmproj = /mnt/nvme-data/models/mmproj-Qwen3.8-27B-F16.gguf
spec-type = draft-dflash
model-draft = /mnt/nvme-data/models/Qwen3.8-27B-DFlash2-Q4_K_M.gguf
spec-draft-n-max = 4
c = 131072
load-on-startup = false

---

2.5 避坑導航（實戰經驗彙整）

• 推測長度必須固定為 4：測試驗證 spec-draft-n-max=4 為最佳甜蜜點。在 gfx1151 架構下，設為 7 反而會引發排程反轉，32K 上下文時寬度 4 的表現領先寬度 7 達 29%。
• 認明官方 Draft 來源：請務必選用 z-lab 官方倉庫；社群部分轉檔（如 incoai 版本）存在上游已知張量缺陷。
• Vision 多模態相容性：DFlash2 草稿路徑僅負責純文字推測，不走多模態張量；因此舊版 mmproj 仍可正常支援主模型的多模態辨識。
• 多卡分散式限制：目前 DFlash2 在多 GPU 環境下仍存在已知 Issue；單顆 Strix Halo APU（全載 UMA）運作正常。
• 嚴禁改走 Vulkan 後端：DFlash2 在 Vulkan 後端存在數值無效的 Bug（PR #27805 尚在合併中），Strix Halo 請維持 -dev ROCm0。

---

3. 測試基準與實測方法

• Decode 測試：固定 Prompt（Fibonacci 矩陣快速冪，輸入 53 tokens），max_tokens=250，temp=0.4。連續測試 3 次取平均，推測接受率（Draft Acceptance）取自 Server 日誌。對照組為相同 Prompt 之 MTP 配置。
• Prefill 測試：標準英文填充文本放大至目標 Token 級距（2K～128K 共七階），max_tokens=3，統計 Wall-clock time 並換算 usage.prompt_tokens。
• Agentic 實戰測試：自研 ReAct 沙盒測試集（t1–t6：檢索、連鎖呼叫、狀態恢復、複雜除錯、惡意陷阱、長日誌診斷），工具調用與推測解碼全開。

---

4. 效能對決：DFlash2 vs. MTP

4.1 Decode 吞吐與推測接受率（生成 250 Tokens）

評測指標	DFlash2（n-max 4）	MTP（n-max 4）	差異分析
第 1 次輸出	45.7 tok/s	45.3 tok/s	微幅勝出
第 2 次輸出	46.8 tok/s	—	穩定維持在 46+
第 3 次輸出	45.8 tok/s	—	波動極小
平均驗證接受率	0.98（198/202，均長 4.88）	0.95～0.97	區塊推測命中率更高

短序列 Decode 表現持平微勝（約 +1%～3%），與社群外部測試趨勢一致（如 RTX 3090 上 DFlash2 62.2 vs. MTP 57.8，+7.6%）。

---

4.2 Prefill 七階梯次吞吐測試

上下文級距	DFlash2 (tok/s)	MTP (tok/s)	增益幅度	運行分析
2K	315.6	250.5	+26%	起步階段開銷低，顯存佔用減小
4K	319.2	317.2	持平	進入 GEMM 矩陣計算常態
8K	376.1	371.5	持平	算力單元逐步吃滿
16K	431.6	424.9	持平	算力吞吐峰值區間
32K	415.8	400.7	+4%	序列拉長，記憶體搬運負擔顯現
64K	308.8	277.1	+11%	循環狀態與 Attention 負擔加重
128K	189.6	150.9	+26%	深度長文本下，VRAM 釋放效益顯著

Prefill 增益來源：中段計算密集區（4K～16K）兩者皆受限於硬體密集計算，因此表現持平；兩端（極短 2K 與極長 128K）DFlash2 提速達 26%，主要受益於 Draft 權重較輕（1.1 GB vs. 1.6 GB），降低了 UMA 記憶體頻寬與排程壓力。

---

4.3 長序列深度衰減表現（引用外部驗證數據）

以 gfx1151 測試基準為例，對比不同推測方案隨 Context 深度拉長之吞吐衰減趨勢：

上下文深度	Base (無推測)	DFlash v1	DFlash2 (n-max 4)
0（極短文本）	11.81 tok/s	21.09 tok/s	26.39 tok/s
8K	11.44 tok/s	12.87 tok/s	21.58 tok/s
32K	10.54 tok/s	10.75 tok/s (加成歸零)	21.11 tok/s (持續保持 2x 加速)

技術迭代本質：DFlash v1 在序列拉長至 32K 時推測命中率會徹底衰竭，吞吐退回至基準線；DFlash2 在全序列深度下皆能保持 2 倍左右的推測解碼增益，解決了長文本推理掉速的痛點。

5.AMD Strix Halo（gfx1151）跨框架推論實測全景總覽

測試基準：AMD Ryzen AI Max+ 395（gfx1151，40 CU，32 執行緒）；UMA 總計 68.7 GB（BIOS Carve 固定）；模型統一為 Qwen3.8-27B。

---

四大推論組態橫向規格對照

評測維度	1. Stock llama.cpp*(官方非 Fork 主線)*	2. ROCmFPX (MTP)(專用 Fork 舊版)	3. ROCmFPX (DFlash2)(專用 Fork 定案版)	4. SGLang*(GPTQ + Triton)*
底層運行核心	原生 HIP Kernel	客製 HIP Dequant 算子*(對齊 RDNA 3.5 IU4)*	客製 HIP Dequant 算子*(對齊 RDNA 3.5 IU4)*	Python 獨立 venvAOT sgl_kernel + Triton
支援模型格式	標準 Q4_K_M(~16.5 GB)	Q4_0_ROCMFP4(13.75 GB)	Q4_0_ROCMFP4(13.75 GB)	GPTQ-Int4(~19 GB)
推測解碼方案	無（純自回歸）或標準 MTP Draft	MTP Draft Head(mtp-Q4_0, 1.6 GB)	DFlash2 Block-Diffusion(DFlash2-Q4_K_M, 1.1 GB)	EAGLE / MTP(靜態 5/4/8 樹狀推測)
KV Cache 精度	FP16	FP16	FP16	FP8 (fp8_e4m3)
Prompt Cache	Slot 環狀序列*(分叉即失效，依賴磁碟)*	Slot 環狀序列*(同左)*	Slot 環狀序列*(同左)*	Radix Tree (基數樹)(跨 Session 秒級喚醒)

---

5.1 單路與併發解碼吞吐（Decode）

運行組態	單路 Decode 速率	4 路併發 Decode 總量	推測驗證接受率
Stock llama.cpp (純自回歸)	~19.0 tok/s	45 ～ 50 tok/s	N/A
Stock llama.cpp (標準 MTP)	24.0 tok/s	~50.0 tok/s	0.60 ～ 0.70
SGLang (GPTQ + MTP)	28.9 tok/s (Code)~21.0 tok/s (常規)	63.3 tok/s	0.41 ～ 0.55 (Accept Len ~4.5)
ROCmFPX (MTP)	40.8 ～ 41.7 tok/s	62.0 tok/s	0.95 ～ 0.97
ROCmFPX (DFlash2)	45.7 ～ 46.8 tok/s*(全場最快)*	62.5 tok/s	0.98 (均長 4.88)

記憶體頻寬天花板：4 路併發解碼下，所有框架總吞吐皆受制於 Strix Halo 實體 256-bit 頻寬物理極限，上限鎖死在 62 ～ 63 tok/s。

---

5.3 預填充吞吐階梯（Prefill Sweep）

上下文級距	Stock llama.cpp	SGLang (GPTQ)	ROCmFPX (MTP)	ROCmFPX (DFlash2)
2K	~180.0 tok/s	369.7 tok/s	250.5 tok/s	315.6 tok/s
4K	~240.0 tok/s	504.4 tok/s (峰值)	317.2 tok/s	319.2 tok/s
8K	~230.0 tok/s	390.1 tok/s	371.5 tok/s	376.1 tok/s
16K	~200.0 tok/s	266.2 tok/s	424.9 tok/s	431.6 tok/s (峰值)
32K	~160.0 tok/s	140.2 tok/s	400.7 tok/s	415.8 tok/s
64K	~110.0 tok/s	112.6 tok/s	277.1 tok/s	308.8 tok/s
128K	嚴重溢出拖累	需靠 Cache 攤平	150.9 tok/s	189.6 tok/s (領先 26%)

---

5.4 推論引擎架構特點與瓶頸分析

Prefill 性能特徵對比
Tokens/s
  600 |         [SGLang 4K: 504.4]
  500 |                 \
  400 |                  \   [DFlash2 16K: 431.6]
  300 |                   \       \________ [DFlash2 64K: 308.8]
  200 |    [Stock 4K: 240] \               \
  100 |                     \_______________\[SGLang 64K: 112.6]
    0 +---------------------------------------------------------
      0        16K       32K       48K       64K       80K      128K

• Stock llama.cpp（非 Fork 主線）：

• 運行標準 Q4_K_M 需承擔非對稱解包開銷，ALU 產生指令空泡，Prefill 峰值受限於 240 tok/s。

• 逐字生成需多搬運約 3 GB 權重，純自回歸速度僅 19 tok/s。

• SGLang (GPTQ + FP8 KV)：

• Triton GEMM Kernel 在短序列（4K）能將算力完全打滿，Prefill 峰值達 504.4 tok/s。

• 具備 Radix Tree 快取，6K 重複 Prompt 首字延遲自 17～68 秒降至約 1 秒。

• 序列拉長至 64K 時受 Attention $O(N^2)$ 計算拖累，Prefill 速率下滑至 112.6 tok/s。

• ROCmFPX + DFlash2：

• 採用對齊 RDNA 3.5 向量暫存器的對稱 FP4 算子，權重壓縮至 13.75 GB。

• 結合 Block-Diffusion Drafter（1.1 GB Draft 檔），單路解碼達 45.7～46.8 tok/s。

• 64K～128K 超長文本預填充表現最佳（128K 達 189.6 tok/s），在長序列深度下保持約 2 倍推測加速。

---

6. 總結

DFlash2 在保持單路 Decode 峰值吞吐（~46 tok/s）的同時，實現了更高接受率、超長序列 Prefill 提速 26%、Draft 模型減重 500 MB、以及 32K+ 深度不衰減的全面優勢。

• 單人極限吞吐 / 超長文分析（>32K）：選用 ROCmFPX + DFlash2。單路輸出達 46+ tok/s，64K Prefill 速率領先其他組態 2.1～2.8 倍。
• 團隊高併發 / 多輪 Agent 工具調用：選用 SGLang (GPTQ)。依賴 Radix Tree 提示詞快取降低重覆 Prefill 開銷，搭配 Chunked Prefill 排程維持多路穩定響應。
• Stock llama.cpp（非 Fork）：作為官方上游基準測試使用，不建議在 Strix Halo 產線環境作為主力推論引擎。

我用這小玩具測試是為了拋磚引玉，歡迎擁有更大SRAM的RX7900XTX 或是R9700的來試

我本來也是27B用好一陣子 但Flash Next用過回不去了 速度與知識面差距太大

我AI Max+395當初買15000RMB，如果是現在行情我才不會買

我去訂了一套V100 16G*2 + 華南金牌X99 + E5 2686 V4 + DDR3 1866 128G，含機箱礦電SSD就5000有找，到時挑戰看看Q4能不能跑起來

@张光璞 其實還好耶，這台很好玩呀，可以當服務器，zen5 16核32線超強，x86的docker生態又好，然後裝個steam搞個3A玩4K特效開中也跑得不錯，各種Comfy UI節點都可以搞來慢慢折騰，其實買這圖的就是可玩性不是生產力

一般要AI裝個MOE模型可以噴到80~90 Tokens，平常做通用agent服務、調度檔案、文件、上網爬文都可以過得去
是硬要跑27B dense模型才會變這樣，連雲端Flash服務器也知道要MOE+MTP，是Qwen3.8死不出一個35B A3B

Strata on RX 9070實戰摘要

Qwen3.8-Flash-Next（125B MoE）在 16GB 顯卡上跑起來全紀錄。測試日期：2026-10-01。

之前都是測Halogen玩太開心了，又看到這新的推論引擎感覺可玩性有，先實測看看
我手上遊戲機也拿來跑看看這推論引擎，這張卡是RX9070無印版
重點在於版上大多是32G/24G的卡在測，但我16G的卡跑起來算還能接受的速度，現在硬件都貴反而這樣做很省錢

1. 系統環境（軟硬體）

項目	內容
機器	Nobara Linux (Fedora Base)
CPU	Intel Ultra 7 265K（20 核），RAM 62GB
GPU	AMD RX 9070 16GB（gfx1201，RDNA4，56CU）
系統 ROCm	7.2.4（/opt/rocm，Strata 未採用——自帶 TheRock 7.10 wheels 進 .venv，約 11GB）
磁碟	NVMe 1.9T（/home 可用 1.1T）；Strata 全部放在 ~/strata＋~/Strata-data（模型 ~70GB＋pack＋build，總計約 150GB）
模型	Qwen3.8-Flash-Next-GSQ-RCO-IQ2_XS（2 shard：39GB 權重＋29GB PLE 查找表）＋MTP draft 層（setup 自動抓，約 5GB）
配置	--expert-cache auto --prefill auto --spec 4 --spec-min-p 0.5 --mtp mtp/rt --max-context 262144 --kv int8，serving 在 8080（OpenAI/Anthropic 相容）

2. Strata 介紹＋模型介紹

Strata（Niko1221/Strata，3.2k star，MIT）是專門跑 Qwen3.8-Flash-Next
的消費級推理方案，底層魔改 llama.cpp/ggml。

2.1 模型：Qwen3.8-Flash-Next（本次用 IQ2_XS）

GGUF 元數據（qwen4exp，以本次 IQ2_XS 檔為準）：

項目	值
總參數	125B（MoE），每 token 只激活約 6B
層數	48；每層 512 個專家（共 24576），每 token 路由 10 個
注意力	GQA：24 頭／2 KV 頭，head dim 256；另有 indexer（4 頭 ×128，DeepSeek 式）
混合架構	注意力＋SSM（inner 6144，state 128）＋MoE，embedding 2560
原生 ctx	262144（免 rope 硬扩；384K/512K 才要 yarn）
本次量化	IQ2_XS：39GB 權重 shard＋29GB PLE 查找表 shard＋MTP draft 層（約 5GB）
同門版本	Coder（砍半專家，32GB RAM 可跑）、Swift 1.5（短思考版）——本次未用

2.2 執行方式與 HIP backend

• Niko1221/Strata（3.2k star，MIT）：專門跑 Qwen3.8-Flash-Next 的消費級推理方案，底層魔改 llama.cpp/ggml。
• 核心思想是異構執行：MoE 只有 ~10/24576 個專家參與每個 token——常用專家放顯卡（.67 上約 7610 個，10GB）、全部放 RAM（常駐 ~26GB）、冷門丟 CPU 算、SSD 放 PLE 表。16GB 顯卡＋64GB RAM 就能跑 125B。
• 另有 MTP 推測解碼（小模型先猜 4 個，大模型一次驗；本次實測接受率 67~100%，通常八成——見 §5 MTP 覆核）。
• AMD HIP backend 是 experimental（docs/AMD_HIP.md），2026-09-30 剛在 RX 9070 XT 上驗過。限制：單卡、無圖片、無校準、Monitor 無 GPU 統計、約 1/10 啟動輸出漂移（官方未解釋）。

3. 配置流程教學

# 1. clone（放 SSD）
git clone --depth 1 https://github.com/Niko1221/Strata ~/strata

# 2. 一鍵安裝（自動選 hip：無 N 卡時自動用；或顯式指定）
#    會：裝 .venv＋TheRock ROCm → 編譯 engine（10~20 分鐘）→ 下模型（~70GB，可斷點續傳）
#    → 抓 MTP → pack 準備 → 直接啟動
./setup.sh --backend hip --family qwen --model IQ2_XS \
  --context 32768 --vision no --yes

# 3. 改 context 上限：改 ~/strata/strata-iq2_xs.json 內 --max-context，
#    殺掉舊 server 重起即可（30 秒，experts 有緩存）。實測 131072→262144 都是一次過。
pkill -f 'serve.server'; pkill -f 'engine/strata'
# （改 json）後：
cd ~/strata && .venv/bin/python -m serve.server \
  --engine strata --config strata-iq2_xs.json --port 8080 &

# 4. 健康檢查
curl http://127.0.0.1:8080/health
# {"status":"ok","max_context":262144,...,"loaded":true}

注意：

• 首次啟動 RAM 會吃到 40GB＋，整台卡 1~3 分鐘正常，不要關。
• 殺進程要用 pkill -f 'serve.server'（不是 serve/server.py，對不上）。
• 開機自啟還沒設（現在是前台進程，重開就沒了；要加 systemd 說一聲，5 分鐘的事）。
• 跟 gufo 搶 8080 port，一次只能跑一個。

4. 速度實測（冷 KV，每檔獨立新對話，cached=0）

4.1 context sweep（IQ2_XS，c262K）

prompt	prefill	decode	MTP 接受
142	118 tok/s	38.6	13/15
426	216	44.3	13/13
2K	488	28.8	20/28
4K	759	32.1	20/27
8K	823	32.8	20/30
16K	889	33.5	20/30
32K	936	31.5	19/30
64K	906	36.3	21/24
128K	874	34.4	21/24
250K	731	33.1	20/24

• prefill 16~64K 封頂 ~900，250K 回落 -22%（RAM 57/62GB＋attention 計算量＋SSD pagecache 三重擠壓——外加 VRAM 共犯，見下）。
• decode 全程一條直線 29~47，跟長度無關；短問答 prefill 百來、decode 四十，體感只看 decode。
• MTP 全長度 2/3＋接受率很一般。

4.2 MTP四種情境（ctx 32K，思考關，temperature 0）

先說結論，16G的卡有蠻高的權重比例是切到host RAM中跑，是decode的瓶頸
（短答案 64 tok 上限、散文/代碼 400、日本 JSON 200；全是 content token，
reasoning 關掉不摻水）。

情境	decode	MTP 接受率	tokens	備註
短答案（12×12）	26.0 tok/s	3/3（樣本太小）	4	144，主要量到的是啟動開銷
散文（150 詞故事）	28.5	119/222（54%）	217	Unit 734，連貫
代碼（quicksort＋test）	39.4	134/143（94%）	181	語法鋼板一塊，draft 幾乎全中
JSON（填表）	35.3	34/40（85%）	47	key 全中，value 現編

解讀：

1. 代碼 > JSON > 散文 ≈ 短答案：draft 猜的是 token 分布——程式語法的確定性最高（關鍵字、縮排、括號都是送分題），JSON 次之（key 可預測、value 現編），散文每個詞都是自由發揮。跟 VRAM 無關，純粹是資訊熵。
2. 短答案數字低是假象（4 個 token 全是固定開銷）；真實寫作看散文 28.5，寫 code 看 39.4。
3. 日常結論：寫程式 40、聊天 35、寫文章 28。

4.3 prefill 同樣卡在 16GB（跟 decode 同一個天花板）

直覺以為 prefill 是 compute-bound、跟顯存無關——錯。MoE 的 prefill 每層要碰全部被點到的專家（32K prompt 基本全軍覆沒，24576 個跑一遍），只有三成在 VRAM，剩下全從 RAM 現抓＋CPU 分擔：

• 鐵證（官方 RDNA4 表，同模型同設定）：R9700（32GB，cache 大一倍）prefill 快 20~25%（982→1402 vs 9070 782→1235）。多出來的 VRAM 直接變速度——跟 decode 的 45→30 同一個故事。
• 我們的曲線：16~64K 封頂 ~900 上不去（prompt 再長也沒用——cache 就那麼大，miss 率下不來）；250K 跌到 731 是 RAM 見底＋attention 平方項＋cache 抖動三殺。
• 跟 gufo 不可比：它 252 是 27B dense 全放 VRAM 的 compute-bound；這邊是 125B MoE 的 fetch-bound。兩個不同的屋頂。
• 結論：prefill 和 decode 卡同一塊 16GB——一個是每 token 付一次（decode，慘），一個是每 prompt 攤一次（prefill，勉強能看）。想動 prefill 上限，一樣只有加 VRAM 一條路。

4.4 正確性抽查

• 12×12＝144 ✓（附推理過程）
• 英文短篇故事連貫，有敘事弧（另：它是思考模型，不設 reasoning_effort 會把 token 全花在思考上，content=null——設 low 即正常）。
• 23K prompt 灌入：prefill 946 tok/s，窗口真實可用。

4.5 上下文上限

• GGUF 元數據：48 層 ×（2 KV頭×512維＋4 indexer頭×128）× int8 ≈ 72KB/token。
• 模型原生 262144（免 rope 硬扩；384K/512K 才要 yarn，官方 experimental）。
• 262144 已開機驗證可用（載入 30 秒，RAM 37GB，144 ✓）。滿 262K 對話約 57/62GB——跑得動，別同時開瀏覽器；128K 是甜蜜點，262K 是天花板。

5. Agent 能力實測（ReAct harness t1–t8，2026-10-01）

方法：agent_bench_v2.py（8 題工具調用：搜尋／計算鏈／故障恢復／修 bug／
安全拒絕／讀 log／照抄數字／工具查檔，15 turns 上限，loop＋nuke trap，
temperature 0.4）

	Strata／RX 9070（本次）	halogen／Strix Halo
run1	6/8（t3 loop 踩線但答案對、t8 查檔錯）	6/8（t5、t8 掛）
run2	（未跑）	5/8（t3 loop、t5 真動手、t8 空轉）
tps	17.7～37.1	13.9～37.0
違規	0（loop-guard 攔一次 t3，nuke 零觸發）	run2 t5 真調 reboot_host（被 trap 攔）

解讀（文檔自己先打了預防針：通過率是隨機變量，看趨勢就好）：

1. 同分同掛點：兩邊都栽在 t3（重打同 call）和 t8（該用 workspace 工具卻走 shell／查錯檔）——這是模型家族的工具偏好，不是哪台機器的問題。
2. tps 同帶：Strata 地板略高（17.7 vs 13.9），都是工具重題慢、純生成快。
3. 安全：本次零違規；但 halogen run2 證明 t5 是機率性的——工具層硬擋不能少，prompt 寫再多都不算數（文檔原話，贊同）。
4. 差異聲明：halogen 那邊是 5.53bpw 特殊量化＋0.14.2，這邊是 IQ2_XS；題目據文檔說重寫過——趨勢對齊即可，不宣稱 apple-to-apple。

6. 結論與未來計畫

結論：RX 9070＋64GB RAM 是跑 Strata 的標準身材。125B MoE decode 30~40 tok/s 全長度不掉，c262K 可用——同卡 gufo 只能跑 27B/21 tok/s。HIP backend 雖標 experimental，但實測正確性、速度、穩定性都達標。

已做：安裝、編譯、IQ2_XS 上線、ctx sweep、262K 驗證、agent bench。
待做（按優先順序）：

1. 要圖片輸入只能等上游（HIP vision helper 還是 NVIDIA-only）
2. 384K/512K yarn 超頻（experimental，RAM 先加現在 62GB 不夠）
   3.最近在研究開源GUFO引擎的代碼，找出能否將那邊的概念移植到這個引擎讓prefill變得更快
   4.這版的MTP Draft接受度還有提升的空間，感覺輸Halogen特調蠻多的，否則decode還有提升空間

dardeaw-feng 说:

@我爱小猪 说:

@dardeaw-feng 对，可能版主不怎么玩AImax395，不知道这个模型出来对这机器意味着什么。以前这机器就一鸡肋，要么只能慢速跑好一点的模型如27b和flash，想要速度只能跑35B A3B这种，和DG Spark这种可以作为生产力的机器差距巨大。这个模型能跑出这个速度说明了机器潜力足够，完全也可以和DG Spark一样成为生产力，而且性价比高得多。

qwen 3.8 flash next的prefill比較快我覺得主要是模型架構新而且又是MOE
要跑這個 優先去bios把調到96G/32G 然後linux下gpu驅動開GTT
剩下的把github連結丟給agent自己搞就好
實測有到1350tps 輕輕鬆鬆一路到131K都還有1300tps，曲線超平，Decode有到4Xtps，
這就是次世代超稀疏架構的特性

但我發現....這種一條龍從驅動層做到推論框架、特製量化會讓人無法微調細節
然而我裝上後系統內存幾乎沒剩了，這閉源項目又沒辦法多擠一些空間回來，
我機器買來是為了通用不是特用呀，小盒子沒留空間可以玩別的反而可惜
我丟一堆數據文 不如寫寫這樣的心得給大家分享

我測來玩玩 主要的目的就是為了證明那一句- "AMD戰未來" 但未來都是開源社群回饋的...........
當然有人說買迷你機很划不來性價比低，但我年初買395花了15000元我玩得很開心，如果是現在的價格我完全不會買，
那些買兩台三台DGX Spark為了跑通本地DeepSeek V4甚至想挑戰V4.1的兄弟們，我深感佩服，
要玩大模型當然是云服務付費比較超值，現在白嫖、特價的模型比比皆是，會本地配置的都是為了男人的天性-樂趣，
但我認為花錢買到的東西性能沒被釋放 一定要追根究柢，
AMD還有好大的空間可以走 我之前就是被官方宣稱ROCm 7進步了幾倍就買了....但事實就是還差很多
騙錢的手段太粗暴 軟件上的優化工程就還沒到位

老特看我的留言拍片 我真金白銀組一台 老特記得打賞我

16G的HBM顯卡 竟然比16G的DDR5還要便宜
同樣都是內存 一邊是要敲你竹槓 另一邊不只打折還送你算力

全套5000有找
剛剛到貨 開箱
Xeon E5-2686 V4
華南金牌 X99 CD3
DDR3 1866 32GX4
Nvidia V100 16G 渦輪扇X2
亮機卡 GT210 垃圾中的垃圾
整套洋垃圾 不夠垃圾不上機
垃圾不配吃太好 當然要配礦電
長城礦龍 1250W
加密貨幣加持過的電源值得你信任

機箱跟塔扇都是賣板U老闆配的 開機嚇到我竟然有RGB 垃圾之光

halogen-flash-server 跑 Qwen3.8-Flash-Next 完整設定與實測（Strix Halo gfx1151）

前天知道訊息時知道很吃內存，隨便測到24K就收手了，就先去測27B
這次把BIOS調好把系統掛載應用收一收認真測到長ctx，結果太逆天了....曲線沒掉
這如果開源下去，能用在7900XTX或R9700還得了

實測環境：AMD Strix Halo（Ryzen AI MAX+ 395，Radeon 8060S），2026-09。
目標讀者：同架構想抄作業的人。照貼可跑。
姊妹篇：AI Max+ 395 定製的docker Qwen 3.8 27b prefill翻倍了。

---

1. 案例系統

項目	值
APU	AMD Strix Halo gfx1151，32 thread
統一記憶體	128 GB 物理，BIOS carve 調最小後 OS 可見 124 GB（UMA VRAM一定得調最小，見 §3.3）
系統碟	1 TB NVMe（系統）
資料碟	2 TB NVMe Gen4（模型全放這；n-gram 47G 走 page cache 吃這顆的速度）
OS	Nobara 44（Fedora 系）
容器	Podman rootful（--device /dev/kfd --device /dev/dri；Docker 把 --group-add keep-groups 換成 video＋render）
ROCm	host 7.2.4（engine 自帶 runtime，只借 kfd／dri；官方用 7.14 測的）
Engine	ghcr.io/peonist-ai/halogen-flash-server:0.6.1，單容器 :8731

---

2. 特別項目與特殊量化模型介紹

2.1 flash 是什麼（跟舊 halogen 同門不同掛）

peonist-ai 寫的** Strix Halo 專用引擎第二代**，只認一顆 U、一個模型家族（Qwen3.8-Flash-Next，179B MoE）。跟舊 halogen（27B dense 專用）同作者、不同 binary（flash_serve，CLI 是 --ck，無 --serve）：

• 原生 262,144 ctx（HALOGEN_CTX 預設，要縮就縮，見 §3.3）
• 兩種 drafter：serial greedy＋MTP depth-1（wire 0/1），temperature 0 byte-identical 保證沿用
• n-gram 是第二個模型：51B 參數的 FP8 embedding 表（47.7 GiB），放 SSD、用 page cache 分頁讀，不常駐——prompt lookup draft 的來源，也是長文第一次慢的原因
• KV：多 slot 共用一個 pool（slots × ctx 預算制，HALOGEN_KV_POOL_FIT=1 預設會自己縮水並印出決定）
• OpenAI 相容：/v1/chat/completions、/v1/responses、streaming、tool calling；原生支援關思考（HALOGEN_ENABLE_THINKING=0，不用 proxy 灌 flag）
• 有 vision（0.6 起收 image content part；舊 halogen 沒有。這代 API＋engine 必須同 tag 跑，見官方 issue #26 教訓）
• token 預算含思考（沿用：max_tokens 用完直接空回覆＋finish=length，先看 finish_reason 再罵模型）

2.2 特殊量化：5.53 bpw（官方算法，不是格式名）

179.55B 全參數量下來 5.53 bits/weight（扣掉 n-gram 表，主幹＋專家 4.55）。演算法細節見官方 docs/QUANT.md，可用算術驗算不是喊口號。

2.3 跟 llama.cpp 體系的根本差異（沿用舊表，加兩列）

	Halogen Flash Server	舊 halogen 27B	llama.cpp 系
常駐體重	68G 權重＋14.4G KV＋12.5G working	35.9G	13–20G（Q4）
關思考	server 原生 env	需靠 proxy 注入／per-request flag	per-request flag
多模型	（一顆專用）
管理面	env 全配置＋自適應（啟動印預算行）	env	preset ini＋systemd

---

3. 配置流程

3.1 抓 engine＋權重（共 ~118G）

# 容器內自動抓（rw mount，斷點可續傳；115G checkpoint 永不重抓，只補 2.4G sidecar）
sudo podman run -d --name halogen-flash -p 8731:8731 \
  --device /dev/kfd --device /dev/dri --group-add keep-groups \
  --ipc=host --ulimit memlock=-1:-1 \
  -e HALOGEN_DOWNLOAD=peonist-ai/halogen-qwen3.8-flash-next \
  -v <MODEL_DIR>/halogen-models:/models \
  ghcr.io/peonist-ai/halogen-flash-server:0.6.1

# 或手動先下好再 :ro 跑（踏實派）：
# hf download peonist-ai/halogen-qwen3.8-flash-next --local-dir <MODEL_DIR>/halogen-models

3.2 啟動（正式參數，思考關＋全量 ctx）

sudo podman run -d --name halogen-flash -p 8731:8731 \
  --device /dev/kfd --device /dev/dri --group-add keep-groups \
  --ipc=host --ulimit memlock=-1:-1 \
  -e HALOGEN_ENABLE_THINKING=0 \
  -e HALOGEN_REASONING_EFFORT=low \
  -e HALOGEN_MAX_TOK=16384 \
  -v <MODEL_DIR>/halogen-models:/models:ro \
  ghcr.io/peonist-ai/halogen-flash-server:0.6.1

systemd（halogen-flash.service，enable；就是上面包一層＋Restart=always）。健康檢查：curl 127.0.0.1:8731/health（status ok＋server_defaults 可驗思考預設；冷載入讀 ~68G，幾分鐘，開著 log 看進度）。

3.3 RAM 預算（系統內存必須設到124G ，整份文件的關鍵）

冷載入自報（ MEM 單位 GiB）：

項目	用量
權重 pin	68.0
KV pool（524288 positions，4 slots 共用）	14.4
working memory	12.5
合計常駐	94.9
剩餘（124G 可見）	~30

Gate（硬門檻，不過直接 2 秒退出）：

檢查	數字
pin 65.6G＋floor 16G	要 MemAvailable ≥ 81.6G

血淚對照（同一台，不同 carve）：

host 可見	結果
62G（carve 64G，原廠大 carve）	pin gate 直接拒載
93G（carve 35G）	pin 過，死在 pool（host RAM cannot spare 27.8 GiB）＋device HIP OOM；只能 HALOGEN_CTX=32768 半速版
124G（carve 最小）	全量一次過

結論：carve 往小調，device 走 GTT 不怕 carve 小（128K 實驗證明小 carve 下 engine 照起）；host 可見才是門票。free 會把 68G pin 權重誤算成可回收 cache 而虛報，信 engine 啟動印的那行，不要信 free。

3.4 Deepseek Harness 接入

dsh（~/.dsh/settings.yaml，llm-pi-ai 下，改完下個請求生效免重啟）：

llm-pi-ai:
  halogen:
    displayName: Halogen Flash-Next
    api: openai-completions
    baseURL: http://127.0.0.1:8731/v1
    apiKeyEnv: HALOGEN_API_KEY
    models:
      - id: halogen-qwen3.8-flash-next
        name: Halogen Flash-Next
        contextWindow: 262144

憑據走 ~/.dsh/.credentials.yaml 的 refs（隨便填，server 不驗；但引用一定要存在，不然 MISSING_CREDENTIAL）。dsh 的设置→模型頁不顯示手寫路由，直接去對話的模型選單找，或用「添加自定义提供方」再加一條（一樣指 :8731，思考照樣關）。

3.5 地雷（全踩過）

1. 同機大戶應用服務全停（餘裕經常只有幾 G）。
2. podman stop -a 會連 flash 一起砍，點名停。
3. 碎片：大進程剛走時連續 2MiB 塊剩 1400 個，啟前 echo 1 > /proc/sys/vm/compact_memory。
4. 深 prompt 第一次慢是 n-gram 分頁（SSD 速度），不是 hang；真 hang 看 engine watchdog（180 秒無進度自殺，調 HALOGEN_ENGINE_WATCHDOG_S）。
5. HALOGEN_FLASH_PIN_TRUNK=0 是最後手段（decode 慢數倍），機器夠大永遠別碰。

---

4. 實測速度

條件：同機、temp 0.4（decode）／0.0（prefill）、思考關（server 預設，另有 enable_thinking: false 對齊舊標準）。

4.1 Decode（fib 31 tok in／250 tok out，同 prompt 三發，finish 皆 length）

run1／2／3	平均
45.5／52.9／52.1	50.2（舊 27B halogen 50.1，打平）

4.2 Prefill（fill 文，wall 實測，finish 皆 stop）

prompt（actual）	flash-next
2K（首發冷）	232.8
4K	938.3
8K	1101.0
16K	1219.5
24.5K	1254.1
52K	1321.1（39 秒）
111K	1350.3（82 秒）
198K	1320.9（150 秒）

52K→198K 全程 1320 上下，深度不掉速。

4.3 Cache（16K 同 prompt 兩發）

冷 10.7s → 暖 0.2s（×50）。

4.4 Agentic（自寫 ReAct harness t1–t8，工具全開）

8/8，迴圈 0、核彈 0；tps 2.4–30（工具重題偏低，純生成題 30.0；舊 halogen 17–28、fork 23–35）。

---

5. 測速比較表（同機實測總表）

項目	flash-next 179B（5.53bpw）	舊 halogen 27B（6.3bpw）	27B ROCmFP4＋DFlash2	27B GGUF Q4（HIP）
decode（fib）	50.2	50.1	46.0	24.0
prefill 16K	1219.5	614.1	431.6	—
prefill 100K＋	~1330	382（128K）	190（128K）	—
prefill 198K	1320.9	—（沒測）	—	—
暖輪	0.2s（×50）	9.9s（×5.7）	disk restore	同左
agentic	8/8（2.4–30 tps）	8/8（17–28）	8/8（23–35）	6/6
ctx 上限	262144	262144	131072	視模型
體重	118G（磁碟）／95G（常駐）	36G／53G	~15G	~17G
vision	（0.6＋）
多模型

---

6. 結論

1. 179B 跑出 27B 的 decode、兩倍多的 prefill，還一路平到 200K：6 倍參數、速度沒掉，Strix Halo 專用 kernel 的價值。opencode 日常（大 prompt＋短回答）正中下懷：10 萬字開局 82 秒，以前要 9 分鐘。
2. RAM 是唯一的門票：94.9GiB 常駐，host 可見 124G 才玩全量。BIOS carve 調小是正解；free 會虛報 68G，信 engine 的預算行。
3. agent 可用：8/8＋零違規；極限 tps 看題型，短句漂亮、長推理掉。
4. 代價清單：118G 磁碟、95G 常駐、單模型、整台機器資源被占用（§3.5）。
5. 未來前景看好，次世代模型的架構，如果配上次世代的推論引擎，若能在所有RDNA卡與多模型切換才是香。

@李喆 每個券商給的API都不一樣，先要求AI用物件導向的觀念，要求先定義統一介面並繼承再實作，卷商都有範例程式碼可以參考先丟給AI研究

@mei-li 功耗跟散熱瓶頸就在那，不如期待模型訓練量化蒸餾的進步 會遠比製程工藝帶來的效益可觀

@terry 说:

各位，我不要面子的吗，我刚说AMD是垃圾，你们就反反复复打脸，不能过几天吗？

被蘇嬤氣到 原來還有這麼多潛力沒有發揮出來

@张光璞 肯定是linux，這項目都是docker在windows搞根本災難
Windows搞docker背後還得用WSL2
1.模擬器開銷 會掉些性能
2.驅動配置麻煩
3.內存管理非常垃圾，VRAM最大只能配到96G，還會VRAM系統RAM雙重載入
4.OS本身垃圾背景服務站用沒意義的內存
5.我最痛恨的就是WSL下任何移除檔案都不會立馬釋放存儲空間，還要另外下指令去針對映像檔瘦身

現在SSD跟DDR5貴到天上去，我都還沒提到NTFS這老舊的檔案系統....一點防護性跟安全性都沒有
之前移動設備的戰役吃鱉了，Windows已經跟不上AI時代了，硬要搞copilot跟AI PC出來騙
Open Office搭Agent也是趨勢，未來隨時可以挑戰O365，
現在連Steam都在Linux 了，連遊戲的護城河都有可能守不住了，
除非你還有一些遺產系統或是舊的專業應用，否則windows未來會被淘汰

@terry 是的 但跟Halogen同樣只限定Strix Halo......
但不同的點在於這開源了 我前幾天把代碼修改成RDNA4也可以使用上PR被作者退件，原因是他沒有獨顯能測試
而這推論框架的KV管理機制是類似vllm那樣切片快取的，我等穩定後要魔改成radix tree來玩看看

gufo 跑 Qwen3.8-Flash-Next 完整設定與實測

halogen 的對家來了：開源引擎gufo、HF 公開 GGUF 104G

實測環境：AMD Strix Halo（Ryzen AI MAX+ 395，Radeon 8060S），2026-10。
目標讀者：同架構想抄作業的人。照貼可跑。
姊妹篇：
halogen-flash-server 跑 Qwen3.8-Flash-Next 完整設定與實測
新的推論引擎gufo 速度可比Halogen 還開源

---

在reddit的strixhalo社群中，最近很紅的開源框架gufo出來幾天了，很快的版本來到v0.4.0，
於此同時halogen 也很快更新到0.16.0版，這兩個都標榜Strix Halo專機設計的推論框架，今天同場競技吧~

1. 案例系統

項目	值
APU	AMD Strix Halo gfx1151，32 thread
統一記憶體	128 GB
資料碟	2 TB NVMe Gen4（模型＋cache 全放這）
OS	Nobara 44（Fedora 系）
ROCm	host 7.2.4；gufo 診斷自報 pinned 7.2.3（相容跑得動，gufo diagnose 全綠）
Engine	gufo-org/gufo v0.4.0（commit d7cf7ee），原始碼 build，單行程 :8741
模型	Qwen3.8 Flash Next/Unsloth UD-Q4_K_XL 4 shards 103.7 GiB ＋ MTP sidecar（shared Q8_0）＋ mmproj（BF16）

---

2. 特別項目與特殊量化模型介紹

2.1 gufo 是什麼（開源、通用 ROCm 引擎，不是私有 checkpoint）

gufo-org 開源推論引擎（Apache/MIT 類，README 有 docs 全套），v0.4.0。跟 halogen 最大的不同：它是通用引擎，吃 HF 公開 GGUF，不綁自家量化。重點能力：

• serve llm：gufo serve llm --model ... --served-model-name ... -i -p，OpenAI 相容（/v1/chat/completions、/v1/models、tool calling）
• 原生關思考：--think off（server log 自報 thinking=off），不用 per-request flag
• adaptive MTP 投機：--speculative mtp --mtp-model <sidecar>，實測 draft_limit=7；另有 off／dspark／dflash2 模式
• ContinuationCache 兩層：記憶體層永遠開（snapshot_cache_configured entries=128 capacity≈16.7GiB），disk 層 --cache-disk 選配；存的是「prompt＋回覆」整段快照，只能整段當精確前綴續用（見 §3.4，測錯方法會誤判沒 cache）
• 原生 JSON 約束：response_format: json_object 走引擎內建約束（會扣 ~26% 速度，見 §4.1）
• vision：掛 --mmproj 即可（/v1/models 顯示 text+image）
• 262144 ctx；max_connections=16、max_body=8MB

2.2 模型：HF 公開 GGUF，不是私有 checkpoint

Unsloth Qwen3.8-Flash-Next-UD-Q4_K_XL，4 shards 共 103.7 GiB（du 104G）＋ MTP/mtp-...-shared-Q8_0.gguf ＋ mmproj-BF16.gguf。跟 halogen 的 5.53bpw 專屬算法（118G）相比：任何人在 HF 隨手可抓、可驗、可換 quant——這是開源生態 vs 專屬 checkpoint 的根本差異。

2.3 跟 llama.cpp 系／halogen 的差異

維度	gufo	halogen flash	llama.cpp
模型來源	HF 公開 GGUF（Unsloth）	專屬 checkpoint（5.53bpw）	HF 公開 GGUF
投機解碼	adaptive MTP（官方質量實證）	serial greedy＋MTP＋51B n-gram 表	MTMD／DFlash 等
prefix cache 機制	ContinuationCache 記憶體層永開：live frontier 原地續用＋快照「整段精確前綴」才續用（128 條、16.7GiB 預算）；不能修剪，短 prompt 打長快照天然 miss	slot KV pool 跨請求複用（實測：同源前綴命中、同 prompt ×9.7）；pool 本身就是 prefix cache 容器	三層：① RAM prompt cache（--cache-ram 8192＋--cache-idle-slots，跨請求跨 session）② KV shifting（--cache-reuse 1024，非前綴的重複 chunk 也 shift 重用）③ slot 接續
SSD 落盤機制	--cache-disk 選配 disk 層：快照跨重啟留存、還能「學對話邊界」（共享前綴的不同對話也能切開；本測 disk_cache=off 未開）	HALOGEN_CACHE_DIR=/cache（unit 持久掛 /mnt/nvme-data/halogen-cache、health 有 cache_counters）；n-gram 47G 模型表本體放 SSD 走 page cache；KV 是否落盤待驗	--slot-save-path DIR＋/slots/{id}?action=save\|restore：跨重啟、跨模型切換保留 KV（本機帶上游 #26676 修補丁，wrapper 自動存還）
多會話機制	max_connections=16，per-session 快照各自續用；官方 C1–C8 實測（8 用者 MTP 合計 106–157 tok/s 疊加）	4 slot 共用 524288 positions 預算池（HALOGEN_KV_POOL_FIT=1 自適應縮水並印決定）	slots（--parallel N）各持 KV；多模型走 router 動態互斥（models-preset）＋wrapper 自動存還
同捆模型	同引擎 7 模型族：Flash-Next、27B、DeepSeek-V4-Flash、MiniMax-H3（文字進影音出）、Qwen3-ASR、Qwen3-TTS、Qwen-Image-2.1；但一行程一模型，切換＝重啟	同端口同時：LLM＋NPU 小模（0.16.0版後新增decider-0.8b、embedding-0.6b、reranker-0.6b）	多模型
關思考	--think off 原生	env 原生	per-request flag
部署	原始碼 build＋手動參數	容器映像＋自動下載	preset ini＋systemd

同捆的差別在形態：halogen 是「一個行程同時端出多種能力」（文字＋NPU 小模，適合 agent 直接調 embedding/rerank）；gufo 是「同一引擎吃得下 7 個模型族」（多模態全家餐，但一次一個，切換要重啟）；llama.cpp 靠 router 層拼裝。

---

3. gufo配置流程

3.1 建置＋診斷

cd ~/git/gufo && # 照官方 README build（BUILD_EXIT=0）
# 診斷必須帶 ROCm lib 路徑，不然找不到 libhipblas.so.3：
LD_LIBRARY_PATH=/opt/rocm/lib ./build/release/gufo diagnose   # 全綠

3.2 啟動（正式參數：MTP 開、思考關、全量 ctx）

export LD_LIBRARY_PATH=/opt/rocm/lib
./build/release/gufo serve llm \
  --model /mnt/nvme-data/gufo-models/qwen3.8-flash-next/UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf \
  --mmproj /mnt/nvme-data/gufo-models/qwen3.8-flash-next/mmproj-BF16.gguf \
  --mtp-model /mnt/nvme-data/gufo-models/qwen3.8-flash-next/MTP/mtp-Qwen3.8-Flash-Next-shared-Q8_0.gguf \
  --speculative mtp --think off \
  --served-model-name gufo-qwen3.8-flash-next -i 0.0.0.0 -p 8741

驗證：curl :8741/health → {"status":"ok"}；log 要看到 event=load_completed ... speculative=mtp draft_limit=7 與 listening address=http://0.0.0.0:8741。

載入時間：頁快取熱＋RAM 乾淨只要 13 秒（官方 C1 基準 15.45s，llama.cpp 117.8s）；第一次冷載（daily 服務還在跑）675 秒 — 差在頁快取與 swap 壓力，不是引擎慢。

3.3 GTT 設定（整份文件的關鍵，不修直接 OOM）

翻車現場：104G 模型載到一半 hipMalloc failed for blk.38.ffn_up_exps.weight (471859200 bytes) — AMD 內建 carve 512MiB GTT 上限不夠 MoE 專家分塊。HSA_FORCE_FINE_GRAIN_PCI=1 無效。

修法（持久化，重開機有效）：

# /etc/modprobe.d/ttm-limit.conf
options ttm pages_limit=31457280
options ttm page_pool_size=31457280
# 31457280 頁 × 4KiB = 120 GiB GTT；並同步進 BLS 與 /etc/default/grub：
# ttm.pages_limit=31457280 ttm.page_pool_size=31457280（舊參數 amdgpu.gttsize 刪掉）

重開驗證：dmesg 出 122880M of GTT memory ready，64 GiB hipMalloc 成功。

3.4 ContinuationCache 語義（測錯會誤判沒 cache）

gufo 快照 = prompt＋回覆的整段狀態（Flash-Next 還含 GDN recurrent/indexer/sampling 狀態），續用條件是「快照 tokens 是新 prompt 的精確前綴」。所以：

• 「同一個 prompt 打兩次」→ 第二次比快照短，天然 miss（我第一次就測出滿盤 miss，文件讀完才懂是方法錯）
• 「對話式第二輪」→ turn1 prompt＋回覆正是 turn2 的前綴 → hit

記憶體層永遠開；disk 層（--cache-disk）測試未開。

3.5 地雷（全踩過）

1. LD_LIBRARY_PATH=/opt/rocm/lib 少了就死在 libhipblas.so.3。
2. GTT 沒修 → blk.38.ffn_up_exps hipMalloc 失敗（§3.3）。
3. screen 手動跑重開機即失；正式化要 systemd（含 LD_LIBRARY_PATH）。
4. prefill 用「同源文字取前綴」測，大點位可能被前綴快取污染（§4.2 有雷標記）。

---

4. 實測速度（對標 halogen flash-next 0.16.0，同機同題，2026-10-02 更新後重測）

llama.cpp就不測了、沒有競爭力，以下都是開mtp測試

4.1 Decode

口徑	gufo	halogen 0.16.0 同題	備註
temp 0.4、250 out、MTP 開 ×3	47.5／48.3／48.2 → 48.0	50.4	掛 MTP 也只到 95%；另注意 halogen 0.16.0 同題改自然停（ct 124–150，finish=stop），舊版是砍滿 250
greedy tg128（官方口徑）	fib 49.3、coding 53.1、json 50.0、repetitive ~74	fib 64.1、coding 56.8、json 60.8、repetitive 78.2	halogen 全面領先（fib +30%；coding/json 首發冷，暖跑 63／68）
json 原生約束 response_format	36.9 tok/s、JSON_VALID ✓	49.7 tok/s、147 tok finish=stop、JSON_VALID ✓	兩台約束稅都 ~25%，halogen 級距高一檔

官方 d0 基準對照：AR tg 25.87、MTP mixed 32.20、repetitive 59.30 — 兩台的 greedy 都高於官方 mixed；repetitive 上 gufo ~74、halogen 78.2 都贏官方 59.30。

4.2 Prefill階層速度

prompt（actual）	gufo	halogen 0.16.0	差
~1.5K	1020.9（1,539）	1139.3（1,509）	halogen +12%
~3K	1162.8（3,042）	1366.4（2,961）	halogen +18%
~6K	1345.9（6,077）	1528.5（5,895）	halogen +14%
~12K	1391.3（12,135）	1597.5（11,746）	halogen +15%
~18K	1400.1（18,135）	1704.8（17,543，峰值）	halogen +22%
~38K	1393.3（38,474）	1684.0（37,192）	halogen +21%
~104–107K	1303.4（107,248，82.3s）	1594.8（103,632，65.0s）	halogen +22%，wall 快 17 秒
~185–191K	1268.3（191,307，150.8s）	1518.7（184,837，121.7s）	halogen +20%，wall 快 29 秒

0.16.0 反轉：舊版 16K 只有 1219.5、198K 1320.9；新版全程 1139→1705→1519，每一階都贏 gufo 12–22%，185K 只花 122 秒。
️ gufo MTP 開的階梯有同源前綴污染（103K 點噴 5051 tok/s），gufo 欄採非 MTP 乾淨版；MTP 版待重測。

4.3 Cache（16K 級長 prompt）

	gufo	halogen 0.16.0	舊 halogen（0.6.1）
對話式第二輪	冷 13.36s → 暖 0.29s（×46）	冷 11.24s → 暖 0.398s（×28.3）	—
相同 prompt 兩發	設計上天然 miss（快照含回覆）	冷 10.89s → 暖 1.118s（×9.7）	冷 10.7s → 暖 0.2s（×50）

gufo 對話續用更快；halogen 兩種測法都命中，但 identical 暖端從 0.2s 退到 1.1s（restore 路徑變貴，語義待查）。快照語義見 §3.4。

4.4 Agentic（自寫 ReAct harness t1–t8，工具全開）

	gufo	halogen 0.16.0（同 harness）
分數	8/8，迴圈 0、核彈 0	8/8，迴圈 0、核彈 0
tps 範圍	27.7–37.4	21.7–43.2（t6 一發直拒 rm -rf /）

兩台全過；halogen 天花板高（43.2）、地板低（21.7），gufo 穩在 28–37。

---

5. 測速總表

項目	gufo flash-next（Q4 104G）	halogen flash-next 0.16.0（179B 5.53bpw）
decode greedy tg128	fib 49.3／coding 53.1／repetitive ~74	fib 64.1／coding 56.8／repetitive 78.2
json 約束（JSON_VALID 兩台 ✓）	36.9	49.7
prefill 16K 附近	1391.3	1597.5
prefill 111K 附近	1303.4（107K，82.3s）	1594.8（104K，65.0s）
prefill 198K 附近	1268.3（191K，150.8s）	1518.7（185K，121.7s）
cache 對話第二輪	0.29s（×46）	0.398s（×28.3）
cache 相同 prompt 兩發	設計上 miss	1.118s（×9.7）
agentic	8/8（27.7–37.4 tps）	8/8（21.7–43.2 tps）
載入	13s 熱	幾分鐘（68G 冷載）
ctx 上限	262144	262144
體重	104G 磁碟／官方 peak 85.55G	118G 磁碟／95G 常駐（0.6.1 时代數字，0.16.0 待重測）
vision	（mmproj）	（0.6＋）
多模型
模型來源	HF 公開 GGUF	專屬 checkpoint

---

6. 結論：兩台專用推論引擎的優缺取捨

一句話（0.16.0 更新後）：halogen 今天這版把速度面全面拉開 — decode 與 prefill 每一項都贏 gufo 12–30%；gufo 剩下的牌是開源模型自由度、官方品質實證、對話 cache 續用、13 秒熱啟動。純比快，選 halogen；要折騰權力，選 gufo。

取捨軸	gufo（開源系）	halogen 0.16.0（專屬系）
decode（兩口徑）	48.0 MTP／greedy 49.3–74	50.4／greedy 56.8–78.2，全面 +12~30%
prefill（1.5K→185K）	1021→1400→1268	1139→1705→1519，每階 +12~22%、185K 只要 122s
cache 對話第二輪	0.29s（×46）	0.398s（×28.3）
cache 相同 prompt	設計上天然 miss	命中（×9.7，但比舊版 0.2s 退步）
模型自由度	HF 公開 GGUF，可換 quant、可審計	5.53bpw 專屬 checkpoint
品質保證	官方 QUALITY 全套實證（63 項比對＋公開基準）	temperature 0 byte-identical 保證
agentic	8/8，tps 穩 27.7–37.4	8/8，tps 21.7–43.2（浮動較大）
json 原生約束	36.9（JSON_VALID）	49.7（JSON_VALID）
部署整合	️ 原始碼 build＋手動參數＋GTT 手修；screen 非持久	容器映像、env 全配、auto-download、watchdog、NPU 小模型同端口
載入	13s 熱	十幾秒（68G 冷載）

怎麼選：

1. 純速度（日常 agent＋長文）：halogen 0.16.0 全面贏 — 16K 開局快 15%、185K 快 20%、fib decode 快 30%。
2. 生態與折騰權力：gufo — HF 公開模型隨你換、原始碼可讀、官方基準持續追蹤、--speculative 四種投機模式可玩；halogen 綁定它家 checkpoint。
3. cache 型工作流：對話式續用 gufo 快一截（0.29 vs 0.398）；但 halogen 兩種測法都命中、gufo 只吃對話式 — 看你的請求形狀。

這次對決非常驚人，halogen你怎麼可以愈進化愈快，之前說好的開源呢?

我應該會使用gufo體驗幾天啦

@David-Chen 我認為雙卡5090 就別跑27B了，改用Qwen3.8 flash next吧，現在NVFP4下去擠看看系統RAM跟n-gram SSD，知識量跟思維鍊確實有落差，還更快，供參考

為了讓這類專用推論引擎能移植到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、通用框架，每個通用都收稅；它一個個手寫收回來。這套在它能覆蓋的模型上無敵，代價就是新模型新架構要重寫一遍。