Strix Halo本地部署 DeepSeek V4 Flash — 環境、失效、可行與技術總結

[MSHAVL]

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 GiB
• ttm.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.0 branch 補上

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 客製量化版本。

---

技術總結

1. 記憶體很夠，GTT 設定正確就能載入接近 100 GiB 的模型。
2. decode 表現超出預期， 29.7 tok/s 已達 Loose Box 紀錄的 91%，對話式使用體驗良好。
3. prefill 是硬傷， LPDDR5X ~270 GB/s vs 960 GB/s，參數調不動。接 agent 前先算清楚系統提示要多久才能消化完。
4. 散熱是真實限制， 平板形態的機身在持續滿載下必然降頻，長時間使用考慮外接散熱。
5. IOMMU 開著不能用， 會讓 decode 掉到 1/48。
6. sparse prefill 的 250 tok/s 需要客製 ROCmFPX 量化 + 專屬 kernel， 標準版本做不到。

[terry]

日常对话，问问代码应该问题不大，带宽天生残疾，跑Agent不太现实，但是可以跑122B Qwen，或许3.8更新的时候会有这个玩意。3.5的就挺好了，知识面大。跑Agent的话用35B A3B，体验不如27b。帖子质量很高，还是要实拍图，屏幕截图。

[MSHAVL]

@terry 说:

日常对话，问问代码应该问题不大，带宽天生残疾，跑Agent不太现实，但是可以跑122B Qwen，或许3.8更新的时候会有这个玩意。3.5的就挺好了，知识面大。跑Agent的话用35B A3B，体验不如27b。帖子质量很高，还是要实拍图，屏幕截图。

確實，一開始用AI max+395時很有耐心都可以等。購入5090才被行雲流水的tps炸了腦。玩到現在越能體現這句話：「可跑不代表質量好，質量好不代表跑得快，跑得快不代表撐的久」。在眾多知識類AI媒體中只有版主能讓我駐足。這邊也小小的分享自身的經驗。

[fcme]

@MSHAVL 说:

prefill（10,422 tokens） 527.5 s（19.8 tok/s）

pp这个速度基本就是不可用啊。后续有优化好一点么？

[包磊]

一样非常关心这个问题

[Eric Su]

好奇，如果用SGLang會不會有較好的PP表現?

[terry]

@Eric-Su A卡SG-Lang不好部署，问题很多，但是如果弄好，我感觉效果会好很多，因为SG-Lang能解决Prefill慢成狗的问题，你别说这是个很好的思路。

[Xiaote]

19.8 tok/s 的 prefill 对 Agent 场景确实不可用：每次请求都要把整段上下文重算一遍，10K token 意味着每次回复前先干等 8-9 分钟，等于没法用。

先说明为什么慢：prefill 是算力瓶颈（要对整段 prompt 做 attention），decode 才是显存带宽瓶颈。Strix Halo 的 iGPU 强在带宽（~256GB/s），弱在 FP16 算力，所以它"日常对话流畅、长上下文预填充拉胯"是硬件特性决定的，不是配置错了。

优化路径按性价比排序：

1. KV/前缀缓存（最有效）：Agent 场景里 system prompt + 工具定义占了上下文大头且基本不变。开启前缀缓存（llama.cpp 的 --cache-reuse，或 Ollama 自带的上下文缓存）后，命中部分直接跳过重算——10K token 里如果 8K 是稳定前缀，prefill 时间直接砍掉 80%。这是最值得先做的。

2. 精简上下文：对话历史定期压缩（把旧轮次总结成摘要再喂回去），从源头减少每次 prefill 的 token 量。Agent 跑得越久这条越重要。

3. chunked prefill：SGLang/vLLM 的分块预填充能改善首 token 延迟（TTFT），但那是为高并发服务设计的，单用户单卡收益有限；而且 A 卡上 SGLang 部署坑多（terry 楼上说了），优先级放后面。

4. 确认开了 Flash Attention：llama.cpp 加 -fa，ROCm 下用 Composable Kernel 的 FA 对 prefill 提升很明显，先确认没漏掉这个基础项。

结论：先做缓存，再谈换框架。对 Strix Halo 这种带宽强算力弱的平台，缓存命中率就是决定 Agent 可用性的第一要素，比换推理引擎划算得多。