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

语音智能体的响应速度取决于用户说完话到智能体开始回复之间的总延迟。这种延迟很少由某一个缓慢组件造成，而是累积于多个独立阶段，每个阶段增加数十到数百 ms。要降低延迟，需要了解每个阶段耗时多少。

语音智能体延迟优化，就是找出这些时间花在何处，并逐阶段将其缩短。

本文是延迟概念概述的配套文章。该页面说明延迟是什么，本文则介绍架构和测量方法，帮助你制定可衡量的延迟预算，并采取具体行动。

摘要

• 首段音频时间涵盖整个管道，而非单个模型的推理时间。
• LLM 的首个 token 时间和端点检测是两项最大的延迟开销。
• 让各阶段重叠运行而非串行运行，可收回大部分延迟预算。
• 流式传输、编解码器选择和播放器缓冲区调优，都能减少可衡量的毫秒级延迟。
• 应针对自己的部署按区域测量，并报告 P50 和 P95。

定义语音智能体延迟预算

延迟预算是为整个管道设定的首段音频总时间目标，并为每个阶段分配额度，合计必须低于目标。定义预算是第一步，也是延迟优化最容易出错的环节，因为工程师可能会混淆两个看似相近、含义却不同的数字。

第一项是模型推理延迟：模型生成输出所花的时间。对于我们的Flash 模型，典型短输入的推理时间约为 75 ms，不含网络和应用开销。这是内部指标，适合用于比较模型，但并非用户实际感受到的数值。

从用户视角，应关注首段音频时间（TTFA）：从用户停止说话到听见智能体回复的第一个音频采样之间的时间。TTFA 始终高于任何单个模型的推理延迟，因为它汇总了整个管道。

级联式语音智能体由五个阶段组成：

• 采集（麦克风）-> STT -> LLM -> TTS -> 播放

音频从麦克风采集后被转录为文本，发送给语言模型，再将模型文本合成为语音，最后缓冲并播放。每个阶段都会增加延迟，而且在若干阶段中，最大开销并非你预期的那项。

以下以服务器距离用户较近的英语智能体为例。这些数字仅为示例范围，不作保证。

通常，最大的两项延迟开销是 LLM 的首个 token 时间，以及管道开头的端点检测延迟。 

该表有助于直观了解管道，但会让人以为各阶段严格串行运行，实际上并非如此。许多最重要的语音智能体延迟优化都来自阶段重叠，而下文大部分预算正是通过这种重叠收回的。

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

转录是管道的第二阶段，其真正的成本不在转录本身，而在于判断用户何时停止说话。本节涵盖这两个方面，帮助你优化语音智能体延迟。

转录在送达 LLM 前完成。Scribe v2 Realtime（scribe_v2_realtime）约在 150 ms 内返回部分转录结果，并按音频块流式处理，因此用户仍在说话时转录文本就已生成。它支持 8 kHz 至 48 kHz 的 PCM 和 mu-law 编码，这对下文的编解码器部分很重要。150 ms 的部分结果开销很低。

更大的延迟成本来自端点检测：系统判定用户确实结束当前轮次的时刻。

语音活动检测（VAD）依据静音划分语音，时间就在这里累积。例如，在宣布轮次结束前等待 700 ms 静音，就会在每个轮次中额外增加 700 ms，且不包括转录时间。这种延迟在转录准确率基准中不可见，却在真实对话中十分明显。它常常是整个管道中最大且可控的延迟，因此很适合作为起点。

端点检测需要在响应速度与打断用户之间权衡。较短的静音阈值让智能体快速回复，但可能在用户自然停顿时中途打断。较长阈值更稳妥，却反应迟缓。实践中，优化文本转语音延迟的三个改动是：

1. 微调静音阈值：将静音阈值调至既不会截断用户自然停顿的最小值，再在生产环境中测量打断率，而非凭猜测判断。
2. 引入实体控制事件：当应用可从其他信号（如松开按住说话按钮、UI 事件）得知轮次结束时，使用手动提交控制，而不是等待 VAD 计时器。
3. 与 LLM 处理重叠：尽早将部分结果下游传递。将稳定的部分结果送入 LLM，若最终转录不同再修正。这是一种推测执行，可将端点检测延迟隐藏在 LLM 提示词处理期间。

如需了解更多，可参阅文本转语音功能页面和实时文本转语音产品页面，其中详细介绍了 Scribe v2 Realtime。

LLM 的延迟贡献

语言模型通常是 TTFA 最大的单项贡献者，因此阶段重叠在语音智能体延迟优化中也最有效。关键在于，智能体开始说话前并不需要完整答案。

最能收回延迟预算的模式是从 LLM 流式输出 token，并在到达时按句子或分句边界分块送入 TTS。其逻辑是先缓冲 token 至句子边界，再在生成下一句的同时合成当前句：

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 ms，支持 32 种语言，每次请求最多接受 40,000 个字符。

75 ms 仅指推理时间。上方预算中的 TTS TTFA 更高，因为除推理外还包括网络往返和服务器调度。

这里最大的杠杆是流式传输。如果请求完整音频并等待，用户必须等整段音频合成后才能听到内容。采用流式传输时，第一个块生成后用户就能听到，其余内容会在用户收听时陆续到达。流式传输不会让模型更快，只是让模型仍在生成时便开始向用户输出。

“流式传输操作指南”介绍了 HTTP 流式传输，“实时 WebSocket 指南”介绍了从 LLM 接收 token 时适用的 WebSocket 方案。

初始化一次客户端，并在以下每次调用中复用：

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 或默认音色是延迟最低的选择。

流式分块大小选择

当 token 流入 TTS、音频流回时，下一个决定是分块大小以及播放器开始前要缓冲多少。

较小的块能更快到达播放器，降低首字节延迟，但会增加消息数量和少量每块开销。较大的块传输效率更高，却会让用户等待更久才能收到第一个块。对于交互式智能体，发言前段应倾向使用较小分块，因为用户正在等待第一个块；后续块在音频已播放时到达，其大小影响较小。

播放器占据了剩余延迟中的很大一部分。大多数音频播放器不会在收到第一个字节时立即播放，而会缓冲少量内容，避免流短暂变慢时出现卡顿。500 ms 的默认缓冲区很常见，并会直接增加感知延迟。降低缓冲区会以略微增加卡顿风险换取更低的 TTFA，合适的数值取决于服务器与客户端之间的网络抖动：

• 在稳定连接上（服务器端播放或同地客户端），50 至 150 ms 的缓冲区通常足够安全，并能显著降低 TTFA。
• 在抖动较大的移动网络或跨区域连接上，较大的缓冲区可避免比延迟本身更糟糕的可听见断续。

具体配置取决于实际用例和优先事项。

编解码器选择

音频的目标用途应决定请求的编解码器。我们返回 mp3_44100_128、mp3_22050_32、pcm_16000、pcm_24000 和 ulaw_8000 等格式。匹配传输层的原生格式可省去转码步骤，有助于优化语音智能体延迟。

对于 Twilio 等电话服务提供商，请使用 ulaw_8000。电话网络端到端采用 8 kHz mu-law，因此直接请求该格式可避免管道中的转码步骤，并符合运营商预期。合成电话网络会立即降采样的高保真音频没有好处，只会增加延迟，且不会保留更多可听见的细节。

对于 WebRTC 和浏览器播放，请使用 PCM（pcm_24000 或 pcm_16000）或 MP3 格式。PCM 未压缩，因此客户端无需解码，可减少少量每块延迟，也便于直接送入 Web Audio 管道。MP3 在线路上传输更紧凑，有利于受限连接，但会增加轻量级的客户端解码开销。

地理位置与网络距离

上述每项优化都假设字节传输距离较短。地理位置决定了延迟预算的下限，因此值得在调优其他内容前先检查。

我们通过北美、欧洲和东南亚的集群提供服务，并自动将每个请求路由到最近集群。公共互联网的网络往返通常为 20 至 200 ms，取决于地理距离；除非改变基础设施的运行位置，否则无法消除。

位于旧金山、距北美集群仅短距离的智能体可能感觉即时响应；但对于每个轮次的流量都要两次跨洋的南亚用户，它可能显得迟缓。

解决方法是让应用服务器与用户同地部署，而不只是靠近我们。如果用户在欧洲，就在欧洲运行智能体后端，以缩短用户到服务器这一段；随后我们的路由会通过附近集群处理服务器到模型这一段。

自行测量语音智能体延迟

上方延迟预算表中的数字仅为规划用的示例范围。实际发布时应依据类似以下脚本、针对自身部署测得的数字。

以下监测代码通过多次试验测量独立 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 个轮次中有 1 次的体验。 
• 按地点实验：从每个服务区域运行相同脚本，并分别保留结果。
• 错开请求以确保准确：间隔发送请求（如上方的 setTimeout）。若同时发出所有请求，测量到的是自身排队而非服务表现。超过并发限制时，请求会按优先级排队，通常会增加约 50 ms；超过容量后则会收到 HTTP 429。
• 测量完整延迟链：将相同计时模式扩展到其他阶段。把STT 完成时间、LLM 首个 token 和播放器启动都放入相同的 performance.now() 计时区间，即可用自己的数字填充完整预算表，并了解应优先优化哪个阶段。

遵循这些建议，即可自行测量语音智能体延迟，并明确应优先处理哪些问题。

什么最能降低语音智能体延迟？

如果想快速采取行动，以下是最有效的改动。

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

• 基于稳定的 STT 部分结果启动 LLM 工作，以隐藏端点检测延迟。
• 在句子边界将 LLM token 流式送入 TTS，让第一句的合成与第二句的生成重叠。
• 将 TTS 音频流式送至播放器，并将播放器缓冲区缩减到网络抖动可承受的最小值。
• 要实现最低延迟 TTS，可使用 Flash 加默认音色或 IVC，并让编解码器匹配传输方式（电话使用 ulaw_8000，浏览器/WebRTC 使用 PCM 或 MP3）。
• 让服务器与用户同地部署，并按区域测量，因为网络链路真实存在且并不均等。

如需更深入的具体技术，请参阅延迟优化开发者操作指南。如需完整可运行的起点，API 快速入门和流式传输操作指南提供了完整示例。 

想更快使用经过微调的智能体级联方案？ElevenAgents已实现这套管道，并内置阶段重叠优化。

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

语音智能体延迟优化需要测量每个阶段，再让各阶段重叠，使最慢的阶段在其他工作已进行时执行。你可以借助上述模式，通过多轮迭代手动构建和调优该级联方案，也可以从已内置延迟优化的管道开始。

ElevenAgents 实现了完整级联方案：从流式 STT，到逐 token 交接给 LLM，再到 Flash TTS，且已内置重叠技术。无需从头开始，只需针对最重视的性能调节阈值。

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

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