HF Jobs 上跨机异步 GRPO：用 LoRA、存储桶和代理代替 NCCL

Hugging Face 博客（2026 年 9 月 10 日）介绍了 TRL AsyncGRPOTrainer 的 LoRA 支持落地（PR #7017，随 TRL v1.14 发布）之后的一个实际项目：在 Hugging Face Jobs 上拆分训练与推理，不再依赖 NCCL 或共享 localhost。

架构

• 一个训练 Job 运行 AsyncGRPOTrainer，模型为 Qwen/Qwen2.5-Math-1.5B，LoRA rank 1、alpha 2、作用于 all-linear。
• 两个 vLLM Job（vllm/vllm-openai:v0.27.1），各用一张 H200，提供基座模型并支持运行时加载适配器。
• 三个 Job 以同一路径挂载同一个 Storage Bucket（hf-mount 提供 POSIX 文件系统），训练器把适配器写入 <output_dir>/.vllm_lora/trl-policy-v{N} 并以原子重命名发布，vLLM 再通过 /v1/load_lora_adapter 按路径加载。
• 训练器侧运行一个代理，TRL 只看到 http://localhost:8000。代理负责添加 Authorization: Bearer 头、把状态变更请求（加载/卸载适配器、pause、resume）广播到所有副本，并按 KV 前缀选择副本。

关键设计点

适配器槽位数由 max_staleness 推导：每个版本加 1，再加交换时的一个临时槽，因此 max_staleness=4 对应 --max-loras 6。适配器名带版本号，避免 vLLM 前缀缓存把旧权重下的 KV 块复用到新策略。

路由按 16 token 一块、链式哈希（以适配器名作为种子）统计各副本已服务的块；多个后继的“公共块”（如共享的聊天模板）被排除，只按提示特有块判定亲和。若最佳副本领先最少负载副本不超过 8 个请求则发往该副本，否则转给最少负载副本。

运行结果

训练 500 步、每步 128 个补全、每提示 8 个 rollout，每 50 步存检查点。训练 Job 为 h200x2，两个推理副本各一张 H200，三个 Job 合计约每小时 20 美元。

• 每次权重同步耗时从 30.8 秒降至 8.5 秒（p50，范围 6.6–9.2 秒，共 126 次同步）；其中两副本接受适配器从约 29 秒降至约 7 秒。
• 252 次适配器加载全部成功：246 次第三次尝试成功，6 次第二次尝试成功。
• 64,728 个 rollout 后，路由计数为 affinity 54,712、spilled 820、unmatched 9,196，unmatched 占 14.2%，理论下限为 12.5%。
• 文章称五次运行把同一配方从 3 小时 27 分缩短到 53 分（500 步）。

作者也说明了限制：每个 Job 目前只能单容器、最多 8×H200；非 LoRA 可直接服务的配置（如 DoRA、modules_to_save 或超过 --max-lora-rank 的秩）会回退到合并权重同步；Python asyncio 代理在最多 128 个并发非流式请求下不构成瓶颈，但更高流量可能需要更快的语言实现。