Contexte et objectifs
Le fine‑tuning de modèles par renforcement learning (RL) combine entraînement, inférence et exécution d’agents dans un même cycle. Cette charge de travail, décrite par Sunil Arora de Google Cloud, impose des exigences d’infrastructure très élevées, notamment la capacité à exécuter des millions de commandes isolées pour calculer les récompenses. Face à ce besoin, l’équipe GKE Labs a développé OpenRL, un projet destiné à décorréler le « loop » RL du « plumbing » de calcul.
Architecture d’OpenRL
OpenRL, présenté en aperçu de recherche en juin 2026, expose une API d’entraînement auto‑hébergée que les entreprises peuvent déployer sur leur propre cluster Kubernetes. L’API sépare explicitement deux primitives : la logique de l’agent RL (définie par les chercheurs) et les ressources de mise à l’échelle (gérées par les ingénieurs d’infrastructure). Cette séparation repose sur les mécanismes natifs de GKE, qui orchestrent le scaling horizontal des pods tout en conservant la cohérence des expériences.
Le projet a été transféré à la Cloud Native Computing Foundation (CNCF), ce qui garantit une gouvernance ouverte et une intégration avec l’écosystème Kubernetes existant.
Gestion du sandbox et sécurité
Un des défis majeurs du RL sur Kubernetes est la création de sandbox sécurisées où chaque action d’agent peut être exécutée sans impacter le système hôte. Google a introduit le Agent Substrate, une couche qui regroupe plusieurs sandbox sur un même nœud de calcul limité. Cette approche maximise l’utilisation du CPU et de la mémoire tout en maintenant l’isolation requise pour le calcul des récompenses.
Le risque d’opérations destructrices a été illustré par le développeur Justin Santa Barbara, qui a évoqué kubectl‑ai capable, en théorie, de formater un disque dur. Grâce à l’Agent Substrate, une telle commande serait confinée à une sandbox, évitant toute altération du matériel réel.
Implications pour l’infrastructure AI
En externalisant le scaling vers GKE et en confinant les actions d’agents dans des sandbox, OpenRL réduit la complexité opérationnelle pour les équipes de recherche. Les ingénieurs d’infrastructure n’ont plus à gérer manuellement le provisionnement de ressources pour chaque itération du RL, ce qui accélère les cycles d’expérimentation. Par ailleurs, la donation du code à la CNCF ouvre la porte à des contributions tierces, potentiellement capables d’ajouter des optimisations de réseau ou des stratégies de placement de pods spécifiques aux charges RL.
Cette séparation des responsabilités, bien que bénéfique, introduit une dépendance accrue à la stabilité du plan de contrôle Kubernetes et aux mécanismes de sécurité des sandbox. Toute faille dans l’Agent Substrate pourrait exposer le cluster à des actions d’agents malveillants, soulignant l’importance d’audits continus et de mises à jour régulières.
