DeepSeek V4 Flash は単一の AMD MI300X で動作 – パフォーマンス、修正点、デプロイガイド

TL;DR

DeepSeek V4 Flash は、重みの量子化やオフロードなしで、3040億パラメータのチェックポイントをフルに使用しながら、単一の AMD MI300X GPU 上で 168 トークン/秒 の中央値デコード（シングルストリーム）および 約 8 K トークン/秒 のプレフィルを実現しています。このパフォーマンスは、ROCm パッチ群、AITER GEMMチューニングテーブル、およびハイブリッド GPU-CPU KVキャッシュ戦略の適用により達成されています。

---

MI300X の重要性

Instinct MI300X は 192 GB の HBM3 と 5.3 TB/s のメモリ帯域幅 を備えており、NVIDIA H100 SXM5 の約 2.4 倍の HBM 容量を持ちます。このメモリの余裕により、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製品ページ

リポジトリが追加する内容

GitHub リポジトリ ryanzhou/deepseek-v4-flash-mi300x は、Fergus Finn による MI300X の導入および Doubleword のデモに加えて、以下の4つの重要な貢献を提供しています。

1. 正しさのオーバーレイ：ROCm ナイトリー（vLLM ROCm 0.26.1rc1.dev229+g124154a88.rocm723）用に、FP8フォーマット処理、MoEルーティング、スペキュラティブ検証、CPU-KV同期の問題を修正。
2. 検証済みのサービング設定：DSpark-7 スペキュラティブドラフト、ブロック拒否、静的 K=7、2048トークンのスケジューラ予算、1024トークンの長大プレフィル制限を含む。
3. AITER GEMMチューニングテーブル：gfx942（MI300X）用の形状で上流に存在しなかったものに加え、MXFP4エキスパート用の OGS ジオメトリオーバーライドを提供。
4. ハイブリッド KV戦略：20 GB GPU fp8_ds_mla キャッシュ + 96 GB ネイティブ CPU オフロード、および vLLM の issue #47282 に記載されたロードパスフェンシング修正を含む。

リポジトリ構成（自己完結型の概要）

.
├─ compose.yaml            # 本番用 Docker-Compose スタック（vLLM ROCm + Caddy）
├─ Caddyfile.example      # HTTPSプロキシテンプレート
├─ vllm-entrypoint.sh      # 開始前に古い CPU-KV mmap ファイルをクリーン
├─ SHA256SUMS              # すべてのランタイムアーティファクトの SHA-256 ピン
├─ patches/
│  ├─ *.py                # 読み取り専用マウントのフルファイルオーバーレイ
│  ├─ diffs/*.patch       # 上流ベースとの統合差分
│  └─ README.md           # 出典情報と再生成手順
└─ tuning/
   └─ *.csv               # gfx942 用の AITER A8W8 ブロックスケールチューニングテーブル

主要なパフォーマンス数値（vLLM ROCm ナイトリー 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、1ストリームあたり中央値 90.3 tok/s
64ストリームバースト	合計 830 tok/s、OOMやエンジンエラーなし
コンテキストウィンドウ	256 K トークンを検証済み（アーキテクチャ上最大 1 M まで対応）
HBM に配置された重み	156.67 GiB（追加の量子化やオフロードなし）

2つの重要な正しさの修正

MXFP4ルーティングバグ

MoE ビットマトリックスカーネルはブロック列を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タイルシャッフル）で FP8 を書き込みますが、上流の AITER は OCP E4M3 レイアウトを期待しています。オーバーレイは float8e4b8 を強制し、FP8_MAX=224.0 を設定し、必要なシャッフルを適用することで、MI300X 上での2倍のスケールエラーを防ぎます。

スペキュラティブデコード設定

スタックは 確率的ドラフト + ブロック拒否（DSpark-7）を使用しています。2つの Gumbelノイズオーバーレイにより、ドラフト提案のノイズと拒否/回復のノイズが独立しており、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 のシングルストリーム
2048トークン予算 + 1024トークンの長大プレフィル制限	52 K のコールドプレフィルの後で短いリクエストの TTFT が 8.2 s から 0.5 s に低下
ハイブリッド KV（20 GB GPU + 96 GB CPU）	1.93 Mトークン長相当の容量、256 K のリクエストを7件まで受け入れ可能

同時処理スイープ（異なる約400語のプロンプト、temperature=1.0、top_p=0.95）

ストリーム数	合計 tok/s	1ストリームあたりの中央値デコード	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. ハードウェア – 1台の MI300X（gfx942、304 CUs、約192 GiB HBM）、AMDドライバ、Docker Compose、約235 GiB RAM、約500 GiBディスク。
2. ピン付きランタイムの取得 – ダイジェストピン付きイメージ vllm/vllm-openai-rocm@sha256:e68d18b2… を使用し、モデルリビジョン 7872f01b1d… をダウンロード。
3. オーバーレイの検証 – 最初の起動前に sha256sum -c SHA256SUMS を実行。
4. スタックの起動 – docker compose up -d；起動成功メッセージ（モデルロード、KVキャッシュサイズ、CUDAグラフキャプチャ）をログで確認。
5. カーネルのウォームアップ – キャッシュなしプレフィル（約8Kトークン）を1回実行してカーネルを初期化；以降のリクエストはより高速になります。
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をマップして、除外されたプレフィックスキャッシュエントリを保存；エントリポイントスクリプトがクラッシュ後に古いマッピングをクリーンアップします。
• スケジューラの警告 – DSpark-7 が2048トークン予算からドラフトスロットを予約しているため、1664トークンのスケジューラ警告は予期されるものです。
• ウォームアップ遅延 – 再起動後の最初のプレフィルは約5.3 s（8.9 Kトークン）かかりますが、以降のプレフィルは約1.7 sに低下します。
• 正しさのテスト – リポジトリには、ツールコール、スキーマチェック、およびネイティブおよび DSpark パス用の38万トークンのニードルリコールをカバーする検証スイートが含まれています。

ライセンスと出典

スタック、ドキュメント、および vLLM 由来のオーバーレイは Apache-2.0 の下でリリースされています；AITER オーバーレイはその MIT ヘッダーを保持しています。DeepSeek V4 Flash モデル自体は Hugging Face 上で MITライセンス です。

---

Hacker News からのコミュニティの知見

• ユーザーが DwarfStar は同じモデルをより少ないメモリで実行できることを指摘。おそらく量子化を利用しているが、このリポジトリは重みの完全な推論を維持するために量子化を意図的に避けています。
• 他のコメントで、MI300X は通常、8GPUのOAMケーシング（約25万ユーロ）として販売され、単体カードとしてではないと明言されています。
• 一部の参加者が、NVIDIA H800 の結果（約15K tok/s/gpu）と比較し、さらなる最適化が可能であると述べています。
• ある貢献者が、MI350P PCIeバージョン（144GB HBM）も MXFP4量子化を使用すれば DeepSeek V4 Flash を収容可能であると指摘。モデルは144GB以内に収まるためです。
• より広い問いとして、数兆パラメータのフロンティアモデルの非量子化推論の可能性について議論がなされ、DeepSeek V4 Flash（304B）は、単一の高HBM GPUがサブトリアンパラメータモデルを処理できることを示しています。