ZPedia丨Hy4 Preview 发布：腾讯开始用产品定义模型

刚刚，腾讯正式发布并开源 MoE 架构模型 Hy4 Preview。

相较于上一代 Hy3，其总参数量从 295B 扩充至 770B，单 Token 激活参数由 21B 提升至 49B，上下文窗口也由 256K 拓展到 1M。

表面上看，这只是一次常规的 Scaling。但深入架构底层会发现，这是一场围绕 Agent 核心瓶颈的针对性重构。从知识容量的解耦分配、长上下文的高效精准检索，到深层网络中状态信息的传递带宽，三个决定 Agent 能力上限的关键维度被同步改造。

770B 不是简单堆参数

规模跃升是 Hy4 Preview 最直观的进化。

相较于 Hy3，Hy4 Preview 的总参数扩大约 2.6 倍，激活参数增长约 2.3 倍，而单 Token 实际调用的计算量仅占总参数的 6.4% 左右。这恰好击中了 MoE 架构的核心逻辑：将“模型能储备多少知识与模式”与“每次推理需付出多少算力”进行深度解耦。

在全部 78 层网络中，Hy4 仅首层采用标准稠密 FFN，其余 77 层均为 MoE 层。每层均配置 256 个路由专家与 1 个共享专家，单 Token 仅动态激活其中的 8 个路由专家与该共享专家。对比 Hy3 的 192 个专家配置，Hy4 优先扩充的是专家池的横向宽度，而非同步增加单 Token 经过的专家数量。

这种设计使 770B 更像衡量知识与表征上限的“容量指标”，而 49B 才是决定单步推理开销的“计算指标”。庞大的专家池促使模型在代码语义、符号推演、金融逻辑和科学文献等多样化数据分布上形成更精细的分工，同时阻断了推理成本随总参数量的线性膨胀。

不过，49B 的激活参数规模本身也并不轻量。达到上一代 2.3 倍的激活体量表明，腾讯并非走极致稀疏化以换取低廉成本的路线，而是在模型交付质量与服务开销之间，主动将重心向前者倾斜。

另一个常被忽视的重构在于模型内部维度的拓宽。Hy4 的隐藏层维度由 4096 增至 6144，注意力 Query 压缩维度达 2048，KV 压缩维度为 512，网络总层数反而从 80 层微缩至 78 层。它摒弃了单纯“加深网络”的粗放路径，转而将新增容量倾注到更宽的表征空间、更庞大的专家集群以及更丰富的信息通路中。

这一架构取向具有鲜明的生产力导向。真实工作流要求模型在同一条推理轨迹内，同步承载需求拆解、规则记忆、工具调用、代码生成、异常回溯与产物校验。与其单向增加网络深度，不如大幅提高单层表征的信息承载上限，并赋予各类异构信息更充分的路由与交互空间。

1M 上下文真正的难点，不是「装进去」，而是「找得到」

Hy4 Preview 将上下文窗口由 256K 拓展至 1M Token，达到了上一代的四倍 。但在真实的智能体应用中，长上下文从来不是一个单纯的容纳量问题 。

即便模型能将整个代码仓库、数十份财务底稿或冗长的运行日志完整塞入窗口，也不代表它在推演到第 60 万个 Token 时，依然能准确定位并遵循开头某份配置文件中的边界约束 。若沿用标准全稠密注意力，每个 Token 都必须与前序序列中的所有位置计算相关性，计算开销与序列长度呈平方级关系 。当窗口从 256K 扩张到 1M 时，理论上的注意力运算量激增近十六倍，极易导致推理性能崩溃 。

破解这一瓶颈的关键，在于 Hy4 引入的带门控深度稀疏注意力（Gated DeepSeek Sparse Attention，即带门控 DSA） 。

DSA 的核心逻辑是分步检索：先借助轻量级索引器从超长历史中快速筛选出与当前 Query 关联度最高的局部候选集，随后仅针对这部分 Token 执行精细的注意力计算 。Hy4 每次固定选取 top-2048 个位置 。在 1M 满载上下文中，这意味着单次查询只需聚焦约 0.2% 的核心历史，使核心计算复杂度直接降维 。

这项改造在工程落地上远比单纯扩大窗口更具现实意义 。真实生产力任务的上下文极少是结构工整的纯文本，而是源代码、表格数据、网页抓取结果、工具接口返回、历史对话与报错栈混杂交织的复杂载荷 。模型需要的从来不是平均通读全部内容，而是在多步执行的不同阶段，动态、精准地定位关键证据片段 。

然而，稀疏注意力机制本身也暗藏隐性开销：尽管核心注意力只计算 top-k，但如果负责寻址的索引器在每一层都要全量扫描一遍 1M 序列，依然会产生庞大的重复开销 。为此，Hy4 进一步集成了跨层索引复用机制 IndexCache 。

在 Hy4 的 78 层网络中，仅有约 21 层独立执行索引检索，其余层均直接复用相邻层的选择结果，砍掉了近四分之三的索引扫描计算 。这与 IndexCache 的核心研究结论高度契合：深层网络相邻层所关注的关键 Token 高度重合，逐层重复寻址毫无必要 。

在 30B DSA 模型的学术基准测试中，IndexCache 在几乎不损耗模型质量的前提下，削减了多达 75% 的索引计算，并分别实现了最高 1.82 倍的 Prefill 加速与 1.48 倍的 Decode 加速 。尽管上述实测倍率源自学术实验模型而非 Hy4 的端到端数据，但它充分解释了 Hy4 为何有能力将 1M 长上下文从理论规格真正转化为可在线落地的工程服务能力 。

此外，Hy4 还在注意力模块中嵌入了门控机制，并设置了可学习的注意力汇聚节点（Attention Sink） 。虽然腾讯官方尚未完全公开门控训练的数学推导细节，但从网络拓扑可以明确：门控用于对注意力输出进行逐元素动态加权，赋予模型按需调节当前层吸收检索信息比例的能力；可学习的 Sink 节点则为注意力权重提供了受控的汇聚锚点，有效化解了超长序列推理中注意力无意义地黏附在开头 Token 的现象 。

三者协同，构成了 Hy4 长上下文落地的完整技术闭环：DSA 负责少看，IndexCache 负责少找，门控与 Sink 则负责精准控制吸收的比例与纯度 。

四条残差流，解决长程 Agent 的另一个瓶颈

长上下文解决的是模型能否从外部历史中找到信息，但 Agent 还面临另一个问题：信息能否在模型内部稳定地传过几十层网络。

传统 Transformer 每层只有一条残差流。输入经过注意力或前馈网络变换后，再加回原始表示。这种结构足够稳定，却也意味着所有信息——任务目标、当前计划、代码状态、工具反馈和异常信号——都被压进同一条通道。

Hy4 引入 identity Hyper-Connections（iHC），把单一残差流扩展为 4 条并行残差流。不同信息可以沿多条路径跨层传播，并在每层进行重新组合。可以把它理解成：过去整支团队共用一张不断被改写的白板，现在有了四张可以并行记录、再相互交换信息的白板。

Hyper-Connections 的价值不在于凭空增加知识，而在于增加网络内部的信息带宽。对于一次性问答，这种变化可能不容易被感知；但对需要几十轮工具调用的任务，模型既要保持最初目标，又要吸收中间结果，还要不断更新计划，多残差流更可能发挥作用。

「identity」同样重要。普通 Hyper-Connections 如果让多条残差流自由混合，深层训练容易破坏残差网络最关键的恒等映射，带来梯度不稳定。iHC 保留稳定的身份通路，再学习额外的信息交换。它试图同时获得两件事：比标准残差连接更高的信息容量，以及大规模训练所需要的稳定性。

因此，Hy4 的技术主线不是一个孤立的新模块，而是相互咬合的系统：MoE 增加知识与能力容量，稀疏注意力提高外部记忆的检索效率，iHC 则扩展内部信息传输能力。它们共同服务于同一种任务——上下文很长、状态不断变化、需要多步执行的 Agent 工作流。

「为生产力而生」，技术上究竟代表着什么

很多模型都会在发布时强调生产力，但 Hy4 与普通的场景微调有一个重要差别：腾讯把产品反馈放进了模型训练与评测的闭环。

Hy4 的后训练数据由腾讯内部的软件工程、游戏、金融、安全等领域专家共同建设，并持续与 CodeBuddy、WorkBuddy 协同设计。这里的 Co-Design，不只是模型接入产品，而是产品中暴露出来的失败案例，反过来决定训练数据、强化学习任务和评测集应该如何构造。

真实 Agent 的失败往往并不是「不会写某一行代码」，而是出在更长的链条上：理解错了隐含约束、忘记检查已有文件、调用了错误工具、修改后没有运行测试、发现报错却陷入循环，或者内容正确但交付物无法使用。这类问题很难通过单轮问答数据修复，更适合把完整执行轨迹作为训练单位，并用环境中的可验证结果作为奖励。

Hy4 没有公开后训练算法、RL 任务数量与算力规模，因此目前无法判断具体采用了多少规则奖励、过程奖励或专家偏好数据。但从能力变化可以看出，优化目标已经从「生成正确答案」进一步转向「把任务闭环」。

这在软件工程评测中表现得最明显。Hy4 在 Terminal-Bench 2.1 上由 Hy3 的 70.8 提升至 85.4，在 DeepSWE 上由 28.0 提升至 64.3，在 SWE Atlas Refactoring 上由 32.9 提升至 53.3；工作智能体方面，Toolathlon-Verified 从 56.2 提升至 74.1，OneMillionBench（带工具）从 51.5 提升至 65.4。这里的共同点不是考查模型能否背出知识，而是能否在真实环境里规划、调用工具、修改对象并验证结果。

不过，官方成绩同样显示，Hy4 还不是一款在所有方向上都领先的模型。它的 Terminal-Bench 已接近第一梯队，但 DeepSWE 仍落后于 Kimi K3 和 Claude Opus 5；ProgramBench 得分 17.5，明显低于 GPT 5.6 Sol 的 25.0 和 Claude Opus 5 的 39.5；在不带工具的 Humanity's Last Exam、HorizonMath 等纯推理任务上，也与最强闭源模型存在差距。

这种能力分布恰恰厘清了 Hy4 的生态位定位：它当前的核心突破并非追求单项极端理论智力的高分，而是致力于将扎实的基础推理、长上下文检索、工具调度与执行闭环能力进行深度工程化耦合 。

腾讯还组织了 163 名内部专家，对 203 个工程任务进行盲测。Hy4 平均得分为 2.99/4，略高于 GLM 5.3 的 2.92 和 Kimi K3 的 2.94；对 GLM 5.3 的胜、平、负比例为 46.8%、12.8% 和 40.4%，对 Kimi K3 则为 51.2%、7.9% 和 40.9%。

这组结果比只看公开榜单更接近实际工作，但也需要克制解读：任务来自腾讯内部，天然更贴近其产品环境；203 个样本不足以证明全面领先；平均分差距也很小。它能证明的是 Hy4 已经进入国内第一梯队，并在腾讯关心的工程工作流中具备竞争力，而不是已经形成代际碾压。

MTP、FP8 与低价 API

一个 770B 模型是否能成为生产力工具，最后仍取决于速度和成本。

Hy4 在主干之外内置了一层原生 MTP（Multi-Token Prediction）模块，总参数 10B、激活参数约 0.7B。普通自回归模型一次只预测下一个 Token，MTP 则额外预测更远的后续 Token；部署时，它可以先提出多个候选 Token，再由主模型并行验证，从而减少逐 Token 串行生成造成的延迟。腾讯给出的 vLLM 部署配置一次启用 3 个 speculative tokens，说明 MTP 已经不是只用于改善训练表征，而被直接纳入推理加速链路。

官方同时开放 BF16 与 FP8 权重，并给出 vLLM、SGLang 和 8 卡张量并行的部署方案。FP8 将权重存储大致压缩到 BF16 的一半，但 770B 仍意味着极高的显存与通信门槛。Hy4 是开放权重模型，却不是普通开发者可以轻松本地运行的模型；它更适合云端集群、模型服务商与大型企业私有化部署。

API 定价则延续了腾讯用低价格推动调用量的策略：输入 6 元/百万 Token，输出 18 元/百万 Token，缓存命中输入为 0.3 元/百万 Token。缓存价格只有普通输入的二十分之一，明显针对长代码仓库、企业知识库和多轮项目这类「大量上下文重复使用」的工作负载。

但 Hy4 Preview 已知存在两个问题：复杂任务上思考时间偏长，以及过度验证。二者在 Benchmark 上可能提高成功率，在生产环境里却会直接转化为更长延迟和更多输出 Token。

用产品定义模型，而不是用模型寻找场景

Hy4 Preview 不是单纯追求参数膨胀的常规升级 。

从 770B/49B 的 MoE，到 top-2048 的稀疏注意力、跨层复用索引、4 条残差流，再到原生 MTP，腾讯解决的是同一个问题：怎样让一个更大的模型，在很长的上下文里持续工作，并把计算花在真正相关的信息和步骤上。

这背后折射出对大模型下一阶段竞争的清晰判断：行业博弈的重心正在从单次文本生成的惊艳度，转向复杂任务能否真正闭环落地 。

Hy4 目前还没有在所有公开评测上领先，也仍有推理冗长和过度验证的问题。但它已经让腾讯的模型路线变得清晰：预训练继续扩大能力上限，后训练围绕真实工作轨迹塑造行为，产品再把用户反馈送回训练系统。

过去，大厂通常先训练一个通用模型，再为它寻找应用；Hy4 展示的是另一条路径：让 CodeBuddy、WorkBuddy 以及腾讯内部真实的工程、金融、游戏和科研工作，反过来定义下一代模型应该学会什么。