写在前面
最近腾讯开源了混元Hy3（Apache 2.0协议），权重已在HuggingFace和ModelScope上线。花了几天时间扒了一遍技术资料和官方文档，从工程视角记录一些观察。这篇笔记不讨论商业竞争，只聊技术选型——MoE怎么做、成本怎么压、工程决策背后的trade-off是什么。
一、架构概览：295B参数的MoE，为什么激活只要21B
Hy3的核心规格：
- 总参数：295B
- 激活参数：21B（每次推理只需要激活约7%的参数）
- 专家数量：192个专家，每次激活Top-8
- 上下文窗口：256K tokens
- 架构：Dense + MoE混合结构
MoE选型的技术逻辑
一个纯Dense的295B模型，单次推理需要加载全部参数，显存需求和计算量级是恐怖的。MoE的核心工程价值是 "参数不白存，算力不白花"——你把295B参数分布在192个专家头上，但每次输入只路由到最相关的8个专家（Top-8）。
从实测数据看，Hy3在高频办公任务中的token消耗显著低于同级别的GLM-5.2：
- 文档处理：节省 47.4% 的token消耗
- PPT制作：节省 49.0% 的token消耗
这就是MoE路由效率的直接体现——当任务越细分、越专业化，路由到正确专家的概率越高，无效计算越少。
192专家 vs 小专家集群的trade-off
有人可能会问："为什么不直接用8个通用专家？"
这里有一个关键工程权衡：专家越多，单专家的参数量越小，但路由的准确度要求越高。 192个专家意味着每个专家的参数量大约是295B / 192 ≈ 1.5B/专家（粗略估计），而Top-8激活总量约12B参数，加上共享的Dense层凑到21B。
这种设计的代价是路由网络的训练难度大幅上升——192选8的组合空间约C(192,8) ≈ 4.1×10^13量级，路由网络必须学会在如此大的空间中快速定位。Hy3在这个方向上花了大量RL算力，应该是做了多阶段的路由蒸馏和专家均衡训练。
二、预训练与RL基础设施重建：工程团队的"清账"动作
2025年12月，团队做了一个大动作：重建了整套预训练和强化学习基础设施，定下三条工程原则——"不偏科、不刷榜、不烧钱"。
数据质量和多样性才是瓶颈
跟很多团队的认知相反，Hy3从preview到正式版的升级 没有动架构，变化集中在两点：
- 数据质量和多样性的提升
- RL算力规模的扩大
这是个很有意思的工程信号：架构定型后，边际收益最高的投入方向不是继续堆参数，而是 清洗数据 + 强化对齐。
具体来说，训练数据的多样性提升，意味着模型在长尾场景中的泛化能力变强。这和WorkBuddy上的实测数据对得上——Hy3预览版用户的自主选择量增长了6倍，任务成功率从72%跃升至90%，平均耗时缩短34%。
这些提升不是模型"变聪明"带来的，而是模型在更多场景中被"对齐"后产生的连锁反应。
RL算力的边际效用
从SWE-bench Verified的分数变化可以反推：preview到正式版的RL训练量应该相当大。
Hy3在代码智能体方向（SWE-bench Verified 78.0分）和高阶数学方向（GPQA Diamond 90.4分）与GPT-5.5的84.4分和93.6分仍有差距。
这说明在复杂推理任务上，RL的边际收益还没有收敛——或者说，在代码和数学这类推理密集型场景中，当前RL pipeline对"思维链长度"和"搜索空间"的覆盖还不够深。
三、成本工程：1元/百万tokens的定价是怎么做到的
定价数据：
| 维度 | 价格（元/百万tokens） |
|---|---|
| 输入 | 1 |
| 输出 | 4 |
| 缓存命中 | 0.25 |
这个价格在同等参数规模的MoE中属于第一梯队。从工程角度看，压缩推理成本依赖几个关键设计：
1. MoE的稀疏激活直接降低单次开销
21B的激活参数 vs 295B的总参数——每次推理省掉了93%的参数加载。这是MoE最直接的降本手段。
2. 缓存策略
缓存命中价0.25元/百万tokens，只有正常输入价的1/4。这意味着在Chat Agent、RAG、多轮对话这类高频重复场景中，如果缓存命中率做到30-50%，综合成本可以再降一个量级。
3. 产品场景的"正向数据飞轮"
Hy3一周内接入了几十款产品，日均token消耗暴涨20倍。这个数据的工程含义是：更多的调用 → 更多的缓存命中 → 更低的边际成本 → 更低的价格 → 更多的调用。
对于做API服务的技术团队，这个循环是工程层面需要重点关注的——Hy3的低价不完全是"烧钱补贴"，而是有稀疏激活 + 缓存 + 规模效应三重支撑。
四、Benchmark解读：代码和数学是短板，搜索Agent是亮点
直接看数据（来源：36氪、新华网评测数据）：
| Benchmark | Hy3 | GPT-5.5 | 差距 |
|---|---|---|---|
| SWE-bench Verified（代码智能体） | 78.0 | 84.4 | -6.4 |
| GPQA Diamond（高阶数学） | 90.4 | 93.6 | -3.2 |
| BrowseComp（搜索智能体） | — | 接近GPT-5.5水平 | ✅ |
有差距的地方在哪
代码和数学是目前MoE模型的"典型硬伤"——稀疏激活天然对需要长链推理的任务不利。因为你在MoE中只激活了部分专家，而复杂推理需要跨多个子空间的协同，专家之间信息传递可能产生损耗。
优势在哪
搜索类智能体（BrowseComp）接近GPT-5.5水平。这和MoE的结构特性有关——搜索任务是"广撒网再聚焦"的模式，正好匹配MoE"多个专家并行筛选"的推理方式。
另一个工程要点：在内部270位专家基于真实工作的盲测中，Hy3均分2.67/4分，优于GLM-5.1的2.51分。优势集中在前端开发、数据与存储、CI/CD等高频实操场景——这些场景的共性是 "重复性高、模式明确、路由效率高"。
五、256K上下文窗口：工程实现的技术挑战
Hy3支持256K上下文窗口，在同级别MoE模型中属于主流配置。
大上下文窗口对MoE架构的核心挑战在于：
- KV Cache膨胀：长上下文的KV Cache随序列长度线性增长，295B的MoE在这方面的显存压力比Dense模型更复杂——因为多个专家的KV Cache都需要维护
- 位置编码的RoPE适配：MoE的专家路由在不同token位置的表现可能不一致，需要做位置感知的路由调优
- 长序列下的路由稳定性：当上下文超过一定长度，部分专家可能出现"拥塞"（被过多token路由到），需要做负载均衡
从实际表现看，Hy3在长文档处理（节省47.4%的token消耗）这样的场景中表现突出，说明工程团队在长序列优化上投入了不少功夫。
小结
从工程角度，Hy3值得关注的点不是"它有多强"，而是 "它用什么样的工程手段把成本压到了什么程度"：
- MoE + 192专家提供了21B激活参数的设计空间
- 数据质量提升 + RL规模扩大是preview到正式版的核心变化
- 1元/百万tokens的定价背后是稀疏激活 + 缓存 + 规模效应的三重支撑
- 代码和数学仍是短板，但高频实操场景的性价比优势明显
对于做技术选型的团队，建议在自己场景下做一次AB对比——特别是在文档处理、搜索Agent、办公自动化这类高频场景中，token消耗可能差30-50%。开源权重已可下载自部署，实测成本比看benchmark更有参考价值。
以上为个人学习笔记，数据来源：新华网、36氪、21世纪经济报道、IT之家公开报道。
