必ず時間通りに仕事を終わらせてください。

DeepSeek オープンソース ウィークの 4 日目には、すべてが 1 つのテーマを中心に展開される、満足のいく「 3 in 1」リリースが発表されました。

並列戦略を最適化します。

• DualPipe:前方および後方の計算通信ステージを完全にオーバーラップし、「パイプラインバブル」を削減する革新的な双方向パイプライン並列アルゴリズムです。対称マイクロバッチスケジューリングにより、並列計算の効率を最適化します。
• エキスパート並列ロードバランサー（EPLB） ：MoE向けの負荷分散アルゴリズム。高負荷のエキスパートを複製し、複数のGPUにインテリジェントに分散することで、コンピューティングリソースをバランスよく活用します。階層型負荷分散とグローバル負荷分散という2つのポリシーを備えています。
• プロファイリング データ:トレーニングおよび推論フレームワークのパフォーマンス分析データ。通信と計算の重複戦略と基礎となる実装の詳細を明らかにします。

これら 3 つのうち、DualPipe は計算と通信のスケジュールを時間の観点から最適化し、EPLB は計算リソースの使用をスペースの観点からバランス調整し、Profiling Data は実際のアプリケーションにおける前述の 2 つの有効性を視覚的に証明します。

さらに、 Liang Wenfeng 氏自身も DualPipe 開発チームの一員です。

リリースから 10 分も経たないうちに、これら 3 つのプロジェクトはいずれも GitHub で 300 を超えるスターを獲得し、中でも DualPipe はスター獲得数が最も急増しました。

DeepSeek がツイートするとすぐに、大量のコメントが殺到し、そのほとんどが賞賛の言葉を惜しみなく述べていました。

素晴らしい仕事ですね！ワクワクします！
最適化戦略により業界のパフォーマンスを再定義できます。

4日目、3日連続の更新です。

デュアルパイプ

DualPipe は、DeepSeek-V3 に登場した最初の双方向パイプライン並列アルゴリズムであり、そのコードは現在完全にオープンソースになっています。

これにより、順方向と逆方向の計算通信フェーズ間の完全なオーバーラップが実現され、パイプライン バブル(つまり、一部のデバイスがアイドル状態になり、特定の時間に待機する状態)が削減されます。

DualPipe は双方向マイクロバッチ スケジューリング戦略を採用しており、その主な機能は次のとおりです。

• 対称設計: 逆方向のマイクロバッチは順方向のマイクロバッチと対称的に配置され、幾何学的にバランスのとれたスケジューリング構造を形成します。
• 計算と通信の重複: 黒い境界線を共有する 2 つのセルは、重複する計算プロセスと通信プロセスを表します。
• 双方向並列処理: ハードウェアの使用率を最大化するために、マイクロバッチを 2 方向で同時に実行します。

1F1B (1 順方向、1 逆方向)などの従来のパイプライン並列方式では、マルチ GPU シナリオを処理するときに大量のバブルが生成されます。

DualPipe は、マイクロバッチの実行順序を並べ替え、対称構造を使用することでこの問題を軽減します。

EPLB

EPLB は、分散トレーニングおよび推論における MoE モデルの負荷不均衡の問題を解決する、V3/R1 向けの専門的な並列ロード バランサーです。

MoE アーキテクチャでは、異なる入力によって異なるエキスパートがアクティブ化されるため、一部のエキスパートが過負荷になり、さらに異なる GPU の使用率に不均衡が生じる可能性があります。

EPLB は「冗長な専門家」戦略を採用しています。

高負荷のエキスパートを識別する → 複数のコピーを作成して異なる GPU に分散する → 推論中に負荷の軽いエキスパートのコピーに入力を動的に割り当てます。

また、次の 2 つの一般的な戦略も含まれます。

• 階層化された負荷分散、エキスパート並列処理、およびより小さな事前充填ステージが使用されます。
• デコードフェーズでは、並列に作業するエキスパートの数が多くなるため、グローバル ロード バランシングが採用されます。

V3/R1における計算通信重複解析データ

オープンソース イニシアチブの第 4 回目のパート 3 では、DeepSeek がトレーニングおよび推論フレームワークからの分析データを公開し、コミュニティが通信計算の重複戦略と低レベルの実装の詳細をより深く理解できるようにしました。

GitHub のドキュメントには、分析用のデータは PyTorch Profiler を使用してキャプチャされたと記載されています。

ダウンロード後、開発者は Chrome ブラウザで chrome://tracing (または Edge ブラウザで edge://tracing) に移動して視覚化できます。

ご注意ください。DeepSeek は、分析のために完全にバランスのとれた MoE ルーティング戦略をシミュレートします。

まず、トレーニング段階です。

トレーニング プロファイル データは、DualPipe 内の個別の前方および後方データ ブロックのペアに対する DeepSeek のオーバーラップ戦略を示しています。

各データ ブロックには 4 つの MoE レイヤーが含まれています。

並列構成は、DeepSeek-V3 の事前トレーニング設定と一致しています。EP64 と TP1 のシーケンス長は 4K です。

簡単にするために、プロファイリング中に PP 通信は含められません。

第二に、推論段階です。

1) 事前充填。

事前入力の場合、構成ファイルは EP32 と TP1 (DeepSeek V3/R1 の実際のオンライン展開と一致している) を使用し、ヒントの長さは 4K に設定され、GPU あたりのバッチ サイズは 16K トークンになります。

事前入力フェーズでは、DeepSeek は重複計算と多対多通信のために 2 つのマイクロバッチを活用し、2 つのマイクロバッチ間で注意計算負荷が均等に分散されるようにします。

つまり、同じプロンプトをそれらの間で配布できるということです。

2) デコード。

（注：関連データはまだ準備できていないため、後日公開されます。）

デコードの場合、構成ファイルは EP128、TP1、および 4K (実際のオンライン展開構成とほぼ一致) のヒント長を使用し、バッチ サイズは GPU あたり 128 リクエストになります。

事前パディングと同様に、デコードでも、重複計算と多対多通信のために 2 つのマイクロバッチ プロセスが使用されます。

ただし、事前パディングとは異なり、デコード中の全対全通信では GPU SM は消費されません。

RDMA メッセージが送信された後、すべての GPU SM が解放され、システムは計算が終了した後に全対全の通信が完了するまで待機します。

all-to-all 実装の詳細については、Open Source Week の第 2 回 DeepEP を参照してください。

もう一つ

「目もくらむほどの輝き！」

オープンソースコンテンツの第4弾に関するネットユーザーのコメントをいくつか紹介します。

これまでのところ、DeepSeek Open Source Week の最初の 4 日間は、フォロワーにとって非常に満足のいくものでした。

特に、今回のオープンソース ウィークでは、大規模モデルのインフラ レイヤーに重点が置かれました。

この物語をフォロ​​ーしている読者はこう言う。

より優れたチームワークは、チーム管理を最適化するだけでなく、最高レベルの AI パフォーマンスを実現するための秘訣でもあります。
DeepSeek は新しい標準を生み出しており、大規模トレーニングの未来はすぐそこにあります。

さて、DeepSeekオープンソースウィークは明日で終わりです。グランドフィナーレはどうなるのでしょうか？