产品规格说明书规定用户在说完话后的 600 毫秒内听到回复。LLM 供应商的仪表盘显示首个 Token 时间（TTFT）为 280 毫秒。你查看的每一张图表都在 SLO 范围内。但用户仍然抱怨智能体有延迟，当你亲自拨打电话时，确实能感觉到明显的停顿——每次都在 600 毫秒以上。仪表盘没有撒谎。它测量的是一个不包含 TTS 流水线、音频传输或接收端抖动缓冲（jitter buffer）的数值。流式传输的最后一个 Token 与第一帧音频之间存在的 350 毫秒差距是真实存在的，只是它没有出现在 LLM 团队的图表上。
Bug 不在模型中。Bug 出在 SLO 上。它被定义在了错误的堆栈层级。供应商的出站（egress）并不是用户的耳朵，任何忽视这一点的延迟契约都会在生产环境中显得数据健康，而产品体验却是一团糟。
首个 Token 时间是组件指标，而非产品指标
TTFT 之所以成为语音智能体默认的延迟 SLI，并不是因为它是一个正确的指标，而是因为它最容易获取。每个 LLM 供应商都会发布 TTFT 数据。每个可观测性供应商的 LLM 集成都能开箱即用地捕获它。这个数字甚至有一个公认的阈值：低于 400 毫秒感觉响应迅速，低于 250 毫秒感觉是即时的。如果你围绕供应商已经测量的指标构建 SLO，你一周内就能发布一个仪表盘。
问题在于 TTFT 测量的是第一个 Token 离开供应商 API 的时刻。它不包括返回到你的编排器（orchestrator）的网络跳转、流式解析器在将文本交给 TTS 之前所做的缓冲决策、TTS 引擎自身产生的首帧音频时间（TTFA）、从 TTS 回传到媒体服务器的 WebSocket 或 HTTP 传输、媒体流水线中的抖动缓冲，或者用户设备上的播放延迟。在快速的 TTS 供应商和干净的美国东部（US-East）部署中，TTFT 与用户实际听到声音之间的差距在 200 到 500 毫秒之间。在典型的多供应商流水线中，跨区域跳转通常会导致这一差距超过 600 毫秒。
最近的独立 TTS 基准测试让这一量级变得具体。Cartesia Sonic 3.5 在接收到文本后约 75–90 毫秒流出第一帧音频。ElevenLabs Flash v2.5 在其实时路径上也处于相同范围。2026 年 5 月的 Coval 基准测试显示，Sonic-3 的 P50 TTFA 为 188 毫秒，ElevenLabs Turbo v2.5 为 264 毫秒。这些是 TTS 供应商边界处测得的最佳情况出站数据——它们已经是快速 LLM TTFT 的两倍或三倍。当你加上传输、抖动缓冲和编解码分帧（codec framing）时，堆栈的最底层并不在 SLO 假设的位置。
每一层都在优化各自的指标，最终由用户买单
语音智能体是一场接力赛。ASR 捕获用户的语音并判断话语何时结束。端点检测器（endpointer）交给 LLM，LLM 流式输出 Token。TTS 引擎将 Token 转换为音频。媒体服务器将音频封装成 RTP 数据包。用户的设备进行缓冲、解码并播放。每一次交接都有负责人，每个负责人都有自己的仪表盘。
失败模式是统一的：每个负责人都优化自己的片段，仪表盘全部变绿，但没人对总和负责。ASR 团队将端点检测（endpoint detection）调整到 200 毫秒的静音阈值并记录为一次胜利。LLM 团队切换到更小的推理层级，将 TTFT 降至 200 毫秒并记录为一次胜利。TTS 团队迁移到流式供应商，将 TTFA 降至 100 毫秒。媒体团队采用更紧凑的抖动缓冲。每一个变化都是真实的。但 SLO 从未被表达为这些片段的总和——它只是 LLM 仪表盘上的一个组件数值——所以没人注意到实际的“嘴到耳”（mouth-to-ear）延迟虽然从 1100 毫秒降到了 950 毫秒，但实际上它本应降至 500 毫秒。这些胜利没有叠加起来，因为没有一个预算来分配它们。
这与定义在错误汇率转换步骤上的财务指标具有相同的架构缺陷。一个由运营欧元业务的团队以美元报告的收入数字，从技术上讲是一个数字；它只是一个偏离了业务契约的数字。一个由销售语音产品的团队在 LLM 出站处报告的延迟数字也是同样的错误。测量单位与用户体验的单位不匹配。
SLO 必须建立在用户感知的边界上
解决办法不是增加更多的组件仪表盘。而是在用户实际感知的层级重新定义 SLO，然后从中推导出各组件的预算。
从业者在实践中总结出了一些行之有效的模式：
-
将 SLI 定义为“嘴到耳”（mouth-to-ear）：即从用户结束说话（ASR 端点检测触发的时刻）到第一帧音频到达用户音频输出设备的耗时。NIST 的关键任务语音方法论也使用了同样的称呼，并且早在 LLM 进入堆栈之前就在测量它了。借用这个名字，它没有歧义。
-
运行测量整个流水线的合成对话探测器（synthetic conversation probes）：这是一个定时任务，拨打真实的电话（SIP、WebRTC 或任何你的生产传输协议），播放一段带有已知声学标记的预录话语，并记录智能体的回复音频。延迟就是播放音频中的标记与录制音频中第一个非静音帧之间的偏移量。这是唯一能包含每一层的测量方法，包括那些你的组件仪表盘在设计上忽略掉的层。SignalWire 最近关于供应商延迟声明的文章对此非常直截了当：任何不在音频回环处测量的数字，都排除了供应商想要排除的任何层。
-
分配累加至 SLO 的每个片段预算：如果 P95 的“嘴到耳”SLO 是 800 毫秒，预算分配可能是：ASR 端点检测 150 毫秒，LLM TTFT 350 毫秒，TTS TTFA 150 毫秒，传输 50 毫秒，以及抖动缓冲和播放 100 毫秒。现在每个组件仪表盘都会同时报告其原始数值和对预算的消耗情况。任何单一组件的退化在发布之前——而不是发布之后——都会被视为针对面向用户的 SLO 的退化。
-
基于 TTFA 与 TTS 层签约，而非 TTFB 或“首块”（first chunk）：TTS 供应商发布的延迟数字种类繁多，令人困惑。首字节时间（TTFB，响应的第一个字节，可能是头部信息）、首块时间（可能是实际音频之前的微小帧数据）以及首帧音频时间（TTFA，第一个可解码的音频帧）。对于语音智能体来说，只有最后一个才有意义。如果你的 TTS 供应商发布的是 TTFB 而你接受它作为延迟契约，那么你接受的就是一个排除了实际音频生成延迟的 SLI。请务必在定义上据理力争。
-
将抖动缓冲视为 SLO 的一部分，而非传输组件：100 毫秒的抖动缓冲意味着每一次交互都要支付 100 毫秒的延迟代价。如果音频质量足够好，可以从缓冲区削减 40 毫秒，那么这 40 毫秒会直接体现为用户感知的延迟降低。媒体团队会对此表示反对，因为他们的 SLO 是音频质量；通过在延迟 SLO 和质量 SLO 下同时为缓冲区分配预算来解决这一冲突，让他们在设计阶段进行博弈，而不是在生产环境中争论。
完成仪表化后的表现
合成探测（synthetic probe）是核心承重组件。没有它，其他的每一个度量指标都只能反映局部情况。一个合理的实现是每分钟针对每个生产区域运行一次，通过与真实用户相同的传输协议发起调用，播放一段固定提示音（一段 2 秒的语音，末尾带有 100 Hz 正弦音作为计时标记），并监听智能体的响应音频。探测器会记录口到耳延迟（mouth-to-ear latency），通过链路追踪关联（trace correlation）捕捉各组件耗时，并输出 SLI 值和各环节的资源消耗。
一个优秀的观测平台——LiveKit、Hamming 或任何现有的以追踪为核心的语音平台——会允许你对合成调用进行标记，使其在仪表盘中显示为一个可区分的群组（cohort）。真实的生产调用仍然是最终事实（ground truth）；而合成探测则是 SLO 的权威预言机（oracle）。当生产群组和合成群组的数据出现分歧时，你就能了解到关于流量模式的具体信息。当它们同步波动时，则说明合成探测正在发挥作用。
各环节的链路追踪关联至关重要，因为一旦违反了 SLO，问题就不再是“系统慢吗”——那是触发警报的原因。问题在于“我们耗尽了哪个环节的预算”。如果答案是 TTS TTFA，故障单就会发给语音引擎团队。如果是抖动缓冲区（jitter buffer），则发给媒体团队。如果是 LLM TTFT，则发给模型团队。合成探测提供了 SLO；链路追踪关联则提供了排障手册（runbook）。
架构上的认知
语音智能体是这类 Bug 的最清晰范例，而这种 Bug 在 AI 接入流水线的任何地方都会反复出现：在错误的堆栈层级定义的 SLO 虽然达标了，但产品体验却已经崩坏。同样的错误也出现在检索流水线中，其中 Embedding 模型的延迟被设为 SLO，而重排序（reranker）的长尾效应才是用户的真实感受。它出现在智能体系统中，LLM TTFT 被设为 SLO，而真正的耗时却留在工具调用（tool call）阶段。它出现在评估中，模型准确度被设为 SLO，而回归测试的漏洞却隐藏在后处理（post-processing）中。
这种模式是一致的。某个组件发布了一个指标。团队因为它易于接入而将其作为契约。当面向用户的体验发生偏移时，该指标依然维持在 SLO 范围内。最终，通过客户投诉或高管在演示通话中发现，这种差距才浮出水面，而团队这才意识到他们已经衡量了整整一个季度甚至更久的错误指标。
防御手段并非对更多组件进行仪表化，而是在用户实际跨越的边界定义 SLO，并由此推导出各组件的预算，而不是将某个组件的指标直接称为产品 SLO。具体到语音智能体，这个边界就是用户的耳朵。SLI 是首音提取时间（time-to-first-audio），通过一个会“听”的探测器来测量。LLM 仪表盘上的 TTFT 数值是一个有用的组件诊断工具，但它不是 SLO，任何基于 TTFT SLA 发布语音产品的团队，都是在签署一份衡量单位与用户实际付费体验不符的契约。