DeepSeek は予想外に 545% のコスト利益率を明らかにしました。

5 回連続のオープンソースリリースの後、DeepSeek にはもう 1 つやるべきことがあります。

先ほど、DeepSeek はDeepSeek-V3/R1 推論システムを正式に発表しました。

重要なポイントには、スループットとレイテンシを最適化する方法が含まれます。

クロスノードEP駆動型バッチ拡張
計算と通信の重複
負荷分散

DeepSeek はオンラインサービスの統計も公開しました。

各 H800 ノードは 1 秒あたり 73.7k/14.8k の入出力トークンを生成します。
原価利益率545%

詳細は下記公式声明をご覧ください↓

スループットの向上、レイテンシの低減

DeepSeek-V3/R1 推論システムの最適化の目標は、スループットの向上とレイテンシの低減です。

これら 2 つの目標を達成するために、大規模なクロスノードエキスパート並列処理 (ExpertParallelism/EP) を使用するアプローチを採用しました。

まず、EPはバッチサイズを大幅に増加させることで、GPU行列乗算の効率を向上させ、スループットを向上させます。次に、EPはエキスパートを複数のGPUに分散させ、各GPUで計算に必要なエキスパートの数を少なくすることで（したがってメモリアクセスも少なくなるため）、レイテンシを削減します。

しかし、EPはシステムの複雑さも増大させます。この複雑さは主に2つの形で現れます。

EPはノード間伝送を導入します。スループットを最適化するには、伝送と計算が同期して実行されるように適切な計算プロセスを設計する必要があります。
EP には複数のノードが関係するため、当然データ並列処理 (DP) が必要となり、異なる DP 間で負荷分散を実行する必要があります。

そのため、この記事の主な内容は、EP を使用してバッチサイズを増やす方法、送信時間を非表示にする方法、および負荷分散を行う方法です。

大規模クロスノードエキスパート並列処理（エキスパート並列処理/EP）

DeepSeek-V3/R1は多数のエキスパートを搭載しており、各層の256個のエキスパートのうち8個のみがアクティブ化されるため、モデルの高スパース性により、各エキスパートに十分なエキスパートバッチサイズを提供し、スループットの向上とレイテンシの低減を実現するために、全体のバッチサイズを大きくする必要があります。これには、大規模なクロスノードエキスパート並列処理（EP）が必要です。

私たちは、複数のマシンと複数の GPU にわたる専門的な並列戦略を採用して、次の目的を達成します。

事前入力：ルーティングエキスパート EP32、MLA、および共有エキスパート DP32。1つの展開ユニットは4つのノード、32個の冗長ルーティングエキスパートで構成され、カードごとに9個のルーティングエキスパートと共有エキスパートが1個あります。
デコード: ルーティングエキスパート EP144、MLA、および共有エキスパート DP144、1 つの展開ユニットは 18 個のノード、32 個の冗長ルーティングエキスパート、カードあたり 2 個のルーティングエキスパート、および 1 個の共有エキスパートです。

通信重複を計算する

複数のマシンと複数のカードを並列に操作すると、大きな通信オーバーヘッドが発生する可能性があるため、ダブルバッチオーバーラップを使用して通信オーバーヘッドをマスクし、全体的なスループットを向上させました。

プレフィルフェーズでは、2 つのバッチの計算と通信がインターリーブされ、1 つのバッチが計算を実行しているときに、他のバッチの通信オーバーヘッドをマスクできます。

△プレフィル段階での二重バッチオーバーラップ

デコードステージでは、ステージごとに実行時間が異なるため、計算と通信のオーバーラップを実現するために、注目部分を 2 つのステージに分割し、パイプラインの合計 5 つのステージを構成します。

△デコード段階での二重バッチオーバーラップ

ダブルバッチオーバーラップの詳細については、プロファイリングデータの GitHub リポジトリ (https://github.com/deepseek-a...) を参照してください。

可能な限り負荷分散する

大規模な並列処理（データ並列処理やエキスパート並列処理を含む）を採用しているため、単一のGPUの計算負荷や通信負荷が過度に高くなると、パフォーマンスのボトルネックとなり、システム全体の速度低下につながります。同時に、他のGPUは待機状態となり、全体の利用率低下につながります。そのため、各GPUへの計算負荷と通信負荷を可能な限り均等に割り当てる必要があります。

ロードバランサーの事前入力
- 根本的な問題は、リクエストの数と長さがデータ並列処理 (DP) インスタンスごとに異なり、その結果、コアアテンションの計算コストとディスパッチ量が変動することです。
- 最適化の目標: 一部の GPU で処理時間が過度に長くなるのを回避するために、各 GPU の計算負荷が可能な限り同じになり (コアアテンション計算負荷分散)、入力トークンの数も可能な限り同じになる (ディスパッチ送信負荷分散) ようにします。
ロードバランサーをデコードする
- 根本的な問題は、リクエストの数と長さがデータ並列処理 (DP) インスタンスごとに異なるため、コアアテンションの計算コスト (KVCache の使用に関連) とディスパッチの数にばらつきが生じることです。
- 最適化の目標: GPU 全体の KVCache 使用量を最小限に抑え (コアアテンション計算の負荷分散のため)、リクエストの数を最小限に抑えます (ディスパッチ負荷分散のため)。
エキスパートパラレルロードバランサ
- 主な問題: 特定の MoE モデルには、本質的に負荷の高いエキスパートがいくつか存在し、異なる GPU 間でエキスパートの計算負荷の不均衡が生じます。
- 最適化の目的: 各 GPU 上のエキスパート計算の量のバランスをとる (つまり、すべての GPU で受信されるディスパッチの最大量を最小限に抑える)。

リファレンスアーキテクチャ図

オンラインシステムの実際の統計データ

DeepSeekV3およびR1のすべてのサービスはH800 GPUを使用し、学習時と同じ精度を維持します。具体的には、行列演算とディスパッチ送信は学習時と同じFP8形式を使用し、コアアテンション演算とコンバイン送信は学習時と同じBF16形式を使用することで、サービスパフォーマンスを最大化します。

さらに、日中のサービス負荷が高く、夜間の負荷が低いことを踏まえ、研究とトレーニングを促進するため、日中のピーク負荷時には全ノードを使用して推論サービスを展開し、夜間の低負荷時には推論ノード数を減らす仕組みを実装しました。直近24時間（北京時間2025年2月27日午後12時から2025年2月28日午後12時まで）において、DeepSeekV3およびR1推論サービスは、ピーク時に合計278ノード、平均226.75ノード（各ノードに8基のH800 GPUを搭載）を使用しました。GPUレンタル費用を1時間あたり2ドルと仮定すると、1日あたり合計87,072ドルとなります。

24時間の統計期間内で、DeepSeekV3とR1は次の結果を示しました。

入力トークンの合計数は 608B で、そのうち 342B トークン (56.3%) が KVCache ディスクキャッシュにヒットしました。

出力トークンの総数は168Bです。平均出力レートは20～22tps、出力トークンあたりの平均KVCache長は4989です。

H800 あたりの平均スループットは、プレフィルタスク (キャッシュヒットを含む) の場合は約 73.7k トークン/秒、デコードタスクの場合は約 14.8k トークン/秒です。

上記の統計には、ウェブサイト、アプリ、APIからのすべての負荷が含まれています。すべてのトークンをDeepSeek R1の価格設定*に従って計算した場合、理論上の1日あたり総収益は562,027ドル、費用対効果は545%となります。

*DeepSeek R1 の価格: 入力トークン 100 万個あたり 0.14 ドル (キャッシュヒット)、入力トークン 100 万個あたり 0.55 ドル (キャッシュミス)、出力トークン 100 万個あたり 2.19 ドル。

もちろん、V3 は価格が低く、有料サービスは一部に過ぎず、夜間割引もあるため、実際の売上はそれほど多くありません。

オリジナルリンク: [1]https://zhuanlan.zhihu.com/p/... [2]https://github.com/deepseek-a...\_6\_one\_more\_thing\_deepseekV3R1\_inference\_system\_overview.md

- 以上-

618ZXW