腾讯混元的 Hy4 Preview 放出消息后我第一反应不是去看榜单分数而是把内部几个业务线在跑的 Hy3 任务全部重新跑了一遍。很多人看到“Hy3 是 295B、Hy4 Preview 是 770B”这个数字对比第一感觉是模型变大了两倍多但我更关心的是这种变大到底是把 Transformer 的每层直接加宽还是架构上换了打法同样是 MoEHy4 Preview 的专家组织方式、注意力机制和训练稳定性和 Hy3 到底差了多少这些架构层面的变化最终又会怎样影响我们做 API 接入和私有化部署时的成本、延迟和效果这篇就当是我个人从 Hy3 迁到 Hy4 Preview 的一份完整迁移笔记从架构原理讲到生产落地把能直接抄作业的部分都放出来。1. 腾讯混元 Hy4 Preview 和 Hy3 差在哪里先分清“模型更大了”和“架构变了”1.1 总参数 295B 到 770B为什么不能简单理解成“能力翻倍”很多朋友第一次听到“770B”下意识会觉得295B 到 770B参数规模翻了将近三倍能力也应该线性暴涨。但做过大模型选型的人都知道这种对比在 MoE 模型上特别容易被带偏。先看总参数的作用。在混合专家结构中总参数决定了模型的知识容量和表达能力的上限。295B 的 Hy3本身已经把常见领域的通识知识覆盖得比较完整了但面对一些非常垂直的领域、冷门语种、长尾格式还是会露出破绽。770B 的 Hy4 Preview 把总参数撑大之后最直接的红利是知识覆盖面更宽能记住的“细节”更多对细粒度指令的区分度也更好。这种提升不像“语文从 90 分到 95 分”那么线性更像是一个容量接近临界点后突然松了一口气。但如果只看总参数你会误以为推理成本也要翻三倍。真正决定单次推理计算量的是模型的激活参数也就是每个 token 真正经过的那部分权重。MoE 模型通过门控网络把 token 路由到不同的专家子网络每次推理只调用其中一部分专家。Hy3 的 295B激活参数在 30B 量级左右而 Hy4 Preview 的 770B我目前从公开信息和实测行为推测激活参数提升并没有按总参数比例暴涨而是控制在一个相对克制的范围。所以正确的理解方式是总参数变大买的是“知识容量”激活参数控制住买的是“可落地的推理成本”。Hy4 Preview 敢以预览版形式开放出来不是因为用了 770B 这个数字博眼球而是它在把容量做大的同时把单 token 的计算代价和显存代价控制在了生产可接受的范围内。1.2 激活参数和总参数的比值看 MoE 架构时第一个要关注的数据评估任何 MoE 大模型我会先算一个简单的比率总参数除以激活参数学术界常叫稀疏度。Hy3 时代这个比率大约是 10 倍意味着平均每 10 个参数里只有 1 个被这个 token 真正读取。770B 的 Hy4 Preview 如果激活参数仍然控制在 40B 到 50B 左右稀疏度就可能到 15 倍甚至 20 倍以上。这个数字代表什么代表每次推理时计算 FLOPS 主要取决于激活参数。激活参数不变或只小幅增加矩阵乘法的体量就不会爆炸式增长。你可以把总参数想象成一家公司的全员花名册里面有三万个人但每次处理一个任务只抽调其中两三千人组成临时项目组。花名册厚了人才类型更全但每次开会的参会人数没有翻倍会议成本自然可控。但这里有个容易被忽视的坑训练和推理的显存占用并不只看激活参数。770B 的模型不管每次激活多少权重都在机器里放着。推理时如果把全部专家都加载进显存单卡放不下必须靠多机多卡做专家并行每张卡负责一部分专家token 要路由到对应卡的对应专家上。这就是 MoE 模型和稠密模型在生产架构上一个本质差别稠密模型可以把权重切到多张卡上做张量并行数据通信相对规整MoE 多了 All-to-All 通信token 可能从一个节点跑到另一个节点。所以“295B 到 770B”对咱们用户侧最直接的影响反而不是单次推理慢了而是部署和调度变复杂了。如果你只是调 API感受是吞吐和响应时间如果做私有化部署得面对更大的集群规模、更重的卡间通信、更严格的网络带宽要求。很多团队在 Hy3 时代用一套 8 卡 A100 可能勉强能转起来换到 Hy4 Preview 就得认真考虑分布式推理架构了这不是模型本身的错而是“总参数”带来的物理约束。2. Hy4 Preview 用了哪些架构升级才让 770B 不再只是 Benchmark 数字2.1 细粒度专家和路由策略从“大而少”到“多而专”Hy3 那代的 MoE专家的设计思路相对传统每个 Transformer 层的 FFN 被横向切分成几个大专家每个专家内部其实还是一个比较宽的 MLP。路由时一般从几十个专家里挑选 top-k 个。这种方式实现简单训练稳定但专家之间容易产生冗余多个专家可能学会了相似的表征挑选哪一个差别不大容量利用效率就有浪费。Hy4 Preview 这一代我能明显感到专家组织的粒度变了。最直观的体感是同样一句提示词模型输出的风格分化更明显代码、数学、公文写作之间的切换比 Hy3 干净利落。这种变化大概率来自更细粒度的专家拆分把每个专家从“宽网络”改成“窄而多”例如把原先 8 个宽专家拆成 64 个窄专家每次仍然激活 6 到 8 个但激活的组合方式变多变灵活了。细粒度专家带来的直接好处是“组合爆炸”。窄专家本身功能更单一路由器可以像搭积木一样为不同任务动态组合出不同的通路。比如遇到代码补全同时激活“语法理解”“上下文跟踪”“API知识”几个窄专家遇到法律文本则换成另一个组合。这种按需组合让总参数不断膨胀的同时还能保持甚至提升激活参数的利用效率是模型在 770B 规模下不至于“钝掉”的关键机制。不过细粒度专家对训练也提出了新挑战。专家越多越容易出现“路由崩溃”现象少数几个专家学得太快门控网络发现走它们 loss 最低于是所有 token 都往这几个专家涌剩下大量专家长期得不到梯度成了摆设。Hy4 Preview 要在 770B 这种规模下保持每个专家都被充分利用一定在负载均衡损失项上做了不少文章。这一点对咱们做应用的人有点远但它决定了模型能力的上限是不是真的被发挥出来了。2.2 长上下文不是靠“无限扩窗”实现的靠的是注意力机制重构Hy3 时代模型也支持比较长的上下文但一旦把输入长度顶到接近窗口上限响应质量会肉眼可见地下滑前文细节记不住、中间层信息被稀释、JSON 格式频繁出错。这不是简单的“注意力窗口不够大”而是原生 Transformer 的注意力机制在长序列下本来就力不从心每个 token 要跟前面所有 token 做交互计算量和显存都按平方级增长。Hy4 Preview 这代从实测看长文本能力明显上了一个台阶尤其是我把几十页技术文档喂进去做结构化抽取的时候它在中后段仍能准确引用前文的细节这种稳定感在 Hy3 上是没有的。背后的架构改动我的理解有两个方向一个是把标准注意力改成分组查询注意力甚至更多头潜在注意力让 K/V 缓存大小降下来另一个是引入稀疏注意力或窗口注意力机制让每个 token 不需要和全序列所有 token 做交互而是先关注局部窗口需要时再通过潜在变量做全局信息聚合。这种改造的真正意义不只是“能塞更多字”而是“长输入不再挤占太多显存”。你可以把标准注意力理解成每个学生都要跟全班每个人交换笔记窗口注意力是小组讨论组内频繁交换跨组信息通过组长汇总。后者明显更适合处理几百 K 字的长文档因为它不再需要把整本教材都摊在桌面上。这对生产环境有直接影响输入长度翻倍如果注意力机制不变KV cache 显存占用也翻倍如果换成细粒度更低的注意力可能只增加一半。Hy4 Preview 敢把上下文窗口拉大说明它在这个维度上做了结构性的减负否则 770B 的权重加上夸张的长序列缓存普通推理集群根本扛不住。2.3 Agent 和结构化输出能力提升才是架构跃迁红利的最终出口从 Hy3 换到 Hy4 Preview我最强烈的感受不是“它知识更多了”而是它在作为 Agent 底层模型时变得可靠了。做过多步工具调用的朋友都知道小模型或老模型最大的问题是“忘”第一步拿到工具返回结果后第二步就把原始任务忘了一半。Hy4 Preview 在多轮工具调用场景里对任务目标、上下文约束和返回格式的执行一致性明显更强。这种能力不太可能是某个单独模块的功劳更像是前面说的总参数容量、注意力机制、专家路由能力结合的产物。Agent 任务本质上需要模型在长上下文中维护多层目标用户原始意图、当前子任务、历史工具返回值、下一步计划。这些信息分散在不同位置模型需要随时跨位置聚合。注意力机制决定了它能不能找到这些信息专家路由决定了它能不能调动合适的能力来处理总参数规模决定了它能装下多复杂的任务状态。Hy4 Preview 这代正好把这三点都往前推了一步。以前做 Agent 架构很多团队喜欢在模型外面套一大堆状态机、记忆模块、规划器来补模型的短板。模型本身更可靠之后外层系统的复杂度反而可以降下来。我在内部测试了个多步骤数据抓取 AgentHy3 跑三步就容易发散Hy4 Preview 可以连续稳定跑完八步这直接改变了我们做 Agent 架构时对模型能力的假设前提。架构跃迁的红利最终不是落在聊天更流畅而是落在这些工程化应用的可靠性上。3. 从 Hy3 迁移到 Hy4 Preview 的完整实操记录和生产适配方案3.1 上线前先跑冒烟测试我设计的五个最小验证任务迁模型最忌讳上来就把所有业务切过去我一般先设计一组冒烟用例用最小的成本判断新模型有没有硬伤。这次我从内部业务里挑出五类典型任务每一类都准备了固定输入和判定标准。第一类是长文档摘要输入一份约 6000 字的行业研究报告要求输出 200 字以内的结构化摘要重点考核它能不能抓住二级结论而非堆砌一级标题。第二类是 JSON 结构化输出给一段非结构化的简历文本要求按预设 JSON Schema 输出字段重点考核格式正确率和字段获取完整度。第三类是代码生成给定一个带有边界条件的编程需求要求生成可直接运行的 Python 函数并附带边界测试。第四类是多轮对话一致性模拟客服连续咨询在第七轮重新询问第一轮提到的订单编号看它是否还记得。第五类是工具调用规划给定三个 API 工具的描述要求它完成一个需要至少三步串行调用的任务。这五类跑下来Hy4 Preview 和 Hy3 的差距非常清晰。长文档摘要上Hy4 Preview 能抓到原文里比较隐蔽的因果逻辑而 Hy3 倾向于“平均用力”把每段都摘一句重点不突出。JSON 输出方面Hy4 Preview 只要给了 Schema连续三十次测试没有一次格式断裂Hy3 偶尔会在嵌套层级较深时漏掉字段。代码生成更是明显Hy4 Preview 对需求中隐含的边界条件理解更到位比如我不说但能推断出“输入可能为空列表”这种场景它会在代码里主动做防御Hy3 则经常忽略。多轮对话一致性上Hy4 Preview 的表现让我比较意外到第七轮还能准确复述第一轮出现的订单号Hy3 在第五轮就开始含糊甚至有一次编造了一个不存在的订单号。工具调用规划更是拉开差距同样一个需要调三个 API 的任务Hy4 Preview 给出的步骤顺序是正确的第一步的输出能被第二步正确引用而 Hy3 给出的方案只有框架缺少参数映射细节。冒烟测试不一定全面但它帮我快速圈定了哪些业务可以先迁移哪些还得再观察。3.2 提示词迁移中我踩的几个坑不是所有 Hy3 提示词都能直接复用迁移工作里最费时间的不是参数配置而是提示词的适配。我原本以为同系列模型提示词可以直接平移实际跑完之后发现有三个地方需要特别注意。第一个坑是“过度约束反而降低效果”。Hy3 时代因为模型指令跟随能力有限我习惯在提示词里加大量约束“你必须一步步思考”“请在回答前仔细检查”“不要使用多余的话”。这些约束在 Hy4 Preview 上反而会触发它的过度推理导致输出冗长、绕圈子。Hy4 Preview 对简洁指令的理解能力更强我现在倾向于把约束精简成一条限制性短语比如“只输出 JSON”或“先给出结论再解释原因”效果反而更好。第二个坑是 few-shot 示例数量可以大幅减少。Hy3 对复杂格式经常需要给 3 到 5 个示例才能稳定输出Hy4 Preview 给 1 个高质量示例就够少数场景零示例也能强行守住格式。这会直接影响 token 成本尤其是每个请求都带大量示例的高频业务光这一项就能省下不少输入 token 开销。但也不能彻底删掉示例在非常垂直的领域里一个示例仍然能帮它校准输出的颗粒度。第三个坑是 system prompt 里的架构性指令要重新设计。Hy4 Preview 因为是更底的模型基座对系统提示词的遵从度更高但也更在意指令之间的优先级。如果把“你是一个友好的助手”和“严格按照 JSON 格式输出”混在同一条 system prompt 里它可能更倾向于先满足角色设定而忽略格式。我调整后的做法是把系统提示词分成两段第一段定义角色和语气第二段用硬性条款列表定义输出契约中间用换行隔开。这样处理后格式稳定性提升明显。3.3 评测集和回归方法用二十个固定用例卡住效果底线提示词调完之后不能只靠人工看几个例子就决定上线。我会维护一个固定评测集二十个用例覆盖摘要、抽取、生成的正确性、格式合规、多轮一致性、工具调用六类能力。把 Hy3 和 Hy4 Preview 都跑一遍记录两个指标任务成功率以及结果的人工评分。我的做法比较朴素但有效。先让 Hy3 基于旧提示词跑一遍评测集记录每个用例的输出和评分。然后把 Hy3 的提示词迁移到 Hy4 Preview跑第二遍记录评分。接着针对 Hy4 Preview 中明显失分的用例单独调整提示词再跑第三遍。对比三份记录能同时看出模型本身的能力变化和提示词适配带来的增量。以 JSON 输出为例我评测集里专门设置了三个嵌套层次的用例。Hy3 在两层嵌套时表现尚可三层嵌套时偶发键缺失Hy4 Preview 第一遍跑三层嵌套就已经完全合规后来我把 Schema 里的字段名换成更接近业务语义的名称它也能准确映射。这类用例说明 Hy4 Preview 在底层指令跟随上确实有代际提升不是简单的“更聪明了”而是“更能按规矩办事了”。评测集建好之后要固化下来每次新版本模型发布都跑一遍。很多团队换模型只做一次抽样验证结果上线后某个冷门场景突然崩了就是因为没有建立长期回归机制。我的习惯是把这个评测集做成一个脚本输入是一组 JSON 请求输出是一份评分表每次模型更新后跑一次两小时能出结果非常值得投入。4. 770B 模型上生产后绕不开的几个现实问题延迟、成本、上下文与灰度4.1 延迟与并发你测的是单请求 P50用户感受到的是 P95Hy4 Preview 在 API 调用时的延迟表现和 Hy3 相比并非完全线性。单次短请求Hy4 Preview 和 Hy3 的响应速度差异不算大因为都受激活参数主导但一旦请求变成长文本Hy4 Preview 的延迟优势反而会体现出来得益于它对 KV cache 的优化。我们内部压测里一份约 8000 token 的输入Hy4 Preview 的首 token 延迟比 Hy3 低了约两成这在长文档处理场景中非常重要。但延迟不能只看平均值。MoE 模型在并发升高后路由会把请求分散到不同专家上如果某个专家恰好成为热点部分请求就会明显变慢。我在并发压测时发现Hy3 在并发 20 左右时 P95 延迟开始明显抬升而 Hy4 Preview 因为专家数量更多热点分散能力更强并发容忍度更高。这意味着在同样的业务压力下Hy4 Preview 反而不需要你准备太高的超时阈值。不过这里的注意点是如果你走的是 API 而非私有化部署最终延迟表现还取决于服务端当前的负载、排队策略和你的套餐等级。不要只看模型本身的单测数据一定要在你真实业务的输入分布下重新压测。我的经验是拿生产环境最近一周的请求日志做采样回放分别记录 P50、P90、P95 三档延迟这样判断是否满足用户体验要求才靠谱。4.2 调用架构需要跟着模型一起改吗微服务边界可以不动但超时和降级必须重设很多团队听到“770B”第一反应是重构整套上层系统。从我这次迁移的体验看如果你已经把大模型能力封装成独立的微服务模块业务层基本不用动真正需要重新设计的是两个横切面超时策略和降级策略。Hy3 时代我们给大模型服务配置的超时上限是 60 秒因为长文本生成偶尔会慢。到了 Hy4 Preview由于模型对长输入的预处理速度更快其实可以把超时上限缩到 45 秒但首 token 超时要从原来的 10 秒放宽到 15 秒左右避免在复杂推理场景下误杀。这些参数如果不调整可能出现一个奇怪现象总耗时没超时但首 token 等久了被自己前面的代理层断掉。降级策略更要提前设计。我的建议是不要把 Hy4 Preview 设成唯一依赖而是在它后面保留一条小模型兜底链路。当 770B 服务出现排队或限流时自动把低优先级、低难度请求切到 Hy3 或更小的模型。我们内部的降级条件是按延迟触发的如果 P95 超过 3 秒且持续 5 分钟就启动降级把标题生成、短文本分类这类简单任务切到小模型只保留复杂推理在高成本模型上。这套机制让我们的整体可用性在模型切换期间保持在 99.5% 以上。微服务架构层面我没有为 Hy4 Preview 单独搭建新的服务模块。大模型网关本身做了接口兼容。如果你之前把模型版本写死在代码里这次正好是重构的机会建议把所有模型调用都收敛到一个统一的 model gateway 上通过配置项切换模型版本而不是在业务代码里改 URL。这是老生常谈但我见过太多团队在换模型时临时改调用地址结果三个月后根本不知道自己线上跑的是哪个版本。4.3 2D 转 3D 等多模态能力的接入路径别把文本推理和生成能力混为一谈Hy4 Preview 相关的热搜词里“2D 转 3D”被频繁提及我看到不少朋友在问接入了 Hy4 Preview 的文本 API是不是就能直接用上 2D 转 3D 的能力这里的理解误区在于2D 转 3D 一般不是文本大模型本身的能力它背后是独立的图片理解与 3D 生成模型和文本模型共享的更多是品牌、入口和用户体系而非同一个权重文件。从架构角度看2D 转 3D 任务通常走的是“多模态编码器 3D 生成模块”的链路输入是图片输出是 3D 模型文件或神经隐式场。文本大模型在其中扮演的角色不是生成 3D 模型而是理解用户指令、提取图片描述、规划生成参数更多是“调度大脑”而非“生成主力”。所以如果你要做一个 2D 转 3D 的工具型产品需要同时接入两个通道文本模型负责指令理解专门的 3D 生成模型负责资产产出两者之间通过异步任务队列串联。我在迁移时把 2D 转 3D 这类多模态任务单独建了一条流水线和纯文本业务的架构完全分开。用户上传图片后先用一个轻量的图片理解模型生成结构化描述再把描述送到 Hy4 Preview 做参数规划和步骤拆解最后交给 3D 生成服务执行。这种分工的好处是每个环节都能独立升级将来 3D 生成模型更新时不用重新验证文本链路。多模态接入的稳定性和单模态不同文件上传、任务轮询、结果下载这些环节都要有超时和重试机制不能在网关层一刀切设置超时时间。4.4 灰度发布顺序先内部工具再低价值业务最后才是核心链路模型切换最大的风险不是模型效果变差而是“突然全量切换出问题了不知道回滚到哪里”。我的灰度策略分三步走每一步都有明确的退出条件。第一步是内部使用让产品、运营、研发同学在日常工作中用 Hy4 Preview 辅助写文档、做总结、写代码。这一步的目的不是验证效果而是收集真实使用中暴露的异常行为比如格式错乱、内容空洞、重复输出。如果内部使用一周没有发现系统性 bug进入第二步。第二步选一个低价值但流量较大的业务灰度比如站内搜索的“相关推荐理由生成”。这类业务的特殊性在于出错不会造成损失但请求量大能快速暴露模型在并发和成本上的问题。灰度比例先放到 10%观察一天看延迟和错误率如果没有异常放到 50%再看一天确认平稳后再放 100%。第三步才轮到核心业务但也不是一次切完。核心业务要先做一轮完整的回归测试包括提示词效果、异常兜底、数据结构兼容性确认无误后新流量切 20%老流量留在 Hy3持续观察至少一周。如果这期间出现任何超过阈值的失败率立刻把模型版本回退到 Hy3再根据日志定位问题。模型切换不是发布会不需要“零时差全量切换”稳比快重要得多。5. 实际决策哪些项目应该留在 Hy3哪些必须切 Hy4 Preview5.1 任务复杂度匹配高频简单任务留在小模型复杂推理才配得上 770B做技术选型不能只看“新模型更强就全员迁移”还要看成本效率。我见过不少团队把简单分类任务也送到超大模型上结果效果没提升多少费用翻了好几倍。Hy4 Preview 的 770B 并不是为所有任务设计的它的优势集中在复杂推理、长文本理解、多步工具调用、高难度代码生成这些场景。如果你手头的业务只是短文本情感分类、关键词提取、标题生成Hy3 甚至更小的模型完全够用。我用一组短文本分类任务做过对比Hy4 Preview 和 Hy3 的准确率都在 95% 左右差距不到 1 个百分点但成本相差数倍。这种情况下强行切换到 Hy4 PreviewROI 就很差。反过来如果你的业务涉及长文档的知识密集提取、需要多步推理的智能客服、代码库级理解与生成或者 Agent 式任务规划Hy4 Preview 的能力优势会非常明显地转化为业务指标。我在一个合同审查项目中测试Hy3 只能抽出显式条款Hy4 Preview 能推断出潜在的风险点这一步差距直接决定了项目能不能落地。任务复杂度是选择模型的第一标准不要被参数数字带着跑。5.2 成本测算方法把输入输出 token 分布和缓存命中率算进去关于成本我不想给出具体价格因为各家套餐和优惠差异太大但测算逻辑是通用的。换到更大的模型之前先取生产环境一周的日志统计平均输入 token 数、平均输出 token 数和日均请求量再乘以不同模型的单价就能得到一天的预估费用。但有几个容易被忽略的隐性成本项。第一是提示词膨胀Hy4 Preview 对示例数量的需求下降输入 token 会减少这是省钱项第二是输出 token 可能变多因为它更容易把话说完整如果前文提到过“回答要克制”输出量能压下来第三是重试率Hy4 Preview 格式错误率低意味着重试次数少也能间接省成本第四是缓存命中率如果网关层开启了 prompt caching高频请求的公共前缀可以被缓存这部分优化在长输入场景的收益很明显。我的建议是不要只看单价要按“完成一个任务的总成本”来算。比如摘要任务Hy3 可能由于理解不足需要你调用两次并做结果融合Hy4 Preview 一次就能搞定尽管单次更贵但完成度更高总成本反而更低。拿真实业务数据跑一周再算这笔账才算把成本测算做到位。5.3 个人建议的混合模型架构让不同量级的模型各司其职这次迁移让我最终形成了一套混合模型架构的思路不打算再追求“一个模型打天下”。我在模型网关层配置了三级路由简单任务走小模型或 Hy3中复杂度任务走 Hy3高复杂度任务才走 Hy4 Preview。路由规则不是纯靠关键词硬匹配而是用一个小模型做意图分类器先判断请求属于“快速任务”“标准任务”还是“深度任务”。比如一句话翻译走小模型普通摘要走 Hy3合同风险点分析和多步代码生成走 Hy4 Preview。这样做的好处是成本可控、延迟可控同时能在核心场景享受架构跃迁带来的能力红利。这种混合架构也给未来留下了扩展空间以后如果出现 1T 参数的更大模型我不需要改业务代码只需要在网关配置里增加一个更高优先级的模型通道把真正的复杂任务指过去就行。模型架构在变应用侧的架构要保持稳定。最后想说的从 Hy3 的 295B 到 Hy4 Preview 的 770B这次升级真正打动我的不是参数数字本身而是背后“容量变大但成本可控”的架构思路。MoE 的路由粒度变细了、注意力机制的显存负担降下来了、长上下文和工具调用能力变稳了这些变化叠加在一起才让大模型从“能聊天”走向了“能承担核心生产任务”。如果你也在做迁移决策我个人的习惯是让简单任务留在小模型把难任务交给大模型中间用模型网关做统一调度先灰度再全量每步都留好回滚开关。技术选型没有绝对的“最优”只有适合你当前业务场景的“最稳”。Hy4 Preview 这代给我们的启示其实是大模型能力的边界正在从“生成得更像人”扩展到“执行得更可靠”而可靠性才是生产力落地的真正前提。
从Hy3到Hy4 Preview：腾讯混元大模型迁移实战笔记
腾讯混元的 Hy4 Preview 放出消息后我第一反应不是去看榜单分数而是把内部几个业务线在跑的 Hy3 任务全部重新跑了一遍。很多人看到“Hy3 是 295B、Hy4 Preview 是 770B”这个数字对比第一感觉是模型变大了两倍多但我更关心的是这种变大到底是把 Transformer 的每层直接加宽还是架构上换了打法同样是 MoEHy4 Preview 的专家组织方式、注意力机制和训练稳定性和 Hy3 到底差了多少这些架构层面的变化最终又会怎样影响我们做 API 接入和私有化部署时的成本、延迟和效果这篇就当是我个人从 Hy3 迁到 Hy4 Preview 的一份完整迁移笔记从架构原理讲到生产落地把能直接抄作业的部分都放出来。1. 腾讯混元 Hy4 Preview 和 Hy3 差在哪里先分清“模型更大了”和“架构变了”1.1 总参数 295B 到 770B为什么不能简单理解成“能力翻倍”很多朋友第一次听到“770B”下意识会觉得295B 到 770B参数规模翻了将近三倍能力也应该线性暴涨。但做过大模型选型的人都知道这种对比在 MoE 模型上特别容易被带偏。先看总参数的作用。在混合专家结构中总参数决定了模型的知识容量和表达能力的上限。295B 的 Hy3本身已经把常见领域的通识知识覆盖得比较完整了但面对一些非常垂直的领域、冷门语种、长尾格式还是会露出破绽。770B 的 Hy4 Preview 把总参数撑大之后最直接的红利是知识覆盖面更宽能记住的“细节”更多对细粒度指令的区分度也更好。这种提升不像“语文从 90 分到 95 分”那么线性更像是一个容量接近临界点后突然松了一口气。但如果只看总参数你会误以为推理成本也要翻三倍。真正决定单次推理计算量的是模型的激活参数也就是每个 token 真正经过的那部分权重。MoE 模型通过门控网络把 token 路由到不同的专家子网络每次推理只调用其中一部分专家。Hy3 的 295B激活参数在 30B 量级左右而 Hy4 Preview 的 770B我目前从公开信息和实测行为推测激活参数提升并没有按总参数比例暴涨而是控制在一个相对克制的范围。所以正确的理解方式是总参数变大买的是“知识容量”激活参数控制住买的是“可落地的推理成本”。Hy4 Preview 敢以预览版形式开放出来不是因为用了 770B 这个数字博眼球而是它在把容量做大的同时把单 token 的计算代价和显存代价控制在了生产可接受的范围内。1.2 激活参数和总参数的比值看 MoE 架构时第一个要关注的数据评估任何 MoE 大模型我会先算一个简单的比率总参数除以激活参数学术界常叫稀疏度。Hy3 时代这个比率大约是 10 倍意味着平均每 10 个参数里只有 1 个被这个 token 真正读取。770B 的 Hy4 Preview 如果激活参数仍然控制在 40B 到 50B 左右稀疏度就可能到 15 倍甚至 20 倍以上。这个数字代表什么代表每次推理时计算 FLOPS 主要取决于激活参数。激活参数不变或只小幅增加矩阵乘法的体量就不会爆炸式增长。你可以把总参数想象成一家公司的全员花名册里面有三万个人但每次处理一个任务只抽调其中两三千人组成临时项目组。花名册厚了人才类型更全但每次开会的参会人数没有翻倍会议成本自然可控。但这里有个容易被忽视的坑训练和推理的显存占用并不只看激活参数。770B 的模型不管每次激活多少权重都在机器里放着。推理时如果把全部专家都加载进显存单卡放不下必须靠多机多卡做专家并行每张卡负责一部分专家token 要路由到对应卡的对应专家上。这就是 MoE 模型和稠密模型在生产架构上一个本质差别稠密模型可以把权重切到多张卡上做张量并行数据通信相对规整MoE 多了 All-to-All 通信token 可能从一个节点跑到另一个节点。所以“295B 到 770B”对咱们用户侧最直接的影响反而不是单次推理慢了而是部署和调度变复杂了。如果你只是调 API感受是吞吐和响应时间如果做私有化部署得面对更大的集群规模、更重的卡间通信、更严格的网络带宽要求。很多团队在 Hy3 时代用一套 8 卡 A100 可能勉强能转起来换到 Hy4 Preview 就得认真考虑分布式推理架构了这不是模型本身的错而是“总参数”带来的物理约束。2. Hy4 Preview 用了哪些架构升级才让 770B 不再只是 Benchmark 数字2.1 细粒度专家和路由策略从“大而少”到“多而专”Hy3 那代的 MoE专家的设计思路相对传统每个 Transformer 层的 FFN 被横向切分成几个大专家每个专家内部其实还是一个比较宽的 MLP。路由时一般从几十个专家里挑选 top-k 个。这种方式实现简单训练稳定但专家之间容易产生冗余多个专家可能学会了相似的表征挑选哪一个差别不大容量利用效率就有浪费。Hy4 Preview 这一代我能明显感到专家组织的粒度变了。最直观的体感是同样一句提示词模型输出的风格分化更明显代码、数学、公文写作之间的切换比 Hy3 干净利落。这种变化大概率来自更细粒度的专家拆分把每个专家从“宽网络”改成“窄而多”例如把原先 8 个宽专家拆成 64 个窄专家每次仍然激活 6 到 8 个但激活的组合方式变多变灵活了。细粒度专家带来的直接好处是“组合爆炸”。窄专家本身功能更单一路由器可以像搭积木一样为不同任务动态组合出不同的通路。比如遇到代码补全同时激活“语法理解”“上下文跟踪”“API知识”几个窄专家遇到法律文本则换成另一个组合。这种按需组合让总参数不断膨胀的同时还能保持甚至提升激活参数的利用效率是模型在 770B 规模下不至于“钝掉”的关键机制。不过细粒度专家对训练也提出了新挑战。专家越多越容易出现“路由崩溃”现象少数几个专家学得太快门控网络发现走它们 loss 最低于是所有 token 都往这几个专家涌剩下大量专家长期得不到梯度成了摆设。Hy4 Preview 要在 770B 这种规模下保持每个专家都被充分利用一定在负载均衡损失项上做了不少文章。这一点对咱们做应用的人有点远但它决定了模型能力的上限是不是真的被发挥出来了。2.2 长上下文不是靠“无限扩窗”实现的靠的是注意力机制重构Hy3 时代模型也支持比较长的上下文但一旦把输入长度顶到接近窗口上限响应质量会肉眼可见地下滑前文细节记不住、中间层信息被稀释、JSON 格式频繁出错。这不是简单的“注意力窗口不够大”而是原生 Transformer 的注意力机制在长序列下本来就力不从心每个 token 要跟前面所有 token 做交互计算量和显存都按平方级增长。Hy4 Preview 这代从实测看长文本能力明显上了一个台阶尤其是我把几十页技术文档喂进去做结构化抽取的时候它在中后段仍能准确引用前文的细节这种稳定感在 Hy3 上是没有的。背后的架构改动我的理解有两个方向一个是把标准注意力改成分组查询注意力甚至更多头潜在注意力让 K/V 缓存大小降下来另一个是引入稀疏注意力或窗口注意力机制让每个 token 不需要和全序列所有 token 做交互而是先关注局部窗口需要时再通过潜在变量做全局信息聚合。这种改造的真正意义不只是“能塞更多字”而是“长输入不再挤占太多显存”。你可以把标准注意力理解成每个学生都要跟全班每个人交换笔记窗口注意力是小组讨论组内频繁交换跨组信息通过组长汇总。后者明显更适合处理几百 K 字的长文档因为它不再需要把整本教材都摊在桌面上。这对生产环境有直接影响输入长度翻倍如果注意力机制不变KV cache 显存占用也翻倍如果换成细粒度更低的注意力可能只增加一半。Hy4 Preview 敢把上下文窗口拉大说明它在这个维度上做了结构性的减负否则 770B 的权重加上夸张的长序列缓存普通推理集群根本扛不住。2.3 Agent 和结构化输出能力提升才是架构跃迁红利的最终出口从 Hy3 换到 Hy4 Preview我最强烈的感受不是“它知识更多了”而是它在作为 Agent 底层模型时变得可靠了。做过多步工具调用的朋友都知道小模型或老模型最大的问题是“忘”第一步拿到工具返回结果后第二步就把原始任务忘了一半。Hy4 Preview 在多轮工具调用场景里对任务目标、上下文约束和返回格式的执行一致性明显更强。这种能力不太可能是某个单独模块的功劳更像是前面说的总参数容量、注意力机制、专家路由能力结合的产物。Agent 任务本质上需要模型在长上下文中维护多层目标用户原始意图、当前子任务、历史工具返回值、下一步计划。这些信息分散在不同位置模型需要随时跨位置聚合。注意力机制决定了它能不能找到这些信息专家路由决定了它能不能调动合适的能力来处理总参数规模决定了它能装下多复杂的任务状态。Hy4 Preview 这代正好把这三点都往前推了一步。以前做 Agent 架构很多团队喜欢在模型外面套一大堆状态机、记忆模块、规划器来补模型的短板。模型本身更可靠之后外层系统的复杂度反而可以降下来。我在内部测试了个多步骤数据抓取 AgentHy3 跑三步就容易发散Hy4 Preview 可以连续稳定跑完八步这直接改变了我们做 Agent 架构时对模型能力的假设前提。架构跃迁的红利最终不是落在聊天更流畅而是落在这些工程化应用的可靠性上。3. 从 Hy3 迁移到 Hy4 Preview 的完整实操记录和生产适配方案3.1 上线前先跑冒烟测试我设计的五个最小验证任务迁模型最忌讳上来就把所有业务切过去我一般先设计一组冒烟用例用最小的成本判断新模型有没有硬伤。这次我从内部业务里挑出五类典型任务每一类都准备了固定输入和判定标准。第一类是长文档摘要输入一份约 6000 字的行业研究报告要求输出 200 字以内的结构化摘要重点考核它能不能抓住二级结论而非堆砌一级标题。第二类是 JSON 结构化输出给一段非结构化的简历文本要求按预设 JSON Schema 输出字段重点考核格式正确率和字段获取完整度。第三类是代码生成给定一个带有边界条件的编程需求要求生成可直接运行的 Python 函数并附带边界测试。第四类是多轮对话一致性模拟客服连续咨询在第七轮重新询问第一轮提到的订单编号看它是否还记得。第五类是工具调用规划给定三个 API 工具的描述要求它完成一个需要至少三步串行调用的任务。这五类跑下来Hy4 Preview 和 Hy3 的差距非常清晰。长文档摘要上Hy4 Preview 能抓到原文里比较隐蔽的因果逻辑而 Hy3 倾向于“平均用力”把每段都摘一句重点不突出。JSON 输出方面Hy4 Preview 只要给了 Schema连续三十次测试没有一次格式断裂Hy3 偶尔会在嵌套层级较深时漏掉字段。代码生成更是明显Hy4 Preview 对需求中隐含的边界条件理解更到位比如我不说但能推断出“输入可能为空列表”这种场景它会在代码里主动做防御Hy3 则经常忽略。多轮对话一致性上Hy4 Preview 的表现让我比较意外到第七轮还能准确复述第一轮出现的订单号Hy3 在第五轮就开始含糊甚至有一次编造了一个不存在的订单号。工具调用规划更是拉开差距同样一个需要调三个 API 的任务Hy4 Preview 给出的步骤顺序是正确的第一步的输出能被第二步正确引用而 Hy3 给出的方案只有框架缺少参数映射细节。冒烟测试不一定全面但它帮我快速圈定了哪些业务可以先迁移哪些还得再观察。3.2 提示词迁移中我踩的几个坑不是所有 Hy3 提示词都能直接复用迁移工作里最费时间的不是参数配置而是提示词的适配。我原本以为同系列模型提示词可以直接平移实际跑完之后发现有三个地方需要特别注意。第一个坑是“过度约束反而降低效果”。Hy3 时代因为模型指令跟随能力有限我习惯在提示词里加大量约束“你必须一步步思考”“请在回答前仔细检查”“不要使用多余的话”。这些约束在 Hy4 Preview 上反而会触发它的过度推理导致输出冗长、绕圈子。Hy4 Preview 对简洁指令的理解能力更强我现在倾向于把约束精简成一条限制性短语比如“只输出 JSON”或“先给出结论再解释原因”效果反而更好。第二个坑是 few-shot 示例数量可以大幅减少。Hy3 对复杂格式经常需要给 3 到 5 个示例才能稳定输出Hy4 Preview 给 1 个高质量示例就够少数场景零示例也能强行守住格式。这会直接影响 token 成本尤其是每个请求都带大量示例的高频业务光这一项就能省下不少输入 token 开销。但也不能彻底删掉示例在非常垂直的领域里一个示例仍然能帮它校准输出的颗粒度。第三个坑是 system prompt 里的架构性指令要重新设计。Hy4 Preview 因为是更底的模型基座对系统提示词的遵从度更高但也更在意指令之间的优先级。如果把“你是一个友好的助手”和“严格按照 JSON 格式输出”混在同一条 system prompt 里它可能更倾向于先满足角色设定而忽略格式。我调整后的做法是把系统提示词分成两段第一段定义角色和语气第二段用硬性条款列表定义输出契约中间用换行隔开。这样处理后格式稳定性提升明显。3.3 评测集和回归方法用二十个固定用例卡住效果底线提示词调完之后不能只靠人工看几个例子就决定上线。我会维护一个固定评测集二十个用例覆盖摘要、抽取、生成的正确性、格式合规、多轮一致性、工具调用六类能力。把 Hy3 和 Hy4 Preview 都跑一遍记录两个指标任务成功率以及结果的人工评分。我的做法比较朴素但有效。先让 Hy3 基于旧提示词跑一遍评测集记录每个用例的输出和评分。然后把 Hy3 的提示词迁移到 Hy4 Preview跑第二遍记录评分。接着针对 Hy4 Preview 中明显失分的用例单独调整提示词再跑第三遍。对比三份记录能同时看出模型本身的能力变化和提示词适配带来的增量。以 JSON 输出为例我评测集里专门设置了三个嵌套层次的用例。Hy3 在两层嵌套时表现尚可三层嵌套时偶发键缺失Hy4 Preview 第一遍跑三层嵌套就已经完全合规后来我把 Schema 里的字段名换成更接近业务语义的名称它也能准确映射。这类用例说明 Hy4 Preview 在底层指令跟随上确实有代际提升不是简单的“更聪明了”而是“更能按规矩办事了”。评测集建好之后要固化下来每次新版本模型发布都跑一遍。很多团队换模型只做一次抽样验证结果上线后某个冷门场景突然崩了就是因为没有建立长期回归机制。我的习惯是把这个评测集做成一个脚本输入是一组 JSON 请求输出是一份评分表每次模型更新后跑一次两小时能出结果非常值得投入。4. 770B 模型上生产后绕不开的几个现实问题延迟、成本、上下文与灰度4.1 延迟与并发你测的是单请求 P50用户感受到的是 P95Hy4 Preview 在 API 调用时的延迟表现和 Hy3 相比并非完全线性。单次短请求Hy4 Preview 和 Hy3 的响应速度差异不算大因为都受激活参数主导但一旦请求变成长文本Hy4 Preview 的延迟优势反而会体现出来得益于它对 KV cache 的优化。我们内部压测里一份约 8000 token 的输入Hy4 Preview 的首 token 延迟比 Hy3 低了约两成这在长文档处理场景中非常重要。但延迟不能只看平均值。MoE 模型在并发升高后路由会把请求分散到不同专家上如果某个专家恰好成为热点部分请求就会明显变慢。我在并发压测时发现Hy3 在并发 20 左右时 P95 延迟开始明显抬升而 Hy4 Preview 因为专家数量更多热点分散能力更强并发容忍度更高。这意味着在同样的业务压力下Hy4 Preview 反而不需要你准备太高的超时阈值。不过这里的注意点是如果你走的是 API 而非私有化部署最终延迟表现还取决于服务端当前的负载、排队策略和你的套餐等级。不要只看模型本身的单测数据一定要在你真实业务的输入分布下重新压测。我的经验是拿生产环境最近一周的请求日志做采样回放分别记录 P50、P90、P95 三档延迟这样判断是否满足用户体验要求才靠谱。4.2 调用架构需要跟着模型一起改吗微服务边界可以不动但超时和降级必须重设很多团队听到“770B”第一反应是重构整套上层系统。从我这次迁移的体验看如果你已经把大模型能力封装成独立的微服务模块业务层基本不用动真正需要重新设计的是两个横切面超时策略和降级策略。Hy3 时代我们给大模型服务配置的超时上限是 60 秒因为长文本生成偶尔会慢。到了 Hy4 Preview由于模型对长输入的预处理速度更快其实可以把超时上限缩到 45 秒但首 token 超时要从原来的 10 秒放宽到 15 秒左右避免在复杂推理场景下误杀。这些参数如果不调整可能出现一个奇怪现象总耗时没超时但首 token 等久了被自己前面的代理层断掉。降级策略更要提前设计。我的建议是不要把 Hy4 Preview 设成唯一依赖而是在它后面保留一条小模型兜底链路。当 770B 服务出现排队或限流时自动把低优先级、低难度请求切到 Hy3 或更小的模型。我们内部的降级条件是按延迟触发的如果 P95 超过 3 秒且持续 5 分钟就启动降级把标题生成、短文本分类这类简单任务切到小模型只保留复杂推理在高成本模型上。这套机制让我们的整体可用性在模型切换期间保持在 99.5% 以上。微服务架构层面我没有为 Hy4 Preview 单独搭建新的服务模块。大模型网关本身做了接口兼容。如果你之前把模型版本写死在代码里这次正好是重构的机会建议把所有模型调用都收敛到一个统一的 model gateway 上通过配置项切换模型版本而不是在业务代码里改 URL。这是老生常谈但我见过太多团队在换模型时临时改调用地址结果三个月后根本不知道自己线上跑的是哪个版本。4.3 2D 转 3D 等多模态能力的接入路径别把文本推理和生成能力混为一谈Hy4 Preview 相关的热搜词里“2D 转 3D”被频繁提及我看到不少朋友在问接入了 Hy4 Preview 的文本 API是不是就能直接用上 2D 转 3D 的能力这里的理解误区在于2D 转 3D 一般不是文本大模型本身的能力它背后是独立的图片理解与 3D 生成模型和文本模型共享的更多是品牌、入口和用户体系而非同一个权重文件。从架构角度看2D 转 3D 任务通常走的是“多模态编码器 3D 生成模块”的链路输入是图片输出是 3D 模型文件或神经隐式场。文本大模型在其中扮演的角色不是生成 3D 模型而是理解用户指令、提取图片描述、规划生成参数更多是“调度大脑”而非“生成主力”。所以如果你要做一个 2D 转 3D 的工具型产品需要同时接入两个通道文本模型负责指令理解专门的 3D 生成模型负责资产产出两者之间通过异步任务队列串联。我在迁移时把 2D 转 3D 这类多模态任务单独建了一条流水线和纯文本业务的架构完全分开。用户上传图片后先用一个轻量的图片理解模型生成结构化描述再把描述送到 Hy4 Preview 做参数规划和步骤拆解最后交给 3D 生成服务执行。这种分工的好处是每个环节都能独立升级将来 3D 生成模型更新时不用重新验证文本链路。多模态接入的稳定性和单模态不同文件上传、任务轮询、结果下载这些环节都要有超时和重试机制不能在网关层一刀切设置超时时间。4.4 灰度发布顺序先内部工具再低价值业务最后才是核心链路模型切换最大的风险不是模型效果变差而是“突然全量切换出问题了不知道回滚到哪里”。我的灰度策略分三步走每一步都有明确的退出条件。第一步是内部使用让产品、运营、研发同学在日常工作中用 Hy4 Preview 辅助写文档、做总结、写代码。这一步的目的不是验证效果而是收集真实使用中暴露的异常行为比如格式错乱、内容空洞、重复输出。如果内部使用一周没有发现系统性 bug进入第二步。第二步选一个低价值但流量较大的业务灰度比如站内搜索的“相关推荐理由生成”。这类业务的特殊性在于出错不会造成损失但请求量大能快速暴露模型在并发和成本上的问题。灰度比例先放到 10%观察一天看延迟和错误率如果没有异常放到 50%再看一天确认平稳后再放 100%。第三步才轮到核心业务但也不是一次切完。核心业务要先做一轮完整的回归测试包括提示词效果、异常兜底、数据结构兼容性确认无误后新流量切 20%老流量留在 Hy3持续观察至少一周。如果这期间出现任何超过阈值的失败率立刻把模型版本回退到 Hy3再根据日志定位问题。模型切换不是发布会不需要“零时差全量切换”稳比快重要得多。5. 实际决策哪些项目应该留在 Hy3哪些必须切 Hy4 Preview5.1 任务复杂度匹配高频简单任务留在小模型复杂推理才配得上 770B做技术选型不能只看“新模型更强就全员迁移”还要看成本效率。我见过不少团队把简单分类任务也送到超大模型上结果效果没提升多少费用翻了好几倍。Hy4 Preview 的 770B 并不是为所有任务设计的它的优势集中在复杂推理、长文本理解、多步工具调用、高难度代码生成这些场景。如果你手头的业务只是短文本情感分类、关键词提取、标题生成Hy3 甚至更小的模型完全够用。我用一组短文本分类任务做过对比Hy4 Preview 和 Hy3 的准确率都在 95% 左右差距不到 1 个百分点但成本相差数倍。这种情况下强行切换到 Hy4 PreviewROI 就很差。反过来如果你的业务涉及长文档的知识密集提取、需要多步推理的智能客服、代码库级理解与生成或者 Agent 式任务规划Hy4 Preview 的能力优势会非常明显地转化为业务指标。我在一个合同审查项目中测试Hy3 只能抽出显式条款Hy4 Preview 能推断出潜在的风险点这一步差距直接决定了项目能不能落地。任务复杂度是选择模型的第一标准不要被参数数字带着跑。5.2 成本测算方法把输入输出 token 分布和缓存命中率算进去关于成本我不想给出具体价格因为各家套餐和优惠差异太大但测算逻辑是通用的。换到更大的模型之前先取生产环境一周的日志统计平均输入 token 数、平均输出 token 数和日均请求量再乘以不同模型的单价就能得到一天的预估费用。但有几个容易被忽略的隐性成本项。第一是提示词膨胀Hy4 Preview 对示例数量的需求下降输入 token 会减少这是省钱项第二是输出 token 可能变多因为它更容易把话说完整如果前文提到过“回答要克制”输出量能压下来第三是重试率Hy4 Preview 格式错误率低意味着重试次数少也能间接省成本第四是缓存命中率如果网关层开启了 prompt caching高频请求的公共前缀可以被缓存这部分优化在长输入场景的收益很明显。我的建议是不要只看单价要按“完成一个任务的总成本”来算。比如摘要任务Hy3 可能由于理解不足需要你调用两次并做结果融合Hy4 Preview 一次就能搞定尽管单次更贵但完成度更高总成本反而更低。拿真实业务数据跑一周再算这笔账才算把成本测算做到位。5.3 个人建议的混合模型架构让不同量级的模型各司其职这次迁移让我最终形成了一套混合模型架构的思路不打算再追求“一个模型打天下”。我在模型网关层配置了三级路由简单任务走小模型或 Hy3中复杂度任务走 Hy3高复杂度任务才走 Hy4 Preview。路由规则不是纯靠关键词硬匹配而是用一个小模型做意图分类器先判断请求属于“快速任务”“标准任务”还是“深度任务”。比如一句话翻译走小模型普通摘要走 Hy3合同风险点分析和多步代码生成走 Hy4 Preview。这样做的好处是成本可控、延迟可控同时能在核心场景享受架构跃迁带来的能力红利。这种混合架构也给未来留下了扩展空间以后如果出现 1T 参数的更大模型我不需要改业务代码只需要在网关配置里增加一个更高优先级的模型通道把真正的复杂任务指过去就行。模型架构在变应用侧的架构要保持稳定。最后想说的从 Hy3 的 295B 到 Hy4 Preview 的 770B这次升级真正打动我的不是参数数字本身而是背后“容量变大但成本可控”的架构思路。MoE 的路由粒度变细了、注意力机制的显存负担降下来了、长上下文和工具调用能力变稳了这些变化叠加在一起才让大模型从“能聊天”走向了“能承担核心生产任务”。如果你也在做迁移决策我个人的习惯是让简单任务留在小模型把难任务交给大模型中间用模型网关做统一调度先灰度再全量每步都留好回滚开关。技术选型没有绝对的“最优”只有适合你当前业务场景的“最稳”。Hy4 Preview 这代给我们的启示其实是大模型能力的边界正在从“生成得更像人”扩展到“执行得更可靠”而可靠性才是生产力落地的真正前提。
