tokens/s・TTFT・レイテンシは何が違う？ローカルLLMの速度指標を整理

ローカルLLMの「速度」を一つの数字だけで表すと、用途によっては判断を誤る。

たとえばtokens/sが高くても、送信してから最初の文字が出るまで長く待つなら、対話では遅く感じることがある。

速度を見るときは、リクエストのどの区間を測った数字なのかを先に分ける。

図を拡大して見る

図: 主な比較軸を1枚に整理。細かな条件は本文と表で確認する。

まず処理の流れを分ける

概念的には次のように考えると分かりやすい。

リクエスト開始
  ↓
入力プロンプトを処理
  ↓
最初のトークンを生成
  ↓
回答を生成
  ↓
応答完了

ここから代表的な速度指標が生まれる。

指標	主に見るもの
入力処理速度	入力トークンを処理する速さ
TTFT	リクエスト開始から最初のトークンまでの時間
生成tokens/s	回答生成中に1秒あたり何トークン生成したか
全体の所要時間	リクエスト開始から必要な回答が完了するまで

ツールによって計測開始・終了の定義は違うことがあるため、数字だけでなく測定方法も確認する。

tokens/sは生成中の速さを見る

生成時のtokens/sは、回答をどのくらいの速さで出し続けられるかを見る指標として使える。

ただし、その前に長い入力処理がある場合、tokens/sだけでは利用者の待ち時間を説明できない。

たとえば二つの実行で生成速度が同じ30 tokens/sでも、最初の文字が1秒で出る場合と10秒後に出る場合では対話体験が違う。

対話ではTTFTも見る

チャット用途では、送信してから回答が表示され始めるまでの時間が使い勝手へ大きく影響する。

そこでTTFT（Time To First Token）を見る。

ただしTTFTも、入力長、モデルの読み込み状態、コンテキストのキャッシュ、実行環境、PC性能などで変わる。比較するときは入力条件をそろえる。

長文入力では入力処理時間を無視しない

長い文書や大きなRAG文脈を毎回入れる用途では、回答生成前の入力処理が待ち時間の大きな部分になることがある。

短い「こんにちは」だけで測った結果から、数万トークンの文書を入れた場合の体感速度は分からない。

自分の用途が長文中心なら、実際に使う程度の入力長でも測る。

大量処理では全体の処理量を見る

多数のリクエストを連続して処理する用途では、最初の文字が出る速さより、一定時間で何件・何トークン処理できるかが重要な場合もある。

対話 → TTFT + 生成速度 + 全体の所要時間
長文対話 → 入力処理 + TTFT + 生成速度
大量生成 → 全体の処理量 + 完了時間

用途ごとに重視する数字が違ってよい。

条件が違う数値を横並びにしない

少なくとも次が異なる結果を、そのまま「速い順」に並べない。

• モデルとリビジョン
• 量子化
• 入力長
• 出力量
• コンテキスト設定
• 実行環境とバージョン
• GPU・CPU
• オフロード設定
• 起動直後か、一度実行した後か

SNSや記事からtokens/sだけ抜き出す場合も、測定条件が分からなければ参考範囲を限定する。

まず自分の1回を区間ごとに記録する

モデル同士を比較する前に、一つのモデルで普段の入力を測る。

モデル:
入力トークン数:
出力トークン数:
入力処理時間:
TTFT:
生成tokens/s:
全体の所要時間:
PC / 実行環境:

この基準があれば、モデルや設定を変えたときに、どの区間が改善・悪化したか分かる。

「もっと速くしたい」と考えたら、まず自分が待っているのが入力処理なのか、最初のトークンなのか、回答生成なのかを特定する。その区間に合う指標を同じ条件で比べる。