英伟达发布Audex 30B统一音频文本模型：MoE架构激活仅3B

英伟达推出Audex-30B-A3B统一音频-文本大模型，用MoE架构解决多模态扩展导致的文本能力退化问题，激活参数仅3B，同步开源2B小版本。

英伟达上个月挂在 arXiv 上的那篇论文——《Unified Audio Intelligence Without Regressing on Text Intelligence》——现在有了正式产品：Nemotron-Labs-Audex-30B-A3B。这是一个总参数 30B、激活参数 3B 的音频-文本统一大模型，同时英伟达还顺手在 Hugging Face 上放了一个 2B 的小版本，方便社区跑起来。

如果你熟悉多模态领域这两年的踩坑史，就知道 Audex 想解决的问题不新鲜——给一个纯文本模型接上音频/语音模态之后，文本能力往往会掉一大截。业内的常规做法要么是拿一个纯文本 LLM 加音频 adapter 硬调，要么干脆重新预训练一个 omni 模型，前者音频差，后者文本掉分。Audex 的路子是：文本骨干不动，把音频编码后映射到文本嵌入空间，再让量化后的音频输出 token 和文本 token 走同一条推理链路。

Audex 模型架构示意图，展示 AF-Whisper 编码器、Mamba-Transformer 骨干和 X-Codec 输出层

架构：Mamba-Transformer 混合 + MoE

Audex 的骨干是英伟达自家的 Nemotron-Cascade-2-30B-A3B，一个 52 层的 Mamba-Transformer 混合结构，里面塞了 128 个可路由专家，每次前向激活 6 个。这套路数跟英伟达前段时间发的 Nemotron 3 Nano Omni 一脉相承，属于 NV 现在押注的技术路线——Mamba 处理长序列有天然优势，音频这种每秒几十上百个 token 的模态，跟它简直是天作之合。

音频输入这边用的是 AF-Whisper 编码器，处理 16kHz 采样的输入，中间挂两层 MLP 适配器把音频特征映射进文本嵌入空间。词表也做了扩容，从原始的 131072 个 token 扩展到 205312 个，多出来的那 7 万多 token 就是留给音频的离散化表示。

输出侧英伟达把语音和非语音音频拆成两条路：

语音输出用的是 X-Codec2，速率 50 tokens/秒，单层 finite scalar quantization（有限标量量化），码本大小 65536
非语音音频（音效、音乐、环境音之类）用的是 X-Codec，速率 200 tokens/秒，4 层展平残差向量量化

这个分工挺讲究的。语音信号的信息密度低、结构规整，50 tokens/秒 + 单层 FSQ 够用；而通用音频信号复杂度高得多，得上残差矢量量化才能保住细节。很多把语音和音频混着搞的模型在这里一刀切，结果两头都不讨好。

关键问题：文本能力真的没掉？

这是 Audex 论文最想证明的点，也是最容易被质疑的点。看跑分：

| 评测集 | Audex-30B-A3B | 骨干模型 | |---|---|---| | MMLU-Redux | 86.4 | 86.3 | | IMO AnswerBench | 81.1 | 79.3 | | MMLU-Pro | 略降 | - | | GPQA-Diamond | 略降 | - |

结论是"基本持平，个别项目还涨了一点"。MMLU-Redux 和 IMO AnswerBench 上甚至超过了纯文本骨干，这个不算意外——扩展词表和多模态训练本身就是一种正则化，能带来些许 side effect。但 MMLU-Pro 和 GPQA-Diamond 掉了一些，说明在需要重推理的硬核任务上，音频训练还是引入了轻微干扰。

这个 tradeoff 在能接受范围内。对比 Qwen3-Omni 这种 omni 路线的选手，Audex 走的是"保文本、加音频"的稳健派，Qwen3-Omni 强调的是 ASR 和语音对话逼近 Gemini 2.5 Pro 的水平。两家目标其实不太一样：一个想做全能通用底座，一个想做音频交互专家。

3B 激活参数的实用价值

30B 总参数只激活 3B，意味着推理成本接近一个 3B 稠密模型的水平，但知识容量是 30B 的。对于音频这种典型的"实时性要求高、上下文长"的场景，这个配比很关键——你没法接受用户说完一句话，模型思考三秒才开始回应。

英伟达同步开源的 Audex-2B 版本走的是同一套 recipe，主要针对端侧和边缘场景。Hugging Face 上放了完整的 Transformers、vLLM、SGLang 和 Docker Model Runner 的使用示例，vLLM 部署直接一行命令：

python3 -m pip install \"vllm[audio]\"
vllm serve nvidia/Nemotron-Labs-Audex-2B

2B 版本支持的任务列表挺全：音频理解、语音识别、语音翻译、TTS、音频生成、S2S（语音到语音）生成。这个覆盖度基本能撑起一个语音助手产品所需的全部后端能力。

跟 NV 自家 Nemotron 3 Nano Omni 什么关系？

英伟达前几个月发的 Nemotron 3 Nano Omni 30B-A3B 已经是一个视频+音频+图像+文本的四模态统一模型。Audex 看起来像是从 Omni 家族里把音频部分单独拎出来做深做透——毕竟对于纯语音交互场景，视频和图像模态是累赘，模型专门优化音频路径能拿到更好的效果。

Omni 走的是"一个模型端到端替代智能体链"的路线，Audex 走的是"专精音频、保留文本"的路线。这两条路都是 MoE 架构，都基于同一套 Nemotron-Cascade 骨干，看得出英伟达在系统性地推进模态融合，思路是先把文本底座打扎实，再逐个模态往上叠。

一些技术细节值得展开

音频 token 化的粒度选择：语音 50 tokens/秒 vs 音频 200 tokens/秒，这个 4 倍的差距对训练效率影响很大。如果统一用 200 tokens/秒，语音训练成本会平白多出 4 倍；如果统一用 50 tokens/秒，通用音频质量会崩。Audex 用两套码本的做法虽然增加了工程复杂度，但从投入产出比看是对的。

词表扩展的做法：从 131072 扩到 205312，多出来的 74240 个 token 分配给了两种音频编解码器。这里有个隐藏成本——embedding 层和输出 head 的参数量都会跟着涨。在 30B 规模下这点开销不算什么，但如果要做到 100B+ 规模，词表膨胀带来的显存压力会开始显著。

Mamba-Transformer 对音频的天然亲和：音频序列长、局部相关性强，Mamba 的状态空间模型比纯 attention 在长音频推理时的显存占用低得多。英伟达选择这个骨干不是随便挑的，配合 MoE 稀疏激活，这套组合拳在音频推理场景下的吞吐会明显高于同参数量的稠密 Transformer。

谁应该关心这个模型

做语音助手/客服的团队：Audex 的 S2S 能力和保留下来的文本智能是刚需组合，你既需要它听懂问题、给出准确答复，又需要它用自然语音说出来
做播客/音频内容生成的：X-Codec 那条路径专门处理非语音音频，理论上可以生成音效、简单音乐段落
做多语言语音场景的：论文强调了语音翻译能力，虽然覆盖语种没有 Qwen3-Omni 的 119 种那么夸张，但英伟达一贯的英语和主要语种质量应该有保障

目前 30B 版本的权重还没在 Hugging Face 上完全放出，2B 版本已经可下载（62.2k 关注量，社区反应挺热）。OpenAI Hub 已经在关注 Audex 系列的接入进度，等 30B 版本权重开放后会第一时间跟进，届时通过统一 API 就能直接调用，不用自己折腾 vLLM 和音频编解码环境。

一点判断

Audex 这篇论文最有价值的贡献不是把音频加进 LLM——这事儿谁都在做——而是用数据证明了"保留文本能力"是可以做到的。过去一年多模态领域太多"我们加了音频/视觉/视频，评测跑分只掉了几个点"的说辞，Audex 至少在几个主流文本 benchmark 上真的做到了不掉分甚至微涨。

对开发者来说，这意味着未来你不再需要在"文本强的模型"和"能听会说的模型"之间做选择。虽然 GPQA-Diamond 这种硬推理任务上还是有点损失，但对绝大多数产品场景，Audex 这种 tradeoff 是能接受的。

英伟达最近在开源模型上的节奏明显加快，从 Nemotron-Cascade 到 Nano Omni 再到 Audex，产品线已经形成了一个完整的模态矩阵。在闭源大厂普遍收紧开源的当下，NV 反其道行之，把 SOTA 级别的模型直接开出来——大概率还是那个老逻辑：模型开源没关系，反正推理都得跑在自家 GPU 上。