同じLLMでもプロバイダーで性能に差、OpenRouterが示す「4つの評価指標」と「テール挙動」重視の測定法
要点
- 同じLLM（大規模言語モデル）であっても、提供するプロバイダーによってインフラや量子化の設定が異なるため、実際のパフォーマンスには違いが生じる。
- プロバイダー性能を評価するための重要指標として、レイテンシ（遅延時間）、スループット（処理速度）、アップタイム（稼働率）、量子化の4つが挙げられる。
- ユーザー体験を評価する際は、平均値ではなく、遅延が発生しやすいテール部分の挙動を示すパーセンタイル指標（p90やp99）を重視すべきである。
- 評価結果は特定のプロバイダーを直接プログラムへ固定せず、自動で接続先を選択するルーティングポリシーとして組み込むことが推奨される。
リード文
LLMのルーティングサービスを提供するOpenRouter（オープンルーター）は2026年7月28日、同じAIモデルであっても経由するプロバイダーによってパフォーマンスや挙動が異なることを指摘し、その評価手法に関するガイドを公式ブログで公開した。同社は、開発者がモデルの選択だけでなく、プロバイダーのインフラや設定の違いが実システムに与える影響を客観的に評価すべきであると説明している。
同一モデルでもプロバイダーごとに異なる挙動
開発者がLLMを選定する際、まずはClaudeやLlamaといった具体的なモデル名に注目し、プロバイダー（接続先となるエンドポイント：ITサービスにアクセスするための接続点）の選択は後回しになりがちだ。しかし、同一のモデルであっても、経由するプロバイダーごとにインフラやルーティングの動作、量子化の選択、および負荷時におけるエラーの発生パターンは大きく異なってくる。
例えば、最初の応答は早いが全体の処理が遅いケースや、精度を下げたモデルの採用により難解なプロンプト（指示文）への回答精度が劣るケースがある。モデル単体の性能ではなく、稼働するサーバー環境を比較し、応答の速さや安定性、モデル精度といったトレードオフを評価することが重要だ。
プロバイダー性能を測る「4つの重要メトリクス」
OpenRouterは、プロバイダーの性能を包括的に評価するための重要メトリクス（測定指標）として、以下の4つを挙げている。
-
レイテンシ（Time to First Token：TTFT）
リクエスト送信から最初のトークン（文字や単語の構成単位）が出力されるまでの時間（TTFT）を指す。チャットなどリアルタイムなシステムで重視される。 -
スループット（出力速度）
テキスト生成開始後、1秒あたりに出力できるトークン数を示す。長文生成や、大量の文書をまとめて一括処理するバッチ処理などで重視される。 -
アップタイム（稼働率）と可用性
プロバイダーの健全性、発生するエラーの比率、障害発生時の挙動を評価する。安定した動作が常に求められる商用の本番システムにおいて最重要視される指標である。 -
量子化（重みの精度）
モデルのパラメータを保持する精度を示す。量子化（データ精度を下げることでモデルを軽量化する手法）を適用すればコストやメモリ使用量は抑えられるが、難解な指示での回答品質低下を招くリスクがある。
「平均値」の落とし穴とパーセンタイル評価の重要性
プロバイダーの応答速度を評価する際、平均値だけで判断することは適切ではないとOpenRouterは指摘している。ほとんどのリクエストが高速に処理されていても、稀に極めて大きな遅延が発生する場合、平均値はその遅延を隠してしまうからである。最悪のユーザー体験を検知するためには、パーセンタイル（データを大きさの順に並べた際の位置を示す統計値）によるテール挙動の監視が不可欠となる。
同社は5分間のローリングウィンドウ（一定時間ごとの移動窓）でp50、p75、p90、p99の値を追跡している。対話型アプリでは、遅延の影響が大きいp90やp99の値が体験の安定性を示す基準となる。
具体例として、2026年6月24日（UTC）に測定された anthropic/claude-sonnet-4.5 のデータが示された。Amazon BedrockとGoogle Vertexの比較では、中央値（p50）はそれぞれ6.3秒と7.8秒だったが、p99ではBedrockが77.4秒、Vertexが92.1秒まで拡大し、テール挙動で明確な差が確認された。
ルーティングポリシーへの適用
プロバイダーの評価を単なる一時的な性能測定で終わらせるのではなく、システムのルーティングポリシー（接続経路の選択ルール）として自動化することが推奨される。
最速のプロバイダー名をシステムに固定するのではなく、OpenRouterの機能を使い、優先度（provider.sort）、遅延の閾値、必要な量子化精度（quantizations フィールド）、障害時のフォールバック（代替切り替え）などを動的に指定することで、測定値に基づいた柔軟な選択が可能になる。