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

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

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

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

摘要

• 构建实时文本转语音系统需要细致调整架构，确保整个 pipeline 的延迟保持较低。
• WebSocket 是大多数 pipeline 的理想默认选择；WebRTC 虽有多项优势，但也更复杂。
• 语音活动检测可实现免手动分段；当应用知道当前轮次已结束时，可通过手动提交进行覆盖。
• 部分结果是暂定的，最终结果则已确认，因此应采用不同方式呈现。
• 约 100 ms 的小 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。

部分结果与最终转写：理解中间结果

实时识别器不会等一句完整的话说完才输出。它会持续给出猜测，随着更多音频到达逐步完善，最后将结果锁定。理解这两种状态的差异，是让转写显得鲜活而非支离破碎的关键。

部分（中间）假设是模型根据目前收到的音频作出的最佳猜测。部分结果在设计上并不稳定。随着更多音频到达，模型会修正前面的词：后续上下文消除歧义后，“我想要”可能变为“我想要两张票”。它们到达很快（约 150 ms 延迟指的就是这个），并且本来就应该被覆盖。

最终假设是已确认、不会再变更的片段。片段定稿后，识别器会继续处理后续内容，之后的假设对应更晚的音频。最终结果可持久化、发送给 LLM，或保存为转写文本。

部分结果和最终结果的区别会影响以下 3 项；如果混淆它们，这些地方很容易出错：

• 用户体验： 显示部分结果会让转写显得实时：用户说话时能看到文字出现，确认麦克风正常工作，系统正在聆听。
• 端点检测： 部分结果会提供持续的语音活动信号。结合 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-400 ms 后定稿）会让系统响应更快。但它也可能截断在分句间自然停顿的用户，将一句想法拆成多个片段，并在智能体中触发过早回复。
• 较长的超时（例如约 800-1200 ms）可以容忍自然停顿，并保持发言完整，但系统响应前会有明显延迟。

这里没有可通用的固定值；应根据交互方式调整阈值：

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

这些建议可帮助你构建有效的端点检测系统，逐步实现实时文本转语音。

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

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

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

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

词级时间戳和实体上下文也是同样的逻辑。请求的每个 token 元数据越多，模型和传输链路的负载就越大。对大多数实时 UI 而言，只需实时获取文本和片段边界；细粒度元数据可在通话结束后通过 Scribe v2 批处理获得。

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

传输和识别逻辑通常最受关注，但不少实际 bug 源于更底层的音频编码和分块方式。正确设置格式和分块大小，是降低文本转语音延迟最经济的方式。

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

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

分块大小最直接影响感知延迟。音频按块发送，识别器会随分块到达生成部分结果。分块越小，更新越频繁，首个部分结果延迟越低；分块越大，消息越少，每次推理上下文略多。实用范围是每块 20-250 ms 音频。以 16 kHz 单声道 16 位 PCM 为例，1 秒音频为 32,000 字节，因此 100 ms 分块约为 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 密钥是机密，绝不能出现在客户端代码中。密钥应保留在服务器上。如果确实需要浏览器直接与识别器通信，应在服务器端创建短期有效的一次性令牌，交给客户端使用，而不是提供 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 看起来会变化多少。

控制变量

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

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

• 相同音频： 向每个系统输入相同文件、相同采样率和相同编码。
• 相同发送节奏： 以相同的实时分块节奏向所有系统传输音频（例如 100 ms 分块）。
• 重复测试并报告分布： 全天多次运行每个文件；报告中位数和尾部数据（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 帧采集，发送约 100 ms 分块，电话音频则匹配源格式。
• 基准测试： 基于自身音频和目标指标，通过实测调整准确率与延迟的权衡参数。
• API 安全： 将 API 密钥保留在服务器端，或为直接客户端连接创建一次性令牌。

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

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

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

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

准备开始构建时，创建免费的 ElevenLabs 账户，立即开始流式转写。

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