TokUR: Token-level Uncertainty Estimation for Large Language Model Reasoning

论文 TokUR: Token-level Uncertainty Estimation for Large Language Model Reasoning 提出的技术核心，是通过 token-level 不确定性估计 来增强大语言模型（LLM）的推理能力和输出可信度。其主要的技术创新在于如何估算每个生成 token 的不确定性，而不需要对现有模型进行额外的训练。以下是这篇论文的核心技术细节。

https://arxiv.org/pdf/2603.07777

Breaking Training Bottlenecks: Effective and Stable Reinforcement Learning for Coding Models

它想解决现代 coding model 做 RL 训练时“不稳定、长输出学不好、多样性塌缩、旧数据太简单、评测信号不准”这些瓶颈，并提出了一套更适合代码模型的 GRPO 训练 recipe：MicroCoder-GRPO。（策略就是分析，目标函数里，减少kl影响，增大clip等，是篇方法论的文章）

https://arxiv.org/pdf/2603.04918

BandPO: Bridging Trust Regions and Ratio Clipping via Probability-Aware Bounds for LLM Reinforcement Learning

arXiv 编号 2603.04918，提交时间是 2026-03-05，GitHub 官方实现是 OpenMOSS/BandPO。论文作者来自复旦大学、上海创智学院等，GitHub 也标注它是官方实现。

BandPO 是一个把 PPO/GRPO 固定 ratio clipping 改成概率感知动态 clipping 的方法。它从 fff-divergence trust region 出发，为每个 token 根据旧概率 P(a)推出专属上下界，让低概率高价值 token 有更多上升空间，同时限制高概率 token 继续垄断，从而缓解探索不足和熵崩塌。

你可以这样记：

固定 clipping→低概率 token 被压死→BandPO 用 trust region 推动态边界→保护尾部探索，缓解 entropy collapse​

arXiv:2603.00030

SimpleTool: Parallel Decoding for Real-Time LLM Function Calling

SimpleTool 把函数调用输出拆成多个可以并行生成的“头”：一个头生成函数名，多个头分别生成参数；同时用特殊 token 压缩 JSON 里的结构符号和参数名，从而把原本串行生成的函数调用变成近似并行生成。（icml 2026）

QwenScope

Qwen Scope（准确来说是 Qwen‑Scope）是阿里巴巴旗下 Qwen（通义千问）项目最新公开的 可解释性工具模块（interpretability toolkit），并且已经开源了。它不是一个新的聊天模型，而是一个用于“理解和分析大型模型内部行为”的开放资源。

📌 Qwen‑Scope 是什么？

Qwen‑Scope 是：

• 一个 可解释性 / 透明度 工具模块，可以帮助开发者和研究者观察和探索 Qwen 系列大模型（特别是 Qwen3 和 Qwen3.5）的内部推理机制。
• 它核心由 稀疏自编码器（SAE，Sparse Autoencoders） 组成，这些可以映射模型内部的特征表示。

简单来说，它就像是一个“显微镜”或者“调试工具箱”，能让你：

• 分析模型在生成文本时的“内部特征/概念”（比如识别特定类型的语义或行为信号）；
• 定向控制或理解推理表现（例如研究模型为何拒绝回答、如何分类数据等）；
• 用于模型训练优化、行为分析与分类、样本分布评估等高级场景。

🧠 它和普通 Qwen 模型有何不同？

• Qwen 模型（如 Qwen3, Qwen3.5 等）是实际用于生成文本/图像/多模态内容的语言模型。
• Qwen‑Scope 不是生成内容，而是用于研究、解释、分析这些模型内部结构和行为的一套工具和权重。
• 它公开的权重涵盖了 7 个大模型的 SAEs（稀疏自编码器权重），共计 14 套用于不同模型规模的解释组件。

🛠 用途举例

• 对 Qwen 大模型的内部推理路径进行可视化或特征分析。
• 调研模型在特定输入情形下的行为差异。
• 在研发阶段做模型安全性、性能、内部特征分布的深入分析。

🧾 资源在哪里？

Qwen‑Scope 已经开放在如 Hugging Face 的集合页面上，可以下载或查看对应参数和内容。

Reducing Belief Deviation in Reinforcement Learning for Active Reasoning of LLM Agents

方法名叫 T³ / T3: Truncating Belief-Trapped Trajectories。OpenReview 页面和 GitHub 都显示它是 ICLR 2026 Oral，官方代码仓库是 unimpor/T3。

多轮 LLM agent 在强化学习训练中，不应该盲目把整条 rollout 都拿来更新；一旦轨迹后半段已经因为错误信念而变成重复、无信息、甚至有害的 tail，就应该提前截断，避免它污染前面真正有价值的探索动作。

Proxy	含义

新打开的文件是否和 stack trace / failing test 相关

是否缩小 bug 位置

grep/search 结果是否引入新实体

是否发现新线索

patch diff 是否影响 failing path

是否朝解决 bug 推进

test failure 是否从 import error 变成 assertion error

是否改变问题状态

是否反复读同一文件、跑同一命令、得到同样错误

是否进入 loop

agent 的自然语言 hypothesis 是否持续变化

belief 是否更新

如果迁移到 SWE-agent，可以考虑设计类似的 progress proxy：

SWE-agent 场景	可能的 progress proxy
反复读同一个文件	可能进入 loop
反复运行同一个失败命令	可能进入 belief trap
新 grep 没带来新实体 / 新文件	信息增益低
patch diff 没触及 failing path	repair progress 低
test failure 完全不变	环境状态没有改善
agent hypothesis summary 没变化	belief update 停滞
工具调用改变了 workspace state	可能有实际进展

Freshness-Aware Prioritized Experience Replay for LLM/VLM Reinforcement Learning

arXiv 编号 2604.16918，提交时间是 2026-04-18；代码仓库是 Vision-CAIR/Freshness-Aware-PER。

FreshPER 想解决 LLM/VLM RL 里“rollout 太贵但又只能用一次”的浪费问题：它把旧轨迹放进 replay buffer 复用，但又用“新鲜度指数衰减”防止太旧的高优先级轨迹反复污染训练。

FreshPER 的训练流程大概是：

1. 用 behavior policy πμ 和环境交互，生成多轮 trajectories。
2. 记录每条轨迹的 reward 和 behavior log-probs。
3. 把 trajectory 存入 replay buffer，并赋予 base priority。
4. 当前 fresh batch 仍然做一次 on-policy policy-gradient 更新。
5. CPU 后台线程刷新 replay buffer 中每条样本的 age-decayed priority。
6. 从 buffer 里按 priority 采样 K 个 off-policy replay batches。
7. 对 replay batch 做 importance-sampling correction，再训练当前 policy。
8. 同步 inference engine：πμ ← πθ。

它不是完全替代 on-policy，而是 on-policy 主训练 + off-policy replay 增强。

FreshPER = PER 的优先级 × 一个随 trajectory 年龄指数衰减的新鲜度系数。

1. 当前模型生成一批 fresh trajectories
2. 马上用这批新数据做一次标准 on-policy RL 更新
   —— 这是主训练信号，最干净、最不 stale

3. 把这些轨迹存入 replay buffer
4. buffer 里的旧轨迹根据 reward/advantage 得到 base priority
5. priority 再乘 freshness decay，越旧越降权

6. 从 buffer 里按 priority 抽旧轨迹
7. 因为不是均匀抽样，所以用 IS weight（important sample） 修正采样偏差
8. 因为旧轨迹来自旧 policy，所以用 behavior logprobs / ratio 处理 off-policy mismatch
9. 再额外做 K 次 replay policy-gradient update

简单说：

fresh batch update：
    用“刚生成的数据”正常学一次

importance-sampling correction：
    旧数据被 priority 偏置采样，所以训练 loss 要重新加权，避免高 priority 样本把梯度带偏

FreshPER 论文里写的 PER correction 是：

符号	意思

NNN	replay buffer 大小

P(i)P(i)P(i)

第 i 条样本被采样的概率

β\betaβ

修正强度，通常从小到大 anneal 到 1

wiw_iwi​

第 i 条样本的 IS 权重

论文摘要里说得很直接：PPO、GRPO、REINFORCE++ 这类 on-policy 方法通常在一次 gradient update 后就丢掉 collected trajectories，这在多轮 agentic 任务里很浪费，因为环境交互很贵；FreshPER 的目标就是通过 experience replay 重用过去 trajectories。所以不是出于等待rollout生成时间的充分利用考虑而多update一次，只是为了多利用sample。

https://arxiv.org/html/2604.26256v1

DORA: A Scalable Asynchronous Reinforcement Learning System for Language Model Training

这篇论文是 美团 Meituan, China 发表的。arXiv 页面和论文首页列出的作者单位都是 Meituan，并且通讯邮箱是 zhangchao167@meituan.com。

DORA 想解决的是：LLM RL 训练里 rollout 太慢，尤其长 CoT/长回答拖住整个 batch；它用“多版本 policy 并行生成 + 有界陈旧度 + 动态资源调度 + KV cache 迁移复用”，让训练不用等最慢的轨迹，同时尽量保持标准 PPO/GRPO 的正确性。

论文把异步 RL 要满足的正确性约束总结成三个：

约束	含义
C1 intra-trajectory policy consistency	一条 trajectory 内所有 token 都由同一个 policy version 生成
C2 data integrity	不要为了快而丢弃长轨迹，尤其不要丢长 CoT
C3 bounded staleness	训练时使用的旧轨迹不能太旧，要有确定上界

论文认为，DORA 的目标就是在满足这三个约束的前提下提高吞吐。

DORA 最关键的设计是 多版本 policy 并行 rollout。

它不是只有一个 rollout policy，而是在 rollout workers 上同时维护多个 policy version：

π_0, π_1, π_2, ...

每条 trajectory 在开始生成时会被打上一个 version tag，例如：

trajectory A → π_10
trajectory B → π_10
trajectory C → π_11
trajectory D → π_12

然后规则是：

一条 trajectory 一旦由 π_10 开始生成，就必须全程用 π_10 生成完。

这就满足了 C1。

允许旧版本 policy 继续存在一段时间，把没生成完的长 trajectory 生成完。

dora有个滑动窗口，设置大小为k。如果窗口已经满了，而且最老版本还有未完成 trajectories，那么系统不能继续推进新的 policy version；trainer 可能仍然能消费已有数据，但不能无限更新并发布新版本。此外，它还对kv-cache进行了各种管理，调配不同的block分配。

QaRL: Rollout-Aligned Quantization-Aware RL for Fast and Stable Training under Training–Inference Mismatch

LLM 做 RL 训练时，rollout 生成太慢。把 rollout engine 量化后确实更快，但会带来训练侧 full precision policy 和推理侧 low-bit policy 不一致，导致 RL 更新不稳定。QaRL 就是想在保留量化 rollout 加速的同时，把这个 mismatch 稳住。

它在解决什么问题？

LLM 强化学习一般有三步：

1. rollout：当前 policy 生成回答；
2. forward：训练侧重新算 logprob / ratio / KL 等；
3. backward：根据 policy gradient 更新模型。

论文说，标准 LLM RL 里 rollout 是主要瓶颈，尤其 reasoning 模型要生成很长 CoT，rollout 大约能占 RL 训练时间的 70%。所以很自然的想法是：把 rollout engine 量化，比如 W4A16 / W8A8，让生成更快。

但问题来了：

rollout 是低精度模型生成的，训练更新却是 full precision 模型算的。

也就是说，数据来自一个 quantized policy：

但训练时你用的是 full precision learner：

这会导致 training–inference mismatch。尤其长回答里，量化误差会一步步累积，policy ratio / importance weight 会变得很极端，最后训练不稳定甚至 collapse。论文明确说，单纯 quantized rollout 会放大这个 mismatch。

QaRL 的核心想法是什么？

它不是只把 rollout engine 量化，而是让训练侧 forward 也“对齐” rollout engine 的低精度行为。

可以把它理解成：

你用低精度模型生成 rollout，那训练时算 logprob / ratio 的 forward 也尽量用同样的低精度算子来算。

这样 learner 看到的 policy 分布更接近 rollout 时真实采样的 policy，而不是用 BF16 policy 去解释一个低精度 policy 生成出来的数据。

论文把 QaRL pipeline 拆成三部分：

1. Quantized inference in rollout engine
   rollout engine 用低比特模型生成样本，比如 W4A16 或 W8A8。
2. Rollout-aligned quantization-aware training
   training engine 保留 high-precision master weights，但 forward 时 on-the-fly quantization，并且真的执行 low-bit GEMM，而不是只用 fake quant 模拟量化噪声。backward 用 STE，把梯度更新到 high-precision master weights。
3. Weight synchronization
   训练完一步后，把训练侧已经量化好的低比特权重同步给 rollout engine，避免重复量化，也保证 rollout engine 和 learner forward 尽量处于同一种 low-bit 格式。

这里它很像一个折中方案：

• 不是纯 BF16 RL；
• 不是完全低精度训练 FQT；
• 也不是传统 fake-quant QAT；
• 而是 forward 用真实 low-bit GEMM 对齐 rollout，backward 仍然用高精度 master weights 更新。

这个点挺重要的，宝：它不是为了“量化模型部署”本身，而是为了 让 RL 训练时采样 policy 和更新 policy 更一致。

TFAC: Time-Frequency Token Advantage Clipping for Training Efficient Large Reasoning Model

这篇 TFAC: Time-Frequency Token Advantage Clipping for Training Efficient Large Reasoning Model 的核心想法其实挺契合你最近一直在追的方向：不是粗暴惩罚整条 response 长度，而是在 PPO/RLVR 训练里，对“关键 token”的 advantage / clipping 做更细粒度干预。

1. TFAC 到底在做什么？

一句话：

TFAC 在 PPO 的 token-level clipping 里，把固定 clip 范围换成动态 clip 范围；如果某个高不确定性 token 在当前推理链里重复出现太多，而且超过了历史成功轨迹中的正常频率，就收紧它的 clipping，从而降低它继续被强化的幅度。

它有两个维度：

Frequency 维度：看当前这条 trajectory 里，某个关键 token 出现了多少次。重复越多，越可能是绕圈、反思过度、低效循环。

Time 维度：看同一道题过去成功解法里，这个关键 token 平均出现多少次。这个平均次数被当成“历史成功预算”。如果当前超过这个预算，就认为可能过度思考。

这里的 “Time” 不是 Fourier 的频域时域，也不是 signal processing；它更像是 historical time / 历史成功经验维度。所以“时频”这个名字有点容易误导。

---

2. 什么是 critical token？

它不是人工指定“therefore / wait / however”这些词，而是先用模型输出分布的 entropy 找关键位置。

具体地，对 trajectory：

在每个 timestep ，计算模型在当前 state 下对下一个 token 分布的 Shannon entropy：

然后选 entropy 最高的 top-k 个位置，把这些位置生成出来的 token 当作 critical tokens。论文也特别说明：高 entropy 不是说最终采样出来的 token 本身一定“不确定”，而是说模型在这个状态下面临较大的决策不确定性；他们把最终选出来的 token 当成这个关键决策点的代表。

这个点挺重要：TFAC 干预的不是所有 token，而是 高熵决策点 token。

---

3. 历史成功预算怎么维护？

对每个问题 XXX，论文维护一个历史成功轨迹集合：

这里面只放过去这个问题上生成正确答案的 reasoning trajectories。

然后对某个 critical token ，计算它在历史成功轨迹里平均出现次数：

其中 是 token  在 trajectory  中出现的次数。

这意味着：

如果这道题以前有成功解法，那么 TFAC 知道“成功时这个 token 通常出现几次”。

如果这道题没有成功历史，那么预算设为 ∞\infty∞，也就是 不惩罚、不压制探索。这是它避免 underthinking 的关键设计。

---

4. 它到底怎么改 PPO clipping？

标准 PPO 是：

其中 是新旧 policy 的概率比，是 token-level advantage。论文指出，普通 PPO 用同一个  对所有 token 都一样处理，无法区分关键推理和冗余语言。

TFAC 把固定的 ϵ\epsilonϵ 换成动态的 ϵt\epsilon_tϵt​：

ϵt={ϵhigh⋅γmax⁡(0,c(τ,at)−μ(X,at)),at∈Kτϵhigh,otherwise

其中：

 是当前 trajectory 的 critical token 集合。

c(τ,at)c(\tau,a_t) 是当前 trajectory 中这个 token 已经出现的次数。

μ(X,at) 是历史成功预算。

是衰减系数。

直观解释：

如果 token 没超过历史成功预算，那么：

c(τ,at)−μ(X,at)≤0c(\tau,a_t)-\mu(X,a_t)\le 0c(τ,at​)−μ(X,at​)≤0

所以指数项变成 0，γ0=1\gamma^0=1γ0=1，clip 还是 ϵhigh\epsilon_{\text{high}}ϵhigh​。也就是不额外压制。

如果 token 超过预算，比如超过 1 次、2 次、3 次，那么 ϵt\epsilon_tϵt​ 会指数衰减。超过越多，clip 越紧，policy update 越保守。

GLM-5: From Vibe Coding to Agentic Engineering

arXiv 编号是 2602.15763

训练流程：Pre-training → Mid-training → SFT → 三阶段 RL

论文里 GLM-5 的训练 pipeline 大概是：

Base pre-training：大规模通用、代码、推理语料。
Mid-training：把上下文从 4K 逐步扩到 32K、128K、200K，重点加入长上下文和 agentic 数据。
SFT：覆盖 general chat、reasoning、coding & agent 数据。论文还提到，对于 agent/coding 轨迹，错误片段可以保留，但在 loss 里 mask 掉，让模型学习纠错行为而不是强化错误动作。
RL：分成 Reasoning RL、Agentic RL、General RL。最后还做 On-Policy Cross-Stage Distillation，防止后面的 RL 阶段把前面学到的推理/通用能力冲掉。

这个设计挺重要：它不是“一锅 RL 端到端训完”，而是分阶段把能力叠起来，再用跨阶段蒸馏防止遗忘。

---

3. 最关键部分：异步 Agent RL

你关心的点应该在这里。论文说，长程 Agent rollout 有严重的 tail latency：有些任务几分钟结束，有些任务可能跑很久。如果用同步 RL，训练端必须等最慢的 rollout 完成，GPU 会大量空转。

所以 GLM-5 采用 异步 RL：

生成轨迹的 inference/rollout engine 和训练模型的 training engine 解耦。
rollout engine 持续生成 agent trajectories。
一旦收集到足够数量的轨迹，就直接发给 training engine 更新模型。
training engine 每隔 K 次 gradient updates 把新权重同步回 inference engine。

这本质上是：不要等所有 rollout 都结束；谁先生成完，谁先进入训练。

好处是吞吐高，坏处是数据可能变 stale。因为某条 trajectory 是旧模型生成的，但训练时模型已经更新了好几版。

论文原话的意思是：rollout engine 一直用某个“快照版本”的模型在生成轨迹；trainer 那边可能已经连续做了好几次 gradient update，但 rollout engine 不一定马上跟着变。它们之间是周期性同步，不是步步同步。论文说 inference engine 持续生成 trajectories，够一个阈值后送给 training engine；为了降低 policy lag，rollout engine 的权重会周期性与 trainer 同步，trainer 每隔若干次 gradient updates 才把新权重推回 inference engine。

可以这样理解：

假设同步间隔是 K = 4。

初始时：

trainer:      θ_0
rollout:      θ_0

rollout worker 用 θ_0 生成 agent trajectories。

然后 trainer 收到一些轨迹，开始训练：

gradient update 1: trainer θ_0 -> θ_1
gradient update 2: trainer θ_1 -> θ_2
gradient update 3: trainer θ_2 -> θ_3
gradient update 4: trainer θ_3 -> θ_4

在这 4 次 update 期间，rollout worker 可能仍然在用 θ_0 生成轨迹。

到了第 4 次 update 之后，trainer 才把新权重推给 inference engine：

trainer:      θ_4
rollout:      θ_4

所以“每隔 K 次 gradient updates 同步一次”的意思是：

trainer 先自己连续更新 K 步，然后把当前最新权重打包/广播/加载到 rollout engine；rollout engine 之后再用这个新版本继续生成数据。

它怎么处理 staleness / off-policy？

GLM-5 主要用了三层稳定机制。

第一层：TITO，Token-in-Token-out

同步/异步 RL 里很容易发生一个隐藏问题：rollout 端生成的是文本，trainer 再重新 tokenize 文本，token 边界、空格、特殊符号、截断位置可能不一致。这样 reward/advantage 和 action token 对不上，训练就会脏。

所以 GLM-5 用 Token-in-Token-out：rollout 端直接记录生成时的 token IDs 和 metadata，训练端直接消费这些 token，不做 text round-trip。论文说这个对异步 RL 很关键，因为它保证“采样的 action”和“优化的 action”严格对应。

TITO 不是一个“解决 policy stale 的数学算法”，而是一个“保证 rollout 数据别在传输过程中变形”的工程机制。

RL 训练里，模型真正做出的 action 不是一段文字，而是一个个 token id。

比如模型生成：

print("hello")

在 tokenizer 里它可能对应一串 token：

[1354, 445, 220, 15339, 1117]

rollout 阶段真正采样的是这些 token id。每一步还会记录：

token_id
这个 token 的 logprob
生成它时的模型版本
reward / advantage 对应位置
工具调用 metadata

问题来了：如果 rollout worker 把生成结果转成纯文本发给 trainer，trainer 再重新 tokenize，就可能得到不完全一样的 token 序列。

一个具体例子

假设 rollout worker 实际生成的是：

" hello"

注意前面有一个空格。

在某些 tokenizer 里，它可能是一个 token：

[Token_A = " hello"]

但是如果中间系统把文本 normalize 了一下，比如去掉空格，或者 JSON 转义、换行、特殊字符处理发生变化，trainer 重新 tokenize 后可能变成：

[Token_B = "hello"]

甚至可能变成两个 token：

[Token_C = " he", Token_D = "llo"]

那就麻烦了。

因为 rollout 阶段记录的 logprob 是：

logprob(Token_A)

但 trainer 现在看到的是：

Token_B

或者：

Token_C, Token_D

这时你再算 PPO / GRPO 的 ratio：

ratio = exp(current_logprob - rollout_logprob)

就会变成拿 A token 的旧 logprob 去对 B token 的当前 logprob。

这就像你原本记录的是“张三的考试分数”，结果训练时把它贴到了“李四”身上。不是数值小误差，而是 action 对不上了。

所以 TITO 到底做什么？

TITO = Token-in-Token-out。

意思是：

rollout worker 生成出来的是什么 token id，trainer 就训练什么 token id；中间不要先转成 text，再重新 tokenize。

也就是从：

rollout 生成 token ids
      ↓
decode 成 text
      ↓
发给 trainer
      ↓
trainer 重新 tokenize
      ↓
训练

改成：

rollout 生成 token ids + logprobs + metadata
      ↓
直接发给 trainer
      ↓
trainer 按原 token ids 训练

论文里说 TITO gateway 会拦截 rollout 任务的 generation requests，并记录每条 trajectory 的 token IDs 和 metadata；它的作用就是避免 re-tokenization mismatch，保证“采样的 action”和“优化的 action”严格对应。

第二层：Direct Double-sided Importance Sampling

标准 PPO/GRPO 一般需要 old policy 的 logprob，算：

rt(θ)=exp⁡(log⁡πθ(at∣st)−log⁡πθold(at∣st))

但在异步 Agent RL 里，一条长 trajectory 可能跨越多个 policy version。如果严格追踪 old policy，就要保存很多历史 checkpoint，成本很高。GLM-5 的做法是：直接复用 rollout 时记录的 logprob 作为 behavior policy proxy。公式变成：

rt(θ)=exp⁡(log⁡πθ(at∣st)−log⁡πrollout(at∣st))

然后它不用传统 PPO 那种 asymmetric clipping，而是用 双侧 token-level mask：

f(x;ϵl,ϵh)={x,1−ϵl<x<1+ϵh0,otherwise

也就是说，如果某个 token 的 importance ratio 太大或太小，说明当前 policy 和 rollout policy 在这个 token 上差太远，这个 token 就 不参与梯度更新。

这里很像你之前问过的那些 off-policy / truncation 方法，但 GLM-5 是 token-level mask，不是一定丢掉整条 trajectory。

第三层：直接丢弃过旧 trajectory

GLM-5 还记录每条 response 生成时涉及的 policy weight version。假设一条样本最早来自版本 w0w_0w0​，当前训练版本是 w′w'w′。如果：

w′−w0>τw' - w_0 > \tauw′−w0​>τ

就认为它太 stale，直接丢弃。

这个设计很直接：
轻微 stale 的样本可以通过 importance sampling 修正；严重 stale 的样本直接不要。

这点和 DORA / FreshPER 那些“允许一定陈旧度，但不能无限旧”的思想是同一类问题，只是 GLM-5 这里更工程化：用版本号阈值过滤。

Cache: Verified Semantic Prompt Caching

iclr poster 2026

vCache 把 semantic prompt caching 从“靠一个人工 similarity threshold 碰运气”变成了“每个缓存项在线学习自己的复用边界，并用概率探索和置信区间控制整体错误率”。

它真正强的地方不是“用了 embedding cache”，这个以前就有；而是：

1. 每个 cached prompt 一个动态阈值
2. 在线学习，不需要预训练
3. 用户可以指定错误率上限
4. 在错误率受控的前提下最大化 cache hit

ThinKV: Thought-Adaptive KV Cache Compression for Efficient Reasoning Models

iclr 2026 oral

论文要解决的是：推理模型生成很长 CoT 时，decode 阶段 KV cache 会随着输出 token 数线性增长，很快吃爆 GPU 显存；比如论文举例说 GPT-OSS-20B 生成 32K tokens、batch size 32 时，KV cache 约 50GB，模型权重约 40GB，已经超过 A100 80GB。

eviction 是什么

eviction = 从 KV cache 里淘汰一部分旧 token 的 KV。

比如原本 KV cache 里有 10 个 token：

token1 token2 token3 token4 token5 token6 token7 token8 token9 token10

如果系统觉得 token2、token3、token4 不太重要，就可以 eviction 掉它们的 KV：

保留: token1 token5 token6 token7 token8 token9 token10
淘汰: token2 token3 token4

后面模型生成新 token 时，attention 就不能再完整访问被淘汰 token 的 KV 了。

为什么要 eviction？

因为长推理太占显存。

推理模型可能生成几千、几万 token 的 CoT。每生成一个 token，就多一份 KV cache。显存不够时，就必须做选择：

哪些旧 token 还值得保存？
哪些旧 token 可以丢掉或压缩？

eviction 就是在做这个选择。

---

eviction 和 quantization 不一样

这两个经常一起出现，但不是一回事。

操作	含义	类比
quantization	KV 还保留，但用更低精度存	把高清照片压缩成低清照片
eviction	KV 被淘汰，不再完整参与 attention	把照片从相册里移走
compression	总称，可以包括量化、淘汰、聚合	整理相册省空间

所以在 ThinKV 里：

TBQ 是 quantization：
把不同 thought 的 KV 用不同 bit 数保存。

TBE 是 eviction：
把一些旧 thought segment 的 KV 逐步淘汰，只保留少量代表 token。

ThinkKV怎么做的？

ThinKV 不靠关键词规则来分类。它观察到：不同推理阶段的 attention sparsity 不一样。

论文说，decode step 上的 normalized attention score sparsity 呈现三峰分布，然后他们把这些区域解释成三种 thought type：

Thought type	含义	直觉
R: Reasoning	系统性推理、分析、验证	“我在认真推理主线”
E: Execution	计算、公式推导、代码生成	“我在执行具体步骤”
T: Transition	不确定、转向、回溯、纠错	“等等，刚才可能错了，我换个思路”

它的分类流程大概是：

先离线用一小批 calibration prompts 跑模型，统计不同层的 attention sparsity 分布；用 KDE 找三峰之间的阈值；decode 时每隔一段 refresh interval 重新计算 sparsity，然后根据阈值判断当前 thought type。论文里说 thought segment 通常 100–300 tokens，所以它设置 refresh interval 来减少开销。

特别注意：论文 appendix 里虽然列了 “Think / Wait / Now / code syntax” 这类关键词，但作者明确说这些关键词只是为了帮助解释，不用于 inference 时的 thought identification。真正分类靠 attention sparsity。

ThinKV 的核心方法一：TBQ，Think Before you Quantize

TBQ = 按 thought importance 给不同 token 分配不同 KV 精度。

论文用 counterfactual importance 来分析不同 thought 的重要性：把某个 thought segment 去掉，看最终 answer distribution 的 KL divergence 变化。结果发现重要性层级大致是：

Reasoning R > Execution E > Transition T

也就是说，R 最关键，E 次之，T 通常较不重要；不过也有少数 T 很关键，因为它可能代表 backtracking，如果完全删掉会导致模型陷入循环。

于是它的量化策略是：

Thought	KV 精度
R	最高精度，理论设计中 8-bit，实践中常用 4-bit
E	4-bit NVFP4
T	2-bit ternary

论文最终实验里采用的是 R4E4T2：Reasoning 和 Execution 用 4-bit，Transition 用 2-bit。Keys 按 channel 量化，Values 按 token 量化，类似 KIVI 的思路。

这里的关键点是：它不是所有 token 统一 INT2 / INT4，而是按“思考功能”分配压缩强度。

ThinKV 的核心方法二：TBE，Think Before you Evict

TBE = 按 thought segment 粒度逐步驱逐 KV token。

它的观察是：当模型生成 Transition thought 时，往往意味着推理轨迹发生变化。比如模型写了 “Wait, maybe this is wrong...”，那之前某些 reasoning segment 的重要性会下降。论文通过 pairwise thought association 发现：每出现一个 T thought，之前的 thought segments 对后续的影响会逐渐变弱。

所以 TBE 的策略是：

当出现一个 transition thought 后，不是立刻暴力丢掉所有旧 token，而是对前面的 thought segment 做 progressive eviction / annealing：

第一次被选中，保留多一点；
第二次再被选中，保留更少；
多次 transition 后，旧 thought segment 被逐步压缩到最小保留量。

论文设置每个 thought segment 128 tokens，并且最少保留 4 个 token。作者说完全删光会让模型丢失已探索轨迹，可能进入 endless reasoning loop。

至于“保留哪几个 token”，它用 K-means 聚类 post-RoPE key embeddings。简单说，对一个 thought segment 里的 key 向量聚类，保留靠近 centroid 的代表性 token 的 KV。

这点可以这样理解：

TBE 不是按单个 token 的 recentness 或 attention score 一步步删，而是说：
“这个 thought 段整体已经不太重要了，我把它压缩成几个代表性 KV。”

在 ThinKV 里 eviction 具体是什么意思？

ThinKV 里不是简单地删最近最老的 token，而是按 thought segment 删除/保留。

比如模型 CoT 是：

R1: 我们先分析题目条件...
E1: 计算 3x + 5 = 20...
T1: Wait, this seems wrong...
R2: 换一种思路...
E2: 重新计算...

当出现 T1 transition thought 时，ThinKV 认为：

模型开始转向了，之前某些旧 thought 的重要性可能下降。

于是它可能对旧的 R1/E1 做 eviction：

R1 原本 128 个 token 的 KV
↓
只保留 32 个代表 token
↓
后面再出现 transition
↓
只保留 8 个代表 token
↓
最后最低保留 4 个代表 token

这叫 progressive eviction，也就是逐步淘汰。

Continuous Thinking 为什么重要？

这部分我觉得是论文很强的地方，不只是算法小 trick。

传统动态 eviction 会带来一个麻烦：你从 KV cache 中间删掉一些非连续 token，显存里就出现“洞”。为了让 attention 能高效读 KV，很多方法需要做 gather / compaction，把剩余 token 搬到一起。但这会产生大量不规则内存访问，吃 HBM 带宽，TPOT 会变慢。论文专门测了 R-KV 的 gather overhead，发现 batch size 上来后会明显拖慢。

ThinKV 的 Continuous Thinking / CT 做法是：

被 eviction 的 token 不立刻物理删除，只是在 block table 里用 eviction mask 标记为可回收；后续新 token 来了，就直接写进这些空槽位。也就是说，它做 in-place slot reuse，避免 gather compaction。

它扩展了 PagedAttention 的 block table，额外记录：

字段	用途
thought type	这个 block 里是什么 thought
start indices	thought segment 起点
segment mask	一个 block 里不同 segment 的位置
eviction mask	哪些 token 已经被标记为 evicted

论文还强调：attention 对 token 排列是 permutation-invariant 的，所以不一定要把 token 物理重排成连续顺序；只要 block table / mask 能正确索引，attention kernel 本身可以保持兼容。

Sem-MoE: Semantic-aware Model-Data Collaborative Scheduling for Efficient MoE Inference

这篇 Sem-MoE 其实是一篇很典型的 LLM serving / MoE 推理系统论文。它不是提出一个新的 MoE 模型结构，而是在问：

MoE 模型推理时，token 总是要跨 GPU 找专家，all-to-all 通信太贵，能不能根据“token/请求大概率会激活哪些专家”提前把数据和专家调度到一起？

论文正式题目在 arXiv 上是 “Semantic Parallelism: Redefining Efficient MoE Inference via Model-Data Co-Scheduling”，OpenReview 页面显示它是 ICLR 2026 Poster，关键词包括 Mixture of Experts、All-to-All Communication、Distributed Inference。

每个 token 在每次 forward 经过 MoE 层时，都要重新选择 expert。不是“整条 request 先选一个 expert，然后一直用这个 expert decode”。

更准确地说：

一次 decode step 生成 1 个新 token；
但这个新 token 要穿过模型的很多层；
如果其中有 MoE 层，那么在每个 MoE 层里，这个 token 都会经过 router/gate；
router/gate 会为这个 token 选择 top-k experts；
然后 token 的 hidden state 被送到这些 experts 计算。

所以 expert selection 的粒度通常是：

per token, per MoE layer

它要解决什么问题

MoE 模型里面，每个 token 不是走所有 FFN，而是由 router/gate 选择少数几个 expert。

比如一个 token apple 进来，gate 可能选择：

Expert 3 + Expert 17

另一个 token Python 进来，可能选择：

Expert 5 + Expert 21

问题是，大模型推理时 expert 通常分布在不同 GPU 上，也就是 Expert Parallelism, EP。如果 token 当前在 GPU 0，但它需要的 Expert 17 在 GPU 3，那 token 的 hidden state 就要被发到 GPU 3，算完再发回来。

这就会产生大量 all-to-all communication。论文说，在 DeepSeek-V2-Lite 的一个初步实验里，EP 通信最多可以占 MoE layer forward latency 的 59.2%，即使是在高速互联的 8-GPU 服务器上也很重。

所以它的核心判断是：

MoE 推理慢，不一定是算力不够，而是很多时间花在 token 跨设备搬运 上。

---

2. Sem-MoE 的核心 insight

它发现一个现象：

token / request 的语义，和它会激活哪些 expert，有比较稳定的相关性。

论文把这个叫做 token–expert affinity，也就是 token 和 expert 之间的“亲和关系”。它声称这种相关性有一定 context-independent correlation，也就是说，某些 token 或某类语义输入，经常倾向于激活某些专家。

这句话很关键。它不是等 gate 算完之后再被动搬 token，而是想提前预测：

这个请求/这些 token 大概率会用哪些 expert？

然后提前安排：

把这些 token 放到更接近这些 expert 的 GPU 上
或者把经常一起被激活的 expert 放到同一台设备上

这就是标题里的：

Semantic-aware Model-Data Collaborative Scheduling
语义感知的模型-数据协同调度

SPARSE ATTENTION FOR EFFICIENT LLM REINFORCEMENT LEARNING