一句话结论：盘古没有停售，但 openPangu-2.0-Flash / 2.0-Pro 真的会在 2026 年 11 月 30 日 00:00（北京时间）下线。11 月 15 日接棒的 openPangu-2.1-Pro 不是"参数更大"，而是"更懂鸿蒙 ArkTS 和昇腾算子"。对还在调 2.0 的团队，这是本月唯一有硬截止日的技术债。

一、先把传言和事实切开

上周"华为云停售盘古"的消息在群里转了一圈，很多人第一反应是"盘古要黄了"。实际情况是两件事被混成了一件：

• 老版本生命周期收尾：华为云 11 月 1 日公告，MaaS 模型即服务平台于 2026 年 11 月 6 日 00:00 停止销售 openPangu-2.0-Flash、openPangu-2.0-Pro，并于 2026 年 11 月 30 日 00:00 正式下线。停售之后新用户不能开通，已购用户还能继续用；下线之后，新老用户都无法调用。
• 新版本排期已定：MaaS 平台将于 11 月 15 日更新上线 openPangu-2.1-Pro 旗舰模型，并同步接入智果 AgentArts、码道 CodeArts、果办 OfficeAce 三款产品。目前小艺 Work 已经先期用上了这颗模型，主打"鸿蒙任务增强"。

也就是说：下线的是两个型号，不是产品线。华为云也已通过官方短信通知现网用户提前准备迁移。

但注意一个细节：2.1-Pro 的参数量、激活量、上下文长度、训练数据等规格，官方目前尚未公开。所以任何"2.1-Pro 参数吊打某某"的说法，现阶段都不成立。做技术决策，只能按已经公开的两条信息来：ArkTS 代码生成质量提升、面向昇腾底层算子开发流程做了适配。

这两条正是本轮选型重点。

时间线（建议直接贴进你的迭代排期）

时间（北京时间）	事件	对开发者的含义
2026-11-06 00:00	openPangu-2.0-Flash / 2.0-Pro 停止销售	新项目不能再选这两个型号
2026-11-15	openPangu-2.1-Pro 在 MaaS 上线	可开通、可灰度、可评测
2026-11-30 00:00	两个 2.0 型号正式下线	未迁移的调用会直接失败

官方替代建议：2.0-Flash → DeepSeek-V4.1-Flash-1017，2.0-Pro → GLM-5.3。华为云同时提示：不同模型在支持能力、API 参数、单价与任务表现上存在差异，迁移前需阅读模型介绍并做评测——这不是免责声明，是操作指令。

二、行业痛点：通用旗舰模型，为什么在你的仓库里"编译不过"

这两年大家选模型的方式，基本是看榜单、看演示、看价格。真正落地时踩的坑却在另一个维度：

第一层，语言方言。 榜单测的是 Python、Java、JS 这类语料海量的主流语言。ArkTS 是鸿蒙原生开发语言，生态新、公开语料相对稀缺，通用模型能写出"看起来对"的代码，但类型声明、装饰器、状态管理、页面路由这些细节经常不贴合 ArkTS 的工程约束，最后变成"生成 80 行、手改 60 行"。这也是华为云这次把"ArkTS 代码生成质量"单独拎出来作为升级点的原因——它修的是方言，不是通用智力。

第二层，算子。 算子是模型能力与芯片之间的翻译层。写一个能在昇腾上跑得动、跑得快的算子，涉及 tiling 策略、内存搬运、流水编排，公开资料极少。通用模型在这里通常只能"给个模板"，调试还得靠人。把算子开发纳入优化方向，本质是在补国产算力生态的最后一公里。

第三层，工具链断点。 模型能生成代码，但代码要进 IDE、进流水线、进办公流程。模型与工具割裂，就会出现"AI 生成得很爽，落地还是要人工搬三次"的尴尬。这次 2.1-Pro 同步接入 AgentArts（智能体搭建）、CodeArts（软件开发）、OfficeAce（日常办公），是把模型从"API"变成"工作流里的一个角色"。

一句话总结痛点：通用模型解决的是"会不会"，工程现场卡的是"合不合规、跑不跑得动、接不接得上"。

三、方案价值：垂直优化到底值多少钱

不谈情怀，谈可量化的三个方向：

1. 减少返工轮次。代码生成的关键指标不是"能不能生成"，而是"一次通过率"。方言类优化对通过率的影响通常大于通用能力提升——它减少的是"改语法"的无效循环，这对工程师是纯消耗。
2. 降低适配成本。模型与昇腾开发流程对齐后，团队在算子调试、性能调优上的隐性工时会被压缩。压缩多少取决于算子复杂度与团队熟练度，建议用自己的任务集实测，不要相信任何百分比。
3. 减少集成胶水。模型直接进入 AgentArts / CodeArts / OfficeAce 后，省掉自建编排层、鉴权与日志的工程量，对中小团队往往是能否按期上线的关键。

华为云在政务、矿山、铁路、金融等行业已有模型落地经验，这种"行业 + 工程"双轮驱动的路线，对做 To B 交付的团队更友好：你只需证明它在你的场景里能用。

四、对比分析：三条迁移路径，怎么选

表 1：2.0-Pro 与 2.1-Pro 的定位差异（按公开信息整理）

维度	openPangu-2.0-Pro（11/30 下线）	openPangu-2.1-Pro（11/15 上线）
定位	通用旗舰，面向通用推理与 Agent 规划	面向鸿蒙 + 昇腾生态的工程化旗舰
公开升级点	—	ArkTS 代码生成质量提升；昇腾底层算子开发流程适配
产品接入	基础 MaaS 调用	同步接入 AgentArts、CodeArts、OfficeAce
生命周期	11/30 00:00 下线	接替 2.0 型号，规格待官方披露
适合人群	通用对话、文案、通用智能体	鸿蒙原生开发、昇腾算子与 AI 工程团队

表 2：三条迁移路径的实际代价

路径	改动成本	能力风险	合规/数据	适合谁
A. 原地升级到 2.1-Pro	低（同平台、同账号体系，改模型 ID 与参数）	中低（新模型规格未公开，需自测）	最省心，仍在华为云体系内	已在华为云跑通、且看重鸿蒙/昇腾适配的团队
B. 换官方建议的第三方模型（DeepSeek-V4.1-Flash-1017 / GLM-5.3）	中（接口参数、计费口径、能力边界都变）	中（能力分布不同，需重新评测）	仍在 MaaS 内，但模型来源变化	通用对话为主、对鸿蒙/算子无强需求的团队
C. 双模型路由（主模型 + 兜底）	高（要做路由、降级、结果一致性校验）	低（可用性最好）	需要额外治理	有 SLA 要求、调用量大、不能中断的业务

我的建议：多数团队走 A + 小流量灰度，把 B 作为压测对照基线（正好满足官方"迁移前做评测"的要求）；只有已有多模型网关时才值得上 C。

成本视角：别用"单价"做决策

正确的口径是单位任务成本，而不是每千 Token 单价：

单位任务成本 = (调用次数 × 平均单次 Token × 单价) ÷ 任务一次通过率

分母常被忽略：单价便宜 30%、但一次通过率低 20 个百分点的模型，实际成本很可能更高，因为返工时间也是钱。具体单价与规格以华为云官网当期页面为准，本文不复述价格。

五、6 步迁移检查清单（可直接抄进工单）

1. 盘点存量调用：列出代码里所有模型 ID、endpoint、SDK 版本，标出 2.0-Flash / 2.0-Pro；别漏定时任务、离线批处理、评测脚本这类"没人维护但一直在跑"的地方。
2. 量化基线：在迁移前用现网 2.0 跑一遍你的真实任务集，记录通过率、平均时延、Token 消耗。没有基线，迁移后的效果就无法证明。
3. 11/15 后开通 2.1-Pro 并跑同一套任务集：同一份 prompt、同一份输入，只换模型。重点看代码类任务的一次通过率和可编译率。
4. 灰度切换：先 5%~10% 流量，观察错误率、时延 P95、超时与限流。新模型上线初期存在限流或个别场景待调优的可能，灰度是唯一的安全垫。
5. 兜底方案：准备备用模型（如官方建议型号）并写好降级开关，11/30 后出问题它就是救命按钮。
6. 11/30 前全量切换 + 回归：把老模型 ID 从代码里彻底删掉，避免"配置里还留着"导致的隐性故障。

评测脚本骨架（示意，接口细节以官方文档为准）

# 最小可用的 A/B 评测骨架：同一数据集，跑两个模型，对比通过率 import os, json, time from statistics import mean BASE_URL = os.environ["MAAS_BASE_URL"] # 以华为云 MaaS 控制台文档为准 API_KEY = os.environ["MAAS_API_KEY"] def call(model: str, prompt: str) -> dict: # 用你现有的 SDK 或 HTTP 客户端替换此处实现 raise NotImplementedError def evaluate(model: str, cases: list[dict]) -> dict: lat, tokens, passed = [], [], 0 for c in cases: t0 = time.time() r = call(model, c["prompt"]) lat.append((time.time() - t0) * 1000) tokens.append(r.get("usage", {}).get("total_tokens", 0)) passed += int(check(r["text"], c["expect"])) # check() 用你的断言/编译校验 return { "model": model, "pass_rate": passed / len(cases), "p95_latency_ms": sorted(lat)[int(len(lat) * 0.95) - 1], "avg_tokens": mean(tokens), }

把 check() 写成"能不能编过、能不能跑通、断言是否成立"三档，比肉眼打分靠谱。代码任务要接编译/静态检查，不要只看输出像不像。

六、三个容易踩的坑

• 把"停售"当"立即不可用"：停售只是不能新购，下线才是断服，11/30 前老模型仍可调用。
• 只看榜单迁移：2.1-Pro 规格尚未公开，任何"能力排序"都是猜测，只能自己跑评测集。
• 忽略非在线链路：离线批处理、RAG 索引重建、Agent 工具调用配置，都可能硬编码老模型 ID，故障往往在 11/30 凌晨集中爆发。

七、写在最后

这次更新真正的信号是：大模型的竞争维度正在从"通用智力"转向"特定语言 + 特定算力 + 特定工具链"的垂直优化。这对开发者既是机会（不必再用通用模型硬磕鸿蒙和昇腾），也是要求——选型标准要从"跑分多少"换成"一次通过率多少、适配成本多少"。

距离 11 月 30 日 00:00 还有 19 天。今天把清单拉出来，还来得及。

正在做 2.0 → 2.1-Pro 迁移的同学，欢迎在评论区留下你的评测集构成（代码类占比、是否含 ArkTS 任务），我会汇总成一份可对比的评测模板。下一篇我会实测 ArkTS 场景下的一次通过率，关注不迷路。