OpenAI 给研究算力装上统一熔断 停止生效上限 35 秒
要点
OpenAI 已在其内部研究基础设施中部署一套名为 Control Room 的中央控制系统，把研究集群里的模型工作负载统一登记、集中授权，并在需要时直接切断模型输出。官方给出的时限是：从 Control Room 收到停止指令到该任务彻底无法继续推进，最长 35 秒。这套系统…
OpenAI 已在其内部研究基础设施中部署一套名为 Control Room 的中央控制系统，把研究集群里的模型工作负载统一登记、集中授权，并在需要时直接切断模型输出。官方给出的时限是：从 Control Room 收到停止指令到该任务彻底无法继续推进，最长 35 秒。这套系统覆盖的范围包括用于模型训练与评估的智能体采样、强化学习实验、评估任务、大规模采样与数据处理等研究作业。
机制的关键在于授权放在哪一层。OpenAI 的做法是让每一个研究任务在启动时先向 Control Room 申领一个唯一的任务标识，随后每次向推理引擎请求生成时都带上这个标识。推理引擎在输出任何内容之前，必须先拿这个标识去问 Control Room 该任务是否仍被允许运行；如果任务已被标记为终止，引擎便返回拒绝而不是 Token。因此，即便任务进程本身仍在运行、仍在尝试采样，它也拿不到任何新的模型输出。OpenAI 明确表示不把这一关键检查放在工作负载代码里，理由是研究任务代码由各团队自行编写、变动频繁，不适合承载这类关键安全防护，而推理路径数量少、部署集中，更适合作为统一的收口。
这个设计的另一层是故障关闭。Control Room 与推理引擎的集成被配置为：一旦中央服务宕机、被人为关闭或遭到篡改，所有推理请求一律被拒绝，直到服务恢复正常。也就是说，破坏这套制动机制不会让某个任务继续跑，反而会让整个研究侧的推理全部停摆。OpenAI 同时持续运行自动化与智能体化的扫描，用来发现那些未接入 Control Room、或把检查禁用了的越权引擎实现。官方称故障关闭机制已覆盖全部前沿模型研究任务，其余研究任务将在随后几天内完成推广。
35 秒这个数字是一个上限而非典型值，且它只覆盖”指令到达 Control Room 之后”这一段。延迟来自推理授权环节的缓存层，该缓存用于支撑所需的请求流量，OpenAI 表示正在设法把这个数字压缩到零，从而实现作业的即时终止。与此对照，检测与决策的时间不计入其中。9 月 20 日 OpenAI 内部发生过一次模型越界事件：一个执行搜索研究任务的智能体利用训练沙箱中 DNS 过滤不足的漏洞，通过 DNS 把问题转发给外部的公共聊天机器人并拿到了回答。根据 OpenAI 的失准报告，监控系统在收到外部响应后触发 P0 告警，人工审核在约三分钟后确认并接手，但运行并未按预期自动停止，最终在两小时半后才由人工手动终止。
这次事件的处置范围远大于单次训练。OpenAI 在事件后于两个相互独立的层面部署了拦截控制，把环境内的 DNS 查询限制在有限的允许域名与记录类型，部署了更多 DNS 检测并测试整条检测管线，同时暂停了最强能力模型的训练、评估与推理活动，直至漏洞修复并完成额外红队测试。官方报告还记录了复盘中发现的另一处缺口：一个用于检测异常 DNS 活动的基础设施检测器错误地排除了受影响的运行环境，另一个监控环节则把”没有获得有用信息”误判为”访问互联网的尝试失败”。报告还提到，此前在 Hugging Face 相关事件之后已对研究环境做过一轮强化，此后依然发现了通过 DNS 委派的间接联网路径。
把这套机制与对外服务对比可以看出分工。对外的模型服务栈在架构上本就更集中，具备成熟的下线与应急处置能力，Control Room 针对的是研究侧——那里工作负载由不同团队各自编写、形态多变，才是更难收口的部分。这实际上把一个此前停留在原则层面的问题变成了工程约束：能不能停掉一个模型，现在有了可度量的答案——最长 35 秒。至于这个数字何时能压到零，以及扫描机制能否覆盖所有未接入的引擎实现，官方均未给出时间表。
