技术 · 熟练
端点下线那天，要重做的不是代码
有一类退役，替代品不是另一个模型名
看到「某模型下线」时，大脑默认的反应是「改个模型名就行」—— 但有一类退役不是这样：托管端点关掉之后，官方给的替代路径是「你自己把同一批开源权重部署起来」，那意味着要备 GPU 与容量，不是改一行配置。更贵的一种藏得更深：如果你的项目用过托管的嵌入模型端点，向量是不通用的 —— 换嵌入模型必须把全部文档重嵌入一遍，这件事拖着不做，检索会悄悄变差而不报错。这一页把「端点级退役」与「模型级退役」分开，给一张三步的迁移前检查：先分清是换名字还是换承载 ② 再查有没有嵌入层被牵动 ③ 最后把「同一天批量关停」的名单按容量准备期倒排。
原理 · 为什么有效
「退役」有两种，替代成本差一个量级。第一种是模型级退役：同一家平台把某个模型 ID 换成更新的 ID，替代品就是另一个字符串，改配置、跑一遍、验证输出格式即可。第二种是端点级退役：平台不再托管某个开源模型，官方给的路径是「在 Model Garden 上自行部署同一批权重」或迁到别的托管方 —— 这时工作量的主体变成容量与运维（备机器、估显存、管版本），代码改动反而是最小的一块。两类混在一张清单里排期，就会把最贵的那种排得最晚。而嵌入层是第三种、最容易被忘掉的一类：嵌入是把文本落成向量的那一层，不同嵌入模型产出的向量空间不通用 ⇒ 换了模型，索引里存的旧向量与新查询向量对不上，检索质量下降但不报错；所以只要退役名单里有嵌入端点，就必须把「重嵌入全部文档」当成本条线上真正的主任务来排，而且要早开始（它按文档量计费与计时，不是一小时的活）。
适用场景
适用于：自建 RAG / 知识库 / 语义检索的项目 · 用托管模型服务的后端 · 跑在云平台「模型即服务」上的推理链路 —— 尤其是把向量索引当成基础设施、平时不太看它的团队。不适用于：只用一家第一方 API 且没有自建索引的轻量用法（那属模型级退役，看 `ai-model-deprecation-sweep-2` 那三样即可）· 还没上线原型的项目（没有存量向量，也就没有重嵌入成本）。
自测 · 5 问
你的检索链路用的是哪一家的嵌入模型，在不在这次的退役名单里？
退役名单里有没有「替代路径是自行部署」的条目 —— 你为它准备了机器与容量吗？
如果换嵌入模型，要重嵌入多少文档、大概多久、谁来做？
你把排期锚在关停日还是容量准备期（前者往往来不及）？
部署时能不能自动发现「某个模型名已经无效」，而不是等线上凌晨报错？
怎么上手 · 验证步骤
先做第 2 问（嵌入层）。它是唯一一个「不做也不会立刻报错」的项 —— 检索慢慢变差，没人知道为什么。查清楚三样：嵌入模型的来源 · 索引里向量的维度与模型标识 · 全量文档数。再回到第 1 问把退役名单分成两栏（换名字 / 换承载），第三栏单独放嵌入类。然后按容量准备期倒排：自部署要备机器与估显存，重嵌入要按文档量算时间 —— 两者都比「改个模型名」长得多，所以排在关停日之前越远越好。做完自己核三样：① 名单里每一条都能说出它是「换名字 / 换承载 / 动嵌入」中的哪一类 ② 嵌入类的那条有文档数与预计时长，不是一个「待办」 ③ 部署时有一道自检能把无效模型名拦在发布前 —— 只要这条自检不存在，这一轮就没做完。
按三栏逐条过一遍：① 换名字类：替代 ID 与输出格式差异验证过了吗 ② 换承载类：机器 / 显存 / 容量估算写出来了吗 ③ 动嵌入类：文档数是几、重嵌入要多久、跑完怎么验证检索质量没退化 ④ 部署期自检有没有覆盖「模型名无效」这一种失败 ⑤ 名单里有没有哪一条你其实是「等它真关了再说」。