8 月 21 日，小红书 Super Intelligence 基础算法实验室（FireRedTeam）开源 FireRedAudio。这个 9B 参数的通用音频语言模型，用"理解与生成解耦"的设计，把语音识别、音频理解、语音合成、语音编辑和长音频分析全部装进了一个模型。
音频 AI 的现状，可以用一个字概括：碎。
语音识别要一个模型，语音合成要另一个模型，语音编辑还要第三个；理解一段录音里的内容是一个任务，把文字变成语音是另一个任务，想在录音里改掉一句话又是新的任务。做音频产品的团队，往往要同时维护好几套系统，每个系统都有自己的接口、自己的部署方式、自己的维护成本。更麻烦的是，不同系统之间的配合还会引入误差——识别结果转给合成模块，合成模块再转给编辑模块，每一次转换都是一次信息损耗。
这两年，业界一直在尝试用"统一模型"解决这个问题：图像领域有统一多模态模型，语音领域也有不少团队把理解与生成往一个模型里塞。但塞法很关键。如果只是把几套旧模块用适配器拼在一起，那只是"拼装式统一"，信息仍然在不同表征之间来回翻译；真正的问题是，理解和生成对音频表征的要求天然不同，强行共用一套表征，两边都做不好。
小红书 FireRedTeam 这次开源的 FireRedAudio，给出的答案是"解耦统一"：理解与生成各用各的音频表征，共享同一个语言模型大脑。它把"听、理解、推理、说、编辑"五件事装进了一个 9B 参数的模型：既能做 ASR 语音识别，也能做音频理解问答；既能零样本克隆声音、按指令合成语音，也能直接修改一段录音里的内容和声学表现；甚至还能理解长达一小时的录音，并精确对应到每一句话的时间位置。
解耦表征架构
FireRedAudio 的核心设计思路，是"理解与生成各用各的表征，但共享同一个大脑"。
为什么需要解耦？因为理解和生成对音频表征的要求本质上是矛盾的。理解任务需要的是"语义层面"的信息——这句话说了什么、什么语气、谁在说话；而生成任务需要的是"像素级"的细节——声音的质感、音色、呼吸、停顿，任何一个细节丢了，合成出来的声音就不自然。过去很多统一模型强行让两套任务共用一套表征，结果往往是理解不够准，生成也不够好。
FireRedAudio 的做法是双通路：音频编码器（Audio Encoder）负责理解，初始化自 OpenAI 的 Whisper-large-v3，专门提取适合识别和推理的信息；RedAE 通路负责生成，用 flow-matching 的扩散 Transformer 从连续隐变量直接重建语音。两条通路表征彼此独立，但共享同一个 9B 参数的语言模型底座——语言和推理能力是共用的，音频的表征是各干各的。官方称这是同类统一音频语言模型中首个公开的解耦设计。
底座方面，语言模型基于 Qwen3.5，让模型继承了强壮的指令遵循和推理能力；语音生成部分则沿用了 FireRedTeam 在语音合成上的积累。换句话说，这是一个"大模型打底、专业模块分工"的架构，兼顾了通用性和专业性。
一个模型五种任务
FireRedAudio 支持的任务可以分成五类：
第一类是语音识别（ASR），把音频转成文字，也是唯一支持多语言的任务。第二类是音频理解，给模型一段音频加一个问题，它就能回答——支持说话人识别、音效理解，还能开启思维链（CoT）先推理再作答。第三类是零样本语音合成，给一段参考音频和它的文字稿，就能克隆出这个声音念任意文本。第四类是指令语音合成，不需要参考音频，用一段音色描述就能"设计"出声音来。
第五类是语音编辑，也是最有意思的一个：给一段已有的录音，你可以让它删除、替换或插入某句话（语义编辑），也可以直接调整音高、语速、音量（声学编辑）。不需要重新录制，不需要专业音频软件，一句指令就改完了。
这五类任务共享同一个推理入口和同一套权重——同一个模型根据输入与指令完成不同任务：给它音频和转写指令它就做 ASR，给它参考声音和文本它就做合成，给它录音和编辑指令它就改语音。对开发者来说，这意味着一个接口、一次部署，就能覆盖绝大多数音频需求。
上手指南
FireRedAudio 的部署不算复杂。环境要求 Python 3.10 和 uv 包管理器，需要 CUDA 工具链（要编译 causal-conv1d 和 flash-attn 内核）以及 ffmpeg，预编译轮子默认面向 CUDA 12.8。权重可以从 Hugging Face 或 ModelScope 下载，国内用户走 ModelScope 会快很多。
Python API 的使用很直观。初始化引擎后，理解类任务只需要主模型权重，生成类任务（TTS、编辑、声音设计）额外加载 RedAE 解码器：
engine = FireRedAudioInference(
model_path="pretrained_models/FireRedAudio",
vae_decoder_path="pretrained_models/RedAE_decoder/model.pt",
device="cuda:0",
)
# ASR
res = engine.understand("asr_zh.wav", "Transcribe speech to text.", task="asr")
# 零样本 TTS：参考音频 + 文字稿，克隆音色
res = engine.tts(
prompt_text="同时，他强调微调要科学有序。",
prompt_audio="tts_zh_prompt.wav",
target_text="安徽淮南秦师傅发现，停在小区的爱车右前驾驶窗玻璃被砸。",
language="zh",
)
命令行的用法同样是一行一条任务，--task 参数切换 asr / understand / tts / edit / voice_design。官方示例音频都是中文，开箱即可体验。如果你的显卡显存有限，也可以只加载主模型做理解类任务，生成类任务按需再挂 RedAE 解码器。
音频理解领先
FireRedAudio 在音频理解上的成绩单，是这次开源最亮眼的部分。在 MMAU 基准（覆盖音乐、音效、语音等多类音频的理解评测）上，FireRedAudio 的 test-mini 得分 82.0、test 得分 80.9；在 MMSU 基准上得分 83.3——三项全部领先。
对比着看更直观：Gemini 3.1 Pro 三项得分是 80.7、78.8、82.7，Qwen3.5-Omni-Plus 是 81.4、79.9、80.7。FireRedAudio 用 9B 的开源模型，在音频理解上压过了这些商用大模型。这也印证了"解耦表征"的价值：理解通路专注语义提取，没有被生成任务拖后腿。
ASR 方面同样能打：在 LibriSpeech clean 上字错误率低至 0.67，FLEURS-102 多语言平均 14.94，优于 Gemini 3.1 Pro 的 18.23 和 Qwen3.5-Omni-Plus 的 23.66。AISHELL-1 中文普通话测试 0.71，与专用 ASR 模型在同一水平线上。
理解能力强的另一个好处是实用场景广。会议录音里"第二个人提到的项目截止日期是什么"，播客里"这位嘉宾对 AI 的态度前后有没有变化"，这类需要跨片段整合信息的提问，正是 FireRedAudio 这类音频理解模型的主场。配合思维链功能，它还能先输出推理过程再给结论，回答的可靠性比直接作答高不少。
语音合成与指令
语音合成是 FireRedAudio 的另一条主线。在 Seed-TTS-Eval 零样本 TTS 评测上，它的平均 CER/WER 只有 1.20，是榜单上所有对比模型里最低的——低于自家此前的 FireRedTTS-2（1.55），也低于 Seed-TTS 本身（1.69）、DiTAR（1.36）和 CosyVoice 3（1.67）。音色相似度 SIM 0.71，同样处于前列。
指令 TTS（按指令设计声音）的表现更突出。官方在自测基准上，FireRedAudio 中文三项指标（APS 86.0、DSD 84.1、RP 70.1）和英文三项（81.1、83.6、70.3）全部第一，超过 Qwen3-TTS-VD 和 Ming-Omni-TTS-16B。也就是说，用"清亮的年轻女声、语速稍快、带点急切"这类描述，就能直接合成出符合要求的声音。
直接修改录音
语音编辑是 FireRedAudio 区别于大多数 TTS 模型的独有能力，分为语义编辑和声学编辑两层。
语义编辑针对"说了什么"：可以删除某句话、替换某个词、插入新内容。模型的处理方式是先把改后的文本写出来（用特殊的开始/结束标记），再渲染成音频——相当于"想清楚再开口"。在语义编辑基准上与 Ming-UniAudio-Edit 对比，FireRedAudio 的替换任务准确率（ACC）中英文分别达到 90.15 和 76.95，明显高于对方的 76.62 和 65.62；删除任务的开放式场景下，字错误率从 22.92 降到 10.49。
声学编辑针对"怎么说的"：调整音高、语速和音量，不需要重新录音。比如"把这句话语速调慢""音高升 3 个台阶"。在音量调整任务上，FireRedAudio 的相对幅度误差（RAE）只有 2.39，而对比模型是 14.90。需要留意的是，声学编辑的指令必须使用官方训练过的固定模板（音高 -6 到 +6 步、语速 0.5 到 2.0、音量 0.3 到 2.0），不是自由对话式的表述。
这两层编辑组合起来，基本覆盖了音频后期最常见的需求：播客录错了词不用重录，替换掉就行；短视频配音想换个节奏，调语速就行；访谈里某段内容敏感，删除即可。对内容生产团队来说，这等于把一部分后期工作从专业软件里解放了出来。
一小时长音频
大多数音频模型只能处理 30 秒到 1 分钟的片段，FireRedAudio 把上限拉到了约一小时。更重要的是，它不只是"能听完"，而是能做到时间与内容的精确对齐：可以输出带时间戳的结构化摘要，可以按时间点检索当时说了什么，也可以反过来——根据内容反查它在录音中的位置，还能跨片段推理分散在不同位置的证据。
这个能力对会议纪要、播客整理、访谈分析、录音取证这类场景价值很大。官方 demo 页放了两个长音频理解的演示视频，可以看到模型在一小时级别的录音上做时间定位的实际效果。想象一下：一场两小时的行业峰会录音，你问"第三位嘉宾在讲到市场规模时引用了哪家机构的数据"，模型直接给出答案和它在录音里的时间位置——这在过去需要人工从头听到尾，或者依赖多段切分拼接的繁琐流程。
FireRedTeam 还在论文里对比指出，多数音频模型只能处理 30 秒到 1 分钟的片段，FireRedAudio 把这一上限提升了一个数量级，这背后是长上下文建模和位置编码上的针对性设计。
局限与展望
FireRedAudio 的局限官方写得很坦诚：除了 ASR 之外，所有任务目前只支持中文和英文，其他语言要等后续版本；零样本 TTS 默认非确定性，因为生成端是 flow-matching 随机采样，想复现结果需要固定随机种子；长音频支持上限约一小时，超出范围未测试。另外，模型内置的零样本语音克隆功能官方声明仅限学术研究用途，禁止任何非法使用，做产品接入时需要留意这一条。
整体来看，FireRedAudio 以 Apache 2.0 协议开源，代码、权重、论文（arXiv 2608.24168）一应俱全，是近期开源音频模型里"任务覆盖最全"的一个。它证明了理解与生成可以解耦共存于一个模型，也让"一个模型处理整个音频链路"从口号变成了可下载的代码。
对熟悉 FireRedTeam 的读者来说，这次开源还有一层延续性：从 FireRedTTS 系列在语音合成上的积累，到 FireRedAudio 把理解、生成、编辑统一进一个模型，这个团队一直在往"全链路音频"的方向走。此前我们介绍过的 FireRedTTS3 主打多语言与声音设计，而 FireRedAudio 更像是把整个音频技术栈收拢到一个底座上的集大成者——零样本 TTS 成绩反超自家专精模型（平均 CER/WER 从 1.55 降到 1.20），也印证了统一架构没有牺牲单点能力。对于做语音产品的团队来说，这套架构值得认真研究——它可能是下一代音频基础设施的样子。
参考资源：
-
• GitHub 仓库：https://github.com/FireRedTeam/FireRedAudio -
• Hugging Face：https://huggingface.co/FireRedTeam/FireRedAudio -
• 论文：https://arxiv.org/abs/2608.24168