据 PPIO 派欧云官方公告10 月 9 日起一批大家常见的模型集中下线包括qwen3.6-plus、qwen3.5-plus、qwen3-coder-next、qwen3-max、glm-5-turbo、minimax-m2含 m2.1、m2.5-highspeed等官方给出的替换模型是qwen3.8-max、glm-5.3-flash、minimax-m3等。紧接着 10 月 10 日deepseek-v4-flash也被deepseek-v4.1-flash取代。更早的 9 月 30 日多款视频模型Wan 2.5/2.6/2.7、MiniMax Hailuo 2.3 等统一被指向 Kling 3.0。官方措辞很直接停服后原 API 调用会返回错误码请尽快迁移。这不是某一家的问题。同一时间段阿里云百炼也在批量下线第三方模型和历史快照模型。对写代码的人来说一个越来越清晰的现实是大模型的 API不是一个稳定接口而是个会频繁过期的东西。事实本身模型版本正在加速轮换把这次下架列表摊开看规律很清楚下架模型下架时间替换模型qwen3.6-plus / qwen3.5-plus / qwen3-max2026-10-09qwen3.8-maxqwen3-coder-next2026-10-09qwen3.8-maxglm-5-turbo / glm-5v-turbo2026-10-09glm-5.3-flashminimax-m2 / m2.1 / m2.5-highspeed2026-10-09minimax-m3deepseek-v4-flash2026-10-10deepseek-v4.1-flash有两个细节值得注意有替换的还算好的像qwen3-embedding-0.6b、ernie-4.5-vl-424b这类公告里替换模型一栏是空的意思是自己想办法。从替换关系能看出平台的商业意图绝大多数请求被统一导向自家的旗舰/新档位比如qwen3.8-max。平台的资源在向少数几个主力模型集中长尾模型天然活不久。变的是什么以前我们习惯了接口定好几年不动现在是模型一年迭代好几代旧版本半年就下线。模型正在按软件版本的方式管理生命周期。没变的是什么无论名字怎么换底层还是 OpenAI 兼容的调用方式——多数的迁移工作是改一个model字符串。这也算不幸中的万幸。技术本质你把 model 名硬编码在哪坑就在哪断供之所以让人头疼往往不是模型本身而是我们自己的代码。常见的坏习惯有把modelqwen3.6-plus直接写死在业务代码里散落在十几个文件用模型名去判断分支逻辑if model xxx没有回归测试迁移后只能人工肉眼看输出对不对没人看平台公告等线上报404 / model not found才发现。说到底模型名是配置不是代码。把它当配置管迁移就是改一行把它当代码写迁移就是一场事故。实用建议给模型加一层路由最省事的做法是在业务和厂商 SDK 之间加一层薄封装统一走别名 → 实际模型的映射并支持回退链。下面这个示例是真实可用的思路基于 OpenAI 兼容接口任何厂商只要提供兼容端点都能套# model_router.py —— 模型别名 回退链把厂商差异挡在业务之外importosfromopenaiimportOpenAI# 别名 - 该平台上的实际模型名换模型只改这里ALIAS{chat-main:[qwen3.8-max,glm-5.3-flash],# 按顺序回退chat-cheap:[qwen3.8-flash,minimax-m3],}# 每个平台一个 clientbase_url 从环境变量读别写死CLIENTS{ppio:OpenAI(base_urlhttps://api.ppinfra.com/v3/openai,api_keyos.environ[PPIO_API_KEY],),}defchat(alias:str,messages:list,platform:strppio):clientCLIENTS[platform]last_errNonefornameinALIAS[alias]:# 逐个候选模型尝试try:returnclient.chat.completions.create(modelname,messagesmessages,)exceptExceptionase:# 模型下线常抛 404回退到下一个last_errecontinueraiseRuntimeError(f所有候选模型均不可用:{last_err})if__name____main__:rchat(chat-main,[{role:user,content:用一句话说明什么是回退链}])print(r.choices[0].message.content) 配套还有几件小事成本很低但很值-**订阅下架公告**。平台的模型下线通知页基本就是你的接口变更日志用 RSS 或定时脚本盯着别等线上炸。--**写回归用例**。挑10~20条真实输入迁移前后各跑一遍比对输出质量别只看接口通不通。--**算清成本账**。新旧模型的价格和 token 用量可能差不少尤其旗舰替换旧款这种迁移前先跑个成本对比。另外注意计费口径——像请求到达模型即计费这类规则意味着断开连接也可能照样扣费别用重试去暴力刷。--**别把鸡蛋放一个篮子**。核心链路至少留一个第二平台的备选抽象层做好了切厂商就是换 base_url。 如果把这套落到流程上可以很简单每次厂商发下架公告先跑脚本对比你在用的模型名和公告里的下架列表命中就建一个迁移工单迁移时固定流程——改别名映射、跑回归用例、对比成本、灰度放量、观察一周。流程不复杂关键是别等到接口报错才想起来。 还有一个心态问题值得说很多人纠结到底用哪个模型最好其实在模型半年一换的节奏下纠结意义不大。与其把精力花在选一个永恒最优的模型不如花在让代码换模型不疼上。前者是运气后者是工程能力。## 收个尾模型加速迭代本身是好事说明技术在往前跑但对做工程的人来说API 随时会过期正在变成新的常态。与其每次被动救火不如一开始就把它当成一个会变的依赖来设计。你手上的项目是硬编码模型名还是已经做了抽象层评论区聊聊。---参考PPIO 派欧云官方公告、阿里云百炼公告等公开信息整理。