模型部署不是“把权重放到服务器上”，而是把一个可变、可能出错的模型系统转成可观察、可限制、可回滚的线上服务。一份合格的上线决定必须同时回答：发布的对象是什么，离线证据是否覆盖真实任务，预发布环境是否可比，灰度中看什么，谁有权放量，以及失败后如何在业务允许的时间内恢复。
本文面向需要把分类、生成、检索增强或智能体系统投入生产的工程、产品、安全和运营人员。它不承诺某个框架或平台“最佳”，也不把示例阈值冒充通用标准；所有数字都应由你的任务风险、流量、硬件、合同和历史基线决定。核验日期为 2026-09-24。
先给结论：什么时候才算部署完成？
服务返回 HTTP 200 只证明某个端点可达，不等于模型正确、权限安全或容量足够。部署完成至少包含五层：制品可追溯、任务质量过线、运行环境可服务、灰度结果可解释、回滚路径已经演练。若系统会调用工具或影响外部数据，还要证明审批、最小权限、幂等和副作用恢复。
NIST AI RMF Core把上线前测试与上线后监控、事件响应、恢复和变更管理放在同一风险循环中；Kubernetes 金丝雀发布教程则说明稳定版本、候选版本、流量、监控和回滚如何形成可操作的发布路径。本站据此整理的是验收方法，不是对任何厂商产品的背书。
第一步：把“模型版本”扩展为“发布对象”
真实线上结果通常由模型权重、推理运行时、提示词、采样参数、检索库、工具定义、安全策略和网关共同决定。只记录模型名会让故障无法复现。例如权重未变，但检索索引换了切分方式，答案仍可能大幅变化；模型未变，但工具权限扩大，风险等级已经改变。
发布清单至少应记录：业务任务、负责人、权重或远端模型 ID、镜像摘要、代码提交、依赖锁文件、运行时与驱动、提示模板摘要、检索索引版本、工具与权限、数据契约、监控面板、回滚包及其保留期限。远端 API 还要记录地区、配额、数据处理边界和供应商变更入口。
第二步：离线评测必须回答业务问题
离线评测的核心不是追求一个漂亮总分，而是判断候选能否在限定风险下完成任务。先从真实错误成本反推指标：哪些错误可由人工发现，哪些会直接进入客户、数据库或外部系统，哪些一旦发生不可逆。然后建立主任务集、风险切片和拒绝/降级样本。
对生成系统，建议把事实、完整性、格式、引用、语气和可执行性分开；对智能体，把计划正确、工具选择、参数、权限、幂等、停止和恢复分开。不要把“回答看起来不错”与“任务已经安全完成”合并为一个含糊标签。
第三步：预发布环境验证启动、依赖和容量
预发布不是开发机的同义词。它应尽量复现生产的硬件类型、驱动、容器、网络策略、存储、配额和下游依赖。不能同构时，要把差异逐项列出，并说明它可能让结果偏乐观还是偏保守。
先做最小启动检查，再做代表性任务，最后做压力与故障注入。检查范围包括镜像能否拉取、模型能否加载、健康接口是否真实、依赖中断是否超时、长输入是否受控、并发是否产生排队、资源耗尽是否优雅失败，以及服务重启后是否恢复正确版本。
涉及 NVIDIA GPU 时，不要把 nvidia-smi 顶部显示的 CUDA 版本当成框架实际运行时；应分开记录硬件、驱动、Toolkit、框架构建和进程可见设备。详细检查可参阅站内CUDA 驱动、Toolkit 与框架兼容性指南。涉及大模型并发容量，还要把输入长度、输出长度和 KV 缓存占用纳入场景。
第四步：灰度必须有对照和停止条件
灰度的价值不是“先放一点看看”，而是用受控流量验证离线假设。优先使用内部用户、影子流量、可撤销任务或低风险租户。为稳定版和候选版保持可比较的流量与标签，避免同一会话来回切换导致状态污染。
放量前写下最低观察量、质量门槛、错误率、延迟、成本、安全事件和人工复核规则。看到结果后再改变阈值会让决策失去可信度。高风险失败可以不等样本量满就立即停止；低频但不可逆的越权行为不应被平均成功率稀释。
Kubernetes Deployment 文档说明了滚动状态、历史修订和回滚边界。要注意，平台级回滚通常只恢复工作负载模板；索引、数据库模式、远端配置和已执行副作用需要应用自己设计恢复方案。
第五步：观测质量，而不只是观测服务器
CPU、GPU、内存和错误率回答“服务是否活着”，不能回答“答案是否仍然可用”。线上观测应同时包含系统层、模型层、任务层和风险层。系统层看请求、错误、队列和资源；模型层看 Token、长度、拒答和工具选择；任务层看格式、业务完成与人工纠正；风险层看越权、敏感信息和异常群体影响。
线上往往缺少即时真值，因此要设计延迟反馈：抽样人工复核、用户纠正、下游撤销、申诉、投诉与后来获得的真实结果。代理指标可以报警，但不能把“用户没投诉”写成准确率，也不能把模型自评写成独立质量证据。
第六步：回滚前先定义恢复对象
回滚应覆盖模型、代码、提示、索引、配置、路由、权限和数据契约。若候选版本写入新格式或执行了外部动作，只切回旧容器可能造成持续错误。发布前要区分可逆变更、需要补偿操作的变更和不可逆变更；不可逆动作应使用审批、预览或限额减少爆炸半径。
演练时记录从触发到停止流量、切回、健康检查、关键样本验证和业务确认的时间。若恢复依赖某位个人手工修改，或回滚包从未实际读取，这条路径就不能算已验证。事件结束后保存版本、影响、时间线、证据和改进项。
34 项模型部署验收清单
下面每项都要求“负责人、证据位置、结论、复查日期”。它既可以转成发布工单，也可以作为审计台账。不是每个项目都需要相同强度，但任何删除项都应写明原因，而不是留空。
| 控制项 | 验收要求 | 回执字段 |
|---|---|---|
| 1. 业务任务与停止条件 | 先写清模型替代或辅助的具体任务、输入来源、输出接收者和最终责任人。把不能接受的结果写成停止条件，例如越权执行、关键字段遗漏、受保护数据外泄或人工无法接管。没有任务边界时，平均分数再高也无法形成上线决定。 | 负责人、证据位置、结论、复查日期 |
| 2. 基线与候选版本 | 保留当前稳定版本的同口径结果，候选版本只改变能被追踪的一组因素。若同时更换模型、提示词、检索库、量化方式和网关，就无法解释收益或故障来源。发布记录要能回答候选究竟比哪一个基线好、好在哪里、代价是什么。 | 负责人、证据位置、结论、复查日期 |
| 3. 模型与制品摘要 | 对权重、容器、代码、依赖锁文件、提示模板、检索索引和安全策略分别计算摘要，并记录构建来源。只写模型名称或镜像标签不够，因为可变标签可能指向不同内容；回滚需要不可变版本或可校验摘要。 | 负责人、证据位置、结论、复查日期 |
| 4. 许可证与使用范围 | 核对模型、数据、基础镜像、字体及第三方库的许可，区分研究、内部使用、对外服务、再分发和衍生模型。许可证结论要链接到对应版本，不把仓库首页一句话当成完整法律判断；存在不确定性时交由合规人员确认。 | 负责人、证据位置、结论、复查日期 |
| 5. 数据代表性 | 验收集应覆盖真实任务中的语言、长度、格式、行业术语、边界输入和失败输入，同时标记数据来源与时间。只用训练分布内的干净样本会低估上线风险。测试集更新时保存版本，避免候选和基线使用不同题目。 | 负责人、证据位置、结论、复查日期 |
| 6. 数据泄漏检查 | 确认测试样本没有以训练、微调、提示示例或检索文档形式进入候选系统。对公开基准要考虑污染可能，不能把熟悉题目的高分直接外推到业务。对包含个人或商业信息的样本，应完成最小化、授权和访问控制。 | 负责人、证据位置、结论、复查日期 |
| 7. 任务指标 | 指标必须对应用户任务：分类看混淆矩阵和关键类别召回，抽取看字段级正确性，生成任务需要事实、完整性、格式与人工可用性。单一平均分会隐藏小群体或高风险切片，必须同时报告分布和失败样本。 | 负责人、证据位置、结论、复查日期 |
| 8. 不确定性与重复 | 具有采样随机性的系统需要在固定设置下重复运行，记录种子、温度、工具状态和结果离散程度。不要挑一次最好结果。若线上供应商无法固定随机性，也应以重复样本和置信区间描述波动，而不是给出伪精确结论。 | 负责人、证据位置、结论、复查日期 |
| 9. 人工复核协议 | 规定谁在什么条件下复核、能看到哪些证据、如何标记分歧以及何时升级。人工通过率只有在评审标准一致时才有意义；建议先用少量共同样本校准评审者，并保存分歧案例用于更新规则。 | 负责人、证据位置、结论、复查日期 |
| 10. 安全与滥用切片 | 根据系统能力设计提示注入、越权工具调用、敏感信息、拒答绕过、恶意文件和超长输入等测试。安全结果要绑定实际工具与权限，不能把无工具聊天模型的拒答率外推到能写文件、发消息或操作浏览器的智能体。 | 负责人、证据位置、结论、复查日期 |
| 11. 公平与群体影响 | 识别可能受到差异影响的人群、语言或地区，按任务风险选择切片和人工审查。样本量不足时明确不确定性，不用总体平均掩盖局部伤害。若系统参与高影响决定，应引入领域、法律和申诉机制评审。 | 负责人、证据位置、结论、复查日期 |
| 12. 隐私与留存 | 画出输入、日志、缓存、向量库、供应商接口和备份之间的数据流，标明每一跳的控制者、保存时长和删除方式。上线前实际演练删除和访问请求，而不是只引用隐私政策；调试日志不得成为长期敏感数据仓库。 | 负责人、证据位置、结论、复查日期 |
| 13. 身份与最小权限 | 为服务、运维人员和自动化任务使用可区分身份，限制模型能访问的工具、网络、文件与密钥。短期凭证优于长期共享密钥。发布验收要证明拒绝路径有效，包括无权用户、过期凭证和越界资源。 | 负责人、证据位置、结论、复查日期 |
| 14. 依赖与供应链 | 生成软件物料清单或等价依赖清单，核对基础镜像、运行时、驱动、框架和自定义算子的来源。扫描结果只是发现证据，还要判断漏洞是否可达、补丁是否兼容，以及无法立即修复时有哪些补偿控制。 | 负责人、证据位置、结论、复查日期 |
| 15. 环境同构 | 预发布环境至少要在硬件类型、驱动、运行时、网络策略、存储和关键限额上与生产可比。开发机能运行不证明生产容器可运行。无法完全同构时列出差异并为每项差异安排额外 canary 观察。 | 负责人、证据位置、结论、复查日期 |
| 16. 启动与健康检查 | 区分进程存活、模型已加载、依赖可用和业务可服务四种状态。健康接口不应在权重尚未加载、检索库未就绪或安全策略缺失时返回成功。还要验证启动失败是否会自动退出，而不是接受流量后持续报错。 | 负责人、证据位置、结论、复查日期 |
| 17. 容量与并发 | 用目标输入长度、输出长度、批量和并发组合测试，而不是只跑一个短请求。记录吞吐、排队、首字延迟、总延迟、显存或内存峰值和错误类型。容量结果只适用于测试硬件、版本与配置，不能无条件外推。 | 负责人、证据位置、结论、复查日期 |
| 18. 长尾与超时 | 分别观察中位数和高分位延迟，并记录客户端、网关、模型服务、工具和下游数据库各自的超时。总超时若短于内部重试链路，可能造成请求已经执行但客户端认为失败，从而触发重复动作。 | 负责人、证据位置、结论、复查日期 |
| 19. 成本口径 | 把输入、输出、缓存、重试、工具调用、向量检索、GPU 空闲、日志和人工复核纳入同一任务成本。只比较每百万 Token 或单卡价格会遗漏大量运营成本。预算门槛应与质量门槛同时评估。 | 负责人、证据位置、结论、复查日期 |
| 20. 可观测标识 | 每个请求需要关联版本、配置、路由、模型、数据或索引版本以及追踪标识。日志应能还原发生了什么，但避免记录不必要的原始敏感输入。指标、日志和追踪必须使用一致时间与版本标签。 | 负责人、证据位置、结论、复查日期 |
| 21. 质量监控 | 线上质量通常不能立即获得真值，应组合抽样人工复核、代理指标、格式失败、用户纠正、下游撤销和投诉信号。代理指标只能作为预警，不能自动等同于真实准确率；定期回流有真值的样本进行复核。 | 负责人、证据位置、结论、复查日期 |
| 22. 漂移与新分布 | 监测输入语言、长度、主题、来源、工具选择和检索命中等分布变化。检测到漂移后先判断是否改变任务风险，再决定重评、限流或回滚。分布变化本身不是质量下降的充分证据。 | 负责人、证据位置、结论、复查日期 |
| 23. 灰度分群 | 灰度应从低风险、可观察、可快速恢复的流量开始，明确排除高风险用户或不可逆动作。随机百分比不是唯一方法，也可按内部用户、特定租户或影子流量分群；必须避免同一会话在版本间来回跳转。 | 负责人、证据位置、结论、复查日期 |
| 24. 对照与归因 | 灰度期间保留稳定版本作为对照，使用同口径时间窗和任务分层。若营销活动、数据源或硬件同时变化，要在结论中标记干扰因素。没有对照时只能描述观察，不能声称改动造成提升。 | 负责人、证据位置、结论、复查日期 |
| 25. 放量门槛 | 每个阶段预先写明最短观察量、最低质量、最高错误率、延迟与成本上限，以及谁可以批准下一阶段。门槛不能在看到结果后临时放宽；高风险事件即使数量少，也可以触发停止。 | 负责人、证据位置、结论、复查日期 |
| 26. 回滚对象 | 列出必须一起恢复的模型、路由、提示、索引、特征、数据库模式和权限策略。仅把容器镜像退回上一版，可能仍使用不兼容的新索引或配置。回滚包要在变更前创建，并验证能够读取。 | 负责人、证据位置、结论、复查日期 |
| 27. 数据兼容 | 检查新旧版本写入的数据格式、缓存键和异步任务是否兼容。不可逆迁移应采用扩展再收缩等方式，保证旧版本在回滚窗口内仍能工作。对工具型智能体，还要处理已经执行的外部副作用。 | 负责人、证据位置、结论、复查日期 |
| 28. 回滚演练 | 在非生产环境按剧本实际执行切回、验证和恢复，不把文档存在当作能力存在。记录恢复时间、失败步骤和人工依赖。若恢复时间超过业务容忍度，发布前应减少变更面或增强双写、热备与开关。 | 负责人、证据位置、结论、复查日期 |
| 29. 人工接管 | 高风险流程必须提供清晰的暂停、审核、撤销和人工完成入口。接管者需要看到模型版本、已执行动作、剩余步骤和证据，不应在事故发生后重新猜测上下文。定期演练值班通知与权限。 | 负责人、证据位置、结论、复查日期 |
| 30. 事件分级 | 按用户影响、数据影响、可逆性和持续时间定义事件等级，规定通知对象和时限。模型产生错误并不总是事故，但越权、泄露、批量不可逆动作和系统性歧视需要更高等级处置与留证。 | 负责人、证据位置、结论、复查日期 |
| 31. 供应商降级 | 外部模型或工具不可用时，明确是切换模型、关闭高级能力、进入只读、排队还是人工处理。降级路径也要验收，因为备用模型可能具有不同上下文、格式、地区和安全边界。 | 负责人、证据位置、结论、复查日期 |
| 32. 变更审批 | 把模型、提示、检索、工具、权限和监控规则都纳入变更管理，按风险决定双人复核或安全审批。紧急变更可以走快速路径，但仍要保留原因、批准者、时间、差异和事后复盘。 | 负责人、证据位置、结论、复查日期 |
| 33. 证据保留 | 保存能重现决定的最小证据：制品摘要、配置、任务集版本、结果摘要、失败样本、视觉回执、批准记录和回滚包。敏感原始数据应以受控引用代替无边界复制，并设置保存与销毁周期。 | 负责人、证据位置、结论、复查日期 |
| 34. 退役与删除 | 上线不是生命周期终点。模型或供应商退役时要迁移调用方、撤销凭证、停止流量、归档必要证据、删除不再需要的数据并更新文档。长期无人负责的影子服务会形成安全和成本风险。 | 负责人、证据位置、结论、复查日期 |
八类上线故障如何定位与恢复？
一、候选版本启动失败
先停止继续放量，保存镜像摘要、调度事件、容器日志、节点类型和最近配置差异。按“镜像能否获取—入口进程是否启动—权重是否读取—依赖是否连通—健康接口是否真实”的顺序定位，避免一开始就重装整个环境。若稳定版本仍健康，优先把候选缩容到零并保留现场；若共享资源已被候选改变，则按备份恢复配置并验证稳定版本的关键样本。启动失败的结论只适用于当前制品与环境，不应写成模型本身不可用。
二、GPU 可见但框架不能计算
分别记录宿主机设备、驱动、容器设备映射、框架构建运行时、动态库路径和最小张量运算。nvidia-smi 成功只说明驱动工具看见设备，不能证明框架加载了正确运行时；nvcc 版本也不等于预编译框架使用的版本。恢复时一次只改变一层，并保留变更前后的命令输出。若最小计算通过但目标模型失败，再转向算子、计算能力、精度、显存与自定义扩展，不要继续盲目换驱动。
三、延迟突然上升但错误率正常
把总延迟拆成网关等待、排队、检索、模型首字、生成、工具和下游写入，按版本与输入长度分组。平均值稳定可能掩盖少量超长请求或某个租户占满队列。先限制最坏输入与并发，检查自动扩缩容和冷启动，再判断是否回滚。若候选提高质量却显著增加高分位延迟，应让产品负责人依据任务时限作取舍，而不是由工程侧用平均吞吐单独决定。
四、输出格式偶发损坏
保存失败原文的受控摘要、模型版本、提示模板、采样设置、结构化输出模式和重试次数，区分模型未遵循格式、截断、解析器不兼容和下游模式变化。重试可能降低表面失败率，却会增加成本并掩盖系统性缺陷；对会触发外部动作的请求，未经幂等设计不得自动重试。恢复可以先进入只读或人工确认，再修复模式约束和失败样本。
五、检索答案变差但模型未变
检查索引摘要、文档集合、切分、嵌入、过滤、排序和权限策略，而不是直接归因于模型。用固定问题保存候选文档、排序分数、权限结果和最终引用，比较稳定索引与新索引。若新鲜度更新引入错误，回滚索引同时要处理缓存；若权限过滤失败，应立即停止相关流量并按安全事件处理。检索命中率、答案正确性和引用支持度要分别记录。
六、工具调用产生重复副作用
先关闭危险工具或切换为审批模式，按追踪标识查明同一意图是否因超时、客户端重试、队列重投或模型重复规划被多次执行。对每个动作保存幂等键、授权主体、参数摘要、外部系统结果和补偿状态。不能撤销的动作要由业务负责人判断后续通知与补救。仅降低模型温度不是可靠修复，因为重复常来自分布式重试和状态管理。
七、供应商 API 限流或区域不可用
区分配额、瞬时限流、账号权限、区域、网络和服务端故障，记录响应码、请求标识与官方状态入口。退避和重试必须受总时限和预算约束；切换供应商前核对模型能力、上下文、格式、数据处理和安全策略差异。备用模型如果没有通过同一关键任务集，只能作为受限降级，不能宣称与主模型等价。恢复后逐步撤销积压，避免流量洪峰。
八、线上质量下降但没有明确技术错误
冻结进一步放量，按任务、用户、语言、输入来源、长度和版本切片，调取人工纠正、撤销、投诉与下游结果。检查数据分布、提示、检索库、工具、政策和供应商是否变化。没有即时真值时，应把结论写成“观察到风险信号”，而不是声称准确率下降。若高风险样本已受影响，即使总体指标未越线也可回滚；恢复后把新失败加入受控任务集。
如何设置阈值，而不制造通用数字？
阈值应从业务容忍度和历史基线推导。先确定一项失败造成的影响、人工是否能发现、多久能恢复，再决定质量、延迟、错误、成本和风险门槛。对有稳定版本的系统，用同口径历史分布建立警戒线；对新系统，用离线验收、受控试点和专家判断形成初始范围，并安排较短复查周期。不要从另一家公司、另一硬件或营销材料复制数字。
阈值还要定义统计口径：时间窗、最小样本量、分母、去重、是否包含重试以及迟到数据如何处理。一次严重越权与一百次普通格式失败不能简单加权成同一个平均数。建议把停止条件分成“立即停止”“暂停放量并人工复核”“继续观察”三层，每层写明责任人和恢复条件。
团队职责如何分开，避免无人对证据负责？
产品负责人确认任务、用户影响与可接受降级；模型或数据负责人维护任务集、切片和结果解释；平台负责人维护制品、环境、容量、观测与回滚；安全与隐私负责人检查权限、数据流、滥用和事件；业务运营或领域专家承担人工复核与申诉入口。最终批准者应能看到所有关键未决项，而不是只收到“技术已上线”的口头结论。
小团队可以一人承担多个角色，但回执仍应区分责任。高风险改动至少需要独立复核，避免同一个人既设计指标、运行测试又单独批准例外。发生紧急变更时，可以缩短流程但不能删除证据；事后必须补齐差异、原因、批准和复盘。
独立任务资产：上线判定记录模板
复制下面的 JSON 作为一次发布的最小记录。字段为空时不应自动判定通过；证据使用受控路径或摘要，禁止把密钥和敏感原文写进公开工单。此模板只验证记录完整性，不验证模型质量。
{
"release_id": "model-service-YYYYMMDD-NNN",
"task": {"owner": "", "scope": "", "stop_conditions": []},
"artifacts": {"model": "sha256:", "image": "sha256:", "config": "sha256:", "index": "sha256:"},
"evaluation": {"dataset_version": "", "baseline": "", "candidate": "", "risk_slices": [], "evidence": ""},
"runtime": {"environment_delta": [], "capacity_receipt": "", "security_receipt": ""},
"canary": {"cohort": "", "start": "", "promotion_gates": [], "rollback_gates": []},
"rollback": {"bundle": "", "last_drill": "", "recovery_time": "", "owner": ""},
"decision": {"result": "hold", "approvers": [], "decided_at": "", "next_review": ""}
}如何用固定夹具检查记录完整性？
本站为本文配套保存了一个确定性校验脚本和三组样例：完整记录应通过，缺少制品摘要的记录应失败，缺少回滚负责人和最近演练时间的记录也应失败。该夹具不连接生产、不调用模型、不测 GPU，只证明发布记录的必需字段和失败分支按预期工作。
运行夹具时应输出输入文件摘要、通过或失败、缺失字段列表和脚本版本。把这种结构校验放进 CI 可以防止空白工单进入审批，但不能代替人工判断证据是否真实、指标是否合适或风险是否可接受。
常见误区：这些证据分别不能证明什么
- 镜像构建成功：不能证明能在生产硬件启动，也不能证明模型质量。
- 健康检查 200：不能证明权重、索引、权限和下游依赖已经可用。
- 离线平均分上升：不能证明高风险切片、延迟、成本或线上分布改善。
- 压测吞吐达标：不能证明结果正确；短输入压测也不能外推长上下文。
- 金丝雀无报警：不能证明监控覆盖完整，尤其不能把没有反馈当成没有伤害。
- 平台支持回滚：不能证明索引、数据、权限和外部副作用已经恢复。
不同类型系统如何裁剪这套流程？
传统分类或抽取模型
重点放在数据切片、阈值、校准、字段契约和下游容错。更新模型时要确认阈值是否需要重算；同一准确率下，不同置信度分布会改变人工复核量和业务风险。
生成式问答与 RAG
除答案质量外，单独检查检索命中、引用是否支持结论、权限过滤、索引新鲜度和无结果时的行为。模型、嵌入、切分、排序和知识库都应独立版本化。
带工具的 AI Agent
把每个工具看成受权限约束的外部系统，验证参数、审批、幂等、超时、重试和补偿操作。对于发信、转账、删除、发布等不可逆动作，默认先预览或人工确认。
第三方模型 API
记录正式模型 ID、地区、限额、数据处理和下线入口；为限流、超时、内容策略变化和供应商退役准备降级。不要把网页标题或 GitHub 更新时间当成正式变更通知。
上线会议应回答的十二个问题
- 这次具体改变了哪些对象，哪些对象保证不变？
- 候选与稳定版使用了同一任务集和同一评价口径吗？
- 最严重的已知失败是什么，用户会如何受到影响？
- 哪些群体、语言、地区或长尾输入仍缺证据？
- 预发布与生产有哪些差异，如何补偿观察？
- 灰度用户是谁，为什么爆炸半径可接受？
- 质量、性能、成本和安全分别由谁看守？
- 什么事件会立即停止，而不是继续收集样本？
- 回滚会恢复哪些对象，哪些副作用需要补偿？
- 人工接管需要什么权限和上下文？
- 证据保存在哪里，何时复查或删除？
- 如果供应商今天不可用，业务进入什么状态？
来源、观察与推断边界
官方材料中，NIST 提供风险管理与上线后监控框架，Kubernetes 提供部署、灰度和工作负载回滚机制，MLflow Model Registry 工作流提供版本、别名和环境间晋级的实现入口。本文的“八道门”“四类证据”和 34 项清单是兰塞 AI 基于这些材料形成的编辑综合，不是上述机构的原文标准。
本文没有连接读者的生产集群，没有部署真实业务模型，也没有给出通用错误率、延迟或成本阈值。可复现资产只校验记录结构。最终上线决定必须由拥有业务、工程、安全和合规责任的人员依据目标环境证据作出。
发布前最后检查
- 主任务、用户、责任人与停止条件已明确；
- 模型、镜像、配置、索引和权限均可追溯；
- 离线评测覆盖任务、风险切片和失败样本；
- 预发布完成启动、依赖、容量、安全和故障检查；
- 灰度有对照、门槛、观察量、负责人和停止开关；
- 回滚包已创建并演练，关键业务恢复得到确认；
- 上线后监控包含质量、性能、成本与风险，且安排复查日期。
若上述任一关键项只有“计划做”而没有回执，正确状态是保持候选或灰度，而不是认证上线。读者还可继续查看AI 基准评测的证据边界和梯度与训练故障排查，分别补齐评测解释和训练侧诊断。
