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 之间的某个值。这也是架构跃迁四个字里最核心的信息它不再是一个同构放大的模型而是整个结构换了一套玩法。对比维度Hy3295B 时期Hy4 Preview770B 时期参数结构以稠密/粗粒度 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: fBearer {API_KEY}}, files{image: (product_photo.png, image_data, image/png)}, data{output_format: glb, texture_resolution: 2048}, timeout180, ) 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 这个量级我更倾向于把它当成一个能力不错但需要明确授权边界的合作者——给它更开放的目标用少量关键约束框住方向然后让它自己拆解步骤。这种思路切换带来的效率提升和模型本身的升级同样明显。技术选型永远不是选一个最大的模型就完事选完之后怎么安排人机协作才是真正拉开差距的地方。