引言最近看新模型我已经很少先看参数量了。原因很简单参数再大、榜单再漂亮最后还是要落到具体任务上。写代码能不能直接跑工具调用会不会出错做一个完整项目时要返工几次这些东西往往比单项 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 时路由器会根据当前输入选择其中一部分专家参与计算而不是每一次都把整个模型全部算一遍。大致是这样1openPangu-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 Avg1693.3、LiveCodeBench V6 Avg385.1、SWE-bench Verified Avg363.1、TAU2-Bench Avg388.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 模型。暂定的四款模型如下4openPangu-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 四款模型怎么跑四款模型均采用流式接口temperature0.6、top_p0.95、max_tokens4096并发固定为 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 个有效响应全部通过”可以避免把基础设施稳定性和模型内容能力混为一谈。图 9Ling 单位错误、Qwen3.6 禁止项失败及 Qwen3.5 传输异常的真实后端审计。3.6 TTFT、可见正文与总时长以下只统计成功获得完整响应的正式首轮请求。openPangu、Ling 和 Qwen3.6 的 n20Qwen3.5 因 1 次传输失败为 n19。| 模型|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 秒|图 10TTFT、首个可见正文、总时长和 Token 覆盖的后端汇总。只看 TTFTopenPangu 的中位数 1.86 秒与 Ling、Qwen3.6 接近。但它的首个可见正文要等到中位 22.48 秒总时长中位 25.02 秒。原因也能从原始流里复核请求已经传入 thinkfalse服务仍返回 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 这次给出的答案很有特点慢一些但很稳。