Depuis le blog chinois de Zhihu chinois (2025/5): https://zhuanlan.zhihu.com/p/23147932785

Récemment, il y a eu pas mal de discussions et de controverses en ligne sur OpenRLHF et Verl.
En tant qu’auteur original, je me sens obligé de publier une déclaration.

En bref: OpenRlhf est comme Kartrider – l’original – et Verl FSDP est comme la vitesse QQ, qui est essentiellement un copieur d’OpenRlhf.

1. Différences de performance entre OpenRlhf et Verl

Il n’y a pas de différence de performance fondamentale entre le FSDP RLHF de VERL et OpenRLHF (Deeppeed) car les deux utilisent VllM pour l’inférence et zéro3 pour la formation.
Les données de performance dans le papier d’origine de Verl étaient basées sur Mégatron RLHF contre l’ancienne version Openrlhf 0.2.
Si vous pensez qu’il y a un grand écart de performance, vous l’avez probablement simplement utilisé de manière incorrecte. Pour le moment, le FSDP est légèrement plus rapide que Deeppeed, mais avec la sortie de Deeppeed compile profonde et surtout AutotpDeeppeed devrait dépasser les performances.

2. Sur HybridFlow Free Scheduling

Tout cadre RLHF développé avec Ray peut obtenir une planification gratuite car Ray Native fournit le groupe de placement fonctionnalité.
Cela signifie que HybridFlow dans l’article de Verl est essentiellement juste un nom plus beau pour l’API du groupe de placement de Ray.
Actuellement, OpenRLHF implémente entièrement HybridFlow, contrairement à Verl.
OpenRLHF prend également en charge le déploiement indépendant de VLLM et d’acteurs pour prévenir les problèmes OOM lors de la formation de très grands modèles (32b + ou de texte long).
En fait, Openrlhf était le d’abord Framework pour prendre en charge cette fonction basée sur l’API du groupe de placement de rayons.

3. moteur hybride

Le moteur hybride a été proposé pour la première fois par De profondeurpas une contribution originale de Verl.
Verl et OpenRLHF prennent désormais en charge cette fonctionnalité.

4. Ray + VllM + Transformers HF + Zero3 pour la formation RLHF

Cette configuration est l’une des le plus simple et le plus convivial Solutions de formation RLHF haute performance, combinant la facilité d’utilisation avec les principales performances.

Il a été proposé pour la première fois et open par OpenRLHF (open source en août 2023, la plupart des fonctionnalités terminées d’ici janvier 2024).
verl fsdp entièrement copié cette configuration.

https://preview.redd.it/vfzm143vroif1.png?width=1440&format=png&auto=webp&s=10d8a5bcd10145a06a3506f037abc10f12dd277

https://preview.redd.it/tqela8mvroif1.png?width=1440&format=png&auto=webp&s=c3a2daa1ead45f7434184f107da8ba2f78cc9c8d

L’idée principale à l’époque était d’utiliser le format de poids HF comme un pont, permettant une synchronisation de poids transparente et une inférence à haute performance basée sur des mécanismes Zero3 / AutoTP, éviter Des cadres poids lourds comme Megatron.

L’architecture OpenRLHF originale:
Ray + Vllm + Zero + Hf

Il existe également de nombreux détails de mise en œuvre connexes:

• Liste des fonctionnalités prises en charge
• Des interfaces standardisées telles que --input_key Pour spécifier le format de champ de saisie

Tous ces éléments dans Verl FSDP étaient modélisé après openrlhf.

Exemple des détails du code:
Verl:

https://preview.redd.it/b8f2lprwroif1.png?width=1440&format=png&auto=webp&s=a0daf3eab1c77f71e4917c044f988c35e229baa4

https://preview.redd.it/exf7lxhxroif1.png?width=1440&format=png&auto=webp&s=220636cea299502df1b94e2544a76b34e2acb6c7

OpenRlhf:

https://preview.redd.it/qfakvovyroif1.png?width=1440&format=png&auto=webp&s=260775676354a50bacd79ce06fb25417a53466dede

Autres idées de conception comme Ref_reward déchargement, Critique Pretrain, RM distantetc., ont également été conçus ou proposés par OpenRLHF, et Verl FSDP implémentent plus tard des fonctionnalités correspondantes.

5. Contrôleur unique

(Mise à jour en mai 2025)

Le concept «un seul contrôleur» mentionné dans le papier Verl provient du même modèle de conception de rayons que HybridFlow.

Dans les premières versions de l’implémentation Ray RLHF d’OpenRLHF, il y avait un RayPPOActorGroup concept – gérer un groupe de processus DP de profondeur zéro avec une classe de groupe de rayons uniques et fournir un async_run_method Interface pour contrôler tous les processus du groupe à la fois.
C’est essentiellement l’idée principale d’un seul contrôleur.

https://github.com/openrlhf/openrlhf/blob/494850f50342ed38d5ae76ef45a3207f3523b582/openrlhf/trainer/ray/launcher.py#l300

Cette interface n’a pas été activée au début car la base de code devait être compatible avec les chemins RLHF Ray et non rayons. Plus tard, lorsque le code non rayé a été supprimé, l’API a été naturellement activée.

Enfin, je tiens à remercier ByTedance pour l’ouverture de son cadre interne pour que tout le monde puisse utiliser et entretenir, ce qui aide la communauté open source à prospérer (par exemple, le soutien FSDP / ULYSSES).

Cependant, j’espère que les amis de la communauté ne dénigreront pas d’autres cadres open source.
Openrlhf, comme un à budget zéro, purement ouvert Project, ne peut pas rivaliser dans la vitesse de développement avec de grands projets commerciaux comme Verl—
J’espère seulement que ce post aide à préserver les contributions que OpenRLHF a apportées à la communauté open-source RLHF.

BTW, la communauté open source devrait respecter l’originalité afin de se développer sainement.