Control Room

モデルの能力が高まり、それに伴う安全性とセキュリティのリスクが増すにつれ、潜在的な問題を検知し、必要に応じてモデルを迅速に停止できることが、ますます重要になっています。この課題に対応するため、私たちは Control Room を構築しました。

Control Room は、研究インフラ全体のモデルワークロードを追跡し、安全性やセキュリティ上の懸念が生じた際に迅速に停止するための一元管理システムです。モデルの学習・評価のためのエージェントによるサンプリングやデータ処理など、研究用のあらゆる推論ワークロードを接続します。私たちのミスアライメント監視システムと連携し、ジョブの停止や一時停止のために介入すると判断してから 35 秒以内に、モデルの出力を停止します。他のシステムに障害が発生しても動作を続け、Control Room 自体が停止した場合はモデルの出力を止めるように設計されています。

Control Room は、最も必要性の高い研究インフラ全体にすでに導入されています。外部向けのモデル提供基盤は、もともとはるかに集約された構成になっており、必要に応じてデプロイ済みモデルの提供を迅速に停止できる運用体制が十分に整っています。

Control Room は、ワークロード、推論エンジン、そして一元管理を担う Control Room サービスを連携させることで動作します。

• ワークロードとは、強化学習の実験、評価、大量のサンプリング、データ処理など、実行されるジョブのことです。エージェントによる推論を行うすべての研究ワークロードには、承認済みのセーフティケースとの紐付けを義務付けています。

• 推論エンジン、または単にエンジンとは、モデルそのものです。エンジンは、GPU 上で直接動作するモデルの頭脳と考えることができます。ワークロードは通常、1 つ以上のモデルを使用し、それらのモデルは単一または複数の異なる推論エンジン上で動作します。同じ推論エンジンが、複数の異なるワークロードで使われることもあります。

• Control Room サービスはジョブを追跡し、モデルの出力生成を継続してよいかを制御します。エンジンはリクエストを処理する前に、Control Room サービスに確認します。ジョブが停止済みであれば、サービスはリクエストを拒否し、それ以上の出力を防ぎます。

Control Room は、次のように連携します。

• 新しいジョブを開始する際、ワークロードのコードが Control Room に新しい job_id を要求します。

• ワークロードがモデルからトークンをサンプリングするたびに、そのモデルを実行する推論エンジンに job_id を渡してリクエストを送ります。エンジンは Control Room に job_id を渡し、そのリクエストを処理する許可を求めます。

• Control Room は、そのジョブが終了済みかを確認し、終了済みであれば推論リクエストを拒否します。エンジンはワークロードの推論リクエストに拒否応答を返し、そのジョブでモデルの出力がそれ以上生成されないようにします。

フロンティアモデルの強化学習ジョブはすべて、監視モデルを伴って実行されます。監視モデルとは、学習中のモデルのあらゆる動作を検査し、問題を検知するとアラートを出す別のモデルです。たとえば、先日の DNS 関連のインシデント⁠（新しいウィンドウで開く）は、監視モデルによって検知されました。

Control Room と監視システムは、次のように連携します。

• 監視システムは潜在的な問題を検知すると、その内容や深刻度に応じて、ジョブの停止を判断することがあります。

• その場合、監視システムは job_id とともに、ジョブの停止を指示するメッセージを Control Room に送ります。Control Room は、そのジョブを終了済みとして記録します。

• 次にその job_id を持つジョブが、追加のトークンをサンプリングするために推論リクエストを送ると、使用するエンジンやモデルにかかわらず、そのリクエストは拒否されます。これにより、それ以上のモデル出力は停止します。

Control Room がジョブの停止指示を受け取ってから、それ以上処理を進められなくなるまでの時間は、最大 35 秒です。この 35 秒の遅延は、必要なトラフィック量に対応するために設けた、推論の認可用キャッシュ層によって生じます。ジョブを即座に終了できるよう、この遅延をゼロにする取り組みを進めています。

実験や評価ジョブなどのワークロードは、通常、研究者や研究チームが管理・運用しています。そのため、ワークロードのコードは頻繁に変更され、安全性を支える重要な保護機能の実装先としては適していません。そこで、ワークロードのコードにバグや不具合があっても影響を受けにくい設計にしています。

具体的には、推論層に終了の仕組みを実装することで、これを実現しています。ワークロードのコードは多種多様で、分散して管理されています。一方、OpenAI の研究全体で使われる推論のコードパスはごく少数で、そのデプロイははるかに集約・統一されています。そのため、推論層をすべての処理が通る関門とすることで、研究で実行されるあらゆるモデル推論について、リクエストごとに Control Room の認可チェックが行われることを強く保証できます。さらに、エージェントとプログラムによる継続的な検査を行い、Control Room が未実装または無効になっている不正なエンジン実装を、ユーザーが誤って、あるいは悪意を持って起動していないか確認しています。

最後に、このシステムは「フェイルクローズ」を採用しています。エンジンと Control Room の連携は、システムエラーや悪意ある者による改ざんなど、何らかの理由で Control Room サービスが停止・無効化された場合、正常な動作が再開するまで、すべての推論リクエストを拒否するように設定されています。フェイルクローズは、フロンティアモデルの研究ワークロードすべてに導入済みで、残るすべての研究ワークロードへの導入も今後数日以内に完了する予定です。

Control Room は、フロンティアモデルの安全な学習とデプロイに向けた包括的な取り組みの一部にすぎません。今後数か月にわたり、意図に沿わない挙動やセキュリティ侵害の監視に投資するとともに、このシステムの強化と拡充を続けていきます。AGI の安全でセキュアな開発・デプロイを支えるシステムづくりに携わりたい方へ。私たちと一緒に働く⁠仲間を募集しています⁠！