概要
- DeepSeek V4 Flashを AMD MI300X 単体で動作させるための構成とパッチ集
- Docker Compose によるプロダクション運用例とバージョン固定
- FP8対応・MoEルーティング・KV同期 などMI300X固有の修正
- 高性能・高同時接続 を実現するカスタムチューニング
- 導入手順、パッチ内容、パフォーマンス指標の詳細解説
DeepSeek V4 Flash on a single AMD MI300X 構成と特徴
- deepseek-ai/DeepSeek-V4-Flash-0731を AMD MI300X 単体で本番運用するためのリポジトリ
- Docker Compose スタック、SHA-256固定ファイル、パッチ、チューニングテーブルを収録
- チェックポイントは 追加の量子化やオフロードなし でそのまま動作
- vLLM ROCm nightly 0.26.1rc1.dev229+g124154a88.rocm723、AITER 0.1.19で検証済み
- 代表的なパフォーマンス:
- シングルストリームデコード: 168.6 tok/s（DSpark-7）
- プレフィル （カーネルチューニング済み）: 約7.9–8.5K tok/s
- 8ストリーム同時実行: 合計542 tok/s、1ストリームあたり90.3 tok/s
- 64ストリームバースト: 合計830 tok/s、OOMやエラーなし
- 256Kコンテキスト 検証済み（アーキテクチャ上は1M対応）
- HBM上の重み: 156.67 GiB（追加量子化・オフロードなし）
MI300Xでの運用意義と特徴
- MI300X は192 GB HBM3と5.3 TB/s帯域、H100 SXM5の2.4倍のHBM容量
- コストは約半分 （Doublewordの試算）
- 304Bパラメータのモデルを HBMに全て収容 可能
- PCIe経由の重みストリーミングやレイヤーオフロード不要
- 20 GB GPU KVプール＋96 GiB CPUティアでキャッシュ管理
- 1枚で2–8ストリーム常時、最大64ストリームバースト対応
- FP8実装差異 （MI300XはAMD/Graphcore fnuz、MI325X以降はOCP標準FP8）
- FP8対応の正確性重視、パフォーマンスチューニングは後回し
既存研究と本リポジトリの追加点
- Fergus FinnやDoublewordのリポジトリで FP8非互換・MoEルーティングバグ等 を特定
- vLLM公式レシピはNVIDIA・新型AMD（MI325X/MI355X）向け
- 本リポジトリで追加した内容
- ROCm nightly向け正確性パッチ （未マージ分含む）
- DSparkドラフティング・ブロックリジェクト・K=7静的設定 を含む検証済みサービング構成
- 2,048トークンのスケジューラバジェット、1,024トークンのロングプレフィル上限
- AITER GEMMチューニングテーブル （gfx942形状追加）、MXFP4エキスパート用OGSジオメトリ
- ハイブリッドKV戦略 （20 GB fp8_ds_mla GPUキャッシュ＋96 GiB CPUオフロード、パス修正付き）
リポジトリ構成
- compose.yaml：本番用スタック（vLLM ROCm＋Caddy）、ダイジェスト固定
- Caddyfile.example：Caddyfile用サンプル
- vllm-entrypoint.sh：/dev/shmの古いCPU-KV mmap削除
- SHA256SUMS：全ランタイムアーティファクトのSHA-256
- patches/：パッチファイル群（.py、diff/.patch、README.md）
- tuning/：AITER A8W8ブロックスケールチューニングテーブル（gfx942用）
ランタイム構成要点
- ダイジェスト固定のvLLM ROCm nightly ＋DeepSeek V4トークナイザ・推論・ツールパーサ
- fp8_ds_mla KVキャッシュ （UE8M0ブロックスケールFP8、256トークンブロック）
- VLLM_ROCM_USE_AITER=1、--moe-backend triton（Triton OGSとAITERで分担）
- DSpark-7スペキュレーティブデコード （確率的ドラフティング＋ブロックリジェクト）
- CUDAグラフキャプチャ （steady decode時に1トークンごとに起動）
- Caddy によるIP制限付きHTTPSプロキシ
導入手順
- ハードウェア要件 ：MI300X（gfx942）、AMDカーネルドライバ、Docker Compose、~235 GiB RAM、~500 GBディスク
- イメージ・モデル取得 ：
- vLLM ROCmイメージとDeepSeekモデルを SHA-256指定でpull
- 設定ファイル準備 ：
- Caddyfile.exampleをコピーし、ホスト名・メール・CIDRを設定
- aiter-cache、crash-dumpsディレクトリ作成、vllm-entrypoint.shに実行権限付与
- SHA256SUMSでオーバーレイ検証
- 起動 ：
- docker compose config -q、docker compose up -d、docker compose logs -f inference
- 正常起動には「Model loading took 156.67 GiB」等のログ確認
- 動作確認 ：
- curlで/v1/models、/v1/completionsエンドポイントをテスト
パッチ内容一覧
- patches/*.pyは 本番用フルファイルオーバーレイ （コンテナ内にread-onlyでマウント）
- 対応するdiffs/*.patchでupstreamとの差分記録
- 主なパッチ例
- gpt_oss_triton_kernels_moe.pack128-fused-silu-fast-routing.py ：MXFP4ビットマトリクスパディング修正＋SiLU融合
- mxfp4.fused-silu.py ：fused-SiLUカーネル用レイアウト修正
- triton-kernels-matmul-ogs-opt-flags.dsv4-mi300x.py ：gfx942用OGSタイルジオメトリ
- fused_compress_quant_cache.fnuz-shuffle.py ：FNUZ FP8＋16×16プリシャッフル
- aiter_pa_mqa_logits.i64.py ：64ビットオフセット対応
- rocm_aiter_mla_sparse.prefill-bh64.py ：決定論的torch.topk＋BLOCK_H=64
- rocm_aiter_mla.dspark-causal.py ：因果的マルチトークンスペキュレーティブ検証
- dspark-speculator.independent-draft-gumbel.py＋spec-decode-utils.independent-draft-gumbel.py ：Gumbelノイズ独立化
- kv_offload_cpu_gpu_worker.load-war.py ：CPU→GPU KVリストアのフェンス修正
正確性・パフォーマンス最適化
- FP8形式の違い ：OCPとFNUZでスケール誤差が最大2倍、シャッフル・最大値設定でMI300Xに最適化
- MoEルーティング ：パディングレーンのマスク不備を修正
- DSpark ：確率的ドラフティング＋ブロックリジェクト
- AITER GEMMチューニング ：21種類のA8W8形状をgfx942用に最適化
- Sparse prefill ：BLOCK_H=64でプレフィル7.9–8.5K tok/s
- KVキャッシュ戦略 ：GPU 20 GB＋CPU 96 GiBで最大1.93Mトークン相当
パフォーマンス指標
- シングルストリーム：126.2–168.6 tok/s、TTFT 1.0秒前後
- 8ストリーム：合計542.3 tok/s、1ストリームあたり90.3 tok/s
- 64ストリーム：合計830.2 tok/s、OOM・エラーなし
- プレフィル ：チューニング済みでC1 7.9–7.99K tok/s、C4 8.46–8.51K tok/s
- ロングプレフィル制限 ：短リクエストのTTFTが8.2秒→0.5秒に短縮
プロダクション運用上の注意
- HBMヘッドルーム は極小（204.5/205.8 GB）、--kv-cache-memory-bytesの増加は不可
- CPU KVティア はキャッシュエントリ用、重み格納用ではない
- --kv-offloading-size 96 で96 GiBのオフロード領域を確保
- パッチ・バージョン固定 で安定運用、アップグレード時は再検証必須
この構成により、 DeepSeek V4 Flash を AMD MI300X 単体で高効率かつ安定して運用可能。 FP8非互換・MoEルーティング・KV同期 などMI300X固有の課題を克服し、 高同時接続・低レイテンシ を両立しています。