770B 总参、49B 激活、1M 上下文、Apache 2.0 一把开源——腾讯混元 8 月 28 日丢出来的 Hy4 preview，不是“又一个大模型”，而是把牌桌直接换到了“长链路生产力”这一格。
先看反直觉的那部分：
770B 听起来像烧钱玩具，但 MoE 把单次激活压到 49B（约 6.4%），等于用 49B 的推理账单，买 770B 的脑容量。Hy3 是 295B/21B/256K，这一代直接拉到 2.6 倍参数、2.3 倍激活、4 倍上下文。
架构上也没偷懒：
78 层 backbone，首层 dense，其余 77 层 MoE（256 路由 + 1 共享，每 token 激活 top-8+1）；注意力是 Gated DSA + IndexCache 跨层稀疏复用，残差流用 iHC 扩到 4 条；还白送一层原生 MTP（10B/0.7B）做投机解码，不计入官方 770B 口径。
为什么这件事值得停一下？
因为 1M 上下文 + 长程 Agent 基准一起跳，才是真信号：
- Terminal-Bench 2.1：70.8 → 85.4
- DeepSWE：28.0 → 64.3（软件工程实战近乎翻倍再翻倍）
- Toolathlon-Verified：74.1，APEX-Agents pass@1 37.1，贴着 Kimi K3 跑
内部 163 专家盲测 203 个工程任务，2.99/4 略胜 GLM 5.3（2.92）和 Kimi K3（2.94）——不是碾压，是“掰手腕”。
我的明确立场：
Hy4 preview 不是来替你写邮件的，它是来替你扛“整库代码 + 跨文件需求 + 多轮调试”的。
腾讯这次的定位很硬——“为生产力而生”，训练数据和 CodeBuddy/WorkBuddy 的软工、金融、游戏、安全专家共建，盲测任务也是真实工程，不是 GSM8K 刷分。对做 Agent / 长上下文 RAG / 代码库的团队，1M 上下文意味着很多场景可以先别切文档了，整仓塞进去。
对开发者的实际影响三点：
- 自部署门槛极高——BF16 权重 ~1.4TiB，FP8 也得 800GB+，8 卡起步，个人玩家看看 API 就行（TokenHub / OpenRouter，缓存命中输入 ¥0.3/百万，输出 ¥18/百万）。
- Agent 框架该重新测了：长链路规划、工具调用、自我验证，Hy4 比上代明显能跑更远，但官方也承认“思考偏长、过度自验”，别无脑当实时系统用。
- 竞品压力给到 Kimi / GLM / DeepSeek：开源权重 + 1M + 软工基准，这三个里至少有一个要连夜改路线图。
未来 3–6 个月我赌这几件事：
- Hy4 正式版（非 preview）会按混元“两月一大版本”节奏落地，多模态补位；
- 1M 上下文会倒逼 Agent 内存管理从“RAG 必备”变成“RAG 可选”；
- 腾讯会把“模型参与自身研发（吞吐 +31.8%）”这条线继续讲，AI 造 AI 从 PR 词变成工程常态。
当然 preview 就是 preview：复杂任务爱绕弯、暂不支持视觉、厂商自测尚无第三方交叉验证——这些别当正式版结论用。
#腾讯混元 #Hy4Preview #开源大模型 #MoE #LongContextAgent
你更看好 1M 上下文干掉 RAG，还是觉得“长上下文 + 工具调用”才是 Agent 的终局？评论区聊聊你拿 Hy4 准备先虐哪个任务。
