Qwen3.8-27B ROCmFP4 完整部署與實測指南（AMD Strix Halo gfx1151）

實測日期：2026-09-06
測試平台：FEVM FAEX1（AMD Ryzen AI Max+ 395 128GB/ Nobara 44 / ROCm 7.2.4）
目標：專供 Strix Halo APU（gfx1151）使用者直接套用的最速配置指南。

Executive Summary（核心結論）

在 AMD Strix Halo 架構下運行 Qwen3.8-27B，兼顧極限吞吐與智商的黃金組合為，測試文本都以代碼或json schema主要是測出mtp差距：

ROCmFP4 權重（13.75 GB）＋ MTP Q4_0 Draft Head（--spec-draft-n-max 4）＋ 關閉 Thinking 模式。

• 生成吞吐（Decode）：實測達到 40.8～41.7 tok/s，相比未開啟 MTP 的 Stock Q4（~29.0 tok/s）提速接近五成。
• 首字延遲（TTFT）：MTP 因推測樹構建 Overhead，小 Prompt 首字耗時為 2.93s（關閉 MTP 時為 0.83s）。追求極致首字反應建議關閉，追求長文吞吐建議開啟。
• 顯存負擔：模型＋MTP Head＋Vision 投影層＋128K KV Cache（FP16）全載顯存僅耗 ~30.2 GB（UMA 總量 68.7 GB，剩餘空間充足）。
• 推論保真度：在沙盒 ReAct 6 項能力測試中全數通過（6/6），未出現低位元量化常見的格式崩潰或死循環。

1. 測試主機硬體與系統環境

提示：ROCm 10 的 RHEL/Fedora 官方套件庫在截稿時最高支援至 7.2.4。此版本完全穩定，且核心需求僅為 Linux Kernel ≥ 7.0（Nobara 的 7.1.4 已滿足），無需冒險升級未驗證版本。

2. 原始碼編譯與權重準備

2.1 編譯專用 llama.cpp Runtime（官方 ROCmFPX 線）

原生 llama.cpp 無法識別 ROCmFP4 專屬的自訂算子（GGML Type 100–106），必須採用專屬 Fork 分支：

# 1. 複製官方 ROCmFPX 倉庫（建議放置於 Gen4 NVMe 上以加快 I/O）
git clone https://github.com/ROCmFPX/ROCmFPX.git /mnt/nvme-data/ROCmFPX
cd /mnt/nvme-data/ROCmFPX

# 2. 設置 ROCm 編譯環境變數
export PATH=/opt/rocm-7.2.4/bin:$PATH
export HIP_PATH=/opt/rocm-7.2.4

# 3. 執行 Strix 專用建置腳本（支援 HIP + Vulkan 雙後端）
bash scripts/build-strix-rocmfp4-mtp.sh

• 編譯產物：build-strix-rocmfp4/bin/llama-server
• 編譯耗時：32 核心約需 30–60 分鐘。全程為純 CPU 編譯，可置於背景執行，不影響線上運算。
• 避坑警示：請勿使用早期社群的 charlie12345 分支，其 MTP 實作在 gfx1151 架構下會引發 Crash；官方 ROCmFPX 倉庫已修復該問題。

2.2 模型三件套下載清單

部署需下載主模型、推測解碼頭（Draft Head）與多模態投影層（mmproj）：

# 建立存放目錄
mkdir -p /mnt/nvme-data/models

# 下載主模型與 MTP Head
hf download kingjones777/Qwen3.8-27B-ROCmFP4-STRIX-MTP-GGUF \
  --include 'Qwen3.8-27B-Q4_0_ROCMFP4_STRIX.gguf' \
  --include 'mtp-Qwen3.8-27B-Q4_0.gguf' \
  --local-dir /mnt/nvme-data/models/

# 下載多模態 mmproj 並更名
hf download unsloth/Qwen3.8-27B-GGUF \
  --include 'mmproj-F16.gguf' \
  --local-dir /mnt/nvme-data/models/

mv /mnt/nvme-data/models/mmproj-F16.gguf \
   /mnt/nvme-data/models/mmproj-Qwen3.8-27B-F16.gguf

存放建議：總體積約 16.2 GB，請務必放置在 PCIe Gen4 資料碟（nvme1n1），能顯著縮短啟動與模型載入（Cold Start）時間。

3. 服務啟動與完整參數配置

3.1 一鍵啟動指令

#!/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

# 規避 Shell 引號展開問題，透過環境變數傳遞思考開關
export LLAMA_ARG_CHAT_TEMPLATE_KWARGS='{"enable_thinking":false}'

/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 \
  --model-draft /mnt/nvme-data/models/mtp-Qwen3.8-27B-Q4_0.gguf \
  --spec-type draft-mtp \
  --spec-draft-ngl 99 \
  --spec-draft-n-max 4 \
  --spec-draft-n-min 0 \
  --spec-draft-p-min 0.0 \
  -a qwen3.8-27b-rocmfp4 \
  -ngl 99 \
  -fa on \
  -ctk f16 -ctv f16 \
  -c 131072 \
  -b 4096 -ub 2048 \
  --reasoning off \
  --jinja \
  --temp 0.4 --top-p 0.95 --top-k 20 --min-p 0.0 \
  --image-min-tokens 1024 \
  --host 0.0.0.0 --port 8080

3.2 參數核心解析

3.3 常見地雷 Check-list

1. 模板參數展開失敗：若將 --chat-template-kwargs 包裹在 Shell 變數中，容易因引號解析錯誤導致伺服器崩潰。請務必使用 LLAMA_ARG_CHAT_TEMPLATE_KWARGS 環境變數傳遞。
2. Draft Head 規格錯誤：MTP 務必認明 Q4_0。使用 Q8_0 會直接破壞推測解碼的加速效益。
3. 推測步數過長：不要使用預設的 n-max 16，請固定設定為 4。
4. Vulkan 後端不相容：ROCmFP4 專屬算子不支援 Vulkan 後端，請維持預設的 ROCm/HIP 後端運行。
5. 多模態權重混用問題：切勿混用 Qwen3.6-27B 的 mmproj，因 Hidden 維度不一致（5120 vs. 2048），伺服器將拋出 n_embd mismatch 錯誤。

4. 實機基準測試數據

測試條件：系統時間 08:07–09:xx，MTP 全開，--spec-draft-n-max 4。

4.1 Prefill 效能階梯測試（2K → 128K）

同 Prompt 階梯式放大測試，記錄真實耗時（Wall-clock Time）與預填充速率：

Prefill 速率曲線圖 (Roofline)
Tokens/s
  500 |
  400 |                     [16K 峰值: 425]
  300 |             [8K: 372]      [32K: 401]
  200 |     [2K: 250]                       [64K: 277]
  100 |                                              [128K: 151]
    0 +---------------------------------------------------------
      0     16K     32K     48K     64K     80K     96K    112K   128K

4.2 首字延遲（TTFT）與生成吞吐（Decode）

首字延遲（TTFT）對照（Prompt: 756 tokens）

生成吞吐（Decode）對照（250 tokens 生成，Temp: 0.4）

4.3 Agent 實戰流量與資源佔用

• Agentic 往返吞吐：在自研 ReAct 框架（t1–t6）多輪工具調用實測中，平均輸出速率為 23–35 tok/s。因結構化輸出（如 JSON Schema）的例外較多，MTP 命中率略為下降，但依然高於原生自回歸。

• MTP 驗證接受率：

• 單輪常規生成：0.95 ～ 0.97

• Agent 多輪工具調用：約 0.80 ～ 0.88

• 實體顯存佔用（rocm-smi）：

• 模型本體（13.75 GB）＋ MTP Head（1.6 GB）＋ mmproj（885 MB）＋ 128K FP16 KV Cache

• 實測總用量：30.2 GB / 68.7 GB（剩餘約 38.5 GB，可支援多開小型模型或高併發 Session）。

5. 推論可靠度驗證（ReAct 沙盒測試）

在獨立沙盒內執行 ReAct t1–t6 複合自動化測試（涵蓋搜尋、錯誤恢復、長日誌診斷與陷阱題），對比其他方案之表現：

評測維度與測試案例	Qwen3.8 27b ROCmFP4	Qwen3.8 27b Q4	Ornith 1.5 35B（參考）
t1 檢索 / t2 連鎖呼叫 / t3 狀態恢復	通過	通過	通過
t4 多重 Debug (8/8 關節點)	4 步通過（最速）	7 步通過	9 步通過
t5 惡意/自殺陷阱排除	3 處陷阱全避開	通過	通過
t6 複合長報錯日誌診斷	通過	通過	通過（需修正路徑 Bug）
異常中斷 / 思考死循環次數	0 次	0 次	0 次
總結得分	6 / 6 (滿分)	6 / 6	6 / 6

結論：社群對於 FP4 低位元量化「缺乏 QAD 蒸餾易降智」的疑慮，在標準 ReAct 測試中並未發生。模型在語法約束、邏輯剪枝與自我除錯上均表現正常。

體驗是相當不錯，以我395米你主機來說，之前是慢，現在是可用程度
這邊大家一起試試不同A卡的差距如何。