Hy4 Preview 与 Hy3：从 295B 到 770B，腾讯混元的架构跃迁与生产力落地

2026年8月28日，腾讯混元团队正式发布新一代旗舰模型 Hy4 Preview，总参数770B、激活参数49B、上下文窗口突破1M Token。距离Hy3正式版发布仅仅过去三天，两代模型构成了当前开源MoE模型最具代表性的生产力组合。

一、架构演进：从常规MoE到稀疏注意力+多流残差的全面重构

很多人看到Hy4的第一反应是"参数翻了一倍多，激活参数也涨了"，但这只是最表层的变化。真正的代际差异在于，Hy3走的是"标准MoE+优化细节"的路线，而Hy4直接对Transformer的两个核心组件------注意力机制和残差通路------做了底层重构。

1.1 MoE结构：专家数量与路由机制的迭代

先看最基础的MoE架构，两代模型都采用了"首层稠密FFN+后续层MoE"的混合设计，这是当前大模型的主流做法------底层用稠密层保证基础特征提取能力，上层用MoE扩容同时控制推理成本。

Hy3的MoE配置：

总层数80层（不含MTP层），第0层为稠密FFN，1-79层为MoE
每层192个路由专家 + 1个共享专家
每个Token激活top-8路由专家 + 共享专家，共9个专家
路由采用Sigmoid打分而非Softmax，配合每个专家独立的偏置项做负载均衡
总参数295B，单Token激活21B

Hy4 Preview的MoE配置：

总层数78层（不含MTP层），第0层为稠密FFN，1-77层为MoE
每层256个路由专家 + 1个共享专家
每个Token同样激活top-8路由专家 + 共享专家，共9个专家
总参数770B，单Token激活49B

这里有个很容易被忽略的细节：虽然都是top-8激活，但专家总数从192涨到256，意味着专家之间的分工可以更细。192个专家的时候，每个专家大概要覆盖1/192的能力范围；到256个专家，每个专家的专精领域可以更窄，专业度更高。这也是为什么Hy4在垂直场景（比如代码、金融分析）提升特别明显的原因之一。

共享专家的设计两代都保留了。这个机制的作用很直观：所有Token都经过共享专家，相当于给整个模型保留了一个"公共基础能力池"，避免路由专家过度特化导致通用能力下降。从工程角度看，共享专家也能一定程度上缓解路由抖动问题------当输入分布变化时，至少有一部分计算是稳定的。

1.2 注意力机制：从GQA到Gated DSA + IndexCache的本质飞跃

这是两代模型最大的架构差异，没有之一。

Hy3用的是行业标准的GQA（分组查询注意力）：64个Query头对应8个KV头，每个KV头被8个Query头共享。这是从GPT-3时代就验证过的成熟方案，在保证效果的同时把KV缓存的内存占用降到原来的1/8。对于256K上下文来说，GQA完全够用，计算瓶颈主要在MoE部分。

但到了1M上下文，标准注意力的O(n²)复杂度就扛不住了。1M Token的自注意力计算，理论运算量是256K的16倍。即便用GQA减少了KV的存储，计算量本身的爆炸依然会让推理速度崩掉。

Hy4的解决方案是带门控的深度稀疏注意力（Gated DeepSeek Sparse Attention，Gated DSA）+ IndexCache。这套机制不是腾讯原创，官方也明确说明灵感来自DeepSeek和GLM的研究，但做了自己的工程优化和门控改进。

Gated DSA的底层逻辑

标准注意力是"全量计算→选结果"，每个Token都要和前面所有Token算一遍相关性，再加权求和。而DSA反过来，是"先筛选→再计算"，分两步走：

第一步，用一个轻量级的索引器（Indexer）快速扫描整个上下文，选出和当前Token最相关的top-k个位置。Hy4里这个k固定是2048。也就是说，不管上下文是10K还是1M，每个Token最终只和2048个Token做精细的注意力计算。

第二步，对筛选出来的2048个Token执行标准的注意力计算，输出结果。

这样一来，注意力计算的复杂度直接从O(n²)降到了O(n)，因为每个Token的计算量是固定的2048次，和总上下文长度无关。1M上下文下，实际参与精细计算的Token比例只有0.2%，计算量下降了几百倍。

但这里有个问题：索引器本身会不会不准？如果关键信息没被选进来怎么办？

这就是Gated（门控）的作用。Hy4在DSA的基础上加了一个门控机制，会动态评估稀疏注意力的输出是否足够可信。如果门控判断当前场景下稀疏检索可能遗漏重要信息，就会补充额外的稠密计算路径，保证效果不降级。具体的门控阈值是训练阶段学出来的，不是人工硬设的。

IndexCache：跨层复用索引的工程巧思

只有DSA还不够。如果每一层都要单独跑一遍索引器，那77层下来，索引器本身的计算量也不小。IndexCache就是解决这个问题的：前面几层算出来的稀疏索引结果，可以缓存起来给后面的层复用。

实际实现中，一般是每隔几层重新计算一次索引，中间层直接复用缓存的top-k位置。这样既保证了索引不会太陈旧，又把索引器的总计算量降到了原来的几分之一。长上下文场景下，IndexCache带来的速度提升非常明显，尤其是Prefill阶段。

这套组合拳打下来，Hy4才能把上下文拉到1M，同时推理速度还能保持在可用水平。根据官方数据，1M满载上下文下，Prefill速度相比全稠密注意力提升了一个数量级以上。

1.3 残差通路：iHC身份超连接，从单车道到四车道

另一个容易被忽略但影响深远的变化是残差结构。

标准Transformer只有一条残差通路：每层的输出 = 输入 + 子层输出（注意力或FFN）。这条通路既是信息流动的主通道，也是梯度反向传播的高速公路。模型浅的时候没问题，但到了70多层、770B参数的规模，单条残差通路就成了瓶颈------信息和梯度都挤在一条道上，深层容易出现信息衰减或者梯度消失。

Hy4用iHC（identity Hyper-Connections，身份超连接） 把残差通路从1条扩成了4条并行的流。简单说就是，每层的输入会分成四路走，每一路都有自己的注意力和FFN计算，最后再合并。四路之间是身份映射连接，不做额外的线性变换，保证梯度可以毫无阻碍地从最底层传到最顶层。

这个设计的直观好处是模型容量变大了，但更本质的作用是拓宽了深度网络中的信息带宽。不同的残差流可以负责不同类型的信息：有的负责语法结构，有的负责语义内容，有的负责推理逻辑，互不干扰。这也是为什么Hy4在复杂多步推理任务上提升明显的底层原因之一。

1.4 MTP层：从3.8B到10B，投机解码的进化

两代模型都内置了原生的MTP（Multi-Token Prediction，多Token预测）层，用于投机解码加速。这是腾讯混元系列的传统艺能，从很早的版本就开始做了。

MTP层的工作原理是：在正常预测下一个Token的同时，额外预测后面的N个Token。如果后面的预测和主模型的实际输出一致，就可以一次性输出多个Token，相当于"猜中了就跳过计算"。这是一种投机解码（Speculative Decoding），但和传统用小模型做草稿的方案不同，MTP是内置在主模型里的一层，不需要额外加载一个小模型。

Hy3的MTP层：总参数3.8B，激活参数约0.3B，默认一次预测1个额外Token
Hy4的MTP层：总参数10B，激活参数0.7B，支持一次预测3个额外Token

配合vLLM的投机解码框架，开启MTP后生成速度通常能提升30%-50%。而且因为是原生内置的，兼容性比第三方投机解码方案好很多，不会出现风格不一致或者错误累积的问题。

1.5 核心架构参数对比表

维度	Hy3	Hy4 Preview
架构类型	MoE（稠密+MoE混合）	MoE（稠密+MoE混合）
总参数	295B	770B
激活参数	21B / Token	49B / Token
层数	80层（1稠密+79 MoE）	78层（1稠密+77 MoE）
专家配置	192路由 + 1共享，top-8激活	256路由 + 1共享，top-8激活
注意力机制	GQA（64Q / 8KV）	Gated DSA + IndexCache（64头）
索引器配置	-	32头，top-2048
残差通路	1条标准残差	4条iHC超连接残差
MTP层参数	3.8B总 / ~0.3B激活	10B总 / 0.7B激活
上下文窗口	256K	1M
隐藏层维度	4096	6144
词表大小	120832	120832

二、性能深度对比：提升到底在哪里，短板有没有补上

光看架构没意思，最终还是要落到实际能力上。我整理了官方发布的基准数据，加上自己实测的一些结果，分四个维度说。

2.1 综合基准：从开源第二梯队到第一梯队头部

先给一个整体定位：Hy3在295B这个量级里是性价比很高的模型，但综合能力和旗舰模型还有明显差距；Hy4 Preview直接摸到了开源模型的第一梯队头部，和GLM-5.3、DeepSeek V4 Pro、Qwen 3.8 Max处于同一水平线。

根据官方发布的盲测结果，Hy4 Preview的平均得分2.99，对比GLM-5.3的2.92和Kimi K3的2.94，胜率分别是46.8%和51.2%。这个成绩是什么概念？放在半年前，开源模型和闭源旗舰的差距大概是0.5分以上，现在已经缩小到0.1分以内了。

纵向对比的话，Hy3到Hy4的提升主要集中在工程和Agent能力上，纯推理类的提升相对小一些。这也符合腾讯的产品定位------这代模型就是冲着生产力去的，不是为了刷数学榜。

2.2 长上下文能力：256K到1M不只是数字游戏

长上下文是Hy4最大的卖点之一，但我要先泼一盆冷水：1M上下文的真正难点从来都不是"装得下"，而是"找得到"和"用得对" 。

很多模型宣称支持几十K上百K上下文，但实际用起来，关键信息放中间就找不到了，或者前面的指令到后面就忘了。这就是"大海捞针"问题------上下文越长，信息密度越低，注意力越容易分散。

Hy3的256K上下文其实已经做得不错了，在200K左右的位置召回率还能保持在90%以上，属于国产模型里的第一梯队。但到了256K的边界，性能下降就比较明显了。

Hy4的1M上下文，靠的就是前面说的Gated DSA机制。稀疏注意力本身很容易出现"漏检"，但加了门控之后，模型可以自己判断什么时候需要稠密计算。在实际的大海捞针测试中，Hy4在800K位置的关键信息召回率依然能保持在85%以上，这个表现是优于很多同级别1M上下文模型的。

实际使用场景下，1M上下文能做什么？

直接载入整个中型代码仓库（大概10-20万行代码）做全仓理解和重构
一次性处理上百份财务报表或者法律文档，做跨文档对比分析
超长日志的全量排查，不需要分段截断
完整的游戏剧本、小说创作，全程保持人设和剧情连贯

但有一点要提醒：1M上下文的Prefill时间和内存占用还是很可观的。不要什么场景都往1M塞，大部分日常任务256K甚至32K就足够了。长上下文是底牌，不是常态。

2.3 代码与Agent能力：提升最明显的生产力赛道

这是Hy4提升最大的领域，也是和Hy3拉开差距的核心赛道。

先看官方数据：

DeepSWE：Hy3 28.0分 → Hy4 64.3分，提升了一倍还多
SWE-Marathon：Hy3 5.0分 → Hy4 31.9分，涨了6倍多

这两个都是代码Agent基准，不是简单的刷题，而是模拟真实的软件开发流程：给一个代码仓库和一个Issue，让模型自己读代码、改代码、跑测试、提交PR。SWE-Marathon更是长流程多步任务，需要连续几十步甚至上百步的正确操作才能完成。

Hy3在这个项目上其实已经不算弱了，在同参数级模型里是第一梯队，但和顶级模型比差距很大。Hy4直接把这个短板补上了，目前在开源模型里属于第一梯队的水平。

为什么提升这么大？我分析有三个原因：

架构层面：iHC多残差流更适合处理多步推理任务，每一步的中间状态都能被不同的通路保存下来
数据层面：腾讯本身有海量的真实软件开发数据，加上CodeBuddy产品的反馈闭环，训练数据质量很高
后训练层面：这代模型做了大量的Agent能力对齐，包括工具调用、自我纠错、流程规划

我自己用实际项目测了一下：把一个中等规模的Spring Boot项目（大概3万行代码）整个丢进去，让它做一个功能迁移，从Redis迁移到MongoDB。Hy3大概能完成60%的工作量，核心逻辑能写对，但配置文件、异常处理、边缘案例经常漏。Hy4大概能完成90%以上，不仅代码逻辑对，连依赖版本、配置类、单元测试都能一起改完，最后还会给你一个迁移检查清单。

这个差距是本质性的。Hy3是"辅助写代码"，你得告诉它每一步怎么做；Hy4是"接手做任务"，你只要说清楚目标，它自己拆分步骤执行。

2.4 推理与数学：有进步但仍非强项

数学和纯推理是Hy3的传统短板，MathArena Apex只有38.7分，和第一梯队差了一倍。Hy4在这方面有进步，但依然不是它的强项。

从目前的评测数据看，Hy4在中等难度数学题上表现不错，高考难度的题目正确率大概在80%左右，但竞赛级别的难题还是不行。和DeepSeek V4 Pro这种专门主打推理的模型比，还有明显差距。

原因也很直观：技术路线不同。DeepSeek走的是"超大规模MoE+深度推理优化"路线，光推理相关的后训练数据就有几万亿Token；腾讯走的是"产品驱动+生产力优先"路线，资源更多倾斜在工程、Agent、多模态这些和产品结合紧密的方向。

所以选型的时候要想清楚：如果你的场景主要是数学证明、科学计算、复杂逻辑推理，优先考虑DeepSeek或者GLM；如果主要是软件开发、办公自动化、业务流程处理，Hy4会更顺手。

2.5 推理速度与成本：激活参数翻倍，但单位成本没涨多少

很多人看到49B激活参数，第一反应是"推理成本是不是也翻倍了？"其实没有。

先看纯理论计算：Hy3激活21B，Hy4激活49B，看起来是2.3倍。但Hy4用了DSA稀疏注意力，注意力部分的计算量反而下降了，尤其是长上下文场景。实际推理中，短上下文下Hy4的单Token计算量大概是Hy3的1.8-2倍，长上下文下反而可能更少。

再看API定价：腾讯云TokenHub上，Hy4的价格是输入百万，输出2.501 / 百万Token。作为对比，Hy3的价格大概是输入百万，输出1.2 / 百万Token。价格涨了一倍左右，但能力涨得更多，尤其是工程和长上下文能力。

如果是自部署的话，成本主要在显存。Hy3 BF16精度需要大概590GB显存，推荐8张H20-3e；Hy4 BF16需要大概1.5TB显存，推荐16张H20-3e或者8张更大显存的卡。如果用FP8量化，显存需求可以减半。

三、工程落地：从环境搭建到生产部署的完整指南

讲完了理论，说点实际的。很多人看了参数就想上手，但真要部署起来还是有不少坑。我把两代模型的部署方法、硬件需求、常见坑都整理出来。

3.1 硬件需求参考

先给大家一个直观的硬件门槛，都是实际测过的可行配置：

模型	精度	最低显存需求	推荐配置	推理速度（约）
Hy3	BF16	~590GB	8×H20-3e (8×80GB)	30-40 tok/s
Hy3	FP8	~300GB	4×H20-3e / 8×RTX 4090	40-50 tok/s
Hy3	Q4_K_M	~150GB	2×A6000 / 4×RTX 4090	20-30 tok/s
Hy4 Preview	BF16	~1540GB	16×H20-3e / 8×H100	25-35 tok/s
Hy4 Preview	FP8	~770GB	8×H20-3e / 4×H100	30-40 tok/s
Hy4 Preview	Q4_K_M	~400GB	4×A6000 / 8×RTX 4090	15-25 tok/s

几点说明：

速度是批量大小为1的交互式场景速度，批量大了吞吐量会更高
开启MTP投机解码后，生成速度还能再提升30%-50%
1M上下文满载的时候，KV缓存会额外占用不少显存，建议预留20%以上的余量
消费级卡能跑，但因为PCIE带宽问题，多卡并行效率不高，适合开发测试，不适合生产

3.2 Transformers 原生调用

最简单的方式是直接用HuggingFace Transformers加载，版本要求5.6.0以上。

Hy3 基础调用示例：

ini 复制代码

from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

# 加载模型和分词器
model_name = "tencent/Hy3"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype=torch.bfloat16,
    device_map="auto",
    trust_remote_code=True
)

# 对话格式
messages = [
    {"role": "system", "content": "你是一个资深Java架构师，回答问题要专业且简洁。"},
    {"role": "user", "content": "解释一下Spring Boot的自动配置原理，以及如何实现一个自定义starter。"}
]

# 应用对话模板并生成
inputs = tokenizer.apply_chat_template(
    messages,
    add_generation_prompt=True,
    tokenize=True,
    return_dict=True,
    return_tensors="pt"
).to(model.device)

outputs = model.generate(
    **inputs,
    max_new_tokens=2048,
    temperature=0.7,
    top_p=0.9,
    do_sample=True
)

response = tokenizer.decode(outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True)
print(response)

Hy4 Preview 调用注意事项：

Hy4的调用方式和Hy3基本一致，模型名换成tencent/Hy4-preview或者tencent/Hy4-preview-FP8即可。但有几个特殊参数需要注意：

ini 复制代码

# 启用稀疏注意力加速（需要对应flash-attention版本支持）
model = AutoModelForCausalLM.from_pretrained(
    "tencent/Hy4-preview-FP8",
    torch_dtype=torch.bfloat16,
    device_map="auto",
    trust_remote_code=True,
    attn_implementation="flash_attention_2",
    # 稀疏注意力相关配置
    sparse_attention=True,
    index_cache=True
)

如果你的环境不支持稀疏注意力，也可以关闭，退化为标准稠密注意力，但速度会慢很多，而且长上下文下可能OOM。

3.3 vLLM 生产部署

生产环境强烈推荐用vLLM，吞吐量比原生Transformers高好几倍，而且原生支持MTP投机解码。

Hy3 vLLM 启动命令：

css 复制代码

vllm serve tencent/Hy3 \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 262144 \
  --speculative-config.method mtp \
  --speculative-config.num_speculative_tokens 1 \
  --tool-call-parser hy_v3 \
  --reasoning-parser hy_v3 \
  --enable-auto-tool-choice \
  --served-model-name hy3

Hy4 Preview vLLM 启动命令：

css 复制代码

vllm serve tencent/Hy4-preview-FP8 \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 1000000 \
  --speculative-config '{"num_speculative_tokens":3,"method":"mtp"}' \
  --attention-backend FLASHMLA_SPARSE \
  --tool-call-parser hy_v4 \
  --reasoning-parser hy_v4 \
  --enable-auto-tool-choice \
  --served-model-name hy4-preview

几个关键参数解释：

--speculative-config.method mtp：启用原生MTP投机解码，这是Hy系列的专属加速
--attention-backend FLASHMLA_SPARSE：启用稀疏注意力后端，跑长上下文必须开
--tool-call-parser和--reasoning-parser：用官方的解析器，工具调用和思考过程的格式会更准

部署完之后就可以用OpenAI兼容的API调用了，无缝替换现有系统。

3.4 量化方案与精度损失

对于大部分生产场景，FP8量化是性价比最高的选择。官方直接提供了FP8版本的权重（tencent/Hy4-preview-FP8），是训练后量化的，不是事后量化的，精度损失极小，基本可以忽略。

如果显存还是不够，可以考虑Q4_K_M量化，用llama.cpp或者Ollama都可以。但要注意：

MoE模型的量化和稠密模型不一样，专家部分的量化对精度影响更大
Q4级别下，代码和推理能力会有可感知的下降，大概5%-10%
共享专家建议用更高精度，路由专家可以量化得狠一点

我的经验是：开发测试环境用Q4没问题，生产环境优先FP8，实在不行再考虑Q4。不要为了省显存用Q2，效果崩得妈都不认。

3.5 常见部署坑点

trust_remote_code必须开：两代模型都有自定义的模型代码，不开加载不了。这也是为什么不能随便用不知名第三方仓库的模型，远程代码是有安全风险的。
分词器的特殊标记 ：Hy系列的思考标记、工具调用标记都是自定义的，不要自己硬拼接字符串，一定要用apply_chat_template。
长上下文的Prefill阶段：1M上下文的Prefill需要很长时间，而且很吃显存。如果你的场景经常需要超长输入，建议用分批Prefill或者流式输入。
MoE的负载均衡：自部署的时候，如果请求分布很偏，可能出现部分专家过载、部分专家空闲的情况。高并发场景建议开启动态负载均衡路由。
MTP和采样参数的冲突：开了MTP之后，temperature太低或者greedy采样的时候，投机命中率会下降，加速效果不明显。一般0.5-0.8的温度下MTP效果最好。

四、选型建议与实际应用场景

4.1 什么时候选Hy3

不要觉得新的就一定好，Hy3在很多场景下依然是更优选择：

成本敏感的生产环境：Hy3的推理成本差不多是Hy4的一半，如果你的任务难度不高，比如客服问答、文档摘要、简单代码生成，Hy3完全够用，性价比更高。
部署资源有限：只有4-8张消费级卡，Hy3 FP8能跑得很流畅，Hy4就很勉强。
中等上下文场景：大部分业务场景32K-64K就足够了，最多128K。这种情况下Hy3的表现和Hy4差距不大，没必要为了用不上的1M上下文多花钱。
稳定优先的场景：Hy3已经发布了几个月，经过了大量生产验证，坑基本都踩完了。Hy4还是Preview版本，可能还有一些未发现的问题，核心业务谨慎直接上。
批量处理任务：比如批量文档处理、批量代码审查，对单Token速度不敏感，更看重总成本。Hy3的单位成本更低。

4.2 什么时候选Hy4 Preview

Hy4适合对能力有要求、愿意为效果付费的场景：

复杂软件开发与Code Review：全仓代码理解、大型重构、深度调试、架构设计。这些场景下Hy4的生产力提升是肉眼可见的，可能一天就能干完以前一周的活。
Agent与工具调用场景：多步工作流、复杂任务自动化、智能体开发。Hy4的规划能力和自我纠错能力比Hy3强一个档次，跑长流程不容易崩。
超长文档处理：整本书、全仓库、上百份合同的分析对比。只有1M上下文才能一次性装下，分段处理会丢失上下文。
多模态与复杂交互：虽然这次发布的是纯语言版，但Hy4的架构是为多模态设计的，后续多模态版本出来之后，能力会再上一个台阶。
技术预研与前沿探索：想跟进最新的模型技术，做二次开发或者垂直领域微调，直接上最新的架构，生命周期更长。

4.3 不推荐的场景

也说一下这两个模型都不擅长的场景，避免大家踩坑：

极致数学推理与科学计算：去用DeepSeek V4 Pro或者专门的数学模型，Hy系列不是干这个的。
极低延迟实时交互：比如实时对话、流式输出要求特别高的场景。MoE模型因为路由和专家切换，首Token延迟天生比稠密模型高一点。追求极致速度可以考虑Qwen或者GLM的小版本。
边缘设备部署：几百B的模型就别想着往边缘塞了，老老实实调用API或者用小模型。
极低资源场景：只有一两张卡的话，还是考虑7B/14B级别的模型吧。MoE模型再怎么量化，总参数量摆在那里，显存下限比同能力的稠密模型高。

五、行业观察与我的观点

最后说点我自己的思考，不一定对，供大家参考。

5.1 开源模型正在快速吞噬闭源的领地

Hy4 Preview发布之后，开源模型和闭源旗舰的差距又缩小了一块。一年前，开源模型和GPT-4的差距大概是两年；现在，最新的开源模型和GPT-5/Claude Opus的差距大概是半年到一年，而且还在缩小。

更关键的是，开源模型正在形成自己的优势：

可以私有化部署，数据不出去
可以自由微调，适配垂直场景
成本更低，量大了之后优势明显
透明可控，不会突然改API或者涨价

对于大部分企业场景，现在开源模型已经完全够用了。甚至在一些特定领域，经过微调的开源模型效果比通用闭源模型还好。

5.2 MoE已经成为旗舰模型的标准配置

两年前大家还在争论MoE到底行不行，现在已经没有悬念了：所有旗舰模型都是MoE架构。稠密模型最多做到几百B，再往上成本就扛不住了。MoE是目前唯一能在可控成本下把模型能力推到旗舰级别的技术路线。

但MoE也不是银弹。它的工程复杂度比稠密模型高一个数量级：路由算法、负载均衡、专家并行、量化策略，每一个都是坑。能把大MoE模型跑稳、跑快，本身就是很强的工程能力。

腾讯这两代MoE模型的演进，能看出来工程能力在快速成熟。Hy3的时候还有一些小问题，比如路由抖动、长上下文不稳定；到Hy4，整个架构已经相当扎实了。

5.3 长上下文的下一个瓶颈是"有效使用"

现在大家都在比谁的上下文长，你1M我2M他4M。但我认为，长上下文的竞赛很快就会遇到边际效应递减。

当上下文足够大之后，核心矛盾就从"能不能装下"变成了"能不能有效利用"。给你1M上下文，但模型只能有效利用前100K和后100K，中间的都找不到，那又有什么用呢？

所以接下来的竞争点，会从"上下文长度"转向"上下文有效利用率"。稀疏注意力、记忆机制、信息组织结构，这些会成为新的技术战场。Hy4的Gated DSA其实就是在往这个方向走，不是一味堆长度，而是保证长上下文下的实际效果。

5.4 生产力模型正在成为新的赛道

之前大家都在比通用能力、比跑分。从Hy3开始，腾讯走出了一条不一样的路：主打生产力，和自己的产品深度结合，用真实场景的反馈来迭代模型。

Hy4更是把这个路线贯彻到底了。你看它提升最大的地方：代码、Agent、长文档处理，全都是生产力场景。它不是为了在榜单上拿第一而生的，是为了让程序员、白领、分析师真的能用它干活而生的。

我觉得这是一个好现象。大模型最终还是要落地到具体的工作中，创造实际价值。跑分再高，干活不行，那就是玩具。

5.5 给开发者的建议

几点实际建议：

不要盲目追新：模型更新太快了，不可能每个都跟。先搞清楚自己的业务需求是什么，再选最合适的模型。Hy3足够用的话，没必要急着升Hy4。
建立模型评估体系：不要光看公开榜单，一定要用自己的业务数据测。同一个模型，在A场景好用，在B场景可能一塌糊涂。建立自己的评测集，比什么都重要。
重视工程优化：模型本身的能力只是基础，工程优化能带来的提升可能比模型升级还大。投机解码、量化、缓存、批处理，每一项做好了都能降本增效。
关注架构演进：不要只会调用API，了解底层架构很重要。同样是MoE，不同的实现差异很大。理解了底层原理，才能更好地选型和调优。
保持理性预期：大模型不是万能的。它能极大提升效率，但不能完全替代人。尤其是复杂决策、创造性工作，还是要人来拍板。把它当成一个超强的助手，而不是替代品。

写在最后

从Hy3到Hy4 Preview，我们能看到腾讯混元团队的技术迭代速度和工程落地能力。这不是简单的参数堆砌，而是从注意力机制到残差结构的全面架构升级，再配合大规模高质量数据训练，最终落地到真实生产力场景。对于开发者来说，这是最好的时代。几年前想都不敢想的百亿千亿级模型，现在可以免费下载、本地部署、随意修改。技术的门槛在快速降低，真正的壁垒变成了对业务的理解、对场景的把握、对工程的打磨。Hy4 Preview还只是一个预览版，正式版应该还会有提升。但即使是现在这个版本，也已经足够强大了。如果你还没试过，强烈建议动手跑一跑，亲自感受一下开源旗舰模型的实力。

技术在进步，我们也得跟着进步。共勉。