延迟优化

本指南介绍改善文本转语音延迟的核心原则。如需了解延迟的概念及其影响因素，请参阅了解延迟。

虽然有许多具体方法，我们将其归纳为四项原则。

四项原则

1. 使用 Flash 模型
2. 利用流式传输
3. 考虑地理位置邻近性
4. 选择合适的音色

使用实时模型

Eleven v4 Turbo 和 Flash v2.5 专为实时使用而设计，中位延迟约为 100ms。与 Multilingual v2 相比，Flash 模型的音频质量会略有降低。

利用流式传输

我们的 API 参考文档提供三种文本转语音端点：

• 常规端点：在单个响应中返回完整音频文件。
• 流式端点：使用 Server-sent events 逐步返回音频分块。
• WebSockets 端点：支持双向流式传输，适用于实时音频生成。

流式传输

流式端点会在实时生成音频时逐步返回内容，从而缩短首字节时间。当输入文本可预先获得时，建议使用此端点。

WebSockets

文本转语音 WebSocket 端点支持双向流式传输，非常适合具有实时文本输入的应用（例如 LLM 输出）。

如果禁用 auto_mode，模型会等待足够的文本与分块计划匹配后，才开始生成音频。

例如，如果将分块计划设为 125 个字符，但只收到 50 个字符，模型会暂停，直到收到更多字符——这可能增加延迟。

有关实现详情，请参阅文本转语音 WebSocket 指南。

选择合适的音色

我们发现，在某些情况下，音色选择会影响延迟。以下按速度从快到慢排列：

1. 默认音色（原预制音色）、合成音色和即时语音克隆（IVC）
2. 专业语音克隆（PVC）

更高音频质量的输出格式可能增加延迟。请在延迟要求与音频保真度需求之间做好平衡。

考虑地理位置邻近性

我们从多个区域提供模型服务，以根据地理位置优化延迟。

例如，使用 Flash 模型和 WebSockets 时，根据所在位置，预期可获得以下 TTFB 延迟：

可通过检查 API 响应中的 x-region 标头，确认哪个后端区域正在处理请求。 当前使用的区域包括：美国、荷兰和新加坡。

如需退出全球路由并始终使用美国服务器，请在 API 请求中使用 api.us.elevenlabs.io 基础 URL：

import os
from elevenlabs.client import ElevenLabs
elevenlabs = ElevenLabs(
    api_key=os.getenv("ELEVENLABS_API_KEY"),
    base_url="https://api.us.elevenlabs.io"
)