腾讯混元Hy4开源：770B参数冲击第一梯队

腾讯把混元推入超长上下文与大规模开源模型竞争

腾讯混元在今天发布并开源了新一代大语言模型 Hy4 preview。这是混元Hy系列的早期公开版本，总参数达到7700亿，激活参数490亿，上下文长度达到100万Token，重点面向软件工程、办公分析、游戏开发和科学研究等生产力场景。

Hy4 preview是一款采用超大规模稀疏架构、支持100万Token上下文的开源大语言模型。 这里有两个数字需要分开理解：770B代表模型整体参数规模，49B代表一次推理时实际参与计算的激活参数。它不是每次生成一个字都把7700亿参数全部跑一遍，而是通过稀疏化机制挑选部分专家参与计算。对用户而言，这种设计试图同时获得大模型的知识容量和相对可控的推理成本。

这次发布的看点，不只是参数继续变大。真正值得关注的是，腾讯正在把混元的竞争重点从单纯的通用问答，转向长周期、跨文件、需要反复验证的实际工作流。对于开发者和深度用户来说，Hy4 preview更像一个面向生产力代理的底座测试版本，而不是一次常规的聊天模型升级。

770B总参数，49B激活：大模型竞争进入稀疏规模化

稀疏混合专家模型是把一个大模型拆成多个专家模块，并在每次输入时只激活其中一部分的架构。 这类模型的核心思路类似于一个拥有大量专科医生的医院：医院整体能力取决于医生数量，但每位患者不会同时接受所有医生诊疗，而是由分诊系统挑选最相关的专家。

Hy4 preview的770B总参数意味着它拥有更大的参数容量，49B激活参数则意味着单次计算规模明显低于完整参数规模。需要强调的是，激活参数不等同于实际部署成本。推理系统仍然需要加载或管理完整专家权重，网络通信、显存占用、专家路由、并行策略和KV Cache都会影响最终效率。

因此，Hy4 preview对普通开发者的实际意义，不是看到49B就可以简单推断它能以49B密集模型的成本运行。它更可能适合拥有多卡集群、专业推理框架或云端算力的团队。对于本地运行用户，模型权重规模、量化精度、显存需求和官方发布的推理方案，仍然比参数总量本身更关键。

从行业竞争看，770B总参数把Hy4 preview放入了当前开源模型的超大规模阵营；49B激活参数则体现了腾讯在稀疏架构和大规模训练基础设施上的路线选择。模型能否真正形成竞争力，最终要看开放权重、许可证、推理代码、量化版本和社区适配是否同步完善，而不只是发布会上的参数数字。

1M上下文不是简单的“能读更多”

上下文长度是模型一次能够接收并处理的输入与输出Token总容量。 Hy4 preview支持1M上下文，意味着它理论上可以处理远超普通长文本窗口的代码仓库、项目文档、会议材料或多份业务文件。

对于软件工程，1M上下文的价值在于模型可以把需求说明、目录结构、核心模块、测试用例、错误日志和历史改动放进同一个任务范围。传统短上下文模型往往需要开发者手动切分文件，再不断提醒模型前文结论；超长上下文则有机会让模型像新加入项目的工程师一样，先通读材料，再提出修改方案。

但上下文窗口大，不代表模型能稳定使用窗口里的每一项信息。长文本中存在大量无关内容时，模型仍然可能出现信息定位失败、前后结论冲突和过度依赖末尾内容等问题。1M上下文更像是一张足够大的工作台，不等于模型已经具备完美的检索、记忆和推理能力。

对企业用户而言，还需要关注三个实际指标：第一，长上下文输入的计费或资源消耗；第二，随着输入长度增加，首Token延迟是否明显上升；第三，模型在百万Token范围内是否仍能准确找到分散在文档不同位置的关键信息。腾讯此次强调的是上下文长度，完整的长上下文召回率、长文档问答准确率和不同长度下的延迟数据，仍需要更多公开评测补充。

腾讯把训练数据搬到了真实生产任务里

Hy4 preview官方披露的另一个重点，是与腾讯内部软工、游戏、金融和安全等领域专家共同建设高质量数据。生产力模型是以完成真实工作任务为主要目标，而不是只优化通用知识问答的模型。

这条路线的变化很明显。通用模型通常通过数学题、知识题和对话偏好评估能力，但真实工作往往包含更多环节：理解模糊需求、拆分任务、调用工具、修改中间产物、运行测试、检查结果，最后还要交付能被别人使用的文件或代码。

腾讯披露，Hy4 preview在软件工程方向增强了长程开发任务的理解、规划、调试和验证能力，并继续优化前端开发中的视觉审美与交互质量。这说明训练目标不再局限于生成一段看起来正确的代码，而是试图覆盖从需求到可运行产品的完整链路。

办公分析方向则聚焦复杂办公环境、金融分析、数据分析、跨文件协作，以及文档、表格和演示文稿的交付。这个方向对模型提出的要求更接近企业助理：它不仅要从文件里提取信息，还要知道不同文件之间的口径关系，识别数据异常，并把分析结果组织成可直接使用的办公产物。

游戏开发是Hy4 preview较有辨识度的应用方向。腾讯表示，模型能够根据一句需求直接生成可玩原型，并熟练使用游戏引擎，开发者可以通过多轮交互持续完善复杂游戏项目。这里的关键不是一次生成一个小游戏，而是模型能否在多轮修改中保持场景结构、脚本接口、资源引用和玩法逻辑的一致性。

科学研究方向覆盖AI研发、分子动力学模拟、凝聚态物理和基础数学等场景。对于这类任务，模型的价值通常不在于给出一段流畅解释，而在于能否提出可验证的假设、选择合理的计算路径，并识别推导中的边界条件。腾讯给出的方向很有野心，但具体能力仍需要公开可复现实验和第三方评测来确认。

内部盲测：Hy4赢了，但优势并不悬殊

腾讯组织163名内部专家，对203个工程任务进行了盲测。结果显示，Hy4 preview平均得分为2.99/4.00，高于GLM-5.3的2.92/4.00和Kimi K3的2.94/4.00。

| 模型 | 内部盲测均分 | Hy4 preview对比结果 | 测试说明 | |---|---:|---|---| | Hy4 preview | 2.99/4.00 | 基准 | 163名内部专家、203个工程任务 | | GLM-5.3 | 2.92/4.00 | Hy4胜46.8%，平12.8%，负40.4% | 同一内部任务集对比 | | Kimi K3 | 2.94/4.00 | Hy4胜51.2%，平7.9%，负40.9% | 同一内部任务集对比 |

在与GLM-5.3的对比中，Hy4 preview胜率为46.8%，平局率为12.8%，负率为40.4%；与Kimi K3对比时，胜率为51.2%，平局率为7.9%，负率为40.9%。

这些数据可以支持一个相对克制的判断：Hy4 preview已经具备开源模型第一梯队的工程生产力竞争力，但它并没有形成压倒性领先。与GLM-5.3相比，平均分只高出0.07分；与Kimi K3相比，只高出0.05分。两组对比中的负率都超过40%，说明不同任务类型、提示方式和工作流设置下，模型之间仍然存在明显的能力互补。

同时，这是一项腾讯内部组织的盲测，任务由腾讯内部专家参与建设，因而更能反映CodeBuddy、WorkBuddy等腾讯产品所面对的真实场景，但不能直接等同于开放社区的独立基准测试。模型选择者还需要等待第三方在代码修复、长上下文检索、工具调用、数学推理和多模态交互上的复测结果。

Hyra与三维Blaschke–Lebesgue问题：重要进展仍需外部验证

三维Blaschke–Lebesgue问题是凸几何中的经典问题，目标是研究给定宽度条件下凸体的最小体积下界。 腾讯表示，Hy4 preview配合Hyra，在这一问题上将体积下界从0.380799推进到0.41104。

作为参照，Meissner四面体猜想给出的数值为0.41986。按腾讯披露的口径，当前结果距离这一数值还剩约2%的差距。这是一个很有吸引力的科研案例，因为它展示的不是模型直接回答一道标准题，而是模型参与复杂数学问题的探索、构造和验证。

不过，数学问题中的“数值推进”与“完成证明”是两回事。一个更好的下界可能来自新的构造、数值实验或局部推导，但只有在定义、假设、推理链和边界条件都被严格验证后，才能成为被数学界接受的结论。现阶段更准确的表述是：腾讯披露Hy4 preview与Hyra在该问题上取得了重要进展，距离最终证明仍有工作要做。

这件事也说明，模型在科学研究中的有效形态可能不是独立替代研究者，而是成为高强度的探索工具：快速生成候选方案、搜索可能的结构、执行大量计算，再由研究者筛选和证明。模型是否真正推动了问题边界，最终还要看论文、证明材料和独立复核。

Hy4 preview适合谁，暂时不适合谁

对于需要处理大型代码仓库、复杂业务文档和连续开发任务的团队，Hy4 preview值得测试。尤其是已经使用CodeBuddy、WorkBuddy等腾讯产品的用户，可以直接观察模型在真实工作流中的表现，而不必只依赖公开聊天演示。

对于希望在本地部署超大模型的个人开发者，Hy4 preview的门槛则不低。770B总参数意味着权重管理和分布式推理仍然是核心问题，49B激活参数也不会消除显存、带宽和KV Cache带来的系统压力。除非已有多卡环境或成熟的推理基础设施，否则直接部署可能不如选择规模更小、社区工具更完整的模型。

对于要求稳定交付的企业，preview版本也不应直接作为唯一生产模型。腾讯已经明确表示，Hy4 preview是Hy4迭代的早期版本，预训练和后训练仍有较大提升空间。已知问题包括复杂任务中的长时间思考，以及过度自我验证倾向。前者可能拉高响应等待时间，后者则可能让模型在已经得到可用答案后继续重复检查，增加成本并拖慢流程。

因此，Hy4 preview更适合作为高难度任务的候选模型和下一代生产力底座进行评估。测试时应记录任务完成率、首次可用时间、最终交付质量、工具调用成功率和人工修改时长，而不是只比较一次对话的主观观感。

腾讯的节奏：两个月一次大版本迭代

公开报道显示，腾讯混元自今年2月重建基础设施后，平均每两个月迭代一次大版本。按照这一节奏，Hy4后续版本预计还会在近期陆续上线。此次先发布preview，说明腾讯希望通过更快开放真实使用入口来收集反馈，再把问题带回训练和后训练环节。

这种发布方式的价值在于缩短模型与真实用户之间的距离。代码工程、办公协作和游戏开发任务都高度依赖具体工作流，实验室指标很难覆盖所有边界情况。让模型尽早进入CodeBuddy、WorkBuddy国内版及国际版、元宝、ima等产品，可以更快获得真实任务中的错误样本和用户评价。

代价同样明确：preview版本可能出现输出不稳定、响应时间过长、复杂任务自我循环和偶发事实错误。用户需要把它当作持续迭代的测试版本，而不是已经完成打磨的最终模型。

判断：参数很大，但真正的牌在工程闭环

Hy4 preview的发布，意味着国内开源模型竞争已经从“谁能做出一个会聊天的模型”，进入“谁能把模型嵌入真实工作并持续交付结果”的阶段。770B总参数和1M上下文是进入第一梯队的门票，203个工程任务的盲测结果则让它拥有了更具体的能力证据。

但目前还不能仅凭腾讯内部数据就断言Hy4 preview全面领先。它与GLM-5.3、Kimi K3的分差有限，长上下文的独立评测、开源协议、部署成本和社区生态仍会决定模型能否扩大影响力。对开发者而言，真正值得观察的是三件事：百万Token上下文是否在长代码和跨文件任务中稳定有效，49B激活架构能否带来可接受的推理效率，以及腾讯能否把内部生产力优化沉淀成开放社区可复用的工具链。

今天的Hy4 preview更像一次高规格公开测试：它已经把参数规模、上下文长度和生产任务能力推到新的位置，但最终能否成为开发者长期使用的基础模型，还要看接下来几个月的版本迭代和第三方验证。至少在当前时点，Hy4 preview值得被列入国内开源大模型的重点测试名单。