Control Room
随着模型能力不断增强，相关的安全风险也在增大。因此，能够发现潜在问题，并在必要时迅速叫停模型，变得越来越重要。为此，我们构建了 Control Room。
Control Room 是一个中央系统，用于追踪我们研究基础设施中的模型工作负载，并在出现安全隐患时迅速将其停止。它连接了所有研究推理工作负载，包括用于模型训练和评估的智能体采样、数据处理等。它与我们的不对齐监测系统协同工作，在决定介入、停止或暂停作业后，能在 35 秒内停止模型输出。其设计确保它在其他系统发生故障时仍能继续工作，而当 Control Room 自身出现故障时，模型输出也会停止。
Control Room 已部署到我们的整个研究基础设施中，这也是最需要它的地方。相比之下，我们对外提供模型服务的技术栈本身就更加集中，并且已具备成熟的运维能力，可在必要时迅速下线模型部署。
Control Room 通过整合几个系统来发挥作用：工作负载、推理引擎和集中式的 Control Room 服务。
工作负载就是正在运行的作业，例如强化学习实验、评估、大规模采样或数据处理作业。我们要求每个执行智能体推理的研究工作负载都关联一份获批的安全论证。
推理引擎（简称引擎）就是模型本身。你可以把引擎理解为模型的大脑，它直接在 GPU 上运行。一个工作负载通常会使用一个或多个模型，这些模型可能运行在一个或多个不同的推理引擎上。同一个推理引擎也可能被多个不同的工作负载使用。
Control Room 服务负责追踪作业，并控制是否允许它们继续生成模型输出。引擎在执行请求之前，会先向 Control Room 服务核实授权。如果作业已被停止，该服务就会拒绝请求，阻止进一步输出。
Control Room 的集成流程如下：
启动新作业时，工作负载代码会向 Control Room 申请一个新的 job_id。
每当工作负载需要从模型采样 token 时，就会向运行该模型的推理引擎发送请求，并传入 job_id。引擎会向 Control Room 申请执行该请求的权限，同时将 job_id 传给 Control Room。
Control Room 会检查该作业是否已被终止；如果是，就拒绝此次推理请求。引擎会向工作负载的推理请求返回拒绝响应，停止为该作业生成更多模型输出。
Control Room 的工作原理
研究作业
推理引擎
在 GPU 上运行模型
Control Room
- job_039，运行中
- job_040，运行中
- job_041，运行中
我们的所有前沿模型强化学习作业都配有监测器。监测器是另一个模型，用于检查受训模型的所有行为，并在发现问题时发出告警。例如，我们最近的 DNS 相关事件（在新窗口中打开）就是由监测器发现的。
Control Room 与我们的监测系统按以下方式集成：
如果监测系统发现潜在问题，它可能会根据具体情况和严重程度，决定停止作业。
此时，监测系统会向 Control Room 发送停止作业的消息，并传入 job_id。Control Room 会将该作业记录为已终止。
下次带有该 job_id 的作业发起推理请求，试图从任何引擎上运行的任何模型中采样更多 token 时，请求都会被拒绝，从而停止进一步的模型输出。
从 Control Room 收到停止作业的指令，到该作业无法再继续推进，最长耗时为 35 秒。这 35 秒的延迟来自推理授权缓存层，该缓存层用于支撑所需的流量规模。我们正在努力将这一延迟降至零，以便即时终止作业。
实验、评估作业等工作负载通常由研究人员或研究团队负责管理和运行。因此，工作负载代码经常变更，并不适合用来实现承担核心防护职责的安全机制。为此，我们在设计实现方案时，确保即使工作负载代码存在缺陷或无法正常运行，该机制也能保持可靠。
我们通过在推理层实现终止机制来做到这一点。工作负载代码多种多样，且分散在各处。相比之下，OpenAI 的所有研究中使用的推理代码路径只有极少数，其部署也更加集中、统一。这意味着推理层可以作为必经关口，让我们能够有力地确保：研究中运行的所有模型推理，每一次请求都要经过 Control Room 的授权检查。此外，我们还持续通过智能体和程序执行全面检查，确保用户不会无意或恶意启动未接入 Control Room 或已将其禁用的违规引擎实现。
最后，我们的系统采用“故障时拒绝访问”机制：引擎中的 Control Room 集成经过专门配置，如果 Control Room 服务因系统错误而中断，或因其他任何原因被禁用，包括遭到恶意行为者篡改，所有推理请求都会被拒绝，直到 Control Room 恢复正常运行。目前，故障时拒绝访问机制已部署到所有前沿模型研究工作负载，并将在未来几天内覆盖其余所有研究工作负载。
