在 NVIDIA，#TeamGreen 最近深入探索了语音 AI 领域，聚焦于三个关键要点，旨在让开发者能够构建低延迟、高性能的语音代理。我们不仅发布了完全开源的模型权重与训练秘诀，还推出了一个名为 Magpie TTS 的文本转语音框架。
在介绍 Magpie 之前，先来看看我们构建的语音代理方案，它由三个核心部分组成：
- 一个低延迟的 ASR（自动语音识别） 模型
- 一个能处理元指令或上下文信息，并基于语音输入做出反应的 LLM（大语言模型）
- 一个低延迟的 TTS（文本转语音） 模型
将所有这些模型串联起来，并控制延迟，是个不小的挑战。因此，我们决定为每一部分都构建自己的解决方案，并对速度进行高度优化。
第一部分：NVIDIA FastConformer 流式 ASR
对于识别部分，我们依赖于 FastConformer，这是由 NVIDIA 内部开发的最先进的 ASR 架构，在多个语言中表现出色。它本身是一个完全卷积的模型，因此运行速度非常快。我们将其调整为流式模式，这种模式下延迟更低，可以在音频输入的同时获取逐词的文本输出。为此，我们将解码器改为缓存感知的流式解码，该解码器能以音频块的粒度输出词块。
这种方法使得我们在处理流式音频时，可以像处理非流式音频一样获得词元输出！但还有更多工作要做，因为通常来说，流式 ASR 的准确率低于非流式 ASR。为了让流式 ASR 达到与非流式相当的准确率，我们还在训练过程中使用了知识蒸馏，将非流式教师模型的知识传授给流式学生模型。最终，我们在五种语言（英语、西班牙语、德语、法语、中文）上训练了这些模型，并全部以CC-BY 4.0许可证发布在 Hugging Face Hub 上：
此外，为了让语音代理达到最低延迟，我们不希望依赖任何云端 API，因此你需要在本地运行这些模型。虽然有些大型模型可能不适用，但 1.1B 参数的模型可以在 RTX 4090 等现代硬件上轻松运行，从而实现超快且完全免费的推理。
我们还在 ai.nvidia.com 上提供了这些流式模型的 NVIDIA NIM 微服务 API，可以在试用并对比它们的速度。
现在，我们有了一个快速准确的 ASR 模型，接下来是…
第二部分：LLM 与大语言模型
这部分可以按需选择。你可以使用本地模型，比如最近的 Llama 和 DeepSeek 版本，它们都表现优异，也可以使用云端 API，这取决于你的延迟要求。
第三部分：Magpie TTS
在语音代理的另一端，我们需要一个 TTS（文本转语音）引擎。这个引擎必须满足：
- 极致的高质量。语音是表达的中心，如果质量不高，人们就不太愿意与你的代理交谈。
- 低延迟。让用户等待回应的对话系统是令人沮丧的。
- 本地运行。我们不希望为每个发出的词元都调用付费 API 服务。
- 可控性。为了创建品牌化的语音代理体验，控制音高、语速、情感等副语言信息至关重要。
因此，我们决定从头构建一个全新的 TTS 系统，命名为 Magpie TTS。在 NVIDIA，我们倾向于以鸟类命名 TTS 模型！我们的上一个 TTS 引擎是 RAD-TTS 和 P-Flow。
Magpie TTS 是围绕两个子模型构建的，通过两种运行模式（因子分解模式与单阶段模式）协同工作：
- AR（自回归） Transformer 解码器，用于生成声学信息。
- 非自回归（NAR） 流匹配解码器。
因子分解模式
在这种双阶段模式下，AR 解码器以自回归方式预测关键声学特征（如基频 F0 曲线、能量、持续时间和激发信息）。然后，NAR 解码器以此作为条件，用流匹配一次性生成所有的 MEL 频谱图帧。这种方式速度极快，并且可以根据你的特定需求，在质量与速度之间做出权衡。
简单来说，AR 解码器处理的是人类语言难以捕捉的“无法书写”的维度（如同一个指挥家），而 NAR 解码器则基于这些信息一次性生成最终的音频表示（如同一个演奏家）。
单阶段模式
在这种模式下，AR 解码器独自承担所有工作，直接以自回归方式生成预训练的音频编码。这在延迟上表现更优，可能适合更快的响应场景。
我们会在后续的博文中介绍更多关于 Magpie 的技术细节，并提供其检查点。敬请关注！
语音代理基准测试
我们将所有模型串联起来，构建了一个语音代理，并在零样本语音对话数据集（日常对话场景，即人们以自然口语闲聊而不是阅读书面文本）上进行了性能基准测试。结果如下：
| 模型套件 |
模型名称 |
WER ↓ |
延迟 |
类型 |
| Whisper |
openai/whisper-large-v3-turbo |
24.48 |
0.97 |
非流式 |
| Canary |
nvidia/canary-1b |
23.63 |
0.54 |
非流式 |
| Parakeet |
nvidia/parakeet-rnnt-1.1b |
19.95 |
0.31 |
非流式 |
| NVIDIA 代理 |
Parakeet 1.1B 流式 + Magpie TTS |
21.72 |
0.16 |
流式 |
表格中的 WER（词错误率） 越低越好，延迟则是从音频输入到生成首个文本词元以及首个 TTS 输出的端到端时间，单位为秒。
如上所示，在零样本日常对话语音识别和合成任务中，我们的流式系统组合在延迟显著降低（快了 6 倍）的情况下，WER 接近非流式系统的顶级水平。
支持状态
- ASR 模型：五种语言的流式 Parakeet 检查点已在 Hugging Face Hub 上以 CC-BY 4.0 许可证发布，可商用。
- Magpie TTS：检查点即将发布，敬请关注后续博文。
- 基准测试数据集：我们正积极考虑在未来发布所使用基准测试的一个子集，以推动语音代理评估的发展。
快速入门
要体验流式 ASR，只需在本地机器上安装 NVIDIA NeMo 工具包或 transformers 库，它都能无缝兼容，因为它是一个标准的 Hugging Face 模型。
pip install nemo_toolkit['asr']
然后：
import nemo.collections.asr as nemo_asr
asr_model = nemo_asr.models.ASRModel.from_pretrained("nvidia/parakeet-rnnt-1.1b-streaming")
print(asr_model.transcribe(["path/to/audio.wav"]))
或者使用 Hugging Face transformers：
from transformers import pipeline
transcriber = pipeline("automatic-speech-recognition", model="nvidia/parakeet-rnnt-1.1b-streaming")
print(transcriber("path/to/audio.wav"))
以上只是 ASR 部分的快速体验。待 Magpie TTS 检查点和完整解决方案发布后，将会有更详细的教程和端到端的示例代码。
技术栈
- ASR 架构：FastConformer 流式 Transducer（基于知识蒸馏优化）
- ASR 训练框架：NVIDIA NeMo
- TTS 架构：Magpie TTS（自回归 Transformer + 流匹配解码器）
- 推理与优化：支持本地 GPU 上的高速推理，兼容 Hugging Face 生态
下一步计划
我们还将发布一系列博文，深入探讨 Magpie TTS 的训练细节、架构选择，以及如何微调或定制语音风格以适用于特定品牌和应用。我们会同步推出更多语言的模型，以及针对不同延迟和质量要求的变体。
我们的最终目标是让所有人都能轻松构建完全本地化、低延迟、多语言的语音代理，无需依赖昂贵的 API。如果你对这些模型有任何问题，或者想分享你构建的应用，欢迎在社区论坛或 NVIDIA 开发者社区联系我们。
感谢阅读，敬请期待更多音频 AI 的更新！
构建低延迟多语言语音代理：利用 NVIDIA Magpie TTS 实现开源权重与完全部署控制
企业 + 文章 发布于 2026年8月10日 顶 8
每一次语音交互都有一个延迟预算。
当用户听到你的应用程序做出回应时，你已经消耗了宝贵的毫秒来捕获音频、转录语音、运行大型语言模型（LLM）、检索上下文并生成响应。文本转语音（TTS）是最后一步——也是用户最容易感知的一步。如果语音生成缓慢，整个体验都会显得迟钝。
你能亲自运行和调优的流水线环节越多，就能从延迟预算中夺回越多的时间。
语音人工智能正飞速发展。集成的语音模型提供了简便性——一次 API 调用，音频输入，音频输出——但它们牺牲了为你的领域微调每个组件、在更优模型发布时进行替换、强制执行数据驻留以及准确了解延迟来源的能力。为了获得更强的控制力，级联架构——将专门构建的 ASR（自动语音识别）、TTS（文本转语音）和 LLM（大型语言模型）组件组合运行——可以让你独立调优每一层，并将其部署在你自有的基础设施上。
NVIDIA Magpie 多语言 TTS 正是为此而生。凭借开源权重、生产就绪的 NVIDIA NIM 以及对 12 种语言的支持，你可以在自己的基础设施内部署多语言语音，针对你的工作负载优化延迟，并针对你的领域定制模型——在自己的环境中实现端到端的全程控制。
最新版本扩展了多语言覆盖范围，新增了现代标准阿拉伯语、韩语和巴西葡萄牙语，同时通过更新的训练数据和模型改进，提升了多种现有语言的质量。
无论你是在构建客户支持代理、医疗保健助手、企业副驾驶、翻译系统还是对话式人工智能应用，Magpie 都为生产级语音人工智能提供了一个开放的基础。
语音 AI 正迈向默认多语言时代
如今的语音应用绝不仅服务于单语场景。
全球客户支持、企业助理、医疗文档记录、零售自动化以及翻译工作流，越来越需要跨多种语言的自然对话——同时还要保持低延迟。
支持更多语言只是挑战的一部分。开发者还需要具备以下能力：
- 在数据所在位置进行部署
- 满足企业隐私要求
- 自定义发音和声音
- 预测生产工作负载下的延迟
- 在自己的基础设施上进行扩展
开放模型正在改变上述每一项的可能性。
一个开放模型，覆盖十二种语言
Magpie TTS（文本转语音）多语言版是一个拥有 3.64 亿参数的开源权重模型，支持以下语言：
英语 · 西班牙语 · 法语 · 德语 · 意大利语 · 越南语 · 普通话 · 印地语 · 日语 · 现代标准阿拉伯语（新增） · 韩语（新增） · 巴西葡萄牙语（新增）
每种语言都通过共享的多语言说话人表征，提供男声和女声选项。
此次发布还通过扩展对印地语和日语的语码转换（code-switching）支持，提升了多语言灵活性。这借助了 IPA（国际音标）形素到音素的处理过程以及自定义发音词典实现——从而能更准确地念出姓名、技术术语和混合语言内容。
开发者无需为不同地区维护独立的 TTS 模型，只需在单一开放基础上即可构建多语言应用。
用户真正能感知到的延迟
在对话式 AI 中，文本转语音是用户听到回复前的最后阶段。这使得“首个音频生成时间（Time to First Audio, TTFA）”——即从语音生成开始到第一个音频片段抵达用户之间的延迟——成为语音管线中最重要的延迟指标之一。
由于 Magpie TTS 可部署在你自己的环境中，你测量到的延迟就是你能实际控制的服务器端延迟，不包含任何托管服务的往返时间。
| GPU |
单流 TTFA |
单流 RTFX |
64 流 TTFA |
64 流 RTFX |
| B200 |
32 ms |
12.1× |
239 ms |
319.81× |
| H100 |
47 ms |
14.7× |
275 ms |
290.79× |
| DGX Spark |
53 ms |
9.8× |
962 ms |
75.88× |
| A100 |
79 ms |
12.2× |
395 ms |
197× |
来源：NVIDIA TTS NIM 性能文档（v26.07），基于本地部署环境三次试验取平均值。
TTFA = 首个音频生成延迟；RTFX = 吞吐量（实时时间的倍数）。
在 B200 上达到 32ms 的 TTFA 时，Magpie 为自动语音识别（ASR）和大型语言模型（LLM）处理留出了充足的延迟预算——将端到端总延迟控制在自然对话所要求的 200ms 窗口内。在各类 NVIDIA GPU 上，Magpie 单流能在 32–79ms 内生成首个音频。在 64 个并发流下，B200 可实现 239ms 的 TTFA，同时提供 320 倍于实时时间的吞吐量——即使面对并发负载，音频生成速度仍是回放速度的 300 多倍。
上表展示了以 NVIDIA NIM（NVIDIA 推理微服务）形式提供服务的 Magpie 在本地环境中的测量结果——该优化容器运行在你自己的 GPU 上。开放的 Hugging Face 检查点（checkpoint）为同一模型，是你用于研究和微调的途径；NIM 则是经过调优的推理服务栈，可产生上述生产级延迟。两者均在你可控制的硬件上运行。
由于模型在你自己的基础设施上运行，你可以直接对性能进行基准测试，根据部署需求进行调优，并按工作负载进行扩展。对于实时语音代理而言，这正是响应灵敏的对话与感觉有延迟的对话之间的区别所在。
实时语音生成优化设计
低延迟并非偶然。Magpie 引入了两项互补架构改进，在保持语音质量的同时降低推理耗时。
帧堆叠
解码器在每一步解码时预测两个音频帧，而非一帧。此举将解码迭代次数减半，缩短生成时间并提升吞吐量。
局部 Transformer
单纯的帧堆叠会引入同时生成的码本标记之间的依赖关系，从而降低音频质量。局部 Transformer 对这些依赖关系建模并精炼生成的音频，恢复帧堆叠可能付出的质量代价。
二者结合，实现更快的生成速度与自然的语音合成。相关架构详见论文 Frame-Stacked Local Transformers for Efficient Multi-Codebook Speech Generation（ICASSP 2026）。
