腾讯混元上周低调放出了 Hy4 Preview参数规模从 Hy3 的 295B 直接干到 770B。数字听着吓人但真正值得关注的不是参数量本身而是这套架构从训练到推理、从文本到多模态的一整套变化。我在大模型基础设施和应用落地这边泡了挺久今天不聊官方宣传稿就实打实聊聊 295B 到 770B 背后发生了什么以及落地时怎么把这个 770B 的家伙用好。这篇文章适合三类人一是做模型部署和推理优化的工程师二是想用大模型做实际业务的算法/后端同学三是对 MoE 这类分布式模型架构感兴趣、想搞清楚参数变大到底意味着什么的开发者。我会把架构跃迁的核心思路、关键差异、落地踩坑和排查技巧一次讲透保证都是可以直接抄作业的内容。1. 从 295B 到 770B参数增长背后到底换了什么思路1.1 数字游戏还是架构跃迁先搞懂稠密模型与 MoE很多人看到 770B 第一反应是又刷参数了但行业内卷的不是参数大小而是同样的算力下谁能跑出更好效果。这里有个基础概念必须搞清楚稠密模型Dense和混合专家模型MoE。Hy3 的 295B 如果走的是稠密路线那推理时每个 token 都得过 2950 亿个参数单看显存和算力就让人头皮发麻。而 770B 这个量级几乎可以断定是 MoE 架构。MoE 的核心思路是搞一个巨大的专家库但每个输入只激活其中一小部分专家。就像一家公司养了几百个行业的顾问但接到具体项目时只让对口的那几位上场而不是所有人一起开会。MoE 里有两个关键参数总参数量Total Parameters和激活参数量Active Parameters。总参数量决定模型文件多大、部署时需要多少显存激活参数量决定每个 token 实际计算量有多大。Hy4 Preview 从 295B 到 770B大概率是总参数量涨了但激活参数量保持在可控范围比如 30B 到 40B 左右。这就解释了一件事为什么参数量翻了一倍多推理延迟却没有同样翻倍。所以这次架构跃迁的本质不是简单堆参数而是把模型从所有人一起干活变成海量专家按需调度。这套思路在翻译、代码生成、多模态这类任务上优势尤其明显因为不同任务的 pattern 差异大专家分化能带来实打实的效果提升。1.2 架构跃迁的驱动因素Scaling Law 与算力约束怎么平衡任何一次架构升级背后都是收益和成本的博弈。这次混元从 Hy3 到 Hy4 Preview 的跃迁我理解有两条主线驱动。一是模型能力的规模收益。业界在训练大模型时有一个朴素的观察参数越多知识容量越大复杂推理能力越强。但纯粹堆参数到 770B 稠密模型训练成本不可接受推理成本更是灾难。MoE 架构相当于在模型容量和单次计算成本之间做了个杠杆让总参数量继续往上走单 token 的计算量不跟着暴涨。这是 295B 到 770B 能成立的前提。二是应用场景倒逼架构调整。Hy4 Preview 不只是参数变大还明显增强了对长文本、图像理解、3D 内容生成等任务的支撑。长文本意味着注意力机制的复杂度不能继续按平方涨多模态意味着模型要同时处理不同模态的编码和对齐。这些需求都直接影响了架构设计——比如专家分组、多模态 token 的独立路由、更高效的位置编码方式。单纯加大参数解决不了这些问题架构必须跟着变。另外还得提一句分布式架构。770B 参数的模型训练时不可能塞进单卡甚至单机。整个训练集群需要同时做数据并行、张量并行、流水线并行和专家并行NCCL 通信量非常大通信拓扑设计不好GPU 再强也白搭。这也是为什么说架构跃迁不单指模型结构还包含整套分布式训练与推理框架的升级。1.3 从 295B 到 770B 的工程代价显存、通信与稳定性这一节写得直接一点770B 不是白给的工程上的代价比很多人想象中大得多。先说显存。以 770B 总参数量计算如果全部用 BF16 存储权重大约是 770 × 10^9 × 2 字节 ≈ 1.54 TB。单张 80G 的 H100/A100 只有 80GB连权重的零头都放不下。即使切成 FP8也还有 770GB 左右。所以生产环境跑 770B基本得用 8 卡到 16 卡甚至更多卡做张量并行和专家并行或者配合量化offload。Hy3 的 295B 可能几张卡还能勉强塞下到 Hy4 这个量级部署方案必须重新设计。再说通信。MoE 模型里最头疼的问题是全对全通信。每个 token 要路由到不同的专家专家可能分布在不同的 GPU 上计算完还要把结果聚合回来。当专家数量多、分布散时通信时间可能比计算时间还长。我在实测中见过 GPU 利用率被通信拖到 40% 以下的情况最后通过调整专家放置策略和通信调度才拉回 70% 以上。这个话题后面展开说。最后是训练稳定性。MoE 模型训练时经常遇到的坑是路由崩溃也就是部分专家被频繁选中另一部分专家长期空闲导致模型 capacity 浪费。通常要加负载均衡损失来约束但负载均衡系数太大会影响模型效果这个平衡点很考验调参经验。Hy4 Preview 这类大版本升级训练周期长中途还容易出现 loss spike一般得有完善的 checkpoint 和异常恢复机制否则几个月的算力可能白烧。2. Hy3 到 Hy4 Preview几个值得关注的核心差异2.1 专家体系与路由策略的变化我把 Hy4 Preview 和 Hy3 放在一起对比时最直观的感受是专家体系更精细了。早期 MoE 就是简单的 Top-K 路由每个 token 全量算一遍所有专家的得分取最高的 K 个专家计算。这种做法在专家数量少、任务类型单一的时候效果不错但专家一多计算开销和路由偏差都是问题。Hy4 Preview 这个级别的大规模 MoE通常会采用分组专家和共享专家的设计。分组专家的意思是把专家分成几个组token 只路由到特定组内减少计算范围共享专家则是每个 token 都一定会去计算的那部分用来捕获通用的语言学知识或跨任务底层特征。这种设计的好处是既能享受专家多样化带来的收益又不会让路由计算成为瓶颈。路由策略上我猜 Hy4 会比 Hy3 更强调负载均衡和路由稳定性。负载均衡不只是靠 auxiliary loss还可能要动态调整 top-k 的 k 值、给某些热点 expert 多塞一些容量。实际使用中如果路由分布做得不好你会看到某些 GPU 显存占用特别高、计算特别忙而另外几张卡闲着这在部署时非常致命。2.2 注意力模块的演进长文本不再是奢侈品参数量变大之外Hy4 Preview 另一个明显趋势是把上下文窗口做得更长。这背后离不开注意力机制的优化。Transformer 架构里标准多头注意力MHA在长序列场景下有一个硬伤KV Cache 随序列长度线性增长计算量随序列长度平方增长。所以现在主流大模型基本都会用 GQA分组查询注意力或类似改进方案把多个 Query 头共享一组 Key/Value显著减少显存占用和计算量。Hy3 到 Hy4在注意力头组织上大概率有结构性的调整否则长文本能力提不上去。位置编码也一样。处理超长序列时RoPE旋转位置编码几乎成了标配。它的优点是可以外推也就是训练时没见过的长度推理时也能处理一部分。但外推也有上限真要做到 256K、1M 这种级别往往还要配合其他手段比如滑动窗口注意力、可学习的长度缩放因子等。这块属于不翻源码看不到但直接决定体验的细节。对于使用者来说长文本能力最直接的感受就是可以把整本书、整个工程代码仓、一整份财务报告直接丢给模型而不是想尽办法切 chunk。这一点在生产环境里能省下大量 prompt 工程的精力。2.3 多模态与 2D 转 3D架构跃迁带来的新可能Hy4 Preview 出来后不少开发者关注的其实不是文本生成而是多模态能力尤其是2D 转 3D这类生成任务。大模型做 2D 转 3D本质上是让模型理解单张图片中的几何结构、纹理和深度关系再生成对应的 3D 表示比如网格、NeRF 或高斯泼溅属于从稀疏观测到稠密预测的逆问题难度非常高。架构跃迁之后这类任务有机会做得更好的原因有两个。一是总参数量大了模型可以记忆更丰富的物体形状先验——比如看到一把椅子能知道椅背通常是什么结构二是多模态对齐做得更深文本、图像、3D 表征能够在一个统一的语义空间里交互。实际应用里2D 转 3D 可以用在游戏资产生产、电商商品建模、AR/VR 内容制作等场景效率比传统摄影测量或者手工建模高一个量级。多模态能力在 Agent 领域同样有价值。Agent 要处理的不只是纯文本还可能要看截图、PDF、网页甚至操作 GUI。能看图的底座模型配合任务规划、工具调用才能组成真正可用的 Agent 架构。所以 Hy4 Preview 的多模态能力某种程度上是给整个 AIGC 应用生态打底。3. 生产力落地770B 模型如何真正用起来3.1 部署选型FP8 量化、张量并行与 KV Cache 配置模型再强部署不了就是零。770B 的落地第一步就是解决怎么把权重塞进显存、怎么保证延迟可接受。首先是精度选择。上线推理时我建议优先试 FP8精度损失在可接受范围内显存直接砍半从 1.54TB 降到 770GB 左右。如果还想压可以进一步做 INT8 或者 AWQ/GPTQ 这类权重量化但要仔细评估业务指标下降幅度。我在一次代码生成任务里做过对比BF16 到 FP8 基本无感到 INT8 时某些复杂逻辑生成任务的准确率掉了 2-3 个百分点需要按场景取舍。其次是模型并行策略。770B 模型单卡肯定放不下至少需要 8 卡到 16 卡。8 卡 80G 显存总共 640GB配上 FP8 权重约 770GB还是放不下所以更现实的方案是 16 卡 H100/H20或者 8 卡 量化到 4bit 左右。部署时张量并行TP是必须的MoE 部分还要考虑专家并行EP把不同专家分布到不同卡上减少单卡压力。KV Cache 的显存计算也很关键。以 32K 上下文、64 层、GQA 8 个 KV head、head_dim 128 为例单序列的 KV Cache 大约为 64 × 8 × 128 × 32768 × 2 字节 ≈ 4.29GB。这个数值随着并发数线性增长64 并发就是 270GB 多非常夸张。所以做长文本场景时KV Cache 量化KV8/KV4、PagedAttention 这类机制要用起来不然显存很快被吃干榨净。3.2 微服务架构与模型接入让大模型变成可调用能力模型部署好之后还要面对工程化问题。我在生产环境里习惯把模型服务封装成独立的一层再通过微服务架构接入业务。这样模型更新、扩容、降级都不会影响上层业务逻辑。具体结构通常是业务微服务 → 统一模型网关 → 推理服务vLLM / TensorRT-LLM / SGLang → 底层 GPU。网关负责路由、限流、鉴权、超时控制。模型服务本身最好拆成文生文、多模态理解、2D 转 3D 生成这几个独立 deployment因为它们的资源占用和扩缩容策略完全不一样。文本生成可能吃 KV Cache图像/3D 生成更吃计算峰值混在一起很容易互相拖累。如果做 Agent 场景模型服务之外还要搭配工具调用框架。我的参考架构里会有一个任务规划器把用户请求拆成多个子任务一个工具注册中心管理查数据库、调搜索、读写文件、唤起其他微服务这些能力以及一个护栏层负责校验模型输出是否符合预期格式。770B 模型这时候的角色更像大脑它不需要事必躬亲关键是规划、判断和调用工具时足够可靠。3.3 成本与算力评估别一上来就想着 770B我知道很多人看到 770B Param、效果更强第一反应就是全上。但作为工程落地最忌讳的就是不看成本硬上。一个 770B MoE 模型的推理成本即使激活参数只有 30B 左右如果并发拉高占用的 GPU 数量和电费、带宽成本都很可观。我一般会做一个简单的估算假设部署 16 卡 H20单卡 96G一台机器的硬件成本加上机柜、带宽、运维月成本大概在中六位数到七位数人民币之间。如果你的业务每天只有几万次请求用 770B 模型每一个 token 都走大参数推理单次成本可能比中小模型高出几个数量级。更明智的做法是分级路由简单任务闲聊、信息抽取走 30B 或 70B 级别的小模型复杂任务深度推理、长文档理解、复杂规划才路由到 Hy4 Preview 这类 770B 模型。实测下来大约 70% 到 80% 的线上请求根本不需要用到 770B 的能力。把大模型用在刀刃上效果和成本才能同时好看。4. 实操记录从 Hy3 迁移到 Hy4 的那些坑4.1 微调阶段数据、超参与训练策略的调整如果想把 Hy4 Preview 接入自己的业务第一步往往不是直接部署开源权重而是做领域微调。770B 模型的微调第一原则是别轻易全参数微调那成本和风险都太高了。推荐路线是 LoRA 或者 QLoRA只调一小部分低秩矩阵就能在很多场景下把领域能力拉起来。超参数调整上有几个点需要注意。学习率一般要比小模型低一个数量级MoE 大模型的参数对更新幅度更敏感学习率太高容易出现路由抖动。批量大小要考虑梯度稳定性一般用梯度累积来模拟大 batch但 MoE 模型天然有负载均衡约束batch 太小会导致路由分布特别不稳定。上下文长度方面如果业务需要长文本建议微调时直接用与预训练一致的长度不要从短长度再外推效果更可控。数据配比同样关键。我的经验是通用数据与领域数据的比例大概控制在 2:1 到 4:1 之间。纯领域数据会导致模型在通用能力上退化纯通用数据则领域效果上不来。另外如果要用 2D 转 3D 或多模态能力微调数据里最好有相当的图文对和 3D 资产数据并且要注意不同模态数据量之间的平衡。4.2 推理框架适配vLLM 与 TensorRT-LLM 的取舍部署 770B 模型时推理框架的选型直接影响吞吐和延迟。目前主流的选项是 vLLM、TensorRT-LLM 和 SGLang各有取舍。vLLM 胜在生态好、上手快PagedAttention 对 KV Cache 的利用率提升非常明显。但它对 MoE 的专家并行支持及自定义算子性能在一些极端规模下不如 TensorRT-LLM 激进。TensorRT-LLM 是 NVIDIA 家的东西对 Tensor Core 的压榨更狠量化、算子融合、FP8 支持都很成熟适合对延迟和吞吐要求极高的场景。SGLang 则在前端和后端一体化解法上更顺滑特别是结构化输出、多模态调用的场景写起来比裸 vLLM 方便。我给个实用建议团队有 CUDA 和推理调优经验优先 TensorRT-LLM想要快速上线、迭代频繁优先 vLLM如果做 Agent 应用、需要频繁切换 prompt 和工具调用可以试试 SGLang。实测中同样的 770B 模型TensorRT-LLM 在 FP8 下比 vLLM 默认配置的吞吐高约 20% 到 30%但初期适配成本也高需要自己写不少配置和插件。4.3 性能调优从吞吐到首 token 延迟的平衡上线之后真正考验人的是性能调优。我要处理的第一对矛盾是吞吐和首 token 延迟。吞吐优化最简单直接的方式是加大并发 batch。MoE 模型因为共享权重batch 越大专家利用率越高单 token 成本越低。但 batch 过大会导致首 token 延迟上升因为排队等待的请求变多了。折中方案是动态 batchcontinuous batchingvLLM 和 TensorRT-LLM 都支持可以做到来一个请求插一个空位而不是等一批结束再计算。首 token 延迟优化则是另一套思路。常见手段包括用更小的 KV Cache、减少 prefill 的计算量采用投机采样让一个小模型快速生成草稿 token大模型只需要做校验解码速度能提升 2 到 3 倍还有 PD 分离部署让 prefill 和 decode 在不同的 GPU 池上运行避免长 prompt 的 prefill 阻塞在线请求的 decode。这些都是实测有效的方案但每一样都要针对业务流量模式做压测。我压测时常用的套路是先固定并发数比如 64、128、256分别记录吞吐tokens/s、TTFTTime To First Token和 TPOTTime Per Output Token再根据业务诉求做取舍。如果做聊天助手TTFT 比吞吐重要如果做离线批量处理吞吐优先。5. 常见问题与排查技巧实录5.1 显存 OOM 与模型加载失败跑 770B 模型最容易遇到的就是显存 OOM。现象一般是进程刚起来CUDA error: out of memory或者跑到一半突然崩掉。排查思路是先分清是哪部分显存爆了。模型权重占多少、KV Cache 占多少、激活值占多少、框架额外开销占多少。用nvidia-smi只能看到总占用建议配合 PyTorch 的torch.cuda.memory_summary()或者框架自带的显存 profiler 来定位。如果是权重占太多优先量化如果是 KV Cache 溢出减小 max_num_seqs 或者开启 KV Cache 量化如果是激活值爆掉降低 batch size 或者换用更省显存的 attention 后端。还有一个常见问题是 huggingface 加载权重时把整个模型复制到内存再转到显存导致内存先爆。解决办法是加载时直接指定low_cpu_mem_usageTrue并配合device_mapauto或者手动切片。不要小看这一步770B 的权重即使 FP8 也有 770GB内存不优化的话很容易在加载阶段就挂掉。5.2 通信瓶颈与 GPU 利用率低MoE 模型跑起来 GPU 利用率只有一半甚至更低大概率是通信瓶颈。现象是nvidia-smi显示 GPU 计算利用率很低但带宽或者 SM 空闲时间异常高。排查工具我推荐三个nvidia-smi看整体利用率、nsys/ncu看 kernel 耗时、NCCL_DEBUGINFO看通信段。最常见的沟通瓶颈是 all-to-all 通信也就是专家间的 token 交换。优化思路有几个一是调整专家放置策略尽量让常常被同时激活的专家放在同一台机器的卡上二是开启 RoCE/IB 高速网络别用千兆以太网跑大规模分布式推理三是调大通信 chunk 的大小减少小消息数量。我踩过的一个坑是把模型并行和专家并行混在一起后没有调通信顺序导致每次路由都要做多次跨节点通信。后来把 EP专家并行和 TP张量并行的通信域分开先做组内通信再做组间通信整体性能提升明显。5.3 输出不稳定的排查采样参数、Prompt 与模型边界很多同学反馈同一个 prompt 每次回答不一样有时候质量很高有时候胡说八道。这不全是模型的问题可能是采样参数没调好。如果做确定性要求高的任务先把 temperature 调到 0top_p 设为 1。要注意的是MoE 模型在 temperature0 时仍然可能因为浮点运算顺序不同导致结果不完全一致这是正常现象不用过于纠结。如果输出重复、绕圈通常要调高 repetition_penalty或者考虑是否 prompt 中上下文过长导致注意力分散。还有一类问题是模型能力边界被误判。770B 模型虽然很强但它不是数据库、也不是计算器。如果你让它做精确的日期计算、复杂的多跳推理或者查询一个它没见过的专有名词它照样会一本正经地胡说。这时候该做的是在应用层加工具调用和 RAG让模型知道自己的不知道而不是逼它硬答。我在产品里一般会加一个置信度门槛模型回答置信度低时自动转人工或转检索链路整体体验会稳定很多。最后再把话说明白点从我实际接触这些大模型的血泪经验来看每次模型规模跃迁最该冷静的不是参数数字而是你手里的业务到底卡在哪里。295B 到 770B 的架构升级解决的是更大容量 更优 MoE 调度 更强多模态的问题对复杂推理、长文本理解、多模态生成这类任务的提升是真真切切的。但要搞清楚这个提升值不值得你花十几张卡的部署成本得先拿真实业务数据说话。我个人习惯的做法是新模型来了先用小流量灰度拿线上真实 prompt 集跑一遍离线评估从效果、延迟、成本三个维度拉一张对比表再决定要不要全量切过去。再强的模型只要接不进你的业务链路、兜不住你的成本红线就只是一个好看的技术指标。真正能沉淀下来的生产力永远是混元这类底座模型 适配业务的工程编排一起跑出来的结果。