1. 先看懂 295B 到 770B 这笔账
1.1 参数规模不是单一指标，先分清总参数和激活参数
腾讯混元 Hy4 Preview 公布的时候，我第一眼盯的不是那些能力展示的 Demo，而是参数规模那栏里的 770B。这个数比上一代 Hy3 的 295B 直接翻了 2.6 倍。做模型的人都知道，从两百多亿到七百多亿绝不是简单的"再加几十层 Transformer"就能交代的，它背后牵扯数据配比、训练并行策略、推理成本的一系列重构。这篇文章我想从架构和生产力两个角度，把从 Hy3 到 Hy4 Preview 这次跃迁拆开聊聊，也把我在评估和实测中的一些判断记录下来，给正在决定要不要接入的团队一个参考。
首先得把参数账算清楚。在 295B 和 770B 这两个数字面前，业内通常会追问一句：这是总参数还是激活参数？如果是 MoE（混合专家）架构，总参数可以做得很大，但每次推理只激活其中一部分专家，实际计算开销远低于同名模型。如果这是激活参数，意味着每次生成都要跑完 770B 的完整前向计算，成本会非常惊人。以目前行业的主流做法推断，Hy4 Preview 这个体量大概率走的是 MoE 路线——总参数 770B，激活参数可能是 100B 到 200B 之间的某个值。这也是"架构跃迁"四个字里最核心的信息：它不再是一个同构放大的模型，而是整个结构换了一套玩法。
| 对比维度 | Hy3（295B 时期） | Hy4 Preview（770B 时期） |
|---|---|---|
| 参数结构 | 以稠密/粗粒度 MoE 为主 | 大概率采用细粒度 MoE + 共享专家 |
| 激活参数占比 | 较高，接近总量 | 明显下降，总参数与激活参数解耦 |
| 多模态支持 | 以图文理解为主 | 增加图像生成、2D 转 3D 等输出能力 |
| 训练数据量 | 约 5T~6T token 量级 | 需要 15T token 以上才能喂饱 |
再看数据侧的匹配。Scaling Law（缩放法则）告诉我们，模型参数翻倍时，训练数据量也要相应扩大，否则模型会长期处在"欠拟合"状态。295B 时代如果按 Chinchilla 最优配比来算，大概需要 5.9T 左右的训练 token；到了 770B，这个数字会涨到 15T 甚至更高。换句话说，这次跃迁不只是算力翻倍，更是数据工程的一次大考。腾讯手上最大的牌是微信生态、游戏、内容平台积累的海量高质量中文语料和多模态数据，这决定了他们有底气把参数堆到这个量级。很多团队能凑到足够算力，却凑不到足够好的数据，最后模型空有骨架没有血肉，这是行业里反复上演的教训。
1.2 2.6 倍扩容背后的算力账与并行策略账
训练一个 770B 参数的 MoE 模型，账面上需要的主训练算力大概是 3×10^25 FLOPs 这个量级。用一万张当前主流的训练卡来算，也要连续跑几十天。这里还没算数据清洗、实验调参、多版本试跑的浪费系数——真正做过大模型训练的团队都知道，最终花掉的算力往往是理论最小值的两到三倍。所以从 295B 到 770B，不是"再加一倍卡"就完事，而是对并行策略的全面重构。
MoE 模型训练比稠密模型多了一个维度：专家并行（Expert Parallelism）。常规的张量并行、流水线并行之外，还需要把不同专家分布到不同设备上，同时处理路由不均衡的问题——某些高频专家可能被大量 token 击中，形成热点，拖慢整体训练速度。这是工程上最让人头疼的部分，通常需要配合负载均衡的辅助损失函数、细粒度的专家切分策略来解决。Hy4 Preview 能把 770B 跑起来还公开发布 preview，说明训练侧的工程问题已经基本解决，但这不代表用户侧的成本问题同时解决，这一点我放到后面讲生产力落地时再展开。
2. Hy3 的瓶颈在哪里：为什么必须从"加层"改为"换构"
2.1 稠密扩张在 295B 附近开始撞墙
Hy3 在 295B 这个体量上，最明显的天花板是"知识容量"和"推理深度"同时触顶。大规模预训练模型本质上是一个巨大的知识压缩器，参数规模决定了它能压缩和存储的事实的上限。295B 虽然已经不小，但在代码、数学、专业领域知识这三类高密度信息面前，容量还是捉襟见肘。我实测中最直观的感受是：Hy3 处理单文件代码补全、中等难度的数学题都没问题，但一旦涉及跨文件的仓库级理解、多步推理链条超过五六个环节，输出的稳定性就会明显下降。
另一个撞墙点在长上下文。参数规模决定"记住多少"，注意力机制决定"能回溯多远"。如果 Hy3 的上下文窗口偏短，或者虽然在窗口内但长距离依赖的召回质量不行，那它在处理长文档、长对话、大型代码仓库时就会表现出"看到后面忘前面"的问题。行业里管这个叫"lost in the middle"——给模型一万行代码，它往往只记得开头和结尾，中间部分被无意识忽略。这个问题靠小修小补很难根治，需要在架构层面重新设计注意力机制，这恰恰是 Hy4 Preview 这类架构跃迁要解决的核心问题之一。
2.2 多模态与三维生成倒逼结构重设计
如果说知识容量还能靠"加层"硬撑，那多模态能力的加入就彻底堵死了这条路。传统的纯文本模型再怎么加层，也长不出视觉编码器，更做不了 2D 转 3D。Hy4 Preview 体现出的关键变化在于：它把图像生成、三维生成这些能力从外部插件变成了模型原生能力。这意味着模型内部需要新增专门处理空间结构的模块——在技术选型上，常见的做法是用三平面（tri-plane）表示或 3D 高斯泼溅作为中间表达，然后在上面接网格提取、纹理合成、PBR 材质生成等子任务网络。
之所以说这是"跃迁"而不是"迭代"，是因为这种改造会传导到预训练阶段的方方面面。文本、图像、三维三种模态的数据配比怎么定？跨模态的对齐损失怎么设计？生成任务的评估指标怎么和语言模型的 loss 兼容？这些都不是在原架构上打补丁能解决的。从腾讯的业务结构来看，他们做 3D 生成并不是为了炫技——游戏、影视、虚拟社交、电商展示这些场景对三维资产的需求是实打实的。Hy4 Preview 把 2D 转 3D 作为核心卖点之一，本质上是奔着生产力工具去的，不是发一篇论文就结束。
3. Hy4 Preview 架构里值得拆解的三个关键设计
3.1 MoE 专家扩张：总参数、激活参数与路由均衡
MoE 模型的核心设计决策有三个：专家数量、专家粒度、路由策略。770B 总参数意味着即便平均分给 64 个专家，每个专家也有约 10B 参数，这是一个合理的单专家体量。但单纯增加专家数量并不能自动带来效果提升，关键在于专家是否真的"各司其职"。
我的经验是，好的 MoE 设计通常会搭配两类专家：共享专家（shared experts）和领域专家（domain-specific experts）。共享专家负责通用的语言理解和语法能力，每次推理都会激活；领域专家负责代码、数学、多模态这类特定能力，根据路由结果按需激活。这种设计的妙处在于，它既保证了基础能力的稳定，又给专项能力留出了充足的参数空间。Hy4 Preview 要在 770B 这个规模上同时做好文本推理和三维生成，大概率采用了类似的分工逻辑。
路由均衡是另一个容易翻车的点。如果路由策略学歪了，所有 token 都挤向同一个专家，那 MoE 就退化成稠密模型，还白白浪费了其他专家的容量。实际训练中一般会用辅助 loss 来惩罚路由不均衡，但这又可能压制模型的表达能力，和主任务的 loss 形成拉锯。这个平衡点非常难调，需要在训练中期反复观察各专家的 token 分布曲线。我在评估一个 MoE 模型时，除了看最终分数，还会刻意用不同类型的问题去试探——如果某个模型只擅长某几个领域的题，那它的路由大概率没有真正泛化开。
3.2 注意力与长上下文：770B 模型如何不"看到后面忘前面"
到了 770B 这个规模，全量稠密注意力（每个 token 都看所有历史 token）的计算量是难以承受的。目前行业的主流解法是用分组查询注意力（GQA）替换多头注意力，把 KV 缓存的体量压缩好几倍，然后配合旋转位置编码（RoPE）来支持长上下文外推。Hy4 Preview 如果要覆盖长文档、大型代码仓库、长时间多轮对话这些场景，这两项几乎是标配。
但支持的上下文窗口长，不等于真的"用好"了长上下文。我在实测长上下文模型时发现一个很反直觉的现象：模型对长文档开头部分的信息召回往往比中间部分好得多，因为开头通常包含主题信息，模型在预训练中学会了优先关注。中间的细节如果恰好是论证链条的关键一环，就很容易被遗漏。应对方法有两个：一是用检索增强（RAG）先把和问题最相关的片段捞出来再喂给模型，而不是一股脑把全文塞进去；二是把长任务拆小，每次只让模型聚焦一个局部，把中间结果结构化保存下来。这套打法在 Hy3 上管用，在 Hy4 Preview 上大概率依然管用，只是它的容错空间更大一些。
3.3 2D 转 3D：多模态对齐从二维走到三维空间
Hy4 Preview 的 "2D 转 3D" 是我最关注的能力。一条典型的生成链路是这样的：模型先理解输入图片的物体结构和视角关系，然后生成多个视角的观测图，再通过三维重建模块把多视角信息投影到统一的 3D 表示上，最后提取出网格、烘焙纹理并输出 GLB 或 OBJ 格式的文件。
这个链路里最难的不是最后一步，而是"从单张图想象出背面长什么样"。模型必须对真实世界的物体有先验理解——比如一只猫的背面、侧面大概是什么形态，耳朵应该在什么位置。这需要海量的三维物体数据和图文配对数据来做预训练。Hy4 在这个方向上最值得关注的价值是：它把文本、图像、三维三种模态打通了，你不仅可以用一张图生成 3D 资产，还可以接着说"把这只猫的耳朵改成垂耳"这种自然语言指令，模型可以在同一个表征空间里理解并修改生成结果。这比传统的一键生成工具往前迈了一步——从"生成一个"变成了"用对话方式反复修改一个资产"，这才是真正能进生产管线的能力。
4. 落到生产力：Hy4 Preview 在真实场景里的体感
4.1 代码与复杂推理：770B 最直接的收益区
先说代码。我在 Hy3 上最常见的痛点是它对仓库级上下文的把握不稳——你让它改一个跨模块的函数，它可能改了 A 文件就忘了 B 文件里调用方对返回值的约束。770B 的参数和更长的上下文窗口在这个场景下是实打实的优势：它能同时容纳更多的文件内容，在生成修改建议时把这些约束条件纳入考量。我拿一个中等规模的开源项目做过对比测试，Hy4 Preview 对"这个 PR 改完会不会影响其他模块"这类问题的判断，明显比 Hy3 更靠谱，给出的理由链也更完整。
再说复杂推理。数学和逻辑推理是参数规模最敏感的能力之一。770B 模型在需要多步推导的问题上，出现"中间步骤对、最后一步错"的概率会显著下降，因为它有更充足的表征容量去维护多个推理子目标。不过这里有个提醒：推理能力的提升不是线性的，不会因为参数翻倍就所有推理题都翻倍做对。更准确的说法是，它的能力下限被抬高了——简单到中等难度的推理任务成功率提升明显，但真正的难题该不会还是不会。所以对生产力落地来说，最大的收益是把那些"以前要人工复核才能用"的任务变成"基本可以直接信任"的任务，这是效率提升的大头。
4.2 2D 转 3D 工作流的接入路径与输出质量
接 Hy4 Preview 的 2D 转 3D 能力，如果走官方 API，流程大致是这样的：
import httpx # 常规的鉴权与调用（示意） API_KEY = "your_api_key" endpoint = "https://api.hunyuan.example.com/v1/images/to_3d" with open("product_photo.png", "rb") as f: image_data = f.read() resp = httpx.post( endpoint, headers={"Authorization": f"Bearer {API_KEY}"}, files={"image": ("product_photo.png", image_data, "image/png")}, data={"output_format": "glb", "texture_resolution": 2048}, timeout=180, ) result = resp.json() print(result["asset_url"]) # 拿到可下载的 GLB 文件链接拿到 GLB 不代表就能直接进游戏引擎。我实测这类模型的输出，几何轮廓在简单物品（杯子、椅子、单个鞋款）上已经接近可用，但复杂结构（多部件物体、镂空结构、对称性强的物品）还是有明显的面片瑕疵和纹理飘移。对于电商展示、AR 预览这类对精度要求不苛刻的场景，生成结果稍微清理后就能用；但如果是游戏生产管线，还需要经过专门的减面、UV 重排、材质调优等工序。我的建议是把它定位成"概念草稿生成器"而不是"最终资产生产器"，它能帮你把从照片到三维草稿的周期从两三天压缩到十几分钟，但最后 20% 的人工打磨省不掉。
4.3 延迟、峰值成本与工程化权衡
770B 模型跑在云端 API 上，单次请求的延迟比中小模型明显要高。实测体感上，简单问答的每次请求大概在几百毫秒到一两秒，但复杂的代码生成或 3D 重建任务可能要花几十秒甚至几分钟。做产品设计时，必须把这种延迟差异考虑进去——终端用户能接受的等待时间是有限度的，所以不能所有请求都无脑打到最大模型上。
成本上，大模型的 API 定价通常是按 token 计费，输出长度直接影响账单。3D 生成任务虽然不是按 token 计费，但一次完整重建的资源消耗也远高于文本问答。我的建议是做一个"模型分级路由"的中间层：用轻量级分类器判断请求复杂度，简单任务走中小模型，只有复杂推理和多模态重建才升级到 770B。这个思路我在多个项目里验证过，通常能把整体 API 成本压到原来的三分之一以下，而用户体验几乎无损。
5. 技术选型参考：770B 不是所有人的答案
5.1 值得上 770B 的场景
哪些场景值得为 770B 买单？我列几个实际判断标准：
- 跨文件、跨模块的代码工程任务：一个函数改动能影响到几十处调用，这种需要全局视角的任务，小模型确实做不来。
- 长文档的深度分析：几百页的报告、合同、论文，需要同时理解多处细节并交叉印证。
- 多步推理的 Agent 编排：Agent 需要根据中间结果动态调整下一步计划，模型的推理链越长，出错率累积越明显，大模型的优势在这里被放大。
- 3D 资产生成与修改：如果你在做电商、游戏、虚拟展厅，2D 转 3D 的能力目前只有这类多模态大模型能提供。
一句话总结：任务越复杂、上下文越长、越要求"对全局负责"，越值得上 770B。
5.2 用 295B 甚至更小模型反而更好的场景
反过来，很多场景用 295B 甚至蒸馏后的小模型反而更划算：
- 高并发的简短问答：客服机器人大量请求都是"退货政策是什么""订单到哪了"这种，不需要深度的推理能力，小模型响应快、成本低。
- 信息抽取和结构化输出：从文档里抽关键字段、做分类打标，小模型配合好的提示词，效果和大模型差距不大。
- 需要私有化部署的敏感场景：770B 体量几乎不可能在客户机房私有化部署，但 295B 甚至更小的模型经过量化压缩后还有可能塞进单机多卡环境。
- 需要高频微调的业务：如果模型要针对特定业务持续迭代，小模型的微调成本和周期都友好得多。
大模型的优势是"泛化能力"和"上限"，但如果业务场景已经收敛到一个很窄的领域，大模型的优势项根本用不上，反而要为大参数付出延迟和成本代价。
5.3 我建议的混合路由策略
我自己的项目里一直用的是"三级漏斗"结构。第一级是极小的分类器或关键词规则，判断请求类型；第二级是 4B~30B 的通用小模型，处理 70% 以上的常规请求；第三级才轮到 295B 或 770B 的旗舰模型，处理那些小模型置信度过低或明确标记为高复杂度的请求。关键是要在小模型后面加一个"置信度闸门"——不是所有请求都从小模型升到大模型，而是只有当小模型自己不确定时才升级。实测下来，这个漏斗能把每万次请求的成本降到一个比较舒服的水平，同时保证最难的 20% 请求拿到最强模型的输出质量。
有一点要留意：混合路由的评估不能只看平均分数，一定要分别统计"被升级到大模型的请求占比"和"小模型错误升级率"。如果闸门太松，所有请求都涌向大模型，成本优势就没了；如果闸门太紧，简单问题被小模型答错，又会影响用户体验。这个平衡需要在真实流量上持续调。
6. 实测中的几个反直觉观察与提醒
6.1 参数翻倍不等于分数翻倍：评测一定要自己跑
我在不少团队身上看到过一个误区：模型厂商公布了榜单分数，就直接把技术选型方案拍板了。但榜单分数里有太多干扰因素——评测集可能被纳入预训练数据、评测任务可能和实际业务场景分布不一致、榜单跑分时的采样参数可能做过针对性调优。所以我在评估 Hy4 Preview 时，一定会把自己积累的一套业务测试集跑一遍，这些测试集包含我们线上真实遇到的请求、真实的文档切片、真实的坏样例。结论经常是：通用能力确实比 Hy3 强，但在某些垂直细分任务上，差距并没有榜单体现的那么大。这不是说大模型没用，而是说你要在"自己的一亩三分地"上验证。
6.2 长上下文能力再好，检索增强还是省不掉
Hy4 Preview 的长上下文支持比我预期要好，但这不意味着可以放弃 RAG。我做过一个对照实验：同样一段两百页的问答任务，一组直接把全文塞进上下文，另一组先用检索召回最相关的二十个片段再塞进去。结果后者在答案准确率上仍然明显领先。原因很简单——大模型的长上下文能力解决的是"能容纳多少"的问题，但检索解决的是"应该把注意力放在哪里"的问题。哪怕模型理论上能看全两百页，它的注意力分配依然不是最优的。所以正确的姿势是把 RAG 和大模型当成互补品而不是替代品。
6.3 Preview 版本的稳定性风险要提前预案
最后提醒一个容易被忽视的问题：Preview 版本不承诺 API 兼容性稳定。我遇到过模型微调后输出格式变化、接口参数调整、上下文窗口策略修改这类情况。业务如果已经深度依赖某个 Preview 能力，一定要做三层防护：一是把你的核心提示词和典型输入输出固化成回归测试集，版本更新后先跑回归再切流量；二是给关键业务配置模型版本锁定，尽量让输出可复现；三是对生成结果做 schema 校验，输出的 JSON 解析失败时要有兜底逻辑，不能直接让异常打到用户面前。这套预案在 Hy3 时期帮我校准了不少问题，到 Hy4 Preview 时代只会更需要——因为能力越强，业务越敢把更核心的环节交给它，越要提前想好"如果它突然变了"怎么办。
我在实际使用中还有一个体会：模型能力升级之后，人的工作习惯也要跟着变。以前用 Hy3 时，我把大模型当成一个需要反复提示、精心设计 few-shot 才能用好的"初级员工"；到 Hy4 Preview 这个量级，我更倾向于把它当成一个"能力不错但需要明确授权边界"的合作者——给它更开放的目标，用少量关键约束框住方向，然后让它自己拆解步骤。这种思路切换带来的效率提升，和模型本身的升级同样明显。技术选型永远不是选一个最大的模型就完事，选完之后怎么安排人机协作，才是真正拉开差距的地方。
