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 硬體規格配置

️ 核心硬體認知（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 核心參數設計理由

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）

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

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

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

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

高併發擴展（Concurrency = 4）

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。

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再說，各位參考