J'ai récemment discuté avec beaucoup de personnes travaillant sur le RL, et j'ai remarqué quelque chose d'intéressant : chaque fois que la conversation tourne autour de l'infrastructure RL, elle gravite presque toujours vers un sujet : l'alignement entre l'entraînement et l'inférence. Comment maintenir la cohérence entre les politiques d'entraînement et d'inférence. Comment contrôler le degré hors politique. Comment gérer la différence de probabilité logarithmique après l'introduction de l'asynchrone. Ce sont toutes des questions importantes, sans aucun doute. Mais je suis de plus en plus convaincu que l'infrastructure RL souffre d'une allocation d'attention significativement déséquilibrée. Empruntant un cadre à une discussion récente avec un collègue, j'appelle cela l'Effet Baril de l'infrastructure RL. Un baril ne contient que l'eau de sa douelle la plus courte. Le débit et la justesse d'un système d'entraînement RL fonctionnent de la même manière : ils ne sont pas déterminés par le module que vous avez le plus optimisé, mais par celui que vous avez le plus négligé. L'alignement entre l'entraînement et l'inférence pourrait être la douelle que vous avez poncée et polie à la perfection. Mais si la stabilité de votre bac à sable est un désastre, si votre pipeline de récompense est constamment bloqué, et si votre observabilité de bout en bout est pratiquement inexistante — quel est l'intérêt d'un alignement parfait ? La capacité du système est déjà limitée par chaque autre maillon faible. C'est fondamentalement différent de la manière dont l'optimisation des systèmes d'inférence fonctionne. En tant que moteur d'inférence, SGLang a un énorme espace stratégique pour l'optimisation, mais son pipeline est relativement linéaire : traitement de la demande, pré-remplissage, décodage. Vous pouvez isoler les goulets d'étranglement module par module, et le couplage entre les composants est gérable. L'entraînement RL est une bête complètement différente — une boucle multi-systèmes cauchemardesquement complexe : la génération de déploiement dépend du moteur d'inférence, le calcul de récompense peut dépendre d'environnements externes, les mises à jour de politique dépendent du cadre d'entraînement, et le prochain tour de déploiements dépend de la politique mise à jour. Si un seul maillon casse, toute la boucle s'effondre. Malheureusement, d'après ce que j'ai vu au cours de l'année passée, il y a encore de nombreux points faibles sous-estimés : Fiabilité du Bac à Sable de l'Agent. C'est probablement le travail le plus sale, le plus épuisant et le moins glamour sur le plan académique dans l'infrastructure RL aujourd'hui. Le RL basé sur des agents a besoin d'un bac à sable d'exécution fiable pour les déploiements — cela semble simple, mais s'avère être un cauchemar. Stabilité des conteneurs, latence de démarrage à froid, fiabilité de l'isolation des ressources, gestion de l'état du bac à sable — ces choses semblent découplées sur le papier, mais les produits de bac à sable disponibles sur le marché sous-performent systématiquement les attentes. Le bac à sable des agents n'est pas un problème d'algorithme, mais il détermine directement votre efficacité de génération de données, ce qui à son tour détermine votre vitesse d'entraînement. Observabilité. Le débogage du pré-entraînement est relativement simple : regardez la courbe de perte, vérifiez la norme du gradient, et vous pouvez généralement identifier le problème. Mais le débogage du RL nécessite des capacités de traçage de bout en bout : distributions de qualité de déploiement, statistiques de récompense, degré hors politique, magnitudes de mise à jour de politique, et même attribution de la différence de probabilité logarithmique (la différence vient-elle du côté de l'inférence, ou du retard de version de l'entraînement asynchrone ?). Malheureusement, la plupart des équipes que j'ai rencontrées volent essentiellement à l'aveugle sur ces dimensions. Cela conduit à une situation délicate : lorsque les résultats de l'entraînement sont médiocres, vous ne savez même pas quel module blâmer. Le Dilemme de l'Échelle. De nombreuses optimisations de l'infrastructure RL ne montrent un impact mesurable qu'à une échelle suffisante. Les expériences à petite échelle ne révèlent souvent aucune différence significative — non pas parce que l'optimisation est inutile, mais parce que le bruit est trop élevé et le nombre d'étapes trop faible pour que le signal émerge. Pourtant, les expériences à grande échelle sont prohibitivement coûteuses. Cela crée un cycle vicieux : vous ne pouvez pas prouver que votre optimisation fonctionne à petite échelle, donc vous ne pouvez pas sécuriser les ressources pour des expériences à grande échelle ; et sans validation à grande échelle, votre optimisation est éternellement bloquée à "théoriquement, cela devrait aider." L'investissement de l'industrie dans l'infrastructure RL est gravement déséquilibré par rapport à sa complexité réelle. La plupart des équipes la traitent comme un travail de réparation sur l'infrastructure de pré-entraînement — prendre un cadre d'entraînement prêt à l'emploi, ajouter un moteur d'inférence, les coller ensemble avec des scripts, et appeler cela l'infrastructure RL. Mais la complexité systémique de l'entraînement RL et du pré-entraînement n'est même pas dans la même catégorie. Les pipelines de pré-entraînement sont linéaires, homogènes, et ont pratiquement zéro dépendances externes. Les pipelines d'entraînement RL sont cycliques, hétérogènes, et dépendent fortement des environnements externes. Appliquer l'état d'esprit architectural du premier au second est garanti de heurter un mur à grande échelle. La véritable difficulté en ingénierie des systèmes ne consiste pas à pousser un module unique à son extrême — il s'agit de comprendre le couplage entre les modules et l'espace de compromis global. Cela est vrai pour les systèmes d'inférence, et encore plus pour l'infrastructure RL, où les dimensions de couplage sont plus grandes, les boucles de rétroaction sont plus longues, et la densité d'information pour le débogage est beaucoup plus faible. Je veux conclure avec deux questions auxquelles j'ai réfléchi, et j'aimerais entendre d'autres personnes travaillant dans cet espace : Où exactement les rendements marginaux de l'alignement entre l'entraînement et l'inférence commencent-ils à diminuer ? Une fois que l'asynchrone est introduit, le degré hors politique est déjà substantiel. Sur cette base, le gain incrémental d'un alignement supplémentaire est-il réellement un meilleur retour sur investissement que d'investir le même effort d'ingénierie dans la stabilité du bac à sable, l'optimisation du pipeline de récompense, ou l'infrastructure d'observabilité ? J'ai ma propre réponse provisoire, mais je pense que cette question mérite une réflexion sérieuse de la part de plus de personnes — plutôt que de se contenter de l'alignement comme priorité absolue simplement parce que c'est le sujet le plus visible. Et il y a une raison pour laquelle c'est le plus visible : l'alignement entre l'entraînement et l'inférence a une formalisation mathématique claire et produit des ablations élégantes — c'est un ajustement naturel pour les articles. Mais comment rédigez-vous un article sur la stabilité du bac à sable ? Comment encadrez-vous la fiabilité de l'orchestration des conteneurs comme une histoire académique ? Vous ne pouvez pas, vraiment. Donc, ces problèmes sont collectivement ignorés. Même si un système d'infrastructure RL atteint un alignement entre l'entraînement et l'inférence au niveau des bits, l'efficacité globale peut encore être désastreuse — parce que le goulet d'étranglement s'est déplacé ailleurs il y a longtemps. Dans quelle mesure l'infrastructure RL peut-elle être standardisée ? Les systèmes d'inférence ont des métriques de référence relativement bien définies — TTFT, TBT, Débit. Ces indicateurs objectifs nous permettent d'évaluer clairement l'impact des optimisations. Mais quels sont les standards d'évaluation pour l'infrastructure RL ? Débit d'entraînement ? Efficacité d'échantillonnage ? Temps total de traitement de bout en bout ? L'architecture optimale peut varier considérablement selon les scénarios (génération de code vs. agent vs. raisonnement). Si nous n'avons même pas de consensus sur ce à quoi ressemble "une bonne infrastructure RL", alors le savoir-faire en ingénierie dans ce domaine sera extrêmement difficile à accumuler et à réutiliser. Que le RL soit le chemin critique pour améliorer les capacités des modèles — ce jugement est encore en évolution. Mais si la réponse est oui, alors l'infrastructure est le goulet d'étranglement le plus sous-estimé sur ce chemin. Pas parce que personne ne travaille dessus, mais parce que l'attention collective est mal allouée. La cruauté de l'Effet Baril est la suivante : peu importe la hauteur de votre douelle la plus haute, elle ne peut pas sauver le système. L'infrastructure RL n'est pas une préoccupation secondaire. C'est un domaine d'ingénierie des systèmes indépendant et de haute complexité. Ce n'est qu'en le traitant comme un citoyen de première classe que nous aurons une chance de faire évoluer le RL.