腾讯 Hy4 把 770B 参数压到 49B 激活，开源大模型竞争转向真实工作负载
腾讯发布并开源 Hy4 preview：总参数量 7700 亿，每个 token 激活约 490 亿参数，上下文窗口超过 100 万 token。它同时进入 WorkBuddy、CodeBuddy 等产品并提供 API，目标不是只在聊天榜单上拿分，而是覆盖软件工程、办公自动化、科研和长周期 Agent 任务。
作者：林岚｜OC 开发者生态编辑
腾讯发布并开源 Hy4 preview：总参数量 7700 亿，每个 token 激活约 490 亿参数，上下文窗口超过 100 万 token。它同时进入 WorkBuddy、CodeBuddy 等产品并提供 API，目标不是只在聊天榜单上拿分，而是覆盖软件工程、办公自动化、科研和长周期 Agent 任务。
一句话结论：Hy4 最值得看的不是“770B”这个大数字，而是腾讯能否把 49B 激活、超长上下文和推理系统优化组合成可负担、可复现的真实吞吐。
Hy4 采用混合专家架构。总参数决定模型可以容纳多少专家知识，激活参数则更接近单次推理真正参与计算的规模。770B/49B 的组合意味着模型每次只调用一小部分专家，因此理论上能在保留大容量的同时控制计算量。但它不等于只部署一个 49B 稠密模型：全部权重仍需要存储和跨设备编排，专家路由也会带来通信、负载不均与尾延迟。
超过 100 万 token 的上下文同样不能直接翻译成“能读懂一整个代码库”。窗口容量只说明请求能装下多少内容，长期任务还取决于注意力计算、KV 缓存占用、检索策略以及模型能否从大量无关信息中找出正确约束。真实工程里，百万上下文更适合被理解为一种上限，而不是免整理代码和文档的许可证。
腾讯在公告中称 Hy4 在若干软件工程、游戏开发和科研任务上优于 GLM-5.3 与 Kimi K3，并强调模型和推理系统共同优化。这里仍要等独立复测：不同评测的工具配置、采样预算和失败重试会显著改变 Agent 成绩。开源权重的价值恰恰在于，开发者可以在自己的仓库、自己的任务时长和自己的硬件上验证，而不是只接受一张汇总表。
对团队而言，评估 Hy4 应该拆成三层。第一层是能力：修复跨文件缺陷、调用终端、持续执行几十分钟时是否稳定。第二层是系统：需要多少 GPU、首 token 与长生成延迟如何、专家并行是否成为瓶颈。第三层是治理：许可证、数据边界、私有部署与日志审计是否符合组织要求。
腾讯把模型同时放进产品、API 和开源生态，说明大厂的模型竞争已经从单一发布会转向完整分发链。开源可以吸引推理框架和企业适配，产品入口提供反馈与收入，云 API 则承接不愿自建集群的用户。三者能否相互促进，比一次榜单领先更重要。
关键事实
- 来源：腾讯官方公告
- 涉及产品：Hy4 preview、WorkBuddy、CodeBuddy
- 核心技术：混合专家模型、约 49B 激活参数、超长上下文
- 关键数字：770B 总参数、49B 激活参数、超过 100 万 token 上下文
OC 判断
先别急着被总参数吓到。大规模 MoE 的难点早已不只是训练出权重，而是让专家路由、显存、网络和服务调度一起工作。Hy4 如果能让第三方在稳定吞吐和总成本上复现腾讯的主张，才会成为真正有分量的开源基础模型；否则，770B 只是一张昂贵的名片。
为什么重要
- 对开发者：开源权重提供了在私有代码库与真实 Agent 流程中复测的机会。
- 对企业：49B 激活降低单 token 计算，不代表 770B 权重的部署成本消失。
- 对行业：模型竞争进一步转向模型、推理框架、产品入口和云服务的协同。
评论
围绕这篇文章补充信息、提出问题或分享观察。