以AI Max+ 395配置SGLang

dardeaw feng

早先有發了一個帖子是講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再說，各位參考

terry

非常好的帖子，AMD小主机的春天。

张光璞

小主机的算力还是太弱了

dardeaw feng

@张光璞其實還好耶，這台很好玩呀，可以當服務器，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

抡锤者