Strix Halo（gfx1151）本地部署 DeepSeek V4 Flash — 環境、失效、可行與技術總結
引言：從 Loose Box 影片到真實部署
Loose Box 專案的影片 與 官方技術文件 展示了令人印象深刻的成果：同樣的 Strix Halo（gfx1151）、同樣的 128GB LPDDR5X，用客製 ROCmFPX 量化模型 + DSpark 投機解碼，decode 達到 32.0 tok/s，sparse prefill 達到 ~250 tok/s。
我在同樣的硬體（Asus ROG Flow Z13 GZ302EA，Ryzen AI Max+ 395，Radeon 8060S，128GB）上用 同樣的 Loose Box 專案（Claude Code 協助部署）實作，結果有幾個關鍵差異，值得完整記錄。
核心結論（先看這裡）：
- decode 29.7 tok/s，已達官方紀錄的 91%，對話式使用體驗良好。
- prefill 與官方差距大，原因不是設定錯誤，是量化版本不同：
- 官方 250 tok/s sparse prefill 建立在 ROCmFPX 客製量化（平均 2.88 bits/parameter）+ 專屬 kernel 之上。
- 我用標準量化版本，exact prefill 實測 20–32 tok/s，與官方 exact prefill 數據（22.5 tok/s）吻合——這才是 Strix Halo 沒有客製量化下的真實表現。
- 因 RTX 5090 eGPU 在 Linux 下無法成功啟動，不再嘗試跑客製量化版本。
- 接 agent 前務必算清楚： 如果你的系統提示超過 2K tokens，exact prefill 會花 1–3 分鐘。
以下從完整技術紀錄中節錄 Strix Halo 部署 DS4 的環境、失效、可行、技術總結。
環境
| 項目 | 規格 |
|---|---|
| 機器 | ASUS ROG Flow Z13 (GZ302EA) |
| SoC | AMD Ryzen AI MAX+ 395 (Strix Halo) |
| iGPU | Radeon 8060S, gfx1151 (RDNA 3.5), 40 CU |
| 記憶體 | 128 GB LPDDR5X 統一記憶體 (~270 GB/s) |
| SSD | WD_BLACK SN770M 2TB (DRAM-less, HMB) |
| OS | Ubuntu 26.04 LTS, kernel 7.0.0-14 |
| ROCm | 7.1.1 (Ubuntu 內建) |
| 模型 | DeepSeek V4 Flash, 95.3 GiB, 256 experts MoE |
BIOS carve 調整
Strix Halo 的 BIOS 把 128 GB LPDDR5X 切成「RAM 側」與「VRAM carve」兩塊。部署 DS4 必須把 carve 調到最小（512 MB），讓 ROCm 改用 GTT 借主記憶體。
如果 carve 還在 96/32 就開 Ubuntu： 系統 RAM 只剩 32 GB，DS4 的 95.3 GiB 載不進去。GTT 是 pinned、OOM killer 殺不掉 → 整台凍結，不是乾淨報錯。
失效路線
| 路線 | 結果 | 原因 |
|---|---|---|
amdgpu.gttsize 不調 |
載入失敗 | iGPU 預設只能借用約一半系統記憶體（實測 61 GiB） |
ttm.pages_limit 未與 gttsize 對齊 |
載入失敗 | TTM 另外卡住 |
amd_iommu=on iommu=pt |
decode 從 29.10 掉到 0.60 tok/s（1/48） | 統一記憶體分頁遷移每次都要過 IOMMU 位址轉換 |
| earlyoom 預設值 | 模型載入完成就被殺 | 預設「可用記憶體低於 10% 就動手」，模型正常就佔 88% |
/opt/rocm/lib → /usr/lib/x86_64-linux-gnu symlink |
cmake 找不到 amd_comgr | amd_comgr-config.cmake 從自身剝 4 層推算前綴，symlink 層數不對 |
可行設定
GRUB 開機參數（關鍵）：
amd_iommu=off amdgpu.gttsize=126976 ttm.pages_limit=32505856 ttm.page_pool_size=32505856
gttsize=126976(MB) = 124 GiBttm.pages_limit必須與 gttsize 對齊（32505856 × 4KiB = 124 GiB）- 驗證：
dmesg | grep GTT應出現126976M of GTT memory ready
反直覺的發現：模型其實不住在 GTT 裡
ggml_cuda: device 0 integrated, alloc 94.9 GiB (> 45% of 124.9 GiB RAM)
-> unified (managed) memory
mem_info_gtt_used = 12,020 MiB ← GTT 只用了 12 GiB
dflash_server RSS = 99.7 GiB ← 模型在一般系統記憶體
模型走
hipMallocManaged統一記憶體路徑，124 GiB GTT 上限並不是實際約束條件。
Ubuntu 26.04 的佈局差異：
- 套件名稱：
libhipblas-dev、librocwmma-dev（不是hipblas-dev） /opt/rocm正確做法：sudo ln -sfn /usr /opt/rocm- rocWMMA 標頭不完整，必須手動從 GitHub
rocm-7.1.0branch 補上
earlyoom 修正：
EARLYOOM_ARGS="-m 3 -r 3600 --avoid '(^|/)(dflash_server|llama-server)$'"
實測效能
| 指標 | 數值 |
|---|---|
| decode（有投機解碼） | 29.7 tok/s（命中率 0.957） |
| prefill（644 tokens） | 20.2 s（31.9 tok/s） |
| prefill（10,422 tokens） | 527.5 s（19.8 tok/s） |
| 溫度 | 從 60°C 衝到 91–94°C，長 prefill 可達 101°C |
比對 Loose Box 官方數據：
| 項目 | Loose Box 官方 | 我實測 |
|---|---|---|
| decode（有投機解碼） | 32.0 tok/s | 29.7 tok/s（91%） |
| decode（無投機解碼） | 25.3 tok/s | ~20 tok/s |
| exact prefill（短 prompt） | 22.5–23 tok/s | 31.9 tok/s |
| exact prefill（8K tokens） | 16.46 tok/s | 19.8 tok/s（10K） |
| sparse prefill（8K tokens） | 251.79 tok/s（ROCmFPX 客製） | 未用客製量化 |
️ 因 RTX 5090 eGPU 在 Linux 下無法成功啟動（Blackwell + USB4 + Linux CUDA 運算必崩，見第二篇），未能嘗試在 5090 上跑 Loose Box 客製量化版本。
技術總結
- 記憶體很夠，GTT 設定正確就能載入接近 100 GiB 的模型。
- decode 表現超出預期， 29.7 tok/s 已達 Loose Box 紀錄的 91%，對話式使用體驗良好。
- prefill 是硬傷， LPDDR5X ~270 GB/s vs 960 GB/s，參數調不動。接 agent 前先算清楚系統提示要多久才能消化完。
- 散熱是真實限制， 平板形態的機身在持續滿載下必然降頻，長時間使用考慮外接散熱。
- IOMMU 開著不能用， 會讓 decode 掉到 1/48。
- sparse prefill 的 250 tok/s 需要客製 ROCmFPX 量化 + 專屬 kernel， 標準版本做不到。
在那之前，雙開機用 Windows 是完全合理的答案，不是妥協。
立即整機斷電，無一次例外