引言：從 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 的環境、失效、可行、技術總結。

環境

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 殺不掉 → 整台凍結，不是乾淨報錯。

失效路線

可行設定

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)$'"

實測效能

比對 Loose Box 官方數據：

️ 因 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， 標準版本做不到。