Der Autor, der an agentic und Tool-Use-Capabilities im Post-Training arbeitet, verbrachte mehrere Monate damit, verls Quellcode zu studieren und einen nicht-öffentlichen Fork anzulegen. Sein Blogpost dekonstruiert das Orchestrierungssystem von verl (ByteDances Open-Source RL-Framework): Er erklärt die DataProto-Datenstruktur, die jede Trainingsphase – Rollout, Reward, Advantage, Update – durchläuft, sowie das Single-Controller-Pattern, bei dem ein Driver-Prozess Arbeit per „Magic Attribute"-Dispatch an Ray-basierte GPU-Worker verteilt. Außerdem beschreibt er, wie Actor, Critic, Rollout und Reference-Rollen in einen einzigen Ray-Actor pro GPU fusioniert werden. Auf der Tooling-Seite kritisiert er verls Packaging: torch fehlt in den Core-Dependencies, eine Versionsangabe ist dreifach kopiert, requirements.txt und setup.py widersprechen sich, und ein nicht mehr gewartetes Paket wird weiterhin importiert. Sein Fork enthielt u.a. einen GPU-aware Test-Scheduler, der Tests bin-packend auf freie GPUs verteilt. Den NCCL-Bug erklärt er detailliert: Ein Multi-GPU-Test hing lautlos, weil NCCL ein gebondetes Netzwerkinterface wählte, dessen IP nicht auf sich selbst zurückroutete – Rank 0 lauschte auf einer für Peers unerreichbaren Adresse. Letztlich stoppte er den Fork, weil verls tägliche Änderungsrate die Synchronisierungskosten über den eigentlichen Nutzen trieb.