论文精读｜TAO：面向 LLM Agent 服务的工具感知联合调度
Agent 会话有九成以上的时间在等 CPU 上的工具调用。TAO 用一个按字典序比较的三元组给等待中的会话估值，再用多背包动态规划一次性决定谁上 GPU、上哪台。这篇精读按论文原始数据复现了关键图表，也标出了它没赢的地方。
Writing
11 posts, newest first.
大模型强化学习中的 KL 散度与 K3 估计器：从数学推导到训推一致性
KL 散度在大模型强化学习里既是约束策略不跑偏的那根绳，也是检验推理与训练引擎数值一致性的探针。本文从三种蒙特卡洛估计器推导到 k3 的方差优势、PPO 与 GRPO 的梯度差异，并用 PyTorch 示例与 verl 的实际实现做对照。
Ray-Learn（一）：actor、资源账本与三个静默陷阱
主流 RL 框架里有一大半把控制面建在 Ray 上，但它们几乎都不用 Ray 的上层库。这一篇从 task / actor 的语义讲起，把资源账本的「账面数字」和物理占用拆开，并用三个可复现的实验说明：多机 RL 里最常见的故障，往往不报错。
Ray-Learn（二）：Placement Group、GPU 身份与 rank 稳定
资源从「几张卡」推进到「卡落在哪」。Placement Group 的 gang 语义、 bundle 顺序为什么不可控、get_gpu_ids 如何翻译成 local rank，以及手工 rendezvous 怎样把 N 个 actor 收成一个 torch 进程组。
Ray-Learn（三）：异步语义、引擎子进程与数据面
推理引擎为什么不能塞进 actor 的 event loop，ObjectRef 为什么会自动解引用，故障该分成哪三类，以及 ray.util.collective 在权重广播里的正确姿势。这一篇覆盖 RL 系统里最容易写出「看起来能跑」的那部分代码。
Ray-Learn（四）：生产 API 补全与五种编排范式
runtime_env 的覆盖顺序、具名服务与拓扑调度、作业生命周期；再把 slime、verl、 NeMo-RL、AReaL、prime-rl 放在同一张表上对比。抽象每加一层，代码量涨一个量级—— 选型问题到最后是预算问题。
Ray-Learn（五）：多机角色约束、并发池与进程监督
前四篇把单机语义讲完了。这一篇补上多机上真正会疼的三块：节点角色怎么用自定义资源钉死、同一 actor 里长短任务怎么分池、以及 Ray 与子进程之间的责任边界。另附具名 actor 死亡后的调用语义。
Ray-Learn（六）：附录 · Ray API 对账与源码阅读地图
把 slime / miles / verl / AReaL / NeMo-RL / prime-rl / TransferQueue 里真实用到的 Ray API 压成一张对账表：谁在用、为什么用、对应哪一篇。并给出按框架的阅读顺序，以及明确可以不学的部分。