超大MoE模型本地部署成本拆解：从显存、通信到硬件选型

一、为什么“激活参数少”不等于“显存占用少”

很多大规模稀疏模型在发布时会重点强调“每个 token 仅激活少量专家”，让读者产生一种推理成本很低的印象。例如总参数达到万亿级，但单个 token 只激活其中一小部分专家。这里需要先区分两个完全不同的概念：

1. 算力消耗：主要与单个 token 实际参与计算的参数量相关。
2. 显存占用：主要与模型总参数量、量化精度、模型分片方式以及运行时缓存相关。

在典型的 MoE 架构中，所有专家都保存在显存或高速存储中。推理时路由模块根据 token 特征选择少量专家进行计算，但这并不意味着未选中的专家可以从显存中移除。原因很简单：不同 token、不同 batch、不同请求会命中不同专家。如果每次请求都从磁盘或远端存储重新加载专家权重，延迟将高到不可接受。

因此，对本地部署而言，必须按照“总参数量”来估算基础显存需求，而不是按照“激活参数量”估算。激活比例可以显著影响算力、吞吐和延迟，但它不能抵消重量级权重常驻显存带来的成本。

二、万亿级 MoE 模型的总参数与激活结构

假设一个 MoE 模型总参数为 2.8 万亿，专家数量为 896 个，每个 token 激活其中 16 个专家。则专家激活比例约为：

16 / 896 ≈ 1.79%

这个比例只表示每个 token 在专家网络上激活的数量占比，并不直接等价于总参数激活比例。除了专家网络之外，模型中通常还存在：

• 注意力层参数；
• 路由网络参数；
• 嵌入层参数；
• 归一化层参数；
• 输出层参数；
• 可能的辅助模块或多任务头。

这些部分可能对每个 token 都是激活的，或者以不同方式参与计算。因此，即便专家激活比例很低，实际前向过程中被激活的总参数量仍可能高于直觉判断。

另外，一些 MoE 架构还包含多专家共享层、共享注意力层或共享专家层。共享专家可能会被更多 token 访问，从而进一步提升算力与带宽压力。评估时不能只看“普通专家激活数量”，还要关注是否存在常驻计算模块。

三、量化格式如何影响显存下限

对超大规模模型来说，原始精度部署通常不可行。以 FP16 或 BF16 为例，2.8 万亿参数需要：

2.8T × 2 字节 = 5.6TB

这已经超过大多数单机甚至小型集群的可用显存。因此，实际部署基本都会采用低精度量化。

常见的量化路线包括：

• INT8 / FP8：权重与激活使用 8-bit 表示；
• INT4 / AWQ / GPTQ：权重 4-bit，激活可按需使用 FP16 或 INT8；
• MXFP4 / MXFP8：基于微缩放的浮点格式，权重使用 4-bit 元素并共享 scale；
• 量化感知训练：训练阶段就引入量化误差，使推理阶段精度损失更小。

以 MXFP4 为例，它并不是简单地把所有参数都用 4-bit 存储。根据常见规范，连续的 4-bit 元素可能共享一个 8-bit scale。这样会带来额外的元数据开销。

假设权重元素为 4-bit，每 32 个元素附带一个 8-bit scale，则平均每元素有效位数可估算为：

4 + 8 / 32 = 4.25 bit

对于 2.8 万亿参数，仅权重部分的裸存储约为：

2.8T × 4.25 bit ÷ 8 ≈ 1487.5GB

这个数字还没包含以下部分：

• 嵌入层或输出层未量化部分的额外开销；
• 非 4-bit 张量，例如归一化参数、路由参数；
• 分片后产生的重复参数或元数据；
• KV cache；
• 通信缓冲区；
• 深度学习框架的运行时工作区；
• 显存对齐与碎片化损耗。

因此，实际部署所需要的显存通常会显著高于裸权重体积。一般建议在裸权重基础上至少预留 20%～50% 的额外空间，用于缓存、通信与运行时开销。

四、通过对比理解显存量级

为了更直观地理解部署门槛，可以把万亿级模型与一个常见的几千亿参数稠密或 MoE 模型进行对比。

例如一个总参数约为 671B 的 MoE 模型，若采用 FP8 格式，主参数大约需要：

671B × 1 字节 = 671GB

如果还有额外的多 token 预测模块，例如约 14B 参数，则该部分还需要：

14B × 1 字节 = 14GB

合计约 685GB。

如果使用 4-bit 权重量化，主权重部分可能降到约 335GB，但激活和额外 buffer 仍会增加数十 GB。整体下来，可能需要约 400GB 显存才能在 8 张 80GB 加速卡组成的节点上运行，总可用显存约 640GB。

而一个总参数为 2.8 万亿的 MoE 模型，规模是上述模型的 4 倍以上。即使采用更激进的 4-bit 量化，权重体积也已经落在 1.4TB 至 1.5TB 量级。这意味着单台 8 卡节点，无论单卡显存是 80GB 还是 96GB，都基本无法承载满血模型。

五、显存之外的隐藏瓶颈：通信拓扑

大规模 MoE 推理的另一个关键瓶颈是通信。原因在于专家分布在不同设备上，每个 token 的前向过程可能涉及跨卡数据传输。

典型流程如下：

1. 路由模块根据 token 表征计算专家得分；
2. 选出 top-k 专家；
3. 将 token 的隐藏状态发送到对应专家所在设备；
4. 在目标设备上完成专家计算；
5. 将结果回传到 token 原始所在设备；
6. 合并多个专家输出并继续后续层。

当专家数量达到数百甚至近千个，并且分布在几十张卡上时，每一步都可能产生 all-to-all 通信。此时通信延迟可能超过专家计算本身，成为系统吞吐的主要限制因素。

影响通信效率的关键因素包括：

• 节点内卡间互联带宽；
• 节点间网络带宽，例如 RDMA 带宽；
• 交换机与拓扑结构；
• all-to-all 通信是否可被合并或分片；
• 是否采用专家并行、张量并行与流水线并行的组合策略；
• 是否使用高速 NVMe 或专用缓存进行权重换入换出。

因此，官方建议使用 64 张以上加速卡组成超节点部署该类模型，并不是单纯因为显存不够，而是为了减少每张卡上的权重大小、提高聚合显存、同时为通信提供足够高的背板带宽。

六、本地部署的硬件方案边界

如果把部署目标限定为“本地环境”，通常会有几类可选方案：

1. 单机单卡或单机多卡

适合中小模型或量化程度较高的模型。对于万亿级 MoE，即使采用 4-bit 量化，单机显存也无法满足权重常驻要求。此时可以考虑：

• 仅部署部分专家；
• 使用分层卸载；
• 接受非常低的并发吞吐；
• 只运行 demo 级推理。

这种方式适合验证模型格式、推理逻辑或开发上层应用，不适合作为生产服务。

2. 多台高显存节点组成小规模集群

如果单台节点为 8 卡，单卡显存 80GB，则单节点理论显存约为 640GB。对于约 1.5TB 的 4-bit 权重，至少需要 3 台节点以上才能放下裸权重。如果再考虑 KV cache、通信缓冲和系统开销，实际可能需要 4 台以上节点。

但这只是显存层级的估算。通信方面，如果节点间网络带宽不足，例如仅有较低带宽以太网而缺乏 RDMA 或其他高速互联方案，那么即使显存够用，延迟和吞吐也可能严重下降。

3. 超节点方案

使用 64 张以上加速卡组成的超节点，单卡需要承载的权重大幅减少。例如 1.5TB 权重分布在 64 张卡上，平均每张卡约需承载：

1.5TB / 64 ≈ 23.4GB

再考虑额外空间后，单卡仍可保持在 40GB 以内。这样不仅显存更从容，还能通过高速背板互联显著降低 all-to-all 延迟。

这种方案的重点是：

• 网络架构是否支持大规模无损传输；
• 是否具备足够的交换机端口；
• 是否支持专家并行；
• 推理框架是否能有效调度 896 个专家的路由；
• 监控、恢复与负载均衡机制是否完善。

七、实际成本怎么估算

本地部署成本通常由以下几部分构成：

1. 加速卡成本

这是主要支出。如果单卡成本较高，64 张卡即构成一个数量级明显的投入。不同采购渠道、不同显存规格和不同供货周期都会显著影响总价。企业通常还需要考虑：

• 备用卡；
• 测试卡；
• 返修周期中的替代方案。

2. 节点与网络设备成本

包括：

• 高密服务器；
• 高速交换机；
• 光模块与线缆；
• 机柜与供电；
• 散热设施。

对于 64 卡以上集群，网络设备成本可能接近甚至超过加速卡成本的一部分比例。

3. 软件与集成成本

包括：

• 推理框架调优；
• 专家并行策略设计；
• 量化工具链适配；
• 路由性能调试；
• 监控与告警系统构建；
• 与业务系统集成。

即使使用开源推理框架，也需要投入相当的人力进行适配和压测。

4. 运维成本

包括：

• 机房机柜费用；
• 电力成本；
• 网络带宽；
• 值班与故障响应；
• 定期压力测试与容量评估。

因此，单纯问“部署一个万亿级模型要花多少钱”无法得到一个固定数字。硬件采购只是最显性的部分，真正影响总拥有成本的是通信方案、推理框架优化能力以及团队的模型工程化经验。

八、从部署评估到工程落地

如果团队希望在本地完成类似规模模型的部署，建议按以下步骤进行评估：

第一步：先确定部署形态

明确是离线评测、内部试用还是对业务提供在线推理服务。不同形态决定了可用延迟、并发、可用性要求以及可接受的硬件成本。

第二步：以总参数为基础计算显存下限

不要只看激活参数。建议同时准备：

• FP8 估算；
• INT4 估算；
• MXFP4 估算；
• 留出 KV cache 与运行时开销。

第三步：确定并行策略

主要包括：

• 专家并行；
• 张量并行；
• 流水线并行；
• 数据并行。

对于超大规模 MoE，专家并行通常是不可回避的选择，但需要配合张量并行与流水线并行控制单卡显存。

第四步：实测通信瓶颈

在购买完整集群前，可以先在较小规模上测试：

• 单卡权重加载；
• 双卡专家并行；
• 节点内 8 卡 all-to-all；
• 跨节点小规模通信。

通过小规模压测可以更准确地判断互联方案是否合适，避免一次性采购后才发现网络无法支撑。

第五步：建立成本模型

将硬件、软件、人力与运维统一纳入模型，按年估算。不要只看一次性采购价，也要关注：

• 利用率；
• 故障率；
• 是否可弹性扩容；
• 是否有多项目共享可能。

九、结论

超大 MoE 模型的本地部署成本，核心由总参数量决定，而不是由激活参数决定。即便使用 4-bit 量化，万亿级模型的权重裸存储也可能达到 1.4TB 以上，加上 KV cache、通信缓冲和运行时工作区后，实际显存需求会更高。

这类模型的严肃部署通常需要几十张甚至更多加速卡组成高速互联集群，并且必须重点解决专家并行下的 all-to-all 通信问题。否则，即便显存总量勉强达标，低带宽网络也会让推理吞吐和延迟迅速恶化。

对企业和开发者来说，更务实的做法不是直接追求“满血本地部署”，而是先基于总参数、量化方案、通信拓扑和业务需求建立评估模型，再逐步通过小规模测试验证推理框架、并行策略与网络能力，最后再决定是否投入完整硬件集群。这样既能控制风险，也能让每一笔基础设施投入都有更清晰的依据。