首 Token 时间（Time to first token，TTFT）是团队在为语音场景挑选推理 API 时使用的指标，也是最容易误导他们的指标。TTFT 标记的是生成开始的时刻，而文本转语音模型必须等到一个完整子句到手才能开口说话。这两个时间点之间的差距，决定了一个智能体是”感觉像在对话”，还是”总被打断”。本文对语音技术栈的每一层进行了基准测试，包括 LLM、语音转文字（STT）、文字转语音（TTS），以及语音到语音（speech-to-speech）。
为什么 TTFT 是正确的切入点，却是错误的终点线
一个语音智能体，就是一个装着语言模型的延迟预算。每一个环节都在消耗用户能听见的毫秒数。
首 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。他的粗略算术将这 800ms 四等分，每部分约 200ms：传输与媒体处理、STT 加短语端点检测（phrase endpointing）、LLM 推理、TTS。
Daily 早前关于”最快语音机器人”的工作提供了人类基线：对话中人类的典型响应时间约为 500ms，超过 800ms 的停顿就会开始让人觉得不自然。
Daily 在 2026 年 2 月的语音智能体 LLM 基准测试中将这一基线直接换算成 LLM 需求：自然对话要求语音到语音低于 1,500ms，折算到”转写 → LLM → 语音”管线中的文本模式 LLM，大约对应 700ms 的 TTFT 预算。
这个 700ms，就是用来衡量所有供应商的那把尺子。
如何读懂一份 TTFT 基准而不被误导
在看表格之前，先给出五条会改变数字含义的方法论事实：
1. 工作负载形态占主导：Artificial Analysis 于 2026 年 3 月更改了默认工作负载，该网站现在报告的是 10k 输入 token 的提示词，而不再是 1k。更长的提示词会同时抬高 TTFT 和输出速度。LiveKit 认为这更贴近语音的实际场景，因为生产环境的智能体会把策略、人设、升级规则、检索数据和工具 schema 都前置加载进提示词。
2. 服务器位置已内嵌在结果中：Artificial Analysis 从 Google Cloud us-central1-a 区的虚拟机进行测试。它明确表示，TTFT 包含网络延迟，并可能因供应商的服务器位置而对其有利或不利。
3. 推理 token 也算数：在 Artificial Analysis 的定义中，推理（reasoning）模型的 TTFT 是第一个推理 token，而不是第一个回答 token。这是两个分开的列。
4. 要从接收端测量：Daily 指出，模型供应商有时引用的是其推理栈内部的 TTFT。Daily 则从”请求发出”测到”从 API 拿到第一个可用 token”。
5. 测试结果不可复现：Daily 对此直言不讳：TTFT 在不同基准测试轮次之间波动很大，而且供应商会在不改模型名的情况下更换推理栈、有时甚至更换权重。
第一层：LLM 首 Token 时间
以下数据来自 Artificial Analysis API 供应商排行榜，取自 2026 年 8 月 30 日。”首块（first chunk）”一列即 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 加投机解码（speculative decoding）来跑 Gemma，并刻意降低每块 GPU 的打包密度，让排队延迟保持低位。据其所述，一个热请求约 100ms 就能开始返回 token。代价是成本：每 100 万输出 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 检测到语音结束开始计时：首份部分转写（partial transcript）的到达时间，和最终转写（final transcript）的到达时间。其 AA-WER Streaming 索引基于约 8 小时音频，权重为 AA-AgentTalk 50%、VoxPopuli 25%、Earnings-22 25%。
厂商公布的延迟数据：
| 模型 | 宣称指标 | 来源类型 |
| Deepgram Flux | 默认配置下端轮检测 p50 约 260ms | 厂商文档 |
| Deepgram Nova-3 | 流式延迟低于 300ms | 厂商文档 |
| AssemblyAI Universal-Streaming | 约 300ms 不可变词（immutable word）输出 | 厂商 |
| Cartesia Ink-2 | 100ms 转写延迟 | 厂商 |
| 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 事件。
最后一项能力比裸数字更重要：如果能基于”预判信号”提前开始生成，当预测正确时，你就能把 LLM 的 TTFT 整体挪出关键路径。
AssemblyAI Universal-Streamring 颠倒了常见的”先部分、后最终”模式，改为输出不可变转写。AssemblyAI 在自己的 2025 年测量中报告，其中位词输出时间为 307ms，而 Deepgram Nova-3 为 516ms。其文档还建议语音智能体使用未格式化的转写文本，因为格式化信息到达更晚，且很少改变 LLM 的行为。
这里的准确率说法存在争议，且都是厂商自发布。AssemblyAI 报告其 Universal-3.5 Pro Realtime 在公开的 Pipecat 语音智能体基准上取得 6.99% WER，领先于 Google Chirp3 的 9.04%、ElevenLabs Scribe v2 的 9.76% 和 Deepgram Flux 的 15.58%。在把它当成定论之前，请自己跑一遍。
LiveKit 还文档化了”抢先生成”（preemptive generation），即在部分转写上就启动 LLM。但 caveat 是真实存在的：如果最终转写之后不得不重新生成回复，你既烧了 token，又什么都没省下。
第三层：文字转语音的首音频时间
这一层是厂商数字与用户体验分歧最大的地方。
ElevenLabs 表示 Flash v2.5 可实现约 75ms。其自家文档做了谨慎限定：75ms 仅指模型推理时间。该公司的延迟概念页面更进一步，列出网络往返通常为 20–200ms（取决于地理距离），并指出大多数音频播放器在播放前会做缓冲，500ms 缓冲很常见。页面还明确表示 Eleven v3 不是为实时场景打造的，其 Agents 平台推荐使用 Flash v2.5、Flash v2 或 Multilingual v2。
Cartesia 对 Sonic-3.6 和 Ink-2 的说法是低于 90ms 的 TTS 和 100ms 转写延迟。MarkTechPost 对 Sonic-3.6 发布的报道曾指出，两者都是厂商自述的模型延迟，而非实测的端到端往返。Cartesia 此前曾宣称 Sonic 3.5 的端到端首音频时间为 82ms。Sonic 运行在状态空间模型（SSM）而非 Transformer 上，其随序列长度的扩展是线性的，而不是平方级的。
质量方面，以下为 Artificial Analysis Provider Voice 竞技场的盲听 Elo，取自 2026 年 8 月 30 日：
| 模型 | Elo | 每 100 万字符价格 |
| Cartesia Sonic 3.6 | 1,288 | $49.00 |
| SpeechifyAI Simba 3.2 | 1,243 | $10.00 |
| 阿里巴巴 Qwen-Audio-3.0-TTS-Plus | 1,243 | $27.60 |
| Inworld Realtime TTS-2 Flash（预览版） | 1,228 | $10.40 |
| BreezeBlue Breeze TTS 2（开放权重） | 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 之间的差距，就是大多数智能体实际运行所处的低延迟档位所付出的质量代价。
第四层：语音到语音的首音频时间
语音到语音模型将 STT、LLM、TTS 压缩为一次推理。往返次数更少，理论上应该意味着更低延迟。
LiveKit 在这一点上很谨慎，指出实时模型并不保证在所有情况下都更快，一个调校得当的级联管线完全可以极具竞争力。
数据支持了这种谨慎。以下来自 Artificial Analysis 语音到语音排行榜，TTFA 在 Big Bench Audio 上测得，取自 2026 年 8 月 30 日：
| 模型 | TTFA | 语音推理 | 任务成功率 | 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（2025 年 10 月版） | 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（2026 年 3 月） | 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% 的任务成功率。
推理努力（reasoning-effort）的代价在同一模型家族内部清晰可见：Gemini 3.1 Flash Live 从 Minimal 到 High，TTFA 从 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，并表示改进的缓存让其 Realtime 语音模型系列的 p95 延迟至少降低了 25%。尾部延迟才是让电话智能体”感觉坏掉”的元凶，所以这个说法比中位数改进更有用。
能力差距
Daily 的基准测试量化了为什么大多数生产级智能体仍在使用级联管线：在其 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。这个共识很能说明问题。
参考预算
由上文已核实的各组件数字汇总而成。这些是规划估算，不是对运行中系统的实测。
激进的级联管线，美国托管、同区域部署（colocated）：
| 环节 | 预算 |
| 传输与媒体（WebRTC） | 50–150ms |
| STT + 端轮检测（Flux 默认配置） | ~260ms |
| LLM 首块（低于 0.5s 档位） | 230–500ms |
| 250+ tok/s 下的句子完成 | ~100ms |
| TTS 首音频 + 网络 | 150–300ms |
| 合计 | 约 790ms–1.3s |
这个结果落在 800ms 目标上或略超出，与 Kwindla “800ms 很紧但可实现”的判断一致。
语音到语音，单模型：
| 环节 | 预算 |
| 传输与媒体 | 50–150ms |
| 模型 TTFA（最低推理档位） | 700ms–1.0s |
| 合计 | 约 750ms–1.15s |
两者相当，但语音到语音的可观测性更差，且按 Daily 的基准，在工具调用和指令遵循上存在可测量的能力差距。
拿这些数据该做什么
- 选对你架构受制于的那个指标。 如果下游挂着 TTS 模型，优化的是 TTFS 而不是 TTFT——也就是 TTFT 和每秒 token 数要一起看。
- 先做同区域部署，再谈优化模型。 LiveKit 将智能体与模型的同区域部署评为”影响极高”，排在模型选择之上。如果你用 SIP，中继线路在地理上也要保持邻近。
- 显式限制推理努力。 这是上文所有表格中最大的单一杠杆，而且在大多数现代端点上它就是一个配置开关。
- 为工具调用留预算。 Kwindla 指出，任何带工具调用的回合都会让 LLM 延迟大约翻倍。LiveKit 建议限制
max_tool_steps、合并外部 API 调用，并播放”思考中”提示音，免得用户只面对一片沉默。 - 先埋点，再调优。 LiveKit Agents SDK 暴露了每回合的
e2e_latency、LLM 首 token 时间和 TTS 首字节时间。Pipecat 通过enable_metrics和观察者暴露等价数据。把日志存到外部，盯着回归。 - 测 p95，别只测 p50。 OpenAI 2026 年 7 月的主要改进就是尾部延迟的降低，因为语音智能体正是在尾部崩掉的。
- 当心基础设施暗坑。 LiveKit 文档记载，在 AWS t3、t4g 这类突发性能型实例上自托管的智能体，即使 CPU 占用看起来很低，也可能遭遇严重延迟和轮次检测超时。
关键要点
- 在 10k token 工作负载上，独立实测最快首块：Baseten 托管的 gpt-oss-120b，0.23s（数据来自 Artificial Analysis）。
- 吞吐量和 TTFT 是两种不同的产品：Cerebras 达到 1,697 tok/s 但 TTFT 为 0.49s；Inception 的 Mercury 2 达到 770 tok/s 但 TTFT 为 3.07s。
- 厂商的延迟宣称（如 ElevenLabs 的 75ms、Cartesia 的低于 90ms）只是模型推理时间，不含网络。
- 推理努力是最大的单一 TTFT 杠杆：Gemini 3.1 Flash Live 从 Minimal 到 High，从 0.96s 变为 2.99s。
- 单看 TTFT 无法预测智能体的”体感”。首句时间（TTFS）才行，因为语音合成需要一个完整子句。
参考来源
- 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
原文：MarkTechPost
作者：Asif Razzaq
原文链接：https://www.marktechpost.com/2026/08/30/lowest-latency-inference-apis-for-voice-and-realtime-agents-a-time-to-first-token-ttft-first-benchmark
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/yinshipin/71534.html
