语音智能体延迟优化：分步指南

语音智能体的响应速度取决于用户说完话到智能体开始回复之间的总延迟。这个延迟很少由单一环节造成，而是多个独立阶段累计的，每个阶段会增加几十或几百毫秒。要减少延迟，需了解每个阶段的耗时。

语音智能体延迟优化，就是逐步找出这些耗时并一一优化。

本文是 延迟概念总览 的补充。那一页介绍了什么是延迟，这里则讲解架构和测量方法，帮助你制定可量化的延迟预算，并给出具体优化措施。

要点总结

• 首次音频输出时间代表整个流程，而不是单一模型的推理时间。
• LLM 的首次 token 输出时间和端点检测是延迟占比最大的两项。
• 各阶段并行处理（而非串行）能回收大部分延迟预算。
• 流式处理、编解码器选择和播放器缓冲区调优都能节省可观的毫秒数。
• 建议按区域测量自身部署的延迟，并报告 P50 和 P95。

定义语音智能体延迟预算

延迟预算是针对流程各阶段设定的首次音频输出总目标时间，每个阶段分配一定额度，总和需低于目标。定义预算是第一步，也是最容易出错的地方，因为工程师可能会混淆看似相近但实际不同的两个数字。

第一个是模型推理延迟：即模型生成输出所需时间。以我们的 Flash 模型 为例，典型短文本输入约为 75 毫秒（不含网络和应用开销）。这是内部数据，适合模型间对比，但不是用户实际体验到的延迟。

从用户角度看，关注的是首次音频输出时间（TTFA）：即用户说完话到听到智能体回复的第一段音频的时间。TTFA 总是大于任何单一模型的推理延迟，因为它包含了整个流程的累计耗时。

一个级联语音智能体通常包含五个阶段：

• 采集（麦克风） -> 语音转文本（STT） -> LLM -> 文本转语音（TTS） -> 播放

音频先由麦克风采集，再转为文本，送入语言模型，模型输出的文本再合成为语音，最后缓冲并播放。每个阶段都会增加延迟，有些阶段的主要耗时并不如你预期。

以下是一个英文智能体的实际案例，服务器距离用户较近。数据仅供参考，并非保证值。

通常，LLM 的首次 token 输出时间和流程起始的端点检测延迟是延迟占比最大的两项。

表格有助于直观展示流程，但它暗示各阶段严格串行，其实并非如此。许多关键的延迟优化来自阶段间的并行处理，这也是下方预算能被回收的原因。

语音转文本：转写与端点检测延迟优化

转写是流程的第二阶段，真正的耗时不在转写本身，而在于判断用户何时说完。本节将介绍这两方面，帮助你优化语音智能体延迟。

转写发生在进入 LLM 之前。Scribe v2 实时版（scribe_v2_realtime）大约 150 毫秒即可返回部分转写结果，并以音频块流式传输，因此用户说话时转写内容已在生成。支持 8kHz 到 48kHz 的 PCM 及 mu-law 编码，这对下文编解码器选择有影响。150 毫秒的部分转写延迟很低。

更大的延迟来自端点检测：即系统判断用户确实说完的时刻。

语音活动检测（VAD）通过静音分割语音，这一过程会累计时间。如果你设置 700 毫秒静音才判定说话结束，每轮对话就会额外增加 700 毫秒延迟，且这一延迟在转写准确率测试中看不到，但在真实对话中非常明显。它通常是整个流程中最可控的延迟，也是优化的好起点。

端点检测是在响应速度和不中断用户之间的权衡。静音阈值短，智能体回复快，但可能在用户自然停顿时打断对方；阈值长则更安全但响应慢。实际中，优化语音转文本延迟的三项措施是：

1. 微调静音阈值：将静音阈值调到不截断用户自然停顿的最小值，并在实际环境中测量中断率，而不是凭猜测。
2. 加入物理控制事件： 当应用能通过其他信号（如按键松开、UI 事件）判断说话结束时，手动提交转写，而不是等 VAD 定时器。
3. 与 LLM 并行处理：提前将稳定的部分转写结果送入 LLM，若最终转写有变化再修正。这种“推测执行”方式能将端点检测延迟隐藏在 LLM 提示词处理过程中。

更多信息可参考 语音转文本功能 页面和 实时语音转文本 产品页面。

LLM 延迟分析

语言模型通常是 TTFA 最大的单项来源，因此阶段重叠在这里的优化效果最明显。关键在于，智能体无需等完整答案生成后再开始说话。

最有效的做法是将 LLM 输出的 token 流式传递给 TTS，按句子或分句分块。逻辑是先缓冲到句子边界，然后合成该句，同时生成下一句：

const SENTENCE_END = /(?<=[.!?])\s+/;

async function* speakLlmStream(tokens: AsyncIterable<string>) {
  let buffer = "";
  for await (const token of tokens) {
    buffer += token;
    const parts = buffer.split(SENTENCE_END);
    buffer = parts.pop() ?? ""; // keep the incomplete fragment
    for (const sentence of parts) {
      if (sentence.trim()) yield* synthesize(sentence.trim());
    }
  }
  if (buffer.trim()) yield* synthesize(buffer.trim());
}

async function* synthesize(text: string) {
  const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
    text,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  yield* stream;
}

长对话建议使用 TTS WebSocket，这样可以持续接收文本，无需每句都重新建立连接。只有模型实际生成音频时才计入并发限制，空闲 WebSocket 几乎不占用资源。

文本转语音：流式处理与音色选择

文本转语音阶段的延迟最容易精确控制，主要有两个调节点：音频流式输出方式和音色选择。

Flash v2.5（eleven_flash_v2_5）是智能体推荐模型，短文本推理约 75 毫秒，支持 32 种语言，每次请求最多 40,000 字符。

75 毫秒仅为推理时间。上文 TTS TTFA 预算更高，是因为还包含网络往返和服务器调度。

这里最大影响因素是流式处理。如果一次性请求完整音频，用户需等全部合成后才能听到；流式则能让用户在第一段生成时就开始听，后续内容边生成边播放。流式不会让模型更快，但能让用户更早听到结果。

详细流式处理方法见 流式处理操作指南，WebSocket 相关内容见 实时 WebSocket 指南，适用于 LLM token 流式输入。

客户端初始化一次，后续每次调用复用：

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient({ apiKey: process.env.ELEVENLABS_API_KEY });

然后建立流并实时转发：

const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
  text: "Your call is connected. How can I help today?",
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
});

for await (const chunk of stream) {
  // forward each chunk to your audio sink as it arrives
}

另一个调节点是音色选择，也会影响延迟。默认音色、合成音色和即时语音克隆（IVC）比专业语音克隆（PVC）合成更快，因为 PVC 模型更复杂，每次生成开销更大。对延迟要求高的智能体，推荐 Flash 搭配 IVC 或默认音色，延迟最低。

流式分块大小选择

TTS 接收 token 并返回音频后，需决定分块大小及播放器缓冲量。

分块越小，播放器越早收到，首次字节延迟更低，但消息数和每块开销略增。分块大则传输更高效，但用户需等更久才能听到第一段。对交互型智能体，建议开头用小块，因为用户最关心第一段，后续分块大小影响较小。

播放器也是剩余延迟的重要来源。大多数播放器不会在收到第一个字节就播放，而是先缓冲一段音频以防止卡顿。常见默认缓冲为 500 毫秒，直接增加感知延迟。减少缓冲可降低 TTFA，但卡顿风险略增，具体取决于服务器与客户端间的网络抖动：

• 连接稳定时（如服务器端播放或本地客户端），50 到 150 毫秒缓冲通常足够，并能显著降低 TTFA。
• 移动端或跨区域连接抖动大时，较大缓冲可避免比延迟更糟的音频断裂。

具体配置需根据实际场景和优先级选择。

编解码器选择

音频用途决定所需编解码器。我们支持 mp3_44100_128、mp3_22050_32、pcm_16000、pcm_24000 和 ulaw_8000 等格式。选择与传输链路原生格式一致可省去转码环节，有助于延迟优化。

电话场景（如 Twilio 等）建议用 ulaw_8000。电话网络端到端为 8kHz mu-law，直接请求该格式可避免转码，符合运营商要求。合成更高保真度音频无意义，因电话网络会直接降采样，只会增加延迟且无听感提升。

WebRTC 和浏览器播放建议用 PCM（pcm_24000 或 pcm_16000）或 MP3。PCM 无压缩，客户端无需解码，可减少每块延迟，适合直接对接 Web Audio。MP3 传输更小，适合带宽受限场景，但需客户端轻量解码。

地理位置与网络距离

上述所有优化都假设数据传输距离较短。地理位置决定延迟下限，因此在调优前值得关注。

我们在北美、欧洲和东南亚设有集群，自动将请求路由到最近节点。公网网络往返通常为 20 到 200 毫秒，取决于地理距离，除非更改基础设施部署，否则无法进一步缩短。

在旧金山等北美集群附近，智能体响应几乎即时；而南亚用户每轮对话需跨洋两次，体验会明显变慢。

解决办法是将应用服务器部署在用户所在区域，而不仅仅靠近我们。如果用户在欧洲，建议后端也部署在欧洲，这样用户到服务器的链路最短，我们再负责服务器到模型的路由。

自测语音智能体延迟

上文延迟预算表中的数据仅供规划参考。实际部署应用时，建议用类似下方脚本自测。

下方工具可单独测量 TTS 阶段的 TTFA，即从请求到收到首段音频的时间，多次试验后统计分位数。请在服务器所在区域运行，而非开发机。假设已用前文的 elevenlabs 客户端：

const VOICE_ID = "JBFqnCBsd6RMkjVDRZzb";
const TEXT = "Thanks for waiting. I have pulled up your account and I can help with that now.";
const TRIALS = 50;

async function measureTtfa(): Promise<number | null> {
  const start = performance.now();
  const stream = await elevenlabs.textToSpeech.stream(VOICE_ID, {
    text: TEXT,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  for await (const _chunk of stream) {
    return performance.now() - start; // first chunk -> stop the clock
  }
  return null;
}

function percentile(values: number[], p: number): number {
  const v = [...values].sort((a, b) => a - b);
  const k = (v.length - 1) * (p / 100);
  const lo = Math.floor(k);
  const hi = Math.min(lo + 1, v.length - 1);
  return v[lo] + (v[hi] - v[lo]) * (k - lo);
}

const samples: number[] = [];
for (let i = 0; i < TRIALS; i++) {
  const ttfa = await measureTtfa();
  if (ttfa !== null) samples.push(ttfa);
  await new Promise((r) => setTimeout(r, 300)); // space requests, don't measure your own queueing
}

console.log(`trials: ${samples.length}`);
console.log(`P50:    ${percentile(samples, 50).toFixed(0)} ms`);
console.log(`P95:    ${percentile(samples, 95).toFixed(0)} ms`);

注意事项：

• 报告 P50 和 P95：重点关注这两个分位数，而非均值。均值会掩盖长尾，而长尾才让智能体体验不稳定。P95 代表每 20 轮中最慢的一轮。
• 按地区测试： 在每个服务区域分别运行脚本，单独记录结果。
• 错开请求以保证准确性：分散请求（如用 setTimeout）。若同时发起，测到的是自身排队延迟而非服务端延迟。超过并发限制时，请求会按优先级排队，通常增加约 50 毫秒，超出容量则返回 HTTP 429。
• 测量全流程延迟：将同样的计时方法应用到其他阶段。用 performance.now() 包裹 STT 完成、LLM 首 token、播放器启动等环节，就能用自己的数据填满预算表，找出最需优化的阶段。

按以上建议操作，即可自行测量语音智能体延迟，并明确优化优先级。

哪些措施最能降低语音智能体延迟？

如果想快速优化，以下是最有效的调整项。

按影响力排序，可用以下方法降低智能体延迟：

• 在 STT 部分转写稳定后立即启动 LLM，隐藏端点检测延迟。
• 将 LLM token 按句子边界流式传递给 TTS，实现第一句合成与第二句生成并行。
• TTS 音频流式传输到播放器，并将播放器缓冲区调到网络抖动可承受的最小值。
• TTS 阶段用 Flash 搭配默认音色或 IVC，延迟最低，并根据传输方式选择编解码器（电话用 ulaw_8000，浏览器/WebRTC 用 PCM 或 MP3）。
• 服务器与用户同区域部署，并按区域测量，因为网络链路实际存在且不均等。

更多详细技术可参考 延迟优化开发者操作指南。完整可运行示例见 API 快速入门和流式处理操作指南。

想更快体验优化好的智能体流程？ElevenAgents 已实现上述流程，并内置重叠优化。

用 ElevenAgents 构建低延迟语音智能体

语音智能体延迟优化需测量每个阶段，并将慢的阶段与其他工作并行。你可以手动多次迭代搭建和调优，也可以直接用已优化好的流程快速开始。

ElevenAgents 实现了完整流程，从流式 STT 到 token 级 LLM 交互再到 Flash TTS，全部内置重叠优化。无需从零开始，只需根据实际需求微调阈值即可。

使用 ElevenAgents 立即创建智能体 或 联系销售 获取更多信息。

语音智能体延迟优化常见问题