哪款文本转语音 (TTS) API 支持流式音频输出？技术深度解析

大多数开发者发现流式 TTS 价值的方式都是不对的：他们在没有流式传输的情况下发布了语音功能，眼睁睁地看着用户在播放任何声音前等待 3-4 秒，然后才开始寻找为什么体验感觉很糟糕。

我当时就是这么做的。我为一个内部工具发布了一个没有流式传输的语音响应功能。在第一次真实的反馈会议中，一位产品经理在酒店 WiFi 上进行了演示。用户点击了按钮，盯着屏幕看了 4.2 秒，音频才开始播放。她问按钮是否起作用了。第二天我就增加了流式传输支持。

支持流式传输和不支持流式传输的 TTS API 之间的区别不在于语音质量。而在于用户从发送请求到听到音频之间的这段时间的体验。在同样的 300 字输入下，非流式传输在 5.1 秒内返回了完整的音频。而流式传输在 140 毫秒内就开始了音频播放。总的生成时间是相同的——改变的是用户听到第一个单词的时间。

流式 vs 非流式：差距比延迟数字显示的还要大

以下是每种模式下实际发生的情况：

非流式： 你向 API 发送文本。服务器生成完整的音频文件。服务器返回该文件。你的应用接收文件。你的应用开始播放文件。用户听到任何声音前的总时间：生成时间加上完整文件的传输时间。

流式： 你向 API 发送文本。服务器开始生成音频并立即开始发送数据块。你的应用接收到第一个数据块并开始播放。用户在文件其余部分仍在生成时就能听到音频。用户听到任何声音前的总时间：生成和传输第一个数据块的时间。

对于一段 500 字的脚本，流式传输可能在 120 毫秒内交付第一个音频块，而完整文件生成需要 8 秒。用户感知的等待时间是 120 毫秒，而不是 8 秒。

这不仅仅是一个微小的优化。它是让语音助手感觉像是在对话，还是像是在进行交易之间的区别。

什么时候流式传输至关重要，什么时候不重要

流式传输对于以下场景至关重要：

1. 语音助手和聊天机器人：对话式轮换需要快速输出首个音频。
2. 实时解说：用于直播活动、游戏或交互式应用。
3. 长内容交付：用户不愿为完整文件等待数秒的场景。
4. 移动端应用：流式传输还可以减少数据消耗（仅传输已播放的内容）。

流式传输在以下场景中不太重要：

1. 预录制内容流水线：音频已提前生成并缓存。
2. 批处理：用户不在实时等待的文档或脚本处理。
3. 简短通知（5 个词以内）：完整文件生成本身就在 100 毫秒以内。

流式 TTS 的技术原理

交付机制是基于 HTTP 或 WebSocket 的分块传输编码 (chunked transfer encoding)。服务器不是等待完整的音频缓冲区就绪，而是随着生成进度发送小的音频片段——通常首批交付的是 4-8KB 的音频数据。客户端（你的应用）接收并顺序排队播放这些片段。

关键性能指标是首字节时间 (TTFB)：即从 API 请求到第一波音频数据到达之间的时间。在良好的条件下（低延迟服务器区域、稳定连接），专为流式设计的 TTS API 的 TTFB 通常在 80-200 毫秒范围内。在延迟波动的移动网络上，这一范围会扩大到 200-600 毫秒。低 TTFB 是让流式 TTS API 真正感觉迅速的技术前提。

在客户端，缓冲区管理传入的数据块，维持平滑播放，并在流中断时处理缺口。在浏览器中使用 MediaSource Extensions 实现时，音频流水线如下：获取响应流，将数据块附加到 SourceBuffer，MediaElement 从缓冲区播放。浏览器处理同步。棘手的部分是在网络速度快于音频播放速度时处理背压 (backpressure)。在 iOS 上，等效的是 AudioQueue；在 Android 上，ExoPlayer 处理缓冲层。

在大多数实现中，这种缓冲是由音频播放库而非自定义代码处理的——但这只有在你使用专为流式输入设计的库时才成立。

开发者笔记： 我的第一个流式实现有一个微妙的缓冲区欠载 (buffer underrun) 问题。音频会开始播放，在 800 毫秒左右出现卡顿，然后继续——产生一种奇怪的断续感，这比原始的非流式版本更具干扰性。诊断这个问题比最初的实现花的时间还长。原因是向缓冲区追加数据块的速度与播放器消耗它们的速度不匹配。解决方法是在开始播放前增加一个小的初始缓冲区（约 1.5 秒的音频数据），这用一点点 TTFB 换取了交付的稳定性。

流式传输支持对比

“支持流式传输”与“针对实时流式传输进行优化”之间的区别非常重要。Azure 支持流式传输，但会通过企业级基础设施路由。Google 的基础 TTS API 不提供与专用实时平台相同意义上的真正分块流式传输。

Fish Audio 流式传输：实现起来是什么样的

Fish Audio 的 API 将流式传输作为一等公民功能提供，而不是企业级插件。向开启了流式传输的 TTS 端点发送请求，将以毫秒级的 TTFB 开始返回音频块。第一个数据块通常携带 4-8KB 的音频数据，足以让播放器立即开始输出。

实际架构如下：你的应用程序向 Fish Audio API 端点发送文本，指定流式输出，并打开响应流。第一个音频块在服务器端完成完整音频生成之前就会到达。你的音频播放器立即开始消耗该流，而缓冲则在播放层处理。

对于语音助手和聊天机器人，这意味着用户在 LLM 或你的应用程序完成完整文本输入之前就能听到响应的开头。结合 GPT 或 Claude 等模型的流式文本生成，你可以将文本流直接流水线化到音频流中，在优化良好的实现下，这将从用户输入到听到响应的总时间缩短至 500 毫秒以内。

语音克隆同样支持流式传输。克隆的声音可以像目录中的任何声音一样进行流式传输，这意味着自定义品牌语音与标准语音相比不会有额外的延迟损失。

高并发意味着多个同步流不会互相降低对方的 TTFB。这对于服务大量用户的应用非常重要：你为一个用户测量的流式性能在 500 个并发用户下依然有效。

Fish Audio 的流式实现效果很好，但它没有通过 API 暴露对块大小或缓冲行为的精细控制。如果你需要为对延迟极度敏感的应用（例如具有严格抖动要求的实时翻译工具）精确控制流参数，你可能需要在响应流之上实现自己的缓冲层。

完整实现文档请参阅 docs.fish.audio。

ElevenLabs：英语内容的流式质量

ElevenLabs 的流式传输在英语内容上表现出色，具有极具竞争力的 TTFB 和可靠的交付。对于以英语语音质量为首要要求且需要流式交付的应用，它是一个强大的选择。

与 Fish Audio 的按需付费结构相比，其成本模型在高流式传输量下扩展得更快。对于具有持续高吞吐量流式传输的应用（如客服机器人、高流量语音助手），成本差异会随时间显著增加。

OpenAI TTS：GPT 生态系统中的简单流式传输

OpenAI 的 TTS 流式 API 确实非常简洁。如果你已经在 OpenAI 栈上构建，流式实现大约只需要两行代码——在请求中设置 stream=True 并迭代响应块。处理文本生成的同一个客户端也可以处理语音流，这大大简化了流水线。

其语音目录仅限于 11 种声音，没有语音克隆，且每字符成本高于专用的 TTS 平台。但对于快速原型开发，其简单性是实打实的。如果你深度嵌入 OpenAI 生态系统且不需要语音定制，作为一个便捷方案是值得使用的。

开发者笔记： 无论使用哪个平台，流取消都不是一件简单的事。当用户中断语音响应时，你需要停止从流中读取，丢弃剩余的音频缓冲区，并干净地释放连接。如果不这样做，连接将保持开启状态，消耗带宽和 API 配额来处理没人听的音频。在开发过程中尤其容易忽视这一点，因为你是在快速连接上进行测试，很少在中途中断播放。

流式 TTS 实现清单

如果你正在集成流式 TTS API，以下是需要在客户端处理的事项：

1. 在需要音频之前打开流。 在会话初始化时预热连接，而不是在用户触发语音响应时。
2. 缓冲传入的数据块。 大多数播放库会自动处理，但要确保你的实现不会在缓冲上阻塞。在播放开始前设置 1-2 秒的初始缓冲区通常值得那点 TTFB 的增加。
3. 处理流中断。 用户有时会切断语音响应。实现干净的流取消，使部分流不会导致错误或让连接处于开启状态。
4. 在移动网络而非仅在 WiFi 上测试。 在延迟波动的连接上，数据块交付模式会发生显著变化。缓冲区欠载（音频中断）是移动端特有的问题，在桌面测试中不会出现。
5. 在并发负载下测试。 1 个并发用户的 TTFB 不能预示 100 个并发用户的 TTFB。在部署到生产环境前进行负载测试。
6. 在生产环境中监控 TTFB。 添加仪表以跟踪首字节延迟随时间的变化。退化通常先在 TTFB 中表现出来，然后才体现在整体延迟中。

常见问题解答

是否每个 TTS API 都支持流式传输？ 不是。一些平台，包括 Google TTS 的基础层和几个较小的提供商，不提供真正的分块流式传输。它们在完整生成后返回完整的音频文件。如果你的应用需要快速的首音，请在集成前务必验证流式支持。

与下载完整文件相比，流式传输快多少？ 对于短回复（50 字以内），差异极小。对于长回复，流式传输开始音频播放的速度比等待完整文件快 5-10 倍。300 字的回复可能需要 5 秒才能完全生成；而流式传输在 200 毫秒内即可交付首个音频。

我可以对克隆语音使用流式传输吗？ 在支持该功能的平台上是可以的。Fish Audio 支持克隆语音的流式传输，且没有额外的延迟损失。在流式传输方面，克隆语音与目录中的任何语音都一视同仁。

流式传输会影响音频质量吗？ 不会。音频质量由模型决定，而不是交付方式。来自高质量模型的流式响应听起来与作为完整文件交付的相同响应完全一样。

流式传输比非流式 TTS 更贵吗？ 在大多数平台上，流式传输不会改变单字符定价。成本是相同的；流式传输是一种交付机制，而不是一个单独的服务层。

实时语音应用的最佳流式 TTS API 是哪个？ 对于大多数实时应用，Fish Audio 具有毫秒级 TTFB 的原生流式传输涵盖了全方位的部署类型：语音助手、聊天机器人、移动应用和高并发服务。ElevenLabs 是以英语为核心、语音质量为首选的应用的替代方案。

结论

流式 TTS 不是一项溢价功能。它是任何用户等待音频开始播放的应用的基础要求。非流式 TTS 适用于内容流水线、预生成工作流和批处理。对于任何涉及实时交互的场景，流式和非流式之间的 TTFB 差异决定了体验感觉是像一段对话还是一个加载界面。

实现细节也很重要——缓冲区管理、流取消、移动网络行为。做好流式传输需要比在 API 调用中切换一个标志更多的考量。但当你第一次进行对比测试时，用户体验的差异是立竿见影且显而易见的。

Fish Audio 的原生流式传输具有毫秒级的 TTFB，涵盖了语音助手、对话式 AI、移动应用和高并发部署。实现细节和流式 API 文档请访问 docs.fish.audio。