万亿参数级 MoE 模型的本地部署：显存核算、硬件选型与成本估算

对于总参数达到万亿量级的 MoE（混合专家）模型，本地部署最先遇到的不是”怎么跑起来”，而是”到底要多少显存、要花多少钱”。很多团队习惯用激活参数去估算资源，这在稠密模型上是合理的，但在 MoE 架构上会严重低估需求。本文以一类总参数 2.8 万亿、采用细粒度专家路由的模型为参照，把显存核算、硬件配置、软件栈和预算估算这四件事讲清楚，并给出一套可复用的推导方法，便于读者在权重发布后逐项核验。

一、先厘清口径：总参数决定显存，激活比例决定算力

MoE 模型的资源估算有两个容易混淆的指标：

• 总参数（Total Parameters）：模型全部专家的参数量之和，决定权重需要占用多少存储与显存。
• 激活参数（Activated Parameters）：单个 token 在前向计算中实际经过的参数量，决定算力消耗与推理延迟。

以 2.8 万亿总参数、896 个专家、每 token 激活 16 个专家的配置为例，专家激活比例约为 16 ÷ 896 ≈ 1.79%。需要强调：专家激活比例不等于严格的参数激活比例。注意力主干、嵌入层、路由网络等非专家部分在每个 token 上都会参与计算，因此真实激活参数比例会略高于专家激活比例。

部署时的结论很直接：全部 896 个专家都必须常驻存储，推理时由路由网络动态调出 16 个。显存占用按总参数计算，激活比例只影响单 token 的计算量。把这两笔账分开算，是后续所有估算的前提。

二、量化格式与显存下限的推导

该模型从监督微调阶段就引入了量化感知训练，权重使用 MXFP4、激活使用 MXFP8。MXFP4 是 OCP 规范中的微缩放格式：每 32 个 4-bit 元素共享一个 8-bit 缩放因子（scale）。因此权重元素的平均位宽不是 4 bit，而是：

每 32 个元素的位宽 = 32 × 4 bit + 8 bit = 136 bit
平均每元素位宽 = 136 ÷ 32 = 4.25 bit

据此推导权重裸数据下限：

2.8 × 10^12 × 4.25 bit ÷ 8 ≈ 1487.5 GB

如果只按 4 bit 粗算，得到的约 1400 GB 只是理论下限；加上缩放因子后约为 1487.5 GB。这还没有计入以下开销：

1. 非 4-bit 张量：嵌入层、归一化层、路由网络等通常保留更高精度；
2. 张量元数据与对齐填充；
3. 运行时工作区（临时缓冲区、通信缓冲）；
4. KV Cache：随并发数与上下文长度线性增长，长上下文场景下不可忽视。

作为量级参照，一个总参数约 671B 的 MoE 模型在 FP8 下主参数加多 token 预测参数约占 685 GB，即使压到 4-bit 量化权重仍需约 335 GB，加上约 37 GB 激活合计约 400 GB，才能放进 8 张 80 GB 加速卡（合计 640 GB）并留出余量。总参数量级放大四倍以上后，满血部署的显存下限也随之抬升一个台阶。

三、硬件配置：为什么必须上超节点

显存装得下只是第一步。大规模 MoE 推理的性能瓶颈往往在通信而非算力。

896 个专家分散在多张加速卡上，每个 token 经路由后需要把激活值搬运到目标专家所在卡，计算完成后再搬回。这是一次典型的 all-to-all 通信模式。当专家切分越细、卡数越多，通信次数与数据量越大，延迟会直接吃掉算力利用率。

因此这类模型的推荐部署形态是由 64 张以上加速器组成的超节点，通过高带宽、低延迟的卡间互联（如 NVLink 或同等高速互联）把通信域做大，让专家间的激活搬运不出单个通信域。若改用普通以太网跨节点互联，all-to-all 的带宽与延迟通常会成为主要瓶颈，需要额外的通信优化（分层 all-to-all、专家复制、拓扑感知路由等）才能接近可用吞吐。

一个粗略的容量规划思路：

项目	估算口径
权重显存	总参数 × 4.25 bit ÷ 8，另加非量化张量
KV Cache	并发数 × 上下文长度 × 层数 × 隐藏维度 × 精度字节数
激活与工作区	按峰值 batch 的激活张量估算，通常为权重的一定比例
通信缓冲	按 all-to-all 峰值消息量预留
冗余	建议预留 15%～25% 余量应对碎片与峰值

四、软件栈与部署路径

本地部署这类模型，软件侧需要解决四件事：量化格式支持、专家并行切分、通信调度、服务化。

# 伪代码：专家并行切分的配置示意
config = {
    "model_path": "/models/moe-2.8t-mxfp4",
    "quantization": "mxfp4_weight_mxfp8_act",
    "parallel": {
        "expert_parallel": 64,     # 专家分布到 64 个 rank
        "tensor_parallel": 8,      # 单专家内部张量切分
        "pipeline_parallel": 2,
    },
    "kv_cache": {
        "max_batch_size": 32,
        "max_seq_len": 32768,
        "dtype": "fp8",
    },
    "comm": {
        "all_to_all_backend": "high_speed_interconnect",
        "overlap_with_compute": True,
    },
}

几个实践要点：

• 优先验证量化内核：MXFP4 的微缩放需要运行时内核支持，部署前应先确认推理框架对该格式的加载与计算路径是否完整，避免”能加载、跑不动”。
• 专家并行度与互联域对齐：专家并行度应尽量落在单个高速互联域内，跨域只做必要的分层聚合。
• 通信与计算重叠：把 all-to-all 与专家计算做流水线重叠，是提升吞吐的关键手段。
• KV Cache 单独规划：长上下文与高并发会显著推高显存占用，建议将 KV Cache 与权重显存分开核算，必要时引入分页管理。

五、成本估算：把一次性投入与持续性支出分开

本地部署的总成本由四部分构成，缺一不可：

1. 加速卡采购：这是最大头。按 64 张以上加速卡起步，单卡价格随互联规格、显存容量差异很大，需按实际选型询价。若追求更高吞吐或更长上下文，卡数还要上调。
2. 服务器与超节点基础设施：包括高速互联交换、机架、供电与散热。高功率密度机架对配电与液冷往往有额外要求，这部分常被低估。
3. 机房与运维：电力容量、制冷、网络带宽，以及持续的运维人力。万亿参数模型的推理服务对稳定性要求高，需要专门的 SRE 投入。
4. 软件与适配成本：推理框架适配、量化内核验证、性能调优的工程投入，通常以人月计。

一个实用的决策框架是：先算显存下限，再算通信约束，最后算预算。如果显存下限已经超出可采购规模，或通信域无法做到单域内 all-to-all，那么本地满血部署在经济上就不成立，此时更现实的路径是采用云端按需算力或调用托管 API。

六、核验清单

本文涉及的显存、硬件配置与性能数字均基于公开架构信息推导，属于估算范畴。权重与技术报告正式发布后，建议按以下清单逐项核验：

• 实际权重文件大小与量化格式，核对 4.25 bit 平均位宽的假设；
• 非量化张量（嵌入、归一化、路由）的精度与占比；
• 单卡显存容量与专家并行的实际切分方案；
• all-to-all 在目标互联域内的带宽与延迟实测；
• 不同 batch 与上下文长度下的 KV Cache 占用曲线；
• 端到端吞吐与首 token 延迟的基准测试结果。

把这六项测完，估算值就能替换为实测值，部署方案也从”纸面可行”变为”工程可交付”。