摘要：腾讯开源 Hy4 preview，总参数量 770B、激活参数 49B、上下文窗口达到 1M token，重点面向长周期软件工程、文档办公和科学研究。参数规模和榜单分数容易吸引注意，决定其工程价值的却是稀疏模型的路由效率、长上下文的有效利用、智能体在多轮工具调用中的稳定性，以及部署和运维成本。对企业用户来说，Hy4 的意义在于国产开源模型开始从通用问答转向复杂工程任务，但“能放下一百万 token”仍不能等同于“能完成一百万 token 尺度的工作”。
摘要
腾讯开源 Hy4 preview，总参数量 770B、激活参数 49B、上下文窗口达到 1M token，重点面向长周期软件工程、文档办公和科学研究。参数规模和榜单分数容易吸引注意，决定其工程价值的却是稀疏模型的路由效率、长上下文的有效利用、智能体在多轮工具调用中的稳定性，以及部署和运维成本。对企业用户来说，Hy4 的意义在于国产开源模型开始从通用问答转向复杂工程任务，但“能放下一百万 token”仍不能等同于“能完成一百万 token 尺度的工作”。
规模数字背后的架构逻辑
770B 总参数与 49B 激活参数，说明 Hy4 preview 采用了大规模稀疏混合专家路线。每个 token 不经过全部参数，而是由路由器选择少数专家参与计算。这样可以在保持单次前向计算量相对可控的同时，扩大模型知识容量和任务分工能力。粗略看，激活参数只占总参数的约 6.4%，但这并不意味着部署成本也只有同尺寸稠密模型的 6.4%。全部权重仍需存放在显存、内存或分层存储中，跨设备通信、专家负载均衡和 KV Cache 都会形成额外开销。
MoE 模型在训练和推理阶段面对不同难题。训练时需要避免少数专家长期拥堵、其他专家得不到充分训练；推理时则要控制不同 token 路由造成的 all-to-all 通信。批量较小、请求差异较大时，专家并行的硬件利用率可能下降。对云 API，平台可以通过大规模请求聚合改善效率；对企业私有化部署，770B 权重仍意味着较高门槛。所谓“开放权重”解决的是可获得性，是否能以合理成本运行，还取决于量化、并行策略、推理引擎和硬件集群。
因此，企业选型不能只看激活参数。需要同时测量首 token 延迟、持续输出速度、长上下文下的显存占用、并发吞吐、跨节点带宽需求，以及工具调用任务的单位完成成本。API 给出的每百万 token 输入 0.834 美元、输出 2.501 美元可以作为初始参照，但真实成本应按“完成一个任务”计算。若模型能够减少返工、缩短代理循环或降低人工检查量，单 token 较高也可能更经济；若长任务中频繁偏航，价格再低也难以进入生产流程。
一百万 token 的价值不在“塞进更多文档”
长上下文常被理解为可以一次投喂整个代码库或大量文件。实际工程中，原始材料越多，噪声、冲突和版本差异也越多。模型需要知道哪些文件是入口、哪些接口已经废弃、哪些测试代表当前行为。把代码仓库不加选择地拼进上下文，可能导致注意力被低价值内容稀释。
一百万 token 更适合支撑持续工作状态：需求说明、代码结构、测试结果、历史决策、工具返回和中间计划可以在较长任务中保留。它降低了频繁压缩上下文造成的信息损失，也让模型有机会追踪跨文件依赖。但长周期工程还需要外部记忆。任务清单、变更记录、假设、失败尝试和验证证据应结构化保存，模型在关键节点重新读取，而不是把一切寄托在上下文窗口里。
评价长上下文模型可以分为三个层次。第一层是检索，能否从远距离位置找回关键事实；第二层是关联，能否整合多个文件中分散的信息；第三层是执行，能否在几十轮工具调用后仍保持目标、约束和代码一致性。许多模型在第一层表现很好，到了第三层会逐步偏航。Hy4 将长周期软件工程列为主要场景，因此比普通问答分数更值得看的，是其在真实仓库中定位问题、修改代码、运行测试、处理失败并最终交付的闭环表现。
203个工程任务盲评应该怎样看
发布资料提到，Hy4 preview 在 203 个工程任务盲评中得到 2.99 分，略高于 GLM‑5.3 的 2.92 和 Kimi K3 的 2.94。差距很小，不能简单外推为普遍领先。盲评的优点是减少品牌偏见，缺点是结果高度依赖任务构成、评分尺度、代理框架和执行预算。如果一个模型获得更多思考 token、更长运行时间或更强工具配置，分数未必只反映模型本身。
企业复测应建立自己的任务集。制造企业可以选择设备接口开发、工艺文档解析、SQL 分析、告警规则编写和历史代码维护；软件团队则应覆盖新功能、缺陷修复、重构、测试补全和依赖升级。每个任务记录成功率、人工接管次数、测试通过率、代码审查问题和总成本。只有把模型放进同一代理框架、使用相同工具和预算，结果才具有选型意义。
还要警惕“平均分掩盖失败类型”。智能体任务中，一次越权修改、误删数据或伪造测试结果，比多次小幅得分提升重要得多。评估表应单独统计不可接受错误，并设置硬性淘汰条件。模型是否愿意承认不确定、是否会读取项目规则、是否能在失败后收缩动作范围，往往决定它能否进入企业环境。
开源大模型进入代理系统后的新要求
通用聊天模型可以通过人工判断答案质量；代理模型会修改代码、调用接口并产生外部影响，需要额外的工程层。第一是权限隔离，模型只获得当前任务所需权限。第二是可回滚，代码和配置变更必须在分支或沙箱中完成。第三是验证先行，把单元测试、静态分析、安全扫描和业务规则作为自动门禁。第四是过程可观测，记录模型计划、命令、文件差异和失败原因。第五是成本控制，对循环次数、上下文增长和外部调用设置预算。
Hy4 preview 的开放也给国产推理基础设施提出压力。770B 级稀疏模型需要完善的专家并行、量化和容错支持。不同 GPU、国产加速卡和高速互联环境能否稳定运行，将影响它从云端 API 走向本地部署。对多数企业，先通过 API 建立任务评估集，再选择蒸馏、小模型协同或私有集群，通常比直接采购大规模硬件更稳妥。
国产模型竞争开始转向工程完成度
过去的模型发布主要比较知识、推理和生成质量。Hy4 preview 把重点放在长周期软件工程、文档和科研任务，说明竞争指标正在改变。模型需要持续维护状态，调用复杂工具，处理环境反馈，并在长时间运行中保持约束。模型能力仍是底座，代理框架、工具标准、记忆系统、评测集和安全治理正在成为同等重要的组成部分。
对开发者而言，Hy4 提供了新的开源基座；对企业而言，它更像一次检验机会：业务是否已经被拆成可调用工具，知识是否有清晰版本，任务是否有自动验收标准。如果这些基础没有准备好，百万 token 和数千亿参数只能提高对话上限，很难直接提高生产效率。