Baseten 解析 Gradium TTS 如何实现快于人类响应的实时语音合成

Baseten 工程博客·2026-10-13 21:32· 1 小时前AI 评分58

用 Gradium 实现实时文本转语音

AI 导读

Baseten 工程博客解析 Gradium TTS 如何实现实时语音合成，Coval 基准测得其 TTFA 中位数为 155 ms，四分位距仅 2 ms。

正文

Gradium TTS：TTFA 快于人类语音

Gradium 的文本转语音（TTS）模型可将书面文本转换为语音音频，专为实时 AI 语音代理交互而设计。

首音频时间（TTFA）衡量的是从发送 TTS 请求到收到首个可播放音频之间的时长。它对于自然流畅的对话至关重要。

为实现可靠自然的对话，Gradium TTS 的 TTFA 快于人类语音响应时间。

Gradium 延迟竞赛演示

亲自体验 TTS 延迟竞赛演示并访问其代码仓库 here。

独立的 Coval 基准测试将 Gradium TTS 归入快于人类语音的层级，让语音代理有时间进行推理或检索上下文，而不会打断对话流。在 Coval TTS 基准测试中（数据采集于 2026 年 5 月 4 日），Gradium TTS 的 TTFA 中位数为 155 ms，四分位距仅为 2 ms，波动范围之小足以让开发者在流水线其余环节设定可靠的延迟预算。

Gradium 的 TTS 不会等待整句话

Gradium TTS 是流式的：它可以在上游文本生成器（如 LLM）尚未完成完整响应之前就开始说话。具体而言，Gradium 的模型采用延迟流建模（DSM），这是由 Kyutai 开发的框架，将文本和音频视为在共享时钟上运行的两条并行流，因此音频可以在文本尚未完全到达之前生成。

两条流对齐到相同的帧率，每 80 ms 一步，因此模型可以在文本到达时生成音频。DSM 的核心思想是音频流比文本落后几步，让模型得以窥见接下来的内容，类似于人类说话者根据即将说出的词语调整语气、语调与节奏。延迟越长，模型获得的上下文越多，语音质量越好；延迟越短，则延迟越低。

音频输出以经过调优的解码步数跟随文本

Delayed Streams Modeling aligns text and audio to a shared 80 ms clock and runs the audio stream a fixed number of steps behind the text, so each audio frame is generated with the next few words already in view. 延迟流建模将文本和音频对齐到共享的 80 ms 时钟，并让音频流固定落后文本若干步，因此每个音频帧生成时，接下来的几个词已在视野之中。

Gradium TTS 在生成最初几个 token 后就开始说话，而非等待完整 token 生成。该模型的设计还使每个 80 ms 帧的生成保持快速，从而在语音开始后维持低延迟。

每个 80 ms 音频帧是如何构建的

音频流中的每一步由两个角色不同的 transformer 生成：

时序 transformer（“读者”）：逐步遍历各条流，接收最新的文本 token 和上一音频帧。它生成一个向量，描述下一音频帧应有的声音，并在准备好接收下一个词时发出信号，从而在文本不均匀到达时保持语音的自然节奏。
深度变换器（“精炼器”）：将该向量转换为一个音频帧。每一帧被编码为最多 32 个 token，其排列方式使得第一个 token 捕获最重要的特征，后续每个 token 添加更精细的细节。精炼器按此顺序生成它们，因此每一帧都会随着每个 token 的生成而变得更加精确。

一次大规模读取，一个小型精炼循环

Within each 80 ms step, the temporal transformer reads the newest text token and the previous audio frame and produces a single summary vector. The depth transformer then generates the frame's audio tokens one at a time, coarse to fine. 在每个 80 毫秒的步骤内，时间变换器读取最新的文本 token 和上一个音频帧，并生成一个单一的摘要向量。然后深度变换器逐个生成该帧的音频 token，从粗到细。

这种拆分实现了 Gradium TTS 的低 TTFA。较大的时间变换器需要跟踪上下文，每个步骤只运行一次；而较小的深度变换器每个步骤最多运行 32 次，但由于它从不回溯时间，因此成本很低。这些多次小型精炼器传递还受益于额外的 GPU 优化。

专门针对更小、延迟优化的模型进行 GPU 优化

GPU 为 AI 模型执行繁重的计算，但它们并非独自工作。CPU 充当调度器，对于每个计算步骤，它选择正确的 GPU 内核、准备其输入并发出启动命令。每一次这样的交接都会花费少量固定时间。

在大型语言模型中，GPU 是瓶颈，每个 GPU 内核运行时间足够长，以至于 CPU 可以在当前内核完成之前排队下一次启动。然而，在流式 TTS 等较小的 AI 模型中，GPU 内核完成的速度比 CPU 排队它们的速度更快。结果，CPU 成为延迟瓶颈，导致 GPU 利用率降低。

Gradium 通过两种方式应对这一挑战：

内核融合：使用 torch.compile 和 Triton，Gradium 将以前需要多次单独 GPU 内核启动的操作合并为一个内核，因此每次启动做更多的工作。
CUDA 图：前向步骤的完整内核序列被记录一次。在随后的每一步中，CPU 发出单个重放命令，GPU 驱动程序连续运行整个记录的序列，而不是等待每个内核单独启动。

典型内核启动与 CUDA 图重放对比

With CUDA Graphs, the CPU issues one replay command and the recorded kernel sequence runs back-to-back, reducing TTFA. 使用 CUDA 图，CPU 发出一个重放命令，记录的核序列连续运行，从而减少 TTFA。

在 Gradium 公布的基准测试中，启用 CUDA 图在小批量大小下将中位 TTFA 降低了 2.5 倍以上。

在 Baseten 上扩展 Gradium TTS

语音 AI 应用的流量往往具有突发性。在营业时间开始时以及停电或营销活动等触发事件期间需求很高。所需的并发量可能在几分钟内上升和下降，因此为峰值配置会让 GPU 在一天中的大部分时间处于空闲状态，而为平均值配置则会在每次峰值的头几分钟内降低性能。

自动扩缩容解决了这个问题，但新副本在模型权重加载到 GPU 内存之前无法处理调用。权重通常从 Hugging Face 或 S3 等上游源拉取，其中速率限制和跨区域延迟会进一步延长冷启动时间，尤其是当许多副本同时请求相同文件时。

Baseten 交付网络（BDN）通过三种方式减少冷启动时间：

推送时镜像：部署时，BDN 将模型的权重复制到 Baseten 管理的存储中，并记录一份内容哈希清单。上游只被访问一次；此后的每次冷启动都从 Baseten 自己的存储读取。
三级缓存：每个 GPU 节点先检查节点本地 NVMe 磁盘，然后是集群内对等缓存，最后是镜像源，以超过 2 GB/s 的速度将权重交付到 H100 节点。
协同下载：在突发期间，模型的每个分块由单个节点从源拉取，并通过集群内网络与对等节点共享，因此 50 副本扩容时源带宽为模型大小的 1 倍，而非 50 倍。

BDN 如何在扩容期间将模型拉入集群

In a cold cluster, each node fetches only its assigned chunks from origin, so total origin bandwidth equals one copy of the model regardless of how many replicas are starting. In a warm cluster, a node assembles the file from peers over the in-cluster network without touching origin at all. 在冷集群中，每个节点只从源获取分配给自己的分块，因此无论有多少副本正在启动，源带宽总量都等于模型的一份副本。在热集群中，节点通过集群内网络从对等节点组装文件，完全不接触源。

来源：Baseten 交付网络（BDN）如何让冷启动变快。

由于权重在模型容器启动之前就已到达，传输也发生在计费 GPU 窗口之外。结果是冷启动速度提升 2–3 倍，因此 Baseten 上的 Gradium TTS 部署可以跟上调用量的突然波动，而无需让客户等待冷副本。Gradium 让每次交互都快速，而 Baseten 让这种性能随着流量涨落始终可用。

Gradium TTS 可作为 Baseten 上的专用部署使用。立即试用，在您自己的工作负载上体验这些优势。

来源：Baseten 工程博客 · baseten.co