The idea of building a personal site started back in September last year. I got a student-discounted instance from Alibaba Cloud (2 cores, 2GB RAM), and even went through the hassle of registering a domain name: changyi.fun. At first, I used WordPress. It worked — until it didn’t. I remember in one of my security classes, the professor specifically called out WordPress for being notoriously insecure. Around the same time, I tried to set up an SSL certificate (in the most complicated way possible via DNS challenge), and ended up completely breaking the site. I didn’t know back then that there were simpler ways. ...

Delta Weight Sync：当 RL 的权重同步从硬件问题变成软件问题 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 需要在系统的哪些环节进行改动。 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 阶段。 ...