无 NCCL：HF Jobs 上 LoRA 异步 GRPO 训练

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

Hugging Face 的 Amine Dirhoussi 等人展示了在 HF Jobs 上跑异步 GRPO 的完整工程细节：LoRA 只同步适配器、共享存储桶替代 NCCL、代理做 KV 缓存亲和路由。同一份 recipe 从 3 小时 27 分钟压到 53 分钟，MFU 从 3.9% 提到 23.5%——每一步的诊断路径都写进了指标里。

本文基于 Hugging Face 团队 2026 年 9 月 10 日发表的《Async GRPO with LoRA across HF Jobs: a bucket, a proxy, and no NCCL》（作者 Amine Dirhoussi、Quentin Gallouédec、Kashif Rasul、Sergio Paniego），原文见 huggingface.co/blog/asyncgrpo-lora-hfjobs。我在原文之外接入了 Thinking Machines「LoRA Without Regret」的信息论论证，用来解释为什么整套架构成立的物理前提是 rank-1 就够——不理解这一步，后面的桶和代理都只是奇技淫巧。

一句话：把 GB 级的权重同步换成 MB 级的适配器同步，一切都变得可能

强化学习训练最痛的地方在于「训练器和采样器必须紧耦合」。GRPO 每几个优化器步就要把最新权重推给推理端，让 rollout 用得上最新策略。传统做法是训练和 vLLM 共享节点，靠 NCCL 或本地文件系统直接搬 tensor。可一旦搬到「一个容器一台机器」的云环境（比如 Hugging Face Jobs），跨节点没 NCCL、没共享磁盘、连 localhost 都不通，这套逻辑瞬间失效。每次同步搬 3GB 的权重穿越公网，训 500 步花几小时都不够。

HF 团队的解法看起来很朴素：只训 LoRA 适配器，只同步适配器。rank-1 的 LoRA 适配器对于 1.5B 模型只有几 MB，走一个挂在所有 Job 上的存储桶就行——桶就是那个「延迟一点、但够用」的共享文件系统。5 次调参跑下来，同样 500 步的训练从 3 小时 27 分压到 53 分，模型 FLOPs 利用率（MFU）从 3.9% 拉到 23.5%，reward 曲线几乎完全重合。这不是「快了一点」的量级，是 3.9 倍。

异步 GRPO + LoRA 在 HF Jobs 上的三 Job 架构：训练 Job 里跑 AsyncGRPOTrainer 和代理，两个 vLLM Job 各占一张卡，一个存储桶挂在三者同一个路径下

架构图。TRL 只跟本机的代理讲话，代理转发到两台 vLLM，适配器目录走桶。图片来源：Hugging Face 官方博客

第一步：搞明白为什么 rank-1 不吃亏

如果 rank-1 只是「凑合能用」，这套架构根本没意义——每次同步几百 MB 的中等秩适配器一样搬不动。所以 Thinking Machines 那篇《LoRA Without Regret》是这里绕不过去的前提。他们在 MATH、GSM8K、DeepMath 这几个数学推理任务上，用 policy gradient 类算法（就是 GRPO 家族）系统对比了 LoRA 和 full fine-tuning，结论是：即便 rank 低到 1，LoRA 在 RL 上也能追平 full fine-tuning 的表现。

证据里最有说服力的一环是信息论论证：每一个 RL episode 通过 advantage function 大约只提供 O(1) 比特的有效学习信号——不像 SFT 每 episode 提供 O(tokens) 比特。他们估算 MATH 数据集上 rank-1 LoRA 对 1.5B 模型有 300 万参数量，即便按每参数 1 比特信息容量算，整个训练过程的总信号量也远远填不满这些参数。换句话说：瓶颈是信号量，不是容量。你上更高的 rank，多出来的容量只是空转。

理解了这一层，HF 团队接下来的所有工程选择才有依据：能拿 rank-1 打天下，就不用担心桶传得慢、担心适配器多占内存、担心跨机搬运的开销——这些都被压到工程可接受的范围内。

三个 Job、一个桶：架构本身其实很小

整个系统就四个组件：

训练 Job：跑 AsyncGRPOTrainer（TRL v1.14 起支持 LoRA-only 同步，PR #7017），h200×2 双卡 FSDP。每几个优化器步（默认 4 步）保存一次适配器到 <output_dir>/.vllm_lora/trl-policy-v{N}，原子改名发布，然后 POST 到 vLLM 的 /v1/load_lora_adapter 端点。

vLLM 副本：两个（或三个）独立 Job，各占一张 H200，跑 vllm/vllm-openai:v0.27.1 镜像。启动时开三个开关：--enable-lora、--max-lora-rank 1、--max-loras 6。为什么是 6？因为 max_staleness=4，训练器要求 vLLM 同时挂载「当前策略 + 前 4 个版本」共 5 份适配器，加上换版本瞬间需要多一个槽位承接新版，所以是 6。少一个，vLLM 就会在同步瞬间静默驱逐一个仍有 rollout 在跑的策略版本。

存储桶：通过 hf-mount 以 FUSE 文件系统的形式挂在三个 Job 的同一路径 /lora 下。训练器写入，vLLM 只读挂载。TRL 和 vLLM 的代码一个字都没改——它俩都以为在跟本地磁盘打交道。

代理：跑在训练 Job 的 127.0.0.1:8000，TRL 只跟它讲话。

这里有一个非常容易踩的坑，几乎所有想复用 vLLM 推理端点的团队都会独立重新发现它一遍：适配器必须带版本号。vLLM 的前缀缓存（prefix cache）是按适配器名字做键的。如果每次都用同一个名字覆盖，权重变了但同名的旧 KV blocks 还在缓存里匹配得上——一个 rollout 的 prefill 走的是老版本、decode 走的是新版本，训练器完全察觉不到，只会看到 ratio 指标从 1.0 慢慢漂移。带版本号（、）就是让「一个名字永远只对应一份权重」，缓存要么命中要么整段作废，永远不会串。