刚刚，腾讯正式发布并开源 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 以及腾讯内部真实的工程、金融、游戏和科研工作，反过来定义下一代模型应该学会什么。