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

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

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

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

摘要

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

定义语音智能体延迟预算

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

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

从用户角度，应关注首段音频时间（TTFA）：从用户停止说话到听到智能体回复的第一个音频采样之间的耗时。TTFA 汇总了整个流程，因此始终大于任一单独模型的推理延迟。

级联式语音智能体包含 5 个阶段：

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

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

以下是面向英语智能体的示例，假设服务器距离用户相对较近。这些数值仅为参考范围，并非保证。

通常，两项最大的延迟来源是 LLM 的首个 token 时间，以及流程开头的端点检测延迟。 

该表有助于直观了解流程，但它会让人以为各阶段严格串行运行，实际并非如此。最重要的几项语音智能体延迟优化都来自阶段重叠，而下方大部分延迟预算正是通过这种重叠节省的。

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

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

转录完成后才会发送给 LLM。Scribe v2 Realtime（scribe_v2_realtime）可在约 150 ms 内返回部分转录结果，并以音频分块流式处理，因此用户仍在说话时转录文本便已生成。它支持 8 kHz 至 48 kHz 的 PCM 和 μ-law 编码，这与下文的编解码器部分相关。这些 150 ms 的部分结果成本很低。

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

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

端点检测需要在响应速度和打断用户之间权衡。较短的静音阈值可让智能体快速回复，但可能在自然停顿时打断用户；较长的阈值更稳妥，却显得迟缓。实践中，优化语音转文本延迟可采取以下 3 项措施：

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 μ-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 音频流式传送至播放器，并将播放器缓冲区缩减至网络抖动可承受的最小值。
• 使用 Flash 搭配默认音色或 IVC，以获得最低延迟的 TTS；并让编解码器匹配传输通道（电话使用 ulaw_8000，浏览器/WebRTC 使用 PCM 或 MP3）。
• 让服务器与用户同地部署，并按区域测量，因为网络链路真实存在且并不均等。

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

想更快使用经过微调的智能体级联流程？ElevenAgents已实现此流程，并内置了重叠优化。

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

语音智能体延迟优化需要测量每个阶段，并让各阶段重叠运行，使最慢的阶段在其他工作进行时后台执行。你可以通过多轮迭代手动构建和调优这一流程，运用上述模式；也可以直接使用已内置延迟优化的流程开始。

ElevenAgents 实现了完整的级联流程，从流式 STT、逐 token 交接至 LLM，再到 Flash TTS，并已内置重叠技术。无需从零开始，只需根据最重要的性能指标调优阈值。

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

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