LLMベンチマークの読み方：tokens per secondと待ち時間を測る

LLMベンチマークを読む：tokens per secondは何を測る指標ですか？

出力のtokens per secondは、最初のトークンが届いた後、LLMが生成したトークンをどのくらいの速さで届けるかを表す指標です。 大規模言語モデル（LLM）は、テキストをトークンという単位で処理します。トークンは単語のこともあれば、単語の一部や句読点のこともあります。したがって、トークン数をそのまま単語数として扱うことはできません。Cerebrasの定義でも、この違いが明確に示されています。

図書館に入り、必要な本を順番に受け取る場面を考えてみてください。入口が開くまでの待ち時間と、本が手渡されるペースは別のものです。必要な本をすべてそろえて帰れる時刻には、その両方が影響します。本を素早く渡してもらえても、入口で長く待った時間は取り戻せません。

アプリケーションでは、次の指標を分けて記録します。

これらの区分はArtificial Analysisの指標定義に沿っています。推論の最初のトークンは、回答の最初のトークンより先に届くことがあります。そのため、両者の時間には別々の名前が必要です。

アプリケーション全体のレイテンシは、ユーザーが操作してから、役に立つ結果を得るまでの時間です。音声アシスタントなら音声が聞こえる時点、エージェントなら操作が完了する時点が終点になるでしょう。検索、ツールの実行、音声合成、画面の更新は、モデルへのリクエストの外側で行われることがあります。この範囲も含めて計測してください。

モデル内部の処理は、プロンプトを処理する**プリフィル（prefill）と、続きを生成するデコード（decode）**に分かれます。LLM推論の解説では、これらの処理が配信システムをどう通るかを説明しています。

速度の数値だけでは判断できない理由

速度の測定結果が示すのは、あるエンドポイントで、あるワークロードを処理したときの性能です。条件にかかわらずモデルに備わる固定の性質ではありません。処理内容や配信条件を変えれば、比較の前提も変わります。

プロンプトの長さとキャッシュの状態

短い質問だけのサポートチャットと、長い会話履歴や検索した規約文書を含むチャットでは、処理内容が異なります。入力が増えれば、回答前に必要な処理も変わります。Groqも、レイテンシ最適化ガイドで入力サイズをTTFTに影響する要因として挙げています。

テストの記録には、プロンプトの長さとキャッシュの状態を残してください。KVキャッシュの解説では、生成時に使う保存済みのアテンション状態と、プロンプトの再利用がキャッシュにどう関係するかを説明しています。同じプロンプトを繰り返してキャッシュが温まった結果を、新しい顧客との会話の結果として扱ってはいけません。

回答が始まる前の推論

推論モデルは、回答を返す前に中間的なトークンを生成することがあります。生成が速いからといって、推論にどれだけの処理を費やすかまではわかりません。公表された速度に推論のストリームが含まれるか、最初のトークンまでの計測が推論テキストで止まるのか、回答テキストで止まるのかを確認してください。

予約アシスタントで意味があるのは、使える返答やツール呼び出しが得られる時点です。「思考中」の表示はリクエストを受け付けたことを伝えられますが、それだけで予約は完了しません。

バッチ処理と同時リクエスト数

バッチ処理は、複数の処理をまとめてハードウェアの稼働効率を高めます。総スループットは複数のリクエストにわたる出力の合計を数える指標で、ユーザーごとの速度は個々のリクエストに届くストリームの速さです。Cerebrasは、バッチ処理によってスループットが向上する一方、待ち時間が増える場合があると説明しています。出典：Cerebrasのスループット解説。

運用時に確認すべきなのは、別の会話が増えても、各会話の出力が滞らずに進むかどうかです。実際の利用を代表する同時アクセスを再現し、リクエストの失敗や再試行も含めて測ってください。ほかに負荷のないエンドポイントで良い結果が出ても、この点はわかりません。

リージョンと配信経路

アプリケーションと配信エンドポイントの所在地は、ネットワークの遅延に影響します。Groqはネットワーク分析のガイドで、サーバー側の処理時間とクライアントが体験するレイテンシを区別しています。

バックエンドを稼働させるリージョンから計測してください。アプリケーションがストリームをブラウザへ中継する場合は、ブラウザ側でも測ります。途中のバッファリングによって、上流では滑らかに届くレスポンスが、画面にはまとまって断続的に現れることがあるためです。この経路を改善するほうが、モデルの変更より効果的な場合もあります。

GPUごとのtokens per secondはどう比較しますか？

推論を実行するアクセラレータであるGPUに、モデルやワークロードから独立した、単独で意味を持つtokens per secondの定格値はありません。ハードウェアを比較するなら、測定結果とともに、モデル、数値精度、コンテキスト、配信構成、同時負荷を示す必要があります。

量子化は数値精度を下げてメモリを節約する手法です。速度と品質のトレードオフは実装によって変わります。Cerebrasもモデル圧縮の解説で、この違いを説明しています。圧縮したモデルの実行環境を比較する際はLLM量子化ガイドを参照し、速度の計測とあわせて回答品質も確認してください。

プロバイダーの公表値をどう読み解きますか？

公表された速度は、モデル名と日付を伴う、各社の主張として扱ってください。以下の提供元のページは2026年10月24日に確認しました。掲載しているのは各社の公表値であり、この記事のために実測した結果ではありません。

Cerebras：公表速度と利用環境の条件

推論サービスを提供するCerebrasは、Developerの表でOpenAI GPT-OSS 120Bの速度を**「~3000 tokens/s」**と記載しています。同じページには、性能はモデルと構成によって変わること、Developerでのアクセスは本番運用ではなく評価を目的としていることも書かれています。出典：Cerebrasの料金ページ。

確認すべきなのは、契約できる実行環境が、自分のワークロードを必要な応答性と処理能力でさばけるかどうかです。表の数値だけでは判断できません。

Groqのtokens per second：対象モデルの行を確認する

推論サービスを提供するGroqは、対応モデル一覧のOpenAI GPT-OSS 120Bの行で、**「SPEED (T/SEC)」欄に「500」**と記載しています。これは、そのモデルについてGroqが公表している値です。出典：Groqの対応モデル一覧。

これらの表から、アプリケーションで各社にどれだけの速度差が出るかを導くことはできません。そうした比較には、プロンプト、推論設定、トークンの数え方、負荷、計測区間をそろえる必要があります。

速度とコストのバランスを判断する際は、Cerebras料金ガイドとGroq料金ガイドを使い、タスクを正常に完了するための費用と、必要な処理能力を比較してください。

独立したベンチマークはどこで確認できますか？

独立したベンチマークサービスのArtificial Analysisは、モデルや推論プロバイダーを比較する出発点として役立ちます。プロバイダーのランキングを開いたら、各結果の前提となるエンドポイントとワークロードまで確認してください。

同サービスの性能測定手法には、現時点で次の条件が示されています。

• 標準のワークロードは、入力が約10,000トークン、回答が少なくとも1,500トークンです。
• 通常のワークロードでは、過去72時間の中央値で結果を示します。
• 主なテストサーバーは、Google Cloudの**us-central1-a**ゾーンにあります。
• 性能測定のトークン数は、各モデル固有のトークナイザーではなく、**o200k_base**で正規化します。

これは共通の比較基準であって、自分のアプリケーションの性能を約束するものではありません。結果を比べる前に、プロンプトのサイズ、エンドポイント、推論モード、測定日を確認してください。プロンプトが長くなると、最初のトークンまでの待ち時間も出力速度も変わる可能性があります。

推論トークンの一部を公開しない推論モデルについて、Artificial Analysisは**回答チャンクの最後の80%**を使って出力速度を計算します。以下の簡単なスクリプトは、その手法やベンチマーク全体のワークロードを再現するものではありません。クライアントで観測したテキストストリームを測ります。

自分のストリームを実測するには？

受信側のクライアントで測定し、ストリーミングのイベント数ではなく、テキストのトークン数を数えてください。イベントにはテキストが含まれない場合も、まとまったテキストが含まれる場合もあります。イベント数を数えると、測っているのは毎秒のチャンク数になります。

以下のPythonの例は、GroqのストリーミングAPIと、テキスト用トークナイザーのtiktokenを使います。最初のテキストチャンクが届くまでの時間、リクエスト送信から最後のテキスト受信までの時間、ストリーム完了までの時間、そして正規化した出力のtokens per secondの推定値を表示します。

必要なライブラリをインストールします。

python3 -m pip install groq tiktoken

環境変数にGROQ_API_KEYを設定してください。GROQ_MODELには、Groqの対応モデル一覧にあり、自分のアカウントで利用できる非推論型のテキストモデルを指定します。アプリケーションの実際の使い方を代表するプロンプトをprompt.txtに保存してください。以下をmeasure_stream.pyとして保存し、python3 measure_stream.pyを実行します。

import os
from pathlib import Path
from time import perf_counter

import tiktoken
from groq import Groq

encoder = tiktoken.get_encoding("o200k_base")
prompt = Path("prompt.txt").read_text(encoding="utf-8")
model = os.environ["GROQ_MODEL"]
parts = []
first = last = None

with Groq(max_retries=0) as client:
    start = perf_counter()
    stream = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    for event in stream:
        now = perf_counter()
        if not event.choices:
            continue
        text = event.choices[0].delta.content or ""
        if not text:
            continue
        if first is None:
            first = now
        last = now
        parts.append(text)
    end = perf_counter()

if first is None:
    raise SystemExit("No text received; no text-speed measurement.")

# Tokenize after timing; never count events as tokens.
count = lambda text: len(encoder.encode(text, disallowed_special=()))
total_tokens = count("".join(parts))
post_first_tokens = total_tokens - count(parts[0])
span = last - first

print(f"First text chunk / TTFT estimate (s): {first - start:.3f}")
print(f"Request to last text (s): {last - start:.3f}")
print(f"Stream complete (s): {end - start:.3f}")
print(f"Normalized output tokens: {total_tokens}")
if span > 0 and post_first_tokens > 0:
    print(f"Post-first output tok/s (estimate): {post_first_tokens / span:.1f}")
else:
    print("Output tok/s unavailable: insufficient text delivery intervals.")

Groq SDKでは、自動再試行を無効にできます。この例では、成功したサンプルに再試行の待ち時間が気づかないうちに含まれるのを避けるため、自動再試行を無効にしています。失敗したリクエストは、失敗として記録してください。

速度の計算では、最初のテキストチャンクをトークン数にも配信区間にも含めません。 これはArtificial Analysisの定義にある、チャンク単位の計算式に沿っています。また、最後のテキストの到着時刻を特定する際は、その後に届くメタデータを除外します。

この例はプレーンテキストに使ってください。推論ストリーム、ツール呼び出しの引数、音声を扱う場合は、イベントの種類ごとに処理を分け、最初の有用な出力が何かを定義する必要があります。比較する際は、プロンプトと設定を固定し、出力の長さを記録したうえで、本番環境のリージョンから、実際の利用を代表する負荷をかけて繰り返し測定してください。典型的な結果も遅かった結果も残し、最速のサンプルを保証値として扱わないことが大切です。

計算ツールやシミュレーターで何がわかりますか？

計画用のツールは、想定した条件で時間がどう変わるかを示せます。ただし、自分のエンドポイントで実際に生じる遅延を調べることはできません。

tokens per secondのシミュレーターの使いどころ

チャット画面で届いたテキストから順に見せるか、完成したオブジェクトを待ってから表示するかを検討する際は、シミュレーターが役立ちます。そのうえで、実際に観測したストリームを使って設計を検証してください。一定速度のシミュレーションでは、本物のレスポンスが途中で止まるか、まとまって断続的に届くか、ツールの処理を待つかはわかりません。

テキストレスポンスが完了した場合、時間の内訳は明快です。リクエスト送信から最後のテキスト受信までの時間は、最初の待ち時間と、最初から最後のテキスト受信までの時間の合計です。 このスクリプトは、公表速度から時間を推測するのではなく、両方の区間を測定します。

tokens per secondはどのくらいあれば十分ですか？

実用的な目標は、タスクのどこで待ち時間が生じるかによって決まります。作ろうとしている体験について、次の問いに答えて設定してください。

音声アプリの開発者なら： 電話の相手が話し終えてから、役に立つ返答を聞くまでにどれだけ待ちますか？ 回答文をすべて生成する前に発話を始められますか？ 音声バッファが空になりませんか？ 相手は途中で割り込めますか？ テキストの出力前に沈黙が生じているなら、デコードを高速化しても、主な問題は残るかもしれません。

チャットアプリの開発者なら： ユーザーが待っているのは、最初の役に立つ文ですか、説明全体ですか、それとも有効な構造化データですか？ 画面に途中の出力を表示できますか？ サポートへの回答と、書き出せるレポートでは、完了とみなす時点が異なります。自分のインターフェースが必要とする時点を測ってください。

エージェントの運用担当者なら： タスクのうち、モデルによる生成とツールの実行は、それぞれどの程度を占めていますか？ 応答を速くしても、ツールの引数の正しさとタスクの成功は維持できますか？ 次のステップは出力全体がそろうまで待ちますか？ 改善する区間を取り違えると、ワークフローの完了時間はほとんど変わらないことがあります。

プロバイダーの選定担当者なら： 検討中の実行環境は、自分のリージョンから、自分のプロンプトとトラフィックで使っても、必要な体験を維持できますか？ 提示された結果は、その環境の典型的な値ですか？ リクエストが失敗したときや、処理能力が逼迫したときはどうなりますか？

トレースから、ユーザーが生成処理や最初の有用な回答を待っているとわかったら、改善に着手してください。主な遅延の原因を切り分けられていないうちは、プロバイダーの移行を急ぐべきではありません。すでに期限内に完了しているバックグラウンドジョブなら、スループットやタスクの正常完了にかかる費用が判断を変えない限り、公表速度が高くなっても大きな影響はありません。

LLMの速度について、何が過大評価されていますか？

最も大きな過大評価は、出力速度が最高なら、アプリケーションに最適なエンドポイントだと考えることです。速度だけでは、回答品質、出力の妥当性、ツール利用の成功は示せません。

どれほど速いエンドポイントでも、周囲のアプリケーションの制約に突き当たります。テキスト生成が速くなっても、遅いデータベース呼び出し、不必要に長い推論経路、検証に通らないレスポンスは直りません。同じように、最初のトークンまでの時間が優秀でも、役に立つ出力が届く前にストリームが止まっている可能性があります。

速度は評価項目に残しつつ、正しく使える結果が得られる時点をゴールにしてください。

よくある質問

次の開発で実践すること

次の改修では、実際の利用を代表する音声のやり取り、チャットのプロンプト、またはエージェントのタスクを取り上げ、結果を使えるようになる条件を定義してください。その時点を、最初の出力とストリーム完了の時点とあわせて計測します。同じタスクで候補のエンドポイントを比較し、失敗も確認したうえで、ユーザーを待たせている区間を最適化してください。

役に立つAIアプリケーションを作るための実践ガイドは、ニュースレターに登録して受け取れます。