LLMのテールレイテンシに対するシンプルな修正策

LLMの応答がリアルタイムのユースケースには遅すぎる場合、より高速なサービスティアのためにコストを倍にする誘惑に駆られるかもしれません。AnthropicのPriorityティア、OpenAIの優先処理、Geminiの優先推論など、LLMプロバイダーが何と呼んでいようともです。よりシンプルな解決策があります。それは、すべてのリクエストを2回送信し、より速い応答を採用することです。 なぜテールレイテンシが音声エージェントにとって重要なのか HOAiの音声エージェントは電話応対をしています。会話の各ターンでLLMリクエストが発生します。ほとんどの応答は1.5秒以内に返ってきますが、時折10秒から20秒かかることがあります。電話では、これは10秒間の気まずい沈黙を意味し、十分な沈黙の後、発信者はエージェントを保留にしてしまいます。これは思ったよりも頻繁に起こります。通常の電話では20から30ターンあります。LLMリクエストの1%が壊滅的に遅い場合、25ターンの通話で長い沈黙に遭遇する確率は約22%になります。 優先ティア vs. 各リクエストを2回送信する 私たちは2つの選択肢がありました。OpenAIの優先ティアにアップグレードし、より高速で一貫性のある応答のためにトークンあたりのコストを2倍にするか。標準ティアにとどまり、各リクエストを2回送信して、より速い応答を採用するかです。私たちは両方のセットアップに対して50件の実際のプロダクションリクエストをリプレイし、2つのメトリックを追跡しました。最初のトークンまでの時間（エージェントが話し始める時間）と、応答完了までの時間（ツール呼び出しを実行できる時間）です。 最初のトークンまでの時間: | メトリック | Priority tier | Standard tier, sent twice | |---|---|---| | median | 0.61s | 0.58s | | p95 | 1.04s | 0.68s | | p99 | 4.2s | 1.2s | 応答完了までの時間: | メトリック | Priority tier | Standard tier, sent twice | |---|---|---| | median | 1.35s | 1.35s | | p95 | 3.4s | 2.0s | | p99 | 9.8s | 3.5s | | worst | 9.8s | 3.5s | リクエストを2回送信する方が、優先ティアを明らかに上回りました。応答完了までの最悪時間は9.8秒から3.5秒に減少しました。最初のトークンまでの最悪時間も4.2秒から1.2秒に減少しました。中央値でさえ優先ティアと正確に一致しましたが、個々のリクエストあたりの標準ティアは遅いにもかかわらずです。これは、遅い応答がまれで独立している場合に機能します。リクエストを2回送信すると、同じターンで両方のコピーが遅くなる可能性は低くなります。これにより、発信者が経験していた10秒間の沈黙が大幅に減少しました。 結論 リアルタイムのインタラクティブなLLM製品を構築している場合、より高速なサービスティアに料金を支払う前に、リクエストを2回送信することと比較ベンチマークを行ってください。同じコストでより良いレイテンシが得られるかもしれません。