无 NCCL 也能训 RL：HF Jobs 上用一个桶、一个代理，把训练和推理拆到两台机器

代理为什么必须存在：不只是加个 header

如果只是加鉴权头，代理没必要专门写。它真正必要，是因为有两件事只有代理能做：

广播加载：适配器要在两台 vLLM 上同时可用，才能让 TRL 假装自己面对一个逻辑上的推理服务器。代理的 /v1/load_lora_adapter 走的是 all-or-nothing 语义：任何一台加载失败，已经加载成功的那台要马上 unload 回滚，返回 504。原因是 FUSE 挂载偶尔会有传播延迟，第一次没读到很正常，代理里带一个 0.5 秒的重试就能把 252 次加载做到 100% 成功——其中 246 次一遍过，6 次要第二次。

KV 缓存亲和路由：这是全篇最工程化的一段。vLLM 内部把 KV cache 按 16-token 的块（block）粒度缓存，同一个前缀已经算过的块下次可以复用，跳过 prefill。GRPO 训练里同一个 prompt 会被采样 8 次，如果 8 次全都路由到同一台 vLLM，后面 7 次 prefill 就能直接命中。代理的路由算法是这样的：

1. 把请求的 token 序列切成 16-token 块，从种子（适配器名）开始做链式 blake2b 哈希。为什么必须链式？因为 KV cache 里第 3 块的值是否有效依赖前 1、2 块完全一致，中间任何一个 token 不同，第 3 块的哈希就应该不同。
2. 每个块的哈希被记录：哪些副本已经 serve 过、有哪些不同的后继块。如果一个块有多个后继，说明它是「大家共享的开头」（模板文本、system prompt），不能拿来判断谁「独占」了这个 prompt。
3. 找到「独占块数」最多的副本。如果它当前 inflight 请求比最少的副本多不超过 8 个，走亲和；否则走溢出到最闲的那台。

跑完一轮 64,728 次 rollout 的分布是：亲和命中 84.5%（54,712 次），因为负载不均衡而放弃亲和的溢出 1.3%，全新 prompt 只能均匀分发的 14.2%——理论最小值是 12.5%（每 8 个 rollout 里必然有 1 个是首次出现）。这意味着大约 35,000 次 prefill 被完全跳过。

五轮跑：把「训快点」拆成可诊断的路径

这一段是这篇博客对做 RL 训练工程的读者最直接的启发。作者没有一开始就给最优参数，而是从一份「能跑但慢」的配置出发，一轮一轮读指标、改一个变量、再读指标。三个指标是他们的诊断三剑客：

• sample/rollout_queue_size：训练器和采样器之间的缓冲队列，看它是满的还是空的
• perf/rollout_wait_s：训练器等采样的时间
• rollout/backpressure_s：采样器因为队列满而被憋住的时间

判断规则：队列满 + 训练器不等 + 采样器被憋 → 训练器慢；队列空 + 训练器在等 + 采样器不憋 → 采样器慢。

Run 2 上 token budget packing 的效果。图片来源：Hugging Face 官方博客

Run 1（基线）：3h 27min，MFU 3.9%。每步 22.9 秒，前向+反向 21.9 秒。队列 476/512 常满，采样器空转。判定：训练器是瓶颈。为什么这么慢？batch/samples_per_row=1.0，也就是一行只装一个样本、64 个微批。GPU 大量算力浪费在 padding 上。

Run 2：token_budget=16384、gradient_accumulation_steps=6。让每一行装满 token 而不是每一行一个样本。结果：每行 12.7 个样本、微批 6 个、步时 5.9 秒、MFU 提到 19%。生成端从 4.6k tok/s 涨到 25k tok/s，副本终于不闲。这一步是 4 倍加速，也是全部 5 轮里收益最大的一步。

Run 3：关闭 gradient checkpointing。checkpointing 会在反向传播里重算前向，代价是「反向≈2×前向」。但 LoRA 训练里 base weights 冻结，反向可以只算适配器那部分。关掉后反向少 1 秒，队列从 420 掉到 71——瓶颈第一次翻到生成端。

Run 4：加第三个 vLLM 副本。但奇怪的是加速不明显，rollout/inflight 卡在 128。翻代码发现是客户端的 max_inflight_tasks=128 上限撞到了，不是 vLLM 满载。这里的教训是：加副本前先确认瓶颈是不是 GPU，不然只是给不用的机器付钱。

Run 5：把 max_inflight_tasks 提到 384、queue_maxsize 提到 768。三个副本各拿 128 并发。53 分钟跑完 500 步，MFU 23.5%，生成 27.5k tok/s。队列又满了，瓶颈又回到训练器。这时候再加副本就没意义了，只有换更多训练卡才有效。

同一个 recipe，同样的 reward 终点，run 5 用 52 分钟走完 run 1 需要 3 小时 26 分的路。图片来源：Hugging Face 官方博客

reward 曲线的重合本身是最重要的验证：这不是拿收敛质量换速度，是同一个训练结果、同一个终点、同一个 ratio≈1.000，只是把中间的等待都消灭了。

对中文语境的启发：三个可以带走的模式

第一，桶就是一个「延迟一点的共享文件系统」。这个视角本身就是一次心智解绑。绝大多数分布式训练的教程都在教你怎么在 NCCL、Ray、TorchDistributed 之间选，好像跨机通信必须是同步的、必须是 tensor 级的。这篇的思路是：如果我要同步的东西只有几 MB、每几秒同步一次，我完全可以用一个最普通的对象存储加一次原子改名把它变成一个软性的同步机制。它不 real-time、有几百毫秒延迟，但 GRPO 那种「大约每几步同步一次」的场景压根不需要 real-time。

第二，前缀缓存 + 版本号的问题会在任何复用推理服务器的训练场景里出现。不止 vLLM，任何带 KV cache 的推理系统都会碰到「权重更了、cache 没更」的情况。工程惯用的解法是要么显式把 cache 冲掉、要么让新旧策略走不同的命名空间。HF 团队选了后者——这个思路可以直接搬到 SGLang、TensorRT-LLM 上，只要你的推理服务器支持按 adapter/model 名做 cache 隔离。

第三，性能优化必须靠指标而不是靠感觉。5 轮里每一次改动都对应一个可测的现象：队列满不满、wait 长不长、backpressure 高不高。这三个数就是一台 RL 训练机的血压计。如果你的训练系统连这三个数都没有埋点，那么你所有的「跑起来慢」都只是猜测。这一点对国内很多快速搭起 RL pipeline 的团队尤其相关——很多系统跑到「能训出来」就停了，从来没测过 MFU、从来没看过队列长度，「慢」和「快」之间的路径根本无法复现。

想上手：能拿走的东西

HF 团队给了完整可跑的代码：github.com/AmineDiro/hfjobs-lora-buckets。快速验证只要 15 分钟（MAX_STEPS=20 ./run_all.sh --wait），跑完整 run 5 的最优配置 55 分钟左右，按 4×H200 的价位大约 18 美元一轮。

配套是三份文档：TRL 的 AsyncGRPOTrainer 文档写清楚了所有可观察的指标，Storage Buckets 讲桶怎么建，hf-mount 讲挂载的 FUSE 层。

如果你想自己 fork 出一份国产云版本，需要替换的只有两件事：一个能被多机以 FUSE 挂载的对象存储（阿里 OSS、腾讯 COS 都有类似能力，加个 s3fs 或 ossfs 就行），以及一个能像 HF Jobs 那样跨机器分配 GPU 容器的编排层（自建 K8s + gpu-operator 就够）。核心的三个组件——LoRA-only 同步、带版本号的适配器、KV 亲和路由——都是与云平台无关的，全部在 TRL/vLLM 侧。

一个观察

这篇博客最反常识的一点，其实不是技术。它花了大量篇幅记录了 5 轮跑的每一次弯路：一开始 MFU 只有 3.9%、加副本以为会快但被客户端限流卡住、以为需要更大 batch 但发现是 padding 浪费。大部分工程博客只写「最优解」，这一篇把「怎么找到最优解」摊在桌面上。这种写法比直接给一个最终参数表值钱得多——参数表 3 个月就过期，方法论不会。