雖然現在strata當紅，但strata並不具備高併發能力

我已有兩台strata主機，速度跟智商也不錯，但有個絕對致命傷 - 只適合單流對話
一遇到多對話就得排隊，完全不適合做為服務，
strata這種推論框架只建議用高性價方案去簡單拼湊就好，不要花大錢，多對話排隊的體驗不佳，
真正的高併發，在於總吞吐量要隨著對話數量提高，並且不同對話之間不能有過久的等待，
手上還有AI Max+395，為了展現他的價值，我開啟了手搓推論引擎之旅，
兩個月前因Halogen的專用引擎效率很好，曾經試著魔改llama.cpp成自製引擎想要跟Halogen比拚效能，拚了兩天就投降因為halogen確實先天上就贏llama.cpp太多了

一直到了gufo的出現

gufo發布約晚halogen三週，但他開源呀!!
我們先談談Halogen最大的缺點，要把他取代掉就得從這邊下手
第一，它是黑盒。docker拉來跑，只能調環境變數，裡面長什麼樣全靠猜。想加模型？此路不通，想加功能？門都沒有。
第二，它卡死的點是結構性的，排程的機制、KV的量化機制全部他說的算。
第三，幾乎無高併發能力，除了預訂了四個slots做緩存增量快取與舊對話落盤SSD，其餘都是單對話思維做的設計。

以 gufo為底進行改造。理由就一個：看得見、改得動，
它的基底是半套高併發理由如下：
1.它有batch但不是mixed batch，他有chunked prefill但不會左手prefill右手decode
2.它的排程與插隊只有先進先出，跟llama.cpp、strata也一樣
3.它的KV機制是fork的增量快取，類似較粗的radix tree，若把增量快取機制來比喻，SGlang是樹葉級、gufo是樹枝級、而llama.cpp、strata、halogen等都只是各別獨立的樹幹各自做增量快取。

MBufo

針對以上經驗，專為 AMD Strix Halo 打造的 gufo 分支，
定位為公平性＋高效低銷的推論引擎——排隊不插隊靠公平調度，花費少靠低精度計算。

上游 gufo 負責單路極限效能；MBufo 真的做到服務端的問題：一台 Strix Halo 節點同時面對十六路請求時能跑多滿，每一路又能吃多長的上下文？三根支柱回答它——負載下公平的排程（§1）、更高壓縮的KV快取（§2）、一個 port 服務多顆模型的 GGUF覆蓋（§3）。底層引擎、核心與絕大部分程式碼都來自上游，在此致謝 gufo-org 及所有貢獻者。

而同為RDNA3/4家族的7900XTX、R9700應該也能稍做修改就相容(但以VRAM為基準無法合併系統RAM使用)，
甚至能魔改出雙卡TP，無奈我手上沒有設備能開發測試。

MBufo 三個數字

§1 高併發（架構差異）

併發不是一個數字。一台吃重的伺服器能不能用，是兩件事決定的，直接影響使用上的體感：

• ITL（token 間延遲）——請求已經在串流之後，它前後兩個 token 之間的間隔。 批次效率再高，只要會讓一條會話凍住一整個 prefill 步驟，那就不叫服務，那叫排隊加上額外手續。
• 公平性——沒有任何 session、客戶端或 prompt 可以讓別的對話等不到。一段 25 萬 token 的 prompt 插進對話中途，不該比十六路短對話得到更多資源。

原先gufo的排程器骨架已經是對的：prefill chunk 有上限、有待跑decoder 時先服務 decode 再做 prefill、admission 有每客戶端上限。它缺的是「便宜地同時兌現這三件事」：一個有上限的 chunk 仍然吃掉一整個 tick，而那個 tick 裡沒有任何 decoder 產出 token——因為 chunk 與 decode 是兩趟分別掃過權重的計算。ITL 與公平性就是從這個 tick 漏掉的：每一輪，串流中的請求都要付一次與它無關的 prefill 步驟。

MBufo 把兩者合併：chunk 與 decode 列共用同一個 ForwardBatch、同一個注意力核心，於是 prefill 的那個 tick 也順便把該出的 token 全部產出。合併沒有繞過公平政策；公平政策正是讓合併安全的前提。

統一 mixed-batch 介面 統一KV量化介面

以物件導向(OOP)實作各模型的引擎，使得所有支援的模型都能享受到Mixed Batch的好處與支援各種KV量化

公平性：排隊不插隊（SRTF＋飢餓 decode 優先搶佔＋near-done 閘門）

長 prefill 曾把短請求的 TTFT 擠爆（5 進 4 反飢餓場景）。三個機制修掉它，全程保持貪婪輸出位元一致（sha 比對通過：24K prefill 單跑與併發跑出相同 sha）：

• SRTF prefill 選取——剩餘 ≤1 個 chunk 的 near-done prefill 排在長 prefill 續片前面（同級按 FIFO）。
• 飢餓 decode 優先搶佔——有請求在排隊等 session 槽位時，長 prefill chunk 讓路， 先把常駐 decode 排空，好讓等待者一有常駐完成就被接納。
• near-done 閘門——只有當某個常駐 decoder 距 token_limit ≤64 token（槽位即將 空出）才觸發搶佔；若常駐全是長輸出 decoder，就不做無意義的 prefill 延遲。光是這個 閘門就把 fairness-A 從 76.5 拉回 7.32。

投機解碼（MTP / DFlash）

• Qwen Flash-Next MTP——併發寬度 2/3/4 的接受率 ** 88.7/91.6/89.5%**。接受率不再隨 batch 衰減，本構建
  穩在 ~90%——各寬度總吞吐全面超過上游（97/111/133 對 70/105/112）。
• Qwen 27B DFlash2——支援 blocked-Q8 KV（verify 寫進 blocked sidecar，continuation快取與 serve 磁碟身分位元級攜帶）； decode（short/prose/code/json 22.9/19.5/56.2/52.3 tok/s）。
• Muse Glimmer DFlash——端到端投機草稿 ~89%。
• Gemma 4 MTP——async-GPU 草稿重寫＋單 forward verify 之後，decode 達 74–86 tok/s

多 sessions 生產配置範例 (以Strix Halo 128G搭配 Qwen Flash Next為例)

排程器保證什麼

多模型 router

一個 port、多顆模型。serve llm --multi-model 把伺服器變成模型 registry：啟動模型成為預設，每個請求依 model 欄位路由到對應模型。模型可在執行期增減（admin API）——不重啟、不斷線。

§2 提供更多壓縮精度（成本差異）

建議使用 q8。 blocked 模式在編解碼層級是位元精確的；f16 仍是預設與基準。4-bit 路徑是給「KV 記憶體成為瓶頸」的機器手動開啟的環境變數鉤子，不是--kv-quant 的格式選項，也不會改變任何預設值——未設定時引擎與不含這些路徑的版本位元相同（以 logit dump 雜湊比對驗證）。完整說明見 docs/KV-V4.md。

佔用

每個 KV 位置的位元組數，以及 -c 262144、Qwen3.8 Flash-Next 12 個注意力層下單一 session 的總量：

代價（量出來的）

以 q8 為基準的正確性：三個互不相關的 400-token 上下文、各 98 步matched-token decode、對三個上下文取平均：

支援模型權重精度：W8A8／ROCmFP4／MXFP4／Q4_K

逐模型精度表

對比 llama.cpp（v0.28.0，gfx1151）

同權重、release build、greedy；prefill＝冷 KV 單流 tok/s，decode＝開投機 tok/s。正數＝MBufo 較快。六格數字皆為 CHANGELOG 量測到的 v0.28.0 開發期數字原文重述。

此次版本推進未跑模型服務效能測試；上表為量測到的 v0.28.0 開發期數字重述，此處未重測。

§3 GGUF 相容（覆蓋承諾）

支援的模型（v0.28.0）

將經典模型架構都做出支援，除了LLM並且能載入Embedding與Reranker
Qwen3.8 Flash-Next、Qwen3.8 27B 、 Qwen3.6-35B-A3B 、Gemma 4、 GPT-OSS 20B／120B 、Muse Glimmer 30B、Llama-3.1、Qwen3-Embedding、bge-m3、bge-reranker-v2-m3、Qwen3-Reranker

§4 效能測試 單對話基準（MBufo，以gfx1151 Strix Halo測試）

冷 KV（每請求唯一 prompt，cached_tokens≈0）、think off、F16 KV、-j 1、
ctx 262144。四組設定：27B（UD-Q4_K_XL 對 ROCmFP4-FAST）＋ Flash-Next（ROCmFP4-FAST
對 UD-Q4_K_XL）。投機：27B＝DFlash2、Flash-Next＝MTP。（註：舊中文版此節為 v0.24.1
數字，已同步為與英文版一致的 v0.25.5。）

這些是單流數字，用來隔離模型與建置版本的選擇；負載下改變的是同時能跑幾條，那是
§1 高併發的故事。

Prefill（tok/s，越高越好）

Decode（tok/s，投機開）

標準：5 個冷 KV 情境（標明 temp）＋ 8 任務 ReAct 代理套件。

代理任務（agent_bench_v2，t1–t8，沙箱工具）

§5 效能測試 高併發測試

三引擎投機併發比較表 — Qwen3.8 Flash-Next

引擎：A Halogen 0.18.1（FN v2, .hgn）／B gufo-upstream 0.21.0＋FN Q4_K_XL＋MTP／C MBufo v0.25.3＋FN ROCmFP4＋MTP。FN 投機器＝MTP。

① Decode 總吞吐 total_tps（N=1/2/3/4 併發）

② 平均每 session decode_tps

③ MTP 接受率（batch_width 2/3/4，server 端）：Halogen只在單流時投機，多併發完全沒有增益
④ Prefill 總吞吐（64K 冷，N=1/2/3/4）

⑤ Fairness 退化比（場景 A 混長文／場景 B 混 4K，越低越好）：A 322／1140｜B 15.3／399｜C 18.9／187

⑥ ITL mean／p95／max（ms，注入 4K prefill）：A 83／341／738｜B 49／93／501｜C 43／68／459

判讀

• 單流 decode：A（halogen）最強 84.9（NPU＋獨占 MTP），但 halogen 只在獨占時投機，一旦併發即關投機頭 → per-session 崩到 22–25、總吞吐停滯（75–88）。
• 高併發 decode：C（MBufo）最佳——per-session 平穩 33–42、總吞吐線性到 128.5、N3–N4 反超 B；B 次之；A 最差（投機 off）。
• Fairness：MBufo 場景 B 187 最佳
• 結論：單發求極限速度選 Halogen；併發／代理／多工實戰選 MBufo。

§6 Qwen3.8 27B 高併發測試

① Decode 總吞吐 total_tps（N=1/2/3/4 併發）

② 平均每 session decode_tps

③ Prefill 總吞吐（64K 冷，N=1/2/3/4）

④ Fairness 退化比（場景 A 混長文／場景 B 混 4K，越低越好）：A 187／34.3｜B 200／1832｜C 167／212

⑤ ITL mean／max（ms，注入 4K prefill）：A 49／144｜B 92／1437｜C 91／1408

判讀

• 結論：27B 投機態下 C（MBufo v0.25.6）綜合最佳——單流最快、高併發擴展最好、fairness 搶佔領先；A（halogen）僅單流 ITL 平順但高併發無擴展；B（上游）decode 接近 C 但 fairness 場景 B 差 8.6×。

結論

llama.cpp並沒有針對RDNA運算做到最佳的優化(預設完全沒用到wmma矩陣加速)
sglang對gguf的支援太爛、用AWQ、GPTQ又造成較大的內存開銷，而且對A卡的性能釋放不利
strata沒有高併發魔改的先天條件
為改善使用體驗，以此自製做為範例，若有興趣的可以試著一起開發魔改下去