研究基础设施里的模型工作负载急停：状态、粒度与恢复条件

先说结论：就本次可用材料而言，能站住的事实只有一条——Control Room 是一个集中式系统，用于跨研究基础设施追踪模型工作负载，并在出现安全或安保关切时快速停止它们（来源：OpenAI, Control Room，来源日期 2026 年 11 月 9 日）。至于状态怎么定义、停到什么粒度、恢复要满足什么条件，摘要没有给出，本文以下部分属于工程推断与建议，不构成对该系统内部实现的描述。

摘要能确认什么，不能确认什么#

可确认的关键词有四个：集中（central）、跨研究基础设施（across our research infrastructure）、追踪（track）、快速停止（rapidly stop），触发条件是安全或安保方面的关切。这四点决定了这类系统的形态：它必须对工作负载有统一视角，否则“跨设施”追踪不成立；它必须能在发现问题时缩短暴露窗口，否则“快速”没有意义。

摘要没有给出状态集合、停止的作用域、停止时延的量化口径、恢复由谁发起，也没有说明停止是硬切还是允许排空。这些内容属于本次材料未覆盖的部分，需要查阅原文或官方文档核实，不能据摘要反推。

“停止”在契约里应该是几个状态#

把急停实现成一个布尔开关，是这类系统最常见的退化。实践上至少要区分两个对外可见状态：已受理停止与已确认停止。前者表示命令已被中央系统接收并下发，后者表示目标工作负载确实不再产生新的输出与写入。二者的差别就是风险窗口的差别，也是事后复盘时唯一能核对的时间点。停止请求还应具备幂等性：同一 request_id 重复提交返回同一结果，避免重试把状态机推乱。

另一个必须提前定下的取舍是：急停时是否允许在途请求排空。安全与安保类关切通常倾向于立即切断，因为排空本身就是暴露时间的延长；但硬切会在检查点、缓存和队列里留下不一致的中间产物。可行的折中是分阶段——先拒绝新请求，再对在途请求设一个极短的硬截止，最后统一进入不可写状态。

粒度：停谁，比停多快更重要#

追踪粒度决定停止粒度：能追踪到多细，才能停到多细。如果系统只知道“某台机器上跑着什么”，那么出事时只能整片停机，影响面被放大；如果能追踪到工作负载的归属单元（项目、实验、负责人），就可以把停止收窄到真正相关的部分。

• 实例级：停单个进程或副本，恢复最快，但漏掉跨副本共享的状态。
• 工作负载级：停掉某负载的全部副本，是较自然的默认单元。
• 共享依赖级：模型权重服务、向量库、缓存、凭证。这一层最容易被忽略，却常常是残留的真正位置。

因此“停止”不应只包含计算路径，还必须切断写入路径：日志、缓存、发布产物、下游队列、外部存储。只停计算不停写入，等于让一个已经不该存在的负载继续把结果留在系统里。

恢复条件：比停止更难定义#

恢复不是把开关拨回去。要让重新启用可信，至少需要三类证据：触发原因已定位并消除；受影响产物已清理，包括缓存失效与凭证轮换；小范围重新启用的验证结果，例如限定配额或影子流量下的观察。建议把恢复权限与停止权限分开——停止是收敛风险，应当快；恢复是重新开闸，应当慢，且留痕：谁发起、依据什么、恢复了哪些作用域。

一个演示用的请求契约#

下表与代码为占位示例，用于说明字段形态，未执行、也不对应任何真实端点。

POST /stop-requests
{
  "request_id": "REQ-DEMO-0001",
  "scope": { "type": "workload", "id": "YOUR_WORKLOAD_ID" },
  "reason_code": "security",
  "requested_by": "YOUR_KEY",
  "deadline_ms": 5000
}
// 占位演示：example.com 风格，非真实站点请求

边界#

本文的推断均以摘要可支持的四个关键词为起点，未对 Control Room 的具体状态机、时延指标或恢复流程作任何断言；这些参数在本次材料中未提供，需以官方文档为准。对 API.PLUS 一侧的接入与排障，若涉及具体端点、字段与限流口径，同样应在有可核验文档后再落地。