Control Room

Je leistungsfähiger unsere Modelle werden und je größer die damit verbundenen Sicherheitsrisiken sind, desto wichtiger ist es, mögliche Probleme zu erkennen und Modelle bei Bedarf schnell zu stoppen. Dafür haben wir Control Room entwickelt.

Control Room ist ein zentrales System, das Modell-Workloads in unserer gesamten Forschungsinfrastruktur verfolgt und sie bei Sicherheitsbedenken schnell stoppt. Es bindet alle Inferenzworkloads in der Forschung ein, darunter agentisches Sampling für Modelltraining und -evaluierung, Datenverarbeitung und mehr. Das System arbeitet mit unseren Systemen zur Überwachung auf Fehlverhalten zusammen. Nach der Entscheidung, einen Job zu stoppen oder zu pausieren, unterbindet es innerhalb von 35 Sekunden die Erzeugung weiterer Modellergebnisse. Es ist so konzipiert, dass es auch beim Ausfall anderer Systeme weiterarbeitet und die Erzeugung von Modellergebnissen stoppt, wenn Control Room selbst ausfällt.

Control Room ist bereits in unserer gesamten Forschungsinfrastruktur im Einsatz, wo der Bedarf am größten ist. Unser Technologie-Stack für die externe Bereitstellung von Modellen ist von Grund auf deutlich zentraler organisiert. Wir verfügen dort bereits über ausgereifte betriebliche Möglichkeiten, Modellbereitstellungen bei Bedarf schnell abzuschalten.

Control Room verbindet mehrere Systeme: den Workload, die Inferenz-Engine und den zentralen Control Room-Dienst.

• Der Workload ist der ausgeführte Job, etwa ein Experiment mit Reinforcement Learning, eine Evaluierung oder ein umfangreicher Sampling- oder Datenverarbeitungsjob. Wir verlangen, dass jeder Forschungsworkload mit agentischer Inferenz einem genehmigten Sicherheitsnachweis zugeordnet ist.

• Die Inferenz-Engine, kurz Engine, ist das Modell selbst. Du kannst dir die Engine als das Gehirn des Modells vorstellen, das direkt auf GPUs läuft. Ein Workload nutzt normalerweise ein oder mehrere Modelle, die auf einer oder mehreren unterschiedlichen Inferenz-Engines laufen können. Dieselbe Inferenz-Engine kann von mehreren unterschiedlichen Workloads genutzt werden.

• Der Control Room-Dienst verfolgt Jobs und steuert, ob sie weiterhin Modellergebnisse erzeugen dürfen. Bevor Engines eine Anfrage ausführen, holen sie beim Control Room-Dienst die Erlaubnis ein. Wurde ein Job gestoppt, lehnt der Dienst die Anfrage ab und verhindert so weitere Modellergebnisse.

Control Room ist wie folgt integriert:

• Beim Start eines neuen Jobs fordert der Workload-Code bei Control Room eine neue job_id an.

• Wenn der Workload Tokens von einem Modell samplen muss, sendet er eine Anfrage an eine Inferenz-Engine, auf der dieses Modell läuft, und übergibt dabei die job_id. Die Engine bittet Control Room um Erlaubnis, diese Anfrage auszuführen, und übergibt dabei die job_id an Control Room.

• Control Room prüft, ob der Job beendet wurde. Falls ja, lehnt es die Inferenzanfrage ab. Die Engine beantwortet die Inferenzanfrage des Workloads mit einer Ablehnung. Dadurch werden für diesen Job keine weiteren Modellergebnisse erzeugt.

Alle unsere Jobs für Reinforcement Learning mit Frontier-Modellen laufen mit einem Überwachungsmodell. Ein Überwachungsmodell ist ein weiteres Modell, das sämtliche Aktivitäten des trainierten Modells prüft und eine Warnung auslöst, wenn es ein Problem erkennt. So wurde etwa unser jüngster DNS-bezogener Vorfall⁠(wird in einem neuen Fenster geöffnet) von einem Überwachungsmodell erkannt.

Control Room und unser Überwachungssystem sind wie folgt miteinander verbunden:

• Erkennt das Überwachungssystem ein mögliches Problem, kann es je nach Umständen und Schweregrad entscheiden, den Job zu stoppen.

• In diesem Fall sendet das Überwachungssystem eine Nachricht an Control Room, um den Job zu stoppen, und übergibt dabei die job_id. Control Room vermerkt, dass der Job beendet ist.

• Stellt der Job mit dieser job_id das nächste Mal eine Inferenzanfrage, um weitere Tokens zu samplen, wird die Anfrage abgelehnt. Das gilt für jedes Modell auf jeder Engine und verhindert die Erzeugung weiterer Modellergebnisse.

Vom Eingang der Anweisung bei Control Room, einen Job zu stoppen, bis zu dem Zeitpunkt, an dem keine weitere Verarbeitung mehr möglich ist, vergehen höchstens 35 Sekunden. Die Verzögerung von 35 Sekunden entsteht durch eine Caching-Schicht für die Inferenzautorisierung, die das erforderliche Anfragevolumen bewältigen hilft. Wir arbeiten daran, diese Zeit auf null zu reduzieren, damit wir Jobs sofort beenden können.

Workloads, darunter Experimente, Evaluierungsjobs und andere Aufgaben, werden normalerweise von einzelnen Forschenden oder Forschungsteams verantwortet und ausgeführt. Deshalb ändert sich der Workload-Code häufig und ist kein idealer Ort, um zentrale Sicherheitsmechanismen zu implementieren. Unsere Implementierung ist daher so ausgelegt, dass sie auch bei fehlerhaftem oder nicht funktionsfähigem Workload-Code zuverlässig arbeitet.

Dafür implementieren wir den Abbruchmechanismus in der Inferenzschicht. Workload-Code ist sehr vielfältig und dezentral organisiert. Dagegen kommen in der gesamten Forschung bei OpenAI nur sehr wenige Inferenz-Codepfade zum Einsatz. Auch ihre Bereitstellung ist wesentlich zentraler und einheitlicher organisiert. Die Inferenzschicht kann somit als zentraler Kontrollpunkt dienen. Dort lässt sich mit hoher Verlässlichkeit sicherstellen, dass jede Modellinferenz in der Forschung bei jeder Anfrage den Autorisierungsprüfungen von Control Room unterliegt. Zusätzlich führen wir kontinuierlich agentengestützte und programmatische Prüfungen durch. Damit prüfen wir, ob jemand versehentlich oder absichtlich unzulässige Engine-Implementierungen startet, in denen Control Room nicht implementiert oder deaktiviert ist.

Schließlich sperrt unser System bei einem Ausfall alle Anfragen („Fail-closed“). Dafür ist die Control Room-Integration in den Engines entsprechend konfiguriert: Fällt der Control Room-Dienst durch einen Systemfehler aus oder wird er aus einem anderen Grund deaktiviert, auch durch böswillige Manipulation, werden alle Inferenzanfragen abgelehnt, bis Control Room wieder normal arbeitet. Das Fail-closed-Verhalten ist inzwischen für alle Forschungsworkloads mit Frontier-Modellen aktiviert. In den nächsten Tagen wird die Einführung für alle übrigen Forschungsworkloads abgeschlossen.

Control Room ist nur ein Teil unseres ganzheitlichen Ansatzes für das sichere Training und die sichere Bereitstellung von Frontier-Modellen. Wir werden das System in den kommenden Monaten weiter verbessern und ausbauen. Parallel investieren wir in die Überwachung auf fehlgeleitetes Verhalten und Sicherheitsverletzungen. Du möchtest Systeme mitentwickeln, die eine sichere und vor Angriffen geschützte Entwicklung und Bereitstellung von AGI ermöglichen? Wir suchen⁠ Verstärkung⁠!