腾讯混元上周低调放出了 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 延迟上升，因为排队等待的请求变多了。折中方案是动态 batch（continuous batching），vLLM 和 TensorRT-LLM 都支持，可以做到来一个请求插一个空位，而不是等一批结束再计算。
首 token 延迟优化则是另一套思路。常见手段包括：用更小的 KV Cache、减少 prefill 的计算量；采用投机采样，让一个小模型快速生成"草稿 token"，大模型只需要做校验，解码速度能提升 2 到 3 倍；还有 PD 分离部署，让 prefill 和 decode 在不同的 GPU 池上运行，避免长 prompt 的 prefill 阻塞在线请求的 decode。这些都是实测有效的方案，但每一样都要针对业务流量模式做压测。
我压测时常用的套路是：先固定并发数（比如 64、128、256），分别记录吞吐（tokens/s）、TTFT（Time To First Token）和 TPOT（Time 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_usage=True，并配合device_map="auto"或者手动切片。不要小看这一步，770B 的权重即使 FP8 也有 770GB，内存不优化的话很容易在加载阶段就挂掉。
5.2 通信瓶颈与 GPU 利用率低
MoE 模型跑起来 GPU 利用率只有一半甚至更低，大概率是通信瓶颈。现象是nvidia-smi显示 GPU 计算利用率很低，但带宽或者 SM 空闲时间异常高。
排查工具我推荐三个：nvidia-smi看整体利用率、nsys/ncu看 kernel 耗时、NCCL_DEBUG=INFO看通信段。最常见的沟通瓶颈是 all-to-all 通信，也就是专家间的 token 交换。优化思路有几个，一是调整专家放置策略，尽量让常常被同时激活的专家放在同一台机器的卡上；二是开启 RoCE/IB 高速网络，别用千兆以太网跑大规模分布式推理；三是调大通信 chunk 的大小，减少小消息数量。
我踩过的一个坑是把模型并行和专家并行混在一起后没有调通信顺序，导致每次路由都要做多次跨节点通信。后来把 EP（专家并行）和 TP（张量并行）的通信域分开，先做组内通信再做组间通信，整体性能提升明显。
5.3 输出不稳定的排查：采样参数、Prompt 与模型边界
很多同学反馈"同一个 prompt 每次回答不一样""有时候质量很高，有时候胡说八道"。这不全是模型的问题，可能是采样参数没调好。
如果做确定性要求高的任务，先把 temperature 调到 0，top_p 设为 1。要注意的是，MoE 模型在 temperature=0 时仍然可能因为浮点运算顺序不同导致结果不完全一致，这是正常现象，不用过于纠结。如果输出重复、绕圈，通常要调高 repetition_penalty，或者考虑是否 prompt 中上下文过长导致注意力分散。
还有一类问题是模型"能力边界"被误判。770B 模型虽然很强，但它不是数据库、也不是计算器。如果你让它做精确的日期计算、复杂的多跳推理，或者查询一个它没见过的专有名词，它照样会一本正经地胡说。这时候该做的是在应用层加工具调用和 RAG，让模型"知道自己的不知道"，而不是逼它硬答。我在产品里一般会加一个"置信度门槛"，模型回答置信度低时自动转人工或转检索链路，整体体验会稳定很多。
最后再把话说明白点
从我实际接触这些大模型的血泪经验来看，每次模型规模跃迁，最该冷静的不是参数数字，而是你手里的业务到底卡在哪里。295B 到 770B 的架构升级，解决的是"更大容量 + 更优 MoE 调度 + 更强多模态"的问题，对复杂推理、长文本理解、多模态生成这类任务的提升是真真切切的。但要搞清楚，这个提升值不值得你花十几张卡的部署成本，得先拿真实业务数据说话。
我个人习惯的做法是：新模型来了，先用小流量灰度，拿线上真实 prompt 集跑一遍离线评估，从效果、延迟、成本三个维度拉一张对比表，再决定要不要全量切过去。再强的模型，只要接不进你的业务链路、兜不住你的成本红线，就只是一个好看的技术指标。真正能沉淀下来的生产力，永远是"混元这类底座模型 + 适配业务的工程编排"一起跑出来的结果。
