DeepSeek V4 Flash 運行於單張 AMD MI300X 上 – 效能、修復與部署指南

TL;DR

DeepSeek V4 Flash 在單張 AMD MI300X GPU 上運行，在不使用權重量化或卸載的情況下，使用完整的 3040 億參數檢查點，實現了 168 tokens/s 中位數解碼（單串流）與 ≈ 8 K tokens/s 預填充。這是透過應用一系列 ROCm 補丁、AITER GEMM 調優表以及混合 GPU‑CPU KV 快取策略實現的。

---

為什麼 MI300X 很重要

Instinct MI300X 提供 192 GB 的 HBM3 與 5.3 TB/s 記憶體頻寬，大約是 NVIDIA H100 SXM5 HBM 容量的 2.4 倍。這份記憶體餘裕讓整個 156.7 GB 的 DeepSeek V4 Flash 檢查點可以完全駐留在 GPU 記憶體中，消除了 PCIe 權重串流或層卸載的需求。龐大的 KV 池（GPU 上 20 GB + CPU 層 96 GB）可支援 2–8 個典型的並行串流，以及高達 64 個串流的突發負載。

"MI300X 擁有 192 GB 的 HBM3 與 5.3 TB/s 的頻寬，成本大約僅為同類 NVIDIA 硬體掛牌價的一半。" – AMD product page

此儲存庫的貢獻

GitHub 儲存庫 ryanzhou/deepseek-v4-flash-mi300x 除了先前的研究（Fergus Finn 的 MI300X 啟動與 Doubleword 的演示）之外，還提供了四項關鍵貢獻：

1. 正確性覆蓋層 (Correctness overlays)：針對 ROCm nightly (vLLM ROCm 0.26.1rc1.dev229+g124154a88.rocm723)，修復了 FP8 格式處理、MoE 路由、投機驗證以及 CPU‑KV 同步問題。
2. 經過驗證的服務配置：包含 DSpark‑7 投機草擬 (speculative drafting)、區塊拒絕 (block rejection)、靜態 K=7、2 048‑token 調度預算，以及 1 024‑token 長預填充上限。
3. AITER GEMM 調優表：為上游版本缺失的 gfx942 (MI300X) 形狀提供調優，並為 MXFP4 專家提供 OGS 幾何覆蓋。
4. 混合 KV 策略：20 GB GPU fp8_ds_mla 快取 + 96 GB 原生 CPU 卸載，並包含在 vLLM issue #47282 中記錄的負載路徑柵欄 (load‑path fencing) 修復。

儲存庫結構 (自包含概覽)

.
├─ compose.yaml            # 生產級 Docker‑Compose 堆疊 (vLLM ROCm + Caddy)
├─ Caddyfile.example      # HTTPS 代理範本
├─ vllm-entrypoint.sh      # 啟動前清理過時的 CPU‑KV mmap 檔案
├─ SHA256SUMS              # 所有執行時產物的 SHA‑265 鎖定值
├─ patches/
│  ├─ *.py                # 以唯讀方式掛載的全檔案覆蓋層
│  ├─ diffs/*.patch       # 相對於上游基準的統一 diff
│  └─ README.md           # 來源與重新生成說明
└─ tuning/
   └─ *.csv               # 針對 gfx942 的 AITER A8W8 區塊縮放調優表

關鍵效能數據 (vLLM ROCm nightly 0.26.1rc1.dev229+g124154a88.rocm723, AITER 0.1.19)

指標	結果
單串流解碼 (中位數)	168.6 tok/s
使用調優內核的預填充	≈ 7.9–8.5 K tok/s (新提示詞下為 6 988–7 019 tok/s)
8 個並行串流	總計 542 tok/s，每串流中位數 90.3 tok/s
64 串流突發	總計 830 tok/s，無 OOM 或引擎錯誤
上下文窗口	已驗證 256 K tokens (架構支援高達 1 M)
HBM 中的權重	156.67 GiB (無額外量化或卸載)

兩項關鍵正確性修復

MXFP4 路由錯誤

MoE bitmatrix 內核將區塊列填充至 Triton 區塊大小，但卻針對全域張量邊界進行遮罩，導致負載下路由毀損。覆蓋層將遮罩替換為：

mask = (offs_local < BLOCK_SIZE) & (offs_global < nonzero_indx_size)

這還為分組 MXFP4 專家增加了融合 SiLU 與快速 DeepSeek 路由。

FP8 格式不匹配

DeepSeek V4 Flash 的 Lightning Indexer 快取以 AMD 的 FNUZ E4M3 佈局 (16×16 tile‑shuffled) 寫入 FP8，而上游 AITER 預期的是 OCP E4M3 佈局。覆蓋層強制使用 float8e4b8 並設定 FP8_MAX=224.0 並應用必要的洗牌 (shuffling)，防止在 MI300X 上出現兩倍的縮放誤差。

投機解碼配置

此堆疊使用 帶有區塊拒絕的機率草擬 (probabilistic drafting with block rejection, DSpark‑7)。兩個 Gumbel‑noise 覆蓋層使草擬建議的雜訊與拒絕/恢復雜訊保持獨立，這僅在 draft_sample_method=probabilistic 時需要。

生產級調優細節

優化項目	觀察到的效果
為 gfx942 調優 21 個常見的 A8W8 GEMM 形狀	解碼吞吐量提升 +42–62% (單/雙串流)
融合 SiLU + 快速路由 + 批次敏感專家區塊	原生 C1 解碼從 34.5 → 56.6 tok/s (+64%)
BLOCK_H=64 稀疏預填充區塊	預填充 7.9–8.5 K tok/s；稀疏注意力追蹤從 317 → 142 ms/請求
靜態 K=7 + 區塊拒絕 + 因果驗證	單串流 119.5 tok/s 且輸出正確
2 048‑token 預算 + 1 024‑token 長預填充上限	在 52 K 冷預填充後的短請求 TTFT 從 8.2 s 降至 0.5 s
混合 KV (20 GB GPU + 96 GB CPU)	相當於 1.93 M‑token 的容量，可容納七個 256 K 請求

並行測試 (不同約 400 字提示詞, temperature=1.0, top_p=0.95)

串流數	總計 tok/s	每串流解碼中位數	p50 TTFT
1	126.2	168.6 tok/s	1.026 s
2	145.4	152.7 tok/s	0.939 s
4	316.8	108.6 tok/s	0.369 s
8	542.3	90.3 tok/s	1.027 s
64	830.2	16.4 tok/s	2.190 s

註： DSpark 接受率隨提示詞內容而異；這些數字反映此特定 Docker 鏡像與配置，而非通用模型基準測試。

部署檢查清單

1. 硬體 – 單張 MI300X (gfx942, 304 CUs, 192 GiB HBM)、AMD 驅動程式、Docker Compose、235 GiB RAM、~500 GB 硬碟。
2. 拉取鎖定版本 – 使用 digest 鎖定的鏡像 vllm/vllm-openai-rocm@sha256:e68d18b2… 並下載模型版本 7872f01b1d…。
3. 驗證覆蓋層 – 首次啟動前執行 sha256sum -c SHA256SUMS。
4. 啟動堆疊 – docker compose up -d；觀察日誌以確認成功啟動（模型載入、KV 快取大小、CUDA graph 擷取）。
5. 預熱內核 – 執行一次未快取的預填充 (~8 K tokens) 以初始化內核；隨後的請求會更快。
6. 冒煙測試 – 透過 Caddy 代理的 /v1/completions 端點發送一個簡單的補全請求。

生產環境注意事項

• HBM 餘裕很緊湊 – 高水位標記達到 ~204.5 GB (總共 205.8 GB)。將 --kv-cache-memory-bytes 提高到 20 GB 以上可能會在圖形擷取期間觸發 HSA_STATUS_ERROR_OUT_OF_RESOURCES。
• CPU KV 層僅儲存快取條目 – --kv-offloading-size 96 --kv-offloading-backend native 會在 /dev/shm 中映射 ~103 GB 用於存放被逐出的前綴快取條目；entrypoint 腳本會在崩潰後清理過時的映射。
• 調度器警告 – 預期會出現 1 664‑token 的調度器警告，因為 DSpark‑7 從 2048‑token 的預算中保留了草擬額度。
• 預熱延遲 – 重啟後的首次預填充處理 8.9 K tokens 約需 ~5.3 s；隨後的預填充會降至 ~1.7 s。
• 正確性測試 – 儲存庫包含一個驗證套件，涵蓋工具調用 (tool-calling)、Schema 檢查，以及針對原生與 DSpark 路徑的 380 K‑token 針尋回率 (needle recall)。

授權與來源

此堆疊、文件與衍生自 vLLM 的覆蓋層均依據 Apache‑2.0 發布；AITER 覆蓋層保留其 MIT 標頭。DeepSeek V4 Flash 模型本身在 Hugging Face 上採用 MIT 授權。

---

Hacker News 社群見解

• 一位用戶指出 DwarfStar 可以使用較少的記憶體運行相同的模型，可能使用了量化，但本儲存庫刻意避免量化以保留全權重推理。
• 另一則評論澄清，MI300X 通常是以 8-GPU OAM 機箱的形式銷售（約 25 萬歐元），而非單張卡。
• 部分參與者將吞吐量與 NVIDIA H800 的結果（≈ 15 K tok/s/gpu）進行比較，並建議還有進一步優化的空間。
• 一位貢獻者提到 MI350P PCIe 版本 (144 GB HBM) 也可以承載 DeepSeek V4 Flash，因為使用 MXFP4 量化時模型可以容納在 144 GB 內。
• 有人提出一個更廣泛的問題，即在不使用量化的情況下，對具有數兆參數的前沿模型進行推理的可行性；DeepSeek V4 Flash (304 B) 證明了單張高 HBM GPU 可以處理亞兆級參數的模型。