了解音频流式传输 | ElevenLabs Documentation

流式播放视频时，你是在下载文件。服务器发送字节数据，播放器会缓冲，直到累积足够数据开始播放。音频生成流式传输则完全不同。开始流式传输时，音频尚不存在。模型会实时合成音频，流式字节数据正是这一合成过程的实时输出。

这一差异很重要，因为它改变了你对延迟、缓冲和故障模式的理解方式。

调用流式端点时会发生什么

调用 ElevenLabs 的流式 TTS 端点时，会依次发生以下过程：

关键在第 3 步：服务器不会等整个音频文件准备好后才发送。这正是流式传输与标准端点的根本区别，标准端点会等待合成完成后才返回任何音频。

使用标准端点时，首次音频时间等于合成整段文本所需的时间。对于短句，可能是 500ms；对于一段文字，可能需要数秒。

使用流式传输时，首次音频时间大致等于合成第一个音频分块所需的时间，通常是前几百毫秒的语音。之后的内容会在后续分块并行生成时播放。

因此，流式传输对于实时应用至关重要：即使完整生成需要更久，用户也能在几分之一秒内听到声音。

ElevenLabs 支持两种流式传输方式，适用于不同的场景。

HTTP 流式传输（服务器发送事件）是更简单的方式。你预先发送完整文本，服务器会在生成音频时将其流式返回。适合在开始前就拥有全部文本的情况，例如预先写好的脚本，或希望立即播放的完整 LLM 回复。

WebSocket 流式传输支持双向通信。你可以逐词或逐句增量发送文本，模型会在完整输入尚未可用时开始生成。这使端到端低延迟语音管道成为可能：LLM 生成 token 后，你可以在 token 到达时将其转发到 TTS WebSocket，而 LLM 甚至尚未完成回复时，音频就已开始播放。

WebSocket 方式会增加复杂性。模型需要决定何时开始生成音频：过早开始，可能在短语边界产生不自然的韵律；过晚开始，延迟则会增加。这可通过分块计划和 auto_mode 设置控制；对于大多数场景，后者会自动处理这种权衡。

流式音频生成中，分块大小与语音自然度之间存在根本性的矛盾。

语音合成模型受益于上下文。了解某个词前后的内容，有助于模型生成自然的韵律。模型根据“The economy”生成音频时，如果句子后续是“is recovering”还是“is in freefall.”，其韵律考量会非常不同。

在模型尚未看到足够文本时过早生成音频，可能导致短语边界的语音听起来不自然。虽然技术上正确，但会略显机械。等待更多上下文可以提升自然度，但会增加延迟。

ElevenLabs 的 auto_mode 会分析传入文本，尝试自动找到合适的平衡。对大多数应用而言，这能带来良好效果。当你需要更精细的控制时，例如在语音智能体中，愿意以略低的韵律自然度换取更低延迟，便可以直接配置分块计划。

这两个概念很容易混淆，但它们是不同的指标。

生成延迟是模型生成音频所需的时间。公开的模型延迟数据从服务器端测量：即 ElevenLabs 返回第一段音频所需的时间，不含网络往返和应用开销。

首次音频时间是从应用发起请求，到最终用户实际播放第一个音频采样之间经过的时间。其中包括网络延迟、服务器处理时间，以及音频播放器引入的所有缓冲。

在实际使用中，首次音频时间通常会显著高于原始模型延迟。网络往返会因地理距离增加 50–200ms，音频播放器缓冲还会进一步增加时间。理解这一区别有助于设定合理预期并诊断性能问题：如果首次音频时间较高，瓶颈通常是网络或应用缓冲，而非模型性能。

“流式端点因为增量发送数据而更慢。” 不，它对用户而言更快，因为用户能更早听到音频。总生成时间相近，变化的是数据开始到达的时间。

“我需要用 WebSocket 才能流式传输。” 不一定。HTTP 流式端点足以处理大多数场景。WebSocket 的特殊价值在于同时生成文本和音频，例如 LLM 生成的文本直接输入音频生成。

“高质量音频格式会显著增加流式延迟。” 这一说法大多被夸大了。延迟的主要来源是模型推理时间和网络往返。更高比特率的输出格式只会增加少量开销，在解决更主要的因素之前，通常不值得优先优化。