Qwen3-TTS：低成本、高性能文本转语音

语音正迅速成为与 LLM 系统交互的主流界面。拥有高性能且富有表现力的文本转语音能力，可以解锁新的产品体验，例如语音代理、听写和内容生成等。

为了以高性能和高性价比服务客户的生成式语音工作负载，我们一直在使用 vLLM-Omni 优化 Qwen3-TTS 模型系列的单副本性能。最终，我们在保持高语音保真度的同时，实现了显著的成本效益（约每百万字符 3-4 美元）。

我们已将 Qwen3-TTS 部署到语音代理、语言学习和企业呼叫基础设施等场景中，并在语音质量和速度方面获得了普遍压倒性的积极反馈。在本文中，我们将介绍一些用于在生产中实现高性价比、高性能 TTS 的优化方法——其成本比同类闭源模型低约 90%（基于每百万 token 3 美元的估算）。

✕

Baseten 的 TTS 成本为每百万字符 3 美元，而 OpenAI 及类似闭源提供商为 30 美元。开箱即用的 Qwen3-TTS 约为每百万字符 4.80 美元，但不包含性能优化或用于中断处理等场景的词级时间戳。Baseten 的实现（含词级时间戳）成本比大多数闭源产品（有些每百万 token 成本超过 50 美元）低 90%，比原生 Qwen3-TTS 低 37.5%。

您今天就可以从我们的模型库试用我们优化后的 Qwen3-TTS 模型，或者联系我们，与我们的工程师讨论如何为您的负载定制 Qwen3-TTS。作为我们使用 vLLM-Omni 提升语音 AI 性能工作的一部分，我们也在将更新回馈给 OSS 社区；更多细节，以及如何专门为语音克隆优化 Qwen3-TTS，将在未来的博客文章中发布！

文本转语音 API 的经济性

通常，托管 TTS API 根据传递给模型的字符数（每千或百万字符）收费。这个费率包含了服务成本（包括 GPU 使用）以及模型处理多个请求以分摊这些成本的并发能力。

对于闭源提供商，其精确的计算公式是不透明的。降低成本的唯一方法是希望提供商降价，或者完全切换模型或提供商。而对于开源、专用的 TTS 产品，这个计算要清晰得多：您直接为 GPU 使用付费。同时，任何能在相同 GPU 上推动更高并发的优化，都将直接降低每千/百万字符的价格。

实现每百万字符低于 5 美元

为了推导开源 TTS 模型每百万 token 的成本，我们首先在一个混合长度提示（20-500 字符，涵盖短话语、IVR 风格脚本、信息简介和段落长度叙述）的语料库上运行了基准测试。下表显示了我们的字符/秒处理速度如何随并发度增加而变化。

当我们推动单个副本的吞吐量时，我们可以将其成本分摊到更多流上，从而降低每百万字符的价格。

P = 6.50 美元（H100 每小时使用列表价）

T = 吞吐量（字符/秒）

M = (1,000,000 * P) / (3600 * T) ​

（我们除以 3600 将每小时列表价转换为每秒成本。）

当 P = 1 个 H100 副本，T = 594 字符/秒 @ 25 个并发流时，M ≈ 3.04 美元/百万字符（每千字符 0.00304 美元）。

不同并发流数量下的成本

✕

在 25 个并发流时，系统达到最佳点：每百万字符 3.04 美元，p50 和 p90 RTF 均远低于实时阈值（绿色虚线）。在低端，单流推理速度比实时快近 6 倍，但成本更高，因为 GPU 利用率不足。在 32 个流时，由于 GPU 争用，p90 RTF 攀升至实时线以上，成本相应增加。此范围内的所有配置都比闭源替代方案成本效益高得多，同时速度快于实时。

以及完整的基准测试：

优化的 Qwen3-TTS 技术栈

为了达到这些激进的成本、延迟和吞吐量指标，我们使用了 vLLM-Omni 进行服务，并专注于从单个副本中榨取最大性能。以下是实现这一目标的服务栈的关键方面。

解耦的声学 token 生成与解码

Qwen3-TTS 及类似的基于 Transformer 的 TTS 模型通常有两个不同的计算阶段：一个自回归（AR）Talker，用于生成声学 token（类似于标准 LLM token 生成），以及一个神经音频编解码器解码器，用于将这些生成的 token 转换为可以流式传输回客户端的音频。

开箱即用时，这些阶段在单个请求内串行运行。AR 步骤在 vLLM 的 Code2Wav 开始将其解码为音频之前，生成完整的声学 token 序列。由于两个阶段共享相同的引擎上下文，解码器在 token 生成期间空闲，AR 阶段在解码期间空闲，从而阻止后续请求被处理，直到正在进行的请求完全清空管道。

vLLM-Omni 的解耦阶段执行将每个阶段作为独立的引擎运行，拥有自己的调度器，并通过一个处理中间数据传输的阶段间连接器连接。这实现了跨请求的流水线：Code2Wav 可以解码请求 A 的 token，同时 Talker 已经在为请求 B 生成 token。每个阶段还独立地对其正在处理的工作进行批处理，以便在任一阶段的单次前向传递中并行处理多个请求。

对于大多数工作负载，这是在单副本设置中支持并发请求的最重要的架构杠杆。

✕

解耦的 TTS 管道。多个文本请求进入阶段 0，其中 AR 阶段和代码预测器生成一系列编解码器帧。然后这些帧被流式传输到阶段 1 的 Code2Wav 解码器，该解码器跨请求并行地将它们转换为音频块。解耦设计意味着解码和生成可以同时运行：当一个请求的帧正在被解码为音频时，下一个请求已经在生成 token。

AR 阶段 CUDA 图与减少 GPU 到 CPU 同步

Talker（AR）阶段源自 Qwen3 LLM 主干。这意味着我们可以利用常见技术来提高基于 Transformer 的 LLM 的 TPS——特别是 CUDA 图优化。

为了利用 CUDA 图，我们首先以离线方式在各种并发设置下对模型进行了性能分析，以识别前向传递中关键点的常见张量形状。然后，这些统计数据用于确定在 vLLM 启动时要捕获的图大小，从而在预热后最小化内核启动序列的数量，同时保持较低的图内存开销。这显著加速了模型，尤其是在前向传递期间有许多内核启动的热路径上。

正如我们在上一节中概述的那样，拥有解耦设置有几个优点。然而，它从根本上引入了一个新的瓶颈：需要序列化并将结果从 Talker 阶段传输到解码器。在更高的并发度下，我们观察到 GPU 到 CPU 的传输和序列化在端到端生成时间中占据了越来越大的份额。

默认情况下，vLLM 使用一个专为通过 IPC 进行多 GPU 通信设计的后端，这本质上在进程之间引入了序列化边界，而在单个副本上运行时这是不必要的。通过切换到 vLLM 的 uniproc 执行器，特别是对于克隆用例，我们看到通过完全跳过序列化并保持在单个进程内，性能得到了显著提升。我们已将此更改回馈给了 vLLM OSS 社区，详见此处。

说话人嵌入缓存

Qwen3-TTS 帮助解锁的主要流程之一是零样本语音克隆。这涉及上传说话人的参考音频录音，通过说话人嵌入步骤进行处理，然后使用该嵌入来调节后续的语音生成。

我们发现客户通常有一组经常重复使用的语音，因此按请求重复上述嵌入过程会导致首次音频时间（TTFA）增加和吞吐量降低。通过使用内存中的 LRU 缓存，可以按说话人名称即时检索频繁重复使用的说话人嵌入，从而最大限度地减少克隆语音的首次音频时间。这有时可以在不需要额外微调的情况下，提供与微调语音相当的性能和质量。

动态帧累积

对于大多数现代 TTS 系统，延迟（首次音频时间，TTFA）和吞吐量（RTF）之间存在权衡。平衡两者的一个关键杠杆是在第一次解码步骤之前累积的音频帧数。

通过最小化这个数字，音频块以更频繁的间隔发送，但无法利用解码器级别的动态批处理。这意味着音频开始流式传输得更快，但解码器上下文有限，可能会损害韵律。

另一方面是增加帧累积，这为解码器提供了更丰富的上下文，但意味着在第一次音频生成之前，我们需要等待更长时间来累积更多帧。这具有更优的批处理机制，因为有一个更大的窗口可以将多个请求包含在同一次批处理解码调用中。结果是以更高的 TTFA 为代价提高了吞吐量。

为了兼顾低 TTFA 和高并发的优势，帧累积计数必须是动态的。我们使用较低的初始帧计数来最小化首次音频时间，然后为后续可以承受更高延迟界限的块增加帧数，以提高正在处理请求的利用率。

为 Qwen3-TTS 添加词级时间戳

对于语音代理用例，在中断发生之前实际说了什么对于自然对话至关重要。这通常需要在生成的音频上提供词级或字符级时间戳，以便可以将中断点映射回最后说出的词。

为了添加这个通常仅在第三方产品中可用的功能，我们将 Qwen3 Forced Aligner 作为后处理步骤集成到 Qwen3-TTS 的前向传递中，允许在同步和异步模式下发出时间戳。这使其成为需要稳健中断处理的端到端语音应用的可行选择。

进一步扩展：在您自己的语音上微调 Qwen3-TTS

使用 Qwen3-TTS，可以通过监督微调（SFT）微调新的语音。这通常需要预先提供较大量的参考音频示例（约 1 小时），但可以通过避免说话人嵌入预填充来实现更高的质量和语音相似度，同时甚至略微提升性能。

实际上，这意味着可以以开源的经济性生成高质量的自定义语音（例如，特定的口音、角色、品牌语音）。您可以在 Baseten 的训练平台上运行此操作，一旦微调完成，生成的 checkpoint 可以无缝接入 vLLM-Omni 服务栈，并立即受益于上述优化（我们有多个客户正是使用此工作流程微调和部署 Qwen3-TTS，我们很快将在我们的 ml-cookbook 中发布完整的微调配方！）。

我们优化后的 Qwen3-TTS 模型今天即可通过我们的模型库自助使用，支持流式传输和语音克隆用例。对于更高级或更大规模的用例，请联系我们进行讨论！