前阵子腾讯混元放出 Hy4 Preview 的消息时我身边的算法群和工程群又热闹了一轮。核心关注点其实就一句话从 Hy3 的 295B 到 Hy4 Preview 的 770B这不是简单把参数量往上翻一倍多而是模型底座、推理代价和应用边界的同步变化。再加上近期“2D 转 3D”这类生产力场景频频出现在各家 Demo 里很多非算法岗的朋友也跑来问我这个变化到底意味着什么。这篇东西不是官方文档的复述更多是我从评测、压测和业务落地角度做的一些观察和推算。先说结论Hy3 适合大多数已经跑通的文本密集型任务Hy4 Preview 则更像是冲着“复杂多模态理解 高成本高价值生产任务”去的。如果你只想做轻量客服、常规知识库问答Hy3 那档规模往往够用但如果你要处理长文档、复杂指令、图片与三维资产生成这类重活Hy4 Preview 的架构优势会体现得非常明显。下面我把整个链路拆开聊。1. 先说清楚这次“架构跃迁”到底在聊什么1.1 Hy3 与 Hy4 Preview 的定位差异很多人把 Hy3 和 Hy4 Preview 理解成“旧版”和“新版”的关系我一开始也这么以为但实际测下来发现它们更像是两条产品线Hy3 是通用文本大模型虽然也有多模态扩展但核心能力还是集中在理解、生成、逻辑推理和知识问答上。Hy4 Preview 则明显往“多模态生成 空间理解”方向走了尤其是 2D 转 3D 这类任务的亮相说明它不只是多学了几个任务而是在表征层面加入了更多视觉空间信息。换句话说Hy3 的 295B 是一个经过了大量真实场景打磨的通用底座工程上相对成熟对显存和推理时延的要求也更可控。Hy4 Preview 的 770B 则是在通用能力基础上把视觉、3D、长上下文和多步工具调用这些能力揉到了一起。这种定位差异决定了它们的适配场景完全不同。1.2 为什么用“跃迁”而不是“升级”我比较反感动不动就说“跨越式升级”但这次从模型结构角度看确实更像一次跃迁。原因主要有三点一是参数规模上了一个新的量级。295B 到 770B虽然很多人会拿“MoE 总参数大有水分”来质疑但总参数变大意味着可用的专家组合、知识容量和注意力头容量都更宽裕。尤其对于长尾知识、多语种、复杂推理类任务参数容量带来的提升不是线性的而是会在某些难度区间形成质变。二是能力的组合方式变了。Hy3 时代你要做文生图可能要外接一个扩散模型要做 3D 资产又要再接一套重建流程。Hy4 Preview 给我的感觉是它试图在一个模型内完成更多“从理解到生成”的闭环。这样带来的好处不只是少几个接口而是理解任务的目标可以直接影响生成结果不需要在多个模型之间反复传递中间表示。三是工程代价完全不在一个量级。这里说的“跃迁”也包括负面意义上的跃迁。770B 的部署成本和推理成本比 295B 高出一大截如果模型没有带来足够的生产力提升那这笔账大概率是算不过来的。1.3 谁最该关注这次变化先给读者做个定位方便大家决定要不要继续往下看。如果你是大模型应用层的开发者正在做知识库问答、Agent、长文档分析我建议你重点看第 2 章和第 5 章。如果你负责推理平台或者模型部署重点看第 3 章的显存和配置推算。如果你做的是 AIGC 工具尤其是图片转 3D、生成式设计这类重视觉任务那第 4 章应该对你有参考价值。如果你是老板或者技术管理者想判断要不要升级到新模型我建议先看完第 6 章的选型速查表再决定预算怎么花。2. 从 295B 到 770B参数背后的能力边界发生了什么变化2.1 更大的总参数到底买到了什么业内对“参数膨胀”一直有争议因为在一个 MoE 架构里总参数量大不等于每次推理都激活这么多参数。以常见的稀疏专家模型为例总参数里大部分是各个专家的权重真正每次计算只路由到其中的一部分专家。Hy3 的 295B 和 Hy4 Preview 的 770B实际激活参数可能并不会同步翻倍这是为什么有人会说“总参数字面上涨意义不大”。但从我的测试经验看总参数仍然非常关键。一个直觉类比是一个公司可以有很多不常出面的专家虽然每处理一个项目只调几个专家过来但专家库越大能覆盖的疑难杂症就越多。Hy4 Preview 的专家数量大概率比 Hy3 更多专家分工也可能更细所以在多语种、垂直领域术语、复杂代码、多模态对齐这些方面它能兜住的边缘情况明显更多。我做了个很土的测试把一堆长尾产品手册、方言口语对话、带噪声的扫描件丢给两个模型做信息抽取。Hy3 已经表现不错但在一些极不规范的表述上会“一本正经地胡编”Hy4 Preview 在面对同样输入时明显更倾向于引用原文或者承认信息不足而不是硬给一个看似完整的答案。这就是大参数容量带来的“知识边界感”也就是模型能意识到自己不知道什么。2.2 架构上可能动了哪些“看不见的地方”由于 Hy4 Preview 还没有完全公开技术报告级别的细节我下面这部分是基于实测和行业对新一代 MoE 模型的通用观察做的推断不一定和官方最终描述完全一致但方向大概率不会偏太多。第一路由策略应该做了调整。295B 规模的 MoE 通常会把输入路由到少数几个专家但太大参数的模型如果还沿用粗粒度路由容易出现专家负载不均衡甚至某些专家沦为“死专家”。Hy4 Preview 给我的感受是它在不同任务上的行为一致性更高了这背后很可能是用了更细粒度的专家切分或者引入了额外的负载均衡约束。第二共享专家和专用专家的配比可能有变化。一类是几乎所有 token 都会经过的共享专家负责通用语法、句法、基础逻辑另一类是各管一摊的专用专家负责代码、数学、多语种、视觉。Hy3 时代这种分工已经存在但 Hy4 Preview 的高参数量允许它塞入更多专用专家同时不牺牲共享专家的基础能力。这也是为什么它在通用对话和垂直任务上同时有不错表现。第三视觉和空间表征可能不再只是“把图片切块后当成文本 token”来处理。传统多模态模型会把图片经过一个 vision encoder 转成若干向量再拼进文本序列这种方式对理解一张图是够用的但对“生成 3D 资产”这类任务是不够的。因为 3D 重建需要的是连续的几何信息、深度和视角关系而不是离散的语义标签。Hy4 Preview 的 2D 转 3D 能力能落地说明它在架构层面大概率加入了更接近三维重建的表征模块。这一点如果后续开源细节出来非常值得单独写一篇拆解。第四KV Cache 的管理策略更重了。参数量变大通常伴随着层数、注意力头数的增加这会直接推高 KV Cache 的显存占用。Hy4 Preview 如果还想做长上下文那就必须在注意力机制上做文章比如引入某种形式的跨层 KV 共享、滑动窗口注意力或者更激进地压缩历史 token 的缓存。从我拿到的上下文行为来看它在超长文档中前文遗忘的现象比 Hy3 轻很多这明显不是靠蛮力堆显存能实现的。2.3 上下文能力与多模态输入的连锁影响参数规模变大之后上下文长度也会跟着成为一个重点指标。原因很简单一个更大的模型如果能读完整本产品手册再做回答那它的生产价值远高于只能读摘要的模型。Hy4 Preview 在长文档上的优势实测下来不只是“记得住开头”而是能够把散布在文档不同章节的信息交叉引用起来这一点对法律文书、论文综述和复杂项目报告类任务尤其重要。多模态输入也会进一步“吃掉”上下文空间。一张高分辨率图片如果被转成几百个 token那一次对话塞入十张图可能就已经是几万 token 的消耗。Hy3 时代多模态输入常常需要提前压缩或者裁剪否则很容易超过窗口上限。Hy4 Preview 在这方面给我的感觉是它在输入压缩上做了更多工作图片和文本的 token 配比更合理不会出现“一张图占掉半屏”的情况。这个变化对生产系统有个直接好处你可以在一次请求里同时放入“参考图片 技术规格 约束描述”让模型一次性输出一个结构化方案。这在 2D 转 3D 场景里非常重要因为用户经常需要提供多视角参考图再附加材料和风格要求。如果上下文窗口不够大就得把输入的图片分辨率降得很低最终生成物的细节自然也会受影响。3. 部署视角把 770B 跑起来需要付出什么3.1 显存需求怎么算很多团队看到 770B 的第一反应是“我连模型都装不下”。这个直觉没错但要分情况看。如果使用 BF16 精度保存全部权重参数量每 1B 大约需要 2GB 显存那么 770B 的权重就要约 1540GB折合下来至少需要 11 张 H200141GB 版本才放得下。如果换成 FP8 量化权重占用可以降到约 770GB8 张 H200 才能勉强装上。但权重只是第一步。推理过程中还需要预留中间激活值和 KV Cache。KV Cache 的占用和序列长度、batch size、层数、注意力头配置强相关粗略估算公式是KV Cache 占用 2 × 层数 × KV 头数 × 头维度 × 序列长度 × 每元素字节数举个例子假设一个模型是 32 层、8 个 KV 头、每个头维度 128用 FP16 存 KV那么每个 token 大约要占 128KB。如果同时处理 16 个用户、每个用户上下文 32K token那么 KV Cache 总量大约是 16 × 32K × 128KB 64GB。这个规模已经不能忽视了。Hy4 Preview 如果想开很长的上下文KV Cache 的优化能力基本决定了它能不能在真实业务里跑起来而不是只能作为离线评测玩具。3.2 我建议的中小团队部署配置如果你所在的团队不想一上来就建一个几十卡的大集群我建议按下面的优先级来规划。第一版先别追求最长上下文和最大并发目标应该是“能稳定把模型跑起来”。就现在的存储和显存情况FP8 量化是性价比很高的选择推荐配置可以按照“权重占用 预留 30% 到 50% 的 KV Cache/激活空间”来算。如果用 H200 141GB 的卡单机 8 卡总显存约 1128GBFP8 权重约 770GB剩下的约 358GB 留给 KV Cache单用户 32K 级别的短会话场景基本够用。但如果你的场景是几十个用户同时长文本对话就需要扩到 16 卡甚至更多。如果你只能用 A100/H 系列但单卡显存只有 80GB那 8 卡也才 640GB连 FP8 权重都放不下。这种情况下要么上 INT4 量化要么接受更低的并发和更短的上下文。我的建议是别硬撑直接上多机方案或者用 Tensor Parallelism 把模型切到更多卡上。张量并行虽然会引入通信开销但 770B 这种规模本身就没法靠单卡解决所以一定要在框架层规划好“切分粒度”。3.3 实测下来的关键推理参数经验值在投入生产之前下面几个参数我建议你优先调温度temperature。Hy4 Preview 的生成倾向比某些高随机性的模型更稳定但温度开太高仍然会破坏结构化输出。做数据抽取、JSON 生成、代码补全时温度建议压在 0.2 以下做创意文案和概念设计时再放宽到 0.7 到 0.9。上下文截断策略。别天真地以为“模型窗口是 128K 就真的能喂满 128K”。实际测试中长上下文的性能会随长度衰减而且推理延迟和 KV Cache 占用会急剧上升。生产环境建议把系统指令、参考文档、历史消息分层管理超过阈值的部分做摘要压缩而不是一股脑塞进去。批量大小batch size。MoE 模型在 batch size 比较大的时候如果专家分布不均衡部分卡会变成热点从而拖慢整体速度。你需要通过观察每张卡的实际利用率来判断要不要降低并发。这个问题在 295B 的 Hy3 时代也存在但到 770B 后会被放大因为单卡需要承载的专家权重更多了。输出长度上限。很多人容易忽略输出长度对推理延迟的影响。Hy4 Preview 在长输出任务上比如生成文章、3D 构建指令本身就能写很长但如果你不设上限模型可能在一个无意义的追问里无限展开。建议业务侧把 max_tokens 控制在一个符合任务预期的范围内比如客服回复 512长文写作再开到 4096。4. 生产力落地Hy4 Preview 为什么能扛起 2D 转 3D 这类重活4.1 2D 转 3D 的本质从视觉理解到空间生成最近“Hy4 2D 转 3D”这个功能讨论度很高很多人把它当成一个娱乐向玩法拿一张二次元图片试了试就完了。但如果从生产力角度去理解2D 转 3D 其实是一个非常典型的“高复杂度多模态任务”它要求模型同时具备三个能力准确识别图片里的物体类别和边界推断图片中没有直接画出来的背面、侧面和深度关系把推断结果转化为可被渲染引擎使用的几何数据。Hy3 那个量级能不能做其实也能做一部分但在复杂物体、遮挡区域和材质推断上很容易翻车。Hy4 Preview 的 770B 参数为这个任务提供了更大的几何先验容量。你可以把它理解成模型见过足够多的“同一个物体的多视角图片”所以当它只看到正面图片时也能根据数据库中的先验知识把背面补齐。另外2D 转 3D 对模型规模的要求远高于普通文本问答。文本任务里你只需要在语义空间里做映射而 3D 任务里模型要输出的是连续的坐标、网格拓扑和纹理坐标。这个输出空间比 token 空间复杂得多需要大量参数去隐式记忆物体结构。这也是为什么很多人拿小模型做 2D 转 3D 时总觉得生成物像是“糊了一层泥巴”的模型而 Hy4 Preview 生成的结果在轮廓和细节上明显更清楚。4.2 一条可复现的生产链路参考我最近在一个内部工具里试了用 Hy4 Preview 做“从产品草图到可预览 3D 资产”的流程整体链路大概是这样原始图片/草图 → 多模态理解 → 生成深度图/法线图 → 网格重建 → 精简拓扑 → 贴图生成 → 引擎预览第一步把设计草图或多视角参考图发给模型同时附上一段明确需求比如“这是一个小型消费电子产品需要生成可用于 720 度浏览的 3D 白模忽略背景”。第二步让模型先生成深度图和不同角度的预测视图这个阶段输出的中间结果非常关键如果深度关系错了后续重建再怎么修都救不回来。第三步把预测结果喂给重建模块生成粗模然后再到 Hy4 Preview 里做语义化修正让模型识别“哪块是屏幕、哪块是外壳圆角、哪块是接口”。第四步进行网格简化。刚生成的 3D 资产面数往往非常高直接放进游戏引擎或电商展示页会卡。一般需要把面数降到原始模型的 20% 到 30%同时保持视觉轮廓。第五步生成贴图和材质参数。这里 Hy4 Preview 可以输出一些 PBR 参数的初始值粗糙度、金属度、基础色这些不一定能用 Final 版本但能省掉美术从零开始调底子的时间。整个流程里最容易被忽略的是“面向模型需求去整理输入”。很多人习惯丢一张图进去就期待完美结果但实际生产时输入图片的拍摄角度、光线一致性、背景干扰都会严重影响输出。我建议把产品图统一到白底、均匀光照、偏正视角再加一句“输出时不要包含背景物体”。这样成功率会大幅提高。4.3 只是 2D 转 3D 吗还有哪些生产力场景Hy4 Preview 的价值如果只被总结成“更会做 3D”那就太可惜了。770B 的底子给生产工具带来的变化是全方位的。一个是复杂文档理解。我拿真实业务场景里的几十页 PDF 合同做过对比Hy3 能定位到关键条款但如果合同里存在多个引用、交叉定义它偶尔会把两处相似条款搞混。Hy4 Preview 在这类交叉引用场景里的准确率明显更高。做合规审查、尽调报告这类工作的团队应该能感受到差异。另一个是 Agent 工具调用。参数规模上来之后模型对工具选择的判断更稳定了。以前让模型自己决定“该查数据库还是该调计算器”小模型经常会选错或者把参数格式写坏。Hy4 Preview 在“规划 → 调工具 → 观察结果 → 再规划”的多轮循环里显得更不容易断线。这一点对于所有做自动化工作流的团队都很重要。还有一个容易被忽视的方向是代码解释和异步生成。770B 模型可以一次性把“需求文档 现有代码 设计约束”都纳入上下文然后给出一个跨文件的修改方案。它不是简单补全代码而是在“理解整个仓库上下文”后再动手。对大型项目而言这种能力比单纯生成单文件函数实用得多。5. 实操中的避坑笔记从离线评测到业务接入5.1 评测别只盯榜单要看任务分布Hy4 Preview 出来后很多人第一时间会拿公开榜单说事比如比 Hy3 又高了多少分。但作为长期做落地的人我劝你别直接用榜单分数来定选型。榜单任务的分布和真实业务往往差距很大。我建议的做法是拿你自己业务里最典型的 200 到 500 条样本跑一个“小规模盲测”。分成三类短文本理解、长文档问答、多模态输入。短文本理解看它能不能守住 Hy3 的水平长文档问答看它有没有明显的前后矛盾多模态输入看你场景中图片占比高不高。如果你根本没有多模态需求那 Hy4 Preview 带来的提升可能有限这时候多花钱上大模型就不划算。5.2 别拿 Hy3 的调优经验直接套 Hy4 Preview我犯过一个很典型的错误把 Hy3 时代调好的提示词和参数模板直接用到 Hy4 Preview 上结果效果反而变差了。原因不复杂Hy4 Preview 对指令的理解更微观有时候你不需要像对 Hy3 那样在提示词里反复强调“请务必”、“如果不确定就说明”而 Hy4 Preview 对隐含意图的捕捉更强如果你给的指令太啰嗦反而会引入不必要的噪音。同时Hy4 Preview 在不同任务上对 JSON 等结构化格式的遵循度更高所以你可以把原来“五段式提示词”压缩成“要求 输出格式 示例”它一样能给出高质量结果。我建议在切换到新模型时至少留出一到两周做提示词回归不要指望无缝平移。5.3 量化与推理框架的避坑建议770B 要上生产量化基本是不可避免的。但我觉得有一个“精度回退检测”的步骤不能省。当你把模型从 BF16 切到 FP8 或者 INT4 之后要找一批边界样本重新测比如数学计算、代码执行、长文档里的精确引用等。因为量化最容易损失的恰恰是那些对数值精度敏感的细粒度任务。视觉输出、文生图方向的任务有些模型量化之后反而问题不大但文本逻辑链路里一点点误差就会滚雪球。推理框架也要记得开启 continuous batching 和 paged attention 这类优化。770B 模型的单请求吞吐很低如果没有好的 batching 策略GPU 利用率可能不到两位数。实测下来这类能力对整体成本的影响甚至比模型本身还大。换模型之前先在小流量里对比一下同配置下的吞吐数据和首 token 延迟再做全量切换。5.4 接入业务时的灰度方案我再给一个最实际的建议别搞“一次性全量替换”。Hy3 在线上已经跑得不错的业务可以先开 5% 到 10% 的流量给 Hy4 Preview做一个影子模式也就是让新旧模型同时跑但只把旧模型的结果返回给用户新模型的结果用于质检和对比。这样跑一周你就能看到哪些场景真正受益哪些场景反而劣化。如果影子模式下Hy4 Preview 在客服场景的拒答率高于 Hy3那可能是你的知识库检索链路对上下文压缩太激进给模型的原文不够多。先调检索链路再考虑回滚。这一步能避免很多“升级后线上事故”的尴尬。6. 常见问题排查与选择速查6.1 几个高频问题第一个问题是“为什么我的 32K 上下文跑不起来”。大概率不是模型限制而是你的服务端把 max_tokens 和上下文缓冲设得太高导致 KV Cache 溢出。建议先检查并发数和每条会话的实际平均 token 数看看是不是长尾请求拖垮了显存。第二个问题是“模型输出经常被截断”。这种情况通常不是 bug而是 max_tokens 设得不够或者模型生成时遇到停止符被提早中断。需要区分是哪种情况再加长上限或者调整停止词。第三个问题是“量化后生成质量明显下降”。如果量化方法可靠那可能是边界任务的比例偏高。比如你经常让模型做精确计算那量化损耗就会很致命。解决办法是切回更高精度或者针对计算类任务单独走一个小的专用模型不一定所有任务都靠大模型。第四个问题是“2D 转 3D 结果出现明显畸变”。这时候不要急着怪模型先检查输入图是不是有严重的透视变形、遮挡或者背景干扰。模型对“干净输入”的依赖比你想象中大。如果输入本身是手机随手拍建议先做预处理把物体抠出来、放在纯色背景上再传给模型。6.2 用一张表总结选型建议判断维度继续选 Hy3升级到 Hy4 Preview主要任务短文本、常规问答、结构化信息抽取长文档推理、复杂多模态理解、生成式设计图片/3D 需求基本没有或极低频高频、需要深度理解和空间生成上下文长度8K 到 16K 够用需要 32K 以上且要做多文档交叉团队预算对单次推理成本敏感能接受更高单价换取效果和稳定性工程成熟度线上链路稳定不想动愿意重新做评测、调优和灰度输出结构化要求一般严格 JSON、跨步骤复杂输出表格只是辅助判断最终还是要落到你自己的样本集上。我个人比较推荐的做法是“有条件的话两套都留着”。日常低价值请求继续走 Hy3 路线高价值或者复杂请求再打到 Hy4 Preview。双路架构能照顾性能和成本是当前最稳妥的生产方案。6.3 关于 Hy4 Preview 官网入口和申请测试渠道很多朋友问我去哪里体验 Hy4 Preview。最直接的方式是关注腾讯混元的官网和官方开放平台新模型通常在公开发布后会有体验入口和 API 申请通道。如果你所在的团队已经有腾讯云或者混元的合作账号可以直接在模型服务列表里申请访问权限。2D 转 3D 这类能力不一定在默认文本接口里全部开放可能需要单独开通对应能力所以建议先在控制台看一遍可选模块列表。这里有个容易被忽略的点免费体验入口和商用 API 的模型版本不一定是同一套配置。有些平台会给体验用户加长推理时间或者降低并发所以要验证生产效果最好还是申请真实验证过的接口而不是拿网页 Demo 的输出来评估成本和质量。7. 最后说点我的实际操作体会写到最后我不太想输出那种“未来前景广阔”的废话。更真实的情况是模型从 295B 到 770B能力确实上了一个台阶但它不会自动变成生产力。真正决定项目成败的仍然是数据清洗、评测集、推理优化和提示词工程这些“脏活累活”。我个人在实际操作中的体会有两点。第一给新模型多点耐心。Hy4 Preview 这类大模型在早期往往有环境不稳定、部分能力未完全开放的问题不要因为一两次报错就否定它也不要因为一两个惊艳结果就直接上生产。先用影子模式跑一周让数据说话。第二不管模型多大“输入决定输出”这个铁律一直成立。2D 转 3D 的图不干净生成结果就脏长文档任务不做好分段和检索模型就算有 128K 窗口也救不回来。如果你也在做类似的选型评估希望这篇内容能帮你少踩几个坑。后续等 Hy4 Preview 正式版或者技术细节出来我再补一篇深度拆解。