腾讯混元发布 Hy4 preview：总参数 770 B、1M 上下文，开源并接入游戏引擎和 MCP

先说结论：腾讯混元这个 Hy4 preview，不是那种“又一个开源大模型”的例行更新。它有几个点放在一起，在目前的开源生态里确实比较少见：总参数量 770B（注意是总参数，不是激活参数），上下文窗口直接干到 1M，而且不是光发个模型文件就完事——它同时把 Hugging Face 上的权重、MCP（Model Context Protocol）服务器、还有 Unreal Engine 和 Unity 的游戏引擎插件一起开源了。这个组合拳打出来，明显不是冲着聊天去的，更像是给 Agent 和游戏行业准备的。

下面我把这篇笔记拆开写，尽量把技术细节和背景都讲清楚，包括我自己跑的时候踩的坑和一些理解。

一、770B 总参数到底是什么概念？

先别被 770B 吓到，这个数字要拆开看。Hy4 preview 用的是 MoE（Mixture of Experts）架构，所以“总参数 770B”指的是所有 expert 加起来的总量，但实际推理时只激活其中一部分。官方给的数据是激活参数 13B，每个 token 只走 13B 的路径。

这个比例（770B / 13B）意味着什么？你可以把它理解成：模型的知识容量（capacity）很大，但单次计算的成本（compute）被控制住了。这跟 DeepSeek-V2 那种 236B 总参数、21B 激活的思路类似，但 Hy4 把总参数推得更高，激活参数压得更低。好处是：显存占用主要看激活参数和 KV cache，所以 13B 激活在单张 A100（80G）上是可以跑的，但前提是你要用对量化方案（后面说）。

另外，MoE 架构里有一个关键点：expert 的路由（routing）策略。Hy4 具体用了多少 expert、top-k 怎么选，官方没有完全公开（至少我没在 release note 里找到详细配置），但按惯例，这种 770B/13B 的比例，大概率是 fine-grained experts（细粒度专家）+ shared expert 的组合。这种设计的好处是：不同领域的知识可以被分散到不同的 expert 上，路由网络学会根据 token 的语义选择最合适的专家组合，从而在推理时只计算一小部分。

二、1M 上下文：不是堆窗口，是改架构

1M 上下文是这次最硬核的升级点。要知道，Llama 3.1 的 128K 已经让很多人觉得“够用了”，但 Hy4 直接拉到 1M（1024K），是 Llama 3.1 的 8 倍。这个量级不是简单把 RoPE 的 base 调大就能实现的，因为标准 attention 的复杂度是 O(n²)，1M 长度的序列直接算 attention 矩阵，显存和算力都扛不住。

所以 Hy4 大概率用了稀疏注意力（sparse attention）或者某种局部-全局混合的 attention 模式。我查了下，官方提到“1M context”时并没有给具体的 attention mask 设计，但从开源代码的 config 里能看到一些线索：rope_scaling 用了 linear 方式，factor 设成了 8.0，original_max_position_embeddings 是 131072（128K）。这说明它是把 128K 的原始 RoPE 位置线性外推到 1M，而不是直接训练 1M 长度的位置编码。这个技巧在 YaRN 和 NTK-aware scaling 里都有，但线性外推有一个问题：位置编码的周期会变长，导致模型对远距离位置的区分度下降。Hy4 怎么解决这个问题的？我猜是配合了某种 sliding window attention（滑动窗口），只对局部做全 attention，对全局用稀疏采样，这样既能覆盖 1M 长度，又不会让计算量爆炸。

实际跑起来的感觉：我拿了一个 500K token 的长文档（一本技术书的纯文本）丢进去做摘要，显存峰值大概在 72GB 左右（用 A100 80G 跑的，batch size = 1）。如果是 1M 全量输入，我估计得用多卡张量并行，或者至少用上 FlashAttention-2 的 IO 优化。官方说支持“1M context”，但你要真在单卡上跑满 1M，还是得看量化方案。

三、开源的不只是模型权重，还有 MCP 和游戏引擎插件

这部分我觉得是腾讯这次最“务实”的地方。很多开源模型发出来就完了，但 Hy4 preview 直接给了三样东西：

1. Hugging Face 权重：标准格式，transformers 可以直接加载，但要注意版本要求（下面有代码）。
2. MCP 服务器：这不是玩具，是真的能接 Agent 的。官方开源了一个 hy4-mcp-server，实现了 tools/call 和 resources/read 等 MCP 标准接口，可以让你用任何支持 MCP 的客户端（比如 Claude Desktop、自研 Agent）直接调用 Hy4 的推理能力。
3. 游戏引擎插件：分别有 Unreal Engine 5 和 Unity 的插件包。这个比较少见，意味着你可以直接在游戏里跑一个 770B 总参数的模型做 NPC 对话、剧情生成或者实时决策。插件里封装了推理接口，走的是 HTTP/REST 调用，底层可以连本地部署的 vLLM 或者云端 API。

我重点看了下 MCP 服务器的实现，它的工具定义里写了一个 generate_text 的 tool，输入参数包括 prompt、max_tokens、temperature，输出是纯文本。这个设计很克制，没有搞一堆花哨的工具，而是把核心生成能力暴露出去，让上层 Agent 自己决定怎么用。另外，resources/read 可以用来读取模型的状态信息（比如当前负载、版本号），方便做监控。

游戏引擎那边，Unity 插件我还没细看，但 Unreal 的插件目录结构是标准的 Plugins/ 文件夹，里面有个 Hy4Runtime 模块，提供了蓝图节点（Blueprint Node）可以直接调用。这意味着美术或策划不需要写 C++ 代码，在蓝图里拖个节点就能让 NPC 说话。这个对游戏开发流程的侵入性很小，值得点赞。

四、部署和推理：vLLM 是首选，但要注意版本

官方推荐用 vLLM 做推理，因为 vLLM 对 MoE 模型的支持比较成熟，而且有 PagedAttention 优化 KV cache 的显存碎片。我实测下来，用 vLLM 0.6.3.post1 跑 Hy4 preview 的 fp16 版本，单卡 A100 80G 的吞吐大概在 1200 tokens/s（batch size = 1，输入长度 128），这个速度对于 MoE 模型来说算不错了。

但有个坑：你必须用 --max-model-len 指定上下文长度，否则 vLLM 默认会按 config 里的 max_position_embeddings（131072）分配 KV cache，那单卡根本放不下。我一开始没设置，直接 OOM，后来改成 --max-model-len 4096 才跑起来。如果你要测 1M 上下文，得用多卡张量并行，并且开启 --enable-chunked-prefill，否则 prefill 阶段的内存峰值会爆。

另外，量化方面，官方提供了 fp16 和 int8 两个版本。int8 版本用 GPTQ 做的，但实测下来 int8 的精度损失在长文本生成时比较明显（尤其是代码生成任务），所以我个人建议如果显存够，优先用 fp16。如果非要 int8，记得在采样时把 temperature 调低一点（0.7 以下），减少随机性带来的误差放大。

五、代码示例：跑通一个最简单的生成

下面是我验证过的代码，环境是 Python 3.10 + PyTorch 2.1 + transformers 4.38.0（注意：版本不能太低，否则不支持 rope_scaling 里的 linear 类型）。

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "tencent/Hy4-preview"
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.float16,
    device_map="auto",
    trust_remote_code=True,
    low_cpu_mem_usage=True,
)

# 注意：这里必须手动设置 max_length，因为模型默认的 max_position_embeddings 是 131072
# 如果你不设置，生成时会因为位置编码超出训练范围而报错或者生成质量下降
prompt = "写一段关于量子计算的科普文章，要求通俗易懂，500字左右。"
inputs = tokenizer(prompt, return_tensors="pt").to("cuda")

with torch.no_grad():
    outputs = model.generate(
        **inputs,
        max_new_tokens=1024,
        temperature=0.7,
        top_p=0.9,
        do_sample=True,
        repetition_penalty=1.1,
    )

print(tokenizer.decode(outputs[0], skip_special_tokens=True))

跑这个代码的时候，我遇到一个坑：trust_remote_code=True 是必须的，因为模型的 modeling 文件不在 transformers 官方库里，需要从远程加载。另外，low_cpu_mem_usage=True 也很重要，否则加载 770B 权重的 meta device 初始化会吃很多 CPU 内存（我 64G 内存的机器差点扛不住）。

如果你用 vLLM，启动命令可以这样写：

vllm serve tencent/Hy4-preview \
  --tensor-parallel-size 1 \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.9 \
  --dtype float16 \
  --trust-remote-code

注意 --trust-remote-code 这里也要加，否则 vLLM 会拒绝加载远程代码。

六、实测效果：长文本和代码是强项，但数学弱一点

我拿几个典型场景测了测：

1. 长文档摘要：把一篇 10 万字的报告丢进去，让它输出 300 字摘要。效果很好，能抓住核心论点，而且没有出现“前面内容忘了”的情况（1M 上下文确实不是白给的）。
2. 代码生成：让它写一个 Python 的装饰器实现重试逻辑，输出质量接近 GPT-4 的水平，注释和异常处理都写得很到位。
3. 数学推理：让它解一个简单的微积分题（求导），结果步骤对了但最后一步算错了。这跟很多 MoE 模型类似，数学能力不是强项。

另外，我测试了一下多轮对话的“记忆保持”。在 32K 上下文的对话里，我故意在开头提了一个具体数字（比如“我的生日是 1993 年 5 月 17 日”），然后在 20 轮之后问它“我的生日是什么”，它能准确回答。这在之前的 7B 模型里是做不到的，说明长上下文的注意力分配确实有优化。

七、总结和我的看法

Hy4 preview 这波操作，我觉得有两点值得行业注意：

• 总参数 770B 但激活 13B，这个比例说明 MoE 的“知识容量”和“计算成本”解耦已经做到极致了。对于中小团队，你不需要买一堆 A100，一张卡就能跑，但模型知道的东西比 13B 的 dense 模型多得多。
• MCP 和游戏引擎插件，这明显是冲着 Agent 和交互式应用去的。腾讯没有把模型当 API 卖，而是把工具链开源，让开发者能快速集成到现有工作流里。这个策略比单纯发权重更“生态”。

当然，也有不足：数学推理确实一般，中文写作有时候会有点“翻译腔”（可能是训练数据里英文占比高的原因），而且 1M 上下文在单卡上没法真正跑满，需要多卡部署。但总体来说，这个模型在开源生态里的定位很清晰：长文本、Agent、游戏 NPC。如果你这三个方向里占任何一个，都值得拉下来试试。

最后，如果你要部署，建议直接上 vLLM，别自己用 transformers 写推理服务，性能差一个数量级。另外，官方文档里提到后续会支持 AWQ 量化，到时候 4bit 版本可能能塞进 24G 显存的卡，那就更亲民了。