余承东挂帅后首份答卷鸿蒙 Agent 端侧 30B盘古生态一个月跑起来了吗【免费下载链接】openPangu-2.0-Pro昇腾原生的openPangu-2.0-Pro语言模型项目地址: https://ai.gitcode.com/ascend-tribe/openPangu-2.0-Pro2026 年 6 月 12 日华为开发者大会HDC 2026主题演讲上余承东以终端 BG 董事长身份正式发布开源盘古 openPangu 2.0 大模型——这是他去年国庆前夕重掌大模型业务后的首次重大产品发布现场那句字典里没有第二只有第一迅速在科技圈刷屏。彼时外界最关心的不是参数数字而是三个具体问题鸿蒙生态里的 Agent 能不能真正用上盘古、端侧 30B 级别的模型能否在麒麟芯片上落地、以及承诺从 6 月 30 日起分批开源 7 大组件的盘古开源生态一个月后到底跑起来没有。一个月后答案以开源仓库的形式摆在了所有人面前6 月 30 日92B 的 openPangu-2.0-Flash 上线7 月 31 日505B 的 openPangu-2.0-Pro 模型权重、基础推理代码与技术报告如约上线即本文所在的仓库。这篇文章将结合社区情报与仓库源码逐项复盘这张挂帅首份答卷的成色。一、承诺清单HDC 2026 上余承东到底承诺了什么复盘开源节奏之前先把 HDC 2026 上公开的承诺逐条列清才能判断后续是否兑现模型矩阵openPangu 2.0 采用稀疏 MoE 架构搭载 512K 上下文窗口分两个版本——Pro 总参数 505B、激活参数 18BFlash 总参数 92B、激活参数仅 6B稀疏配比大幅降低运行负载昇腾深度调优模型原生针对昇腾芯片优化据发布会口径单卡推理吞吐率可达市面主流开源模型的 2 倍鸿蒙 Agent 专项优化openPangu 2.0 对 Agent 任务做专项优化执行速度与精准度更优、资源消耗更低端侧能力支持端侧 30B 级别模型运行于麒麟芯片开源路线图从 6 月 30 日起分批开源 7 大组件包括新增的预训练代码、后训练代码与训练算子。值得注意的是余承东对参数规模的解释505B 并非算力上限而是算力大量支持了国内其他企业需求自己留的数量非常有限AI 算力成本非常高华为更聚焦时延和吞吐率的提升。这句话定下了盘古 2.0 的路线——不拼参数拼工程效率这也与后来开源技术栈的走向完全一致。二、开源节奏复盘一个月跑通了什么对照承诺清单看执行节奏时间线非常清晰时间事件对应承诺2026-06-12HDC 2026 发布 openPangu 2.0宣布 7 大组件分批开源发布2026-06-30openPangu-2.0-Flash 模型权重、基础推理代码、训推算子上线Flash 按期兑现2026-07-31openPangu-2.0-Pro 模型权重、基础推理代码与技术报告上线Pro 按期兑现2026-09-28预训练代码、SFT 代码、后训练 RL 代码上线训练/后训练组件兑现也就是说从 6 月 30 日 Flash 开源到 7 月 31 日 Pro 开源恰好一个月内完成了主力模型矩阵的完整上架而预训练—SFT—RL全链路代码在 9 月底跟进七组件清单整体在按计划分批兑现。这个节奏在国产大模型开源史上属于相当克制的承诺—交付闭环——没有跳票只是分批次。而 7 月 31 日上线的本仓库openPangu-2.0-Pro正是这张答卷的核心实物约 505B 总参数、18B 激活参数的 MoE 模型以 277 个 safetensors 分片落地model.safetensors.index.json并附带完整技术报告 openPangu-2.0 Tech Report.pdf。三、源码级拆解这张答卷的技术含量在哪仓库体量并不大——配置文件、分词器、权重分片与许可证——但技术信息密度极高。读一遍 config.json 和 configuration_openpangu_v2.py就能还原出 2.0-Pro 的完整架构画像。3.1 稀疏 MoE384 路由专家激活仅 18Bconfig 中n_routed_experts: 384、num_experts_per_tok: 8、n_shared_experts: 1、first_k_dense_replace: 3——前 3 层为稠密层其余 47 层为 MoE 层每 token 只激活 8 个路由专家加 1 个共享专家配合routed_scaling_factor: 2.5与norm_topk_prob: true。这正是505B 总参、18B 激活的由来稀疏路由把单 token 的计算成本压低到接近稠密 20B 模型的水平而知识容量保留在 500B 量级。3.2 长上下文与注意力的工程化取舍512K 上下文max_position_embeddings: 524288是这次发布的最大卖点之一但支撑它的不是蛮力堆算力而是三套机制的组合MLA多头潜变量注意力沿用高效 MLAkv_lora_rank: 512、q_lora_rank: 1536将 KV 缓存大幅压缩缓解长序列推理的显存压力DSA SWA 分层混合50 层中swa_layers列出 35 层滑动窗口注意力窗口 512dsa_layers列出 18 层稀疏全局聚合层层配比约 1:2。SWA 负责局部窗口建模、DSA 负责稀疏全局聚合在保持精度的同时显著降低长序列推理的计算、显存与访存开销README.md 第 2 节对此有官方说明稀疏索引器index_n_heads: 32、index_topk: 2048、param_sink_number: 128配合router_sliding_window: 3为长上下文的全局信息聚合提供低成本的索引通道。3.3 自投机3 头 MTP 一次多猜 3 个 tokenconfig 中num_nextn_predict_layers: 3对应 README 所述的 3 头 MTPMulti-Token Prediction自投机模块——额外预测 3 个 token配合昇腾硬件的算子融合显著提升推理吞吐。这一设计与单卡吞吐率 2 倍的宣称互为印证自投机本质是用更少的串行解码步数换更高的 token 产出率。3.4 拓扑与优化器mHC 四支流与 Muonmhc_num_stream: 4、use_mhc: true对应 4 支流 mHCmulti-stream Hierarchical Connectivity拓扑把传统残差连接升级为多支流结构以提升表征多样性use_mome: true对应训练中采用的 Muon 优化器追求更快收敛。这些细节在训练代码开源openPangu-2.0-Training 仓后都可以被社区直接复现验证。3.5 分词器的工程细节tokenization_openpangu_v2.py 中预分词正则对中文标点做了全角/半角、CJK 标点集合的精细处理BPE 采用 byte-level 回退tokenizer_config.json 中vocab_size: 151552除文本起止符外还定义了对话与工具调用专用 token见下一节。可以说盘古 2.0 的中文原生不止体现在训练数据上也写进了分词器代码里。四、鸿蒙 Agent 原生集成tokenizer 里藏着证据原生集成鸿蒙 Agent常被当作发布会修辞但在 tokenizer_config.json 的特殊 token 表里能看到实打实的设计证据|message_start|/|message_end|id 148901/148902结构化对话边界|tool_call_start|/|tool_call_end|id 148903/148904工具调用边界即 Agent 的 Function Calling 通道think//thinkid 148905/148906思考过程标记为慢思考/推理模式预留。这些 token 意味着模型从预训练阶段起就被训练成以对话工具调用的原生协议来交互而不是靠后处理硬拼 JSON。评测数据也给出了支撑在 README.md 第 3 节的 Agent 能力评测中Pro-Thinking 在 TAU2-BenchAvg3达 81.1、MCP-Atlas 达 61.3、WildClawBench 达 46.5、BrowseComp 达 65.7——Agent 任务并非弱项而是与通用能力并列的主线。生态侧的落地动作同样在推进6 月 30 日 Flash 开源的同一周期华为小艺 Claw 即宣布接入开源盘古 2.0 Pro 模型重点提升鸿蒙系统级任务执行能力。这与硬件—模型—Agent—生态全栈打通的叙事一致——openPangu 2.0 不是单独卖模型而是作为鸿蒙智能体底座的底座。五、端侧 30B 上麒麟可行性拆解支持端侧 30B 模型运行于麒麟芯片是发布会最具想象力的表述也是社区争论最多的点。30B 参数的全精度权重在手机上显然放不下约 60GB FP16所以关键在三点量化、稀疏路由与 NPU 协同。从盘古家族已有实践看端侧路径早已铺好此前的 openPangu-Embedded-1B 专为端侧设计基于昇腾 NPU 优化采用 GQA 注意力与 RoPE 位置编码提供 SHA-256 权重校验、vLLM-Ascend 部署与模型热更新等完整工具链openPangu-Embedded-7B 则有知识蒸馏教师-学生、Istio 服务网格治理等企业级配套。这些组件证明盘古系在端侧与边缘侧的工程积累是成体系的。落到 HarmonyOS 7 的实际接入社区实战文章给出了更冷静的图景端侧模型加载需避免主线程阻塞、流式文本生成、多轮对话受 8K tokens 上下文上限约束需要压缩策略、Function Calling 机制用于实现 Agent 调度以及围绕 NPU 的预热、批处理、后台保活与降级策略。也就是说端侧 30B 的可行性不在于能不能塞进手机而在于量化版本 NPU 调度 上下文管理这套系统工程能否在麒麟芯片上把延迟和功耗压到可用区间。盘古 2.0 的 MoE 稀疏激活18B/6B恰好是天然利好——激活参数越小端侧能效比越可控这也是 Flash 版6B 激活而非 Pro 版更可能成为端侧主力候选的原因。六、生态活跃度盘点从 1B 到 718B 的完整矩阵把时间线拉长到发布前后半年openPangu 的开源动作远不止 2.0 这一个点而是铺出了一条完整的产品线矩阵端侧/边缘openPangu-Embedded-1B、Embedded-7B覆盖端侧部署、蒸馏、热更新场景旗舰开源openPangu-2.0-Flash92B/6B 激活与 2.0-Pro505B/18B 激活7 月前全部上线准万亿级 MoEopenPangu-Ultra-MoE-718B-V1.1718B 总参/39B 激活配套开源 Omni Proxy 调度特性与 AMLA 算子——后者通过以加代乘的重构将昇腾硬件算力利用率推至 86.8%614 TFLOPS远超当时 FlashMLA 在 H800 上约 66.7% 的水平直接把推理效率竞争拉到了算子级架构探索openPangu-R-7B-Diffusion 扩散语言模型突破 32K 上下文并解锁慢思考openPangu-R-72B 在 SuperCLUE 11 月 DeepSearch 评测登顶——证明盘古系在非自回归生成与深度搜索等前沿方向同样在开源输出。社区侧的技术热度也可量化围绕 Embedded 系列的部署、校验、许可证解读文章在 CSDN 持续产出单篇收藏量从十余次到数十次不等openPangu-2.0-Flash 的同档模型横评文章阅读量超 7.5 万社区关注点已经从看发布会转向怎么部署、怎么微调、怎么合规商用。而一份真实的横评也给出了有价值的反差结论openPangu-2.0-Flash 在结构化输出任务中首轮 100% 通过率最优指令遵循与输出稳定性是强项但响应延迟显著高于同档竞品——也就是说盘古的优势是稳与准而非单纯的速度或跑分。七、冷静看待许可证边界与能力短板开源不等于无约束。LICENSE 文件中的 OPENPANGU MODEL LICENSE AGREEMENT VERSION 2.0 明确了几条硬边界禁止在欧盟境内使用第 3.1 条若发起针对该模型的版权或专利诉讼许可将自动终止第 3.2 条再分发时须保留协议副本基于模型的产品须标注Powered by openPangu并附商标声明第 4.2 条。对于计划做衍生模型或商用的团队这些条款尤其欧盟限制与专利诉讼终止机制必须在立项前纳入合规评估。能力边界同样需要正视README 的测评表中Pro-Thinking 与 Non-Thinking 在 Apex17.7 vs 2.1、HLE27.1 vs 9.0等极限推理集上的分数说明快慢两个模式差距巨大——快推理Non-Thinking更适合日常 Agent 任务慢推理Thinking才适合攻坚数学与深度推理而在横评中暴露的延迟问题则指向单卡吞吐率 2 倍的工程优化更多体现在吞吐而非首 token 延迟上。这提醒使用者选型时要把思考模式开关和时延预算一并纳入设计而非只看总参数。结语一个月跑通了主干全链路仍在兑现回到标题的问题盘古生态一个月跑起来了吗答案是——主干跑通了全链路还在兑现。一个月内Flash 与 Pro 双版本权重、基础推理代码、训推算子与技术报告全部按承诺上线预训练/SFT/RL 代码在 9 月底跟进7 大组件路线图无跳票鸿蒙侧的 Agent 集成有小艺 Claw 接入 Pro 模型佐证端侧 30B 有 Embedded 系列与 HarmonyOS 实战路径支撑。但生态的真正繁荣取决于三件尚未完全兑现的事训练代码复现出的性能是否与论文一致、昇腾之外的硬件能否承接这股开源势能、以及许可证边界下的商用生态能长多大。余承东说字典里没有第二只有第一——对开源生态而言第一不在发布会上而在每一个 fork、每一次评测复现和每一行生产代码里。【免费下载链接】openPangu-2.0-Pro昇腾原生的openPangu-2.0-Pro语言模型项目地址: https://ai.gitcode.com/ascend-tribe/openPangu-2.0-Pro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 余承东挂帅后首份答卷：鸿蒙 Agent + 端侧 30B，盘古生态一个月跑起来了吗？
余承东挂帅后首份答卷鸿蒙 Agent 端侧 30B盘古生态一个月跑起来了吗【免费下载链接】openPangu-2.0-Pro昇腾原生的openPangu-2.0-Pro语言模型项目地址: https://ai.gitcode.com/ascend-tribe/openPangu-2.0-Pro2026 年 6 月 12 日华为开发者大会HDC 2026主题演讲上余承东以终端 BG 董事长身份正式发布开源盘古 openPangu 2.0 大模型——这是他去年国庆前夕重掌大模型业务后的首次重大产品发布现场那句字典里没有第二只有第一迅速在科技圈刷屏。彼时外界最关心的不是参数数字而是三个具体问题鸿蒙生态里的 Agent 能不能真正用上盘古、端侧 30B 级别的模型能否在麒麟芯片上落地、以及承诺从 6 月 30 日起分批开源 7 大组件的盘古开源生态一个月后到底跑起来没有。一个月后答案以开源仓库的形式摆在了所有人面前6 月 30 日92B 的 openPangu-2.0-Flash 上线7 月 31 日505B 的 openPangu-2.0-Pro 模型权重、基础推理代码与技术报告如约上线即本文所在的仓库。这篇文章将结合社区情报与仓库源码逐项复盘这张挂帅首份答卷的成色。一、承诺清单HDC 2026 上余承东到底承诺了什么复盘开源节奏之前先把 HDC 2026 上公开的承诺逐条列清才能判断后续是否兑现模型矩阵openPangu 2.0 采用稀疏 MoE 架构搭载 512K 上下文窗口分两个版本——Pro 总参数 505B、激活参数 18BFlash 总参数 92B、激活参数仅 6B稀疏配比大幅降低运行负载昇腾深度调优模型原生针对昇腾芯片优化据发布会口径单卡推理吞吐率可达市面主流开源模型的 2 倍鸿蒙 Agent 专项优化openPangu 2.0 对 Agent 任务做专项优化执行速度与精准度更优、资源消耗更低端侧能力支持端侧 30B 级别模型运行于麒麟芯片开源路线图从 6 月 30 日起分批开源 7 大组件包括新增的预训练代码、后训练代码与训练算子。值得注意的是余承东对参数规模的解释505B 并非算力上限而是算力大量支持了国内其他企业需求自己留的数量非常有限AI 算力成本非常高华为更聚焦时延和吞吐率的提升。这句话定下了盘古 2.0 的路线——不拼参数拼工程效率这也与后来开源技术栈的走向完全一致。二、开源节奏复盘一个月跑通了什么对照承诺清单看执行节奏时间线非常清晰时间事件对应承诺2026-06-12HDC 2026 发布 openPangu 2.0宣布 7 大组件分批开源发布2026-06-30openPangu-2.0-Flash 模型权重、基础推理代码、训推算子上线Flash 按期兑现2026-07-31openPangu-2.0-Pro 模型权重、基础推理代码与技术报告上线Pro 按期兑现2026-09-28预训练代码、SFT 代码、后训练 RL 代码上线训练/后训练组件兑现也就是说从 6 月 30 日 Flash 开源到 7 月 31 日 Pro 开源恰好一个月内完成了主力模型矩阵的完整上架而预训练—SFT—RL全链路代码在 9 月底跟进七组件清单整体在按计划分批兑现。这个节奏在国产大模型开源史上属于相当克制的承诺—交付闭环——没有跳票只是分批次。而 7 月 31 日上线的本仓库openPangu-2.0-Pro正是这张答卷的核心实物约 505B 总参数、18B 激活参数的 MoE 模型以 277 个 safetensors 分片落地model.safetensors.index.json并附带完整技术报告 openPangu-2.0 Tech Report.pdf。三、源码级拆解这张答卷的技术含量在哪仓库体量并不大——配置文件、分词器、权重分片与许可证——但技术信息密度极高。读一遍 config.json 和 configuration_openpangu_v2.py就能还原出 2.0-Pro 的完整架构画像。3.1 稀疏 MoE384 路由专家激活仅 18Bconfig 中n_routed_experts: 384、num_experts_per_tok: 8、n_shared_experts: 1、first_k_dense_replace: 3——前 3 层为稠密层其余 47 层为 MoE 层每 token 只激活 8 个路由专家加 1 个共享专家配合routed_scaling_factor: 2.5与norm_topk_prob: true。这正是505B 总参、18B 激活的由来稀疏路由把单 token 的计算成本压低到接近稠密 20B 模型的水平而知识容量保留在 500B 量级。3.2 长上下文与注意力的工程化取舍512K 上下文max_position_embeddings: 524288是这次发布的最大卖点之一但支撑它的不是蛮力堆算力而是三套机制的组合MLA多头潜变量注意力沿用高效 MLAkv_lora_rank: 512、q_lora_rank: 1536将 KV 缓存大幅压缩缓解长序列推理的显存压力DSA SWA 分层混合50 层中swa_layers列出 35 层滑动窗口注意力窗口 512dsa_layers列出 18 层稀疏全局聚合层层配比约 1:2。SWA 负责局部窗口建模、DSA 负责稀疏全局聚合在保持精度的同时显著降低长序列推理的计算、显存与访存开销README.md 第 2 节对此有官方说明稀疏索引器index_n_heads: 32、index_topk: 2048、param_sink_number: 128配合router_sliding_window: 3为长上下文的全局信息聚合提供低成本的索引通道。3.3 自投机3 头 MTP 一次多猜 3 个 tokenconfig 中num_nextn_predict_layers: 3对应 README 所述的 3 头 MTPMulti-Token Prediction自投机模块——额外预测 3 个 token配合昇腾硬件的算子融合显著提升推理吞吐。这一设计与单卡吞吐率 2 倍的宣称互为印证自投机本质是用更少的串行解码步数换更高的 token 产出率。3.4 拓扑与优化器mHC 四支流与 Muonmhc_num_stream: 4、use_mhc: true对应 4 支流 mHCmulti-stream Hierarchical Connectivity拓扑把传统残差连接升级为多支流结构以提升表征多样性use_mome: true对应训练中采用的 Muon 优化器追求更快收敛。这些细节在训练代码开源openPangu-2.0-Training 仓后都可以被社区直接复现验证。3.5 分词器的工程细节tokenization_openpangu_v2.py 中预分词正则对中文标点做了全角/半角、CJK 标点集合的精细处理BPE 采用 byte-level 回退tokenizer_config.json 中vocab_size: 151552除文本起止符外还定义了对话与工具调用专用 token见下一节。可以说盘古 2.0 的中文原生不止体现在训练数据上也写进了分词器代码里。四、鸿蒙 Agent 原生集成tokenizer 里藏着证据原生集成鸿蒙 Agent常被当作发布会修辞但在 tokenizer_config.json 的特殊 token 表里能看到实打实的设计证据|message_start|/|message_end|id 148901/148902结构化对话边界|tool_call_start|/|tool_call_end|id 148903/148904工具调用边界即 Agent 的 Function Calling 通道think//thinkid 148905/148906思考过程标记为慢思考/推理模式预留。这些 token 意味着模型从预训练阶段起就被训练成以对话工具调用的原生协议来交互而不是靠后处理硬拼 JSON。评测数据也给出了支撑在 README.md 第 3 节的 Agent 能力评测中Pro-Thinking 在 TAU2-BenchAvg3达 81.1、MCP-Atlas 达 61.3、WildClawBench 达 46.5、BrowseComp 达 65.7——Agent 任务并非弱项而是与通用能力并列的主线。生态侧的落地动作同样在推进6 月 30 日 Flash 开源的同一周期华为小艺 Claw 即宣布接入开源盘古 2.0 Pro 模型重点提升鸿蒙系统级任务执行能力。这与硬件—模型—Agent—生态全栈打通的叙事一致——openPangu 2.0 不是单独卖模型而是作为鸿蒙智能体底座的底座。五、端侧 30B 上麒麟可行性拆解支持端侧 30B 模型运行于麒麟芯片是发布会最具想象力的表述也是社区争论最多的点。30B 参数的全精度权重在手机上显然放不下约 60GB FP16所以关键在三点量化、稀疏路由与 NPU 协同。从盘古家族已有实践看端侧路径早已铺好此前的 openPangu-Embedded-1B 专为端侧设计基于昇腾 NPU 优化采用 GQA 注意力与 RoPE 位置编码提供 SHA-256 权重校验、vLLM-Ascend 部署与模型热更新等完整工具链openPangu-Embedded-7B 则有知识蒸馏教师-学生、Istio 服务网格治理等企业级配套。这些组件证明盘古系在端侧与边缘侧的工程积累是成体系的。落到 HarmonyOS 7 的实际接入社区实战文章给出了更冷静的图景端侧模型加载需避免主线程阻塞、流式文本生成、多轮对话受 8K tokens 上下文上限约束需要压缩策略、Function Calling 机制用于实现 Agent 调度以及围绕 NPU 的预热、批处理、后台保活与降级策略。也就是说端侧 30B 的可行性不在于能不能塞进手机而在于量化版本 NPU 调度 上下文管理这套系统工程能否在麒麟芯片上把延迟和功耗压到可用区间。盘古 2.0 的 MoE 稀疏激活18B/6B恰好是天然利好——激活参数越小端侧能效比越可控这也是 Flash 版6B 激活而非 Pro 版更可能成为端侧主力候选的原因。六、生态活跃度盘点从 1B 到 718B 的完整矩阵把时间线拉长到发布前后半年openPangu 的开源动作远不止 2.0 这一个点而是铺出了一条完整的产品线矩阵端侧/边缘openPangu-Embedded-1B、Embedded-7B覆盖端侧部署、蒸馏、热更新场景旗舰开源openPangu-2.0-Flash92B/6B 激活与 2.0-Pro505B/18B 激活7 月前全部上线准万亿级 MoEopenPangu-Ultra-MoE-718B-V1.1718B 总参/39B 激活配套开源 Omni Proxy 调度特性与 AMLA 算子——后者通过以加代乘的重构将昇腾硬件算力利用率推至 86.8%614 TFLOPS远超当时 FlashMLA 在 H800 上约 66.7% 的水平直接把推理效率竞争拉到了算子级架构探索openPangu-R-7B-Diffusion 扩散语言模型突破 32K 上下文并解锁慢思考openPangu-R-72B 在 SuperCLUE 11 月 DeepSearch 评测登顶——证明盘古系在非自回归生成与深度搜索等前沿方向同样在开源输出。社区侧的技术热度也可量化围绕 Embedded 系列的部署、校验、许可证解读文章在 CSDN 持续产出单篇收藏量从十余次到数十次不等openPangu-2.0-Flash 的同档模型横评文章阅读量超 7.5 万社区关注点已经从看发布会转向怎么部署、怎么微调、怎么合规商用。而一份真实的横评也给出了有价值的反差结论openPangu-2.0-Flash 在结构化输出任务中首轮 100% 通过率最优指令遵循与输出稳定性是强项但响应延迟显著高于同档竞品——也就是说盘古的优势是稳与准而非单纯的速度或跑分。七、冷静看待许可证边界与能力短板开源不等于无约束。LICENSE 文件中的 OPENPANGU MODEL LICENSE AGREEMENT VERSION 2.0 明确了几条硬边界禁止在欧盟境内使用第 3.1 条若发起针对该模型的版权或专利诉讼许可将自动终止第 3.2 条再分发时须保留协议副本基于模型的产品须标注Powered by openPangu并附商标声明第 4.2 条。对于计划做衍生模型或商用的团队这些条款尤其欧盟限制与专利诉讼终止机制必须在立项前纳入合规评估。能力边界同样需要正视README 的测评表中Pro-Thinking 与 Non-Thinking 在 Apex17.7 vs 2.1、HLE27.1 vs 9.0等极限推理集上的分数说明快慢两个模式差距巨大——快推理Non-Thinking更适合日常 Agent 任务慢推理Thinking才适合攻坚数学与深度推理而在横评中暴露的延迟问题则指向单卡吞吐率 2 倍的工程优化更多体现在吞吐而非首 token 延迟上。这提醒使用者选型时要把思考模式开关和时延预算一并纳入设计而非只看总参数。结语一个月跑通了主干全链路仍在兑现回到标题的问题盘古生态一个月跑起来了吗答案是——主干跑通了全链路还在兑现。一个月内Flash 与 Pro 双版本权重、基础推理代码、训推算子与技术报告全部按承诺上线预训练/SFT/RL 代码在 9 月底跟进7 大组件路线图无跳票鸿蒙侧的 Agent 集成有小艺 Claw 接入 Pro 模型佐证端侧 30B 有 Embedded 系列与 HarmonyOS 实战路径支撑。但生态的真正繁荣取决于三件尚未完全兑现的事训练代码复现出的性能是否与论文一致、昇腾之外的硬件能否承接这股开源势能、以及许可证边界下的商用生态能长多大。余承东说字典里没有第二只有第一——对开源生态而言第一不在发布会上而在每一个 fork、每一次评测复现和每一行生产代码里。【免费下载链接】openPangu-2.0-Pro昇腾原生的openPangu-2.0-Pro语言模型项目地址: https://ai.gitcode.com/ascend-tribe/openPangu-2.0-Pro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考