TTFT・TPOTとは？LLM運用のレスポンス測定方法と100万トークン単価のROI計算シミュレーション

1. プリフィル（Prefill）フェーズ：TTFT（Time to First Token）

ユーザーから送られてきたプロンプト（質問文＋過去の会話履歴＋RAGで取得した参照ドキュメント）の全体を一度にGPUへ読み込み、並列計算してKey/Valueテンソルを計算・キャッシュ（KV Cache）に格納するフェーズです。

• 測定指標: TTFT（Time to First Token / 最初の1文字が出るまでの時間）
• ボトルネック要因: 主に「計算性能（Compute Bound）」。入力プロンプトのトークン数が長くなればなるほど、最初の1文字が返るまでの時間は長くなります。
• ユーザー体験への影響: 「システムがフリーズしたのではないか？」という初期離脱の不安に直結します。目安として1.0秒以内、遅くとも2.0秒以内が許容ラインとされます。

2. デコード（Decode）フェーズ：TPOT（Time Per Output Token）

最初のトークンが出た後、自己回帰的（Autoregressive）に1トークンずつ順番に次の単語を予測・生成していくフェーズです。前の単語が決まらなければ次の単語を計算できないため、並列化できず逐次処理となります。

• 測定指標: TPOT（Time Per Output Token / 1トークンあたりの生成時間）
• ボトルネック要因: 主に「GPUメモリ帯域幅（Memory Bandwidth Bound）」。数十億〜数千億個の巨大なモデル重みをメモリから演算コアへ1トークンごとに毎回転送する必要があるためです。
• ユーザー体験への影響: 流れるような文字送りの滑らかさに直結します。人間が自然に文章を読める速度（約15〜25 tokens/s）を下回ると、「カクカクして遅い」と強いストレスを感じます。

総所要時間 (E2E Latency) = TTFT + (出力トークン数 – 1) × TPOT

import time
import statistics
from openai import OpenAI

# OpenAI互換クライアントの初期化
client = OpenAI()

def measure_llm_metrics(model_name: str, prompt: str):
    timestamps = []
    response_tokens = []
    
    start_time = time.perf_counter()
    
    stream = client.chat.completions.create(
        model=model_name,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    
    for chunk in stream:
        delta = chunk.choices[0].delta.content
        if delta:
            timestamps.append(time.perf_counter())
            response_tokens.append(delta)
            
    total_time = time.perf_counter() - start_time
    output_count = len(timestamps)
    
    if output_count == 0:
        return "レスポンスが空でした"
        
    # TTFT: 最初のリクエスト送出から第1トークン到着までの時間
    ttft_sec = timestamps[0] - start_time
    
    # TPOT & ITL (Inter-Token Latency): 2トークン目以降の間隔
    intervals = [timestamps[i] - timestamps[i - 1] for i in range(1, output_count)]
    tpot_sec = statistics.mean(intervals) if intervals else 0.0
    tps = 1.0 / tpot_sec if tpot_sec > 0 else 0.0
    
    print(f"=== モデル: {model_name} 測定結果 ===")
    print(f"生成チャンク数: {output_count} chunks")
    print(f"TTFT (初回応答時間): {ttft_sec * 1000:.1f} ms")
    print(f"TPOT (平均トークン生成時間): {tpot_sec * 1000:.2f} ms")
    print(f"生成スループット: {tps:.1f} tokens/sec")
    print(f"総所要時間 (E2E): {total_time:.2f} sec")

# 実行例
if __name__ == "__main__":
    test_prompt = "マイクロサービスアーキテクチャのメリットとデメリットを初心者向けに要約してください。"
    measure_llm_metrics("gpt-4o-mini", test_prompt)

【シミュレーション前提条件】

• 月間総クエリ数: 10,000回（社員100人が1日平均5回利用）
• 1回あたりの入力トークン: 平均1,500トークン（システム指示＋過去履歴＋社内マニュアルRAG検索結果）
• 1回あたりの出力トークン: 平均500トークン（要約や解説の回答文）
• 月間総トークン量: 入力 1,500万トークン（15M） / 出力 500万トークン（5M）
• 為替レート: 1ドル = 150円換算

① プロンプトキャッシング（Prompt Caching）の徹底

OpenAIやAnthropicが提供するプロンプトキャッシングは、同一のコンテキスト（共通システム指示や固定参照ドキュメント）をGPUメモリ上に保持する仕組みです。これにより、TTFTが最大80%短縮され、キャッシュ対象の入力料金も50〜80%ディスカウントされます。RAGシステムにおいて最も即効性のある高速化・節約手法です。

② 投機的デコード（Speculative Decoding）の採用

自前でvLLM等の推論サーバーを運用する場合、軽量な小型モデル（例：Llama-3-8B）に先行して数トークンを予測させ、巨大な親モデル（例：Llama-3-70B）がそれを1ステップで並列検証する「投機的デコード」を有効化すると、モデルの精度を1ミリも落とすことなくTPOTを1.5〜2.5倍高速化できます。

③ 出力トークン上限（max_tokens）の絞り込み

「総遅延時間は出力トークン数に比例する」という大原則を忘れてはなりません。プロンプト内で「3行以内で要約してください」「箇条書きで3点のみ」といった文字数制限を明示し、APIパラメータのmax_tokensを必要最小限に設定するだけで、無駄な長文生成による待ち時間と課金を一挙に削減できます。

④ 心理的待ち時間を削減するフロントエンドUX

技術的な限界でTTFTが1秒を超える場合でも、UI/UXの工夫で体感速度を大幅に引き上げることが可能です。リクエスト送信直後に「社内マニュアルを検索中…」といったステップ進行状況を表示したり、タイピング風のカーソルアニメーションを即座に走らせることで、ユーザーの体感待機ストレスを半減させることができます。

【全13回シリーズの全体像マップ】

• 第1弾：総合知能・学術知識編
  • 第1回：MMLU / MMLU-Pro —— 大学・専門レベルの学術知識
  • 第2回：HellaSwag —— 常識的推論と文脈継続
  • 第3回：ARC / ARC-AGI —— 未知の規則性を見抜く汎用知能
• 第2弾：数学・論理推論編
  • 第4回：GSM8K —— 小学校レベルの多段階文章題
  • 第5回：MATH —— 高校・大学オリンピック級の高度数学
  • 第6回：BIG-bench Hard（BBH） —— 思考連鎖（CoT）の限界突破
• 第3弾：実務・人間選好・指示追従編
  • 第7回：LMSYS Chatbot Arena —— ユーザー盲検対決とイロレーティング
  • 第8回：IFEval —— フォーマット・禁止ルールへの厳格追従
• 第4弾：実務タスク・特化領域指標編
  • 第9回：HumanEval / EvalPlus & Pass@k —— コーディング能力の不偏推定
  • 第10回：SWE-bench —— GitHubバグ修正と自律エージェント
  • 第11回：RAGAS —— 検索精度と社内文書QAの品質切り分け
• 第5弾：事実性・安全性・運用指標編
  • 第12回：TruthfulQA & HaluEval —— 人間の迷信トラップとハルシネーション検出
  • 第13回：システム運用・効率性指標（本記事） —— TTFT、TPOT、スループット、100万トークンROI