8.0
热点
AI SCORE
工具产品2026-08-31 05:24
语音 Agent 推理延迟基准测试：TTFT 全链路排名
MarkTechPost#语音Agent#延迟优化#基准测试
Editor brief · 编辑速览
对语音 Agent 全链路（LLM、STT、TTS、speech-to-speech）进行 TTFT 延迟实测，给出经过验证的厂商数据对比。
首 token 耗时（Time to First Token，TTFT）是团队选择语音推理 API 时使用的指标。但它也是一个容易误导他们的指标。TTFT 标记的是生成开始的时间点；而语音合成模型要等到完整分句才能开口说话。这两个时间点之间，存在着"感觉像在对话"和"总是被打断"的智能体之间的全部差异。本文将对语音技术栈的每一层进行基准测试，包括 LLM、语音转文本、文本转语音和语音转语音。
语音智能体是一个内部包含语言模型的延迟预算。每一个阶段都在消耗用户能感知到的毫秒数。
首 token 耗时（TTFT）是发送推理请求到接收首个 token 返回之间的间隔。IBM 的定义将其描述为系统从空闲状态转变为明显活跃状态的时刻。
对于聊天场景，TTFT 几乎就是全部答案。对于语音而言，它只是总和中的一个项。
原因在于机械层面。文本转语音模型无法合成半个单词。它需要一个完整的分句或句子才能产生音频。LiveKit 将由此产生的指标称为"首句耗时"（Time to First Sentence，TTFS），并在其 Gemma 4 部署文章中论证，TTFS 才是用户实际感知的指标。
这就给了你两个旋钮而非一个。TTFT 控制生成何时开始。每秒 token 数控制首句何时完成。某提供商在一个指标上胜出而在另一个上落后，用起来并不会感觉快。
LiveKit 的语音智能体概览将一个轮次分解为：STT 约 100–200ms、流式 LLM 约 300–500ms、TTS 约 100–200ms，以及通过 WebRTC 的网络传输约 50–150ms。他们将实际端到端目标定在 700ms 到 1.2s。
Pipecat 的联合创作者 Kwindla Hultman Kramer 建议将语音到语音的中位延迟目标设为 800ms，对于概念验证则放宽至 1,500ms 可接受。他的粗略算法将这四等分：传输和媒体处理约 200ms、STT 加上短语端点检测约 200ms、LLM 推理约 200ms、TTS 约 200ms。
Daily 早期关于最快语音机器人的研究提供了人类基准。人类在对话中的典型响应时间约为 500ms。超过 800ms 的停顿开始让人感觉不自然。
Daily 2026 年 2 月的语音智能体 LLM 基准测试直接将其转化为 LLM 需求。自然对话需要语音到语音延迟在 1,500ms 以内，这意味着在一个转录到 LLM 再到语音的链路中，文本模式 LLM 的 TTFT 预算约为 700ms。
这 700ms 数字是衡量每个提供商的标准线。
在表格之前，有五个会改变数字含义的方法论事实：
工作负载形态主导一切：Artificial Analysis 在 2026 年 3 月更改了默认工作负载。该网站现在报告的是 10k 输入 token 提示词，而非 1k。更长的提示词会同时提高 TTFT 和输出速度。LiveKit 认为这更接近语音场景的现实，因为生产环境中的智能体会预先加载策略、角色设定、升级规则、检索数据和工具模式。
服务器位置已 baked in：Artificial Analysis 在 Google Cloud 的 us-central1-a 区域的虚拟机上进行测试。他们明确表示 TTFT 包含网络延迟，可能会根据提供商的服务器位置而产生优势或劣势。
推理 token 计入：在 Artificial Analysis 的定义中，推理模型的 TTFT 是首个推理 token，而非首个答案 token。这是两个独立的列。
从接收端测量：Daily 指出，模型提供商有时会引用其推理栈内部的 TTFT。Daily 从请求发送到 API 输出的首个可用 token 测量。
结果不可复现：Daily 对此直言不讳：TTFT 在不同基准测试运行之间差异很大，提供商有时会在不更改模型名称的情况下更换推理栈和权重。
下图数据来源于 Artificial Analysis API 提供商排行榜，获取时间为 2026 年 8 月 30 日。"首个数据块"列即为 TTFT。工作负载为 10k 输入 token，单一提示词，72 小时中位数。
| 提供商 | 模型 | TTFT | 输出速度 |
|---|---|---|---|
| Baseten | gpt-oss-120b (high) | 0.23s | 266 tok/s |
| Baseten | gpt-oss-120b (low) | 0.24s | 271 tok/s |
| DeepInfra | Nemotron 3 Ultra | 0.28s | 371 tok/s |
| Cohere | North Mini Code | 0.32s | 104 tok/s |
| Cohere | Command A+ | 0.40s | 239 tok/s |
| Baseten | Inkling Small | 0.42s | 337 tok/s |
| Modular | Gemma 4 31B (NVFP4) | 0.44s | 243 tok/s |
| Nebius | GLM-5.3-Flash | 0.46s | 206 tok/s |
| Fireworks | Nemotron 3.5 Lightning | 0.46s | 501 tok/s |
| Together AI | Kimi K2.7 Code | 0.47s | 245 tok/s |
| Cerebras | gpt-oss-120b (high) | 0.49s | 1,697 tok/s |
芯片供应商优化的指标与语音智能体需要的不同。
| 提供商 | 模型 | TTFT | 输出速度 |
|---|---|---|---|
| Cerebras | gpt-oss-120b (high) | 0.49s | 1,697 tok/s |
| Celeris | Celeris-1 | 0.62s | 1,612 tok/s |
| Cerebras | Gemma 4 31B | 0.53s | 1,351 tok/s |
| Groq | gpt-oss-20b (high) | 0.82s | 957 tok/s |
| SambaNova | gpt-oss-120b (high) | 0.92s | 706 tok/s |
| Groq | gpt-oss-120b (low) | 0.69s | 473 tok/s |
| Inception | Mercury 2 | 3.07s | 770 tok/s |
Mercury 2 是最清晰的例证。它是一个基于扩散的语言模型，每秒生成 770 个 token。首个数据块在 3.07s 后到达。这是自然对话整个 LLM 预算的四倍。
Cerebras 和 Groq 是另一种情况。它们的 TTFT 相当不错，吞吐量也异常出色。对于 TTFS 而言，这种组合特别强，因为句子几乎在首个 token 落地后立即完成。
| 提供商 | 模型 | TTFT | 输出速度 |
|---|---|---|---|
| Amazon Bedrock | GPT-5.6 Luna (非推理) | 0.59s | 181 tok/s |
| Amazon Bedrock | GPT-5.6 Terra (非推理) | 0.72s | 103 tok/s |
| OpenAI | GPT-5.6 Luna (非推理) | 0.74s | 113 tok/s |
| Gemini 3.7 Flash (low)，AI Studio | 0.84s | 315 tok/s | |
| Anthropic | Claude 4.5 Haiku (非推理) | 0.84s | 82 tok/s |
| Amazon Bedrock | Nova Micro | 0.86s | 264 tok/s |
| Gemini 3.5 Flash (minimal)，AI Studio | 0.90s | 202 tok/s | |
| OpenAI | GPT-5.6 Sol (非推理) | 1.06s | 71 tok/s |
注意同一模型在不同主机上的表现。GPT-5.6 Luna 非推理版本在 Amazon Bedrock 上测得 0.59s，在 OpenAI 自家 API 上则是 0.74s。托管和路由与权重同样重要。
LiveKit 发布了自家推理产品的 TTFT 数据。Gemma 4 31B 在 LiveKit Inference 上测得 192ms，Gemini 2.5 Flash 为 911ms，GPT-5.5 为 966ms，GPT-4.1 为 1,006ms，同样的 Gemma 4 31B 通过 OpenRouter 则为 1,876ms。
LiveKit 对其机制保持透明，这使得该说法比大多数竞品更可信。它在 SGLang 后面运行 Gemma，并使用投机解码，且故意不完全打包每个 GPU 以保持队列延迟低。它表示，一个热请求约在 100ms 开始返回 token。代价是成本，为每百万输出 token 1.20 美元。
同一篇文章报告了完整对话的 TTFS：LiveKit 上的 Gemma 4 31B 为 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 得分为 75.6%，GPT-5.5 为 75.9%，GPT-4.1 为 43%，Gemini 2.5 Flash 为 39%。在 τ²-bench 上，GPT-5.5 以 93.9% 领先，Gemma 4 31B 为 76.9%。
对于语音，STT 延迟不是转录速度。它是指用户停止说话后，流水线需要多长时间才知道用户已经停止。
Artificial Analysis 在其流式 STT 排行榜上测量两个指标，均从 SileroVAD 检测到的语音结束时刻开始：到首个部分转录文本的时间，以及到最终转录文本的时间。其 AA-WER Streaming 指数基于约 8 小时的音频，权重为 AA-AgentTalk 50%、VoxPopuli 25%、Earnings-22 25%。
供应商公布的延迟数据：
| 模型 | 声称 | 来源类型 |
|---|---|---|
| Deepgram Flux | 默认设置下 p50 端轮次检测约 260ms | 供应商文档 |
| Deepgram Nova-3 | 亚 300ms 流式延迟 | 供应商文档 |
| AssemblyAI Universal-Streaming | 约 300ms 不可变词元输出 | 供应商文档 |
| Cartesia Ink | 2100ms 转录延迟 | 供应商文档 |
| Speechmatics Voice SDK | 0.451 ± 0.022s 语音结束到最终文本 | 供应商内部工具 |
Deepgram Flux 是架构上最有趣的一个。它将端轮次检测整合到识别模型中，而非在顶部额外加装 VAD。Deepgram 表示，与传统 STT 加 VAD 流水线相比，这可将智能体响应延迟削减 200–600ms。它暴露了 eot_threshold（0.5–0.9）、eager_eot_threshold（0.3–0.9），以及一个允许你提前启动 LLM 的 EagerEndOfTurn 事件。
最后这项能力比原始数字更重要。如果你能在一个 eager 信号上开始生成，当预测正确时，你就能将 LLM TTFT 完全移出关键路径。
AssemblyAI Universal-Streaming 反转了通常的部分文本然后最终文本的模式，通过发出不可变转录文本。AssemblyAI 报告其自身 2025 年测量中，词元输出的中位延迟为 307ms，Deepgram Nova-3 为 516ms。其文档还建议语音智能体使用未格式化的转录文本，因为格式化到达更晚且很少改变 LLM 行为。
这里的准确率声明存在争议，且来自厂商自行发布。AssemblyAI 报告其 Universal-3.5 Pro Realtime 在开放的 Pipecat voice-agent 基准测试中 WER 为 6.99%，领先于 Google Chirp3 的 9.04%、ElevenLabs Scribe v2 的 9.76% 和 Deepgram Flux 的 15.58%。在你将其视为定论之前，自己跑一遍测试。
LiveKit 也记录了抢占式生成（preemptive generation），即在部分转录文本上就开始运行 LLM。这里的注意事项是真实的：如果在最终转录后需要重新生成回复，你会浪费 token，什么也省不下来。
这是厂商数字与用户实际体验偏差最大的地方。
ElevenLabs 声称 Flash v2.5 提供约 75ms。其官方文档谨慎地做了限定：75ms 指的是模型推理时间。该公司的延迟概念页面进一步列出，网络往返通常为 20–200ms（取决于地理位置），并指出大多数音频播放器在播放前会缓冲，500ms 的缓冲很常见。文档还指出 Eleven v3 不是为实时场景构建的，推荐使用 Flash v2.5、Flash v2 或 Multilingual v2 用于其 Agents Platform。
Cartesia 声称 Sonic-3.6 和 Ink-2 的 TTS 低于 90ms，转录延迟为 100ms。Marktechpost 对 Sonic-3.6 发布的报道指出，两者都是厂商声明的模型延迟，而非实测的端到端往返。Cartesia 此前声称 Sonic 3.5 的端到端首音频时间为 82ms。Sonic 运行在状态空间模型而非 Transformer 上，其扩展性随序列长度线性增长而非二次增长。
在质量方面，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 之间的差距，就是大多数 AI 智能体实际运行的低延迟层级的质量代价。
语音转语音模型将 STT、LLM 和 TTS 合并为一次传递。更少的往返次数应该意味着更低的延迟。
LiveKit 在这里很谨慎，指出实时模型并不能保证在所有情况下都更快，一个调优良好的流水线可以具有很强的竞争力。
数据支持这种谨慎态度。来自 Artificial Analysis 语音转语音排行榜，在 Big Bench Audio 上测量的 TTFA，检索日期为 2026 年 8 月 30 日：
| Model | TTFA | Speech reasoning | Task success | S2S Index |
|---|---|---|---|---|
| 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 是这块看板的亮点：0.70s TTFA，97% 语音推理率和 94.7% 任务成功率。
推理努力惩罚在单一模型系列中也可见。Gemini 3.1 Flash Live 在 Minimal 和 High 之间从 0.96s 变为 2.99s。OpenAI 的 GPT-Realtime-2.1 从 0.97s 到 1.21s，换来 2.1 个百分点的任务成功率提升。
OpenAI 于 2026 年 7 月初发布了 gpt-realtime-2.1 和 gpt-realtime-2.1-mini，并声称改进的缓存将其实时语音模型的 p95 延迟降低了至少 25%。尾延迟才是让电话 AI 智能体感觉坏掉的罪魁祸首，所以这比中位数改进更有用的声明。
Daily 的基准测试量化了为什么大多数生产环境 AI 智能体仍然使用级联流水线。在其 aiwf_medium_context 测试中，GPT Realtime 得分为 86.7%，而 GPT-4.1 为 94.9%。根据 Daily 的评估，Ultravox 0.7 是第一个在长多轮对话中表现良好的语音转语音模型，它是开放权重的。
Artificial Analysis 还基准测试了四个厂商的"默认级联系统"，这对于了解平台实际发货的内容是很好的上下文：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）。
其中三个运行在 Gemini 2.5 Flash 上。这是一个很有说明性的共识。
根据上述已验证组件数据汇总。这是规划估算，而非运行系统的实测。
激进的级联流水线，美国托管，共置：
| Stage | Budget |
|---|---|
| Transport and media (WebRTC) | 50–150ms |
| STT + end-of-turn (Flux at defaults) | ~260ms |
| LLM first chunk (sub-0.5s tier) | 230–500ms |
| Sentence completion at 250+ tok/s | ~100ms |
| TTS first audio + network | 150–300ms |
| Total | ~790ms–1.3s |
这落在或略高于 800ms 目标，与 Kwindla 的框架相符：800ms 很紧但可以实现。
语音转语音，单模型：
| Stage | Budget |
|---|---|
| Transport and media | 50–150ms |
| Model TTFA (minimal reasoning tier) | 700ms–1.0s |
| Total | ~750ms–1.15s |
相当，但可观测性较差，且根据 Daily 的基准测试，在工具调用和指令遵循上有可测量的能力差距。
选择你的架构所限制的指标。如果 TTS 模型位于下游，优化 TTFS，而非 TTFT。这意味着要把 TTFT 和每秒 token 数结合起来考虑。
在优化模型之前先做共置托管。LiveKit 将 AI 智能体模型共置托管评为非常高的影响力，高于模型选择。如果你使用 SIP，也要让 trunk 在地理上保持接近。
显式限制推理努力。这是上表中最大的单一杠杆，在大多数现代端点上是一个配置标志。
为工具调用做预算。Kwindla 指出，任何涉及工具调用的回合大约会使 LLM 延迟翻倍。LiveKit 建议限制 max_tool_steps，整合外部 API 调用，并播放思考音效，这样沉默就不是用户唯一的反馈。
在调优之前先埋点。LiveKit Agents SDK 暴露了 e2e_latency、LLM time to first token 和每轮 TTS time to first byte。Pipecat 通过 enable_metrics 和 observers 暴露了等效指标。将日志存储在外部并关注回归。
测量 p95，而不仅仅是 p50。OpenAI 自己在 2026 年 7 月的主要改进是尾延迟降低，因为那才是语音 AI 智能体出问题的地方。
注意基础设施陷阱。LiveKit 记录，在 AWS 可突发实例类型（如 t3 或 t4g）上自托管 AI 智能体，即使在看似低 CPU 使用率的情况下，也可能遇到严重的延迟和语音检测超时。
Artificial Analysis: LLM API Providers Leaderboard
Artificial Analysis: Performance Benchmarking Methodology
Artificial Analysis: Speech to Speech Leaderboard
Artificial Analysis: Streaming Speech to Text Leaderboard
Artificial Analysis: Text to Speech Provider Voice Leaderboard
LiveKit: Understand and Improve Voice Agent Latency
LiveKit: Latency Optimized Inference, Gemma 4
LiveKit: Voice Agents
Daily: Benchmarking LLMs for Voice Agent Use Cases
Daily: Advice on Building Voice AI
Deepgram: Migrating from Nova-3 to Flux
Deepgram: Measuring STT Latency
AssemblyAI: Introducing Universal-Streaming
ElevenLabs: Understanding Latency
ElevenLabs: Latency Optimization
Cartesia: Sonic-3.6 and Ink-2
OpenAI: Realtime and Audio Guide
aiewf-eval benchmark source