AI・機械学習
DeepSeek V4 Flash を単一の AMD MI300X で実行する
DeepSeek V4 Flash on a Single AMD MI300X (github.com)
要約
本リポジトリは、DeepSeek V4 Flash モデルを単一の AMD MI300X GPU 上で本番環境実行するために必要な設定とパッチを提供します。FP8フォーマットの不整合、高並列時のMoEルーティング、CPU-KV同期などのMI300X特有の問題を解決し、vLLMのROCmナイトリービルドとAITERライブラリを用いて、256Kコンテキスト長で高いスループットを実現しています。
全文翻訳
単一のAMD MI300XでのDeepSeek V4 Flash
このリポジトリには、deepseek-ai/DeepSeek-V4-Flash-0731を1基のAMD MI300Xで本番稼働させるために使用する設定とパッチが含まれています。Docker Composeスタック、SHA-256で固定されたファイルオーバーレイ、アップストリームとのリファレンス差分、チューニングテーブルが含まれています。チェックポイントは、追加の重み量子化やオフロードなしで出荷時のまま実行されます。
固定スタック(vLLM ROCmナイトリー 0.26.1rc1.dev229+g124154a88.rocm723、AITER 0.1.19)からの結果:
メトリック
結果
シングルストリームデコード(ストリームあたりの中央値、DSpark-7)
168.6 トーク/秒
チューニング済みカーネルによるプリフィル
約 7.9–8.5K トーク/秒(出荷プロファイルでの新規プロンプトで 6,988–7,019 トーク/秒)
8並列ストリーム
542 トーク/秒(集計)、90.3 トーク/秒(ストリームあたり中央値)
64ストリームバースト
830 トーク/秒(集計)、OOMなし、エンジンエラーなし
コンテキスト
256K検証済み(アーキテクチャは1Mをサポート)
HBM内のウェイト
156.67 GiB — 追加の量子化やウェイトオフロードなし
公式のvLLMレシピはNVIDIAおよび新しいAMDハードウェアを対象としています。MI300Xでモデルを確実に実行するには、そのFP8フォーマット、高並列時のMoEルーティング、因果的投機的検証、CPU-KV同期、およびいくつかの未調整カーネル形状の修正が必要でした。このリポジトリはそれらの修正を収集し、本番で使用されるバージョンを固定します。
MI300Xを選択した理由
MI300Xは192 GBのHBM3と5.3 TB/sのメモリ帯域幅を持ち、H100 SXM5(AMD)のHBM容量の2.4倍です。Doublewordの記事によると、リスト価格で約半額です。この304Bパラメータのチェックポイントでは、メモリ容量によりシンプルなシングルGPUデプロイメントが可能です。PCIeウェイトストリーミングやレイヤーオフロードなしで、モデル全体がHBMに収まります。20 GBのGPU KVプールと、エビクトされたプレフィックスキャッシュエントリ用の96 GiB CPUティアのためのスペースがあります。1枚のカードで2〜8の一般的な同時ストリームと最大64ストリームのバーストを処理できます。
MI300X(CDNA3)は、AMD/GraphcoreのfnuzバリアントのE4M3を実装していますが、MI325X以降はOCP標準のFP8を使用します(背景)。MI300XでOCPセマンティクスを仮定するカーネルは、スケールドメインで2倍の誤差が生じる可能性があります。このFP8実装での正確性が最優先事項であり、パフォーマンスチューニングはその後に行われました。
先行研究と本リポジトリの追加点
Fergus FinnのMI300Xワークログと付随するDoublewordリポジトリは、FP8の非互換性、gfx942でのAITER高速パスの欠如、スパースMLAデコードでのHIPグラフの危険性、およびMoEルーティングのバグを特定しました。公式のvLLMレシピはNVIDIAハードウェアと新しいAMD GPU(4KコンテキストのMI325XおよびMI355X)をカバーしていますが、0731チェックポイントの単一MI300X本番構成はカバーしていません。このリポジトリは以下を追加します:
固定されたROCmナイトリー用の正確性オーバーレイ。まだアップストリームvLLMにマージされていない修正も含まれます。
確率的DSparkドラフティング、ブロック拒否、静的K=7を使用した検証済みサービング構成。コールドプロンプトが他のストリームを遅延させるのを防ぐために、2,048トークンのスケジューラバジェットと1,024トークンのロングプリフィルキャップを使用します。
パッケージ化されたテーブルに欠けていた、gfx942の繰り返し形状に対するAITER GEMMチューニングテーブル、およびMXFP4エキスパート用のgfx942 OGSジオメトリオーバーライド。
ハイブリッドKV戦略:20 GBのfp8_ds_mla GPUキャッシュ + 96 GiBネイティブCPUオフロード。アップストリームIssue #47282で文書化されているがPR #47291でマージされなかったロードパスフェンシング修正が含まれます。
リポジトリレイアウト
. ├── compose.yaml # 本番スタック(vLLM ROCm + Caddy)、ダイジェスト固定 ├── Caddyfile.example # Caddyfileにコピーし、ホスト名、メールアドレス、ソースCIDRを設定 ├── vllm-entrypoint.sh # 開始前に/dev/shmから古いCPU-KV mmapを削除 ├── SHA256SUMS # 全てのランタイムアーティファクトのSHA-256ピン ├── patches/ │ ├── *.py # バイト単位の本番オーバーレイ(読み取り専用でマウント) │ ├── diffs/*.patch # アップストリームベースリビジョンからの統一差分 │ └── README.md # 出所と再生成手順 └── tuning/ └── *.csv # gfx942用のAITER A8W8ブロックスケールチューニングテーブル
ランタイム構成
スタックは、以下の設定でダイジェスト固定された公式vLLM ROCmナイトリーを使用します:
--trust-remote-code と DeepSeek V4 トークナイザー、推論、ツールパーサー
fp8_ds_mla KVキャッシュ(UE8M0ブロックスケールFP8、汎用非スケールFP8ではない)、256トークンブロック付き
VLLM_ROCM_USE_AITER=1 および --moe-backend triton; Triton OGSはグループ化されたMXFP4エキスパートを処理し、AITERはアテンションと密線形レイヤーを処理します
DSpark-7 確率的ドラフティングとブロック拒否による投機的デコード
フル/ブレーク可能なCUDAグラフキャプチャ。安定したデコード中にトークンごとに1つのグラフ起動を提供します
IP許可リスト付きHTTPSプロキシとしてのCaddy
デプロイ方法
1. ホスト前提条件
MI300X(gfx942、304 CU、約192 GiB HBM)、動作中のAMDカーネルドライバー、最新のDocker Compose、CPU KVティア用の約235 GiB RAM、および約500 GBのディスク(モデルキャッシュだけで約156 GB)。
2. 固定ランタイムとモデルのプル
VLLM_IMAGE='vllm/vllm-openai-rocm@sha256:e68d18b2ba50298661bfc49baf01158fbf036645c2362cccf3e8a7a79fe6c69a'
MODEL='deepseek-ai/DeepSeek-V4-Flash-0731'
REVISION='7872f01b1d1fe23eabc4c98b48bffcef5a386062'
docker pull "$VLLM_IMAGE"
docker run --rm --entrypoint hf \
-v /root/.cache/huggingface:/root/.cache/huggingface \
"$VLLM_IMAGE" download "$MODEL" --revision "$REVISION"
3. ファイルの準備
cp Caddyfile.example Caddyfile # 次にホスト名、メールアドレス、remote_ip CIDRを設定します
mkdir -p aiter-cache crash-dumps
chmod +x vllm-entrypoint.sh
sha256sum -c SHA256SUMS # 最初の起動前にオーバーレイを検証します
4. Docker Composeの起動
config -q docker compose up -d
docker compose logs -f inference
正常な起動には約5分かかり、以下のすべてが表示される必要があります:
Model loading took 156.67 GiB
DSpark draft model loaded: 96 params
GPU KV cache size: 1,927,444 tokens
Maximum concurrency for 262,144 tokens per request: 7.35x
Created mmap file /dev/shm/vllm_offload_...mmap (103.08 GB)
Capturing CUDA graphs (FULL)
Application startup complete
グラフキャプチャ後、rocm-smi --showmeminfo vramを実行します。ウォームアップ後の高値は約205.8 GB中204.5 GBです。数GBしか残っていない場合、サーバーは起動するかもしれませんが、最初の要求で失敗する可能性があります。
5. スモークテスト
HOST='your-host.example.com'
curl -fsS "https://$HOST/v1/models"
curl -sS "https://$HOST/v1/completions" \
-H 'Content-Type: application/json' \
-d "{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "prompt": "Calculate 17 * 23. Answer with the number only.", "temperature": 0, "max_tokens": 32}"
パッチ
各patches/*.pyファイルは、コンテナ内の対応するファイルの上に読み取り専用でマウントされるフルファイルオーバーレイです。compose.yamlにはターゲットパスが含まれています。対応するdiffs/*.patchは、アップストリームベースリビジョンからの変更を記録します。ベースイメージはダイジェスト固定されたままなので、アップグレードにはイメージ参照の変更とスタックの再検証が必要です。
オーバーレイ
マウント先
修正内容
gpt_oss_triton_kernels_moe.pack128-fused-silu-fast-routing.py
vllm/.../fused_moe/experts/gpt_oss_triton_kernels_moe.py
MXFP4ビットマトリックスパディングレーン + 融合SiLUグループ化エキスパート + 高速DeepSeekルーティング
MXFP4 Tritonパスに必要。マスク修正はまだアップストリームにありません。
mxfp4.fused-silu.py
vllm/.../fused_moe/oracle/mxfp4.py
ゲート/アップインターリーブレイアウト(融合SiLUカーネル用)
融合SiLUオーバーレイと共に必要。標準SiLUパスを維持する場合は両方スキップします。
triton-kernels-matmul-ogs-opt-flags.dsv4-mi300x.py
vllm/third_party/triton_kernels/matmul_ogs_details/opt_flags.py
gfx942 MXFP4 OGSタイルジオメトリ(最大1,536ルーティング行)
gfx942でのパフォーマンス。標準ジオメトリは768行を超えると急激に低下します。
fused_compress_quant_cache.fnuz-shuffle.py
vllm/models/deepseek_v4/common/ops/fused_compress_quant_cache.py
FNUZ FP8 + 16x16プリシャッフル(Lightning Indexerキャッシュライター用)
MI300Xで必要。MI325X/MI355XはOCP FP8を使用し、標準バイトを維持する必要があります。
aiter_pa_mqa_logits.i64.py
aiter/ops/triton/gluon/pa_mqa_logits.py
64ビットオフセット(ChunkK=256ページ化MQAカーネル用)
KVオフセットが4 GiBを超える可能性がある場合に必要。小さなKVプールではスキップします。
rocm_aiter_mla_sparse.prefill-bh64.py
vllm/v1/attention/ops/rocm_aiter_mla_sparse.py
決定論的torch.topkプリフィル + BLOCK_H=64ヘッド-512スパースプリフィル
決定論は再現可能なツール呼び出しに必要。BLOCK_H=64はパフォーマンスのためです。
rocm_aiter_mla.dsp