Tre justeringer kuttet Hugging Faces GRPO-kjøring fra 3 t 27 min til 53 minutter

53 minutter tok 500 treningssteg etter justeringene, mot 3 t 27 min i første forsøk, skriver Hugging Face i et teknisk blogginnlegg. Oppsettet trener en rank-1 LoRA-adapter på Qwen2.5-Math-1.5B med AsyncGRPOTrainer i TRL, som fra versjon 1.14 kan synkronisere bare adapteren til vLLM i stedet for hele modellen.

Adapteren er noen få megabyte, mens hele modellen er rundt 3 GB. Den kan derfor flyttes via en Storage Bucket som er montert på samme sti i alle Jobs, så treneren og vLLM-replikaene kjører på hver sin maskin uten NCCL. En liten proxy legger på autentisering, sender hver ny adapter til alle replikaene og ruter hver rollout til replikaen som allerede har prompt-prefikset i KV-cachen. Etter 64 728 rollouts traff rutingen cachen i 84,5 % av tilfellene.

Første kjøring utnyttet bare 3,9 % av GPU-kapasiteten (MFU), fordi treneren behandlet én sekvens om gangen, 64 ganger per steg. Tre endringer flyttet flaskehalsen fram og tilbake mellom trening og generering:

1. Et token-budsjett på 16 384 pakket rundt 13 sekvenser per rad, og forward og backward falt fra 21,9 til 5,6 sekunder.
2. Gradient checkpointing, som er på som standard, ble slått av fordi 1,5B-modellen får plass i minnet uten.
3. Taket på samtidige forespørsler økte fra 128 til 384. Taket gjaldt hele rollout-arbeideren, så en tredje vLLM-replika hjalp nesten ingenting før det ble hevet.

Belønningskurven endret seg knapt: siste kjøring endte på 0,416 mot 0,438 i den første, og trente på 31 % flere eksempler. Oppskriften ligger i repoet hfjobs-lora-buckets, med en røyktest på 20 steg som tar rundt 15 minutter.

For deg som finjusterer egne modeller med RL er lærdommen bredere enn Hugging Face-infrastrukturen: sammenlign ventetiden på rollouts med køens mottrykk før du kjøper flere GPU-er, for flaskehalsen satt to ganger i treneren og én gang i en klientkonstant.