収益を公開

(github.com/deepseek-ai)

12 ポイント投稿者 xguru 2025-03-02 | 1件のコメント | WhatsAppで共有

DeepSeek-V3/R1 推論システム概要

DeepSeek-V3/R1推論システムの最適化目標は、より高いスループットと低いレイテンシ
そのために、**クロスノード Expert Parallelism（EP）**を適用して最適化
- スループット向上: EPはバッチサイズを拡張してGPU行列演算の効率を高め、スループットを向上させる。
- レイテンシ低減: Expertを複数GPUに分散し、各GPUのメモリアクセス負荷を減らすことでレイテンシを下げる。
ただし、EPはシステムの複雑性を高める:
- クロスノード通信が必要: 通信と演算を重ねて実行し、ボトルネックを防ぐ必要がある。
- マルチノード利用: Data Parallelism（DP）を適用する必要があり、DP間のロードバランシングも必要。

DeepSeek-V3/R1モデルは各レイヤーで256個のExpertのうち8個だけが活性化されるため、バッチサイズ拡張が必須
PrefillとDecode段階ごとの並列性の違い:
- Prefill段階: EP32、DP32（4ノード、各GPUが9個のExpertを処理）
- Decode段階: EP144、DP144（18ノード、各GPUが2個のExpertを処理）

EPはクロスノード通信コストを増加させるため、これを減らすためにダブルバッチ・オーバーラップ戦略を使用
- Prefill段階: 2つのマイクロバッチを交互に実行し、一方のバッチの通信をもう一方のバッチの演算の背後に隠す。
- Decode段階: Attentionレイヤーを2段階に分け、5段階パイプラインを用いて演算-通信オーバーラップを最大化する。

GPU間の不均衡を防ぎ、リソース利用を最大化するため、3つのロードバランシング手法を適用
1. Prefillロードバランサ
- 問題: リクエスト数およびシーケンス長の差により、コアAttention演算とデータ転送の負荷が不均衡になる。
- 目標:
  - GPU間でコアAttention演算負荷の均衡を維持する。
  - GPUごとの入力トークン数を均等化する。
1. Decodeロードバランサ
- 問題: KVCache使用量の違いにより、GPU間の演算負荷が異なる。
- 目標:
  - GPU間でKVCache使用量の均衡を維持する。
  - GPUごとのリクエスト数を均等化する。
1. Expert-Parallelロードバランサ
- 問題: 特定のExpertの負荷が高く、GPU間で演算の不均衡が発生する。
- 目標:
  - 各GPUのExpert演算負荷の均衡を維持する。

DeepSeek-V3/R1推論サービスはH800 GPU上で実行され、学習時と同じ演算精度を維持
- FP8: 行列演算およびデータ転送
- BF16: 中核となるMLA演算および結合転送
ピーク時および夜間の運用戦略
- 日中はサービス負荷が高く、夜間は負荷が低下
- ピーク時間帯: すべてのノードを活用して推論サービスを実行
- 夜間の低負荷時間帯: 一部ノードを研究および学習用途に切り替え、リソースを効率的に利用
24時間運用統計（UTC+8、2025-02-27 12:00 PM ~ 2025-02-28 12:00 PM）
- 総入力トークン: 608B（このうち56.3%にあたる342BはKVキャッシュヒット）
- 総出力トークン: 168B（平均出力速度20~22トークン/s）
- 平均KVCache長: 出力トークンあたり4,989トークン
- H800ノードあたりの処理速度:
  - Prefill段階: 73.7kトークン/s（キャッシュヒット含む）
  - Decode段階: 14.8kトークン/s

GPU使用量: ピーク時278ノード、平均226.75ノード（各ノードは8基のH800 GPUを含む）
GPUレンタル費用: H800 GPU 1基あたり $2/時間 → 1日の総運用コスト: $87,072
すべてのトークンが課金対象と仮定した場合の理論上の1日収益: $562,027 → 収益率 545%
- （R1の入力/出力トークン価格: $0.14M（キャッシュヒット）、$0.55M（キャッシュミス）、$2.19M）
ただし、実際の収益はさらに低い:
- DeepSeek-V3の料金はR1よりはるかに低い
- サービスの一部のみが収益化されている（Webおよびアプリ利用は無料提供）
- 夜間には自動割引が適用される

sppappi 2025-03-03

質問を3つするとフリーズしてしまう…。