Comment Control Room bloque l’inférence dans la recherche d’OpenAI

Dans la recherche interne d’OpenAI, Control Room doit bloquer les sorties des modèles au plus tard 35 secondes après réception d’un ordre d’arrêt.

En septembre, pendant une expérience d’apprentissage par renforcement, un agent d’OpenAI a exploité une faille dans le filtrage des requêtes DNS pour interroger un chatbot public. Le système de surveillance a signalé le comportement en moins de quinze minutes. Une personne a commencé à examiner l’alerte trois minutes plus tard. Le rapport d’incident d’OpenAI fait état d’un délai de deux heures et demie avant l’arrêt de l’expérience.

C’est sur la dernière étape, l’exécution de l’ordre d’arrêt, qu’intervient Control Room. Déployé dans l’infrastructure de recherche interne d’OpenAI, le service peut retirer à une tâche l’autorisation de demander de nouvelles sorties à un modèle. Il couvre les évaluations, le traitement de données et les tâches de génération utilisées pour l’entraînement. Les déploiements destinés aux utilisateurs relèvent d’un dispositif d’arrêt distinct, selon l’entreprise. Une autorisation liée à chaque tâche

Au démarrage, une tâche de recherche reçoit un identifiant. Chaque fois qu’elle sollicite un modèle, elle transmet cet identifiant au moteur d’inférence, le logiciel qui exécute le modèle sur les GPU. Le moteur vérifie alors que la demande est toujours autorisée. Si la tâche a été marquée comme arrêtée, il renvoie un refus. Le processus de recherche peut rester actif, et le même moteur peut continuer à servir les autres tâches autorisées.

L’ordre d’arrêt peut venir d’une personne ou du système de surveillance des comportements des modèles. Dans les expériences d’apprentissage par renforcement sur ses modèles les plus avancés, OpenAI fait tourner un second modèle chargé d’examiner les actions du premier. Selon la gravité du signal, la surveillance peut demander directement l’arrêt de la tâche. La restriction suit alors son identifiant, même si elle sollicite ensuite un autre modèle sur un autre moteur. D’où viennent les 35 secondes

Dans sa description technique, OpenAI fait partir le chronomètre au moment où Control Room reçoit l’ordre d’arrêt. L’entreprise indique qu’il faut alors au maximum 35 secondes pour que la tâche ne puisse plus progresser grâce à de nouvelles sorties. Le temps passé à détecter le comportement, à examiner l’alerte ou à décider d’intervenir se situe en amont de cette mesure.

Le délai vient du cache d’autorisations. Pour absorber le volume de requêtes, l’infrastructure conserve brièvement les décisions d’accès. Une autorisation accordée avant l’ordre d’arrêt peut donc encore être utilisée pendant un court laps de temps. OpenAI dit travailler à réduire ce délai jusqu’à pouvoir appliquer l’arrêt immédiatement. Quand le service central tombe en panne

Le même contrôle peut bloquer les requêtes si Control Room devient indisponible. Les moteurs concernés refusent alors les demandes d’inférence jusqu’au rétablissement du service. Lors de l’annonce, OpenAI indiquait avoir déployé ce mode de fonctionnement pour toutes les tâches de recherche sur ses modèles les plus avancés, avec une extension aux autres tâches internes prévue dans les jours suivants.

Le contrôle est placé dans les moteurs d’inférence, dont OpenAI utilise un nombre limité de variantes, alors que le code des expériences change souvent d’une équipe à l’autre. Le laboratoire dit aussi rechercher en continu les moteurs lancés sans cette vérification ou avec le contrôle désactivé.