ホーム AI・LLM パイプライン並列のバブルの計算 作成日: 2026年7月20日 21:33 パイプライン並列のバブルの計算 入力 パイプライン段数8マイクロバッチ数32 AI・LLM パイプライン並列のバブルの計算 パイプラインの段数と1バッチあたりのマイクロバッチ数から、パイプライン並列学習におけるバブルの割合と、それに伴う計算効率を求める。 入力 パイプライン パイプライン段数 ≥ 1 モデルを分割する逐次的な段の数で、デバイス群ごとに1段。パイプラインは全段が稼働するまでにこの段数分のステップで満たされる。 マイクロバッチ数 ≥ 1 グローバルバッチを分割してパイプラインに流すマイクロバッチの数。マイクロバッチが多いほど、立ち上げと排出に対して各段が長く稼働し続ける。 結果 値を入力すると計算結果が表示されます。 バブルの割合 % 立ち上げと排出のアイドル時間に費やされるスケジュールの割合。8段から1を引いた値を、32マイクロバッチに段数を足して1を引いた値で割ったもので、...。 パイプライン効率 % 有用な計算を行うスケジュールの割合。32マイクロバッチを同じ総数で割ったもので、...。これはバブルの割合を1から引いた値。 共有 レポートを印刷 リセット 埋め込み この計算機を埋め込む プレビュー このコードをページに貼り付けると計算機を表示できます。 コードをコピー この計算を共有 このリンクを開くと、入力した値がそのまま表示されます。 リンクをコピー 共有する XFacebookLINE メール 最終更新: 2026-06-22 パイプライン並列のバブル パイプライン並列は、モデルを逐次的な段に分割し、各段を別々のデバイス群に配置します。最初のデバイス上の層ブロックが出力を次へ渡し、これが順に続きます。これにより1台のアクセラレータに収まらないモデルを複数台にまたがらせられますが、特有の代償を伴います。すなわち、すべての段を同時には稼働させられないことです。バッチの始めには後方の段がデータの到着を待って手すきになり、終わりには最後のマイクロバッチが流れ出るにつれて前方の段が手すきになります。このアイドル区間がパイプラインのバブルであり、この計算ではそれを定量化します。 バブルが生じる理由 8つの工程からなる組立ラインを考えます。最初の品物は工程一から工程七を通り抜けてからでないと工程八に仕事が回らず、その時点でラインが完全には使われていないステップが七つ経過しています。ラインが空になるときも同じことが逆向きに起こります。pp 段のパイプラインでは、この立ち上げと冷却のコストは、後にどれだけの作業が続くかにかかわらず p − 1p\,{-}\,1 ステップになります。その固定コストが問題になるかどうかは、その後ろを何個のマイクロバッチが流れるかで決まります。 計算式 pp 段のパイプラインと mm 個のマイクロバッチについて、標準的な同期スケジュールでのバブルの割合 BB と、相補的な効率 EE は次のようになります。 B=p−1m+p−1E=mm+p−1\begin{aligned} B &= \frac{p - 1}{m + p - 1} \\ E &= \frac{m}{m + p - 1} \end{aligned}BE=m+p−1p−1=m+p−1m 分母はパイプラインの総ステップ数、すなわち mm 個の有用なマイクロバッチに、立ち上げと排出の p − 1p\,{-}\,1 ステップを足したものです。あらゆるステップは有用な作業かバブルのいずれかなので、2つの割合は常に足して1になります。 計算例 8段のパイプラインに1バッチあたり32個のマイクロバッチを流す場合を考えます。 B=8−132+8−1=739≈0.179=17.9%E=3239≈0.821=82.1%\begin{aligned} B &= \frac{8 - 1}{32 + 8 - 1} = \frac{7}{39} \approx 0.179 = 17.9\% \\ E &= \frac{32}{39} \approx 0.821 = 82.1\% \end{aligned}BE=32+8−18−1=397≈0.179=17.9%=3932≈0.821=82.1% スケジュールのおよそ18%がバブルに失われ、有用な計算には約82%が残ります。マイクロバッチ数を64に増やすと、固定の七ステップの立ち上げがより多くの作業に分散されるため、バブルはおよそ11%まで下がります。 限界 この式は、標準的な同期スケジュール、各段のコストが等しいこと、段間の通信が無視できるほど小さいことを前提としています。連続しない複数の段の塊を各デバイスに割り当てるインターリーブ方式は、ここで得られる値よりバブルを小さくします。一方、段ごとのコストの偏りや段間の重い転送があると、実際の効率は悪化することがあります。ここでのマイクロバッチ数は、グローバルバッチを通じてオプティマイザの挙動を左右する量でもあり、これは実効バッチサイズの計算が扱います。またパイプライン並列は通常データ並列と組み合わされ、その固有のスケーリング損失はデータ並列スケーリングの計算が扱います。 よくある質問 (FAQ)パイプラインのバブルとは何ですか。パイプライン並列では、モデルを逐次的な段に分けて別々のデバイスに置き、マイクロバッチが組立ラインのようにそれらを流れます。各バッチの始めには最初の段だけが処理を持ち、残りはデータの到着を待ちます。終わりには、最後の段が処理を終えるあいだ前方の段が手すきになります。この立ち上げと排出のアイドル時間がバブルです。 順伝播と逆伝播の回数が同じ同期スケジュールでは、バブルは段数から1を引いたぶんの立ち上げステップが、スケジュール全体に広がったものに相当します。 バブルはどうすれば減らせますか。直接的な手段はバッチをより多くのマイクロバッチに分割することです。立ち上げと排出のコストは段数から1を引いたステップ数で固定されているため、バッチを細かく分けるほどその固定コストがより多くの有用な作業に分散され、バブルの割合が縮みます。 インターリーブ方式などの高度なスケジュールは、連続しない複数の段を各デバイスに割り当てることでさらに削減します。ただしマイクロバッチを増やすと1マイクロバッチあたりのサイズが小さくなり、カーネルの効率を損なうこともあるため、バブルは消滅ではなく縮小にとどまります。 段数とマイクロバッチ数はどう関係しますか。段数を増やすとパイプラインが深くなり、立ち上げと排出のコストが上がるため、マイクロバッチ数が一定ならバブルが大きくなります。マイクロバッチを増やすと逆に作用し、その固定コストが薄まります。目安として、バブルを小さく保つにはマイクロバッチ数を段数より十分大きく、しばしば4倍以上に保ちます。バブルの割合と効率は常に足して1になるため、一方を改善すればもう一方も改善します。 免責事項 これは標準的な同期パイプラインのバブルの式を用い、各段のコストが等しいこと、単純な立ち上げ・排出スケジュール、段間の通信が無視できることを前提とします。インターリーブ方式や段ごとのコストの偏りがあると結果は変わります。実測の効率の保証ではなく、計画用の概算として扱ってください。 次のおすすめ データ並列スケーリングの計算 デバイスごとのスループットとスケーリング効率から、データ並列デバイス全体の実際の学習スループットを見積もる。理想的な線形スループットと、1台のデバイスに対して達成された高速化倍率も併せて算出する。 詳しく解説実効バッチサイズの計算 デバイスごとのマイクロバッチ、データ並列のデバイス数、勾配累積ステップ数から、分散学習における実効（グローバル）バッチサイズを求める。オプティマイザの1ステップあたりのトークン数も併せて算出する。 詳しく解説 200+ ツール · 10 言語対応 · 完全無料 学習・スケーリングの他の計算 Chinchilla最適トークン数LLMトレーニングVRAMの計算LoRA の学習パラメータ数を計算データセットのトークン数の計算データ並列スケーリングの計算パイプライン並列のバブルの計算 +6 more Show less 学習FLOPsの計算学習率ウォームアップの計算計算最適なモデルサイズ計算予算から求めるエポック数勾配累積のメモリ計算実効バッチサイズの計算 AI・LLMの他のカテゴリ コスト・料金 1ドルあたりトークン数の計算GPU クラウド費用を計算GPU利用率コストの計算LLMファインチューニング費用の計算LLMレート制限の計画LLM学習のカーボンフットプリントの計算LLM学習時間とコストの計算LLM月額コストの計算エージェントコストの計算コンテキストコストの増加の計算コンテキスト長の判定システムプロンプトの償却コストトークンから単語数への変換トークンコスト計算バッチAPIの節約額の計算プロンプトキャッシュの節約額の計算ベクトルDBコストの計算ベクトルDBサイズの計算音声合成コストの計算音声文字起こしコストの計算画像生成コストの計算関数呼び出しのトークンオーバーヘッド構造化出力のトークンオーバーヘッド自己ホストとAPIの損益分岐の計算推論エネルギーコストの計算埋め込みコストの計算推論・サービング トークンあたりFLOPsの計算バッチ推論スループットの計算モデルFLOPs利用率の計算画像入力トークン数の計算実効トークン毎秒の計算推論スループットの計算推論レイテンシの計算投機的デコーディングの高速化の計算ハードウェア・メモリ KVキャッシュサイズの計算LLM推論のVRAM計算MoE のアクティブパラメータ数を計算Transformerのパラメータ数の計算アテンションメモリの計算モデルに必要なGPU台数の計算モデルのダウンロード時間の計算量子化によるモデルサイズの計算RAG・埋め込み RAGチャンク分割の設計評価 A/Bテスト有意性の計算LLM評価のサンプルサイズの計算pass@k の計算パープレキシティの計算すべてのツール コサイン類似度の計算 この計算機は役に立ちましたか？ 役に立った 改善が必要 改善が必要 どのような点が改善されると良いですか？ フィードバックを送信 Powered by OneCalc ↗
最終更新: 2026-06-22 パイプライン並列のバブル パイプライン並列は、モデルを逐次的な段に分割し、各段を別々のデバイス群に配置します。最初のデバイス上の層ブロックが出力を次へ渡し、これが順に続きます。これにより1台のアクセラレータに収まらないモデルを複数台にまたがらせられますが、特有の代償を伴います。すなわち、すべての段を同時には稼働させられないことです。バッチの始めには後方の段がデータの到着を待って手すきになり、終わりには最後のマイクロバッチが流れ出るにつれて前方の段が手すきになります。このアイドル区間がパイプラインのバブルであり、この計算ではそれを定量化します。 バブルが生じる理由 8つの工程からなる組立ラインを考えます。最初の品物は工程一から工程七を通り抜けてからでないと工程八に仕事が回らず、その時点でラインが完全には使われていないステップが七つ経過しています。ラインが空になるときも同じことが逆向きに起こります。pp 段のパイプラインでは、この立ち上げと冷却のコストは、後にどれだけの作業が続くかにかかわらず p − 1p\,{-}\,1 ステップになります。その固定コストが問題になるかどうかは、その後ろを何個のマイクロバッチが流れるかで決まります。 計算式 pp 段のパイプラインと mm 個のマイクロバッチについて、標準的な同期スケジュールでのバブルの割合 BB と、相補的な効率 EE は次のようになります。 B=p−1m+p−1E=mm+p−1\begin{aligned} B &= \frac{p - 1}{m + p - 1} \\ E &= \frac{m}{m + p - 1} \end{aligned}BE=m+p−1p−1=m+p−1m 分母はパイプラインの総ステップ数、すなわち mm 個の有用なマイクロバッチに、立ち上げと排出の p − 1p\,{-}\,1 ステップを足したものです。あらゆるステップは有用な作業かバブルのいずれかなので、2つの割合は常に足して1になります。 計算例 8段のパイプラインに1バッチあたり32個のマイクロバッチを流す場合を考えます。 B=8−132+8−1=739≈0.179=17.9%E=3239≈0.821=82.1%\begin{aligned} B &= \frac{8 - 1}{32 + 8 - 1} = \frac{7}{39} \approx 0.179 = 17.9\% \\ E &= \frac{32}{39} \approx 0.821 = 82.1\% \end{aligned}BE=32+8−18−1=397≈0.179=17.9%=3932≈0.821=82.1% スケジュールのおよそ18%がバブルに失われ、有用な計算には約82%が残ります。マイクロバッチ数を64に増やすと、固定の七ステップの立ち上げがより多くの作業に分散されるため、バブルはおよそ11%まで下がります。 限界 この式は、標準的な同期スケジュール、各段のコストが等しいこと、段間の通信が無視できるほど小さいことを前提としています。連続しない複数の段の塊を各デバイスに割り当てるインターリーブ方式は、ここで得られる値よりバブルを小さくします。一方、段ごとのコストの偏りや段間の重い転送があると、実際の効率は悪化することがあります。ここでのマイクロバッチ数は、グローバルバッチを通じてオプティマイザの挙動を左右する量でもあり、これは実効バッチサイズの計算が扱います。またパイプライン並列は通常データ並列と組み合わされ、その固有のスケーリング損失はデータ並列スケーリングの計算が扱います。 よくある質問 (FAQ)パイプラインのバブルとは何ですか。パイプライン並列では、モデルを逐次的な段に分けて別々のデバイスに置き、マイクロバッチが組立ラインのようにそれらを流れます。各バッチの始めには最初の段だけが処理を持ち、残りはデータの到着を待ちます。終わりには、最後の段が処理を終えるあいだ前方の段が手すきになります。この立ち上げと排出のアイドル時間がバブルです。 順伝播と逆伝播の回数が同じ同期スケジュールでは、バブルは段数から1を引いたぶんの立ち上げステップが、スケジュール全体に広がったものに相当します。 バブルはどうすれば減らせますか。直接的な手段はバッチをより多くのマイクロバッチに分割することです。立ち上げと排出のコストは段数から1を引いたステップ数で固定されているため、バッチを細かく分けるほどその固定コストがより多くの有用な作業に分散され、バブルの割合が縮みます。 インターリーブ方式などの高度なスケジュールは、連続しない複数の段を各デバイスに割り当てることでさらに削減します。ただしマイクロバッチを増やすと1マイクロバッチあたりのサイズが小さくなり、カーネルの効率を損なうこともあるため、バブルは消滅ではなく縮小にとどまります。 段数とマイクロバッチ数はどう関係しますか。段数を増やすとパイプラインが深くなり、立ち上げと排出のコストが上がるため、マイクロバッチ数が一定ならバブルが大きくなります。マイクロバッチを増やすと逆に作用し、その固定コストが薄まります。目安として、バブルを小さく保つにはマイクロバッチ数を段数より十分大きく、しばしば4倍以上に保ちます。バブルの割合と効率は常に足して1になるため、一方を改善すればもう一方も改善します。 免責事項 これは標準的な同期パイプラインのバブルの式を用い、各段のコストが等しいこと、単純な立ち上げ・排出スケジュール、段間の通信が無視できることを前提とします。インターリーブ方式や段ごとのコストの偏りがあると結果は変わります。実測の効率の保証ではなく、計画用の概算として扱ってください。
