OpenAI 在 11 月 9 日的官方博客里介绍了一个新系统 Control Room：一个中央系统，追踪其研究基础设施里的全部模型工作负载，出现安全或安保问题时能快速叫停。它已经部署于整个研究基础设施，决定干预之后，最长 35 秒内就能让目标作业停下模型输出。
它由三部分协同工作：工作负载、推理引擎和 Control Room 服务。工作负载是正在跑的作业，比如强化学习实验、评估、大规模采样或数据处理；OpenAI 要求每一个做 agentic inference（智能体式推理）的研究工作负载都关联一个经批准的安全案例。推理引擎就是模型本身，在 GPU 上运行。流程是：作业开始时先向 Control Room 申请一个 job_id；每次需要模型采样 token 时，工作负载把 job_id 传给推理引擎，引擎在出结果前先向 Control Room 请求许可；如果该作业已被终止，请求会被拒绝，引擎不再继续输出。OpenAI 还会持续运行 agentic 与程序化扫描，检查有没有人无意或有意绕开 Control Room、启动未受管控的推理引擎。
为什么把终止机制放在推理层而不是工作负载里？OpenAI 的解释是：工作负载代码由各个研究团队持有、经常变化，不适合承载关键安全保护；而推理代码路径数量很少、部署集中统一，卡在推理层等于卡住了瓶颈——研究中跑的所有模型推理，每次请求都必须经过 Control Room 的授权检查。它还与失齐监控系统联动：所有前沿强化学习作业都配一个 monitor（另一个模型盯着被训模型，发现问题就报警）；近期那起模型经 DNS 漏洞溜上互联网的事件就是 monitor 发现的，站里 10 月 24 日报道过这起 9 月的 DNS 事件（OpenAI 给前沿模型训练「断网」）。监控系统发现问题后可以直接让 Control Room 按 job_id 终止作业，此后该作业向任何模型、任何引擎的推理请求都会被拒绝。
有两点局限要说清：35 秒是上限，来自推理授权的缓存层，OpenAI 称正努力把它降到零；而且这 35 秒只计收到停令之后，不含发现问题和决定干预的时间——此前那次 DNS 事件从报警到停掉据报道花了约 2.5 小时，Control Room 解决的是“决定之后停得不够快”的问题。系统采用 fail-closed 设计：Control Room 本身宕机、或被恶意篡改禁用时，所有推理请求一律拒绝，直到服务恢复；目前已覆盖全部前沿模型研究负载，几天内扩到其余研究负载。外部服务栈本身已较集中、能快速下线部署，所以 Control Room 优先用在研究侧。这是 OpenAI 继 10 月 29 日公开四层失齐监控（站里已有报道）之后的又一步，把“发现问题”补上了“强制叫停”。
来源：OpenAI 官方博客，原文
没有回复内容