DeepSeek V4 Flash をAMD MI300X 1枚で本番稼働させる方法と実測値まとめ
「巨大なAIモデルを動かすには複数のGPUが必要」という常識を覆す実例が登場しました。エンジニアの ryanzhou 氏が GitHub に公開したリポジトリ deepseek-v4-flash-mi300x は、304億パラメータ（※パラメータとはAIモデルの賢さを決める数値の個数のこと）を持つ deepseek-ai/DeepSeek-V4-Flash-0731 を AMD MI300X という GPU 1枚で本番運用するための設定・パッチ・チューニング表をすべてまとめたものです。Hacker News でも 300pts 超の注目を集めています。
なぜ AMD MI300X なのか
AMD MI300X は次の 2 点で、今回のような超大型モデルの単独搭載に向いています。
| 比較項目 | AMD MI300X | NVIDIA H100 SXM5 |
|---|---|---|
| HBM（高速メモリ）容量 | 192 GB | 約 80 GB |
| メモリ帯域幅 | 5.3 TB/s | 3.35 TB/s |
| 定価ベースのコスト感 | H100 の約半額（Doubleword 試算） | 基準 |
HBM（High Bandwidth Memory）とは GPU に直接積まれた超高速メモリのことで、容量が多いほど大きなモデルをそのまま乗せられます。MI300X の 192 GB という容量があるからこそ、304B パラメータのモデル（重みだけで 156.67 GiB）を量子化（データを圧縮して軽くする処理）なし・オフロード（一部を外部に逃がす処理）なしでそのまま乗せることができました。
実測スループット（pinned スタック環境）
使用スタック：vLLM ROCm nightly 0.26.1rc1.dev229+g124154a88.rocm723、AITER 0.1.19
| 指標 | 結果 |
|---|---|
| 1 ストリーム デコード中央値（DSpark-7） | 168.6 tok/s |
| プリフィル（チューニング済みカーネル） | ≈ 7.9〜8.5K tok/s |
| 8 並列ストリーム 合計 | 542 tok/s（1 ストリーム中央値 90.3 tok/s） |
| 64 ストリーム バースト 合計 | 830 tok/s（OOM・エラーなし） |
| 対応コンテキスト長 | 256K トークン を検証済み（アーキテクチャ上は 1M まで対応） |
※「tok/s」はトークン（AIが処理する文字のかたまり）を 1 秒間に何個生成できるかを示す速度指標です。
1 枚の GPU で 64 並列リクエストをさばけているのは、実用的な API サービスとして成立するレベルです。
動かすために解決した 5 つの技術的な壁
公式の vLLM レシピは NVIDIA ハードウェアおよび MI325X 以降の新しい AMD GPU を対象としており、MI300X（開発コード gfx942）での単独本番構成は含まれていませんでした。今回のリポジトリが対処した主な問題は以下の 5 つです。
- FP8 フォーマットの違い MI300X（CDNA3 世代）は AMD/Graphcore 独自の fnuz 形式の FP8 を実装しており、MI325X 以降が採用する OCP 標準の FP8 とは異なります。OCP 前提のカーネルをそのまま使うと、スケールの計算が 2 倍ずれる誤りが発生します。
- 高並列時の MoE ルーティングバグ MoE（Mixture of Experts）とは、多数の「専門家モジュール」を状況に応じて使い分けるモデル構造です。並列接続数が多いときにルーティングが誤作動するバグを修正。
- 投機的デコードの検証ロジック DSpark という手法で高速にトークンを「先読み」し、後から正しいか検証するしくみの不具合を修正。
- CPU–KV 同期の問題 GPU と CPU の間でキャッシュ（一時保存データ）を受け渡す際のフェンス（同期のタイミング調整）修正。upstream の issue は存在しましたが PR はマージ未了でした。
- gfx942 向けのカーネルチューニング表 パッケージ済みテーブルに gfx942 固有の形状が欠けており、AITER GEMM のカスタムチューニング表を追加。
リポジトリに含まれているもの
.
├── compose.yaml # Docker Compose による本番スタック定義（ダイジェスト固定）
├── Caddyfile.example # HTTPS リバースプロキシ設定のひな形
├── vllm-entrypoint.sh # 起動前に古い CPU-KV mmap を /dev/shm から削除するスクリプト
├── SHA256SUMS # 全アーティファクトの SHA-256 固定値
├── patches/ # 本番環境で適用しているパッチ（差分ファイルと解説付き）
└── tuning/ # gfx942 向け AITER A8W8 ブロックスケールチューニング表（CSV）
パッチはすべてバイト単位で一致する読み取り専用マウントとして適用するため、upstream の vLLM 本体を直接書き換えずに修正を重ねられます。
動かすための前提条件チェックリスト
実際に試す場合、以下をすべて満たしているか確認してください。
- AMD MI300X（gfx942、304 CU、HBM 約 192 GiB）が 1 枚あること
- AMD カーネルドライバーが正常に導入されていること
- Docker Compose（新しめのバージョン）が使えること
- CPU 側の RAM が 約 235 GiB 以上（CPU KV キャッシュ層に使用）
- ディスク空き容量が 約 500 GB 以上（モデルキャッシュだけで約 156 GB）
メモリ要件に注意：CPU RAM の 235 GiB という数字はハードルが高く、一般的なワークステーション向け構成では不足します。本格的な本番環境を想定した構成です。
デプロイの大まかな流れ（3 ステップ）
ステップ 1：ランタイムとモデルを取得する
リポジトリに記載されているダイジェスト固定の vLLM ROCm イメージと、deepseek-ai/DeepSeek-V4-Flash-0731（リビジョン 7872f01b1d1fe23eabc4c98b48bffcef5a386062）を Hugging Face からダウンロードします。ダイジェスト固定とは「バージョンを SHA-256 ハッシュで一意に指定する」手法で、意図しないバージョン変更を防ぎます。
ステップ 2：設定ファイルを用意する
Caddyfile.example をコピーして Caddyfile にリネームし、ホスト名・メールアドレス・アクセス許可する IP アドレス範囲を記入します。
ステップ 3：スタックを起動する
docker compose up でサービスを起動します。vllm-entrypoint.sh が起動前に古いキャッシュファイルを自動クリーンアップします。
主要な設定ポイント
- KV キャッシュ戦略：GPU 側に 20 GB の fp8_ds_mla キャッシュ、CPU 側に 96 GiB のネイティブオフロードを組み合わせるハイブリッド構成
- スケジューラバジェット：2,048 トークン。コールドプロンプト（初めて処理するプロンプト）が他のストリームをブロックしないよう、長プリフィルは 1,024 トークン上限でキャップ
- 投機的デコード：DSpark-7（K=7 の静的設定・確率的ドラフト・ブロックリジェクション）で単ストリームの応答速度を改善
- HTTPS プロキシ：Caddy を IP 許可リスト付きで前段に配置
ここから何が見えるか
このリポジトリが示す最も重要なポイントは「公式サポートの対象外ハードウェアでも、コミュニティが修正を積み重ねれば本番レベルで動く」という事実です。
- 公式の vLLM や AMD のドキュメントが追いついていない領域を、個人の検証と公開リポジトリで埋める動きは、オープンソース AI の典型的な進化パターンです。
- MI300X は H100 SXM5 と比べてメモリ容量が約 2.4 倍ありながら定価ベースでは約半額とされており、メモリ容量がボトルネックになる超大型モデルの運用コスト試算を変える可能性があります。
- ただし、本番導入にあたっては公式サポート有無・ドライバの安定性・運用体制も含めて総合的に判断する必要があります。Hacker News のコメント欄でも、コスト・安定性・再現性に関する議論が活発に続いています。
以上です。なるほどラボでは、こうしたAIを"自分の環境で動かしたい・24時間働かせ続けたい"という方向けの情報を発信しています。自分に合った動かし方が気になる方は、無料の診断をどうぞ。