Async GRPO with LoRA across
来自 Hugging Face · 期号 2026-09-10
摘要
Hugging Face 的工程师把 AsyncGRPOTrainer 拆到了三个独立的 HF Job 上跑，训练和推理不再共享一台机器。 关键是把全量权重同步换成了 LoRA adapter 同步。一个 rank-1 adapter 只有几 MB，走 Storage Bucket 挂载的共享文件系统就够了，不需要 NCCL。训练器每几步把 adapter 写到 bucket，vLLM 从 /v1/load_lora_adapter 端点加载。 训练器和两个 vLLM 副本之间加了一个小代理：负责加 auth header、把 rollout 路由到已经缓存了该 KV prefix 的副本、以及向所有副本广播 adapter 更新。 五轮优化跑下来，同一个配方从 3 小时 27 分钟压到了 53 分钟（500 步）。瓶颈分析显示，最开始的瓶颈是训练器跟不上，打包 microbatch、去掉前向重算、加副本、提高 in-flight 上限，每一步都缩短了总时间。 原文给了完整的配置示例和每轮跑分的对照表。
深读
导读 Hugging Face 的工程师将 AsyncGRPOTrainer 拆成三个独立的 HF Job 运行，训练和推理不再共享一台机器。关键是把全量权重同步换成了 LoRA adapter 同步，一个 rank-1 adapter 只有几 MB，走 Storage Bucket 挂载的共享文件系统就够了，不需要 NCCL。读完能理解这套架构的完整设计、路由策略和五轮优化如何将 500 步的训练时间从 3 小时 27 分钟压到 53 分钟。 关键信息 - 训练器、两个 vLLM 副本各跑一个独立的 HF Job，三者通过 Storage Bucket 挂载的共享文件系统交换 LoRA adapter，不使用 NCCL。 - 一个 rank-1 LoRA adapter 只有几 MB（1.5B 模型的全量权重约 3 GB），这是整套方案可行的系统前提。 - 训练器每 4 个 optimizer 步发布一次 adapter，通过 /v1/load_lora_adapter 端点通知 vLLM 加载，vLLM 最多同时保留 6 个 adapter 版本（max_staleness=4 加 2 个额外槽位）。 - 代理负责三件事：添加 auth header、按 KV prefix 将 rollout 路由到已缓存该 prefix 的副本、向所有副本广播 adapter 更新。 - 五轮优化跑下来，同一配方从 3 小时 27 分钟降到 53 分钟（500 步），每次 weight sync 的中位时间从 30.8 秒降到 8.5 秒。 - 252 次 adapter 加载全部成功，其中 246 次一次成功，6 次在第二次重试时成功。 逐节讲解 架构：HF Job、Storage Bucket 与三个独立进程 AsyncGRPOTrainer 原本已经支持训练和生成分离，但要求两者共享文件系统或能组成 NCCL 组。HF Job 是一个容器跑在一台 VM 上，无法跨节点通信，也没有共享本地磁盘。LoRA 让问题变得可解：rank-1 adapter 只有几 MB，可以通过 Storage Bucket 挂载的 FUSE 文件系统在 Job 之间传递。最终架构包含三个 Job：一个训练器（跑 AsyncGRPOTrainer + LoRA + FSDP）、两个 vLLM 副本（各用一张 H200）、一个 Storage Bucket 挂载在三个 Job 的同一路径下，以及一个运行在训练器 Job 上的代理。 训练器不再向 vLLM 发送张量，而是每几步将 adapter 保存到 <output_dir>/.vllm_lora/trl-policy-v{N}，通过原子重命名发布目录，然后调用 vLLM 的 /v1/load_lora_adapter 端点。vLLM 从…