实时语音转文本，延迟低于 200 毫秒：架构指南

实时文本转语音（STT）会在人说话时持续转录音频，并在数百毫秒内返回文字。但要保持较低的 STT 延迟，架构与模型同样关键。工程师需要统筹传输、分块、端点检测和采集路径，这些环节都会增加延迟。其中任何一环效率不足，都可能耗尽 200ms 的延迟预算。

本指南提供一套实用方法，帮助你从传输层开始构建实时文本转语音 pipeline。我们将以 Scribe v2 Realtime 为例：它的模型延迟约为 150ms，可生成部分转录结果，支持 90 多种语言、PCM（8kHz-48kHz）和 mu-law 音频，并提供语音活动检测和手动提交控制，用于完成分段。

我们将介绍音频如何到达服务器、识别假设如何演变为已确认文本、流内功能会带来哪些成本，以及如何正确采集和转发音频。

摘要

• 构建实时文本转语音系统需要细致优化架构，确保整个 pipeline 的延迟都保持较低。
• 对大多数 pipeline 而言，WebSocket 是合适的默认选择；WebRTC 虽有多项优势，但实现更复杂。
• 语音活动检测可实现免手动分段；当应用已知当前轮次结束时，手动提交可作为覆盖机制。
• 部分结果是暂定的，最终结果则已确认，因此应以不同方式呈现。
• 约 100ms 的小型 PCM 分块可降低获得首个部分结果的延迟。

实时文本转语音：WebSocket 与 WebRTC 对比

转录开始前，音频必须从来源传输到识别器。所选通道决定了后续所有环节的延迟下限。将音频送达转录层有两种可行方案。

WebSocket 是基于 TCP 的长连接、有序、可靠、双向通道。建立连接后，可向上发送二进制音频帧，并向下读取转录事件。它在客户端和服务器端都易于使用，可穿过已允许 HTTPS 的企业代理和防火墙，而且所有浏览器和服务器运行时都支持。

WebSocket 的限制在于它基于 TCP。如果数据包丢失，TCP 会重传，并在缺口填补前阻塞后续数据。网络状况良好时，这并不明显；出现丢包时，则会产生队头阻塞：音频短暂停滞、积压，然后成批到达。

WebRTC 专为实时媒体而设计。它通过 UDP（经由 SRTP）传输媒体，因此丢包不会阻塞流，pipeline 会继续运行。它包含可吸收数据包到达时间波动的抖动缓冲区，通过 ICE/STUN/TURN 协商 NAT 穿透，使路由器后的对等端能够连接，并自带音频采集和编码机制。

对于无法直接连接的客户端，通常需要 TURN 服务器；服务器端也必须终止媒体流，而非读取字节流。

以下是关键取舍：

对于大多数用例，WebSocket 是合适的选择。客户端网络连接良好且你能控制采集路径时，可使用它，例如服务器间 pipeline、桌面应用、宽带环境下的浏览器应用，以及多数音频已通过其他方式到达服务器的呼叫中心后端。

如果直接从网络不稳定的消费级移动设备采集音频、已运行用于双向音频的 WebRTC 技术栈（例如也会语音回复的语音智能体），或低丢包的实时行为比实现简洁性更重要，请选择 WebRTC。

本指南其余部分将使用 WebSocket 连接识别器，因为它能清晰呈现各个组件，也是多数团队的合适起点。这些内容并不局限于 WebSocket，因此之后可以在前端加入 WebRTC 媒体链路，在服务器上将音频解码为 PCM，再将相同分块转发到 pipeline。

部分结果与最终转录：解释中间结果

实时识别器不会等到完整句子结束才输出。它会持续给出猜测，随着更多音频到达而逐步完善，随后将其确认。理解这两种状态的区别，才能让转录看起来自然而非支离破碎。

部分（中间）假设是模型根据目前收到的音频做出的最佳猜测。部分结果天生不稳定。随着更多音频到达，模型会修正之前的词语：后续上下文消除歧义后，“I want to”可能变为“I want two tickets”。它们很快返回（约 150ms 的延迟指标指的正是这一点），并且本就应被覆盖。

最终假设是不会再变化的已确认分段。分段完成后，识别器会继续处理后续音频，之后的假设描述的是更晚的音频。最终结果可用于持久化、发送给 LLM 或保存为转录文本。

部分结果与最终结果的区别会影响以下三件事；若混淆两者，就容易出错：

• 用户体验：显示部分结果会让转录看起来是实时的：用户会在说话时看到文字出现，从而确认麦克风正常，系统正在聆听。
• 端点检测：部分结果提供持续的语音活动信号。结合 VAD，可判断说话者是否真正结束说话。
• 下游时序：在 语音智能体 pipeline 中，流程依次是音频输入、文本转语音、LLM、文本转语音，最后是音频输出。可基于部分结果提前进行推测性处理，并在最终结果到达时确认，以偶尔丢弃推测性工作的代价缩短感知响应时间。

应以不同方式呈现部分结果和最终结果。一种简单有效的模式是，维护一条与最新部分结果绑定、可变的“当前行”；最终结果到达时，将其提交到仅追加的转录记录中：

type TranscriptState = {
  committed: string[]; // finalized segments, never rewritten
  current: string;     // latest partial, overwritten on each update
};

const onPartial = (s: TranscriptState, text: string): TranscriptState =>
  ({ ...s, current: text });

const onFinal = (s: TranscriptState, text: string): TranscriptState =>
  ({ committed: [...s.committed, text], current: "" });

在视觉呈现上，已确认文本使用常规样式，当前文本则使用较浅或斜体样式，让用户了解它仍可能变化。

端点检测与语音活动检测（VAD）

了解说了什么只是问题的一半。识别器还必须知道一句话何时结束。这个判断决定何时完成分段，以及在智能体中系统何时开始回复。

端点检测是判断一次话语是否结束的过程。过早完成会在用户说到一半时截断；过晚完成则会让智能体在用户明显说完后仍保持沉默。

Scribe v2 Realtime 提供两种互补机制：

• 语音活动检测根据静音对音频分段：识别器会检测语音何时变为持续静音，并以此边界自动完成分段。VAD 是对话界面的合适默认方案，因为它能适应自然语速和节奏，无需手动跟踪时间。
• 手动提交控制：手动提交控制让应用独立于静音状态，自行决定何时完成当前分段。发送提交信号后，识别器会关闭当前分段并输出最终结果。当应用已知当前轮次结束时，这是合适的工具：例如按住说话按钮松开、“发送”操作或外部轮次管理策略。

两者可很好地配合使用。典型的 语音智能体使用 VAD 实现免手动操作，并将手动提交作为覆盖机制：这样思考时暂停的用户不会被截断，而点击按钮的用户可立即获得边界。

静音阈值存在实际取舍，没有放之四海而皆准的正确值：

• 较短的语音结束超时（例如静音约 200-400ms 后完成）会让系统感觉响应迅速，但也会截断在分句间自然停顿的用户，将一个想法拆为多个分段，并在智能体中触发过早回复。
• 较长的超时（例如约 800-1200ms）可容忍自然停顿并保持话语完整，但系统反应前会出现明显延迟。

这里没有全局通用常量；应根据交互场景调整阈值：

• 听写和记笔记可容忍更长停顿，因为用户会在句中思考。应倾向更长超时，并主要依赖 VAD。
• 命令控制和事务型智能体适合较短超时加手动提交，因为交互轮次简短明确。
• 多语种或非母语说话者停顿更多，因此完成分段前应预留更长静音时间。

运用这些建议，有助于构建有效的端点检测系统，迈向实时文本转语音。

流内功能：语言检测与说话人分离

流式识别不只能生成文字。不过，每增加一种所需信号，都会影响延迟和稳定性。经验法则是：只启用实时体验所需的功能，其余延后到批处理。

自动语言识别可让 Scribe v2 Realtime 在支持的 90 多种语言中识别所说语言，无需预先指定。代价是模型需要一小段音频才能做出可靠判断，因此在语言确定前，流的最初部分结果可能不够稳定。如果已知语言，指定它可消除这一不确定性，通常能让早期部分结果更稳定。

说话人分离可将语音归属到不同说话者，识别谁说了什么。在 批量转录中，这相对容易，因为模型能看到整个文件。流式处理则更难：识别器只能根据目前的音频分配说话人标签，而早期音频的标签可能要等听到该说话者更多语音后才能修正。应像处理部分文本一样处理流式说话人标签：在分段完成前都视为暂定。

词级时间戳和实体上下文也遵循相同逻辑。请求的每个 token 元数据越多，模型和传输链路需要承载的内容就越多。对于大多数实时 UI，只需实时获取文本和分段边界；细粒度元数据可通过 Scribe v2 在通话后批处理。

流式音频格式：PCM 与 mu-law

传输和识别逻辑最受关注，但大量真实环境中的 bug 实际源于更底层：音频的编码和分块方式。正确设置格式和分块大小，是降低文本转语音延迟成本最低的优化手段。

若能控制采集，建议使用 PCM（线性、16 位有符号、小端序）。更高采样率可携带更多声学细节：16kHz 是语音识别的标准下限，通常已足够；8kHz 属于电话级别，会丢失高频内容。应使用与来源匹配的采样率。将 8kHz 电话音频上采样到 48kHz 没有益处，因为缺失的信息无法恢复。

8kHz 的 mu-law 是电话音频格式。如果从 Twilio 等服务商接入通话，音频会以 8kHz mu-law 格式到达，应直接以该格式转发，而非进行两次转码。匹配来源格式可避免重采样伪影和不必要的转换步骤。

分块大小最直接影响感知延迟。音频以分块发送，识别器会在分块到达时生成部分结果。较小分块意味着更新更频繁、获得首个部分结果的延迟更低；较大分块则意味着消息更少，每次推理有略多上下文。实用范围是每个分块 20-250ms 音频。举例来说，对于 16kHz 单声道 16 位 PCM，1 秒音频为 32,000 字节，因此 100ms 分块约为 3,200 字节。

在浏览器中采集麦克风输入

在浏览器中，合适的工具是 Web Audio API 与 AudioWorklet。worklet 在音频渲染线程运行，以小帧接收音频，不会像旧版 ScriptProcessorNode 那样受主线程卡顿影响。它负责将浏览器原生浮点采样转换为 16 位 PCM，交给主线程后再通过 WebSocket 转发。

worklet 处理器的核心是浮点数到 PCM 的转换：

// pcm-worklet.ts - registered via audioContext.audioWorklet.addModule()
class PCMWorklet extends AudioWorkletProcessor {
  process(inputs: Float32Array[][]) {
    const channel = inputs[0]?.[0]; // mono; Float32, range [-1, 1]
    if (!channel) return true;
    const pcm = new Int16Array(channel.length);
    for (let i = 0; i < channel.length; i++) {
      const s = Math.max(-1, Math.min(1, channel[i]));
      pcm[i] = s < 0 ? s * 0x8000 : s * 0x7fff;
    }
    // Transfer the buffer to the main thread without copying.
    this.port.postMessage(pcm.buffer, [pcm.buffer]);
    return true;
  }
}
registerProcessor("pcm-worklet", PCMWorklet);

代码中的 pipeline

该 pipeline 包含 3 个部分：采集麦克风并将 PCM 流式传输到服务器的浏览器客户端、将音频转发到 Scribe v2 Realtime 并将转录结果转回的 Node 服务器，以及从文件或电话桥接传输 PCM 的脚本化客户端。

服务器使用中继而非将识别器直接暴露给浏览器，原因很重要：ElevenLabs API 密钥是机密，绝不能出现在客户端代码中。密钥应保留在服务器上。如果确实需要让浏览器直接与识别器通信，应在服务器端创建短期单次使用 token，并将其交给客户端，而不是 API 密钥。

浏览器客户端

客户端连接到服务器的 WebSocket，通过上方 worklet 采集麦克风，并在每个 PCM 帧生成时立即转发。传入事件（服务器已规范化为 { type, text }）会驱动前文的部分结果／最终结果状态：

// client.ts - runs in the browser. ws is an open WebSocket to your server.
const audioContext = new AudioContext({ sampleRate: 16000 });
await audioContext.audioWorklet.addModule("pcm-worklet.js");

const mediaStream = await navigator.mediaDevices.getUserMedia({
  audio: { channelCount: 1, echoCancellation: true, noiseSuppression: true },
});

const source = audioContext.createMediaStreamSource(mediaStream);
const worklet = new AudioWorkletNode(audioContext, "pcm-worklet");

// Forward each PCM frame to the server the moment it is produced.
worklet.port.onmessage = (e: MessageEvent<ArrayBuffer>) => {
  if (ws.readyState === WebSocket.OPEN) ws.send(e.data);
};
source.connect(worklet);

// Manual commit: tell the server to finalize the current segment.
const commit = () => ws.send(JSON.stringify({ type: "commit" }));

服务器中继

服务器为每个客户端打开一个识别器连接，将 API 密钥保留在服务器上，直接转发二进制 PCM，并将识别器事件规范化为客户端使用的稳定 { type, text } 格式：

// server.ts - Node, using the `ws` library. ELEVENLABS_API_KEY and the
// recognizer URL come from the environment; see the Speech to Text reference
// for the exact path and query parameters.
import { WebSocketServer, WebSocket } from "ws";

new WebSocketServer({ port: 8080 }).on("connection", (client) => {
  // The API key stays on the server, never on the wire to the browser.
  const recognizer = new WebSocket(process.env.RECOGNIZER_WSS_URL!, {
    headers: { "xi-api-key": process.env.ELEVENLABS_API_KEY! },
  });

  // Browser -> recognizer: forward binary PCM, translate control messages.
  client.on("message", (data, isBinary) => {
    if (recognizer.readyState !== WebSocket.OPEN) return;
    if (isBinary) recognizer.send(data); // raw PCM bytes
    else if (JSON.parse(data.toString()).type === "commit")
      recognizer.send(sendCommit());
  });

  // Recognizer -> browser: normalize events into a stable shape.
  recognizer.on("message", (raw) => {
    const event = parseRecognizerEvent(raw.toString());
    if (event && client.readyState === WebSocket.OPEN)
      client.send(JSON.stringify(event));
  });

  // ... open handshake, queueing pre-open audio, and teardown on close/error
});

所有与端点相关的内容都集中在下面两个适配器函数中。请用文本转语音参考文档中的准确字段名替换它们；其余 pipeline 无需改变：

// The single place that knows the recognizer's wire format.
const sendCommit = (): string => JSON.stringify({ type: "commit" });

type NormalizedEvent =
  | { type: "partial"; text: string }
  | { type: "final"; text: string }
  | { type: "vad"; speaking: boolean };

function parseRecognizerEvent(raw: string): NormalizedEvent | null {
  const msg = JSON.parse(raw);
  if (msg.is_final === true || msg.type === "final")
    return { type: "final", text: msg.text ?? "" };
  if (msg.type === "vad") return { type: "vad", speaking: !!msg.speaking };
  if (typeof msg.text === "string")
    return { type: "partial", text: msg.text };
  return null;
}

脚本化后端客户端

对于后端 pipeline 和下方基准测试，无需浏览器也可使用同一个识别器连接：从任意来源读取 PCM，按实时分块节奏发送，并读取返回事件。API 密钥和 URL 与服务器一样来自环境变量。

// stream-stt.ts - pace ~100ms chunks at real time, then commit the tail.
const SAMPLE_RATE = 16000, CHUNK_MS = 100;
const CHUNK_BYTES = (SAMPLE_RATE * 2 * CHUNK_MS) / 1000; // 3200 bytes
const ws = new WebSocket(process.env.RECOGNIZER_WSS_URL!, {
  headers: { "xi-api-key": process.env.ELEVENLABS_API_KEY! },
});

// Send: walk the PCM buffer in 100ms chunks, sleeping between to mimic a
// live source. For audio that already arrives in real time, drop the sleep.
async function sendAudio(pcm: Buffer) {
  for (let off = 0; off < pcm.length; off += CHUNK_BYTES) {
    ws.send(pcm.subarray(off, off + CHUNK_BYTES));
    await new Promise((r) => setTimeout(r, CHUNK_MS));
  }
  ws.send(JSON.stringify({ type: "commit" })); // finalize the trailing segment
}

// Receive: print partials in place, append finals.
ws.on("message", (raw) => {
  const e = parseRecognizerEvent(raw.toString());
  if (e?.type === "final") console.log(`[final]   ${e.text}`);
  else if (e?.type === "partial") process.stdout.write(`[partial] ${e.text}\r`);
});

文本转语音延迟与词错误率基准测试

延迟和词错误率都会因说话者、语言、声学条件、音频时长、到各服务商最近区域的网络路径，以及各服务当前负载而变化。

在某个城市用笔记本测得的结果，无法直接推广到另一座城市的生产环境。应在接近生产环境的基础设施上，使用接近真实输入的音频运行测试工具，并报告范围和分布，而非单一数值。

唯一重要的延迟和准确率数据，是在接近生产环境的基础设施上，使用自身音频测得的数据。以下是文本转语音延迟基准测试指南。

文本转语音延迟应测量什么

对实时文本转语音延迟进行基准测试时，应测量以下主要指标：

• 首个部分结果时间：从发送首个音频分块到收到首个非空部分结果的时间。
• 部分结果至最终结果的延迟：从一次话语的最后一个音频分块到最终假设的时间。
• 词错误率（WER）：最终转录文本相对于人工参考文本的 WER，所有系统使用相同计算方法。
• 稳定性变动：完成前被改写的部分结果数量。该指标可反映实时 UI 看起来会有多大程度的变化。

控制条件

为避免数据不可靠，应在实验中设置多项控制条件，保持一致性。

以下是进行 文本转语音 延迟基准测试时的主要控制条件：

• 相同音频：向每个系统输入相同文件、相同采样率和相同编码。
• 相同发送节奏：以相同实时分块节奏传输至每个系统（例如 100ms 分块）。
• 重复测试并报告分布：全天多次运行每个文件；报告中位数和尾部值（p50/p95）。
• 相同参考文本和评分方法：计算 WER 前，以相同方式规范化文本（大小写、标点和数字）。
• 披露区域和网络：说明测试工具运行的位置以及到各服务商的网络路径。

保持这些要素一致，才能得到更准确的指标。

测试工具框架

测量核心接收服务商适配器，并记录首个部分结果时间、完成延迟和部分结果变动：

// benchmark.ts - measurement core; one StreamFn adapter per provider.
type StreamFn = (
  audioPath: string,
  onEvent: (kind: "partial" | "final", text: string) => void,
  result: RunResult
) => Promise<void>; // adapter sets result.lastChunkSentAt on the final chunk

interface RunResult {
  firstPartialMs?: number;
  finalLagMs?: number;
  hypothesis: string;
  partialEdits: number;
  lastChunkSentAt: number;
  startedAt: number;
}

async function measure(streamFn: StreamFn, audioPath: string): Promise<RunResult> {
  const result: RunResult = {
    hypothesis: "", partialEdits: 0, lastChunkSentAt: 0,
    startedAt: performance.now(),
  };
  let prevPartial = "";

  await streamFn(audioPath, (kind, text) => {
    const now = performance.now();
    if (kind === "partial") {
      if (text && result.firstPartialMs === undefined)
        result.firstPartialMs = now - result.startedAt;
      if (text !== prevPartial) { result.partialEdits++; prevPartial = text; }
    } else { // final
      result.hypothesis = result.hypothesis ? `${result.hypothesis} ${text}` : text;
      if (result.lastChunkSentAt)
        result.finalLagMs = now - result.lastChunkSentAt;
    }
  }, result);

  return result;
}

词错误率是对规范化文本计算的标准 token 级 Levenshtein 距离。计算前，应对参考文本和假设文本以相同方式转为小写并去除标点，否则测量到的是规范化器而非模型。应将此测量封装在循环中，为每个服务商将每个文件运行约 10 次，并报告首个部分结果时间和 WER 的中位数（p50/p95），因为单次样本主要受网络波动影响。

要运行它，需要提供两项内容。首先，为每个系统编写一个 StreamFn 适配器。上方的脚本化客户端已是其中一个；其他适配器遵循相同的（audioPath, onEvent, result）约定，并在最终音频分块发送时设置 result.lastChunkSentAt。其次，加载音频文件和参考文本，并在它们之间调用 measure。在能代表部署环境的机器上，使用能代表用户的音频运行它，即可获得可复现的对比结果。

回顾如何实现实时文本转语音

本文介绍了许多架构改进措施，帮助你持续优化系统，向实时文本转语音迈进。

生产级实时 STT 系统取决于几项关键决策：

• 传输：若追求简洁且网络可控，请选择 WebSocket；若需要丢包容忍能力并从消费级设备采集音频，请选择 WebRTC。
• 部分结果与最终结果：将部分结果视为暂定、最终结果视为已确认，并以不同方式呈现，以便用户信任实时文本。
• 端点检测：使用 VAD 实现免手动分段，将手动提交作为覆盖机制，并根据交互场景而非固定常量调整静音阈值。
• 流内功能：只在实时体验需要时启用流内功能，其余延后通过 Scribe v2 批处理。
• 音频格式：以小型 PCM 帧采集，发送约 100ms 分块，并为电话音频匹配来源格式。
• 基准测试：根据自身音频和目标指标，以实测方式调整准确率与延迟之间的参数。
• API 安全：将 API 密钥保留在服务器上，或为直接客户端连接创建单次使用 token。

如果想了解如何 优化语音智能体延迟，我们也为你准备了相关指南。

使用 Scribe v2 Realtime 构建实时文本转语音系统

Scribe v2 Realtime 的模型延迟约为 150ms，可生成部分结果。用户实际体验到的是这一数值还是更高延迟，取决于周边架构，而这正是你能够控制的部分。采用本文策略，可优化 pipeline 架构、降低延迟并改善客户体验。

如需深入了解，可查看 文本转语音功能概览，阅读我们的 模型参考文档以获取完整功能和语言列表，并访问实时产品页面：实时文本转语音 API 和 实时文本转语音。

准备开始构建时，创建免费的 ElevenLabs 账户，立即流式生成第一份转录文本。

实时文本转语音延迟常见问题