AMD MI300X 1枚でDeepSeek V4 Flashを量子化なし動作｜vLLM構成と168 tok/sの実測
AMD MI300X 1枚でDeepSeek V4 Flashを量子化なし動作｜vLLM構成と168 tok/sの実測
「LLM推論はNVIDIA一択」という常識が静かに崩れ始めています。AMD MI300X単体で、284〜304Bパラメータを持つ大規模MoEモデル「DeepSeek V4 Flash」を量子化なしで本番稼働させた実装がHackerNewsで336点を獲得し、大きな注目を集めました。
この記事では、GitHubリポジトリ ryanzhou/deepseek-v4-flash-mi300x が公開したパッチ・設定一式を軸に、以下の3点を順を追って解説します。
- MI300Xのどのスペックがこのユースケースを可能にしたのか
- 本番稼働に必要だった2つの核心パッチの技術的な中身
- H100との実測スループット・コスト効率の比較
そもそも何が起きたのか：MI300X単体で大規模MoEモデルが「無圧縮」で動いた
公開されたリポジトリの概要
ryanzhou/deepseek-v4-flash-mi300x は、AMD MI300X 1枚の環境でDeepSeek V4 Flashをvllm ROCmスタック上で動かすためのパッチ・Docker設定・チューニングパラメータをまとめたリポジトリです。ライセンスはリポジトリ本体がApache-2.0、モデル本体がMITと、いずれも商用利用が可能な構成になっています。
なぜ「量子化なし」がインパクトを持つのか
大規模モデルを限られたGPUメモリに収めるため、従来はINT4やINT8などの量子化が半ば必須とされてきました。しかし量子化には精度劣化というトレードオフが伴い、特にコード生成・ツール呼び出し・構造化出力のような精度を問われる用途では品質低下が目立ちます。
FP16/BF16フルロードのままGPU 1枚に収めることができれば、精度劣化の心配なくモデル本来の性能を引き出せます。今回の実装はまさにそれを実現しており、「量子化が必要ない時代の選択肢」としてROCmエコシステムの実用フェーズ到達を証明する事例となっています。
ハードウェア編：AMD MI300Xが持つ192GB VRAMと5.3 TB/s帯域の威力
スペック早見表（MI300X / H200 / H100比較）
| 項目 | MI300X | H200 | H100 |
|---|---|---|---|
| VRAM | 192GB HBM3e | 141GB | 80GB |
| メモリ帯域幅 | 5.3 TB/s | 4.8 TB/s | 3.35 TB/s |
| H100比VRAM | 約2.7倍 | 約1.8倍 | ― |
VRAM容量が推論品質を決める理由
LLM推論においてGPUメモリを消費するのはモデルの重みだけではありません。入力トークンと出力トークンの中間表現を保持するKVキャッシュも、バッチサイズやコンテキスト長に応じて膨大なメモリを必要とします。
DeepSeek V4 Flashの実消費量は156.67 GiB。H100の80GBでは単体搭載すら不可能ですが、MI300Xの192GBであれば重みを載せた上で35GB以上の余裕が生まれ、KVキャッシュとバッチ処理の余地を確保できます。
「帯域幅こそがデコード速度の律速」という原則
デコードフェーズ（トークンを1つずつ生成する段階）は「メモリバウンド」な処理であり、演算性能よりもメモリへのアクセス速度が律速要因になります。MI300Xの5.3 TB/sという帯域幅はH200の4.8 TB/sを10%上回り、これが実測168 tok/sというデコード速度に直結しています。
技術編：本番稼働に必要だった2つの核心パッチ
パッチ①：MXFP4ルーティングのマスク計算修正（わずか1行）
MoE（Mixture of Experts）アーキテクチャでは、各トークンを処理する「エキスパート」をルーティングするロジックが核心です。ROCm環境ではこのルーティング計算のマスク処理に誤りがあり、ツール呼び出しや構造化スキーマの処理で誤動作が発生していました。
修正自体はわずか1行の変更ですが、この1行が本番可用性の分水嶺になっています。精度の低下ではなく「そもそも正しい結果が返らない」という問題だったため、APIサービスとして使う場合には必須の修正です。
パッチ②：FP8フォーマット互換レイヤーの挿入
MI300X（gfx942世代）はAMD独自のFNUZ形式のFP8を使用しますが、DeepSeek V4 FlashはOCP（Open Compute Project）標準のFP8を前提に設計されています。この形式の不一致をそのままにするとKVキャッシュのFP8最適化が機能しません。
今回の実装では変換レイヤーを挿入することでこの互換性問題を解決しており、「重みはFP16/BF16で無圧縮・KVキャッシュはFP8で効率化」という設計判断を実現しています。
KVキャッシュ設計：GPU 20GB＋CPUオフロード96GB
KVキャッシュは fp8_ds_mla 形式を採用し、GPU側20GB＋CPUオフロード96GBという構成で256Kコンテキストのリクエストを同時7件処理可能としています。CPUオフロードを組み合わせることでGPUメモリを重みの搭載に最大限振り向けながら、長大なコンテキストにも対応できる実用的な設計です。
ソフトウェアスタック編：vLLM ROCmでどう組むか
使用コンポーネント一覧
| コンポーネント | バージョン・役割 |
|---|---|
| vLLM ROCm | nightly（v0.26.1rc1） |
| コンテナ管理 | Docker Compose |
| HTTPSプロキシ | Caddy |
| スペキュレーティブデコード | DSpark-7（ドラフトモデル） |
スペキュレーティブデコード（DSpark-7）の効き方
スペキュレーティブデコードは、小さなドラフトモデルが先読みで複数トークンを予測し、メインモデルが一括検証する手法です。拒否サンプリングにより精度を維持しながらデコードを加速できます。DSpark-7の採用により、単純なデコードよりも高いスループットを実現しています。
スケジューラのチューニング勘所
実際の開発現場では、スケジューラの設定が全体的なスループットに大きく影響します。今回の構成では以下の2点を設定しています。
- 2,048トークンのバジェット設定：1スケジューリングサイクルあたりの処理量を制御
- 1,024トークンの長プリフィル上限：少数の超長文リクエストがキューを占有して他のリクエストを止めないための公平性確保
ベストプラクティスとして、対話型ユースケースと長文バッチ処理が混在する環境では、この種のプリフィル上限が体感レイテンシに効いてきます。
パフォーマンス編：実測168 tok/s、プリフィル8,500 tok/sの内訳
計測結果まとめ
| シナリオ | スループット |
|---|---|
| シングルストリーム（デコード中央値） | 168.6 tok/s |
| プリフィル（チューニング後） | 7,900〜8,500 tok/s |
| 8並列ストリーム | 542 tok/s（合計） |
| 64ストリームバースト | 830 tok/s（合計） |
数字の読み方：シングル vs 並列で傾向が変わる理由
注目すべきは、並列度を上げると合計スループットは増加するが、1ストリームあたりのスループットは低下するという点です。8並列では1本あたり平均68 tok/s、64並列では約13 tok/sまで落ちます。
- 対話型（チャットボット・コード補完）：シングルストリームの168 tok/sが目安
- バッチ処理（文書要約・大量API呼び出し）：合計スループット830 tok/sが指標
自分のユースケースに合った数値を見て判断することが重要です。
コスト編：H100に生スループットで負けても選ばれる理由
スループットとコスト効率の比較表
| 項目 | MI300X（最適化後） | H100 FP8 |
|---|---|---|
| スループット | 約 7,350 tok/s | 約 11,550 tok/s |
| コスト効率 | 3,695 tok/ドル | 2,315 tok/ドル |
| 時間単価（目安） | 約 $1.99/h | 約 $4.99/h |
「1ドルあたり60%以上優位」というインパクト
生スループットではMI300XはH100の約64%に留まりますが、時間単価がおよそ4割であるため、1ドルあたりに換算すると60%以上のコスト優位が生まれます。「速さ」ではなく「コストあたりの生産量」で選ぶ時代においては、この指標こそが意思決定の軸になります。
MI300Xが向くケース／向かないケース
向くユースケース：
- 社内向け推論APIの常時稼働運用
- バッチ推論（文書処理・データ変換）
- コスト最優先での大量トークン生成
向かないユースケース：
- P50/P99レイテンシを徹底的に詰めるリアルタイム用途
- CUDAカーネル最適化の最新成果に強く依存するワークロード
- NVIDIA特有の機能（Tensor Parallelism最適実装など）を使い込む環境
よくある質問（FAQ）
Q. なぜ量子化なしで動かせるのか？
192GBというVRAM容量により、BF16フルロードで156.67 GiBを消費するDeepSeek V4 FlashをGPU単体に搭載できます。量子化による精度劣化を一切受け入れることなく、モデル本来の出力品質を維持できる点が最大のメリットです。
Q. vLLMはNVIDIA専用ではないのか？
かつてはそういう認識が強かったですが、現在はROCmバックエンドが整備されておりAMD GPUでも動作します。ただし、CUDAカーネルの成熟度との差が残っており、一部の処理で10〜15%程度のスループット差があるケースも報告されています。
Q. 商用利用は可能か？
リポジトリ本体はApache-2.0ライセンス、モデル本体はMITライセンスと、いずれも商用利用が明示的に許可されています。社内サービスやSaaSへの組み込みも問題ありません。
Q. 自分で再現するには何が必要か？
最低限必要なものは以下の通りです。
- AMD MI300X搭載インスタンス（クラウドはOrion CloudやFluidStackなどで提供）
- ROCm対応ドライバ（6.x系推奨）
- vLLM ROCm nightly（v0.26.1rc1以降）
ryanzhou/deepseek-v4-flash-mi300xリポジトリのパッチと設定ファイル
まとめ：GPU選定の判断軸は「速度」から「1ドルあたりのトークン」へ
今回の実装が示した最も重要なメッセージは、GPU選定の評価軸がピーク性能からコスト効率へシフトしているという事実です。
量子化なし動作を成立させたのは、192GB VRAMという物理的な余裕と、KVキャッシュのFP8化・CPUオフロードを組み合わせた設計判断です。本番可用性を確保するためのパッチは技術的に小さく、ROCmエコシステムの課題も「カーネル成熟度の差」という明確な形で残っているだけです。
段階的に理解を深めていただくために、次のアクションとして自社ワークロードでのコスト効率試算を行うことをお勧めします。バッチサイズ・コンテキスト長・同時接続数を手元の数値で試算することで、MI300XとH100のどちらが最適かが明確になるはずです。
参考リンク
- GitHub: ryanzhou/deepseek-v4-flash-mi300x
- AMD公式：vLLM × AMD — MI300X上の高効率LLM推論
- dstack：DeepSeek R1 inference MI300X vs H200
- AMD ROCmブログ：MI300XでのWide EP DeepSeek分散推論
- DeployBase：MI300X vs H200 スペック比較