レイテンシーの平均値は良好なのに、対話型AIは遅く感じるのはなぜ？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Do Latency Averages Look Healthy While Interactive AI Feels Slow? - Zima Store Online

レイテンシーの平均値が健全に見えても、インタラクティブAIの応答が遅く感じられることがあります。ユーザーの記憶に残るやり取りでは、まれに発生する長い待ち時間や、連続して発生する一時停止が大きく影響するためです。

ローカルで実行する9回のプロンプトは300ミリ秒で開始できても、10回目だけがモデルの読み込みやツールの処理のために5秒待たされることがあります。平均は依然として1秒未満でも、会話は繰り返し途切れたように感じられます。インタラクションの品質を左右するのは、単一の代表値や、無関係なリクエスト種別をまとめた平均値ではなく、ユーザーが実際に記憶するやり取りにおける遅延の分布と発生順序です。

平均値では遅延分布の形が見えない

算術平均は、すべてのリクエストを1つの数値にまとめます。多数のキャッシュヒットや短いプロンプトによって、少数の非常に遅い応答が薄められることがあります。パーセンタイルを使えば、ユーザーが特定の遅延しきい値を超えて待つ頻度を把握できますが、p95でさえ最悪の1%を隠してしまうことがあります。

レイテンシーのテールが示すように、ファンアウト型システムでは、遅いコンポーネントがごく一部あるだけでも、リクエスト全体のレイテンシーを支配することがあります。インタラクティブAIでも、必要な処理段階のうち最も遅いものを待つことになります。

ワークロードの構成も重要です。ヘルスチェックやキャッシュされたステータス取得を、音声による応答、RAG検索、ツール操作と同じレイテンシー平均に含めるべきではありません。全体の平均値が低いことは数学的には正しくても、運用上は意味を持たない場合があります。

ユーザーが体験するのは完了だけでなく、節目と停止

チャットの1ターンには、キュー待ち、検索、最初のトークン、トークンの出力間隔、ツール待ち、最終完了という複数の時間があります。合計時間が短くても、冒頭に長い無音時間があると、開始が早く一定のペースでストリーミングされる少し長めの応答より悪く感じられることがあります。

最初のトークンまでの時間と完全な応答時間は、モデルの異なる挙動を表すため、レイテンシー分析では区別します。インタラクティブな1ターンを説明するには、どちらも必要です。

目に見える停止には発生順序もあります。数個のトークンを出力した後にツール処理で停止する場合と、最初のトークンの前に同じ時間待たされる場合とでは、注意の途切れ方が異なります。フェーズ全体の平均を取ると、このインタラクションの構造が消え、誤ったコンポーネントの最適化につながります。

パーセンタイルが誤解を招く場合

計測ツールが停止中に新しい処理の発行を止める場合、完了したリクエストだけをサンプリングする場合、または無関係な時間帯を集計する場合、パーセンタイルは正確ではありません。この協調的欠落により、負荷時にユーザーが実際に遭遇する遅延が、まさに過小評価されることがあります。

Gil Teneによる協調的欠落の解説は、システムが遅くなったときに送信を遅らせるのではなく、想定したリクエストスケジュールを維持する必要がある理由を示しています。そうしなければ、レイテンシー分布が実際より健全に見えてしまいます。

すべてのフェーズのトレースが高速なのにユーザーが遅いと報告する場合、テールレイテンシーの説明も当てはまりません。インターフェースの描画、ネットワークのバッファリング、フィードバックの遅延などが、計測対象のサーバー境界の外側に存在する可能性があります。計測開始が遅すぎたり終了が早すぎたりする場合、パーセンタイルのダッシュボードを増やしても役に立ちません。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

ユーザーが実際に待つ節目をトレースする

エンキュー、実行開始、検索完了、最初のトークン、各ツール呼び出し、最終トークン、クライアント描画を、1つの単調増加するトレース識別子で計測します。インタラクションの種類別、およびコールド状態とウォーム状態別に、p50、p95、p99、最大値、しきい値超過率を報告します。

AIのコールドスタートのトレースを使い、コールド状態での読み込みと定常状態の推論を切り分けます。待ち時間を除外しないよう、失敗したターンやキャンセルされたターンもデータセットに残します。

想定した固定スケジュールでリクエストを再生し、クライアントから見える節目とサーバーから見える節目を比較します。遅いパーセンタイルの原因となっているフェーズを最適化します。サーバーとクライアントのトレースが一致しない場合は、通信と描画を追跡します。コールド状態のターンだけが急増する場合は、定常状態の生成ではなく読み込みを改善します。