編按：本文綜合整理自 Ryan Zhou 的開源部署儲存庫、DeepSeek 官方模型頁、AMD MI300X 官方規格及 Hacker News 討論，並加入 Siami 編輯部觀點與數據查核。
一份剛公開的生產部署套件顯示，DeepSeek-V4-Flash-0731 可以在單張 AMD Instinct MI300X 上完整載入，不需額外壓縮權重，也不必把模型權重卸載到主記憶體。專案作者 Ryan Zhou 公布 Docker Compose、固定版本的映像、修補檔、校正表與安全雜湊，讓其他具備相同硬體的團隊能重現部署。
最醒目的數字是單串流解碼中位數達到 168.6 tokens/s；八個並行串流可提供每秒 542 tokens 的總吞吐量，64 串流突發測試則達到每秒 830 tokens，過程中沒有記憶體不足或引擎錯誤。這不只是「模型能開機」，而是接近可投入服務的工程成果。
一張卡為何裝得下大型模型
核心條件是 MI300X 提供 192GB HBM3。AMD 官方資料列出的峰值記憶體頻寬為 5.3TB/s；部署紀錄則顯示模型權重實際占用約 156.67GiB HBM，仍能保留約 20GB 給 GPU KV 快取，並搭配 96GiB 的 CPU 快取層存放被逐出的前綴資料。
這份配置使用 DeepSeek-V4-Flash-0731 的原始發布權重，沒有再進行額外權重量化，也沒有透過 PCIe 持續搬運權重。部署後的重要結果包括：
- 單串流解碼中位數：168.6 tokens/s
- 調校後預填速度：約 7,900 至 8,500 tokens/s
- 八串流總吞吐量：542 tokens/s
- 64 串流突發總吞吐量：830 tokens/s
- 已實測上下文：256K tokens；模型架構支援上限為 1M
- GPU 內權重占用：156.67GiB
DeepSeek 官方模型頁把 V4 Flash 描述為稀疏混合專家模型；基礎模型約 284B 參數、每次推論啟用約 13B，而完整儲存庫還包含推測解碼元件。這也解釋了為何「總參數龐大」不必然等於每個 token 都要動用全部參數，但模型權重依然必須妥善放入記憶體。
真正困難不是容量，而是 ROCm 軟體相容性
MI300X 的記憶體容量很適合大型模型，但現成 vLLM 配方主要針對 NVIDIA 與較新的 AMD 加速器。作者表示，要讓這套模型穩定跑在 MI300X，必須處理 FP8 格式、混合專家路由、高併發、推測解碼驗證、CPU 與 GPU 的 KV 快取同步，以及多組尚未調校的核心形狀。
其中一個關鍵差異是 MI300X 採用 AMD／Graphcore 的 E4M3 FNUZ FP8 變體，MI325X 與更新產品則使用 OCP 標準 FP8。若核心程式錯把兩種格式視為相同，縮放範圍最糟可能出現兩倍誤差。這不是單純跑得慢，而是可能直接影響模型輸出正確性。
專案因此提供完整覆蓋檔與對應差異檔，並鎖定 vLLM ROCm nightly 及 AITER 版本。修補內容涵蓋 MXFP4 路由遮罩、FNUZ FP8 寫入排列、稀疏注意力、推測解碼，以及 CPU 至 GPU 快取還原時的同步問題。部署指南還要求用 SHA-256 驗證所有執行期檔案，降低修補檔遭意外替換的風險。
數據解讀與限制
168.6 tokens/s 是「單一串流的解碼中位數」，而 830 tokens/s 是 64 串流突發時的「整體吞吐量」，兩者不能直接互相比快。併發提高後，總吞吐量增加，但每個使用者分得的即時速度通常會下降。專案公布八串流時每串流中位數為 90.3 tokens/s，這項指標更接近多人同時使用的體感。
此外，模型架構雖支援 100 萬 tokens 上下文，目前部署只驗證到 25.6 萬 tokens。作者使用 20GB GPU KV 池與 96GiB CPU 層，代表超長上下文仍依賴分層快取與資料搬移；不能把「能支援 1M」理解成「已在單卡上用 1M 完整壓力測試」。
Hacker News 也有人拿 DeepSeek 論文中 H800 的每張 GPU 約 1.5 萬 tokens/s 數字比較，但該數字屬於不同測試條件與總吞吐量口徑，不能與單串流 168.6 tokens/s 直接相除。合理結論是 MI300X 軟體堆疊仍有最佳化空間，而不是單憑兩個數字判定某張卡快了數十倍。
硬體取得也是限制。MI300X 是 OAM 模組，並非一般消費級 PCIe 顯示卡；主機、散熱、電力和記憶體需求都高。專案列出的先決條件包括約 235GiB 系統記憶體與約 500GB 磁碟，模型快取本身就約 156GB，因此「單卡」不等於一般工作站可輕鬆複製。
為什麼這件事重要
這項成果的重要性不只是 DeepSeek 又多一種跑法，而是展示了開源模型與非 NVIDIA 加速器之間的工程缺口，可以透過可稽核、可重現的社群工作逐步補齊。過去企業評估 AI 推論硬體時，常不能只看晶片理論算力；模型框架、核心函式庫、資料格式與錯誤修補是否成熟，往往才是能否上線的決定因素。
MI300X 的 192GB HBM 讓完整模型權重留在單一裝置，減少跨卡通訊與權重卸載的複雜度。若服務需求落在少量至中等併發，單卡部署可能比多卡拓撲更容易維護，也能降低分散式推論中的故障點。不過實際總持有成本仍要計入伺服器、功耗、租用價格、工程維護與軟體更新，不能僅用「一張卡」判定更便宜。
更值得關注的是，專案沒有只貼一張跑分截圖，而是公開版本雜湊、差異檔、調校表、啟動健康訊號與壓力測試結果。這種發布方式讓第三方可以檢查哪些修補尚未進入上游、哪些只是效能調校、哪些屬於正確性必要條件。對希望降低單一供應商依賴的 AI 團隊而言，這種工程透明度比一句「支援 ROCm」更有價值。
社群怎麼看
網路回應大致分成肯定與保留兩派。肯定者注意到部署沒有額外犧牲權重精度，單串流速度也足以支援互動式應用；保留者則提醒，已驗證上下文只有模型標稱上限的四分之一，而且整體效能仍可能透過更多核心調校繼續提升。
社群討論聚焦於幾個問題：
- 單張 MI300X 的實際採購與租用方式，是否比八卡整機更容易取得。
- 256K 上下文是否已能涵蓋大多數程式開發與文件分析情境。
- 修補內容何時能進入 vLLM、AITER 等上游專案，減少自行維護覆蓋檔的負擔。
- 相同配置能否延伸到 MI325X、MI350 系列，並保留正確的 FP8 路徑。
Ryan Zhou 的儲存庫目前採 Apache 2.0 授權，內容包括 Compose 堆疊、Caddy 範例、完整修補與效能調校資料。對具備 MI300X 的團隊而言，它已是一份可實際檢驗的起點；對一般讀者而言，這則消息則揭示了大型開源模型走向多元硬體生態時，軟體工程仍是最關鍵的戰場。
資料來源：部署儲存庫｜DeepSeek 模型頁｜AMD MI300X｜早期 MI300X 移植紀錄｜Hacker News 討論
網友熱門留言 (3)