了解音频流式传输 | ElevenLabs Documentation

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

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

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

调用 ElevenLabs 的流式 TTS 端点后，会依次发生以下情况：

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

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

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

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

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

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

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

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

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

语音合成模型受益于上下文。了解某个词前后的内容，有助于模型生成自然的韵律。模型根据“The economy”生成音频时，若句子以“is recovering”结尾，与以“is in freefall.”结尾时，韵律考量会截然不同。

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

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

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

生成延迟是模型生成音频所需的时间。~75ms Flash 模型指标指的就是这个：模型处理简短文本输入的推理时间，不包括网络往返和应用开销。

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

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

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

“我需要 WebSocket 才能流式传输。” 不一定。HTTP 流式端点能很好地满足大多数场景。WebSocket 的特别价值在于同时生成文本和音频的情况，例如 LLM 生成的文本直接输入音频生成。

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