模型下线如果等同于删除制品或关闭服务，最先暴露的往往不是存储问题，而是未登记的应用、评测基线、提示配置和审计记录失去依赖。另一个极端是担心误删而永久保留所有版本、日志和数据，长期成本与权限风险不断增加。下线需要先画依赖、安排迁移，再决定哪些对象归档、何时销毁。

适合场景：模型替换、供应服务终止、版本停止维护、项目结束或风险要求停止使用时的退出规划。

先区分停用、下线、归档和销毁

停用可以只是停止新应用接入，现有调用仍运行；下线通常意味着生产入口逐步撤除；归档保留必要制品、配置和证据供复盘或回退；销毁则按授权和制度删除不再需要的对象。四种状态不应由一个“已删除”字段代替。

模型可能先进入冻结状态，不再接受新版本和新调用方，同时盘点依赖。替代方案顺利获得验证后，现有应用分批迁移；观察窗口结束后关闭旧入口；最后根据回退、审计和数据要求决定归档或销毁。

状态转换要有责任人和顺利获得条件。谁可以宣布停止新接入，谁确认业务迁移完成，谁批准销毁，谁保留审计材料，都应明确。状态不清会让应用认为模型仍可用，平台认为已经退出，形成新的风险。

先画依赖图，再决定下线顺序

模型依赖不仅是API调用。应用可能顺利获得网关路由或别名间接访问；提示与后处理针对特定模型行为；评测基线与回归结果绑定版本；数据和索引可能为该模型准备；发布、监控和告警也引用服务名称。

依赖图至少覆盖：

• 直接与间接调用应用、用户和服务账号
• 网关路由、模型别名、缓存和降级策略
• 提示模板、结构化输出和工具参数约定
• 评测数据、基线、质量门槛和发布记录
• 训练或微调来源、模型制品与派生版本
• 监控、日志、审计、合同和风险材料

依赖发现可以结合配置、网关日志、资产关系和应用申报，任何单一来源都可能不完整。近期无调用不代表没有依赖，周期性任务、灾备和手工流程可能长时间沉默。应设置确认窗口并让应用责任人签认。

模型资产、版本和分发关系可以参考 模型资产管理方法 。下线阶段需要在此基础上增加实际调用、业务责任和归档关系，不能只看仓库中有没有文件。

图中外圈依赖不是全部迁移到新模型。有些应用迁移，有些项目终止，有些证据归档，有些临时数据按规则销毁。下线计划应为每个依赖选择出口。

替代迁移要同时验证行为与运行链路

新模型或新服务即使接口兼容，输出行为、格式、拒答、工具参数和错误语义仍可能不同。迁移前应使用代表性业务任务和已知失败样本回归，确认提示、后处理和评测门槛是否需要调整。

运行链路也要复测。网关路由、限流、监控、日志、成本统计和故障切换可能绑定旧服务。仅修改模型地址不代表迁移完成。涉及第三方服务时，还要检查数据处理、凭证、合同和支持边界。

迁移波次可以按业务影响、替代难度和回退能力排序。低风险、无副作用且依赖简单的应用先迁移；高风险工具、复杂格式和关键流程后移。每一波都保留旧入口的有限回退条件，但要防止双轨无限延长。

模型发布和回滚方法可以结合 模型发布流程 使用。下线场景的特殊点是回退窗口有明确终点，旧模型停止维护或合同终止后不能假设永久可回。

观察期检查暗流量与孤儿依赖

迁移完成声明后，应保留一段观察期，监控旧入口、别名、凭证和存储访问。任何调用都要找到责任人，判断是漏迁、计划任务、测试流量还是异常访问。观察期长度依据业务周期和风险设定，不使用通用数字。

孤儿依赖包括无人负责的应用、失效账号、未知脚本、历史评测或无法解释的文件。它们不能因为找不到负责人就自动迁移，也不应无限保留。项目治理角色需要决定停用、隔离、归档或进一步调查。

缓存和离线任务容易被遗漏。某些应用不直接调用模型，却读取预生成结果；批处理可能按月运行；灾备入口只在演练时使用。依赖盘点要结合业务周期，而不是只看近几天请求。

旧入口仍有未知流量时，物理删除不是清理，而是制造不可解释中断。 先让未知变成有责任的对象，再决定处置。

归档范围由回退、复盘和制度共同决定

可能需要归档的对象包括模型制品或服务版本说明、关键配置、来源与许可材料、评测报告、发布和审批、重大事件、迁移记录及必要日志索引。并非所有原始训练数据、提示和调用内容都需要永久保留。

归档要说明用途和访问角色。用于技术复盘的材料与正式审计材料可能不同；回退需要的制品和环境信息也与长期证据不同。混在一个目录中，会导致权限过宽和清理困难。

外部托管模型可能无法归档制品，此时应保留可取得的版本、合同、配置、评测与迁移证据，并注明不可见边界。不能用本地占位文件假装拥有模型资产。

归档介质、加密、完整性、备份和恢复应由企业标准决定。下线验收可以抽查一次读取或恢复，确认材料不是“保存了但打不开”。归档到期后按规则复核和处置。

成本控制要看持有、迁移和风险三类成本

持有成本包括存储、备份、许可、服务、监控、权限管理和安全维护。迁移成本包括适配、测试、双轨、培训和业务窗口。风险成本则来自提前删除导致中断、长期保留导致暴露，以及旧版本无人维护。

三类成本不能用一个无假设数字比较。项目应记录对象数量、保留用途、访问频率、替代难度和责任投入，建立若干情景。例如旧模型只能短期回退、关键项目需要长期证据、普通实验可按规则清理，各自采用不同策略。

成本决策还要防止把所有数据都转移到低成本存储后宣布完成。访问权限、检索、恢复和销毁仍需管理；归档越多，未来审查和迁移负担越大。没有用途的保留不是保险。

供应方费用、存储价格和具体节省比例必须基于合同与环境核验。本文只给予构成方法，不给出通用TCO结论。

销毁前需要最后一次反向核对

销毁候选应从对象反向查询应用、发布、评测、事件和审批，确认没有活动依赖、回退窗口结束、保留责任解除，并取得相应批准。若关系系统不完整，应结合人工确认，不因查询为空就直接删除。

销毁动作包括服务入口、凭证、路由、制品、缓存、临时副本和不再需要的日志或数据。不同对象可以分阶段处理，先撤销调用和权限，再删除数据。操作要有证据，但证据本身不应保留被删除的敏感内容。

备份和副本要进入范围。只删除主库而保留无限备份，会让销毁结论失真。无法立即处理的备份可以记录到期和隔离措施，由负责团队执行，不虚构“已彻底删除”。

破坏性操作必须按企业授权和回滚规则执行。本文给予规划框架，不替代具体环境的变更审批、备份与恢复确认。

下一步建议

选择一个计划退出的低风险模型，先标记冻结而不是删除。用配置、调用记录和责任人申报建立依赖图，为每个依赖选择迁移、终止、归档或销毁出口。完成替代回归和一轮观察后，再确定归档范围与销毁清单。任何未知调用和无人负责对象都先隔离调查，不用进度压力替代确认。

常见问题

模型没有调用量，能否直接下线？

不能只凭近期调用量判断。周期性任务、灾备、测试入口、缓存生成和手工流程可能长时间没有请求，网关或别名也可能隐藏直接关系。应结合配置、资产、日志和应用责任人确认，并观察一个覆盖合理业务周期的窗口。

若确实没有活动依赖，可以先撤销新接入和普通调用，保留受控回退，再观察是否出现异常。无人认领的依赖要进入隔离和治理流程，不宜直接迁移到新模型。最终销毁还需确认归档与审批要求，并让业务、平台和审计责任人分别确认各自范围已经关闭。销毁后再观察旧入口是否出现异常访问。

归档模型制品就足以支持未来回退吗？

不一定。回退还可能需要运行环境、依赖、配置、提示、数据或索引版本、接口策略和评测基线。只有一个模型文件，未必能恢复当时服务，更不能证明回退后符合当前安全和业务要求。

归档计划应区分“保存证据”和“具备可运行回退”。后者需要更完整对象和定期验证，成本也更高。旧环境若已停止维护，继续保留可能增加风险；应根据回退价值决定，而不是默认所有版本永久可恢复。若选择保留回退能力，应定期执行受控读取或恢复，并记录失效条件、依赖状态和当次责任人。否则只能称为证据归档。

模型下线时审计日志应该保留多久？

没有适用于所有企业的统一期限。需要结合适用法律与行业要求、合同、事件调查、业务用途、数据类型和企业留存制度决定。技术团队不能仅依据存储成本自行设定，也不应无限保留以求安心。

更可执行的做法是分类：重大事件与审批证据、普通运行日志、敏感内容和临时调试数据分别确定用途、权限和到期动作。到期后验证主存储、索引、导出与备份处理，并保留不含敏感原文的处置记录。制度或合同变化时，重新评估尚未到期的存量材料，不能只调整新数据。结论变化要同步到备份与导出副本的处置计划。