Qwen3 235B A22B实测：2.4万亿参数开源模型超越Claude Opus

国产万亿模型密集出击

近期国产大模型的迭代速度令人应接不暇。就在Kimi K3发布后不久，阿里巴巴通义千问团队又抛出了重磅炸弹——Qwen3最强版本（参数规模高达2.4万亿，即2.4T）。更关键的是，官方已经确认将采用**开放权重（open weight）**形式发布。

这里有必要厘清一个常被混淆的概念：开放权重与通常意义上的完全开源存在微妙但关键的差异。开放权重意味着模型的参数文件可供公开下载和本地部署，用户可以进行推理甚至微调，但训练代码、完整数据集和训练流程不一定公开。Meta的LLaMA系列是这一模式的代表性案例：其权重文件公开下载，但使用须遵守专属商业许可协议，且训练数据构成、RLHF对齐流程等关键环节均不透明。真正意义上的开源（如OSI定义）要求代码、数据、训练流程全部透明可复现，任何人都能查看、修改、再分发，不附加限制性条款。

值得一提的是，OSI（开源倡议组织）在2024年正式发布了《开源AI定义v1.0》，明确要求真正的开源AI必须包含足以重现训练的数据信息、完整的训练代码和参数权重，三者缺一不可——这一定义直接将LLaMA系列、Mistral等主流"开源"模型排除在外，也使得"开放权重"这一更精确的术语在业界逐渐成为共识。

这一区别的深层影响远不止于法律文本。从监管视角看，欧盟AI法案（EU AI Act）对开放权重模型的监管力度低于闭源模型，但这也引发了争议：缺乏训练数据透明度的开放权重模型是否真的比闭源模型更安全？开源倡导者认为，权重公开至少允许安全研究者对模型进行红队测试和对抗攻击分析；批评者则指出，开放权重模型一旦发布便无法撤回，若存在对齐缺陷，修复成本远高于闭源模型的服务端热更新。从安全审计角度看，开放权重模型允许研究者对参数进行逆向分析，发现潜在偏见或对抗漏洞，但缺乏训练数据透明度意味着无法从根源上理解模型行为的来源。Meta的LLaMA系列、Mistral均属于开放权重模式而非严格开源。这一区别在商业使用授权、安全审计可行性和学术可复现性等方面均有实质影响——但对大多数开发者而言，开放权重已足够实用：数据不离境、可定制系统提示、延迟更可控，能本地部署、能微调、能集成到私有系统，这是闭源API模式无法提供的核心价值，也是为何"开放权重"在商业生态中的接受度远高于学术界对其局限性的批评。

值得关注的是，2.4T这一参数规模背后，极可能采用了混合专家架构（Mixture of Experts，MoE）。这一架构思想源于1991年学术界的早期探索，但现代MoE的复兴可追溯到2017年Google Brain团队发表的《Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer》，该论文首次将稀疏MoE层集成进大型序列模型，实现了训练效率的数量级提升。让MoE真正进入公众视野的，是2024年初Mistral AI发布的Mixtral 8x7B——首个主流开放权重MoE模型，以总参数46.7B、激活参数12.9B的组合在当时制造了震动。

MoE架构从学术概念到工程实践经历了三十年的沉淀。2022年Google发布的Switch Transformer首次将MoE扩展至万亿参数规模，验证了架构可行性；2023年的GLaM和ST-MoE则解决了早期MoE训练不稳定的核心痛点——通过辅助损失函数约束路由器的负载均衡，防止少数专家被过度激活而多数专家退化为死亡神经元的问题。这一系列工程突破，才使得2.4T这一规模在今天成为可交付的产品而非纸面数字。

其核心结构是：在Transformer的前馈网络层，用N个并行的"专家网络"替换单一的FFN，并配备一个可学习的门控路由器（Router），每个Token在推理时只激活其中K个专家（通常K=2或K=8）。与传统稠密模型不同，MoE在推理时并不激活全部参数，通过"路由器"动态选择少数几个"专家子网络"处理每个Token。MoE的核心权衡在于：训练时需要比同等激活参数的稠密模型消耗更多GPU内存（因为所有专家权重都需要加载），但推理时的FLOPs消耗可以大幅降低。以Qwen3 2.4T为例，若其稠密激活参数约为200B量级（类比DeepSeek-V3的671T总参/37B激活的比例），则实际推理时的算力消耗与一个中等规模稠密模型相当，但模型的知识容量和表达能力却接近全量参数规模。MoE的工程挑战集中在两点：路由器负载均衡（防止所有Token都流向同一个专家），以及分布式推理中的跨设备通信开销——这也是MoE在推理服务工程化时最大的挑战所在。GPT-4、Mixtral、DeepSeek-V3均采用了类似路线，正是这种架构让超大规模模型在工程上具备可行性。

虽然完整模型权重、详细规格及官方Benchmark尚未正式放出，但"开源"这一点已获官方明确承诺。在闭源大模型霸榜的当下，一个万亿级别的开源模型意味着什么，大家都看得到。

更值得关注的是官方发布公告中的大胆宣言：该模型是"当今最强大的模型之一，仅次于Fable 5"。这样的表述在业界并不多见，而一位YouTube测评博主决定用自己的基准测试，来验证这句话是否名副其实。

预览版已可直接使用

对于想尝鲜的用户来说，好消息是无需等待权重放出。预览版已经上线，可通过官方Token套餐以及Coder等工具直接调用。也就是说，如果你已经订阅了Token套餐，现在就能免费体验这个前沿级别的模型。

测评博主正是这样操作的——他将模型接入Claude Code，并用自建的"KingBench"基准测试进行全面评估。KingBench区别于学术界主流基准（如MMLU、HumanEval、GSM8K）的核心在于其"可观察性"设计理念。主流基准的共同特点是评分可以完全自动化，结果是二值的——这带来了"Goodhart定律"效应：当评分指标成为优化目标，模型会学会在这些特定格式上得高分，而不一定真正提升了能力。这一问题在AI评测领域尤为突出：当HumanEval发布时，它代表了代码能力评测的前沿；但随着各大模型在该基准上的训练数据污染加剧，HumanEval的区分度已大幅下降——部分模型的HumanEval得分超过95%，但实际代码生成能力却相差悬殊。

这一现象被研究者称为「基准污染」（Benchmark Contamination），其本质是训练集与测试集的边界被侵蚀。MMLU基准发布时代表了知识推理评测的前沿，但随着各大模型将其纳入训练目标，部分模型已能在MMLU上超过90%，却在实际任务中表现平庸。正是在这一背景下，KingBench、LiveCodeBench等以「防污染」为核心设计原则的新型评测框架开始受到关注。

KingBench的应对策略是将评估结果转化为人类可直观判断的视觉产物——一个3D眼镜盒能否点击打开、一只熊猫是否看起来"正在吃东西"、一个弓箭游戏是否有手感——这些判断人类几秒内就能完成，但无法被模型"刷分"，因为输出本身就是最终裁判。每道题的输出都是可视化的交互产物，而非填写答案或代码通过率统计，前端渲染正确与否、动画流畅度、游戏可玩性，都依赖人工主观判断而非自动化评分，更接近真实用户需求，也是区分顶级模型与次顶级模型的有效判别器。这种评测哲学与斯坦福HELM、Scale AI的SEAL，以及使用竞赛平台实时新题规避数据污染的LiveCodeBench等评测框架的方向一致：减少对固定格式答案的依赖，增加对开放式产出质量的评估权重。这套测试涵盖前端与动画任务、Three.js 3D任务、SVG绘图、数学难题、长周期自主智能体任务，以及一个极难的3D建模题，每题满分10分，总分80分。

八项硬核测试逐一拆解

前端与3D交互能力

第一题是电梯模拟器：需要构建一个可在不同楼层生成乘客的模拟系统，三部电梯各只能载一人，未搭上的乘客需等待下一趟，并悬停时显示每个人的目标楼层提示。最终拿下8分，电梯逻辑正确、动画流畅，虽不及Opus 4.8的满分表现，但已与GPT 5.6、GLM 5.2持平。

第二题的Three.js隐形眼镜盒是几乎所有模型都会翻车的难题——要求带有醒目L/R标识的盒盖，并能点击打开。Three.js是基于WebGL的JavaScript 3D图形库，其挑战在于多层抽象的同步：模型需要同时理解欧拉角与四元数的旋转表达、物体层级关系（父子节点变换的传递）、相机视锥与光照模型的交互，以及浏览器事件循环与渲染帧的时序关系。

Three.js之所以能成为测评顶级模型的利器，在于它处于多个知识领域的交叉点：数学层面涉及线性代数（矩阵变换、坐标系转换）、四元数旋转（避免万向锁问题）和光线投射（用于鼠标点击检测）；软件工程层面要求理解场景图（Scene Graph）的父子变换传递机制；WebGL渲染管线层面则涉及顶点着色器和片段着色器的工作原理。特别值得一提的是「万向锁」（Gimbal Lock）问题——当使用欧拉角描述三维旋转时，特定角度组合会导致两个旋转轴重合，丢失一个自由度，产生动画抖动；四元数的核心价值正在于从数学层面彻底规避这一问题，而正确选择旋转表达方式是Three.js代码是否能流畅运行的关键判断点之一。当一个模型能在没有视觉反馈的情况下，纯粹通过代码推演出在浏览器中正确渲染的3D交互场景，这证明它具备了跨越多个抽象层次的系统性理解能力，而非碎片化的API记忆。任何一个维度的理解偏差都会导致3D场景的视觉崩溃，且错误往往不是报错而是"渲染出奇怪的东西"，难以通过测试用例捕获——这正是为何该题历史上绝大多数模型都会翻车。该模型同样拿下8分，成为这道题历史上第二强的模型（仅次于满分的Fable 5，甚至超过了只拿7分的Opus 4.8）。第三题的折叠桌滑块动画也获得8分，与Opus 4.8打平。

绘图与游戏物理

第四题要求用SVG绘制一只吃汉堡的熊猫。SVG（可缩放矢量图形）的挑战与Three.js截然不同——它要求模型在脑海中建立一个精确的二维坐标系，用path指令的贝塞尔曲线描述有机形状（如熊猫的耳朵弧度），并确保多个形状的层叠顺序和比例关系在纯代码层面自洽。这是一种"无像素缓冲区"的绘图挑战：完全依赖代码描述几何形状与空间关系，没有像素级容错空间，对模型的空间想象力和坐标推算能力要求极高，是区分"能生成可运行代码"与"真正理解空间与图形"的有效判别器。SVG的path指令体系（M/L/C/Q等命令组合）本质上是一种描述几何的领域特定语言，模型不仅需要记住语法，更需要在无画布反馈的情况下在心理空间中"预先渲染"出最终图形——这种能力与纯文本推理有本质差异，是大模型空间理解能力的真实映射。结果比例协调、汉堡辨识度高，且真实呈现出"正在吃"的姿态，获得8分，与Kimi K3、Grok 4.5、GLM 5.2并列最高分。

第五题的弓箭射击游戏要求实现瞄准射击、命中排行榜等功能。该模型交出满分10分，游戏可玩、物理手感良好、排行榜正常更新，这一成绩此前只有Opus 4.8和Grok 4.5达到过。

推理与长周期智能体任务

第六题是关于有序对排列计数的数学难题，正确答案为2460——很多模型都会彻底失败。该模型精确算出2460，满分入账，跻身Opus 4.8、Fable 5、Kimi K3、GPT 5.6等强推理模型的行列，证明它不只是个"前端花瓶"。

第七题是最考验综合能力的长周期自主任务：从零生成游戏事实数据集，微调一个Gemma 2B模型，再搭建一个每次刷新都能生成熊猫冷知识的本地Web界面。这代表了当前AI Agent领域最具挑战性的任务类型——多步骤工具调用链（Tool Calling Chain）。与单次代码生成任务有本质区别：模型需要维护一个跨多个步骤的"工作记忆"，依次完成数据生成、环境配置、模型微调、服务部署等跨领域操作。

ReAct（Reasoning + Acting）框架是这类任务的主流范式，由普林斯顿大学和Google在2022年论文中正式提出，核心思想是让语言模型以交替输出"思考步骤"和"行动指令"的方式完成工具增强任务，使决策过程可追踪、可调试。在工程实践中，ReAct框架的瓶颈往往不在于单步推理能力，而在于错误恢复能力——当某一工具调用返回意外错误时，模型是否能正确解读错误信息并调整后续计划，而非陷入重复尝试同一失败操作的循环（即"幻觉死循环"）。这要求模型具备三种能力的协同：状态追踪（记住微调脚本已成功生成但尚未执行）、错误恢复（当pip安装依赖失败时能重新规划路径）、以及工具接口适配（理解不同工具的输入格式约定）。OpenAI、Anthropic和Google DeepMind均将「可靠的多步骤任务完成能力」列为2024-2025年的核心研究目标；TAU-Bench、SWE-bench等专门面向真实软件工程任务的评测基准显示，即便是最强模型，在需要数十步操作的复杂任务上完成率也鲜少超过50%——这正是第七题满分的含金量所在。该模型完全自主完成整个流程，再获满分——这在实际工程中等价于一个初级工程师独立完成了一个完整的ML项目迭代周期，也是连续第三个满分。

第八题3D手表是全场最难的题目，要求秒/分/时针平滑运转、支持日期星期与双时区显示。最终仅得3分，手表能渲染、指针会动，但未达到完整可用的要求。不过参考背景是——该题最高分也只是Fable 5的4分，不少模型直接0分，所以3分反而算是不错的尝试。

排名第二，营销罕见地兑现

最终，该模型以65/80分（81.25%）收官，在博主的整个排行榜上位列第二名。它仅落后于Fable 5的82.5%，却明确超越了Claude Opus 4.8的80%，同时大幅领先Kimi K3（77.5%）、GLM 5.2（75%）和GPT 5.6（71.25%）。

换句话说，官方"仅次于Fable 5"的宣言，在这套独立基准测试中竟然分毫不差地兑现了。对于习惯了厂商过度宣传的用户来说，"营销与现实一致"本身就是一件稀罕事。

使用体验：并非全无短板

不过图表并不能说明全部。博主在实际接入Claude Code使用时发现，该模型响应快、指令遵循度高、产出质量确实达到顶级闭源模型的水准，但在长会话的持续任务上表现稍弱——有时该创建的文件没有创建，在工具链衔接层面偶尔"掉链子"。

这一现象与当前所有顶级模型在Agentic场景下的两个结构性瓶颈密切相关。第一是上下文窗口的"注意力衰减"问题，又称**「Lost in the Middle」现象**——由斯坦福大学2023年同名研究论文正式命名。研究发现，Transformer模型在处理长上下文时，对位于上下文中间位置的信息存在系统性的注意力折扣：模型更容易记住开头和结尾的内容，而忽略中间部分。这一特性的底层机制与位置编码方案有关——RoPE（旋转位置编码）和ALiBi等现代方案虽然改善了超长上下文的外推能力，但注意力的U型分布特性（首尾强、中间弱）仍然存在，这源于注意力机制本身的softmax归一化特性而非特定位置编码的缺陷，意味着这一局限无法通过简单的工程补丁彻底消除。这一特性在Agent场景中会产生严重的工程后果：在一个包含50轮工具调用的长任务中，第20轮生成的临时文件路径很可能在第45轮时已从模型的有效注意力范围中"淡出"。当前业界的主流应对策略包括：在系统提示中强制模型维护结构化的"工作状态摘要"、引入外部键值存储作为显式记忆模块、以及使用滑动窗口压缩技术对早期上下文进行摘要化处理。

第二是工具调用协议的适配问题：不同框架（Claude Code、LangChain、AutoGen等）对工具调用的JSON格式、错误返回码的语义约定存在细微差异，模型如果在预训练和微调阶段主要见过某一框架的调用日志，在其他框架下就可能生成格式偏差的调用指令。这两个问题性质不同：前者需要改进模型的长程注意力机制或引入外部记忆模块；后者可以通过针对特定框架的少量指令微调（SFT）快速修复。这也解释了为何同一模型在不同Agent框架下表现差异显著——需要更长时间的实际使用才能区分两者。

博主特别强调这只是初步观察，他计划将其作为日常主力模型继续使用一段时间，再在后续视频中给出更完整的结论。

结语：开源阵营的一次里程碑

综合来看，Qwen3这一超大规模版本是极具竞争力的模型：排名第二、力压Claude Opus 4.8，并在游戏开发、数学推理、智能体三项任务上拿到满分。而它最大的价值在于可及性——预览版已包含在Token套餐中，用户能以远低于闭源实验室的成本体验前沿级模型。

再加上即将开放的模型权重，这对整个开源生态无疑是一记重磅。一个2.4万亿参数、采用MoE架构、达到这种性能水准的模型选择开放权重，意味着研究者可以在本地研究其行为，企业可以在私有环境中部署而无需将数据发送至第三方API，开发者社区可以在此基础上构建专用微调版本——并不是每天都能见到的事。从Kimi K3到Qwen3，短期内连续两个万亿级模型的诞生，再次印证了国产大模型正在加速崛起。

核心要点

核心要点

核心要点

核心要点