腾讯混元Hy4 Preview深度技术解析:770B MoE、递归自我改进与国产大模型闪电战
一、引言:770B 的"生产力宣言"
2026年8月28日,腾讯混元正式发布并开源了新一代大语言模型 Hy4 preview。这是一款总参数达 770B(7700亿)、每 token 激活 49B(490亿)的 MoE 架构模型,原生支持 1M 上下文窗口,采用 Apache 2.0 协议开放 BF16 和 FP8 权重。发布当天,vLLM 和 SGLang 即推出官方部署镜像,昇腾、燧原等国产芯片实现 0day 适配——这一连串动作释放了一个清晰的信号:腾讯正在以"月度"级别的迭代节奏,全力杀入开源大模型的头部阵营。
同日,阿里通义千问发布 Qwen3.8-Flash,智谱开源 GLM-5.3-Flash。三款模型同日登场,不是巧合。国产大模型的竞争已经从"年会发布"进化到"周更时代"。
Hy4 preview 的定位非常明确:为生产力而生。它不追求通用对话的全能,而是锚定代码工程、办公分析、游戏开发、科学研究四大场景,深度联动 WorkBuddy、CodeBuddy、元宝、ima 等腾讯产品矩阵。在腾讯内部组织的 163 名专家、203 项工程任务盲测中,Hy4 preview 以 2.99/4.00 的均分略超 GLM-5.3(2.92)和 Kimi K3(2.94),在 DeepSWE 基准上更是以 64.3 分超越了 DeepSeek V4 Pro 的 62.7。
但真正让技术社区兴奋的,不是这些数字——而是 Hy4 preview 首次参与了自身的研发过程,形成了"递归自我改进闭环"的雏形。本文将深入拆解其技术架构、核心创新与行业影响。
二、MoE 架构深度解析:256 专家路由与共享专家机制
2.1 整体架构一览
Hy4 preview 的主干由 78 层 Transformer 组成,其中第 1 层为标准密集 FFN(Dense Feed-Forward Network),后 77 层为 MoE 层。每一层 MoE 包含 256 个路由专家 + 1 个共享专家,每 token 激活 Top-8 路由专家 + 共享专家,即每层实际激活 9 个专家。
输入 Token 序列
│
▼
┌─────────────────────────────────┐
│ Layer 1: Dense FFN │
│ (标准前馈网络,无 MoE 路由) │
└──────────────────┬──────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ Layer 2-78: MoE (每层 256 路由 + 1 共享专家) │
│ │
│ ┌─────── Router ───────┐ │
│ │ Top-8 选择 │ │
│ └──┬───┬───┬───┬───┬──┘ │
│ │ │ │ │ │ │
│ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──────┐ │
│ │E1│ │E3│ │E7│...│E8│ │E │ │Shared│ │
│ └──┘ └──┘ └──┘ └──┘ └──┘ │Expert│ │
│ Top-8 路由专家 └──────┘ │
│ │
│ 输出 = Σ(Top-8 路由专家输出) + 共享专家输出 │
└──────────────────┬───────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ MTP Layer (10B 总参 / 0.7B 激活) │
│ 多 token 预测 → 投机解码加速 │
└──────────────────┬───────────────────────────────────┘
│
▼
输出 Token 序列
2.2 路由机制与负载均衡
Hy4 preview 的门控路由(Gating Router)本质上是一个可学习的线性变换加 Softmax 归一化。每个 token 的 hidden state 通过路由网络计算出与 256 个专家的亲和度分数,然后取 Top-8 激活。其核心实现可抽象为:
import torch
import torch.nn.functional as F
class MoERouter(torch.nn.Module):
"""Hy4 preview 风格的 MoE 路由模块"""
def __init__(self, hidden_size: int, num_experts: int = 256, top_k: int = 8):
super().__init__()
self.num_experts = num_experts
self.top_k = top_k
# 路由网络:线性投影 + 可选激活
self.gate = torch.nn.Linear(hidden_size, num_experts, bias=False)
def forward(self, x: torch.Tensor):
# x: (batch_size, seq_len, hidden_size)
# 计算路由分数
scores = self.gate(x) # (batch, seq, num_experts)
# 可选:添加负载均衡噪声(训练时)
if self.training:
noise = torch.randn_like(scores) * 0.01
scores = scores + noise
# Top-8 选择
top_k_weights, top_k_indices = torch.topk(
F.softmax(scores, dim=-1),
k=self.top_k,
dim=-1
)
return top_k_weights, top_k_indices, scores
2.3 共享专家的设计意图
共享专家是 Hy4 preview 相比传统 MoE 的一个重要设计差异。传统 MoE 中,每个 token 仅激活路由专家,不同专家之间可能存在"信息孤岛"——某些通用知识(如语法规则、常见模式)被分散到多个专家中,导致专家利用率不均衡。共享专家作为一个始终激活的公共通道,负责承载对所有 token 都通用的信息,从而:
- 降低路由负担:通用知识由共享专家统一处理,路由专家可以更专注于细分领域
- 减少专家倾覆(Expert Collapse):共享专家吸收了基础模式,降低某些路由专家因负载不足而退化
- 提升推理效率:共享专家的输出可以预计算缓存,减少动态路由的计算开销
class MoELayer(torch.nn.Module):
"""Hy4 preview 单层 MoE 实现"""
def __init__(self, hidden_size: int, moe_intermediate_size: int = 2048,
num_experts: int = 256, top_k: int = 8):
super().__init__()
self.router = MoERouter(hidden_size, num_experts, top_k)
# 256 个路由专家
self.experts = torch.nn.ModuleList([
ExpertFFN(hidden_size, moe_intermediate_size)
for _ in range(num_experts)
])
# 1 个共享专家(始终激活)
self.shared_expert = ExpertFFN(hidden_size, moe_intermediate_size)
def forward(self, x: torch.Tensor):
batch, seq, hidden = x.shape
# 共享专家输出(始终计算)
shared_output = self.shared_expert(x)
# 路由专家选择
top_k_weights, top_k_indices, _ = self.router(x)
# 稀疏激活:仅计算选中的专家
# 实际实现中会使用并行 dispatch 机制
routed_output = torch.zeros_like(x)
for b in range(batch):
for s in range(seq):
for k in range(self.router.top_k):
expert_idx = top_k_indices[b, s, k]
weight = top_k_weights[b, s, k]
expert_out = self.experts[expert_idx](x[b:b+1, s:s+1])
routed_output[b, s] += weight * expert_out[b, 0]
# 路由专家 + 共享专家输出合并
return routed_output + shared_output
2.4 参数规模与激活比
Hy4 preview 的参数规模非常"经济":770B 总参数下仅激活 49B,激活比约 6.36%。相比之下,同级别的稠密模型要达到同等能力需要完整激活全部参数,推理成本呈线性增长。MoE 架构的"大库小用"是其将 API 价格压到输入 6 元/百万 token 的核心原因。
| 模型 | 总参数 | 激活参数 | 激活比 | 上下文 |
|---|---|---|---|---|
| Hy3 | 295B | 21B | 7.1% | 256K |
| Hy4 preview | 770B | 49B | 6.4% | 1M |
| GLM-5.3 | 753B | 40B | 5.3% | 1M |
| DeepSeek V4 Pro | 1.2T+ | ~60B | ~5% | 1M |
三、Gated DSA 稀疏注意力与 IndexCache:1M 上下文的工程密码
3.1 长上下文的核心挑战
1M 上下文意味着模型需要同时关注 100 万个 token 之间的相互关系。标准 Full Attention 的计算复杂度为 O(n²),当 n = 1M 时,单次前向传播的注意力计算量达到 10¹² 次量级,这在实际推理中是不可接受的。
Hy4 preview 采用了 Gated DeepSeek Sparse Attention (Gated DSA) 来解决这一问题。
3.2 Gated DSA 的工作原理
标准 Attention(稠密):
Q · K^T → 所有位置 → 计算量 O(n²)
Gated DSA(稀疏):
Q · K_idx^T → 仅 Top-k 位置 → 计算量 O(n·k),k << n
Step 1: 通过 Indexer 为每个 query 选择 Top-k 相关 key 位置
Step 2: 仅在选中的 k 个位置上计算注意力
Step 3: 通过门控机制(Gating)调节稀疏注意力与全局信息的融合
Gated DSA 的核心思路是:先筛选,再计算。它通过一个轻量级的 Indexer 网络,从全部 key 中选出与当前 query 最相关的 k 个位置(k = 2048),然后只在这 k 个位置上执行标准注意力计算。这将 O(n²) 的复杂度降低到 O(n·k),在 1M 上下文下节省约 500 倍计算量。
import torch
import torch.nn.functional as F
class GatedDSA(torch.nn.Module):
"""Gated DeepSeek Sparse Attention 简化实现"""
def __init__(self, hidden_size: int = 6144, num_heads: int = 64,
num_indexer_heads: int = 32, top_k: int = 2048):
super().__init__()
self.num_heads = num_heads
self.num_indexer_heads = num_indexer_heads
self.top_k = top_k
self.head_dim = hidden_size // num_heads
# QKV 投影
self.q_proj = torch.nn.Linear(hidden_size, hidden_size)
self.k_proj = torch.nn.Linear(hidden_size, hidden_size)
self.v_proj = torch.nn.Linear(hidden_size, hidden_size)
# 查询压缩 (query → 2048 维)
self.q_compress = torch.nn.Linear(hidden_size, 2048)
# KV 压缩 (key/value → 512 维)
self.kv_compress = torch.nn.Linear(hidden_size, 512)
# Indexer: 32 头, 每头 128 维
self.indexer = torch.nn.Linear(2048, num_indexer_heads * 128)
self.indexer_top_k = top_k # 索引器选择 top-2048
# 门控网络
self.gate = torch.nn.Sequential(
torch.nn.Linear(self.head_dim, 1),
torch.nn.Sigmoid()
)
def forward(self, x: torch.Tensor, index_cache=None):
batch, seq, _ = x.shape
# 标准 QKV 投影
q = self.q_proj(x)
k = self.k_proj(x)
v = self.v_proj(x)
# 查询压缩用于索引
q_compressed = self.q_compress(x) # (batch, seq, 2048)
# 索引器:生成稀疏注意力索引
indexer_out = self.indexer(q_compressed)
# 使用 index_cache 或重新计算
if index_cache is not None:
# 跨层复用索引
sparse_indices = index_cache
else:
# 计算当前层的稀疏索引
indexer_scores = torch.matmul(
indexer_out,
indexer_out.transpose(-2, -1)
)
_, sparse_indices = torch.topk(
indexer_scores,
k=self.indexer_top_k,
dim=-1
)
# 仅在选中的稀疏位置上计算注意力
# 实际实现中会使用 gather + flash attention 变体
k_sparse = torch.gather(
k.unsqueeze(1).expand(-1, self.num_heads, -1, -1),
dim=2,
index=sparse_indices.unsqueeze(-1).expand(-1, -1, -1, self.head_dim)
)
v_sparse = torch.gather(
v.unsqueeze(1).expand(-1, self.num_heads, -1, -1),
dim=2,
index=sparse_indices.unsqueeze(-1).expand(-1, -1, -1, self.head_dim)
)
# 稀疏注意力计算
attn_scores = torch.matmul(q.view(batch, -1, self.num_heads, self.head_dim).transpose(1, 2),
k_sparse.transpose(-2, -1)) / (self.head_dim ** 0.5)
attn_weights = F.softmax(attn_scores, dim=-1)
# 门控机制
gate_values = self.gate(
attn_weights.mean(dim=-1, keepdim=True)
)
attn_weights = attn_weights * gate_values
attn_output = torch.matmul(attn_weights, v_sparse)
attn_output = attn_output.transpose(1, 2).contiguous().view(batch, seq, -1)
return attn_output, sparse_indices
3.3 IndexCache:跨层稀疏索引复用
IndexCache 是 Gated DSA 的配套优化。在多层 Transformer 中,相邻层的注意力模式往往具有相似性——如果第 l 层认为位置 i 与位置 j 相关,第 l+1 层大概率也有类似的判断。IndexCache 将这一观察转化为工程实践:将前面层的稀疏索引缓存下来,后续层直接复用,避免每层重复计算昂贵的索引选择。
无 IndexCache:
Layer 2: 计算 Indexer → 选择 Top-2048 → 注意力计算
Layer 3: 计算 Indexer → 选择 Top-2048 → 注意力计算 (重复!)
Layer 4: 计算 Indexer → 选择 Top-2048 → 注意力计算 (重复!)
...
有 IndexCache:
Layer 2: 计算 Indexer → 选择 Top-2048 → 注意力计算
Layer 3: 复用 IndexCache → 注意力计算 (跳过!)
Layer 4: 复用 IndexCache → 注意力计算 (跳过!)
...
Layer N: 重新计算 Indexer → 更新 Cache → 注意力计算
这种"跳跃式复用"策略在长上下文场景下效果显著——每跳过一个索引计算层,就节省约 O(n·k) 的计算量,同时保持 99% 以上的注意力质量。
3.4 iHC 残差超连接
Hy4 preview 的另一个架构创新是 iHC(identity Hyper-Connections),它将标准的单条残差流扩展为 4 条并行残差流。这相当于在深层的 78 层网络中铺设了 4 条"信息高速公路",缓解了超深网络中的梯度弥散问题。
标准残差连接:
x_{l+1} = x_l + FFN(LN(x_l))
iHC (4 条残差流):
[x₁, x₂, x₃, x₄]_{l+1} = [x₁, x₂, x₃, x₄]_l + F([x₁, x₂, x₃, x₄]_l)
其中 F 是 Transformer 子层(注意力或 FFN),
输入为 4 条流的拼接,输出再分配到 4 条流
四、多 Token 预测(MTP)与投机解码加速
4.1 MTP 的原理
Hy4 preview 在主干之外内置了 1 层 MTP(Multi-Token Prediction)层,总参数 10B、激活 0.7B,专门用于投机解码(Speculative Decoding)。这是 Hy4 preview 区别于多数"事后外挂"投机解码方案的关键:MTP 是原生内置在权重中的,而非推理框架的附加组件。
投机解码的核心思想是"以小博大":用一个轻量级草稿模型快速生成多个候选 token,然后用主模型并行验证这些 token 的正确性。如果草稿命中率高,就可以一次验证确认多个 token,大幅提升解码吞吐。
标准自回归解码(逐个 token):
Token 1 → Token 2 → Token 3 → Token 4 → ... (每步 1 次前向)
MTP 投机解码(批量验证):
Draft: [Token 2, Token 3, Token 4] (草稿预测)
Verify: 并行验证 3 个 token (1 次前向)
Accept: [Token 2 ✓, Token 3 ✓, Token 4 ✗]
→ 一次确认 2 个 token,回退到 Token 3 重新生成
4.2 MTP 采样实现
import torch
import torch.nn.functional as F
class MTPDecoder:
"""Hy4 preview 内置 MTP 投机解码"""
def __init__(self, main_model, mtp_module,
num_speculative_tokens: int = 3):
self.main_model = main_model
self.mtp_module = mtp_module # 10B 参数 / 0.7B 激活
self.num_speculative_tokens = num_speculative_tokens
@torch.no_grad()
def generate(self, input_ids: torch.Tensor, max_new_tokens: int = 1024):
generated = input_ids.clone()
prompt_len = input_ids.shape[1]
while generated.shape[1] - prompt_len < max_new_tokens:
# Step 1: 使用 MTP 模块生成草稿 token
draft_tokens = self._draft(generated)
# Step 2: 主模型并行验证草稿
accepted = self._verify(generated, draft_tokens)
# Step 3: 接受通过验证的 token
generated = torch.cat([generated, accepted], dim=-1)
return generated
def _draft(self, context: torch.Tensor) -> torch.Tensor:
"""MTP 草稿生成:预测后续 num_speculative_tokens 个 token"""
drafts = []
current = context
for _ in range(self.num_speculative_tokens):
# MTP 前向传播(轻量级)
logits = self.mtp_module(current)
next_token = self._sample(logits[:, -1, :])
drafts.append(next_token)
current = torch.cat([current, next_token], dim=-1)
return torch.cat(drafts, dim=-1)
def _verify(self, context: torch.Tensor,
drafts: torch.Tensor) -> torch.Tensor:
"""主模型并行验证草稿 token"""
# 拼接上下文和草稿
full_input = torch.cat([context, drafts], dim=-1)
# 主模型单次前向(并行计算所有位置)
main_logits = self.main_model(full_input)
# 验证每个草稿位置
accepted = []
for i in range(drafts.shape[1]):
draft_token = drafts[:, i:i+1]
target_logits = main_logits[:, context.shape[1] + i, :]
target_probs = F.softmax(target_logits, dim=-1)
# 拒绝采样:使用草稿分布 vs 目标分布
draft_prob = target_probs.gather(-1, draft_token)
accept_prob = torch.min(
torch.ones_like(draft_prob),
draft_prob / (draft_prob + 1e-8)
)
if torch.rand(1) < accept_prob:
accepted.append(draft_token)
else:
# 从修正后的分布重新采样
adjusted_probs = F.softmax(target_logits, dim=-1)
# 减去草稿分布中的概率进行修正
corrected = F.relu(adjusted_probs - draft_prob * adjusted_probs)
corrected = corrected / corrected.sum(dim=-1, keepdim=True)
resampled = torch.multinomial(corrected, 1)
accepted.append(resampled)
break
return torch.cat(accepted, dim=-1) if accepted else drafts[:, :1]
@staticmethod
def _sample(logits: torch.Tensor, temperature: float = 0.9):
probs = F.softmax(logits / temperature, dim=-1)
return torch.multinomial(probs, 1)
4.3 部署配置
在 vLLM 中启用 MTP 投机解码:
# 官方 vLLM 部署命令(8 卡张量并行)
docker run --gpus all \
-p 8000:8000 \
--ipc=host \
-v ~/.cache/huggingface:/root/.cache/huggingface \
vllm/vllm-openai:hy4-preview \
tencent/Hy4-preview-FP8 \
--tensor-parallel-size 8 \
--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 \
--port 8000 \
--served-model-name hy4-preview
# SGLang 部署命令
docker run --gpus all --ipc=host -p 8000:8000 \
lmsysorg/sglang:hy4-preview \
python3 -m sglang.launch_server \
--model tencent/Hy4-preview-FP8 \
--tp-size 8 \
--reasoning-parser auto \
--tool-call-parser auto \
--speculative-algorithm NEXTN \
--speculative-num-steps 3 \
--speculative-eagle-topk 1 \
--speculative-num-draft-tokens 4 \
--port 8000 \
--served-model-name hy4-preview
五、递归自我改进闭环:模型开始"造自己"
5.1 从"用 AI 写代码"到"AI 优化 AI"
Hy4 preview 最具前瞻性的突破,不是参数规模或跑分,而是它首次参与了自身的研发全链路。腾讯官方披露,Hy4 preview 在以下环节实现了自动优化参与:
- 训练方法优化:模型提出候选训练策略,运行对比实验,评估效果
- 数据策略优化:模型分析数据分布,提出采样策略调整方案
- 评估体系优化:模型参与设计评测方案,识别评估盲区
- 底层算子优化:模型分析推理系统的算子瓶颈,提出算子融合方案
递归自我改进闭环流程图:
┌───────────────┐
│ 提出方案 │
│ Hy4 preview │
│ 自动生成 │
└───────┬───────┘
│
▼
┌───────────────┐
│ 运行实验 │
│ (Codex Session│
│ 并行执行) │
└───────┬───────┘
│
▼
┌───────────────┐
│ 读取结果 │
│ 分析日志 │
│ 比较指标 │
└───────┬───────┘
│
┌───────┴───────┐
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ 方案有效 │ │ 方案无效 │
│ 纳入下一轮 │ │ 分析失败原因│
└──────┬──────┘ └──────┬──────┘
│ │
└───────┬───────┘
│
▼
┌───────────────┐
│ 代码/日志/ │
│ 反馈回流 │
│ 进入下一轮 │
└───────────────┘
5.2 推理系统自优化:31.8% 的吞吐提升
最具体的成果体现在推理基础设施的自主优化上。Hy4 preview 通过自主分析推理系统瓶颈,围绕算子融合和通信优化开展多轮优化,端到端吞吐量相比基线提升了 31.8%,且在不同上下文长度(4K-256K)和并发度(1-64)下均获得稳定收益。
# 抽象描述 Hy4 preview 的推理系统自优化流程
class InferenceOptimizer:
"""Hy4 preview 自主推理优化框架"""
def analyze_bottleneck(self, profile_data: dict) -> str:
"""分析推理 profile 数据,识别瓶颈"""
# 分析各算子的耗时占比
op_times = profile_data['op_times']
# 识别通信开销
comm_overhead = profile_data['communication_latency']
# 识别显存瓶颈
memory_bandwidth = profile_data['memory_bandwidth_util']
if op_times['attention'] > 0.4 * sum(op_times.values()):
return 'attention_is_bottleneck'
elif comm_overhead > 0.3 * profile_data['total_time']:
return 'communication_is_bottleneck'
elif memory_bandwidth < 0.5:
return 'memory_bound'
else:
return 'compute_bound'
def propose_optimization(self, bottleneck: str) -> dict:
"""根据瓶颈类型提出优化方案"""
optimizations = {
'attention_is_bottleneck': {
'action': 'fuse_attention_ops',
'target': '将 QKV 投影 + 注意力计算 + 输出投影融合为单个 kernel',
'expected_gain': '0.15-0.25'
},
'communication_is_bottleneck': {
'action': 'optimize_allreduce',
'target': '使用 AllReduce 合并 + 异步通信隐藏传输延迟',
'expected_gain': '0.10-0.20'
},
'memory_bound': {
'action': 'kv_cache_compression',
'target': '对 KV cache 进行低精度量化 + 稀疏化存储',
'expected_gain': '0.20-0.35'
},
'compute_bound': {
'action': 'tensor_parallel_resharding',
'target': '调整张量并行策略,减少计算倾斜',
'expected_gain': '0.05-0.15'
}
}
return optimizations.get(bottleneck, {})
def run_experiment(self, optimization: dict) -> dict:
"""运行优化实验,返回结果"""
# 实现优化方案
# 运行基准测试
# 收集性能数据
return {
'throughput_gain': 0.318,
'latency_reduction': 0.24,
'memory_saved_gb': 12.5,
'stability': 'consistent_across_context_lengths'
}
5.3 科学发现中的自我进化
Hy4 preview 在科研领域的表现更加令人印象深刻:
- 分子动力学模拟:配合 Hyra,32,512 原子磷脂双分子层 SO3LR 模拟,在已高度优化的 JAX 实现上再提速 2.0×,达 54.9 ms/step,单张高端 GPU 可容纳 30 万原子
- 低温量子输运器件设计:自主完成量子散射求解器构建、五势垒结构稳健优化,高能阻带平均泄漏率从 48.2% 降到 4.8%
- 三维 Blaschke–Lebesgue 问题(百年经典几何难题):体积下界从 0.380799 推进到 0.41104,Meissner 四面体猜想上界 0.41986,只剩约 2% 的 gap
六、生产力场景实测:4 大场景的工程验证
6.1 软件工程
Hy4 preview 在软件工程场景的基准测试中表现尤为突出:
| 基准 | Hy3 | Hy4 preview | 提升 |
|---|---|---|---|
| Terminal Bench 2.1 | 70.8 | 85.4 | +14.6 |
| DeepSWE | 28.0 | 64.3 | +36.3 (翻倍) |
| SWE Atlas Refactoring | 32.9 | 53.3 | +20.4 |
| APEX-Agents (pass@1) | — | 37.1 | 新基准 |
DeepSWE 从 28.0 跃升至 64.3(翻倍以上),超越 DeepSeek V4 Pro 的 62.7,说明 Hy4 preview 在长代码库环境下的综合工程能力有了质的飞跃。
6.2 办公分析
在办公场景下,Hy4 preview 支持一次性处理 72 份文件并判断发票合规性,从规章制度中找出仍在生效的条款,完成从信息处理到文档、表格、演示文稿交付的完整工作流。OfficeQA Pro 得分 66.2,体现了跨文件协作和长文档理解的能力。
6.3 游戏开发
Hy4 preview 支持"一句话生成可玩原型"——通过自然语言描述即可生成一个可交互的游戏原型,并能通过 MCP 协议接入 Unreal Engine 5 等主流游戏引擎,在多轮对话中持续迭代。
6.4 科学研究
除了前述的分子动力学、量子输运和数学问题,Hy4 preview 在 GPQA Diamond 上获得 92.3 分,HLE(Humanity’s Last Exam)达到 55.4(带工具),均为开源模型中的顶尖水平。
七、开源生态与部署实践
7.1 Apache 2.0 的商业影响
Hy4 preview 采用 Apache 2.0 协议,这是最宽松的开源许可证之一。它允许使用者自由地商用、修改和分发,无需公开修改后的源码。这意味着:
- 企业可以基于 Hy4 preview 构建私有化部署的 AI 产品,无需担心许可证合规问题
- 与 GLM-5.3 的定制许可证相比,Apache 2.0 没有地域限制和领域限制
- 金融、政企等对合规敏感的行业可以放心使用
7.2 国产芯片 0day 适配
Hy4 preview 发布当天即完成昇腾和燧原国产芯片的适配,这在开源大模型领域尚属首次:
Hy4 preview 国产芯片适配矩阵:
┌─────────────────────────┐
│ Hy4 preview │
│ (770B MoE) │
└──────┬──────────┬───────┘
│ │
┌────────────┘ └────────────┐
▼ ▼
┌───────────────────┐ ┌───────────────────┐
│ 昇腾 (Ascend) │ │ 燧原 (Enflame) │
│ CANN 适配 │ │ GCU 适配 │
│ vLLM-Ascend │ │ 自定义算子 │
│ Docker: │ │ 优化推理栈 │
│ quay.io/ascend/ │ │ │
│ vllm-ascend:hy4 │ │ │
└───────────────────┘ └───────────────────┘
7.3 部署方案与硬件要求
Hy4 preview 的部署门槛较高——FP8 量化版约 770GB,BF16 全精度版约 1.54TB:
| 部署模式 | 精度 | 显存需求 | 推荐配置 | 推理速度 |
|---|---|---|---|---|
| 最小部署 | FP8 | ~770GB | 8× 80GB GPU (H100) | ~36 tok/s |
| 生产部署 | FP8 | ~850GB | 8× 100GB+ GPU | 启用 MTP 更快 |
| 全精度 | BF16 | ~1.54TB | 需专家并行 | 更高质量 |
八、国产大模型"闪电战":竞争格局深度分析
8.1 迭代节奏:从"年度"到"月度"
2026年8月,国产大模型的迭代节奏达到了前所未有的密度:
2026年8月国产大模型发布日历:
8月 中旬: DeepSeek V4 Pro 正式版
8月 中旬: Qwen3.8-Flash 发布
8月 28日: Hy4 preview 开源
8月 28日: GLM-5.3-Flash 开源
8月 28日: Qwen3.8-Flash 同日发布
自 2026 年 2 月重建预训练与强化学习基础设施以来,混元平均每两个月迭代一次大版本。从 Hy3(295B/21B/256K)到 Hy4 preview(770B/49B/1M),仅隔不到两个月,规模扩大 2.6 倍,上下文扩展 4 倍。
8.2 多模型横向对比
2026年8月开源旗舰模型对比:
模型 总参数 激活参数 上下文 协议 输入价格(/M tokens)
─────────────────────────────────────────────────────────────────────────
Hy4 preview 770B 49B 1M Apache 2.0 ¥6 (≈$0.83)
GLM-5.3 753B 40B 1M 定制 ¥10 (≈$1.40)
GLM-5.3-Flash 320B 18B 1M MIT ¥1.10 (≈$0.15)
Qwen3.8-Flash 125B+51B 6B 262K→1M Qwen 社区 ¥1.20 (≈$0.16)
DeepSeek V4 Pro 1.2T+ ~60B 1M 定制 ~¥3.20 (≈$0.44)
价格与性能的权衡:
✦ Hy4 preview: 能力最强档, 价格中档, Apache 2.0 最宽松
✦ GLM-5.3-Flash: 轻量高性价比, MIT 协议
✦ Qwen3.8-Flash: 极致性价比, 适合批量推理
✦ DeepSeek V4 Pro: 参数最大, 但协议较严格
8.3 竞争重心转移
行业的竞争重心正在从"参数比拼"向"生产力指标"转移。Hy4 preview 的发布策略——preview 先行、产品内嵌、专家盲测、快速迭代——代表了新的竞争范式。腾讯通过 WorkBuddy、CodeBuddy、元宝、ima 组成的"产品矩阵",将每一次模型发布都变成真实场景的反馈收集入口。
腾讯首席 AI 科学家姚顺雨主导下的这一策略,让混元在不到半年的时间里完成了从追赶者到第一梯队的跨越。正如腾讯在发布公告中坦言:“通过 preview 先行、正式版跟进的方式,将真实世界的反馈持续引入研发过程,让模型在解决实际问题中进步。”
九、已知局限与未来方向
腾讯明确承认 Hy4 preview 的已知问题:
- 推理过长(Over-thinking):模型在复杂任务上倾向于花费过多时间推理,导致延迟增加
- 过度验证(Over-verifying):模型会反复检查自己的输出,验证到超出实际需要的程度
- 多模态缺失:Hy4 preview 和 Hy3 均为纯文本模型,暂不具备多模态能力
这些局限也正是 Hy4 正式版的优化方向。腾讯表示 Hy4 的下一版模型将在近期陆续上线。同时,Hy4 preview 的"高努力推理模式"(high reasoning effort)和"直答模式"(no_think)为用户提供了在不同场景下的灵活选择——简单任务用 no_think 加速,复杂任务用 high 确保质量。
十、总结
Hy4 preview 的发布标志着腾讯混元正式进入开源大模型的第一梯队。它不仅在参数规模、上下文长度、推理能力上实现了代际跃升,更重要的是,它开启了"模型参与优化自身"的递归自我改进范式。从 53 天前的 Hy3 到今天的 Hy4 preview,迭代节奏从"年度"压缩到"月度",这本身就是工程能力与组织效率的胜利。
在国产大模型"闪电战"的竞争格局中,Hy4 preview 以 Apache 2.0 的完全开放、国产芯片的 0day 适配、产品矩阵的深度联动,构建了差异化的竞争壁垒。对于开发者社区而言,770B 的权重、1M 的上下文、内置的 MTP 投机解码——这些技术能力的开放,意味着在腾讯的产品体系之外,AI 社区也可以基于 Hy4 preview 构建自己的生产力工具。
正如腾讯所言,这只是一个"preview"。真正的 Hy4 系列还在路上。但即使只是预览版,Hy4 preview 已经用实力证明:开源模型的能力天花板,正在被重新定义。
参考来源:
- 腾讯混元官方公告:https://www.tencent.com/tencent-releases-and-open-sources-tencent-hy4-preview/
- 腾讯云开发者社区:https://cloud.tencent.cn/developer/article/2733836
- 科技日报:http://www.stdaily.com/web/gdxw/2026-08/28/content_571433.html
- 人民网:http://finance.people.com.cn/n1/2026/0829/c1004-40788564.html
- Hugging Face 模型卡:https://huggingface.co/tencent/Hy4-preview
- MindStudio 技术分析:https://www.mindstudio.ai/blog/tencent-hy4-preview-open-weight-model
- mer.vin 评测:https://mer.vin/news/tencents-hy4-preview-edges-out-glm-5-3-and-kimi-k3/
- DataLearnerAI:https://www.datalearner.com/ai-models/pretrained-models/hy4-preview