Posts

前几天在看苏剑林老师的这篇文章：https://kexue.fm/archives/11848，里面有一句话让我停了一下： 但现在除 KV Cache 外，Decoding 还有一个新的变数——MTP，或者说推测解码，其思想是计算换速度。然而 MLA 在 Decoding 时表现为 head_dims=512+ 的 MQA，已经提前消耗了大部分算力，所以“MLA+MTP”很容易吃亏。 我第一反应是：这是什么意思？为什么 MLA 在 decode 时会“提前消耗算力”？为什么它在 decode 时的 FLOPs，相当于一个 head dim 512+ 的 MHA，反而和 MTP 有冲突？ 顺着这个问题往下看，最后发现背后其实是一个非常经典、但放在 Attention 上又很有意思的概念：Arithmetic Intensity（AI，计算密度）。 而且最后得到的结论意外地简单（下面都按 BF16 的 KV cache 算）： 把 MHA 一路约下来，AI 居然刚好就是 1； GQA、MQA 也一样干净，只和 head 的数量有关 —— context length、head dim 全部约掉了，一个都不剩； MLA 还是同一个形状，同样和 latent dim 无关，只是多了一个不到 2 的常数。 把四种结构排在一起，single-token decode 下 attention core 的 AI 是这样的： Attention 历史 cache 里存什么 这时的 AI 大约是 MHA 每个 Query head 各有 K、V 1 GQA 一组 Query head 共用 K、V Query head 数 / KV head 数 MQA 所有 Query head 共用 K、V Query head 数 MLA 只存一份 latent，K、V 都从它展开 约 2 × Query head 数 第 2 节和第 4 节会把这四行分别推一遍。前三行其实是同一个公式的三个 special case，只是 KV head 数取值不同；最后一行多出来的那个常数，来源完全不同。 ...

TL;DR：full-duplex benchmark 已经从单轮 timing 指标，推进到 overlap handling、multi-turn task、tool-use state rollback、semantic-aware interruption 和 emotion reasoning。但这些方向现在还是分散的：有的测模型该不该停，有的测用户改口后 tool state 能不能更新，有的测情绪理解，有的测 instruction-conditioned interrupt。真正缺的是一个统一的 content-conditioned dynamic behavior benchmark：当用户语音流里出现 wrong fact、self-correction、safety risk、emotion shift、contradiction、new constraint 这类内容信号时，模型是否能在正确时间改变行为，并同时做到动作、内容、状态和语气都正确。 上一篇写 full-duplex RL 时，我们把主线放在 when to speak：模型什么时候开口、什么时候停、什么时候 backchannel、什么时候让出 floor。这个问题很重要，但如果继续往 voice agent 的真实场景走，会很快遇到另一个问题： 模型需要根据声音活动决定说不说，也需要根据用户正在说的内容动态改变自己的行为。 比如用户正在基于一个明显错误的事实继续推理；用户中途改口；用户的语气从正常变成焦虑；用户提出一个会导致危险操作的前提；用户在模型说话时补充了新的 hard constraint。此时系统需要决定的范围已经从普通 turn-taking 扩展到了这些问题： content signal 出现了吗？ 证据够了吗？ 要继续听、短反馈、主动打断、让出、纠正，还是延迟 tool call？ 纠正以后，后续 state 有没有更新？ 语气是否也要调整？ 我觉得这会成为 full-duplex benchmark 的下一步。重点会从单纯做 latency benchmark，转到把内容理解和实时交互动作绑在一起测。 本文目录如下： 0. 为什么 timing benchmark 不够？ 1. 现有 benchmark 已经走到哪里？ 2. content-conditioned behavior 到底是什么？ 3. 最近邻 work 分别覆盖了哪一半？ 4. 一个更完整的 benchmark 应该怎么定义？ 5. 这件事对 full-duplex RL 有什么价值？ 6. 风险和边界 7. 结语 0. 为什么 timing benchmark 不够？ 早期 full-duplex benchmark 主要解决一个很直接的问题：模型是否真的具备双工交互能力。Full-Duplex-Bench v1 把 full-duplex 互动拆成 pause handling、backchanneling、smooth turn-taking、interruption management 四类行为，指标包括 takeover rate、backchannel frequency/JSD、response latency 和 interruption 后的 response quality（Full-Duplex-Bench, arXiv:2503.04721）。 ...

TL;DR：full-duplex spoken model 的主问题已经从「能不能同时听和说」推进到「能不能在连续语音流里做正确的 floor-control decision」。Moshi 先把实时双流 speech-to-speech 建起来，Full-Duplex-Bench 把 pause handling、turn-taking、backchanneling、interruption management 变成可测指标，后续 alignment/RL 工作开始把 interaction timing 从语义生成里拆出来优化。DuplexPO（arXiv:2607.07148）的关键处理是：只在 dynamics-critical windows 里采样，用 FCDR 分解 start/backchannel/stop/regularization reward，再用 GRPO-style objective 更新局部 policy，同时通过 KL 和 SFT reference 保住 what to say。 full-duplex RL 的脉络要先从一个更朴素的问题开始：语音模型已经会回答问题以后，为什么还要专门学「什么时候说」？ 传统 voice assistant 像一个严格排队的柜台：用户说完一句，系统转写一句，LLM 生成一句，TTS 再读一句。这个流程在任务型 QA 里很自然，因为它默认对话已经被切成整齐的 turn。真实对话更像两个人共用同一个声道：用户会停顿、补充、犹豫、打断；听者会用很短的 backchannel 表示还在听；说话权的交接经常发生在几百毫秒的窗口里。 所以 full-duplex spoken model 最后面对的对象不只是文本 token。它每一小段时间都在回答三个问题： content: 现在要说什么 timing: 现在该不该开口 state: 如果用户开始说话，系统该继续、停下，还是只给短反馈 这三个问题混在一起训练，就容易出现一个熟悉现象：模型答案没错，但交互很别扭。它可能在用户长停顿时抢话，也可能在用户真正说完以后沉默太久，还可能把本该一声「嗯」的 backchannel 变成完整句子。 本文目录如下： 0. 什么是 full-duplex spoken model? 1. 第一阶段：先把双流实时建起来 2. 第二阶段：把自然交互拆成可测行为 3. 第三阶段：为什么 SFT 到这里会变弱 4. 第四阶段：RL 怎么进入 full-duplex 5. DuplexPO：把 conversational dynamics 单独拿出来优化 6. 实验结果说明了什么 7. 对 RL infra 的启发 8. 结语 full-duplex spoken model RL 的主线：先获得双流实时能力，再把互动行为拆成评估维度，最后用局部 RL 优化 floor-control decisions。 ...

TL;DR：Agent execution 的核心在于如何合理并行化 single task——这是 Bitter Lesson 在协作层面的下一题，也是这场 24 小时 hackathon 让我想清楚的事。 最近参加了一个 24 小时的 hackathon，结束之后越想越觉得，新的协作范式和老的已经完全不一样了。这篇文章把我在现场观察到的几个点串一下，更多算是几个我觉得值得后续认真做的方向，谈不上结论。 Hackathon 为什么是好的压力测试？ 之前的合作模型是「人 ↔ 人」。中间多了 agent 之后，如果 agent 还只是人的纯辅助、context 是人的严格子集，问题不大——这其实是过去一年绝大多数日常工作的状态。 但 24 小时 hackathon 是另一回事： deliver 优先级第一，没人有时间审 agent 的每个判断； agent 的 context 和人的 context 事实上已经独立演化，但协作仍然要继续； latency 比 throughput 重要——你跑得再多 task，最终交付的就是一个 demo。 这些约束把日常工作里看不出来的问题一下子全暴露出来，下面所有的现象都是从这里来的。 一次 demo 8 小时报废：多跳协作里 context 一定会丢 我们队里吃了一个完整的亏。队友 a 跑通了一个挺漂亮的 demo，让自己的 agent「把所有代码和内容别加筛选地提交 GitHub、保证能复现」。他把 PR branch 直接发给我；我又把 branch 丢给自己的 agent，让它复现。结果完全！没法！复现——尤其当 a 的环境和 GPU instance 因为忘记充钱被回收掉之后，我们四个人花了快 2 个小时还是没能跑起来那个 demo，直接把之前 8 个小时的努力全废了。 ...

TL;DR 在 LLM 的 RL post-training 中，trainer 每完成一个 optimizer step，就需要把更新后的权重同步给负责 rollout 的 inference engine。在解耦（disaggregated）架构下，这一步长期被视为必须依赖高带宽 RDMA 的环节——同步开销随模型规模线性增长，并主导整个 sync 阶段。 2026 年上半年，学术界、工业界与开源社区几乎同时给出了同一个观察并加以利用：在典型的 RL 学习率下，每个 step 之后真正发生变化的权重只占很小一部分（在 BF16 表示下，超过 99% 的元素逐字节未变）。因此只传输变化的部分（delta），即可将通信量降低约两个数量级，且重建无损、bit-identical。这把权重同步从一个依赖 RDMA 网络的硬件问题，转化为一个如何编码稀疏 delta 的软件问题——使得 RL 训练能够运行在普通以太网，甚至跨数据中心的共享存储之上。 本文先说明这一观察的来源与依据，再以 slime 的实现为完整实例，拆解要落地 delta weight sync 需要在系统的哪些环节进行改动；最后讨论当 rollout 采用低精度（量化）时，这套 delta 故事会遇到的新问题。 1. 背景：weight sync 为什么是瓶颈 现代 RL 框架普遍将 trainer（Megatron / FSDP）与 rollout/inference engine（SGLang / vLLM）解耦：两者采用不同的并行策略与算子实现，往往运行在不同的进程、节点乃至数据中心。由此产生一个不可回避的步骤：每次策略更新后，必须将 trainer 的新权重同步给 inference engine，否则采样所用的是过期策略。 默认做法是 full broadcast：把全部参数从 trainer 广播给所有 inference rank（典型实现是 trainer 的 rank 0 与 inference engine 的所有 rank 组成一个 NCCL 通信组）。其开销随模型规模线性增长，在解耦架构中通常主导整个 sync 阶段。 ...