2026-10-10 零点，六条百炼模型下线公告共同生效。我在生效日当天上午十点多、下午一点多各对了一遍账，对象是自己项目里在用的二十个模型 ID。

这篇按依赖治理的顺序走：官方口径分几层、每层能回答什么问题、依赖盘点要做到哪一级、生效日当天的读数是什么、这套核查今天还立不住的地方在哪。所有在架与可调通读数都带时刻（2026-10-10 上午 10:4x / 下午 13:4x），复用前请重跑文末那个对账脚本，别把本文的快照当长期口径。

一、官方口径分三层，各管一件事

这个话题里二手数字特别多，先把来源钉清楚。三层官方材料形态不同，能回答的问题也不同。

第一层，模型下线机制说明页。 help.aliyun.com/zh/model-studio/model-depreciation 正文可读，不是壳。它在「下线模型列表」下按批次列：2026年10月10日将下线这一批挂了六条公告（118177、118434、118344、118345、118331、118332），往下还有 2026-05-30、2026-05-13、2026-03-30、2026-01-30、2025-07-30、2025-07-02、2025-05-08、2024-04-22 八个历史批次，其中两批注明未发布专项公告。操作建议只有两条：去控制台的模型监控页看自己账号是不是正在调待下线模型；要换就先测替代模型的业务效果再切。这一层给的是批次与公告编号，不给 ID 清单。

第二层，公告页。 国内那六条公告页是 SPA 壳，正文只到影响时间为止，名单不在 HTML 里。ID 级清单在国际站的同主题公告页上：正文可读，清单表是一张图，读图结果是主线 5 条（qwen3-max、qwen3-max-preview、qwen3.6-max-preview、qwen3-vl-flash、qwen3-coder-plus）加快照 40 条，每条带推荐替换模型。价格也在同一张表里，本文一个数字不抄，只抄替换模型的名字，因为名字才能进代码。读图转写有拼写风险，所以我在正文里举例的快照 ID 都跟平台自己的家族详情交叉印证过，不全量罗列那四十条。

第三层，错误码页。 它给的是失效后的预期报错形态：调用已下线模型返回 403 Endpoint.AccessDenied，原文举的就是一条带日期后缀的历史快照；模型不存在或未开通是 404 ModelNotFound；专属部署端点的 model 参数要填部署名称（带哈希后缀那串），填模型名报 model_not_found，两边 API-KEY 混用报 invalid_api_key。

社区今天也在做同一件事。掘金有篇《179 个模型 10 月 10 日下线：给项目做一次模型依赖全量体检》，那个 179 是作者自己的对账口径，我不采信为下线总数；它另有两条技术断言我今天用命令印证了，见第二、三节。

二、依赖盘点要做到 ID 级，家族级会漏

壳内能查在架的路径有四条，我逐条试过，三条会给不同答案。

分页全量列表。 bl model list --page-size 50 翻完四页，上午数到 179 个模型族，下午数到 178 个。返回的 total 字段上午写 188、下午写 187，两次都比实际返回多 9，差值稳定但我查不到原因，所以两个数我都记。列表浏览态里每个家族的 items 是空的，带日期后缀的快照 ID 在这一层根本看不见。

单查。 bl model list --model <id>。上午它对 wan-video、cosyvoice、embedding、qwen-rerank、deepseek、Kimi-K2、happyhorse-1.1 这七个家族回答 Model "<id>" not found.，而这七个在分页列表里明明在列；退出码是 0。下午一点多原样复测，七个仍然 not found，退出码仍然是 0。同一条命令对另一部分家族和几乎所有快照 ID 又是正常的：qwen3-max、qwen3-vl-flash、qwen3-coder-plus 单查成功，qwen3-max-2026-01-23 这类快照 ID 单查也成功。所以它不是整体失效，是对一部分家族稳定地假阴性，坏得没有规律可循也没有文档说明。我不猜成因，两次复测一致就是我敢写的全部。

对做依赖盘点的人，这一条的含义很直接：任何靠退出码判断查询成败的脚本，会把"查无此模型"当成功处理。

家族详情。 单查成功时返回体里的 items[] 才是快照 ID 的出处。下午 13:47 查 qwen3-max 家族，items 里是四个：qwen3-max、qwen3-max-2026-01-23、qwen3-max-preview、qwen3-max-2025-09-23。后两个在退役名单上，此刻仍作为家族成员列在详情里。

可调用性 probe。 bl text chat --model <id> --max-tokens 1，一个 token 的最小调用，见第三节。

还有一条负结论：列表返回的 JSON 里，我把 offline、deprecate、retire、sunset、expire 全搜了一遍，一个下线标记字段都没有。掘金帖说浏览态缺 upcomingOfflineAt，这点我印证了。换句话说，你无法靠任何字段判断一个 ID 是否待下线，只能拿名单去对。

三、生效日当天的两次读数

上午 10:44，我拿三个在退役名单上的 ID 各发了一次一个 token 的最小调用，对照一个在架 ID：

qwen3-max              → ok，exit 0
qwen3-coder-plus       → ok，exit 0
qwen3-max-2026-01-23   → ok，exit 0
qwen3.7-max（对照）     → ok，exit 0

下午 13:46 用对账脚本再跑一批快照 ID，单查层面同样全部返回在架。官方错误码页写的是调用已下线模型返回 403 Endpoint.AccessDenied，我上午和下午都没复现到 403。

这两件事放在一起，我能写的结论只有一句：生效日上午与下午两次实测，名单上的 ID 仍调用成功，与错误码页的预期报错不一致；公告自己带着【以实际变更时间为准】，灰度还是延迟，从外部判定不了。我不写"下线没生效"，也不写"公告是假的"，两者都超出证据。对治理的实际含义是：今天脚本没报错，不代表你的 ID 不在名单上；报错开始的那天也不会提前通知你。

矩阵本身也在动：

四、把对账接进依赖治理流程

台账分两级登记。 快照 ID 和主线 ID 分开记，快照条目在登记当天就写上"它会退役"。今天这批四十条快照就是例证：依赖里带日期后缀的人，本来就该把快照退役当常态。

壳内三法交叉。 三条路径各有盲区，那就让它们互相补。我把对账写成了一个脚本，逻辑三十字说完：分页拉全量拿家族集合；逐个单查，成功就读 items 拿快照；单查说 not found（退出码 0）的，回分页集合里看家族在不在，在就标 ⚠ 假阴性；带日期后缀的 ID 再按前缀回退找家族、取详情核对。

python3 check_model_ids.py qwen3-max wan-video cosyvoice deepseek-v3 qwen3.7-max

# 分页全量：4 页 / 178 个家族（bl 2.1.0，No Auth）
模型 ID                    单查              分页家族  家族详情 items  结论
qwen3-max                  ok                在列      含            在架（单查与详情一致）
wan-video                  not-found(exit0)  在列      -             ⚠ 列表在列但单查假阴性
cosyvoice                  not-found(exit0)  在列      -             ⚠ 列表在列但单查假阴性
deepseek-v3                ok                -         -             在架（单查与详情一致）
qwen3.7-max                ok                在列      含            在架（单查与详情一致）

⚠ 那一列就是单查想藏起来的东西：家族在矩阵里，单查却说不存在，退出码还是 0。脚本把它捞回来标成警告，而不是"不存在"。七个假阴性家族全部落进这一列，没有一个漏成"查无此模型"。脚本不鉴权、只读、不耗额度，四页列表十秒拉完，放进流水线没有额外成本。

另一半对账在控制台。 机制页操作建议第一条就是模型监控页（控制台 > 模型监控），看账号实际在调哪些模型。壳内对账答"这个 ID 在不在矩阵里"，监控页答"我有没有在用"，两问都答完才轮到迁移。

替换映射要人工核。 国际站公告正文里有一句容易被跳过：推荐替换指引不再随新模型上线而频繁更新。名单上的替换模型是某个时点的建议，不是持续维护的映射表。阿里云社区那篇迁移实录里还有个更具体的警告（社区文章自述，我没复现）：作者让模型自己给迁移建议，结果建议里编出了 8 个带 -latest 后缀的别名，还推荐了 23 个本身就在退役名单上的模型。把"让模型帮你换模型 ID"当自动化的人，这条值得贴在工位上。

替换关系我只抄名字：qwen3-max、qwen3-max-preview、qwen3.6-max-preview 指向 qwen3.7-max；qwen3-vl-flash 指向 qwen3.6-flash；qwen3-coder-plus 指向 qwen3.7-plus；四十条快照的推荐替换集中在这三个上。我自己在壳内交叉印证过 qwen3-max-2026-01-23、qwen3-max-2025-09-23、qwen3-vl-flash-2026-01-22、qwen3-coder-plus-2025-09-23 这几条仍列在对应家族详情里，其余以公告图为准。

五、这套核查今天立不住的地方

判断"几点几分之后开始报错"，不够。 我只能给两个时刻的快照，给不出切换点。

拿 ID 级名单做自动化门禁，不够。 国内公告是壳、机制页只给链接、国际站清单是图，机器可读的文本名单今天不存在。能做的是把读图名单存成自己的基线文件，标注来源与日期，定期人工复核。

预测下一批，不够。 机制页的历史批次里有两批没发专项公告，说明"没刷到公告"不等于"没有动作"，等公告再动手的人历史上至少漏过两次。

六、接入与复核路径

装对账能力是一条命令的事（CLI 安装页，API Key 在控制台的密钥管理页创建）：

npm install -g bailian-cli
bl model list --page-size 50 --output json   # 不用鉴权，先看矩阵长什么样

对账脚本不需要装任何依赖，Python 标准库加一个 bl 就够。复核动作三步：拉四页列表看模型族数与 total 是否又变了；把代码里的 ID 喂给脚本看 ⚠ 与"不可见"两列；去控制台 > 模型监控看账号真实在调谁。三件事都做完，才叫对过账。平台入口在百炼控制台首页。

六条公告、主线加快照两页名单、两次实测、一个会假阴性且退出码为 0 的查询命令。名单会过期，公告会再发，今天这批里最该进操作规范的只有一条：查在架的那条命令会说谎，而退出码看不出来。