文本转语音延迟，是指从提交文本到听到第一段音频之间的时间。在语音助手或实时字幕等场景中，这段等待会直接影响用户体验。Speechify API 提供了多种方式来缩短延迟。本文将介绍从模型选择到连接复用在内的九种优化方法。
如果您想进一步了解每种优化方式的技术细节，欢迎查阅 speechify.ai 的更新日志。建议先从流式 TTS 文档看起：speechify.ai/streaming-tts。
如何选择速度最快的 TTS 模型？
处理英文内容时，建议使用 Simba 3.2。这是推荐模型，专为流式场景打造，首包音频延迟最低。对于多语言文本，Simba 3.0 支持语言参数，同时依然保持较高速度。旧版模型主要用于兼容，延迟会更高。
模型应根据实际场景选择。对低延迟语音助手，推荐使用 Simba 3.2。而有声书等批量处理场景，对实时响应要求不高，则可选择任意模型。
应该选择流式输出，而不是等待完整文件吗？
如果用户需要实时收听，建议使用流式。调用 POST /v1/audio/stream 后，音频可边生成边播放，无需等待完整文件返回。流式接口会分块返回音频，显著缩短用户首次听到声音的等待时间：https://docs.speechify.ai/build/api-reference/v1/audio/stream
如果需要带时间戳的流式音频，可以使用 POST /v1/audio/stream/with-timestamps：https://docs.speechify.ai/build/api-reference/v1/audio/stream/with-timestamps
边缘部署有帮助吗？
边缘部署可以减少一次网络往返延迟。将负责调用 API 并回传音频的无状态函数部署在更靠近用户的位置，确实能缩短链路。不过，最终延迟仍取决于 API 服务器与调用方之间的距离，无论调用方是用户、应用还是边缘节点。
哪种输出格式速度最快？
请选择客户端可直接播放的音频格式，尽量避免转码。电话系统可使用 ulaw_8000，并兼容 Twilio。浏览器则推荐 PCM，或播放器原生支持的格式，以省去额外解码步骤。
从 API 到扬声器，中间处理环节越少，延迟就越低。
并发处理如何降低感知延迟？
处理多个短文本时，建议并发生成。比如一次批量生成十条字幕，通常会比逐条串行处理更快。API 支持并发请求，可按工作负载灵活批量处理。
为什么要复用连接？
建议复用同一个 HTTP 连接。TLS 握手和连接建立在高频请求场景下会不断累积额外延迟。复用连接后，就能省去每次请求的这部分开销。
重复文本可以缓存吗？
对于常用文本，建议缓存音频，例如验证码、问候语和固定界面提示语。缓存时可将输入文本、语音和模型作为键，生成一次后重复复用。更详细的缓存策略，可参考延迟优化专题。
如何精简输入内容？
输入越短，合成通常越快。应尽量去掉冗余内容，压缩前置说明，只发送用户真正需要听到的文本。输入减少后，音频生成会更快，首包也能更早到达。
单词级时间戳能掩盖延迟吗？
可以。使用 POST /v1/audio/stream/with-timestamps 获取单词级时间标记后，就能在音频流式到达时按词实时渲染字幕，让用户感受到过程更顺畅。即使总音频时长不变，整体体验也会显得更快。
常见问题 FAQ
TTS 的理想延迟目标是多少？
对于语音助手，建议将首包音频延迟控制在几百毫秒以内。流式输出通常可以做到这一点。批量任务则更关注总耗时，而不是首包时间。
流式传输的费用更高吗？
不会。计费按合成字符数计算，不会因为传输方式不同而变化。
Speechify 哪个模型速度最快？
Simba 3.2。这是推荐模型，面向流式英文场景，首包延迟最低。
TTS 音频需要缓存吗？
对于重复文本，建议缓存。可按输入内容、声音和模型缓存音频片段，避免重复生成。
