一个模型系统上三个可执行停点与随附的托管审计接口

一、能被叫停是一项非功能需求，而这三样多半还不存在

据公开报道，一家模型公司向立法者递交过一份前沿 AI 安全法案的草案设想，里面包含在满足条件时中止模型训练与部署的闸门安排。这份设想的具体门槛、条文结构与它讨论的制度背景都不在本篇范围内，我们也不判断这类安排该不该存在。有一个事实跟这些争论无关：任何一个系统，如果”被叫停”这件事要有意义，它必须先具备三个接口——明确的停点、可交接的状态、可复核的记录。

这三样在任何一家模型服务商的架构里都多半不存在。不是因为大家不愿意做，而是它从来没被当成需求提出来过。可用性、延迟、吞吐这些非功能需求有明确指标、有测试方法、有责任人；”可被停止”没有。它的难处在于，停止不是一个布尔值，至少是三个位置不同的动作，而且每个动作完成后系统仍然要能被别人接着看下去。

下面三张清单，是我们按”如果明天要交出去”这个假设整理的。它可以直接用来评审自家现有架构，不需要等任何外部条件。

二、停点清单：三个停点的工程含义完全不同

停点 要停的是什么 工程上必须做得到的动作 最难的一环
停止继续训练 训练任务与它的数据管道 检查点原子关闭，不留半写状态；调度队列排空；数据消费位点固化并可复述 分布式训练的中止一致性，任一节点失败都可能污染这一版检查点
停止对外服务 推理入口与它承载的全部业务 网关层有明确下线语义，包括返回什么、降级到哪；已签发凭证能批量失效；客户侧预案同步生效 下游把模型能力当成不会消失的依赖，接口一停就是生产事故
停止某个能力分支 同一个模型里的某一类行为 约束解码、输出过滤、工具白名单裁剪，且开关状态可被外部验证 只在提示层禁用会留下绕过路径；改权重则牵出再训练与再验证的成本

三个停点里，第一个最接近”物理动作”，第三个最容易被做假。把某个能力关掉的正确形态是：它对应一组可判定的行为测试，关掉之后这组测试稳定失败，而不是”提示词里不再提它”。这也是为什么能力级开关必须和评测基线绑在一起交付，否则”已停用”这三个字无法被任何人核实。

三、可交接状态清单：停得下来，还要接得出去

只会停不会交，叫停就变成一次数据销毁。可交接状态至少要包含下面五项，每一项都要能落到具体文件。

项目 具体到文件层面的内容 缺了会怎样
版本对应关系 权重、配置、分词器与词表、推理引擎、服务镜像五者的配对表 接手方不知道该重放哪一套组合，同权重跑出不同结果
评测基线与已知缺陷 最后一次通过的评测集版本与结果、未修复缺陷清单及其触发条件 已知缺陷被当成新问题重查，或者被误判为停用造成的损伤
运行手册与依赖清单 启停顺序、外部服务依赖、容量假设、回退到上一版本的具体步骤 停止操作可执行，恢复操作无人能执行
密钥与访问边界处置 每一把密钥的用途、交接时吊销还是代持、谁能访问生产与训练环境 交接过程本身成为一次暴露面扩大
训练数据与管道的可复述描述 数据源清单与各自许可范围、清洗与切分规则、被排除的样本类别 无法证明停用之后不会以同一套管道重启

这份清单的价值不只服务于”被叫停”这一个假设场景。它和一次彻底的基础设施迁移、一次并购中的技术尽调、一次供应商更换用的是同一套东西。我们的经验是：凡是交接清单需要临时现编的团队，最后一定会漏掉版本对应关系和密钥处置两项，而这两项恰好是接手方唯一真正需要的。

四、权重托管的三种模式与各自的失效场景

如果要求的是”外部方也能让权重停止流通”，光有停点不够，还要有权重本身的可控形态。常见的三种都有明确的失效场景，选型前得先把这些场景写进风险表。

  • 第三方托管加条件释放。托管方自身的可用性与司法管辖冲突会让释放动作卡住；更实际的问题是释放条件由谁判定，判定分歧时托管方有没有能力抵抗压力。
  • 多方分割密钥。任何一方缺席或不配合就锁死，恢复路径长；密钥份额的保管介质与轮换流程本身要另建一套治理。
  • 仅承诺封存、不交权重。实施成本最低，但它完全依赖承诺方的信用，一旦需要向外部举证”确实封存了”，能拿出的只有自己写的内部审计记录，证明力有限。

三种模式的差别不在安全强度，在于”停止”这个动作需要几方同时同意。需要同意的一方越多，误停与赖停的概率同时上升，这是设计上的取舍，没有哪种模式两头都占。

五、审计字段清单：日志要能回答三个问题

审计不是为了留一堆记录，是为了让三个问题在事后有唯一答案。字段要提前埋，事件发生后再补通常补不齐。

要回答的问题 必须落库的字段 由谁写入 保留与访问控制
谁在什么时候启动了多大规模的训练 任务标识、发起人与审批链、算力规模与所在区域、起止时间、中止时的检查点标识 调度系统写入，业务侧只读 保留期要长于任何一次事后复核的周期，访问按最小权限
用了什么数据 数据集标识与版本、来源与许可范围、切分结果的校验值、被排除的类别 数据管道写入 与数据集同生命周期，数据销毁时要留处置记录
结果如何被评估 评测集版本、通过项与失败项、人工判定人及结论、结论与被停能力的对应关系 评测系统写入 只可追加更正，不可删除原判定

三个字段的写入方分属三个系统，这意味着审计的落地难点在跨系统标识对齐：训练任务 id、数据集版本、评测记录必须能被同一个查询串起来。做不到这一点，日志再全也只能证明”发生过一些事”，回答不了”为什么停的是这个模型”。

六、报告口径的一致，以及作为使用方要问的三句话

对外报告与内部技术事实的一致性是这一整套接口里最容易失守的一环，而且失真会朝两个方向发生。把”模型具备某类能力”写成”已经造成后果”，是夸大；把”我们在评测里没有观察到某类行为”写成”不存在该行为”，是另一种失真，后者在停用声明里更常见。可用的纪律只有一条：报告里的每一句状态描述，都要能指向一张有版本号的评测记录，指不到就改成”未测得”。

最后一件事发生在采购侧。绝大多数企业不是模型的训练方，是使用方，而使用方对”可被叫停”能做的贡献只在合同条款上。签合同前把三句话问清楚：第一，你的服务在什么情况下会被停止，停止时我方有没有提前量与迁出窗口；第二，停掉之后我方提交的数据、微调得到的权重与配置怎么处置，由谁执行、能否举证；第三，如果上游被要求中止能力，我方能不能在不改代码的前提下拿到降级形态。三句里有两句拿不到书面答复，就该把这部分风险放进自家的容量与替代方案里，而不是放进对上游的信任里。这套接口在洹拓自己维护的模型服务上按上面三张清单逐项落地过，缺项很多，但至少每一缺项都能说清楚要补哪一块。

#版本冻结 #前沿模型治理 #权重托管 #审计日志 #事件报告