腾讯混元 Hy4 preview：770B 参数，面向真实生产力任务
从长程编程、办公分析、游戏开发到科学研究，拆解腾讯混元 Hy4 preview 的官方发布信息与实际评测边界。
编辑说明： 本稿基于腾讯混元官方 Hy4 preview 发布稿，资料检索日期为 2026 年 8 月 29 日。内部盲测、吞吐提升和科学研究结果均按“腾讯披露”表述，不当作独立复现结论。
真正值得看的，不只是 770B
腾讯混元这次发布 Hy4 preview，最容易被记住的是三个数字：总参数 770B、激活参数 49B、上下文长度超过 1M。但对开发者来说，更实际的问题是：它能不能跨工具、跨文件，完成一项真正的工作？
腾讯将 Hy4 preview 定位为“为生产力而生”。模型训练数据由软件工程、游戏、金融、安全等领域的内部专家共建，并与 CodeBuddy、WorkBuddy 做了深度协同。这是腾讯给出的产品定位，是否成立，还需要用可复现的工作流验证。
先说结论
- Hy4 preview 仍是早期预览版，不等于已经完成生产验证。
- 官方重点展示的软件工程、办公分析、游戏和科学研究，适合拆成可回放任务分别测试。
- 2.99/4.00 是腾讯内部盲测结果，属于方向性证据，不是独立排行榜。
- 先用一个边界清晰的任务建立基线，再增加工具权限、长上下文或自部署容量。
图 1：腾讯官方发布页是 770B 总参数、49B 激活参数和 1M 上下文等信息的主要来源；这张图支持的是发布事实，不是独立性能结论。
腾讯希望用户测试的四类场景
软件工程方面，腾讯强调长程任务的理解、规划、调试与验证，以及前端视觉审美和交互质量。真正有区分度的测试不是让模型生成一个页面，而是让它修改多个文件、运行检查、定位失败原因，再把项目修到可交付状态。
办公分析方面，官方案例是从 72 份文件中判断发票是否合规，并从 3 份制度文件中找出当前生效规则。这个任务比普通摘要更有价值，因为它会暴露跨文件检索、规则时效和证据引用问题。
游戏开发方面，腾讯展示了通过 MCP 接入 Unreal Engine 5 制作射击游戏 Demo，以及使用 Unity 制作第三人称企鹅冒险游戏。它说明模型可以在受控环境里操作一条工具链，但不能据此推断所有生成游戏都能直接进入生产。
科学研究方面，发布稿提到 AI 研发、分子动力学、量子输运和几何问题，并披露了 32,512 原子分子动力学系统 2 倍提速、量子输运高能泄漏率从 48.2% 降至 4.8% 等结果。这些案例适合作为独立复现的入口；在代码、参数和专家复核公开前，不能直接当作普遍科学结论。
内部盲测能说明什么
腾讯称组织了 163 名内部专家，完成 203 个工程任务的盲测。Hy4 preview 平均 2.99/4.00，GLM-5.3 为 2.92，Kimi K3 为 2.94。这说明在这组任务和评分标准下，内部专家略偏好 Hy4 preview，但不等于公开环境中的统一模型排名，因为提示词、工具、采样和评分细节并未完全公开。
腾讯还披露，Hy4 preview 自主分析推理系统瓶颈并围绕算子融合、通信优化迭代后，端到端吞吐较基线提升 31.8%。这是一个值得关注的系统实验结果，但不能延伸成“模型可以无监督优化任意推理基础设施”。
怎么体验，怎么做第一次评估
Hy4 preview 已上线腾讯云 TokenHub、OpenRouter，并可在 WorkBuddy、CodeBuddy、元宝和 ima 中体验。官方价格为输入 6 元/百万 tokens、输出 18 元/百万 tokens、缓存命中 0.3 元/百万 tokens；WorkBuddy 和 CodeBuddy 提供两周限时免费体验。
第一次测试不必追求宏大：准备一个有边界的代码仓库任务、一个跨文件办公任务和一个工具调用原型。记录提示词、模型版本、工具调用、耗时、token、失败次数和最终产物。若使用 SandBase 这类网关，可以把密钥留在服务端，并用相同工作流复测不同模型；但在确认模型目录和 API 返回前，不应声称 SandBase 已直接接入 Hy4 preview。
preview 就意味着还要观察
腾讯明确说明 Hy4 preview 仍是早期版本，已知问题包括复杂长任务中的过度思考和过度自我验证。需要低成本探索的团队可以现在试用；需要稳定延迟、固定行为或独立科学审计的团队，应把它当作评测候选，等待更多证据。
结论： Hy4 preview 的看点，是腾讯把一个大规模开源模型放进代码仓库、办公文件、游戏引擎和科研环境这些“脏活”里。判断它是否值得采用，应该看能否完成可复核的工作流，而不是只看参数规模。
一套可复现的评测方法
评估 Hy4 preview 前，先固定代码仓库版本、输入文件、验收标准、允许调用的工具和时间预算，再用第二个模型执行同一任务。否则，一个看起来更漂亮的 Demo 可能只是因为提示词更宽松。
代码任务可以准备三类：跨文件追踪 bug、需要迁移和测试的功能，以及同时接受截图和测试套件验收的前端改动。记录每次工具调用和回滚。少写一些 token 不代表更便宜，如果最后需要人工反复修复，真实成本可能更高。
办公任务应保持源文件不可变，要求模型输出带文件名和页码引用的决策表，并统计误批、误拒、缺失证据和审核耗时。1M 上下文可能减少手工切片，但更大的窗口不会自动带来更高的事实准确率。
游戏或网页任务则要把视觉效果和工程结果分开验收：项目能否在干净环境启动，素材是否有授权，第二台设备上的交互是否正常，以及模型能否从失败构建中恢复。Demo 最吸引人的往往是第一次生成，最昂贵的却是后续修复循环。
API 还是自部署
如果目标是了解模型行为、控制预算或和其他模型对比，先用 TokenHub、OpenRouter、WorkBuddy 或 CodeBuddy 体验更合适。密钥应留在服务端，每次运行附带 request ID，并记录延迟、token、重试次数和最终状态。
自部署是另一种决策。770B MoE 即使每个 token 只激活 49B 参数，权重存储、量化质量、长上下文 KV cache、互联带宽和升级成本仍然不低。“开放权重”改变的是谁可以运行模型，并不意味着推理免费。
如果 Hy4 preview 已出现在 SandBase 的模型目录和 API 返回中，可以用 SandBase 做服务端路由、用量记录和多模型复测；在目录和接口确认前，不应从发布稿推断已经直接接入。
下一版本值得观察什么
第一是公开的生产力评测 harness。内部盲测能提供方向，但如果能公开任务、提示词、工具、评分规则和失败案例，结果会更容易解释。
第二是长上下文质量，而不是窗口数字。真正该看的指标包括检索准确率、引用完整度，以及无关内容增加后性能如何衰减。
第三是自我验证和完成时间的平衡。腾讯已经把“过度思考”和“过度自我验证”列为已知问题，后续版本需要证明模型能判断什么时候继续检查有价值，什么时候只是在重复循环。
常见问题
图 3：WorkBuddy 是第一次做边界清晰试验的官方入口之一；具体可用模型和限制仍应以测试当天产品页面为准。
Hy4 preview 是开源模型吗？
腾讯在发布稿中提供了 Hugging Face、GitHub、ModelScope 和 GitCode 链接。准备部署前仍需检查具体许可证、权重格式和硬件要求；有权重不等于拥有完整生产服务栈。
2.99/4.00 是独立 Benchmark 吗？
不是。这是腾讯内部 163 名专家、203 个工程任务的盲测结果，适合当作发布证据，不是独立复现的公开排行榜。
可以直接用它做财务或科研决策吗？
只能作为有人工复核、引用和审计记录的助手。发布稿中的金融和科学案例值得跟进，但不能替代领域专家或独立验证。
第一次应该怎么试？
先在 WorkBuddy、CodeBuddy、TokenHub 或 OpenRouter 选择一个边界清晰的任务，保存提示词和输出，再用控制模型重复一次，比较成功工作流的真实成本。
图 2：部署前应以仓库中的权重文件、运行说明和许可证为准，不要只根据“开放权重”四个字制定生产方案。
