音声・リアルタイムエージェント向け推論 API の TTFT ベンチマーク調査

音声やリアルタイムエージェントの推論 API を選ぶ際、チームは「最初のトークンまでの時間（TTFT）」という指標を重視しがちです。しかし、この指標には落とし穴もあります。TTFT は生成が開始されるタイミングを示すに過ぎず、テキストから音声へ変換するモデルは、完全な文節が届くまで発話できません。その間の差こそが、「対話らしいエージェント」と「途中で切れてしまうエージェント」を分ける要因です。

本記事では、LLM（大規模言語モデル）、音声認識（STT）、音声合成（TTS）、そして音声から音声への直接変換（Speech-to-Speech）に至るまで、音声スタックのすべての層をベンチマークします。

なぜ TTFT が正しい入り口であり、同時に誤ったゴールラインなのか

音声エージェントとは、内部に言語モデルを搭載した「遅延時間の予算」です。ユーザーが聴覚として認識するミリ秒単位で、各工程が消費されます。

最初のトークンまでの時間（TTFT）は、推論リクエストを送信してから最初のトークンを返すまでの間隔を指します。IBM の定義では、これはシステムがアイドル状態から視覚的にアクティブな状態へ移行した瞬間と捉えられています。

チャット利用においては、TTFT はほぼ全体像を表す指標となります。しかし、音声利用においては、それは単なる「和算」の一部に過ぎません。

その理由は機械的な制約にあります。音声合成モデルは単語の半分を合成することはできません。音声を生成するには、完全な文節または文が届く必要があります。LiveKit はこの結果生じる指標を「最初の文までの時間（TTFS）」と呼び、Gemma 4 の導入に関する投稿で、「ユーザーが実際に体感するのは TTFS である」と主張しています。

つまり、調整すべきノブは一つではなく二つあるのです。TTFT が生成の開始タイミングを制御し、1 秒あたりのトークン数（Tokens per second）が最初の文が完了するまでの速度を決定します。どちらかの指標で勝っても、もう一方で負ければ、システム全体として「高速」と感じられることはありません。

遅延予算：音声の 1 トーン（ターン）が実際にコストするもの

LiveKit の音声エージェントの概要では、1 回のターンを STT（約 100–200ms）、ストリーミング処理を含む LLM（300–500ms）、TTS（100–200ms）、そして WebRTC を介したネットワーク遅延（50–150ms）に分割しています。これらを合計すると、実用的なエンドツーエンドの目標は 700ms から 1.2 秒となります。

Pipecat の共同作成者である Kwindla Hultman Kramer は、音声から音声までの遅延を中央値で 800ms に抑えるよう推奨しており、概念実証（PoC）であれば 1,500ms までなら許容できるとしています。彼の概算計算では、この時間を 4 つの要素に均等に分け、それぞれ約 200ms と見積もっています。具体的には、転送とメディア処理、STT とフレーズ終端検出、LLM の推論、そして TTS です。

最も高速な音声ボットに関する Daily の過去の研究は、人間の反応速度の基準値を示しています。会話における典型的な人間の応答時間は約 500ms です。800ms を超える間隔は不自然に感じ始めます。

Daily が 2026 年 2 月に発表した音声エージェント LLM ベンチマークでは、これを LLM の要件として直接換算しています。自然な会話を実現するには、音声から音声までの遅延が 1,500ms を下回る必要があり、これは文字列変換→LLM→音声という構成の中で、テキストモードの LLM に割り当てられる TTFT（First Token Time）の予算が約 700ms であることを意味します。

この 700ms という数字こそが、すべてのプロバイダーに対して満たすべき基準です。

TTFT ベンチマークを誤解せずに読み解く方法

表に入る前に、数値の意味を変える重要な手法論の事実を 5 つ紹介します。

「ワークロードの形状が支配的である」：Artificial Analysis は 2026 年 3 月にデフォルトのワークロードを変更しました。現在は 1,000 トークンではなく、10,000 トークンの入力プロンプトを基準にレポートしています。長いプロンプトは TTFT（最初のトークンまでの時間）と出力速度の両方を引き上げます。LiveKit はこれを音声利用における現実に近い状況だと指摘しています。なぜなら、実際の運用ではエージェントがポリシー、ペルソナ、エスカレーションルール、取得データ、ツールスキーマを先頭に配置するからです。

「サーバーの場所が前提条件となる」：Artificial Analysis のテストは Google Cloud の us-central1-a ゾーンにある仮想マシンから行われます。同サイトは明確に、「TTFT にはネットワーク遅延が含まれるため、プロバイダーがどこでサービスを提供しているかによって有利・不利が生じる」と述べています。

「推論トークンのカウント方法」：Artificial Analysis の定義では、推論モデルの TTFT は最初の回答トークンではなく、最初の推論トークンを指します。これらは別々の列として扱われます。

「受信側から測定する」：Daily は、モデルプロバイダーが時折、自社の推論スタック内部の TTFT を引用していることに注意しています。一方、Daily の測定は API からの要求送信から最初の利用可能なトークンまでの時間を計測します。

「実行結果は再現性が低い」：Daily はこれを率直に指摘しています。TTFT はベンチマークの実行間でも大きく変動し、プロバイダーはモデル名を変えずに推論スタックや重み（weights）を変更することがあるからです。

レイヤー 1：LLM の TTFT

以下の図は、2026 年 8 月 30 日に取得した Artificial Analysis の API プロバイダーリーダーボードからのものです。「最初のチャンク」列が TTFT を示します。ワークロードは入力トークン 10,000 で単一プロンプト、72 時間分の中央値です。

測定された最も低い最初のチャンクの遅延

• Provider：Model / TTFT / Output speed

Baseten gpt-oss-120b（高負荷）：0.23 秒、266 トークン/秒

Baseten gpt-oss-120b（低負荷）：0.24 秒、271 トークン/秒

DeepInfra Nemotron 3 Ultra：0.28 秒、371 トークン/秒

Cohere North Mini Code：0.32 秒、104 トークン/秒

Cohere Command A+：0.40 秒、239 トークン/秒

Baseten Inkling Small：0.42 秒、337 トークン/秒

Modular Gemma 4 31B (NVFP4)：0.44 秒、243 トークン/秒

Nebius GLM-5.3-Flash：0.46 秒、206 トークン/秒

Fireworks Nemotron 3.5 Lightning：0.46 秒、501 トークン/秒

Together AI Kimi K2.7 Code：0.47 秒、245 トークン/秒

Cerebras gpt-oss-120b（高負荷）：0.49 秒、1,697 トークン/秒

スループットの罠

シリコンベンダーは、音声エージェントが求める指標とは異なるものを最適化しています。

プロバイダー | モデル | TTFT | 出力速度

---|---|---|---

Cerebras gpt-oss-120b（高負荷） | 0.49 秒 | 1,697 トークン/秒

Celeris Celeris-10 | 0.62 秒 | 1,612 トークン/秒

Cerebras Gemma 4 31B | 0.53 秒 | 1,351 トークン/秒

Groq gpt-oss-20b（高負荷） | 0.82 秒 | 957 トークン/秒

SambaNova gpt-oss-120b（高負荷） | 0.92 秒 | 706 トークン/秒

Groq gpt-oss-120b（低負荷） | 0.69 秒 | 473 トークン/秒

Inception Mercury 2 | 3.07 秒 | 770 トークン/秒

Mercury 2 は最も明確な事例です。これは拡散ベースの言語モデルで、1 秒間に 770 トークンを生成します。しかし、最初のチャンクが到着するのは 3.07 秒後です。これは自然な会話に必要な LLM の予算全体を 4 倍も上回る遅延です。

Cerebras と Groq は異なるケースです。両社の TTFT（First Token Time）は妥当で、スループットは exceptional です。特に TTFS（Time to First Sentence）の観点では、この組み合わせが強力になります。最初のトークンが届いた直後に文が完成するためです。

フロンティアおよびプロプライエタリなエンドポイント

プロバイダー | モデル | TTFT | 出力速度

---|---|---|---

Amazon Bedrock GPT-5.6 Luna（推論なし） | 0.59 秒 | 181 トークン/秒

Amazon Bedrock GPT-5.6 Terra（推論なし） | 0.72 秒 | 103 トークン/秒

OpenAI の GPT-5.6 Luna（推論機能なし）は 0.74 秒、出力速度は 113 トークン/秒でした。

Google の Gemini 3.7 Flash（低遅延モード）、AI Studio では 0.84 秒で 315 トークン/秒を記録しています。

Anthropic の Claude 4.5 Haiku（推論機能なし）は 0.84 秒、82 トークン/秒でした。

Amazon Bedrock の Nova Micro は 0.86 秒で 264 トークン/秒です。

Google の Gemini 3.5 Flash（最小構成）、AI Studio では 0.90 秒、202 トークン/秒となりました。

OpenAI の GPT-5.6 Sol（推論機能なし）は 1.06 秒で 71 トークン/秒でした。

同じモデルでもホスト環境によって数値が変わる点に注目してください。GPT-5.6 Luna（非推論版）は、Amazon Bedrock では 0.59 秒ですが、OpenAI 自身の API では 0.74 秒となりました。モデルの重みだけでなく、ホスティングやルーティングの仕組みも遅延時間に大きく影響します。

ベンダーが測定した特異なケースとして、LiveKit が自社推論製品で公開した TTFT（First Token Time）の数値があります。Gemma 4 31B を LiveKit Inference で実行した場合、192ms という結果でした。一方、Gemini 2.5 Flash は 911ms、GPT-5.5 は 966ms、GPT-4.1 は 1,006ms、そして OpenRouter を経由した同じ Gemma 4 31B では 1,876ms となりました。

LiveKit はその仕組みを明確に開示しており、この主張は他社よりも信頼性が高いと言えます。同社は SGLang の背後で Gemma を実行し、推測的デコーディング（speculative decoding）を活用しています。また、キューイング遅延を低く抑えるため、意図的に GPU への負荷を分散させています。暖かい状態のリクエストであれば、約 100ms でトークンの返却が始まるとのことです。その代償としてコストは高く、出力トークン 100 万あたり 1.20 ドルとなっています。

同じ記事では、会話全体における TTFS（Time to First Sentence）の数値も報告されています。Gemma 4 31B（LiveKit）が 354ms、Gemini 2.5 Flash が 1,034ms、GPT-4.1 が 1,088ms、Gemini 3.0 Flash が 1,267ms、そして GPT-5.5 が 1,404ms でした。

能力値の数値も併記されています。Artificial Analysis が独立してスコアリングした IFBench では、Gemma 4 31B は GPT-5.5 の 75.9% に対し 75.6%、GPT-4.1 に対しては 43%、Gemini 2.5 Flash に対しては 39% を記録しています。また τ²-bench では、GPT-5.5 が 93.9% で首位に立ち、Gemma 4 31B は 76.9% です。

レイヤー 2：音声認識（STT）とターン検出

音声処理における STT の遅延時間は、単なる文字起こしの速度を指すわけではありません。それは、ユーザーが話し終わった直後から、システムが「会話が終了した」と判断するまでの時間を意味します。

Artificial Analysis はストリーミング STT リーダーボードにおいて、SileroVAD によって検出された音声の終了時点から計測される 2 つの指標を評価しています。1 つ目は最初の部分文字列が表示されるまでの時間（time to first partial transcript）、2 つ目は最終的な文字起こしが完了するまでの時間です。その「AA-WER Streaming」インデックスは、約 8 時間の音声データに基づいており、重み付けは AA-AgentTalk が 50%、VoxPopuli が 25%、Earnings-22 が 25% です。

ベンダーが公表している遅延時間データ：

• モデル：クレーム内容 / ソースタイプ
• Deepgram Flux：デフォルト設定でターン終了検出に約 260ms (p50) / ベンダードキュメント
• Deepgram Nova-3：ストリーミング遅延が 300ms を切る / ベンダードキュメント
• AssemblyAI Universal-Streaming：不変の単語発出に約 300ms / ベンダー
• Cartesia Ink-2：文字起こし遅延が 100ms / ベンダー
• Speechmatics Voice SDK：音声終了から最終結果まで 0.451 ± 0.022 秒 / ベンダー内部ツール

Deepgram Flux は、アーキテクチャの観点から最も興味深いエントリーの一つです。これは、VAD（音声活動検出）を後付けするのではなく、認識モデル自体に話者終了検出機能を統合しています。Deepgram によると、このアプローチにより、従来の STT と VAD を組み合わせたパイプラインと比較して、エージェントの応答遅延を 200〜600ms 削減できるとのことです。

また、eot_threshold（0.5〜0.9）、eager_eot_threshold（0.3〜0.9）を設定可能で、LLM の処理を早期に開始できる EagerEndOfTurn イベントも提供しています。

この最後の機能は、単なる数値上の優位性よりも重要です。予測が正確な場合に「積極的な信号」に基づいて生成を開始できれば、LLM の TTFT（最初のトークンまでの時間）をクリティカルパスから完全に外すことが可能になります。

AssemblyAI の Universal-Streaming は、通常のパターンである「部分的な結果→最終結果」というモデルを逆転させ、不変のトランスクリプトを逐次出力します。同社が 2025 年に実施した測定では、Deepgram Nova-3 の 516ms を上回る 307ms の中央値単語発出時間を記録しました。

また、ドキュメントでは音声エージェント向けに「整形済みトランスクリプト」ではなく「未整形のトランスクリプト」を使用することを推奨しています。その理由は、フォーマット情報が後から付与されるためで、LLM の動作にはほとんど影響しないからです。

ここで主張されている精度の数値については議論の余地があり、ベンダーが公表したデータに過ぎません。AssemblyAI は、オープンソースの Pipecat 音声エージェントベンチマークにおいて、Universal-3.5 Pro Realtime が 6.99% の WER（単語誤り率）を達成し、Google Chirp3（9.04%）、ElevenLabs Scribe v2（9.76%）、そして Deepgram Flux（15.58%）を上回っていると報告しています。

しかし、これらを確定事実として扱う前に、実際に自分で検証を行うことを強くお勧めします。

LiveKit も同様に「先読み生成」のドキュメントを提供しており、これは部分的なトランスクリプトに基づいて LLM の処理を開始する機能です。ただし、重大な注意点があります。最終的なトランスクリプトが確定した後に返信を再生成する必要が生じた場合、トークンを無駄に消費しただけで何のメリットも得られないというリスクがあるのです。

レイヤー 3：テキストから音声への時間（Time to First Audio）

ベンダーが発表する数値と、実際のユーザー体験の間には、最も大きな乖離が生じます。

ElevenLabs は Flash v2.5 が約 75ms で動作すると明言しています。ただし同社のドキュメントでは注意深く条件付けられており、「75ms はモデル推論時間のみを指す」とされています。さらに、社内のレイテンシ概念ページでは、地理的条件によって通常 20〜200ms のネットワーク往復時間を要し、多くのオーディオプレーヤーが再生前にバッファリングを行う（500ms のバッファリングが一般的）と記載されています。また、ElevenLabs v3 はリアルタイム用途には向いておらず、Agents Platform では Flash v2.5、Flash v2、または Multilingual v2 を推奨しています。

Cartesia は Sonic-3.6 と Ink-2 について、TTS でサブ 90ms、トランスクリプトで 100ms のレイテンシを謳っています。Marktechpost が Sonic-3.6 のリリースを取り上げた際にも、これらはベンダーが発表したモデル推論時間であり、エンドツーエンドの往復時間を測定した値ではないと指摘されました。Cartesia は以前、Sonic 3.5 のエンドツーエンド・ファーストオーディオ到達時間を 82ms と主張していました。Sonic はトランスフォーマーではなく状態空間モデル（State Space Models）上で動作しており、シーケンス長に対して二次関数的に而非線形にスケーリングします。

品質については、Artificial Analysis の「Provider Voice」アレーナにおける盲聴テストによる Elo 評価（2026 年 8 月 30 日時点のデータ）は以下の通りです。

• Model：Elo / Price per 1M chars
• Cartesia Sonic 3.6：1,288 / $49.00
• SpeechifyAI Simba 3.2：1,243 / $10.00
• Alibaba Qwen-Audio-3.0-TTS-Plus：1,243 / $27.60
• Inworld Realtime TTS-2 Flash (preview)：1,228 / $10.40
• BreezeBlue Breeze TTS 2 (open weights)：1,220 / $34.00
• ElevenLabs v3 Conversational：1,215 / $50.00
• Google Gemini 3.1 Flash TTS：1,210 / $18.30
• ElevenLabs Flash v2.5：1,083 / $50.00

Sonic 3.6 の 1,288 と Flash v2.5 の 1,083 の差は、多くのエージェントが実際に稼働している低遅延ティアにおける品質の代償です。

レイヤー4：音声対音声の初回音声到達時間（TTFA）

音声対音声モデルは、音声認識（STT）、大規模言語モデル（LLM）、音声合成（TTS）を1回のパスで完結させます。往復回数が減ることで、遅延が低下するはずです。

LiveKit はこの点において慎重です。リアルタイムモデルがすべてのケースで高速になるとは限らず、適切にチューブされたパイプラインであれば十分に競争力を持つ可能性があることを指摘しています。

そのデータはこの警戒心を裏付けています。Artificial Analysis の音声対音声リーダーボード（2026 年8月30日時点の Big Bench Audio ベースの TTFA 測定値）より：

• モデル：TTFA / 音声推論 / タスク成功 / S2S インデックス
• Deepslate Opal：0.44s / 85% / — / —
• Gemini 2.5 Flash Native Audio Dialog：0.63s / 69% / — / —
• Grok Voice Think Fast 2.0 High：0.70s / 97% / 94.7% / 79.0%
• Grok Voice Fast 1.0：0.78s / 93% / — / —
• Qwen3.5 Omni Flash Realtime：0.79s / 59% / 29.1% / —
• OpenAI GPT-Realtime-1.5：0.81s / 81% / 85.1% / 70.3%
• OpenAI GPT Realtime Mini (Oct '25)：0.81s / 64% / 79.6% / 56.8%
• OpenAI GPT-Realtime-2.1 Mini Minimal：0.85s / 63% / 76.7% / 52.8%
• Google Gemini 3.1 Flash Live Minimal：0.96s / 71% / 74.6% / 63.9%
• OpenAI GPT-Realtime-2.1 Minimal：0.97s / 87% / 89.4% / 70.3%
• Amazon Nova 2.0 Sonic (Mar 2026)：1.14s / 88% / 57.1% / —
• OpenAI GPT-Realtime-2 (High)：1.14s / 97% / 89.8% / 73.6%
• OpenAI GPT-Realtime-2.1 High：1.21s / 96% / 91.5% / 73.9%
• Google Gemini 3.1 Flash Live High：2.99s / 97% / 71.8% / 71.5%
• OpenAI GPT-Realtime-2.1 Mini High：4.28s / 75% / — / —

このリーダーボードにおける注目すべき点は、Grok Voice Think Fast 2.0 High です。TTFA は 0.70 秒で、音声推論の成功率が 97%、タスク成功率が 94.7% を記録しています。

推論コストのペナルティは、同じモデルファミリー内でも明確に現れます。例えば Gemini 3.1 Flash Live では、Minimal モードから High モードへ切り替えると、応答時間が 0.96 秒から 2.99 秒へと伸びます。一方、OpenAI の GPT-Realtime-2.1 は 0.97 秒から 1.21 秒に抑えられ、タスクの成功率を 2.1 ポイント引き上げることに成功しています。

OpenAI は 2026 年 7 月初旬に gpt-realtime-2.1 と gpt-realtime-2.1-mini をリリースし、キャッシュ機能の強化により Realtime 音声モデル全体の p95 レイテンシ（遅延）が少なくとも 25% 短縮されたと発表しました。電話対応エージェントにおいて「壊れている」と感じさせる原因は、平均値ではなく極端に遅い応答時間（Tail latency）です。そのため、中央値の改善よりもこの主張の方が実用的な価値を持ちます。

能力の格差

Daily のベンチマークは、なぜ多くの生産環境のエージェントが依然としてカスケード型パイプラインを採用しているのかを定量的に示しています。aiwf_medium_context テストでは、GPT Realtime は GPT-4.1 の 94.9% に対し 86.7% のスコアでした。Ultravox 0.7 は、Daily の評価によると長期的な多回対話において良好に動作する最初の音声入力・音声出力モデルであり、オープンウェイトで利用可能です。

Artificial Analysis も、各プラットフォームが実際に提供している「デフォルトのカスケードシステム」4 つをベンチマークしています。これは実際の運用環境を理解する上で有用な文脈となります。対象は以下の通りです：Deepgram Voice Agent（Nova-3 + GPT-4o Mini + Aura-2）、ElevenLabs Agents（Scribe v2 Realtime + Gemini 2.5 Flash + Eleven Flash v2）、Cartesia Line（Ink + Gemini 2.5 Flash + Sonic）、そして Inworld Realtime（Inworld STT 1 + Gemini 2.5 Flash + Inworld TTS 1.5 Mini）。

この 4 つのうち 3 つが Gemini 2.5 Flash を採用しています。これは業界の共通認識を如実に示す結果です。

リファレンス・バジェット

上記で確認した各コンポーネントの数値を組み合わせて算出されたものです。これらは稼働中のシステムの測定値ではなく、計画段階での推定値です。

アグレッシブなカスケード型パイプライン（米国ホスト、コロケーション済み）の各ステージと所要時間:

・トランスポートおよびメディア (WebRTC): 50〜150ms

・STT とターン終了判定 (Flux デフォルト設定): 約 260ms

・LLM の最初のトークン生成 (サブ 0.5 秒ティア): 230〜500ms

・文の完成 (250 トークン/秒以上): 約 100ms

・TTS の最初の音声出力およびネットワーク遅延: 150〜300ms

合計: 約 790ms〜1.3 秒

この数値は、800ms という目標にほぼ達するか、わずかに上回る水準です。Kwindla が示すように、800ms は厳しいラインですが達成可能な範囲と言えます。

音声から音声への処理を単一モデルで完結させる場合:

・トランスポートおよびメディア: 50〜150ms

・モデルの TTFA (最小限の推論ティア): 700ms〜1.0s

合計: 約 750ms〜1.15 秒

この構成も同等の速度を誇りますが、可観測性が低く、Daily のベンチマークによると、ツール呼び出しや指示の遵守能力において明確な性能差が確認されています。

今後の方針

自社のアーキテクチャがどの指標に制約されているかを特定し、優先すべきメトリクスを選びましょう。TTS モデルが後段に配置される場合、TTFT ではなく TTFS (Time to First Speech) の最適化が重要です。つまり、TTFT と秒間トークン数の両方を考慮する必要があります。

モデルの微調整よりも先にコロケーションを実行してください。LiveKit では、エージェントとモデルのコロケーションを「非常に大きな影響を持つ施策」と位置付けており、モデル選択よりも優先度が高いとしています。SIP を利用する場合は、トランクも地理的に近い場所に配置しましょう。

推論コストを明示的に制限してください。上記の表で最も大きな変動要因となるのがこの項目であり、現代のエンドポイントでは設定フラグとして制御可能です。

ツール呼び出しのためのバッファを確保してください。Kwindla によると、ツール呼び出しが発生するターンでは LLM の遅延が概ね倍増します。LiveKit では、max_tool_steps の制限や外部 API 呼び出しの統合、そしてユーザーに沈黙以外のフィードバックとして思考音（シンキングサウンド）を再生することを推奨しています。

チューニングを行う前に、まずは計測を。LiveKit Agents SDK では、1 トーンあたりのエンドツーエンド遅延（e2e_latency）、LLM のトークン初出力までの時間（TTFT）、TTS のバイト初出力までの時間を取得できます。Pipecat でも同様に enable_metrics と観測者（observers）を通じて計測が可能です。ログは外部に保存し、性能の低下がないか常時監視しましょう。

平均値（p50）だけでなく、95 パーセンタイル（p95）も測定してください。OpenAI が 2026 年 7 月に実施した主な改善は、まさにこの「遅延の尾」を削減することでした。音声エージェントが機能不全に陥るのは、平均値ではなく極端な遅延が発生する部分だからです。

インフラにおける落とし穴にも注意が必要です。LiveKit のドキュメントによると、AWS で自己ホスト型のエージェントを t3 や t4g といったバースト型インスタンスで動かすと、CPU 使用率が低く見える場合でも、深刻な遅延やターン検出のタイムアウトが発生するリスクがあります。

重要なポイント

• 独立して測定された最速初出力: 10k トークンのワークロードにおいて、Artificial Analysis のデータによると Baseten が gpt-oss-120b を 0.23 秒で提供しています。
• スループットと TTFT は別物: Cerebras は 1,697 tok/s の高速処理を実現しますが、TTFT は 0.49 秒です。一方、Inception の Mercury 2 は 770 tok/s で、TTFT は 3.07 秒かかります。
• ベンダーの遅延主張には注意: ElevenLabs が「75ms」、Cartesia が「90ms 未満」と謳う数値は、ネットワーク時間を含まないモデル推論時間のみを指しています。
• 推論コストが TTFT に与える影響: 「推論努力（reasoning effort）」の設定が TTFT を左右する最大の要因です。Gemini 3.1 Flash Live では、設定を「最小」から「高」に切り替えると、応答時間が 0.96 秒から 2.99 秒へと伸びます。
• TTFT だけでエージェントの体感は測れない: エージェントがどう感じるかを予測するには TTFT だけでは不十分です。重要なのは「最初の文までの時間」です。音声合成には完全な節（clause）が必要になるためです。

出典

• Artificial Analysis: LLM API Providers Leaderboard
• Artificial Analysis: Performance Benchmarking Methodology
• Artificial Analysis: Speech to Speech Leaderboard
• Artificial Analysis: Streaming Speech to Text Leaderboard

人工知能分析：テキスト音声変換プロバイダーのVoiceリーダーボード

LiveKit：音声エージェントの遅延を理解し改善する

LiveKit：遅延最適化推論、Gemma 4

LiveKit：音声エージェント

Daily：音声エージェントユースケース向けLLMベンチマーク

Daily：Voice AI構築に関するアドバイス

Deepgram：Nova-3からFluxへの移行

Deepgram：STT（自動音声認識）遅延の測定

AssemblyAI：ユニバーサル・ストリーミングの紹介

ElevenLabs：遅延の理解

ElevenLabs：遅延最適化

Cartesia：Sonic-3.6とInk-2

OpenAI：リアルタイムおよびオーディオガイド

aiewf-evalベンチマークソース

音声およびリアルタイムエージェント向け最低遅延推論API：Time to First Token（TTFT）を重視したベンチマーク