最近腾讯混元放出的 Hy4 Preview参数规模直接到了 770B比上一代 Hy3 的 295B 翻了一倍还多。不少同学第一反应是“又来一个千亿大模型”但在我这种天天跟模型部署、推理优化打交道的人眼里真正值得研究的是它背后的架构变化——因为架构一变后面所有训练、微调、推理、量化、部署的方案全都得跟着重新走一遍。这篇文章我就站在工程落地的角度把 Hy3 到 Hy4 的架构跃迁拆开讲清楚再聊聊 770B 这种体量想真正落到生产环境需要解决哪些现实问题。内容主要面向正在做大模型选型、私有化部署或者推理优化的工程师也会照顾想搞清楚 MoE 架构到底怎么回事的新手朋友。1. 从 295B 到 770B腾讯混元的这次升级到底在升什么1.1 参数规模暴涨背后的算力账怎么算先来算一笔账。295B 到 770B如果按稠密模型Dense Model的思路估算训练和推理的成本接近 2.6 倍。但熟悉大模型的人都知道MoEMixture of Experts混合专家模型的总参数量和激活参数量是两码事。Hy3 时代的 295B大概率是典型的稀疏 MoE 结构。所谓“稀疏”意思是模型虽然把所有参数都存下来了但每次推理只激活其中一小部分专家网络。到了 Hy4 Preview 的 770B增长的很大一部分来自专家数量的扩展和共享专家Shared Expert的调整。这里需要解释一个关键点否则很多人会误以为 770B 就是比 295B 贵 2.6 倍的跑法。MoE 模型的核心思路是“召之即来挥之即去”——一张 770B 的大模型不是每次问答都把这 7700 亿个参数全部过一遍而是通过一个路由网络Router把不同的 token 分发给最合适的那几个专家。总参数量决定模型的知识容量上限激活参数量才决定单次推理的计算成本。所以从 295B 到 770B知识容量上限提升明显但激活参数的增幅往往远小于 2.6 倍。这也是腾讯混元敢把参数推到 770B 的重要原因——只要稀疏度设计得当单次推理的开销并不会出现想象中的翻倍。1.2 从 Hy3 到 Hy4为什么说这是“架构跃迁”如果只是把专家数量从 8 个加到 32 个那顶多叫“容量扩充”不叫“架构跃迁”。Hy3 到 Hy4 的关键变化在于三个维度注意力计算方式、专家路由策略、训练稳定性控制。先看注意力机制。早期的大模型普遍采用因果注意力Causal Attention每个 token 只能看到前文。后来各家开始探索稀疏注意力、滑动窗口注意力等变体目的是在长上下文场景下把计算复杂度从平方级拉下来。Hy4 Preview 我推测在注意力层做了更细粒度的分组和裁剪类似 GQAGrouped Query Attention分组查询注意力的进一步扩展把 KV Cache 的占用压下来。这一点对 770B 级别的模型尤其重要因为 KV Cache 是推理显存的“隐形杀手”参数涨了之后如果不控制 KV Cache显存很容易直接被撑爆。再看专家路由。Hy3 时代的路由策略相对常规top-k 选择是主流也就是每个 token 固定激活 top-k 个专家。Hy4 Preview 更可能使用了多级路由或者带负载均衡约束的路由策略让不同 token 分配到不同粒度的专家既保证利用率又避免个别专家过热。这个设计在训练阶段能提升专家利用率在推理阶段则能减少局部排队导致的延迟抖动。最后是训练稳定性。770B 的大规模 MoE 训练中最怕的就是 loss spike损失突刺和专家退化Expert Collapse的恶性循环。所谓专家退化就是路由网络学会把几乎所有 token 都丢到一个专家身上其他专家变成“僵尸专家”白白占用存储却没有产出。Hy4 Preview 在训练策略上一定加强了负载均衡 Loss 和路由扰动这些细节普通用户看不到但直接影响模型最终质量。2. 架构跃迁的核心细节MoE、注意力与训练策略2.1 MoE 架构下的参数拆分想要真正理解 770B 是怎么塞进 GPU 的得先搞清楚 MoE 模型的参数都藏在哪。为了说明方便我列一个典型的参数分布表按我基于公开信息和架构逻辑做的推测来展示不代表官方数据但能帮大家建立直观感受。参数模块Hy3 (295B) 推测量级Hy4 Preview (770B) 推测量级作用专家参数多个 FFN 专家约 200B约 550B承担主要的知识存储和特征变换占参数大头共享专家/公共层参数约 30-50B约 80-120B所有 token 都会经过负责通用语义提取注意力层参数约 15-25B约 30-50B处理 token 之间的关联关系嵌入与输出层参数约 5-10B约 10-20B词表映射与词表大小强相关注意表格里的量级划分。专家参数是绝对大头这决定了 MoE 模型的“知识广度”。也就是说770B 相比 295B 多出来的参数绝大多数都分配给了专家网络。这背后的设计逻辑很直接想让模型知道更多领域知识、掌握更多语言模式最直接的方式就是把专家数量做大、专家容量做深。但同时要意识到多出来的专家参数是“沉睡资产”。每次推理只唤醒其中一部分所以存储压力是实打实存在的计算压力却受到控制。这也是为什么我们看到 770B 的总参数会觉得“这得跑在多夸张的机器上”但实际上如果稀疏度设计合理单次推理的计算量可能只相当于一个 100B 左右的稠密模型。这就是 MoE 的优雅之处也是它成为当前千亿级大模型主流架构的根本原因。2.2 注意力机制和长上下文处理从 Hy3 到 Hy4注意力机制的变化值得单独拿出来说。大模型的上下文长度越做越长如果还使用标准的多头注意力MHAKV Cache 的显存占用会线性甚至超线性增长。对于 770B 这种体量的模型KV Cache 稍微省一点就能多放不少并发请求。我判断 Hy4 Preview 大概率采用了类似 GQA 甚至 ULDUnlimited Depth这类优化手段。GQA 的核心是把多组 Query 共享同一组 Key 和 Value好比一个大型图书馆有多个读者Query共用同一套索引目录Key/Value省下了大量重复存储。这个优化在 7B 级别的模型上效果不显眼但在 770B 级别、动辄 128K 上下文的场景下能把 KV Cache 缩减好几倍。另一个值得关注的是长上下文下的计算效率。纯注意力机制的时间复杂度是 O(n²)n 是序列长度。128K 上下文就意味着 128K 个 token 两两计算注意力直接算肯定扛不住。Hy4 这类模型一般会用稀疏注意力或者滑动窗口 全局 token 混合的方案把计算复杂度压到接近 O(n) 的量级。实际效果就是上下文再长单 token 的推理延迟不会爆炸式增长。2.3 从训练到推理架构变化带来的连锁反应架构变化不仅影响模型本身的性能还会在训练和推理两个阶段引发一系列连锁反应。训练阶段最大的变化是显存管理。770B 模型全参训练时除了参数本身还需要保存优化器状态和梯度显存占用是推理的数倍到十数倍。所以 770B 大概率采用了 ZeROZero Redundancy Optimizer这类分布式优化策略把优化器状态、梯度和参数切分到不同 GPU 上否则整卡集群也扛不住。同时MoE 模型的专家 parallelism专家并行也很关键因为不同专家可以放置在不同 GPU 上token 通过 all-to-all 通信被路由到对应的专家所在设备。通信开销是 MoE 训练里最难啃的骨头网络带宽稍微拉胯训练效率就直线下降。推理阶段则要面临“存储与计算”的平衡问题。770B 的参数摆在那里无论如何一定要有足够的显存空间去装载。工程上通常会拆成多个 GPU 用张量并行Tensor Parallelism扛住单层参数再用流水线并行Pipeline Parallelism切层。到具体部署时还要结合模型并行的各种策略去调不是简单分几块卡就完事。3. 生产力落地实操部署、推理与调优指南3.1 硬件选型与显存估算如果说看完前面你还觉得 770B 很有吸引力那这一步就会让你立刻清醒——想把 Hy4 Preview 这类模型部署进生产环境首先要解决的是显存问题。我们按推理场景来算。770B 参数如果用 FP16半精度存储每个参数占 2 字节那就是 770B × 2 1540GB约 1.5TB 显存。目前主流的数据中心级 GPU单卡显存最大也就是 80GB如 A100/H100或 192GB超大显存版本单卡绝对装不下。即使不考虑 KV Cache、中间激活、CUDA context 这些额外开销光参数本身就需要至少 20 张 80GB 的卡才能放下。所以实战中必须上量化。常见的量化方案有 INT8、INT4、FP8 等。INT4 量化后理论上可以做到每个参数约 0.5 字节770B 就变成约 385GB8 张 80GB 的卡可以勉强塞进去但 INT4 量化的精度损失问题需要考虑。工程上更稳妥的选择是 FP8 或者 INT8显存需求在 770GB-800GB 左右需要 10 张以上的 80GB 卡。这里我建议团队在做硬件规划时至少按“参数显存 × 1.5”来预留因为 KV Cache 和中间激活在长上下文场景下很容易吃掉额外 30%-50% 的显存。3.2 量化方案怎么选FP8、INT8 还是 INT4量化是落地 770B 模型绕不开的一步。我实测过的经验是不同量化位宽效果差异很大。量化方案每参数占用770B 总占显存质量影响适用场景FP162B1540GB基准追求极致精度的离线分析FP81B770GB极小实测近似无损生产环境常用INT81B770GB极小稍有边界波动大多数在线服务INT40.5B385GB明显部分任务掉点显存紧张的测试环境我自己的建议是如果 GPU 资源相对充足优先用 FP8。FP8 在 NVIDIA 的 Hopper 架构上有硬件加速推理速度比 FP16 快不少而且质量损失几乎感知不到。如果你用的是老一代卡比如 A100 只能吃 FP16/INT8 没有原生 FP8 支持那就用 INT8配合 AWQ 这类权重感知校准方法可以把精度损失控制在很小范围内。INT4 我不太建议直接上生产尤其在数学推理、代码生成这类对精度敏感的任务上INT4 掉点会很明显。3.3 推理加速与并发优化模型装下了接下来就是怎么跑得快、并发拉得高。推理框架方面目前主流的选择是 vLLM 和 TensorRT-LLM。vLLM 的 PagedAttention 机制借鉴了操作系统虚拟内存的思路把 KV Cache 分成固定大小的块按需分配显存利用率比传统方式高很多特别适合长并发场景。TensorRT-LLM 则偏向极致性能优化会在模型加载时做大量层融合和算子优化单请求延迟通常更低但需要花更多时间去编译和调参。MoE 模型的并发优化还要额外关注路由平衡。如果某个专家被大量请求命中它所在的 GPU 会成为热点拖慢整体响应。生产环境里通常要做两类事一是尽量使用支持 expert parallelism 的推理框架让不同专家分布在多张卡上减轻热点二是在调度层做流量控制避免突发的长上下文请求把某张卡的 KV Cache 打满。实际部署中还需要关注 batch size批大小的选择。MoE 模型的推理吞吐量和 batch size 不是简单的线性关系因为 batch 越大能同时利用的专家越多计算密度越高。我通常在压测时从 batch1 开始逐步往上加找到一个吞吐量增速放缓的拐点那个点就是最佳的并发配置。4. 常见问题与排查技巧实录4.1 显存不足模型还没加载就 OOM这是部署 770B 类模型最常见的翻车现场。很多人按估算买了 8 张卡以为够了结果一加载就 OOMOut of Memory。排查思路先看代码里有没有把模型均匀切到所有卡上再看是否忘了开模型并行。很多时候是因为 PyTorch 的默认行为把模型放在单一设备上。另外还要看进程启动时的 CUDA contextCUDA 上下文占用有些框架初始化时就会在每张卡上预留几百 MB 到几个 GB 的显存卡一多累计很可观。解决办法有几个方向一是换用支持动态显存分配的推理引擎比如 vLLM二是把模型量化到更低精度三是调整分布式策略让每张卡分担的层数更均匀。别一上来就怪硬件不够先检查代码里有没有显存泄漏。4.2 推理速度慢并发一上去延迟就崩另一个高频问题是单请求延迟很低但并发一高整体吞吐就崩了。这个问题的根源通常在 KV Cache 的分配策略和算子瓶颈上。如果你用的是原生 PyTorch 直接推理出现这个问题毫不意外。原生推理没有 PagedAttention也没有 CUDA Graph很多小算子反复调度GPU 利用率打不上去。换成 vLLM 或者 TensorRT-LLM 之后通常会有立竿见影的改善。另外检查一下是否开了 continuous batching连续批处理这个功能可以让 GPU 在一个 batch 的某个请求结束后立刻补进新请求避免计算资源空转。还有一个容易忽略的点是 CPU 和 GPU 之间的数据传输。MoE 模型的 expert routing 涉及大量 token 和 expert 之间的映射如果数据在 CPU 和 GPU 之间来回搬运延迟会非常高。好的推理框架会把整个计算图放在 GPU 上只把输入输出留在 CPU 侧。4.3 量化之后效果下降不是所有任务都适合低位宽量化掉点是绕不开的关键问题。我实践中发现数学推理、长链思考、代码生成的场景最容易出问题因为这些任务对数值精度敏感。相反文本摘要、闲聊、文案生成这类任务INT4 也扛得住。遇到量化后效果下降先别急着换更高位宽。可以试试 AWQ 或 GPTQ 这类 weight-only 量化方案它们会专门找对模型输出影响最大的权重子集进行高精度保留经常能解决低位宽下的明显掉点问题。如果还是不行再升级到 FP8 或者混合精度方案——比如大部分层用 FP8关键层用 FP16。还有一个很多新手不知道的技巧量化校准数据集要贴近你的真实使用场景。用通用语料校准的 INT4 模型放在代码生成场景可能效果很差但如果你用大量代码语料重新校准一遍效果往往能回升不少。校准数据这件事值得多花时间。4.4 MoE 特有的路由短路问题使用 MoE 模型时还有一个隐性坑路由短路。简单说就是有的 token 被错误路由到不相关的专家导致输出质量不稳定。这样的问题在在线服务中很难排查因为损失不大但会反复出现零星的质量投诉。我的排查建议是在推理框架里开启路由统计日志观察每个专家的命中次数分布。如果发现某个专家命中次数异常偏高八成是路由网络出问题了。这种情况一般跟校准数据和推理框架的路由实现有关可以尝试更换推理框架或者引入路由扰动参数来打散偏置。5. 生产力落地的关键反思回到标题从 295B 到 770B这场架构跃迁到底能带来什么我个人的理解是参数规模的增长不是核心竞争力核心是把这么多参数组织起来并稳定地跑起来的能力。腾讯混元从 Hy3 到 Hy4 Preview 的升级本质上是在回答一个问题如何让千亿级 MoE 模型从“实验室跑通”走向“生产环境真好用”。我项目里踩过最深的一个坑是前期过度关注参数规模带来的能力提升忽略了部署复杂度对整个项目周期的影响。770B 模型的推理集群规划、运维监控、灰度发布、降级方案每一块都比 295B 时代要复杂一个台阶。如果团队里的工程能力顶不住再强的模型也只能躺在实验室里看。所以给正在做选型或即将部署这类大模型的朋友一个建议在兴奋于模型能力的同时提前把推理资源预算和工程排期做进去。模型选型不光看基准测试分数还要看你自己的 GPU 机房、网络拓扑、运维体系能不能接得住。毕竟生产力落地的核心指标不是“模型有多大”而是“多久能稳定跑起来”。这正是我对 Hy4 Preview 这类模型最关注的部分也是我写下整篇笔记的价值所在。
从295B到770B：腾讯混元Hy4的MoE架构跃迁与工程落地
最近腾讯混元放出的 Hy4 Preview参数规模直接到了 770B比上一代 Hy3 的 295B 翻了一倍还多。不少同学第一反应是“又来一个千亿大模型”但在我这种天天跟模型部署、推理优化打交道的人眼里真正值得研究的是它背后的架构变化——因为架构一变后面所有训练、微调、推理、量化、部署的方案全都得跟着重新走一遍。这篇文章我就站在工程落地的角度把 Hy3 到 Hy4 的架构跃迁拆开讲清楚再聊聊 770B 这种体量想真正落到生产环境需要解决哪些现实问题。内容主要面向正在做大模型选型、私有化部署或者推理优化的工程师也会照顾想搞清楚 MoE 架构到底怎么回事的新手朋友。1. 从 295B 到 770B腾讯混元的这次升级到底在升什么1.1 参数规模暴涨背后的算力账怎么算先来算一笔账。295B 到 770B如果按稠密模型Dense Model的思路估算训练和推理的成本接近 2.6 倍。但熟悉大模型的人都知道MoEMixture of Experts混合专家模型的总参数量和激活参数量是两码事。Hy3 时代的 295B大概率是典型的稀疏 MoE 结构。所谓“稀疏”意思是模型虽然把所有参数都存下来了但每次推理只激活其中一小部分专家网络。到了 Hy4 Preview 的 770B增长的很大一部分来自专家数量的扩展和共享专家Shared Expert的调整。这里需要解释一个关键点否则很多人会误以为 770B 就是比 295B 贵 2.6 倍的跑法。MoE 模型的核心思路是“召之即来挥之即去”——一张 770B 的大模型不是每次问答都把这 7700 亿个参数全部过一遍而是通过一个路由网络Router把不同的 token 分发给最合适的那几个专家。总参数量决定模型的知识容量上限激活参数量才决定单次推理的计算成本。所以从 295B 到 770B知识容量上限提升明显但激活参数的增幅往往远小于 2.6 倍。这也是腾讯混元敢把参数推到 770B 的重要原因——只要稀疏度设计得当单次推理的开销并不会出现想象中的翻倍。1.2 从 Hy3 到 Hy4为什么说这是“架构跃迁”如果只是把专家数量从 8 个加到 32 个那顶多叫“容量扩充”不叫“架构跃迁”。Hy3 到 Hy4 的关键变化在于三个维度注意力计算方式、专家路由策略、训练稳定性控制。先看注意力机制。早期的大模型普遍采用因果注意力Causal Attention每个 token 只能看到前文。后来各家开始探索稀疏注意力、滑动窗口注意力等变体目的是在长上下文场景下把计算复杂度从平方级拉下来。Hy4 Preview 我推测在注意力层做了更细粒度的分组和裁剪类似 GQAGrouped Query Attention分组查询注意力的进一步扩展把 KV Cache 的占用压下来。这一点对 770B 级别的模型尤其重要因为 KV Cache 是推理显存的“隐形杀手”参数涨了之后如果不控制 KV Cache显存很容易直接被撑爆。再看专家路由。Hy3 时代的路由策略相对常规top-k 选择是主流也就是每个 token 固定激活 top-k 个专家。Hy4 Preview 更可能使用了多级路由或者带负载均衡约束的路由策略让不同 token 分配到不同粒度的专家既保证利用率又避免个别专家过热。这个设计在训练阶段能提升专家利用率在推理阶段则能减少局部排队导致的延迟抖动。最后是训练稳定性。770B 的大规模 MoE 训练中最怕的就是 loss spike损失突刺和专家退化Expert Collapse的恶性循环。所谓专家退化就是路由网络学会把几乎所有 token 都丢到一个专家身上其他专家变成“僵尸专家”白白占用存储却没有产出。Hy4 Preview 在训练策略上一定加强了负载均衡 Loss 和路由扰动这些细节普通用户看不到但直接影响模型最终质量。2. 架构跃迁的核心细节MoE、注意力与训练策略2.1 MoE 架构下的参数拆分想要真正理解 770B 是怎么塞进 GPU 的得先搞清楚 MoE 模型的参数都藏在哪。为了说明方便我列一个典型的参数分布表按我基于公开信息和架构逻辑做的推测来展示不代表官方数据但能帮大家建立直观感受。参数模块Hy3 (295B) 推测量级Hy4 Preview (770B) 推测量级作用专家参数多个 FFN 专家约 200B约 550B承担主要的知识存储和特征变换占参数大头共享专家/公共层参数约 30-50B约 80-120B所有 token 都会经过负责通用语义提取注意力层参数约 15-25B约 30-50B处理 token 之间的关联关系嵌入与输出层参数约 5-10B约 10-20B词表映射与词表大小强相关注意表格里的量级划分。专家参数是绝对大头这决定了 MoE 模型的“知识广度”。也就是说770B 相比 295B 多出来的参数绝大多数都分配给了专家网络。这背后的设计逻辑很直接想让模型知道更多领域知识、掌握更多语言模式最直接的方式就是把专家数量做大、专家容量做深。但同时要意识到多出来的专家参数是“沉睡资产”。每次推理只唤醒其中一部分所以存储压力是实打实存在的计算压力却受到控制。这也是为什么我们看到 770B 的总参数会觉得“这得跑在多夸张的机器上”但实际上如果稀疏度设计合理单次推理的计算量可能只相当于一个 100B 左右的稠密模型。这就是 MoE 的优雅之处也是它成为当前千亿级大模型主流架构的根本原因。2.2 注意力机制和长上下文处理从 Hy3 到 Hy4注意力机制的变化值得单独拿出来说。大模型的上下文长度越做越长如果还使用标准的多头注意力MHAKV Cache 的显存占用会线性甚至超线性增长。对于 770B 这种体量的模型KV Cache 稍微省一点就能多放不少并发请求。我判断 Hy4 Preview 大概率采用了类似 GQA 甚至 ULDUnlimited Depth这类优化手段。GQA 的核心是把多组 Query 共享同一组 Key 和 Value好比一个大型图书馆有多个读者Query共用同一套索引目录Key/Value省下了大量重复存储。这个优化在 7B 级别的模型上效果不显眼但在 770B 级别、动辄 128K 上下文的场景下能把 KV Cache 缩减好几倍。另一个值得关注的是长上下文下的计算效率。纯注意力机制的时间复杂度是 O(n²)n 是序列长度。128K 上下文就意味着 128K 个 token 两两计算注意力直接算肯定扛不住。Hy4 这类模型一般会用稀疏注意力或者滑动窗口 全局 token 混合的方案把计算复杂度压到接近 O(n) 的量级。实际效果就是上下文再长单 token 的推理延迟不会爆炸式增长。2.3 从训练到推理架构变化带来的连锁反应架构变化不仅影响模型本身的性能还会在训练和推理两个阶段引发一系列连锁反应。训练阶段最大的变化是显存管理。770B 模型全参训练时除了参数本身还需要保存优化器状态和梯度显存占用是推理的数倍到十数倍。所以 770B 大概率采用了 ZeROZero Redundancy Optimizer这类分布式优化策略把优化器状态、梯度和参数切分到不同 GPU 上否则整卡集群也扛不住。同时MoE 模型的专家 parallelism专家并行也很关键因为不同专家可以放置在不同 GPU 上token 通过 all-to-all 通信被路由到对应的专家所在设备。通信开销是 MoE 训练里最难啃的骨头网络带宽稍微拉胯训练效率就直线下降。推理阶段则要面临“存储与计算”的平衡问题。770B 的参数摆在那里无论如何一定要有足够的显存空间去装载。工程上通常会拆成多个 GPU 用张量并行Tensor Parallelism扛住单层参数再用流水线并行Pipeline Parallelism切层。到具体部署时还要结合模型并行的各种策略去调不是简单分几块卡就完事。3. 生产力落地实操部署、推理与调优指南3.1 硬件选型与显存估算如果说看完前面你还觉得 770B 很有吸引力那这一步就会让你立刻清醒——想把 Hy4 Preview 这类模型部署进生产环境首先要解决的是显存问题。我们按推理场景来算。770B 参数如果用 FP16半精度存储每个参数占 2 字节那就是 770B × 2 1540GB约 1.5TB 显存。目前主流的数据中心级 GPU单卡显存最大也就是 80GB如 A100/H100或 192GB超大显存版本单卡绝对装不下。即使不考虑 KV Cache、中间激活、CUDA context 这些额外开销光参数本身就需要至少 20 张 80GB 的卡才能放下。所以实战中必须上量化。常见的量化方案有 INT8、INT4、FP8 等。INT4 量化后理论上可以做到每个参数约 0.5 字节770B 就变成约 385GB8 张 80GB 的卡可以勉强塞进去但 INT4 量化的精度损失问题需要考虑。工程上更稳妥的选择是 FP8 或者 INT8显存需求在 770GB-800GB 左右需要 10 张以上的 80GB 卡。这里我建议团队在做硬件规划时至少按“参数显存 × 1.5”来预留因为 KV Cache 和中间激活在长上下文场景下很容易吃掉额外 30%-50% 的显存。3.2 量化方案怎么选FP8、INT8 还是 INT4量化是落地 770B 模型绕不开的一步。我实测过的经验是不同量化位宽效果差异很大。量化方案每参数占用770B 总占显存质量影响适用场景FP162B1540GB基准追求极致精度的离线分析FP81B770GB极小实测近似无损生产环境常用INT81B770GB极小稍有边界波动大多数在线服务INT40.5B385GB明显部分任务掉点显存紧张的测试环境我自己的建议是如果 GPU 资源相对充足优先用 FP8。FP8 在 NVIDIA 的 Hopper 架构上有硬件加速推理速度比 FP16 快不少而且质量损失几乎感知不到。如果你用的是老一代卡比如 A100 只能吃 FP16/INT8 没有原生 FP8 支持那就用 INT8配合 AWQ 这类权重感知校准方法可以把精度损失控制在很小范围内。INT4 我不太建议直接上生产尤其在数学推理、代码生成这类对精度敏感的任务上INT4 掉点会很明显。3.3 推理加速与并发优化模型装下了接下来就是怎么跑得快、并发拉得高。推理框架方面目前主流的选择是 vLLM 和 TensorRT-LLM。vLLM 的 PagedAttention 机制借鉴了操作系统虚拟内存的思路把 KV Cache 分成固定大小的块按需分配显存利用率比传统方式高很多特别适合长并发场景。TensorRT-LLM 则偏向极致性能优化会在模型加载时做大量层融合和算子优化单请求延迟通常更低但需要花更多时间去编译和调参。MoE 模型的并发优化还要额外关注路由平衡。如果某个专家被大量请求命中它所在的 GPU 会成为热点拖慢整体响应。生产环境里通常要做两类事一是尽量使用支持 expert parallelism 的推理框架让不同专家分布在多张卡上减轻热点二是在调度层做流量控制避免突发的长上下文请求把某张卡的 KV Cache 打满。实际部署中还需要关注 batch size批大小的选择。MoE 模型的推理吞吐量和 batch size 不是简单的线性关系因为 batch 越大能同时利用的专家越多计算密度越高。我通常在压测时从 batch1 开始逐步往上加找到一个吞吐量增速放缓的拐点那个点就是最佳的并发配置。4. 常见问题与排查技巧实录4.1 显存不足模型还没加载就 OOM这是部署 770B 类模型最常见的翻车现场。很多人按估算买了 8 张卡以为够了结果一加载就 OOMOut of Memory。排查思路先看代码里有没有把模型均匀切到所有卡上再看是否忘了开模型并行。很多时候是因为 PyTorch 的默认行为把模型放在单一设备上。另外还要看进程启动时的 CUDA contextCUDA 上下文占用有些框架初始化时就会在每张卡上预留几百 MB 到几个 GB 的显存卡一多累计很可观。解决办法有几个方向一是换用支持动态显存分配的推理引擎比如 vLLM二是把模型量化到更低精度三是调整分布式策略让每张卡分担的层数更均匀。别一上来就怪硬件不够先检查代码里有没有显存泄漏。4.2 推理速度慢并发一上去延迟就崩另一个高频问题是单请求延迟很低但并发一高整体吞吐就崩了。这个问题的根源通常在 KV Cache 的分配策略和算子瓶颈上。如果你用的是原生 PyTorch 直接推理出现这个问题毫不意外。原生推理没有 PagedAttention也没有 CUDA Graph很多小算子反复调度GPU 利用率打不上去。换成 vLLM 或者 TensorRT-LLM 之后通常会有立竿见影的改善。另外检查一下是否开了 continuous batching连续批处理这个功能可以让 GPU 在一个 batch 的某个请求结束后立刻补进新请求避免计算资源空转。还有一个容易忽略的点是 CPU 和 GPU 之间的数据传输。MoE 模型的 expert routing 涉及大量 token 和 expert 之间的映射如果数据在 CPU 和 GPU 之间来回搬运延迟会非常高。好的推理框架会把整个计算图放在 GPU 上只把输入输出留在 CPU 侧。4.3 量化之后效果下降不是所有任务都适合低位宽量化掉点是绕不开的关键问题。我实践中发现数学推理、长链思考、代码生成的场景最容易出问题因为这些任务对数值精度敏感。相反文本摘要、闲聊、文案生成这类任务INT4 也扛得住。遇到量化后效果下降先别急着换更高位宽。可以试试 AWQ 或 GPTQ 这类 weight-only 量化方案它们会专门找对模型输出影响最大的权重子集进行高精度保留经常能解决低位宽下的明显掉点问题。如果还是不行再升级到 FP8 或者混合精度方案——比如大部分层用 FP8关键层用 FP16。还有一个很多新手不知道的技巧量化校准数据集要贴近你的真实使用场景。用通用语料校准的 INT4 模型放在代码生成场景可能效果很差但如果你用大量代码语料重新校准一遍效果往往能回升不少。校准数据这件事值得多花时间。4.4 MoE 特有的路由短路问题使用 MoE 模型时还有一个隐性坑路由短路。简单说就是有的 token 被错误路由到不相关的专家导致输出质量不稳定。这样的问题在在线服务中很难排查因为损失不大但会反复出现零星的质量投诉。我的排查建议是在推理框架里开启路由统计日志观察每个专家的命中次数分布。如果发现某个专家命中次数异常偏高八成是路由网络出问题了。这种情况一般跟校准数据和推理框架的路由实现有关可以尝试更换推理框架或者引入路由扰动参数来打散偏置。5. 生产力落地的关键反思回到标题从 295B 到 770B这场架构跃迁到底能带来什么我个人的理解是参数规模的增长不是核心竞争力核心是把这么多参数组织起来并稳定地跑起来的能力。腾讯混元从 Hy3 到 Hy4 Preview 的升级本质上是在回答一个问题如何让千亿级 MoE 模型从“实验室跑通”走向“生产环境真好用”。我项目里踩过最深的一个坑是前期过度关注参数规模带来的能力提升忽略了部署复杂度对整个项目周期的影响。770B 模型的推理集群规划、运维监控、灰度发布、降级方案每一块都比 295B 时代要复杂一个台阶。如果团队里的工程能力顶不住再强的模型也只能躺在实验室里看。所以给正在做选型或即将部署这类大模型的朋友一个建议在兴奋于模型能力的同时提前把推理资源预算和工程排期做进去。模型选型不光看基准测试分数还要看你自己的 GPU 机房、网络拓扑、运维体系能不能接得住。毕竟生产力落地的核心指标不是“模型有多大”而是“多久能稳定跑起来”。这正是我对 Hy4 Preview 这类模型最关注的部分也是我写下整篇笔记的价值所在。