トークン毎秒よりもエンドツーエンドタスクレイテンシが重要な理由
あなたのAIコードレビュー工具は毎秒150トークンを自慢しています。印象的ですね？しかし、開発者は毎回のプルリクエストに対してフィードバックを得るのに8秒待っているのです。ベンチマークの数字と実際の体験との間にギャップがあることは、エンジニアリングチームを日々フラストレーションの渦に巻き込みます。
トークン毎秒は、モデルが出力を生成し始める速さ、すなわち生のスループットを測定します。一方で、エンドツーエンドタスクレイテンシは実際に重要な指標である、リクエストから利用可能な結果までの総時間を測定します。この記事では、なぜこの違いが開発者の生産性に影響を与えるのか、LLM推論におけるレイテンシの起源、そして実際のパフォーマンスを反映する指標でAI開発ツールを評価する方法について解説します。
トークン毎秒は誤解を招くLLMベンチマークである理由
エンドツーエンドレイテンシは、プロンプトを提出してから完全で実用的な応答を得るまでの総時間を測定します。トークン毎秒（TPS）は、モデルが出力を生成し始めた後の速さだけを示します。この違いは重要です。なぜなら、印象的なTPSを持つモデルでも、最初の単語が出現するまでに数秒待たされると、痛く遅く感じるからです。
ベンダーは、スペックシートに大きな数字が見栄えが良いため、TPSを強調するのが大好きです。しかし、TPSは実際の体験に影響を与えるいくつかの要因を無視します：
キュー時間：
処理が始まる前にリクエストが待機する時間
ファーストトークンまでの時間：
何らかの応答が現れるまでの遅延
ネットワークオーバーヘッド：
システムとモデルの間の転送時間
ポストプロセッシング：
生成が完了した後のパース、バリデーション、配信
では、実際の質問はこうです：開発者が実際に使用できるものを手に入れるまでどれくらい待つのか？それがエンドツーエンドタスクレイテンシです。そして、
AI駆動のコードレビュー
セキュリティスキャン
や品質分析では、それはツールが効果をもたらすのか、それとも遅くするのかを決定する指標です。
AIアプリケーションにおけるエンドツーエンドタスクレイテンシとは
エンドツーエンドタスクレイテンシは、リクエスト提出から完全で実行可能な応答までの壁時計時間です。これにはすべてが含まれます：ネットワーク転送、キュー時間、処理、生成、配信。孤立したベンチマークとは異なり、エンドツーエンドレイテンシは開発者がAIツールを使用したときに実際に体験する内容を反映します。
ファーストトークンまでの時間
ファーストトークンまでの時間（TTFT）は、リクエストを送信してから応答の最初の部分を見るまでの遅延です。ストリーミングアプリケーションにおいて、TTFTは知覚される応答性を促進します。200ミリ秒未満のTTFTはほぼ瞬時に感じられ、1秒を超えると遅さを感じるでしょう。
TTFTはプロンプトの長さとモデルのサイズに大きく依存します。長いプロンプトは、生成を開始する前により多くの処理を必要とします。
トークン生成時間
最初のトークンが出現した後、モデルはトークンを一つずつ生成します。新しいトークンはすべての前のトークンに依存します。この逐次プロセスは、自動回帰生成と呼ばれ、主要なレイテンシのボトルネックを生み出します。
モデルは数千の入力トークンを迅速に処理するかもしれませんが、出力生成中に劇的に遅くなることがあります。これが、TPSベンチマークが誤解を招く可能性がある理由です。
タスク完了までの総時間
タスク完了までの総時間は、リクエスト提出から最終的な実用的出力までの全期間です。コードレビューやセキュリティスキャンのようなタスクでは、通常、行動を起こす前に全応答を待ちます。すべてが届くまで行動できない場合、ストリーミングはあまり役に立ちません。
この指標は開発者の生産性に直結します。
LLM推論が応答レイテンシを生む原因
レイテンシの起源を理解することで、最適化の機会を特定できます。LLM推論は異なる段階で行われ、それぞれの段階が総応答時間に寄与します。
入力トークン処理
プレフィル段階では、プロンプト全体が並行処理されます。モデルは入力をエンコードし、内部表現を構築し、生成の準備をします。長いプロンプトはここで多くの時間を要しますが、現代のアーキテクチャは一定の閾値まで文脈を効率的に処理します。
この段階がTTFTを決定します。
出力トークン生成
生成は本質的に逐次的です。モデルは一つのトークンを生成し、それを文脈に組み込み、次のトークンを生成します。この自動回帰ループは応答が完了するまで繰り返されます。このステップは各トークンが前のすべてに依存するため、並列化はできません。
長い応答では、出力生成が通常総レイテンシを支配します。
ポストプロセッシングと配信
生成が完了した後、応答はしばしばパース、バリデーション、フォーマット、ネットワーク転送を必要とします。TPSベンチマークはこれらのステップを完全に無視します。本番システムでは、ポストプロセッシングは意味のあるオーバーヘッドを追加する場合があり、特に応答が構造化された出力や他のツールとの統合を必要とする場合に顕著です。
実際に重要な主要なLLMレイテンシ指標
AI開発ツールを評価する際は、実世界のパフォーマンスを反映する指標に注目しましょう。以下が実践的なリファレンスです：
測定する内容
なぜそれが重要なのか
ファーストトークンまでの時間（TTFT）
最初のトークンが現れるまでの遅延
知覚される応答性
トークン間レイテンシ（ITL）
連続するトークン間の時間
ストリーミングの滑らかさ
総応答時間
リクエストから完了までの全体の期間
実際の生産性への影響
P95/P99レイテンシ
最悪のパフォーマンス
負荷の下での信頼性
TTFTは応答が現れ始める時期を示します。IDEの提案やチャットインターフェースのようなインタラクティブなユースケースでは、TTFTは他のどの指標よりもユーザーの認識を形作ります。迅速なTTFTは、全生成プロセスが長くかかる場合でも、ツールを応答性が高いと感じさせます。
トークン間レイテンシ
トークン間レイテンシ（ITL）は、ストリーミング中の連続するトークン間の隙間を測定します。一定で低いITLはスムーズな読書体験を生み出します。不規則なITLは、トークンが束になって到着するため、途切れ途切れで気が散る感じを与えます。
非ストリーミングのユースケースでは、総応答時間が重要です。コードレビューのフィードバック、セキュリティスキャンの結果、品質レポートは通常、完全な出力として届きます。全てを待っているのであって、トークンが流れ込むのを見ているわけではありません。
P95およびP99レイテンシパーセンタイル
中央値のレイテンシは問題のある外れ値を隠します。P95レイテンシは95%のリクエストがその閾値よりも早く完了することを意味します。P99は最も遅い1%をキャッチします。素晴らしい中央値のレイテンシを持ち、ひどいP99を持つツールは、開発者がその遅いリクエストを平均よりも頻繁に体験するため、ユーザーを定期的にフラストレーションに陥れることになります。
エンドツーエンドレイテンシが開発者の生産性に与える影響
レイテンシは技術的な指標だけではありません。それは開発者の働き方やチームがコードを迅速に出荷する速度に直接影響を与えます。
開発者のフローステートを破る
コンテキストスイッチは高コストです。開発者がAIからのフィードバックを待っていると、彼らはアイドル状態になったり、別のタスクに切り替えたりします。どちらの場合でも、彼らは勢いを失います。たとえ短時間であっても中断は回復に何分もかかります。遅いAIツールは一日を通して常に微小な中断を生み出します。
迅速なフィードバックは開発者をフローステートの中に維持します。彼らは質問をし、答えを得て、作業を続けます。
CI/CDパイプラインのボトルネック
自動化されたワークフローでは、レイテンシが累積します。コードレビュー、セキュリティスキャン、品質チェックはしばしば逐次的に実行されます。各AI駆動ステップが5秒ではなく30秒かかる場合、パイプラインは数分の遅延を加えます。これを毎日の数十件のプルリクエストにかけると、重大なボトルネックが生まれます。
ピ