引言
最近看新模型，我已经很少先看参数量了。
原因很简单：参数再大、榜单再漂亮，最后还是要落到具体任务上。写代码能不能直接跑，工具调用会不会出错，做一个完整项目时要返工几次，这些东西往往比单项 Benchmark 更有参考价值。
openPangu-2.0-Flash 这次比较特别。它有 92B 总参数，但采用 MoE 架构，每个 Token 实际激活约 6B 参数，同时支持 512K 上下文。从官方公布的数据来看，模型在指令遵循、数学推理、代码和 Agent 等测试上都有不错的成绩。
openPangu-2.0-Flash 的 Tool Call 表现很好，结构化输出也比较稳，但综合成绩并不靠前，命令行和部分 Agent 任务失分明显。到了网页应用开发、小游戏这类完整项目里，它和一些 27B 左右的模型相比，也没有拉开明显差距。评测地址：“https://www.bilibili.com/video/BV19bTm6VEAQ”
一、先看懂 openPangu-2.0-Flash
开始测试之前，还是要先把模型本身讲清楚。
这里不用展开太多架构细节。后面的横评真正需要理解的，其实就是三个地方：92B 和 6B 是什么关系，Flash 主要解决什么问题，以及为什么官方跑分不能直接代表项目效果。
1.1 92B 总参数
openPangu-2.0-Flash 是基于昇腾 NPU 训练的大规模混合专家（MoE）语言模型，参数规模约 92B，每 token 激活参数规模约 6B，模型支持 512k 上下文长度，训练数据总量约34T tokens。后训练阶段完成快慢合一微调（SFT）、多专项强化学习（RL），并通过在线蒸馏（OPD）完成能力合一。
MoE 可以理解成模型内部放了很多不同的“专家”。处理一个 Token 时，路由器会根据当前输入选择其中一部分专家参与计算，而不是每一次都把整个模型全部算一遍。
大致是这样：
1
openPangu-2.0-Flash 的总参数约为 92B，每个 Token 实际激活约 6B。不能简单按照：92B > 27B，然后默认盘古应该稳赢。92B 表示整个专家池的容量，6B Active 更接近一次推理真正参与计算的参数规模。MoE 想做的事情，本来就是把这两件事拆开：模型可以很大，但每次不必把所有参数都用上。
不过这里还有一个很容易误解的地方。
6B 激活参数并不代表它就是一个 6B 小模型。整个 92B 的模型权重依然存在，部署时仍然要考虑这些参数的存储和加载。所以它虽然在计算量上有 MoE 的优势，本地部署成本却不能简单按照 6B 模型来估算。
从工程角度看，我们后面真正应该比较的是：相近的推理成本下，openPangu 能不能把更大的参数容量转化成更好的任务效果。这比单纯比“谁的参数更大”有意义。
1.2 Flash推理效率
openPangu-2.0-Flash 还有一个比较醒目的参数：512K 上下文。这个长度已经足以覆盖很多企业场景。
比如把一整份招标文件、几十个章节的技术文档，甚至一个规模不算小的代码仓库上下文交给模型，理论上都可以放进同一次任务里。问题也随之而来。上下文越长，Attention 的计算压力和 KV Cache 占用都会增加。几十万 Token 如果完全按照普通方式处理，速度和显存压力都会很明显。
所以 openPangu 在这里用了 MLA，并组合了 DSA 和 SWA。简单理解就是，模型不会要求所有层都用同一种方式处理几十万 Token。有些层更关注附近的信息，有些层负责从长上下文里抓关键内容，用这种方式压低长文本推理的开销。
另外它还有 MTP，也就是 Multi-Token Prediction。模型在生成时可以额外预测后续多个 Token，用于提高推理效率。把这些设计放在一起，其实就比较容易理解 Flash 这个名字了。
它并不是为了把模型做小，而是希望让一个总容量很大的 MoE 模型，实际跑起来没那么“重”。
所以我更愿意把它看成一款明显偏工程应用的模型，而不是单纯追求参数规模的模型。
1.3 实际项目测试情况
openPangu-2.0-Flash 官方公布的测试覆盖得比较广。
除了常见的数学和推理任务，还有不少代码与 Agent 相关测试。Thinking 模式下，官方给出的 AIME 2026 Avg@16=93.3、LiveCodeBench V6 Avg@3=85.1、SWE-bench Verified Avg@3=63.1、TAU2-Bench Avg@3=88.0
单看这些数据，很容易对它的代码和 Agent 能力形成比较高的预期。
但标准测试里的高分，到了具体项目里还要再看任务是怎么完成的。以本文后面会用到的单次 Tool Call 为例，模型需要先判断该调用哪个函数，再根据 Schema 生成正确参数：
{
"name": "get_order_detail",
"arguments": {
"orderId": "123456"
}
}
这一类单次调用主要考察指令理解、函数选择和参数生成。当然，Tool Use 本身并不只有这一种形式，一些 benchmark 已经会加入多轮调用、并行工具和状态依赖，难度要高得多。
真正放进长链 Agent 后，问题还会继续增加。假设用户问：
“帮我分析今年公司的采购情况，判断风险项目有没有异常，再找出最值得关注的三个项目。”
模型可能先查询总体数据，再根据返回结果决定是否继续查询风险项目；拿到风险列表以后，还要判断哪些项目需要补查详情，最后把几次工具返回重新整理成结论。
这里考察的已经不只是某一次函数有没有调用正确，还包括任务规划、状态判断和连续执行。所以后面的测试会把这两件事分开看：单次 Tool Call 看调用是否准确，多步骤 Agent 看模型能不能把整条任务链走完。
Coding 也是一样。写对一个函数，与真正把一个项目跑起来，中间还有不少距离。
让模型完成一个算法函数，和让它真正做出一个能运行的数据看板，差距很大。后者还涉及需求理解、数据结构、页面状态、异常处理和 Debug。很多问题只有代码真正跑起来才会暴露。
这也解释了为什么第三方测试里会出现一个挺有意思的结果：openPangu 的 Tool Call 得分很好，但到了更完整的 Agent 和网页开发任务中，优势没有同步放大。
所以接下来不再继续分析模型参数。我们直接开始做测试。下一章先把参与横评的模型、统一测试环境和评分方法定下来，然后从第一组实际任务开始跑结果。
二、评测标准
前面看完参数，接下来就该实测了。这次我不准备再跑一套 AIME、GPQA 或 LiveCodeBench。官方已经给出了这些成绩，第三方视频也做过比较完整的标准测试，再做一遍意义不大。其实对于开发者来说更关心的是另一件事：同一个需求分别交给几款模型，最后谁交出来的东西更省心。
所以这一轮横评尽量往实际开发靠。
2.1 同参数模型比较
模型不能随便拉几个名字过来比。openPangu-2.0-Flash 有 92B 总参数，但每 Token 只激活约 6B，本身就是一个比较特殊的 MoE。于是这次我选了两类对手：一类和它一样走稀疏 MoE 路线，另一类则是更小的 Dense 模型。
暂定的四款模型如下：
4
openPangu-2.0-Flash 的 92B/6B 来自官方模型仓库。几款模型里，我比较关注 openPangu 和 Ling-2.6-flash，因为两者都采用 MoE 路线，激活参数规模也比较接近，放在一起更容易观察它们在实际任务中的表现差异。
Qwen3.6-35B-A3B 的规模更小，总参数 35B、激活参数 3B，可以作为更轻量的 MoE 参照。Qwen3.5-27B 则采用 Dense 架构，我把它放进来主要是想看看：面对同样的业务任务，一个参数规模更小的稠密模型，实际完成度会和 openPangu 相差多少。
这里需要说明一下，这种横评并不能用来单独判断 MoE 架构或者总参数规模带来了多少收益。几款模型的训练数据、后训练方式、上下文能力和服务端推理环境都不相同，最后看到的差异实际上是这些因素共同作用的结果。
所以后面的结论会尽量停留在本文能够验证的范围内：
在相同 Prompt、输入数据和任务要求下，几款模型的完成质量、稳定性和实际可用性有没有明显差异。
如果 openPangu 在 Coding 或多步骤 Agent 任务里表现更稳，我们可以说它在本文测试条件下更适合这类任务；如果和 27B Dense 的实际效果接近，也只能说明这组任务里没有拉开明显差距，不能进一步反推“92B 总参数没有价值”。
横评模型也不准备继续增加。四款已经足够覆盖大规模 MoE、轻量 MoE 和 Dense 三种不同配置，再往上加，文章很容易变成模型截图合集，反而不容易看清每一轮测试真正暴露的问题。
2.2 测试真实业务场景
横评最麻烦的一个问题，是怎样才算“公平”。一种做法是把所有模型的 Temperature、Top P、Max Tokens 全部设成完全一样。看起来很严谨，实际未必合理。
不同模型的训练方式不一样，官方推荐的采样参数也不同。比如 Qwen3.6 官方针对一般 Thinking 任务和精确 Coding 任务就分别给出了不同的推荐设置；Ling 这类模型也有自己的推理配置。把所有参数硬改成一个值，反而可能把某些模型拉到并不擅长的工作区间。
所以这次只统一真正会影响任务公平性的部分：相同 Prompt、相同输入数据、相同功能要求、相同输出限制、相同工具定义。推理参数则尽量采用模型官方推荐配置。
还有一点需要提前说明。如果一个模型同时有 Thinking 和 Non-Thinking，我不会所有题都强制开慢思考。真实项目里也不会这么用。
例如 JSON 提取、字段整理这种确定性比较强的任务，用快速模式就够了；到了 Coding、Debug 和多步骤 Agent，再打开 Thinking。我们要测的是日常使用效果，不是想办法把每个模型的 Benchmark 分数榨到最高。
对于可以自动判定的 API 任务，先做不计统计的预热，再至少保留 20 次正式运行；Coding 和 Agent 任务则固定数据集条目数，并逐条报告成功与失败。不能因为碰巧截到一次成功结果，就把偶然样本当成稳定能力。样本量、分母和置信区间必须和结果一起公开。
2.3 第一组常见的结构化业务任务
我会给模型一组采购业务数据，例如项目数量、成交金额、预算金额、风险项目数等，再要求它按照固定 JSON 返回分析结果。
{
"summary": "",
"riskLevel": "",
"indicators": [],
"followUps": []
}
同时加入几条限制，例如：不得编造输入中不存在的数据；没有同比数据时不得生成同比；等和真实业务场景问答一致，如果模型只是多写一句：“下面是根据您提供的数据生成的 JSON：”，对于聊天没有任何问题。但在真实工作流里，这一句就可能让下游 JSON.parse() 直接报错。大模型经常犯这个问题，很容易干扰到工作流的正常运行。
2.4 第二组常见前端项目
接下来进入 Coding。我平时更容易接触到的场景：做一个采购数据 ChatBI 看板。
我会提供一组固定 JSON 数据，让四个模型根据同一份需求完成页面。面至少包括：
成交金额、项目数量、风险项目数等指标、一张趋势图、风险项目列表；
最终要把页面真正跑起来。因为很多模型生成代码的时候看起来很完整，复制到项目里才发现图表没有渲染、字段映射错了，或者某个按钮根本点不动。最后真正影响体验的，往往就是这些小问题。
这一轮我会同时记录第一次生成后的完成度，以及为了跑通项目需要追加多少轮修改。假如模型 A 第一次只做到 80%，但一句话就能修好；模型 B 第一次看起来有 95%，最后却来回改了五六轮，那么实际开发体验未必是 B 更好。
2.5 第三组修代码BUG
实际开发里，大模型更多时候面对的是一堆已经存在的代码，然后有人告诉它：这里报错了，帮我看看；或者是给我修改全部的代码要怎么样。所以第三轮专门做 Debug。
我会准备一段来自实际工作流风格的 JavaScript 代码，在里面故意放几个很常见的问题，例如：字符串和对象混用、重复 JSON.stringify、错误 JSON.parse。要求模型不能重写整套逻辑，只允许在现有接口基础上修改。
在实际项目里，这通常比原来的 Bug 更麻烦。第三组测试主要看两件事：能不能找准问题，以及修完以后会不会把别的地方一起改坏。
2.6 最后一组 Agent
第四轮会是这篇文章里难度最高的一组。这次不再告诉模型应该调用哪个接口，只给它几个可用工具，例如orders_overview、orders_risk。然后提出一个完整问题：查询今年公司的采购情况，判断风险项目是否存在异常，并找出最值得关注的三个项目，说明原因。模型需要自己决定先查什么。
理想的执行过程大致是：
6
这里终于可以把 Tool Call 和 Agent 分开看了。一次函数调用格式正确，只能说明模型会用工具。真正的 Agent 还要判断什么时候调用、调用几次、上一轮结果是否足够，以及下一步应该干什么。
openPangu 官方目前公布的 Agent 测试已经覆盖 MCP-Atlas、TAU2-Bench、Claw-Eval、PinchBench 等任务，所以这也是我最期待的一轮。
Ling-2.6-flash 官方同样把 tool use、multi-step planning 和 task execution 作为这一版本重点优化的能力。两款激活参数都在 6B 左右的 MoE，真正放到同一套多工具任务里，会比单看排行榜有意思得多。
2.7 可复现指标与统计规则
前一版采用“完成度、正确性、指令遵循、稳定性、可用性”五项各 2 分的主观分制。这个办法适合快速写体验，但第三方无法根据原始回答复算 9.6 和 9.3 的差别，也很难判断 0.1 分究竟来自哪里。因此从本轮开始，不再给模型人工打 10 分制总分，改用能够从实验记录直接重算的指标。
| 指标
|
定义
| | --- | --- | |
传输成功率
|
请求获得并完整读完服务端响应的比例
| |
首轮成功率
|
第一次回答即满足该任务全部自动检查的比例
| |
严格契约通过率
|
JSON、Schema、字段值、业务规则和禁止项全部通过的比例
| |
修复后任务成功率
|
首轮失败后，最多追加 3 轮固定反馈，最终完成任务的比例
| |
修复轮数
|
成功样本在首轮之后额外需要的轮数；首轮成功记为 0
| |
Agent 任务成功率
|
Agent 数据集上，模型独立完成完整目标的条目比例；不能用单次 Tool Call 正确率代替
| |
延迟
|
同时报告 TTFT、首个可见正文时间和总时长的 median、P90、P95
|
每个比例都必须同时给出成功数、总样本数和 Wilson 95% 区间。每次请求还要保存 provider、endpoint、region 是否公开、是否 streaming、并发数、传输重试数、输入/输出 Token、实际返回 model ID 和原始响应。网络错误与内容错误分开统计，预热、冒烟、参数探测和正式样本也不能混在一起。
不同任务使用与任务目标对应的成功判据。结构化输出看严格契约；前端和 Debug 看测试是否通过、首轮成功率以及修复轮数；Agent 看完整目标是否达成、工具轨迹是否合法。这样后续每一章都可以复算，但不会为了凑一个总分而把不同性质的指标硬加在一起。
三、实战测试：结构化业务任务
第一轮还是从结构化采购分析开始。这类任务没有 Coding 那么显眼，也没有 Agent 那么复杂，但我平时做工作流时反而很看重它。因为模型返回的结果通常不是给人直接阅读，而是马上交给 JSON.parse()、Schema 校验或者下一个节点。
这种情况下，“大概答对”没什么用。少一个字段、单位自己改了、JSON 外面多一句解释，后面的程序都可能直接失败。
每款模型先预热 2 次，再进行 20 次正式首轮请求；如果首轮没有通过严格校验，允许模型根据固定反馈最多修复 3 次。最后一共得到80 个正式首轮请求，以及 21 个实际发生的修复请求。
3.1 数据集和严格输出契约
数据集是一组 2026 年上半年采购经营记录。核心指标如下：
| 指标
|
数值
| | --- | --- | |
项目数量
|
12 个
| |
预算金额
|
9340 万元
| |
成交金额
|
8593 万元
| |
风险项目数
|
4 个
| |
高风险项目数
|
2 个
| |
待验收项目数
|
2 个
|
输入还包括六个月成交金额和四个风险项目。六个月金额合计为 8593 万元，风险项目按风险分排列：
{
"period": "2026-01-01/2026-06-30",
"projectCount": 12,
"budgetAmount": 9340,
"awardedAmount": 8593,
"riskProjectCount": 4,
"highRiskProjectCount": 2,
"pendingAcceptanceCount": 2,
"riskProjects": [
{"projectId": "PRJ-2026-007", "riskScore": 91, "facts": ["单一来源采购", "交付已逾期18天"]},
{"projectId": "PRJ-2026-003", "riskScore": 86, "facts": ["合同变更金额占原合同17%", "存在1次有效投诉"]},
{"projectId": "PRJ-2026-010", "riskScore": 78, "facts": ["预付款比例70%", "供应商审计材料已过期"]},
{"projectId": "PRJ-2026-012", "riskScore": 72, "facts": ["中选报价比有效报价中位数低23%"]}
]
}
输出只能包含 summary、riskLevel、indicators、followUps 四个顶层字段，而且顺序固定。summary 不超过 100 个汉字；整体风险必须按输入规则判为“高”；五项指标的名称、数字和单位必须逐字段一致；跟进项目必须是风险分最高的三个项目，顺序固定为 PRJ-2026-007、PRJ-2026-003、PRJ-2026-010。
完整数据：
模型最常见的毛病并不是不会分析，而是太喜欢“补充完整”。明明没有同比数据，也要顺手加一句“暂无法判断同比变化”。人看起来没问题，程序看到禁止词就直接拒绝。为了避免测试过程中悄悄改 Prompt 或数据，这一版还给数据集和 Prompt 做了哈希。只要任意一个字符发生变化，就不能再把结果混入当前批次。
3.2 四款模型怎么跑
四款模型均采用流式接口，temperature=0.6、top_p=0.95、max_tokens=4096，并发固定为 1，传输层自动重试为 0。四款模型分别走自己的官方或当前公开服务：
| 模型
| | --- | |
openPangu-2.0-Flash
| |
Ling-2.6-Flash
| |
Qwen3.6-35B-A3B
| |
Qwen3.5-27B
|
主批次还采用了轮转顺序。每跑一轮，就把四款模型的请求位置向前移动一次，避免某个模型一直排在第一或者最后。
这里中途出了一个值得单独说的问题。openPangu 在主批次里连续 20 次都没有拿到模型响应。刚看到这个结果时，如果直接按表格统计，它的成功率会是 0%。但继续查日志以后发现，问题发生在模型之前：本机继承的 HTTPS 代理在收到 HTTP 响应前就重置了 GitCode 的 TLS 连接。换成同一密钥、同一个 Prompt 直连以后，接口正常返回 HTTP 200，并完整收到 [DONE]。
所以这 20 次我保留在实验记录里，但把它们归类为基础设施异常，没有算成 openPangu 的模型失败。随后重新预热 2 次，再独立补跑 20 个正式样本。这个补测解决了“把网络故障当模型失败”的问题，但也带来一项限制：openPangu 不再与另外三款模型处于同一轮转批次。所以它的正确率仍可按相同 Prompt 和计分器比较，延迟则只能解释为当前 API 路径的端到端体验，不能解释成纯模型吞吐量。
这也带来一个限制：正确率可以比，延迟不能当成同机模型速度比。
openPangu 最终走的是单独直连补测批次，另外三款来自主轮转批次，服务商、部署硬件和网络路径都不同。所以后面所有速度数据，我只把它理解成“这次调用 API 实际要等多久”。不是模型裸吞吐 benchmark。
图 7：正式协议、数据集哈希、并发/重试配置和供应商路由的后端审计。密钥值未写入日志。
3.3 自动判定和修复方法
首轮回答按五层顺序判断：传输是否完成、是否为纯 JSON、Schema 是否满足、业务语义是否正确、全部严格契约是否同时通过。核心逻辑可以简化为：
parsed = json.loads(content)
schema_success = all([
list(parsed) == ["summary", "riskLevel", "indicators", "followUps"],
len(parsed["summary"]) <= 100,
keys_and_types_are_valid(parsed),
])
semantic_success = all([
parsed["riskLevel"] == "高",
parsed["indicators"] == expected_indicators,
[x["projectId"] for x in parsed["followUps"]] == expected_follow_up_ids,
reasons_only_use_input_facts(parsed["followUps"]),
contains_no_forbidden_claim(parsed),
])
strict_contract_success = schema_success and semantic_success
修复测试不是人工临场提示。运行器把失败检查项填入固定模板，要求模型只修复失败项并重新返回完整 JSON。例如 indicators 失败时，反馈中会附上五项指标的精确目标数组。每个失败样本最多追加 3 轮；首轮通过记 0 轮，一轮反馈后通过记 1 轮，三轮后仍失败记为 unresolved。
延迟也拆成三个指标：
TTFT：收到第一个流式 Token 的时间，包括 reasoning_content；
首个可见正文：收到第一个 content 字符的时间；
总时长：从发出请求到完整读完流的时间。
如果只报 TTFT，先输出隐藏推理、很晚才输出正文的模型会显得异常快。成功率给出 Wilson 95% 区间；median 使用标准中位数，P90/P95 使用 nearest-rank。Agent 任务成功率在本组不适用，必须等到独立 Agent 数据集完成后另行报告。
3.4 首轮成功率和严格契约结果
| 模型
|
传输成功
|
JSON 解析
|
Schema
|
语义正确
|
严格契约/首轮成功
|
Wilson 95%
| | --- | --- | --- | --- | --- | --- | --- | |
openPangu-2.0-Flash
|
100%（20/20）
|
100%（20/20）
|
100%（20/20）
|
100%（20/20）
|
100%（20/20）
|
83.9%–100.0%
| |
Qwen3.5-27B
|
95%（19/20）
|
95%（19/20）
|
95%（19/20）
|
95%（19/20）
|
95%（19/20）
|
76.4%–99.1%
| |
Qwen3.6-35B-A3B
|
100%（20/20）
|
100%（20/20）
|
95%（19/20）
|
90%（18/20）
|
85%（17/20）
|
64.0%–94.8%
| |
Ling-2.6-Flash
|
100%（20/20）
|
100%（20/20）
|
100%（20/20）
|
20%（4/20）
|
20%（4/20）
|
8.1%–41.6%
|
图 8：从 80 条正式请求和 21 条修复记录重新计算的后端汇总。
openPangu 在这 20 个正式样本中全部首轮通过。Qwen3.5 的 19 个有效响应也全部通过，表中的 95% 来自 1 次传输失败，而不是内容答错。Qwen3.6 有 3 次内容契约失败。Ling 的 20 次回答全部可以解析，顶层 Schema 也全部正确，但只有 4 次逐字段满足业务契约。
这里不再把 100%、95% 和 85%换算成 10.0、9.3、9.6 之类的主观分数。以每款 20 次的样本量看，openPangu、Qwen3.5 和 Qwen3.6 的 Wilson 区间仍有明显重叠，不能声称它们之间已经形成统计显著的总体能力排序。本文能确认的是这批固定任务中的观测结果，以及每个失败具体发生在哪里。
3.5 失败样本和修复轮数
| 模型
|
首轮通过
|
最多 3 轮修复后成功
|
已解决样本修复轮数 median / P90 / P95
|
仍未解决
| | --- | --- | --- | --- | --- | |
openPangu-2.0-Flash
|
20/20
|
20/20
|
0 / 0 / 0
|
0
| |
Ling-2.6-Flash
|
4/20
|
20/20
|
1 / 1 / 1
|
0
| |
Qwen3.6-35B-A3B
|
17/20
|
19/20
|
0 / 1 / 1
|
1
| |
Qwen3.5-27B
|
19/20
|
19/20
|
0 / 0 / 0
|
1 个传输异常
|
Ling 的失败非常集中：16 次把数量单位从契约要求的“个”改成了更自然的“项”。典型输出是：
{
"indicators": [
{"name": "项目数量", "value": 12, "unit": "项"},
{"name": "预算金额", "value": 9340, "unit": "万元"},
{"name": "成交金额", "value": 8593, "unit": "万元"},
{"name": "风险项目数", "value": 4, "unit": "项"},
{"name": "待验收项目数", "value": 2, "unit": "项"}
]
}
这不是 JSON 或常识错误，而是严格接口契约错误。16 个失败样本在看到精确校验反馈后都只用 1 轮修复，说明 Ling 能修，但如果生产链路没有校验和反馈，首轮直接接入的成功率仍只有 20%。
Qwen3.6 的 3 次首轮失败更分散：1 次 summary 超过 100 个汉字，2 次主动写出“当前无历史同期数据，无法进行同比或环比分析”。后一句事实本身没错，但 Prompt 明确禁止输出这些词，下游禁止项扫描会直接拒绝。其中摘要超长样本和 1 个禁止项样本在第 1 轮修复成功；另一个禁止项样本连续 3 轮仍重复相关表述，最终任务成功率停在 19/20。
Qwen3.5 唯一失败发生在 TLS 连接阶段，没有模型内容可修，所以保持 unresolved。把它记入总体首轮任务成功率可以反映真实 API 可用性；同时单列“19 个有效响应全部通过”，可以避免把基础设施稳定性和模型内容能力混为一谈。
图 9：Ling 单位错误、Qwen3.6 禁止项失败及 Qwen3.5 传输异常的真实后端审计。
3.6 TTFT、可见正文与总时长
以下只统计成功获得完整响应的正式首轮请求。openPangu、Ling 和 Qwen3.6 的 n=20，Qwen3.5 因 1 次传输失败为 n=19。
| 模型
|
TTFT median / P90 / P95
|
首个可见正文 median / P90 / P95
|
总时长 median / P90 / P95
| | --- | --- | --- | --- | |
openPangu-2.0-Flash
|
1.86 / 1.97 / 2.02 秒
|
22.48 / 27.14 / 30.15 秒
|
25.02 / 29.91 / 33.07 秒
| |
Ling-2.6-Flash
|
1.90 / 2.47 / 3.47 秒
|
1.90 / 2.47 / 3.47 秒
|
3.91 / 4.49 / 5.52 秒
| |
Qwen3.6-35B-A3B
|
1.76 / 2.01 / 2.13 秒
|
1.76 / 2.01 / 2.13 秒
|
3.64 / 4.01 / 4.05 秒
| |
Qwen3.5-27B
|
2.30 / 4.12 / 5.86 秒
|
2.30 / 4.12 / 5.86 秒
|
5.67 / 7.93 / 8.28 秒
|
图 10：TTFT、首个可见正文、总时长和 Token 覆盖的后端汇总。
只看 TTFT，openPangu 的中位数 1.86 秒，与 Ling、Qwen3.6 接近。但它的首个可见正文要等到中位 22.48 秒，总时长中位 25.02 秒。原因也能从原始流里复核：请求已经传入 think=false，服务仍返回 reasoning_content，正式样本的隐藏推理字符中位数为 3266.5。另三款模型在本轮快速模式下都没有独立推理字符。
所以真实用户体验不是“openPangu 1.86 秒开始回答”，而是“约 1.86 秒开始产生隐藏推理，约 22.48 秒才出现可见 JSON”。Qwen3.6 的总时长中位数和 P95 分别为 3.64 秒、4.05 秒，是本批次观测到的最低值；Ling 分别为 3.91 秒、5.52 秒；Qwen3.5 为 5.67 秒、8.28 秒。
这些数字包含 provider 的排队、网络、服务端实现和部署硬件，不能当作同机纯推理速度。特别是 openPangu 来自直连补测批次，延迟排名只能描述本次接口体验。
3.7 输入/输出 Token 与记录覆盖
| 模型
|
Usage 覆盖
|
输入 Token 中位数
|
输出 Token 中位数
|
总 Token 中位数
|
输出 Token 总数
| | --- | --- | --- | --- | --- | --- | |
openPangu-2.0-Flash
|
20/20
|
822
|
2006
|
2828
|
40112
| |
Ling-2.6-Flash
|
20/20
|
904
|
387
|
1291
|
7596
| |
Qwen3.6-35B-A3B
|
20/20
|
910
|
382.5
|
1292.5
|
7699
| |
Qwen3.5-27B
|
19/20
|
910
|
240
|
1150
|
5632
|
四家 tokenizer 和 usage 口径可能不同，所以输入 Token 不能直接解释为 Prompt 长短发生了变化。它们的 Prompt 文本和哈希相同。这里记录 Token 的主要目的，是让读者估算接口成本、核对输出规模，并解释为什么 openPangu 的总时长明显更长：它的 completion usage 包含了大量推理过程。
每个正式请求的 provider、region 说明、endpoint、streaming、并发、retry、请求参数、实际 model ID、TTFT、首个可见正文、总时长、Token、失败项和原始文件位置：
原始 SSE 事件没有塞进 CSV，而是完整保留在每个请求的 JSON 文件中。这样既能快速筛选表格，也可以回到毫秒级流事件复核 TTFT 和内容拼接。
3.9 本组结论
这组结构化任务里，openPangu 的观测优势非常明确：20/20 首轮严格通过，未使用修复轮次。它对字段、单位、排序和禁止项的遵循最稳定。但代价同样明确：首个可见正文中位 22.48 秒，总时长中位 25.02 秒，明显慢于另外三款接口。
Qwen3.5 更接近“快而稳”的选择。它的 19 个有效响应全部严格通过，中位总时长 5.67 秒；总体 19/20 的唯一缺口来自传输异常。Qwen3.6 的中位总时长最低，为 3.64 秒，首轮严格通过 17/20，加入最多 3 轮修复后达到 19/20。Ling 的接口也很快，所有回答都能解析，但首轮严格契约只有 4/20；好消息是 16 个单位错误全部一轮修复成功。
因此，本组不能简单写成“某模型 10 分、某模型 9.6 分”。更准确的选择是：要求首轮零清洗时，openPangu 在本样本中最稳；同时重视低延迟时，两款 Qwen 更均衡；Ling 若接入严格校验和自动修复，也能把最终成功率提升到 100%，但不能忽略它 20% 的首轮契约通过率。
这些结论只适用于当前固定数据集和当前 API 服务。92B 总参数是否能在 Coding、Debug 和 Agent 中换来更明显收益，还要由后续独立任务验证。尤其是 Agent 任务，必须报告完整目标成功率、工具轨迹和修复轮数，不能从这组 JSON 结果外推。
结尾
这轮重新跑完以后，我对 openPangu-2.0-Flash 的判断反而简单了不少。
它没有在所有地方都赢，但在这一组严格结构化任务里，优势很明确。20 次正式请求全部首轮通过，没有字段漂移，没有多写一句不该出现的话，也没有进入修复流程。对于需要直接把模型输出交给下游程序的工作流，这种“按要求来”比回答得更漂亮更重要。
这也和前面参考测评里看到的 Tool Call 表现基本能对上。换成真实采购数据、固定 Schema 和禁止项以后，openPangu 的这项能力没有掉下来。至少在我这次测试的场景里，它更像是一款适合接进流程的模型，而不是需要开发者不断替它收拾输出格式的模型。
代价也摆在那里。当前 GitCode API 下，openPangu 的首个可见正文中位要等 22.48 秒，总时长中位 25.02 秒；两款 Qwen 则明显更快。 如果业务是后台批处理，我可能更愿意换稳定性；如果是用户盯着页面等结果的实时 ChatBI，这二十多秒就很难忽略。
所以这篇文章最后，我不太想再给 openPangu 一个“值得推荐”或者“不值得推荐”的简单标签。
更准确的说法是：它已经在严格指令和结构化输出上跑出了很扎实的结果，但还没有证据说明 92B 的总参数能够在所有实际任务里稳定换来更高的应用收益。这也是为什么我越来越不愿意只看模型参数和排行榜。
真正把模型接进项目以后，开发者面对的是另外一组问题：第一次能不能做对，失败以后要修几轮，Schema 会不会乱改，以及用户到底要等多久。openPangu-2.0-Flash 这次给出的答案很有特点：
慢一些，但很稳。
