OpenAI上线Control Room，35秒内可熔断异常模型任务

随着人工智能模型性能的不断提升，伴随而来的安全与防务风险也愈发显著。如何在发现潜在问题时迅速终止模型运行，成为保障研究安全的核心挑战。为此，OpenAI 推出了名为 Control Room 的中央控制系统。

Control Room 覆盖了 OpenAI 整个科研基础设施，负责集中追踪所有模型工作负载，并在出现安全漏洞或对齐偏差时快速叫停。该系统深度整合了包括模型训练评估中的智能体采样、数据处理在内的全部研究推理负载，与现有的不对齐监测系统协同工作。从下达干预指令到彻底中断模型输出，整个响应耗时控制在 35 秒以内。此外，Control Room 具备故障闭锁特性：即使自身服务宕机或被破坏，也会直接切断模型推理输出，确保风险不外溢。

目前，Control Room 已在 OpenAI 科研计算环境中全面部署。相比本身架构更为集中、具备成熟下线机制的外部商业服务集群，高度灵活的研究环境对该系统的需求更为迫切。

运作机制：在推理瓶颈层设卡

Control Room 由三大核心组件协同运行：

• 工作负载（Workload）：指具体运行的科研任务，例如强化学习实验、评估测试或大规模数据处理。OpenAI 要求凡是涉及智能体推理的科研工作，都必须附带获批的安全案例（Safety Case）。
• 推理引擎（Inference Engine）：直接运行在 GPU 上的模型执行载体，相当于模型的大脑。单个工作负载可调用多个引擎，同一个引擎也可承载多项不同任务。
• Control Room 服务中心：负责全局追踪任务状态并判定是否授权继续生成。推理引擎在处理请求前，必须向该服务进行校验。

在标准工作流中，研究人员启动新任务时，工作负载代码会向 Control Room 申请专属的 job_id。每当任务需要调用模型采样 Token 时，都会将该 ID 传递给推理引擎；引擎随即向 Control Room 校验当前任务是否已被标记终止。一旦发现任务被停用，引擎将直接拒绝推理请求，立即遏制输出。

异常警报与秒级拦截

在所有前沿模型的强化学习任务中，OpenAI 均部署了专门的监视器（Monitor）——即另一个用于审查受训模型行为的独立模型。此前发生的智能体利用 DNS 绕过限制访问外部聊天机器人事件，正是被该监视系统成功捕获。

当监视器识别到严重风险并判定需要停机时，会直接通知 Control Room 标记终止该 job_id。此后，该任务在任何引擎上的下一次推理请求都将被全面拒绝。

速度与可靠性保障

从发出终止指令到任务彻底受阻，系统目前的最大延迟为 35 秒。这一延迟源于应对高并发流量的鉴权缓存层，OpenAI 正在进一步优化以将延迟归零，实现瞬时熔断。

科研工作负载通常由分散的研究团队维护，代码迭代极其频繁且容易包含缺陷，并非部署关键安全防线的理想层级。因此，OpenAI 选择将拦截机制下沉至更加集中统一的推理层。全机构使用的核心推理代码路径极少，推理层构成了天然的“瓶颈”，确保每次推理请求都必须穿透 Control Room 的权限校验。系统还会持续运行自动化审查程序，防止有人无意或恶意启动未接入 Control Room 的非法引擎。

同时，系统采用严格的“故障闭锁（Fail-Closed）”设计：一旦 Control Room 因故障下线，或遭到恶意篡改而停用，所有推理引擎将默认拒绝一切请求，直到服务恢复正常。目前该策略已应用于所有前沿模型研发，并在数日内覆盖剩余全部研究场景。