<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>LLM - 标签 - lilfry's library</title><link>https://lilfry09.github.io/tags/llm/</link><description>LLM - 标签 - lilfry's library</description><generator>Hugo -- gohugo.io</generator><language>zh-CN</language><managingEditor>lilfry@sjtu.edu.cn (lilfry)</managingEditor><webMaster>lilfry@sjtu.edu.cn (lilfry)</webMaster><copyright>All rights reserved.</copyright><lastBuildDate>Mon, 13 Jul 2026 23:30:00 +0800</lastBuildDate><atom:link href="https://lilfry09.github.io/tags/llm/" rel="self" type="application/rss+xml"/><item><title>异步 RL：用 Policy Staleness 换掉全局 Barrier</title><link>https://lilfry09.github.io/ai/async-rl-policy-staleness-global-barrier/</link><pubDate>Mon, 13 Jul 2026 23:30:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/async-rl-policy-staleness-global-barrier/</guid><description><![CDATA[<h3 id="异步-rl-的核心就是rollout-worker-持续生成样本trainer-收到足够样本就立即更新不再等待同一轮所有请求全部完成它用一定程度的-policy-staleness-换掉同步-barrier因此-gpu-更忙吞吐更高但训练数据也不再严格来自当前-policy"><strong>异步 RL 的核心就是：rollout worker 持续生成样本，trainer 收到足够样本就立即更新，不再等待同一轮所有请求全部完成。它用一定程度的 policy staleness 换掉同步 barrier，因此 GPU 更忙、吞吐更高，但训练数据也不再严格来自当前 policy。</strong></h3>
<p>如果只看系统吞吐，异步 RL 很诱人。长 CoT 请求不再把整轮训练卡住，短请求生成完就可以进入训练队列，trainer 不必陪最后几个超长样本一起发呆。</p>
<p>但这笔交易并不免费。同步 RL 里的等待点很烦，却也维护了一个重要假设：本轮训练数据大体来自同一个 policy snapshot。异步 RL 把这个假设拆掉之后，系统变成一条更高吞吐的流水线，同时也把 off-policy correction、数据分布偏差和样本版本管理都请上了牌桌。</p>]]></description></item><item><title>DLLM 方法综述：从掩码扩散到大语言扩散模型</title><link>https://lilfry09.github.io/ai/dllm-method-survey/</link><pubDate>Mon, 13 Jul 2026 00:00:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/dllm-method-survey/</guid><description><![CDATA[<p>如果把 <code>DLLM</code> 理解成 <code>Diffusion Language Model</code> 或 <code>Diffusion Large Language Model</code>，那它现在最值得讨论的地方不是“它能不能一次生成多个 token”这么简单。</p>
<p>更准确地说，DLLM 在重新打开一个被自回归 LLM 几乎盖住的问题：</p>
<p><strong>语言模型一定要从左到右写下去吗？</strong></p>
<p>自回归模型的答案是：是的，把序列概率拆成一串 next-token 条件概率，训练、推理、缓存、服务系统全都围绕这个假设展开。扩散语言模型的答案是：未必。我们也可以先拿到一个被破坏的句子，再让模型用双向上下文一步步修复它；也可以先生成骨架，再填细节；也可以在多个位置同时做决策，只把足够确定的位置提交。</p>
<p>所以 DLLM 真正有意思的地方，是它把语言生成从“写作”改成了“编辑”。</p>]]></description></item><item><title>R3 和异步 RL：强异步 MoE 训练中的 routing replay 问题</title><link>https://lilfry09.github.io/ai/r3-async-rl-moe-routing-replay/</link><pubDate>Mon, 13 Jul 2026 00:00:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/r3-async-rl-moe-routing-replay/</guid><description><![CDATA[<h3 id="r3-和异步-rl-解决的是两个正交问题异步导致的是用旧-policy-的数据更新新-policyr3-修的是对同一个-token同一组参数训练重算时没有复现-rollout-当时的-moe-routing即便-composer-天生允许-policy-staleness也仍需先保证行为-policy-的-token-probability-能被准确重建否则-off-policy-correctionkl-和-policy-ratio-都会被错误-routing-污染"><strong>R3 和异步 RL 解决的是两个正交问题：异步导致的是“用旧 policy 的数据更新新 policy”，R3 修的是“对同一个 token、同一组参数，训练重算时没有复现 rollout 当时的 MoE routing”。即便 Composer 天生允许 policy staleness，也仍需先保证行为 policy 的 token probability 能被准确重建，否则 off-policy correction、KL 和 policy ratio 都会被错误 routing 污染。</strong></h3>
<p>关于这件事，有两个容易混在一起的判断：一个是“逻辑上不等价”的区分，这个分类基本正确；另一个是“想更新生成 token 时参与计算的 experts”，它也抓到了现象，但最后一句需要更精确一点：R3 的关键未必是<strong>冻结并只更新原 experts</strong>，而是<strong>重放 rollout routing，以便正确重建 behavior-policy forward 或训练所需的概率和梯度路径</strong>。两件事很接近，却不能完全画等号。</p>]]></description></item><item><title>读 Qwen Bebop 与 DeepSeek DSpark：Speculative Decoding 正在从技巧变成系统工程</title><link>https://lilfry09.github.io/ai/qwen-bebop-deepseek-dspark-speculative-decoding/</link><pubDate>Sat, 11 Jul 2026 23:30:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/qwen-bebop-deepseek-dspark-speculative-decoding/</guid><description><![CDATA[<p>最近两篇关于 <code>speculative decoding</code> 的论文很值得放在一起看。</p>
<p>一篇是 Qwen Team 的 <strong>Bebop</strong>，全名是 <em>Breaking Entropy Bounds: Accelerating RL Training via MTP with Rejection Sampling</em>。它关心的是：在大规模 RL 后训练里，rollout 太慢，能不能用 <code>MTP</code> 把采样阶段加速起来？</p>
<p>另一篇是 DeepSeek 的 <strong>DSpark</strong>，全名是 <em>Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation</em>。它关心的是：在线上高并发 serving 里，speculative decoding 为什么经常一上负载就不稳，怎样让它真正移动吞吐-延迟前沿？</p>
<p>这两篇看起来一个讲训练，一个讲推理；一个讲 Qwen 的 RL pipeline，一个讲 DeepSeek-V4 的线上服务。但我读完之后觉得，它们其实在回答同一个更大的问题：</p>
<p><strong>speculative decoding 的核心已经不只是“多猜几个 token”，而是怎样让猜测、验证、分布匹配和系统负载一起闭环。</strong></p>]]></description></item><item><title>GroupDPO: Memory efficient Group-wise Direct Preference Optimization</title><link>https://lilfry09.github.io/ai/groupdpo-group-wise-preference-optimization/</link><pubDate>Tue, 05 May 2026 00:00:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/groupdpo-group-wise-preference-optimization/</guid><description>GroupDPO 将 DPO 从一正一负的单对偏好扩展到多候选回答组，并通过一阶梯度等价的 surrogate loss 降低显存开销。</description></item><item><title>读 MOPD：后训练正在从单一 RL 走向多教师能力合并</title><link>https://lilfry09.github.io/ai/multi-teacher-on-policy-distillation-post-training-primitive/</link><pubDate>Tue, 05 May 2026 00:00:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/multi-teacher-on-policy-distillation-post-training-primitive/</guid><description><![CDATA[<p>这篇文章最值得注意的地方，不是它又给后训练加了一个新缩写，而是它指出了一个正在变清晰的趋势：</p>
<p><strong>后训练的主线，可能正在从“用一个奖励函数把模型直接 RL 到更强”，转向“先训练多个能力专家，再用 on-policy distillation 把这些能力合并回一个主模型”。</strong></p>
<p>如果说 SFT 是教模型模仿答案，DPO/RL 是教模型偏向更好的行为，那么 <code>Multi-Teacher On-Policy Distillation</code> 更像是在回答另一个问题：</p>
<p><strong>当我们已经用不同数据、不同奖励、不同阶段训练出了多个强 teacher，怎样把它们稳定地压回一个 student，而不是靠简单模型融合或离线蒸馏丢掉能力？</strong></p>]]></description></item><item><title>模型更强之后，Agent 框架会怎样退到 runtime</title><link>https://lilfry09.github.io/ai/stronger-agent-models-thinner-frameworks/</link><pubDate>Tue, 05 May 2026 00:00:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/stronger-agent-models-thinner-frameworks/</guid><description>当模型通过轨迹训练学会规划、工具使用、错误恢复和上下文选择后，Agent 框架最该简化的不是安全和评估，而是替模型思考的调度层。</description></item><item><title>面试高频：Bradley-Terry vs Plackett-Luce，奖励建模到底差在哪</title><link>https://lilfry09.github.io/ai/bt-vs-pl-ranking-in-alignment/</link><pubDate>Wed, 08 Apr 2026 14:20:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/bt-vs-pl-ranking-in-alignment/</guid><description>一句话：BT 是 PL 在候选数 N=2 时的特例。BT 更轻、更稳、更适合现有 RLHF/DPO；PL 信息更全，但标注和训练成本显著更高。</description></item><item><title>读 YaRN：长上下文扩展，核心不是硬拉窗口，而是别把 RoPE 拉坏了</title><link>https://lilfry09.github.io/ai/yarn-context-window-extension/</link><pubDate>Tue, 07 Apr 2026 21:12:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/yarn-context-window-extension/</guid><description><![CDATA[<p>如果只把 <code>YaRN</code> 看成“又一个把上下文从 <code>4k</code> 拉到 <code>64k/128k</code> 的技巧”，其实有点可惜。</p>
<p>它真正碰到的，是一个比“扩窗”更本质的几何问题：</p>
<p><strong>模型原本已经习惯了一套位置相位系统。现在你强行把长度拉大，怎样才能让这套系统在更长范围内继续工作，同时尽量不丢掉近距离的位置分辨率？</strong></p>
<p>这个问题一旦说清楚，<code>YaRN</code> 的设计就会显得非常自然。</p>]]></description></item><item><title>读《Reasoning with Sampling》：RL 没让模型变聪明，它只是在重分配推理能力</title><link>https://lilfry09.github.io/ai/reasoning-with-sampling-rl-redistribution/</link><pubDate>Tue, 07 Apr 2026 20:55:00 +0800</pubDate><author>fry</author><guid>https://lilfry09.github.io/ai/reasoning-with-sampling-rl-redistribution/</guid><description><![CDATA[<p>这篇论文真正危险的地方，不是它提出了一个新采样器，而是它在追问一个更深的解释问题：</p>
<p><strong>reasoning model 的进步，到底是模型学会了新能力，还是我们终于学会了怎么从旧能力里采样？</strong></p>
<p>如果这个问题问对了，很多关于 <code>RL for reasoning</code> 的叙事都得重写。</p>]]></description></item></channel></rss>