ホーム AI・LLM 実効トークン毎秒の計算 作成日: 2026年7月20日 21:33 実効トークン毎秒の計算 入力 アクセラレータあたりのピークトークン毎秒2,500アクセラレータ数8利用率70 % AI・LLM 実効トークン毎秒の計算 アクセラレータ1台あたりのピーク速度、アクセラレータ数、利用率から、推論フリートが持続できるトークンスループットを見積もる。単一ストリームのピークではなく現実的な処理能力を示す。 入力 フリート アクセラレータあたりのピークトークン毎秒 ベンチマークで測定した、1台のアクセラレータがフルバッチで達する最良の持続スループット。これはそのアクセラレータ上の全同時リクエストにわたる合計出力であり、単一ストリームではありません。 アクセラレータ数 ≥ 1 ワークロードを並列で処理するアクセラレータの台数。各台がトラフィックを独立に分担するとき、スループットはこの台数にほぼ線形に比例します。 利用率 % 1 – 100 % フリートがベンチマークのピークで動作する時間の割合。実際のトラフィックには閑散時、不均一な負荷、スケジューリングの空きがあるため、持続出力は理論上の合計を下回ります。 結果 値を入力すると計算結果が表示されます。 実効スループット フリート全体の持続的な毎秒トークン数。アクセラレータあたり2,500に8台と利用率70 %を掛けた値で、およそ...です。処理能力の計画はこの値に対して行います。 詳細 1日あたりのトークン数 実効速度でフリートが1日に処理できるトークン数（...）。持続スループットに1日の86,400秒を掛けたものです。 共有 レポートを印刷 リセット 埋め込み この計算機を埋め込む プレビュー このコードをページに貼り付けると計算機を表示できます。 コードをコピー この計算を共有 このリンクを開くと、入力した値がそのまま表示されます。 リンクをコピー 共有する XFacebookLINE メール 最終更新: 2026-06-22 実効トークン毎秒 1台のアクセラレータのピークトークン速度は、最良の瞬間に捉えられたベンチマークの数値である。デプロイ全体が1日を通じて実際に持続するスループットはそれとは別物である。トラフィックは満ち引きし、アクセラレータは部分的にアイドルになり、容量は急増に備えて確保される。この計算は、その持続的なフリート規模の速度を、アクセラレータあたりのピーク、アクセラレータ数、利用率係数から見積もる。処理能力の計画はこの値に対して行うべきである。 ピークと持続スループット ピークの数値を足し合わせて処理能力を過大評価するのは容易である。ピークはすべてのアクセラレータがあらゆる瞬間にフルバッチで飽和していることを前提とするが、それが実際のフリートで実際の時間にわたって成り立つことはない。需要は不均一であり、負荷分散は不完全であり、運用者は急増を吸収するために意図的に余裕を残す。利用率係数はそのすべてを1つの乗数に畳み込み、楽観的な上限をワークロードに約束できる数値に変える。 計算式 veff=vg⋅G⋅uTd=veff⋅86400\begin{aligned} v_{eff} &= v_g \cdot G \cdot u \\ T_d &= v_{eff} \cdot 86400 \end{aligned}veffTd=vg⋅G⋅u=veff⋅86400 ここで vgv_g はアクセラレータあたりのピーク（毎秒トークン数）、GG はアクセラレータ数、uu は利用率、veffv_{eff} は持続スループット、TdT_d は1日に処理されるトークン数（1日は86,400秒）である。各台がトラフィックを独立に分担するとき、スループットはアクセラレータ数にほぼ線形に比例する。 計算例 それぞれフルバッチで毎秒2,500トークンとベンチマークされた8台のアクセラレータからなるフリートを、利用率70%で運用する場合を考える。 veff=2500×8×0.7=14,000 tokens/sTd=14,000×86400≈1.21×109 tokens/day\begin{aligned} v_{eff} &= 2500 \times 8 \times 0.7 = 14{,}000\ \text{tokens/s} \\ T_d &= 14{,}000 \times 86400 \approx 1.21 \times 10^{9}\ \text{tokens/day} \end{aligned}veffTd=2500×8×0.7=14,000 tokens/s=14,000×86400≈1.21×109 tokens/day このフリートは毎秒14,000トークンを持続し、1日におよそ12億トークンを処理できる。これが素朴なピーク毎秒20,000トークンをどれだけ下回るかに注目されたい。不完全な利用率に失われた容量の30%は、まさによりよいバッチ処理とスケジューリングで取り戻せる余地である。 計画への使い方 1日あたりのトークン数を予想需要と比較する。需要をこの処理能力で割って、この規模のフリートが何台分必要かを求め、平均を上回る急増のための余裕を加える。出力はアクセラレータ数と利用率の両方とともに上がるため、目標はハードウェアを増やすか利用率を上げるかのいずれでも達成できる。後者のほうが通常は安い手段である。アクセラレータあたりのピーク自体はバッチのベンチマークから得られ、バッチ推論スループットの計算で扱う。フル稼働を下回って運用するコスト面の帰結はGPU利用率コストの計算で扱う。 よくある質問 (FAQ)これはピークスループットとどう違いますかピークスループットは、1台のアクセラレータがフルバッチで飽和した瞬間に達する値です。実効スループットは、現実が入り込んだ後にフリート全体が長期にわたって持続する値です。トラフィックは不均一に到着し、一部のアクセラレータは部分的にアイドルになり、バッチは常に満杯とは限らず、容量は急増に備えて確保されます。アクセラレータあたりのピークに台数を掛けると理論上の上限が得られ、利用率を掛けると実際に約束できる数値まで下がります。処理能力の計画はピークではなく実効値を用いるべきです。 アクセラレータあたりのピークはどこから来ますかモデルサイズ、精度、系列長、サービングスタックに依存するため、実行する予定のバッチサイズで特定のモデルを特定のハードウェア上でベンチマークして測るのが最良です。妥当性の確認として、メモリ帯域幅のルーフラインが単一ストリームの復号の上限を与え、バッチサービングはそれに同時リクエスト数を掛けます。ベンチマークの値があればそれを用い、ルーフラインは楽観的な上限としてのみ用いてください。 これを処理能力の計画にどう使いますか実効スループット、または1日あたりのトークン数を、予想需要と比較します。あるワークロードが1日に一定数のトークンを必要とするなら、それを1日あたりの処理能力で割って、この規模のフリートが何台分必要かを求め、平均を上回る急増のための余裕を加えます。出力はアクセラレータ数と利用率の両方とともに上がるため、目標はハードウェアを増やすか、よりよいバッチ処理とスケジューリングで利用率を上げるかのいずれでも達成できます。後者のほうが通常は安く済みます。 免責事項 これはスループットがアクセラレータ数に線形に比例し、単一の利用率係数が現実のすべての損失を捉えると仮定します。ネットワーク、負荷分散、不揃いな系列長、テールレイテンシは持続出力をさらに下げることがあります。対象ハードウェアでベンチマークを取り、平均需要を上回る余裕を保ってください。 次のおすすめ バッチ推論スループットの計算 測定したバッチ完了時間から、合計の毎秒トークン数、リクエストごとの速度、毎秒リクエスト数を算出する。バッチ推論におけるスループットとレイテンシのトレードオフを示す。 詳しく解説GPU利用率コストの計算 アイドル時間を計上したときの予約アクセラレータの実コストを把握する。時間あたりの料金と利用率を入力すると、有用な1時間あたりの実効コストとアイドル容量に費やした金額が得られる。 詳しく解説 200+ ツール · 10 言語対応 · 完全無料 推論・サービングの他の計算 トークンあたりFLOPsの計算バッチ推論スループットの計算モデルFLOPs利用率の計算画像入力トークン数の計算実効トークン毎秒の計算推論スループットの計算 +2 more Show less 推論レイテンシの計算投機的デコーディングの高速化の計算 AI・LLMの他のカテゴリ コスト・料金 1ドルあたりトークン数の計算GPU クラウド費用を計算GPU利用率コストの計算LLMファインチューニング費用の計算LLMレート制限の計画LLM学習のカーボンフットプリントの計算LLM学習時間とコストの計算LLM月額コストの計算エージェントコストの計算コンテキストコストの増加の計算コンテキスト長の判定システムプロンプトの償却コストトークンから単語数への変換トークンコスト計算バッチAPIの節約額の計算プロンプトキャッシュの節約額の計算ベクトルDBコストの計算ベクトルDBサイズの計算音声合成コストの計算音声文字起こしコストの計算画像生成コストの計算関数呼び出しのトークンオーバーヘッド構造化出力のトークンオーバーヘッド自己ホストとAPIの損益分岐の計算推論エネルギーコストの計算埋め込みコストの計算学習・スケーリング Chinchilla最適トークン数LLMトレーニングVRAMの計算LoRA の学習パラメータ数を計算データセットのトークン数の計算データ並列スケーリングの計算パイプライン並列のバブルの計算学習FLOPsの計算学習率ウォームアップの計算計算最適なモデルサイズ計算予算から求めるエポック数勾配累積のメモリ計算実効バッチサイズの計算ハードウェア・メモリ KVキャッシュサイズの計算LLM推論のVRAM計算MoE のアクティブパラメータ数を計算Transformerのパラメータ数の計算アテンションメモリの計算モデルに必要なGPU台数の計算モデルのダウンロード時間の計算量子化によるモデルサイズの計算RAG・埋め込み RAGチャンク分割の設計評価 A/Bテスト有意性の計算LLM評価のサンプルサイズの計算pass@k の計算パープレキシティの計算すべてのツール コサイン類似度の計算 この計算機は役に立ちましたか？ 役に立った 改善が必要 改善が必要 どのような点が改善されると良いですか？ フィードバックを送信 Powered by OneCalc ↗
最終更新: 2026-06-22 実効トークン毎秒 1台のアクセラレータのピークトークン速度は、最良の瞬間に捉えられたベンチマークの数値である。デプロイ全体が1日を通じて実際に持続するスループットはそれとは別物である。トラフィックは満ち引きし、アクセラレータは部分的にアイドルになり、容量は急増に備えて確保される。この計算は、その持続的なフリート規模の速度を、アクセラレータあたりのピーク、アクセラレータ数、利用率係数から見積もる。処理能力の計画はこの値に対して行うべきである。 ピークと持続スループット ピークの数値を足し合わせて処理能力を過大評価するのは容易である。ピークはすべてのアクセラレータがあらゆる瞬間にフルバッチで飽和していることを前提とするが、それが実際のフリートで実際の時間にわたって成り立つことはない。需要は不均一であり、負荷分散は不完全であり、運用者は急増を吸収するために意図的に余裕を残す。利用率係数はそのすべてを1つの乗数に畳み込み、楽観的な上限をワークロードに約束できる数値に変える。 計算式 veff=vg⋅G⋅uTd=veff⋅86400\begin{aligned} v_{eff} &= v_g \cdot G \cdot u \\ T_d &= v_{eff} \cdot 86400 \end{aligned}veffTd=vg⋅G⋅u=veff⋅86400 ここで vgv_g はアクセラレータあたりのピーク（毎秒トークン数）、GG はアクセラレータ数、uu は利用率、veffv_{eff} は持続スループット、TdT_d は1日に処理されるトークン数（1日は86,400秒）である。各台がトラフィックを独立に分担するとき、スループットはアクセラレータ数にほぼ線形に比例する。 計算例 それぞれフルバッチで毎秒2,500トークンとベンチマークされた8台のアクセラレータからなるフリートを、利用率70%で運用する場合を考える。 veff=2500×8×0.7=14,000 tokens/sTd=14,000×86400≈1.21×109 tokens/day\begin{aligned} v_{eff} &= 2500 \times 8 \times 0.7 = 14{,}000\ \text{tokens/s} \\ T_d &= 14{,}000 \times 86400 \approx 1.21 \times 10^{9}\ \text{tokens/day} \end{aligned}veffTd=2500×8×0.7=14,000 tokens/s=14,000×86400≈1.21×109 tokens/day このフリートは毎秒14,000トークンを持続し、1日におよそ12億トークンを処理できる。これが素朴なピーク毎秒20,000トークンをどれだけ下回るかに注目されたい。不完全な利用率に失われた容量の30%は、まさによりよいバッチ処理とスケジューリングで取り戻せる余地である。 計画への使い方 1日あたりのトークン数を予想需要と比較する。需要をこの処理能力で割って、この規模のフリートが何台分必要かを求め、平均を上回る急増のための余裕を加える。出力はアクセラレータ数と利用率の両方とともに上がるため、目標はハードウェアを増やすか利用率を上げるかのいずれでも達成できる。後者のほうが通常は安い手段である。アクセラレータあたりのピーク自体はバッチのベンチマークから得られ、バッチ推論スループットの計算で扱う。フル稼働を下回って運用するコスト面の帰結はGPU利用率コストの計算で扱う。 よくある質問 (FAQ)これはピークスループットとどう違いますかピークスループットは、1台のアクセラレータがフルバッチで飽和した瞬間に達する値です。実効スループットは、現実が入り込んだ後にフリート全体が長期にわたって持続する値です。トラフィックは不均一に到着し、一部のアクセラレータは部分的にアイドルになり、バッチは常に満杯とは限らず、容量は急増に備えて確保されます。アクセラレータあたりのピークに台数を掛けると理論上の上限が得られ、利用率を掛けると実際に約束できる数値まで下がります。処理能力の計画はピークではなく実効値を用いるべきです。 アクセラレータあたりのピークはどこから来ますかモデルサイズ、精度、系列長、サービングスタックに依存するため、実行する予定のバッチサイズで特定のモデルを特定のハードウェア上でベンチマークして測るのが最良です。妥当性の確認として、メモリ帯域幅のルーフラインが単一ストリームの復号の上限を与え、バッチサービングはそれに同時リクエスト数を掛けます。ベンチマークの値があればそれを用い、ルーフラインは楽観的な上限としてのみ用いてください。 これを処理能力の計画にどう使いますか実効スループット、または1日あたりのトークン数を、予想需要と比較します。あるワークロードが1日に一定数のトークンを必要とするなら、それを1日あたりの処理能力で割って、この規模のフリートが何台分必要かを求め、平均を上回る急増のための余裕を加えます。出力はアクセラレータ数と利用率の両方とともに上がるため、目標はハードウェアを増やすか、よりよいバッチ処理とスケジューリングで利用率を上げるかのいずれでも達成できます。後者のほうが通常は安く済みます。 免責事項 これはスループットがアクセラレータ数に線形に比例し、単一の利用率係数が現実のすべての損失を捉えると仮定します。ネットワーク、負荷分散、不揃いな系列長、テールレイテンシは持続出力をさらに下げることがあります。対象ハードウェアでベンチマークを取り、平均需要を上回る余裕を保ってください。
