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

实时文本转语音（STT）会在说话时主动转录音频，并在数百毫秒内将语音转为文本。但保持低 STT 延迟既是架构问题，也是模型问题。工程师需要规划传输、分块、端点检测和采集路径，这些环节都会增加延迟。其中任一环节效率不足，都可能耗尽 200 ms 的延迟预算。

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

我们将介绍音频如何到达服务器、假设文本如何演变为已确认文本、流内功能的代价，以及如何正确采集和转发音频。

摘要

• 构建实时文本转语音系统需要精细调整架构，确保整个管线始终保持低延迟。
• WebSocket 是大多数管线的合适默认选择；WebRTC 虽有多项优势，但复杂度也更高。
• 语音活动检测可进行免手动分段；当应用知道当前轮次结束时，手动提交可用于覆盖该判断。
• 部分结果是暂定的，最终结果则已确认，因此应采用不同方式呈现。
• 约 100 ms 的小型 PCM 分块可最大限度缩短首个部分结果的延迟。

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

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

WebSocket 是基于 TCP 的长连接、有序、可靠、双向通道。你可以打开连接、上传二进制音频帧，并接收转录事件。它在客户端和服务器端都很直接，可穿过已允许 HTTPS 的企业代理和防火墙，且所有浏览器和服务器运行时都支持它。

WebSocket 的限制在于它基于 TCP。若数据包丢失，TCP 会重传，并在缺口补齐前阻塞后续数据。网络状况良好时，这通常不明显；但发生丢包时，会产生队头阻塞：音频短暂堆积，随后成批到达。

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

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

以下是主要取舍：

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

如果直接从不可靠移动网络上的消费者设备采集音频、已为双向音频运行 WebRTC 技术栈（例如可回话的语音智能体），或低丢失的实时表现比实现简单更重要，请选择 WebRTC。

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

部分结果与最终转录：临时结果说明

实时识别器不会等到完整句子说完才输出。它会持续输出猜测结果，随着更多音频到达而逐渐准确，最后将其确认。理解这两种状态的差异，才能让转录显得鲜活而非支离破碎。

部分（临时）假设是模型基于目前收到音频作出的最佳猜测。部分结果在设计上并不稳定。随着更多音频到达，模型会修正前面的词语：“I want to” 在后续上下文消除歧义后可能变为 “I want two tickets”。它们到达很快（约 150 ms 延迟所指的就是这一点），并且设计为可被覆盖。

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

部分结果与最终结果的区别会影响以下三点；若混淆它们，就容易出错：

• 用户体验： 显示部分结果可让转录呈现实时感：用户会看到说话时文字同步出现，从而确认麦克风正常、系统正在聆听。
• 端点检测： 部分结果可持续反映语音活动。结合 VAD，可判断说话者是否真正停止。
• 下游时序： 在 语音智能体管线 中，流程依次为音频输入、文本转语音、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 每秒为 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);

代码中的管线

该管线有三个组件：采集麦克风并将 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
});

所有端点特定逻辑都集中在下面两个适配器函数中。请将字段名称替换为文本转语音参考文档中的准确名称；其余管线无需更改：

// 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;
}

可编程后端客户端

对于后端管线和下方基准测试，同一识别器连接无需浏览器即可运行：从任意源读取 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。第二，加载音频文件和参考文本，并在它们上运行测量。使用代表部署环境的机器、代表用户的音频运行，即可获得可复现的对比结果。

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

本文介绍了多项架构调整，帮助你逐步改进系统，迈向实时文本转语音。

生产级实时 STT 系统主要取决于以下几项决策：

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

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

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

Scribe v2 Realtime 的模型延迟约为 150 ms，可生成部分结果。用户实际感受到这一延迟还是更高延迟，取决于周边架构，而这正是你能掌控的部分。采用本文的策略，可构建更完善的管线架构，降低延迟并改善客户体验。

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

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

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