读 Mini-Omni 这篇论文的时候，有几个地方卡了挺久，记录一下思考过程。
论文链接： arXiv 2408.16725
一、Batch Trick：凭什么样本 2 的文本更好？
Mini-Omni 的推理策略挺巧妙：把 batch size 从 1 扩到 2，样本 1 同时生成文本 + 音频，样本 2 只生成文本。每一步把样本 2 的文本 token 替换到样本 1 对应位置，让音频在”更好的文本”指导下生成。
论文说这样音频质量会更好。但为啥 样本 2 的文本更好？
两个样本跑的是同一个模型、同一次前向传播。文本 head 的参数没变，hidden states 也是共享的——同一个 hidden state 过同一个线性层，输出的 logits 应该一模一样才对。
想了一会儿发现问题出在自回归的滚雪球效应上：
-
第 1 步确实一样，两个样本的输出完全相同
-
但从第 2 步开始，样本 1 的上文里混入了音频 token，样本 2 的上文是纯文本
-
Transformer 的 attention 看到的上文不同了，hidden states 从此分叉
-
音频 token 作为”噪声”混入上文，会逐步干扰样本 1 后续的文本推理
所以不是”文本 head 变差了”，而是上文污染导致 hidden states 偏移。样本 2 的上文始终干净，推理链更稳定。
本质上这是一个多任务 vs 单任务的 trade-off。小模型容量有限，上文里多了一堆音频 token 会分散 attention 的注意力。大模型可能不需要这个 trick。
二、Delay Pattern：不是 Flatten，是并行 + 求和
Mini-Omni 用多层 codebook（SNAC，7 层）来编码音频。我一开始以为模型会把所有层的 token 拉平（flatten）成一条长序列：
... text, a1, b_pad, c_pad, a2, b1, c_pad, a3, b2, c1, ...但实际上不是这样。Mini-Omni 在每个时间步通过 8 个 LM head ==并行==输出 8 个 token（1 个文本 + 7 个 SNAC 层），然后把这 8 个 token 的 embedding 求和作为下一步的输入。
简化成 text + 3 层音频（a, b, c），实际的并行输出矩阵是：
| 时间步 | Text head | Layer a | Layer b | Layer c |
|---|---|---|---|---|
| t1 | text₁ | pad | pad | pad |
| t2 | text₂ | a₁ | pad | pad |
| t3 | text₃ | a₂ | b₁ | pad |
| t4 | text₄ | a₃ | b₂ | c₁ |
几个关键点：
-
Text 先行一步，音频层逐层延迟。t1 时所有音频层都还是 pad
-
高层能参考低层：生成 b₁ 时，a₁ 已经在上一步输出过了，通过 attention 可以看到
-
上下文长度 = 时间步数，不是时间步 × 8。因为 8 个 head 的输出被求和成一个向量，不会让 context 爆炸
这就是 delay parallel 的效率优势：一次 forward 出 8 个 token，但 context 长度不膨胀。
三、论文的一个小槽点
关于”求和”这件事，论文自己在两处的描述都不一致：
Section 3.2 写的是：
“all sequences generated in parallel are summed before producing the next token”
Section 3.3 写的是：
“all sequences are summed and averaged to integrate features”
sum 和 mean 只差一个常数系数，本质没区别，但这种核心机制连个公式都不给、两处措辞还不一致，确实有点让人抓狂。Mini-Omni 整体偏 technical report 风格，很多关键细节靠一句话带过，读起来要自己去脑补和验证。
小结
读这篇论文最大的收获不是记住了哪个架构细节，而是体会到**“带着质疑去读”**的重要性：
-
论文说”文本质量更好”→ 追问凭什么 → 发现是 attention 上文分叉
-
以为是 flatten → 画 token 序列去验证 → 发现是并行求和
-
论文说 summed → 去找原文 → 发现两处描述不一致
每次觉得”不对劲”的时候，往往就是理解真正深入的时候。