ホーム AI・LLM データ並列スケーリングの計算 作成日: 2026年7月20日 21:33 データ並列スケーリングの計算 入力 デバイス数64デバイスごとのスループット2,000スケーリング効率90 % AI・LLM データ並列スケーリングの計算 デバイスごとのスループットとスケーリング効率から、データ並列デバイス全体の実際の学習スループットを見積もる。理想的な線形スループットと、1台のデバイスに対して達成された高速化倍率も併せて算出する。 入力 クラスタ デバイス数 ≥ 1 作業を分担するデータ並列アクセラレータの台数。各デバイスはモデルの複製を保持し、自身のマイクロバッチを並列に処理する。 デバイスごとのスループット 1台のデバイスが単独で持続的に出せるスループット（毎秒あたりのサンプル数またはトークン数）。この単位が理想値と実際値にそのまま引き継がれる。 スケーリング効率 % 0 – 100 % 理想的な線形スケーリングのうち実際に達成された割合（0から1の間）。通信、同期、負荷の偏りによって1を下回る。 結果 値を入力すると計算結果が表示されます。 実際のスループット 損失を考慮した現実的なスループット。理想の...を効率90 %で割り引いて、...となる。 高速化倍率 クラスタが1台のデバイスより何倍速く動くか。64台×効率90 %で、...倍となる。 詳細 理想スループット スケーリングが完全に線形だった場合のスループット。64台×それぞれ2,000で、...となる。 共有 レポートを印刷 リセット 埋め込み この計算機を埋め込む プレビュー このコードをページに貼り付けると計算機を表示できます。 コードをコピー この計算を共有 このリンクを開くと、入力した値がそのまま表示されます。 リンクをコピー 共有する XFacebookLINE メール 最終更新: 2026-06-22 データ並列スケーリング データ並列は、モデルの学習を速くする最も一般的な方法です。モデルを多数のアクセラレータに複製し、各複製にバッチの一部を与え、毎ステップ勾配を平均します。理想的にはスループットがデバイス数に正比例して上がるはずですが、実際にはそうなりません。複製を同期させ続ける勾配の平均化に、クラスタの規模とともに増える時間がかかるためです。この計算では、その損失を考慮する前の理想的な線形スループットと、考慮した後の現実的な値を分けて示し、結果として得られる高速化倍率を求めます。 理想と実際 理想スループットは、完全なスケーリングが与える値です。すなわち、各デバイスが単独性能をオーバーヘッドなしにすべて発揮した場合のスループットです。実際のスループットは、その理想をスケーリング効率で割り引いた値です。スケーリング効率は0から1の間の単一の割合で、並列実行の不完全さをすべて吸収します。効率が0.9なら、クラスタは理論上の最大の90%を発揮するため、64台のジョブは完全にスケールする57.6台分のように振る舞います。 計算式 デバイス数を dd、デバイスごとのスループットを vv、スケーリング効率を EE とすると、理想スループット II、実際のスループット AA、および一台のデバイスに対する高速化倍率 SS は次のようになります。 I=d⋅vA=I⋅ES=d⋅E\begin{aligned} I &= d \cdot v \\ A &= I \cdot E \\ S &= d \cdot E \end{aligned}IAS=d⋅v=I⋅E=d⋅E 高速化倍率は、デバイス数を効率で縮小しただけの値です。1台のデバイスは vv で動き、クラスタは A=d⋅v⋅EA = d \cdot v \cdot E で動くためです。 計算例 64台のデバイスがそれぞれ単独で毎秒2,000サンプルを持続し、実測のスケーリング効率が0.9の場合を考えます。 I=64×2000=128,000A=128,000×0.9=115,200S=64×0.9=57.6\begin{aligned} I &= 64 \times 2000 = 128{,}000 \\ A &= 128{,}000 \times 0.9 = 115{,}200 \\ S &= 64 \times 0.9 = 57.6 \end{aligned}IAS=64×2000=128,000=128,000×0.9=115,200=64×0.9=57.6 クラスタは毎秒115,200サンプルを処理します。これは1台のデバイスに対して57.6倍の高速化であり、完全なスケーリングが意味する64倍ではありません。差にあたる毎秒およそ13,000サンプルが、複製を同期させ続けるためのコストです。 限界 このモデルは、スケーリング損失のあらゆる要因を、ユーザーが与える一つの効率の値に凝縮します。その値をインターコネクトの帯域幅・モデルサイズ・バッチから予測することはしません。効率が一定であることもまれです。勾配のall-reduceが増える一方でデバイスごとの計算量は変わらないため、デバイスを増やすほど効率は通常下がります。したがって、あるクラスタ規模で測った値を別の規模で前提にすべきではありません。ここでは純粋なデータ並列を前提としています。この複製がもたらすバッチへの影響は実効バッチサイズの計算が、モデルをパイプライン段に分割する際の固有のオーバーヘッドはパイプライン並列のバブルの計算が扱います。 よくある質問 (FAQ)スケーリング効率とは何ですか。スケーリング効率とは、クラスタが実際に達成するスループットを、追加した各デバイスがそれぞれの単独性能をすべて発揮した場合に達成されるスループットで割った比率です。効率が0.9であれば、64台のデバイスが理想的な57.6台分の働きをすることを意味します。 この値は、勾配通信、同期待ち、作業の偏りなど、不完全なスケーリングのあらゆる要因を0から1の間の単一の割合にまとめたものであり、学習ジョブの並列化がどれだけうまくいっているかを報告する標準的な方法です。 なぜスケーリングは線形にならないのですか。データ並列学習では各オプティマイザステップで、すべてのデバイス間で勾配を交換して平均するall-reduceが必要になります。この通信はデバイスごとの有用な計算量が一定のままクラスタの規模とともに増大します。 さらに同期バリア、グループ全体を待たせる落伍デバイス、デバイス数の増加に伴って縮小する計算対通信の比率が加わるため、追加されたデバイスの寄与は最初のデバイスより小さくなります。その結果が線形を下回るスケーリングであり、ここでは1未満の効率として表現されます。 スケーリング効率はどうすれば改善できますか。一般的な手段は、通信の間に行う計算量を増やすこと、すなわちデバイスごとのバッチを大きくしたり勾配累積を用いたりして、固定的なall-reduceのコストをより多くの作業で薄めることです。加えて、より高速なインターコネクトやトポロジを考慮した集団通信アルゴリズムを用いて通信そのものを削減します。 勾配通信を逆伝播と重ね合わせること、データシャーディングのバランスを取って落伍デバイスを減らすことも有効です。デバイスを増やしても効率が安定して保たれることが、よく調整された並列構成の証です。 免責事項 これは、スケーリング損失をユーザーが与える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 データ並列スケーリング データ並列は、モデルの学習を速くする最も一般的な方法です。モデルを多数のアクセラレータに複製し、各複製にバッチの一部を与え、毎ステップ勾配を平均します。理想的にはスループットがデバイス数に正比例して上がるはずですが、実際にはそうなりません。複製を同期させ続ける勾配の平均化に、クラスタの規模とともに増える時間がかかるためです。この計算では、その損失を考慮する前の理想的な線形スループットと、考慮した後の現実的な値を分けて示し、結果として得られる高速化倍率を求めます。 理想と実際 理想スループットは、完全なスケーリングが与える値です。すなわち、各デバイスが単独性能をオーバーヘッドなしにすべて発揮した場合のスループットです。実際のスループットは、その理想をスケーリング効率で割り引いた値です。スケーリング効率は0から1の間の単一の割合で、並列実行の不完全さをすべて吸収します。効率が0.9なら、クラスタは理論上の最大の90%を発揮するため、64台のジョブは完全にスケールする57.6台分のように振る舞います。 計算式 デバイス数を dd、デバイスごとのスループットを vv、スケーリング効率を EE とすると、理想スループット II、実際のスループット AA、および一台のデバイスに対する高速化倍率 SS は次のようになります。 I=d⋅vA=I⋅ES=d⋅E\begin{aligned} I &= d \cdot v \\ A &= I \cdot E \\ S &= d \cdot E \end{aligned}IAS=d⋅v=I⋅E=d⋅E 高速化倍率は、デバイス数を効率で縮小しただけの値です。1台のデバイスは vv で動き、クラスタは A=d⋅v⋅EA = d \cdot v \cdot E で動くためです。 計算例 64台のデバイスがそれぞれ単独で毎秒2,000サンプルを持続し、実測のスケーリング効率が0.9の場合を考えます。 I=64×2000=128,000A=128,000×0.9=115,200S=64×0.9=57.6\begin{aligned} I &= 64 \times 2000 = 128{,}000 \\ A &= 128{,}000 \times 0.9 = 115{,}200 \\ S &= 64 \times 0.9 = 57.6 \end{aligned}IAS=64×2000=128,000=128,000×0.9=115,200=64×0.9=57.6 クラスタは毎秒115,200サンプルを処理します。これは1台のデバイスに対して57.6倍の高速化であり、完全なスケーリングが意味する64倍ではありません。差にあたる毎秒およそ13,000サンプルが、複製を同期させ続けるためのコストです。 限界 このモデルは、スケーリング損失のあらゆる要因を、ユーザーが与える一つの効率の値に凝縮します。その値をインターコネクトの帯域幅・モデルサイズ・バッチから予測することはしません。効率が一定であることもまれです。勾配のall-reduceが増える一方でデバイスごとの計算量は変わらないため、デバイスを増やすほど効率は通常下がります。したがって、あるクラスタ規模で測った値を別の規模で前提にすべきではありません。ここでは純粋なデータ並列を前提としています。この複製がもたらすバッチへの影響は実効バッチサイズの計算が、モデルをパイプライン段に分割する際の固有のオーバーヘッドはパイプライン並列のバブルの計算が扱います。 よくある質問 (FAQ)スケーリング効率とは何ですか。スケーリング効率とは、クラスタが実際に達成するスループットを、追加した各デバイスがそれぞれの単独性能をすべて発揮した場合に達成されるスループットで割った比率です。効率が0.9であれば、64台のデバイスが理想的な57.6台分の働きをすることを意味します。 この値は、勾配通信、同期待ち、作業の偏りなど、不完全なスケーリングのあらゆる要因を0から1の間の単一の割合にまとめたものであり、学習ジョブの並列化がどれだけうまくいっているかを報告する標準的な方法です。 なぜスケーリングは線形にならないのですか。データ並列学習では各オプティマイザステップで、すべてのデバイス間で勾配を交換して平均するall-reduceが必要になります。この通信はデバイスごとの有用な計算量が一定のままクラスタの規模とともに増大します。 さらに同期バリア、グループ全体を待たせる落伍デバイス、デバイス数の増加に伴って縮小する計算対通信の比率が加わるため、追加されたデバイスの寄与は最初のデバイスより小さくなります。その結果が線形を下回るスケーリングであり、ここでは1未満の効率として表現されます。 スケーリング効率はどうすれば改善できますか。一般的な手段は、通信の間に行う計算量を増やすこと、すなわちデバイスごとのバッチを大きくしたり勾配累積を用いたりして、固定的なall-reduceのコストをより多くの作業で薄めることです。加えて、より高速なインターコネクトやトポロジを考慮した集団通信アルゴリズムを用いて通信そのものを削減します。 勾配通信を逆伝播と重ね合わせること、データシャーディングのバランスを取って落伍デバイスを減らすことも有効です。デバイスを増やしても効率が安定して保たれることが、よく調整された並列構成の証です。 免責事項 これは、スケーリング損失をユーザーが与える1つの効率の割合として捉える一次近似のモデルである。その割合をインターコネクトの帯域幅、モデルサイズ、バッチから導出することはせず、純粋なデータ並列を前提とする。固定値を仮定するのではなく、自身のクラスタで効率を実測すること。
