LLMのLatencyとThroughput：API購入者がスピードを測定する方法

モデルAPIを評価する際、LLMのレイテンシとスループットのトレードオフを理解することは、ユーザーエクスペリエンスとインフラコストの両方を最適化するために不可欠です。レイテンシはモデルがクエリに応答するまでの経過時間を測定し、スループットは特定の時間枠内にシステムによって処理または生成されたトークンの量を測定します。開発者やAIプロダクト構築者にとって、一方の指標を最適化することは、多くの場合、もう一方とのトレードオフを伴います。

誤ったスピード指標を選択すると、ユーザーインターフェースの動作が鈍くなったり、API料金が不必要に高額になったりする可能性があります。本稿では、これらの指標を測定し、特定のワークロードに適したAPIを選択し、最適化戦略を実装するためのフレームワークを提供します。

重要なポイント

• Time to First Token (TTFT) は、チャットインターフェースのようなインタラクティブなアプリケーションにおいて、ユーザーが感じるスピードに直接影響を与える重要なレイテンシ指標です。
• Tokens Per Second (TPS)（ストリームあたりのトークン数）は、文書の要約や大量のデータ抽出といったバックグラウンド処理タスクにおける主要なスループット指標です。
• モデルのアーキテクチャとサイズがベースラインのパフォーマンスを決定します。DeepSeek V4 FlashやGemini 3.5 Flashのような小型モデルは、Claude Fable 5やGPT-5.5のようなフラッグシップモデルよりも高速です。
• マルチプロバイダー・ルーティングを活用することで、開発者はリアルタイムのプロバイダーパフォーマンスに基づいて、レイテンシやスループットを動的に最適化できます。

---

主要指標の定義：レイテンシ vs スループット

APIの購入やルーティングを行う際に十分な情報に基づいた意思決定を行うには、開発者は「スピード」を個別の測定可能なコンポーネントに分解する必要があります。

LLM APIリクエストのタイムライン:
[ユーザーがリクエストを送信] 
       │
       ▼ (ネットワーク転送 + プロンプト処理)
[Time to First Token (TTFT)] <--- インタラクティブなUXに不可欠
       │
       ▼ (自己回帰生成: 1秒あたりのトークン数)
[Inter-Token Latency (ITL)]  <--- 読み心地を左右する
       │
       ▼ (生成完了)
[Total Latency]              <--- ストリーミングを行わないブロッキング呼び出しに不可欠

1. Time to First Token (TTFT)

TTFTは、APIリクエストを送信してからレスポンスの最初のトークンを受け取るまでの時間です。この指標には、ネットワークの往復時間、プロンプトのシリアル化、およびモデルが入力トークンを処理するのに必要な時間（プリフィルフェーズ）が含まれます。インタラクティブなアプリケーションにとって、TTFTはユーザーがレスポンスの開始をどれだけ早く確認できるかを決定するため、最も重要な指標となります。

2. Inter-Token Latency (ITL)

ITLは、ストリーミングフェーズ中に連続するトークンを生成する間にかかる平均時間です。ITLが高すぎると、テキストが人間が読む速度よりも遅く表示され、ユーザーエクスペリエンスが損なわれます。安定した低いITLは、スムーズなテキストレンダリングを保証します。

3. Tokens Per Second (TPS)

TPSは、モデルの生成スループットを表します。これは、出力トークンの総数を（プリフィルフェーズを除いた）合計生成時間で割って算出されます。スループットを評価する際、開発者は以下を区別する必要があります：

• シングルユーザーTPS： 単一のアクティブストリームの生成速度。
• システムスループット： APIプロバイダーがすべてのアクティブユーザー全体で同時に処理できるトークンの総数。

4. Total Latency

Total Latency（合計レイテンシ）は、APIリクエストの開始から終了までの全所要時間です。構造化されたJSON抽出やバックグラウンドでの分類など、ストリーミングを行わないリクエストの場合、合計レイテンシが監視すべき主要な指標となります。

---

アーキテクチャ上のトレードオフ：なぜスピードが異なるのか

LLMのレイテンシとスループットのトレードオフは、Transformerアーキテクチャの物理的特性とハードウェアのメモリ帯域幅に起因します。プリフィルフェーズ（TTFTを決定する）では、入力プロンプト全体が一度に処理されるため、計算は高度に並列化可能です。このフェーズは通常、計算量に依存します（compute-bound）。

生成フェーズ（TPSを決定する）では、モデルはトークンを1つずつ生成します。新しいトークンが生成されるたびに、すべてのモデルウェイトをHigh Bandwidth Memory (HBM) からGPU SRAMへロードする必要があります。この自己回帰プロセスは、メモリ帯域幅に依存します（memory-bandwidth bound）。

これらの制約があるため、開発者は自身の主要なパフォーマンス要件に合わせてモデルを選択する必要があります：

• フラッグシップモデル： Claude Fable 5、Claude Opus 4.8、GPT-5.5などのモデルは、生のスピードよりも推論の深さを優先します。これらは膨大なパラメータ数を持ち、その結果、TTFTが高くTPSが低くなる傾向があります。
• 高速・低コストモデル： DeepSeek V4 Flash、Gemini 3.5 Flash、Laguna XS 2.1などのモデルは、スピードに最適化されています。これらは、より少ないパラメータ数、投機的デコード、または蒸留アーキテクチャを使用することで、非常に低いTTFTと高いTPSを実現します。

開発者は、TokenLab LLM API Leaderboard for Developersを参照して、これらのモデル階層間のリアルタイムのスピード指標を比較できます。

---

意思決定フレームワーク：レイテンシとスループットのどちらを優先すべきか

レイテンシとスループットのどちらを優先するかは、アプリケーションのユースケースに完全に依存します。

ユースケース	主要指標	副次的指標	推奨モデルクラス
インタラクティブなチャットボット	Time to First Token (TTFT)	Inter-Token Latency (ITL)	Fast Frontier (例: Gemini 3.5 Flash)
コーディングアシスタント	TTFT & シングルストリームTPS	Total Latency	Specialized Coding (例: Claude Sonnet 5, Kimi K2.7 Code)
大量データ抽出	システムスループット	タスクあたりのコスト	Low-Cost Open-Weight (例: DeepSeek V4 Flash, GLM-5.2)
自律型エージェント	Total Latency (非ストリーミング)	TTFT	High-Reasoning Open-Weight (例: DeepSeek V4 Pro)
画像/動画生成	Total Latency	画像あたりのコスト	Specialized Media APIs (例: Nano Banana 2, Seedance)

インタラクティブなアプリケーション（レイテンシ優先）

会話型UI、カスタマーサポートボット、ライブ検索アシスタントの場合、システムが応答しないと感じられるとユーザーの離脱率が高まります。開発者はTTFTの最小化を優先すべきです。生成の合計時間が数秒かかる場合でも、TTFTが300ミリ秒以下であれば、ユーザーはエンゲージメントを維持できます。

バッチ処理とパイプライン（スループット優先）

数千件のPDF請求書の処理、日次レポートの生成、バッチ評価の実行といったオフラインタスクでは、TTFTは重要ではありません。目標は、可能な限り低いコストで、1分あたりの処理トークン数を最大化することです。開発者はシステムスループットとコスト効率に注力すべきです。バッチ処理中のコスト最適化に関する詳細な分析については、TokenLab AI Model Routing Benchmark Cost Per Taskを参照してください。

---

APIパフォーマンスの測定：実践的なコード例

TTFT、ITL、TPSを正確に測定するには、ストリーミングAPIを使用し、リクエストライフサイクルの特定のポイントでタイムスタンプを記録する必要があります。以下は、OpenAI互換クライアントを使用して特定のモデルのこれらの指標を測定する実行可能なPythonスクリプトです。

import time
import os
from openai import OpenAI

# クライアントの初期化 (OpenRouterまたは互換性のあるプロバイダー向けに設定)
client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ.get("OPENROUTER_API_KEY", "your_api_key_here")
)

def measure_api_performance(model_name: str, prompt: str):
    print(f"Evaluating speed metrics for: {model_name}")
    
    start_time = time.time()
    response = client.chat.completions.create(
        model=model_name,
        messages=[{"role": "user", "content": prompt}],
        stream=True
    )
    
    ttft = None
    token_timestamps = []
    total_tokens = 0
    
    for chunk in response:
        chunk_time = time.time()
        # チャンク内にテキストコンテンツが存在するか確認
        if chunk.choices and chunk.choices[0].delta.content:
            content = chunk.choices[0].delta.content
            # トークン数の概算 (大まかな測定として1トークン ≈ 4文字)
            estimated_tokens = max(1, len(content) // 4)
            total_tokens += estimated_tokens
            
            if ttft is None:
                ttft = chunk_time - start_time
                print(f"-> Time to First Token (TTFT): {ttft:.3f} seconds")
            
            token_timestamps.append(chunk_time)
            
    end_time = time.time()
    total_duration = end_time - start_time
    generation_time = total_duration - ttft if ttft else total_duration
    
    # Inter-Token Latency (ITL) と Tokens Per Second (TPS) の計算
    if len(token_timestamps) > 1:
        intervals = [token_timestamps[i] - token_timestamps[i-1] for i in range(1, len(token_timestamps))]
        avg_itl = sum(intervals) / len(intervals)
        tps = total_tokens / generation_time if generation_time > 0 else 0
    else:
        avg_itl = 0
        tps = 0
        
    print(f"-> Total Latency: {total_duration:.3f} seconds")
    print(f"-> Average Inter-Token Latency (ITL): {avg_itl:.3f} seconds")
    print(f"-> Estimated Throughput (TPS): {tps:.2f} tokens/sec")
    print("-" * 50)

# 高速・低コストモデルを使用した使用例
if __name__ == "__main__":
    test_prompt = "Write a 200-word essay on the history of computing."
    # 現在の低コストルーティングモデルの例を使用
    measure_api_performance("google/gemini-3.5-flash", test_prompt)

---

API購入者のための最適化戦略

測定の結果、選択したAPIが遅すぎる、または高額すぎることが判明した場合、いくつかの最適化戦略でパフォーマンスを向上させることができます。

1. プロンプトの最適化とプリフィルの削減

プリフィルフェーズは入力プロンプトのサイズに応じてスケールするため、プロンプトの長さを短縮することで直接的にTTFTを減少させることができます。

• 冗長な指示を削除する。
• プロバイダーがサポートしている場合は、システムプロンプトのキャッシュを利用する。これにより、APIホストは長いシステムプロンプトのコンパイル済み状態をキャッシュでき、後続のリクエストでプリフィル計算をバイパスできます。

2. 動的プロバイダー・ルーティング

OpenRouterのプロバイダー選択ドキュメントによると、モデルのパフォーマンスは、どの基盤ホスト（プロバイダー）がリクエストを処理するかによって大きく異なります。一部のプロバイダーは低レイテンシに最適化されており、他のプロバイダーはスピードを犠牲にして低コストを提供しています。

ルーティング層を活用することで、開発者は以下が可能になります：

• 複数のプロバイダーにクエリを投げて、現在最もレイテンシが低いものを特定する。
• フォールバックパスを設定し、主要プロバイダーでレイテンシのスパイクが発生した場合に、自動的に高速な代替手段へルーティングする。
• 特定のパフォーマンスしきい値に基づいてプロバイダーをフィルタリングする。

3. モデルの階層化

より小さなモデルで処理できるタスクに、Claude Fable 5やGPT-5.5のようなフラッグシップモデルを使用しないでください。単純なクエリ（分類、フォーマットなど）をDeepSeek V4 FlashやGLM-5.2に送信し、高価なモデルは複雑な推論ステップのためだけに予約するルーティングを実装してください。

---

スピードベンチマークの限界

スピード指標を評価する際、開発者は以下の制限事項に留意する必要があります：

• ネットワークのばらつき： APIレイテンシは、アプリケーションサーバーとAPIプロバイダーのホスティングリージョン間の物理的距離に大きく依存します。ベンチマークは常に本番環境と同じリージョンにあるサーバーから実行してください。
• プロバイダーの混雑： スループットとレイテンシは、グローバルなトラフィックパターンに基づいて1日を通して変動します。単一のベンチマーク実行結果は、一貫した本番パフォーマンスを代表するものではありません。
• トークン推定の不一致： モデルによって使用するトークナイザーが異なります。TPSが高いモデルであっても、競合するモデルよりも単語を小さく多数のトークンに分割するトークナイザーを使用している場合、実際には高速ではない可能性があります。

---

よくある質問

高いスループット（TPS）は常に高速なユーザーエクスペリエンスを意味しますか？

いいえ。APIのスループットが高くてもTTFTが悪い場合、ユーザーはテキストが突然画面に表示されるまで、長く応答のない待機時間を経験することになります。インタラクティブなアプリケーションでは、高いTPSよりも低いTTFTの方が重要です。

プロンプトキャッシュはレイテンシにどのような影響を与えますか？

プロンプトキャッシュは、長いプロンプトのTTFTを大幅に短縮します。システム指示やコンテキストドキュメントの処理済みトークンをキャッシュすることで、プロバイダーは後続のリクエストで計算負荷の高いプリフィルフェーズをスキップでき、応答時間の短縮につながります。

スピードを最優先する場合、オープンウェイトモデルとクローズドソースモデルのどちらを選ぶべきですか？

ホスティングインフラストラクチャに依存します。Qwen3.7 Plus、GLM-5.2、DeepSeek V4 Proのようなオープンウェイトモデルは、専用のプライベートハードウェアにデプロイできるため、スループットを保証できます。しかし、管理されたクローズドソースAPIは、プライベートインスタンスで費用対効果高く再現するのが難しい、大規模で最適化されたインフラストラクチャを使用していることがよくあります。現在のパフォーマンスランキングはTokenLab Model Rankingsで比較できます。

---

次のステップ

アプリケーションのスピードとコスト効率を最適化するには、まず上記で説明したストリーミング指標を使用して現在の本番ワークロードを測定することから始めてください。

本番パイプライン向けの最新モデルを評価・比較する準備はできましたか？TokenLabの包括的なモデルランキングを利用して、アプリケーションにとって最適なレイテンシ、スループット、コストのバランスを見つけてください。