Kimi-Audio 之后并没有一个统一的“下一代 Audio 模型”定义。有的模型强化离线音频推理，有的追求低首包语音生成，有的同时监听和说话，还有的把 ASR、TTS、实时对话放进同一 backbone。把它们放在一张总榜上会掩盖真正的架构差异。
Moonshot 官方仓库仍列 Kimi-Audio-7B 与 Kimi-Audio-7B-Instruct。Kimi K2/K3 是文本模型产品线，不能据此推导出 Kimi-Audio 2。
Kimi-Audio 的重要基线是“连续输入、离散输出”：音频 encoder 负责理解，音频 tokenizer 负责生成，7B decoder-only Transformer 在文本和音频任务上联合预训练，再用 instruction tuning 与音频强化学习形成理解和对话能力。后继模型大多没有抛弃这个混合接口，而是在调度和后训练上继续扩展。
一、后 Kimi-Audio 时代的三条架构路线
二、主要模型矩阵：先比较系统边界，再看 benchmark
表中“全双工”只指模型在输出时仍持续理解用户输入，并对重叠和打断建模；WebSocket 双向传输或外部 VAD 停止播放不算原生全双工。开放状态以对应版本的官方仓库和模型卡为准。
| 模型 | 输入 → 输出 | 架构重点 | 全双工 / 推理 | 开放状态 |
|---|---|---|---|---|
| VITA-Audio 2025-05 | 语音/文本 → 文本+语音 | Qwen2.5 7B；MCTP 一次前向预测多个跨模态 Token | 低首包流式 S2S；论文重点不是持续双流 | 代码/权重；许可限制商用 |
| Step-Audio 2 2025-07 | 音频/文本 → 文本+语音 | latent audio input + 离散语音输出；reasoning RL、RAG、搜索 | 显式思考与工具；非原生持续双流 | 2/2 mini 有官方权重 |
| Qwen3-Omni 2025-09 | 文本/图像/音频/视频 → 文本+语音 | Thinker-Talker MoE；多码本 AR codec + causal ConvNet | 流式、多语言、Thinking 版本；非持续双流定义 | Apache-2.0 权重/代码 |
| PersonaPlex-7B 2026-01 | 英语语音+角色/声音提示 → 英语语音 | Moshi 双音轨骨干；文本控制角色，语音提示控制声音 | 原生全双工、重叠与打断 | MIT 代码；NVIDIA 权重许可 |
| MiniCPM-o 4.5 2026-02 | 音视频/文本 → 文本+语音 | 9B；毫秒时间线与 TDM 编排多路流 | 全双工 omni；约 1 Hz 决定是否主动发言 | Apache-2.0 权重/代码 |
| StepAudio 2.5 2026-05 | 统一输入 → ASR / TTS / Realtime | 共享 backbone；三套任务化 RLHF 与 decoding regime | 实时分支优化延迟和 persona；报告不以持续双流为核心 | 查到技术报告，未查到 2.5 正式权重 |
| Gemini 3.1 Flash Live | 多模态 → 文本+音频 | native audio API、thinking、grounding、function calling | 低延迟 audio-to-audio | 封闭 Preview API；内部架构未披露 |
| GPT-Realtime-2.1 | 文本/图像/音频 → 文本+音频 | 实时 S2S reasoning、function calling | 打断、工具与可配 reasoning effort | 封闭商业 API；无权重 |
VITA-Audio 的 53 ms、Qwen3-Omni 的理论 234 ms 等数字使用不同硬件、缓冲起点、首块定义和网络假设。只有在相同输入、硬件、并发和测量边界下，首包延迟才可比较。
三、ASR、TTS、实时对话一起训练，会让效果更好吗？
通常会改善共享表示和数据效率，但不会自动让三个任务都达到单任务最优。ASR 希望稳定、可验证、低幻觉的文本序列；TTS 需要高熵声学细节和偏好质量；实时对话还要优化延迟、是否开口、打断和 persona 一致性。它们共享语言与声学知识，却有不同的最优解码目标。
StepAudio 2.5 的关键并不是强迫三个任务使用同一个解码器配置，而是共享 audio-language backbone，再为每种工作模式配置不同的后训练和推理约束：
| 模式 | 主要目标 | 专门化方式 | 多任务收益 |
|---|---|---|---|
| ASR | 转写正确、稳定 | 可验证奖励、多 Token decoding | 从 TTS/对话数据学习发音和口音覆盖 |
| TTS | 自然度、音色、可控性 | 偏好 RLHF 与生成采样 | 从 ASR 学到更稳的内容对齐 |
| Realtime | 低延迟、角色与交互 | generative reward model 和实时调度 | 复用理解、语言和发声能力 |
因此更准确的结论是：联合训练让 backbone 更通用，task-tailored post-training 让每个任务避免被平均化。若数据比例、梯度尺度和采样策略控制不好，负迁移仍会出现，例如 TTS 的声学长序列挤占语言建模容量，或对话式改写损害逐字 ASR。
四、真正的新分水岭是时间建模
第一代统一模型主要回答“同一模型能否听懂并说出来”；后续模型开始回答“说话期间还能不能听、什么时候该沉默、复杂推理时媒体循环是否会卡住”。这使架构从单序列变成多流时间线，或把快交互层与慢推理层异步拆开。
- PersonaPlex：沿 Moshi 的用户/助手并发音频流，专注英语角色和声音可控的自然轮换。
- MiniCPM-o 4.5：用毫秒时间线与 TDM 把音频、视频、文本和助手语音编入同一序列，并学习主动发言决策。
- DuplexOmni：研究原型把低延迟 interaction layer 与可插拔 thinking/tool layer 异步并行，避免复杂任务阻塞说话循环。
这也解释了为什么单句 MOS 不再足以评价实时模型。更关键的指标包括：打断检测与停止延迟、误开口率、重叠恢复、回声鲁棒性、长会话声音漂移，以及工具等待期间是否能正确保持沉默。
五、按任务选择，而不是追逐“最新”
| 需求 | 优先看 | 必须额外验证 |
|---|---|---|
| 音频问答、长音频理解 | Audio Flamingo 3、Step-Audio 2、Nemotron Omni | 音频时长、非语音声音、文本输出是否足够 |
| 开放权重的多模态语音生成 | Qwen3-Omni、MiniCPM-o 4.5 | 显存、语言范围、实时部署栈 |
| 英语全双工角色 Agent | PersonaPlex | 许可、仅英语、回声消除 |
| ASR/TTS/对话共用一套基座 | StepAudio 2.5 的设计路线 | 当前权重可得性与各模式回归 |
| 最快接入生产 API | GPT-Realtime、Gemini Live | 成本、地域、数据条款、不可审计内部结构 |
截至目前，最稳妥的技术判断不是“Audio 模型终于统一了”，而是统一 backbone 与专用 operating regime 正在同时成立。连续 encoder、文本隐藏状态、离散语音 Token、流式调度和任务化 RLHF 仍各自承担不同职责。
评论加载中...