腾讯HY3开源模型深度实测：轻量MoE硬刚旗舰级性能

腾讯HY3：轻量级MoE的野心

腾讯正式发布了开源权重大模型 HY3，这是此前预览版之后的完整推理模型。从架构来看，HY3 总参数量达 2950 亿，采用 MoE（混合专家）设计，每次推理仅激活 210 亿参数，内部包含 192 个专家，使用 Top-8 路由机制。

关于MoE架构：MoE（Mixture of Experts，混合专家）是一种将神经网络划分为多个「专家子网络」的架构范式，核心思想源自1991年 Jacobs 等人的早期研究，近年来被 Google（Switch Transformer、Gemini）、Meta（LLaMA MoE 变体）、Mistral（Mixtral 8x7B）等机构大规模应用于大语言模型。其关键优势在于「稀疏激活」：模型总参数量可以非常大，但每次推理时只有一小部分参数被实际计算，从而大幅降低推理延迟和算力成本。具体到路由机制，每个输入 Token 会经过一个轻量级的「门控网络（Gating Network）」，由该网络决定将该 Token 分配给哪几个专家处理，最终对各专家输出进行加权求和。HY3 采用 Top-8 路由意味着每个 Token 会同时经过8个专家的加权处理，激活比例仅约7%（210亿/2950亿）。

这种设计的代价是训练复杂度更高——需要解决「专家负载不均衡」问题（少数专家被过度激活而其余闲置），通常通过辅助损失函数（Auxiliary Loss）强制均衡分配来缓解。当路由网络倾向于反复选择同几个「强专家」时，会导致其他专家因缺乏训练信号而逐渐退化为「僵尸专家」，这一现象被称为专家坍塌（Expert Collapse）。Google在Switch Transformer中首次系统性地引入容量因子（Capacity Factor）和辅助损失函数来缓解此问题，后续研究者又提出Expert Choice路由（由专家主动选择Token而非Token选择专家）等替代方案。HY3采用192个专家的Top-8路由，意味着每个专家被激活的概率约为4.2%，如何在如此稀疏的激活率下保持训练稳定性，是腾讯在工程层面需要解决的核心挑战。整体而言，体现了极致的计算效率取舍：以较低的激活成本，逼近旗舰级模型的实际表现。

HY3 主要面向推理、智能体工作流、代码生成及真实生产环境部署。一个值得关注的特性是「推理强度可调」——默认以快速的无思考模式运行，遇到代码、数学或多步任务时可按需切换低推理或高推理模式，兼顾速度与深度。

推理强度可调的技术背景：这一机制本质上是控制模型在生成最终答案前进行「内部思维链（Chain-of-Thought）」的计算量，与 OpenAI o系列、DeepSeek R1 的设计思路一脉相承。从实现原理看，模型通常通过特殊控制 Token（如 <think> 标签）或系统提示来触发不同推理深度：无思考模式直接输出答案，高推理模式则允许模型进行数百乃至数千 Token 的自我审查与反复验证——这一过程通常发生在一个「内部草稿区」，最终答案只取推理链末尾的结论部分。

这种动态调度能力背后，是以过程奖励模型（Process Reward Model, PRM）为核心的强化学习训练范式。与传统RLHF对最终答案打分不同，PRM对推理过程的每个中间步骤进行评分，使模型学会何时需要「多想一步」。DeepSeek R1通过Group Relative Policy Optimization（GRPO）算法证明了这一路径的有效性，HY3的动态切换能力表明其训练时已对不同复杂度任务进行了分层标注，使模型具备元认知能力——即判断当前任务是否值得深度推理的自我评估能力。这对智能体工作流（Agentic Workflow）尤为关键——一个自动化 Pipeline 中可能同时包含需要深度推理的数学子任务和只需快速响应的格式转换步骤，若强制使用统一推理强度，不仅会造成算力浪费，还可能因过度「思考」简单任务而引入冗余错误。

更关键的是，HY3 基于 Apache 2.0 license 发布，对商业使用极为友好。Apache 2.0 是开源界最宽松的许可证之一：企业可以不修改或修改后商业部署模型权重，无需公开源码，也无需支付版税——这与一些「伪开源」模型的社区许可证（例如 Meta 早期 LLaMA 协议中对月活用户超7亿企业的商业限制）形成鲜明对比。Apache 2.0 还明确授予专利使用权，避免了贡献者事后对下游用户发起专利诉讼的法律风险，这对企业法务部门极为重要。腾讯选择 Apache 2.0，实质上是一种市场策略，意在吸引企业用户将 HY3 部署在私有化环境中，扩大生态影响力。

腾讯官方宣称，尽管体量远小于万亿参数旗舰模型，HY3 已能与之正面竞争。当然也有短板——上下文窗口仅 256K，在超长文档场景下略显不足（相比之下，Gemini 2.5 Pro 支持 100 万 Token 上下文）。官方同时强调，得益于更优质的后训练数据和更多强化学习投入，HY3 在抗幻觉能力和工具调用稳定性上均有提升。

代码与智能体基准：与DeepSeek同台竞技

在开发者最关心的编码能力上，HY3 的基准成绩相当亮眼。SWE-Bench Multilingual 上，HY3 拿到 75.8 分，仅微落后于 DeepSeek V4 Pro 的 76.24 分；更难的 SWE-Bench Pro 上，HY3 以 57.9 分反超了 DeepSeek V4 Pro 的 55.4 分。

关于SWE-Bench评测体系：SWE-Bench 是由普林斯顿大学于2023年提出的代码能力基准，专门用于评估模型解决真实 GitHub Issue 的能力——从热门开源 Python 仓库（如 Django、Flask、Scikit-learn）中提取历史 Bug 修复任务，要求模型直接生成能通过单元测试的代码补丁，极大提升了评测的工程实用性。与 HumanEval、LeetCode 类题目相比，SWE-Bench 的核心难点在于「上下文感知」：模型必须理解数万行代码构成的真实项目结构，定位问题根源，并生成与既有代码风格、接口约定高度兼容的补丁，而非在空白画布上从零编写算法。

SWE-Bench Multilingual 是其多语言扩展版，覆盖 Java、TypeScript、Rust 等语言的真实工程仓库，进一步检验模型跨语言迁移能力；SWE-Bench Pro 则进一步筛选了更复杂的多文件跨模块修复场景，要求模型同时修改多处相互依赖的代码文件，并保证全局一致性。值得注意的是，尽管SWE-Bench已成为代码能力评测的事实标准，学界对其局限性存在持续讨论——首先是数据污染风险：测试集来自公开GitHub仓库，无法完全排除模型训练数据中已包含对应修复提交的可能性。其次是部分机构在提交时为模型提供了额外的Oracle错误信息，这在真实工程场景中并不存在。HY3在Pro版本上超越DeepSeek V4 Pro因此更具说服力，因为Pro版本增加了噪声和多文件依赖，更难被表面的上下文匹配所蒙混，参考价值更高。

综合来看，HY3 目前仍落后于 GLM 5.2（当前开源模型的顶级水平），但在代码和智能体相关基准上，它已经能与 DeepSeek V4 Pro 打得有来有回，而模型体量却小得多。腾讯还指出，HY3 在推理、长上下文理解、办公生产力、金融分析、前端开发和游戏创作等方向均有明显提升。

定价方面，正式收费后约为每百万输入 Token 0.14 美元、每百万输出 Token 0.58 美元。以其能力档位来说，这一价格极具竞争力——相比之下，GPT-4o 约为输入 2.5 美元/百万 Token、输出 10 美元/百万 Token，HY3 的输出定价仅为其约 1/17。

前端开发：开源模型的意外惊喜

腾讯反复强调 HY3 在前端开发方向的优势，实测也印证了这一判断。评测者使用 World of AI Benchmark 平台对其进行了多方向测试。

在 macOS 克隆测试中，HY3 在浏览器内的整体还原效果相当出色。它为每个独立应用生成了 SVG 图标，其中 CyberStrike 3D 游戏图标甚至带有动画效果，点进去还生成了一个可运行的 3D 第一人称射击游戏——操控虽略显粗糙，但核心功能均有实现。Finder、Safari、Terminal、Notes、Settings 及 App Store 都有对应的模拟界面。

更值得关注的是滚动触发效果、动画背景、光标交互、字体排版等细节处理——这类效果在开源权重模型中此前相当少见。前端代码生成能力的高低，本质上反映了模型对「声明式UI逻辑」与「命令式动画控制」两种编程范式的融合理解。CSS Animation基于关键帧声明，而Intersection Observer API则需要命令式地注册回调、管理观察者生命周期，WebGL更要求模型掌握着色器语言GLSL的编写——这三类API的使用模式差异极大，且在训练语料中的频率远低于React组件或jQuery操作。HY3能够在单次生成中协调这些API，暗示其后训练阶段可能针对前端工程场景进行了专项数据增强，这与腾讯自身庞大的游戏和应用开发业务场景高度吻合，内部真实工程数据可能是其前端能力突出的重要来源。这些特性还需要对「用户感知体验」有一定判断力，知道何时添加过渡动画才会显得自然而非突兀。如果你从事前端开发，完全可以把 HY3 当作「前端脚手架模型」来用，尤其适合需要滚动触发类交互动效的场景。它能围绕指定 package 生成设计，且生成的元素往往真正可交互、可运行，而不少模型恰恰在这类基础前端任务上翻车。

3D与物理模拟：跨模型横评见真章

在 3D 可视化方面，HY3 一次提示即生成了地球在太空中旋转的 HTML 可视化效果，云层与大气层次感均有呈现，视觉观感甚至优于 Opus 4.8。它还顺利完成了 3D 太阳系模拟器，行星阴影和外观还原度较为真实。

据 Thomas Chess 的横向对比，将 HY3、Gemini 3.5 Flash、GLM 5.2 和 DeepSeek V4 放在一起运行三个 HTML5 Canvas 物理演示（保龄球、空气曲棍球、开球）。

HTML5 Canvas物理模拟的评测价值：以此类场景作为评测并非随意，它实际上是一个综合考察模型多维能力的压缩测试——模型需要同时掌握物理引擎逻辑（碰撞检测算法如 AABB 或 SAT、动量守恒方程、摩擦系数建模）、Canvas 2D API 的正确调用（路径绘制、变换矩阵、像素操作）、动画帧循环（requestAnimationFrame）的性能优化，以及将抽象物理规则转化为可感知视觉效果的「审美判断力」——例如为碰撞添加适当的视觉反馈、控制运动模糊程度。更重要的是，代码逻辑正确性与用户感知质量可以完全解耦：一段物理公式完全正确的代码，若帧率过低或缺乏视觉润色，用户体验仍可能极差。因此该测试能同时揭示效率、成本和视觉质量三个维度的模型差异，是一种颇具创意的评测设计。

结果颇有意思：HY3 约消耗 30K tokens、成本不到 1 美分；Gemini 3.5 用 23K tokens 却花了约 21 美分；GLM 5.2 用 25K tokens 花 7 美分；DeepSeek V4 用了约 50K tokens，表现反而最弱。

HY3 在三个物理场景中的表现基本追平 Gemini 3.5，但价格便宜约 35 倍。保龄球碰撞干净、运动轨迹可信、开球散开也有真实感。评测者总结：GLM 5.2 代码能力更强，但 HY3 的成品视觉效果更好；一旦任务涉及审美、物理效果和模拟手感，HY3 的性价比优势就非常突出。

综合评价：高效、便宜、够用

另一位评测者 TheHype 用海浪冲沙堡、工厂装配线、three.js 交互程序三个提示词，横向对比了 HY3、Fable 5、Opus 4.8 和 Sonnet 5。HY3 以约 14 分钟完成全部任务，明显快于 Fable 5（18 分钟）、Sonnet 5（19 分钟）和最慢的 Opus 4.8（27 分钟）。

值得注意的是，响应速度不仅取决于模型本身的推理效率，还受 MoE 稀疏激活特性的直接影响。大模型推理的速度上限通常不受算力（FLOPS）限制，而受显存带宽（Memory Bandwidth）制约——每次推理需要将模型参数从显存加载到计算单元，参数量越大，加载耗时越长。对于2950亿参数的MoE模型，若以BF16精度存储，理论权重约590GB；但每次推理只激活210亿参数（约42GB），实际需要高速读取的权重量大幅缩减。相比之下，同等效果的Dense模型虽然总参数更少，但每次推理必须全量加载所有参数。这一机制使MoE在吞吐量和首Token延迟（TTFT）上均能保持优势，也部分解释了HY3速度领先的底层原因，尤其适合高并发API服务场景。

结论是：HY3 速度快、代码整洁、完成度出乎预料，但与顶级模型仍有可见差距——沙堡使用的是近似物理而非完整模拟，3D 程序视觉接近前沿但优化几乎为零。作为开源权重模型能达到如此效率，代码质量已远超其体量和价格所对应的预期。

综合多方评测，HY3 是一款好用、经济且效果相当可观的开源大模型，在智能体、代码、STEM 和推理任务上稳定跻身第一梯队。它未必是最强，但性价比出色。照此节奏，腾讯推出真正顶级的开源模型或许只是时间问题。

核心要点

核心要点

核心要点