超大 MoE 模型本地部署的显存与成本拆解：以万亿参数规模为例

一、为什么总参数量比激活参数量更决定部署门槛

在讨论超大模型部署成本时，最容易产生误判的一点，是把“每个 token 激活多少参数”当成“需要装多少参数”。对于稠密模型，这两者基本一致；但对于 MoE 架构，二者差异极大。

以 2.8 万亿总参数为例。MoE 架构下，模型包含 896 个专家，每个 token 根据路由选择其中 16 个专家参与计算。16 除以 896，得到的专家激活比例约为 1.79%。这个数字常被用来描述模型的“稀疏激活程度”，但它不能直接等同于参数量只占总量的 1.79%。

原因在于，推理阶段的路由是动态的。不同 token、不同 batch、不同请求会命中不同专家。为了让任意输入都能正确完成前向计算，部署方必须把所有专家权重都放在可被访问的存储中，而不是只加载某几个专家。也就是说：

• 总参数量决定显存和存储的下限；
• 激活参数量决定单步计算的算力需求；
• 专家数、路由策略和请求分布共同决定通信与调度成本。

因此，2.8 万亿参数的 MoE 模型，无论单 token 激活多少专家，其显存规划都必须按接近 2.8 万亿参数来估算。这是后续所有成本推导的基础。

二、量化能降低显存，但远不是“除 4”那么简单

原始权重如果采用 FP8 或 BF16 保存，2.8 万亿参数会直接达到数十 TB 级别，几乎不可能用常规本地硬件承载。于是部署方案通常会引入低比特量化。但真实显存占用并不只等于“参数量乘以量化位宽”。

以 4-bit 权重为例。最朴素的计算是：

2.8T 参数 × 4 bit ÷ 8 = 1400GB

这看起来是一个可接受的下限。但实际使用的 MXFP4 等块量化格式并不是单纯 4-bit 存储。MXFP4 通常以 32 个 4-bit 元素为一组，每组附带一个 8-bit scale，用于恢复组内数值范围。因此每个元素的等效位宽不是 4 bit，而是：

32 × 4 bit + 8 bit = 136 bit
136 bit ÷ 32 = 4.25 bit

按这个更贴近实际的数值计算：

2.8T 参数 × 4.25 bit ÷ 8 ≈ 1487.5GB

也就是说，仅权重部分就已经接近 1.5TB。而这还只是理论裸数据。

真正部署时还要叠加以下几部分：

1. 非 4-bit 张量：并非所有参数都适合 4-bit 量化，Embedding、归一化层、路由网络等可能保留更高精度。
2. 元数据与对齐开销：权重分片、页对齐、校验信息和加载索引都会增加实际占用。
3. 运行时工作区：前向计算中的中间激活、算子临时缓冲、梯度状态虽在推理时减少，但不会完全消失。
4. KV cache：长上下文或多并发请求下，KV cache 可能成为独立且显著的显存消耗来源。
5. 多副本与流水线缓冲：如果采用流水线并行，多个 stage 之间的缓冲区也会占用额外空间。

所以，部署规划不能只看“4-bit 等于多少 GB”，而必须把权重、量化元数据、运行时状态和通信缓冲都纳入预算。

三、用一个 671B 稠密 MoE 模型做参照

为了更直观地理解 2.8 万亿参数的部署压力，可以拿一个约 671B 参数的 MoE 模型作为参照。

该模型在 FP8 精度下，主参数加额外预测模块参数合计约 685GB。若采用 4-bit 权重量化，权重部分约 335GB，同时激活与量化相关开销还需约 37GB，合计约 400GB。

这意味着，即便只是 671B 参数模型，要完整加载并保持可用推理空间，8 张 80GB 显存加速卡合计 640GB 也只是刚刚够用，其中还要预留 KV cache 和运行时开销。若并发升高或上下文变长，余量会迅速被耗尽。

而 2.8 万亿参数模型的总参数量是这个 671B 模型的 4 倍以上。按同样的量化策略推算，仅权重部分就突破 1.4TB，整体显存需求很容易超过 1.6TB 甚至更高。这就解释了为什么单机多卡方案在 2.8 万亿参数面前基本不可行。

四、为什么必须使用多卡超节点，而不是简单堆显存

当模型权重达到 1.5TB 级别时，即便采购足够多的显卡，把它们插进一台机器也面临物理上限。更关键的是，MoE 推理不只是“装得下”，还涉及大量卡间通信。

在 896 个专家的 MoE 架构中，专家分布在多张卡上。每个 token 完成路由后，都需要把中间激活发送到目标专家所在的卡，计算完成后再取回结果。这个过程可以简化为：

输入 token
  → 路由决策
  → 跨卡发送到 16 个专家
  → 各专家计算
  → 跨卡回收结果
  → 合并输出

如果每张卡只放一部分专家，那么每处理一个 token，都可能产生多条跨卡通信路径。请求量增大时，通信压力会呈非线性增长。

这里的核心约束不是单卡算力，而是 all-to-all 通信带宽。大规模 MoE 推理对这类通信极其敏感。若通信域较小，跨节点跳数多，延迟会直接翻倍甚至更高。此时即使每张卡的 FLOPs 很高，实际利用率也可能很低。

因此，这类模型的部署方案通常建议使用 64 张以上加速器组成超节点，并依赖高带宽互联将通信域尽量收敛到单一高速域内。NVLink、InfiniBand 或等效高速互联的目标一致：让专家通信尽量不发生跨节点跳转，从而降低延迟和拥塞。

换句话说，本地部署超大 MoE 模型，真正的门槛往往不在于“有没有足够显存”，而在于“有没有足够大的高速通信域”。

五、成本不只是显卡价格

如果按 64 张 80GB 显存加速卡计算，仅 GPU 采购成本就会达到一个量级。以当前市场常见的单卡价格区间做粗略估算：

64 × 单卡价格

仅这一项就可能进入数百万人民币级别。但这还远不是全部成本。实际部署通常还要包含：

1. 整机与互联设备：高速交换机、线缆、光模块、冷却系统等。
2. 内存与存储：权重加载需要高速 NVMe 或持久化存储，模型版本管理也会占用大量空间。
3. 电力与机房改造：多卡系统功耗可达数十千瓦，对供电、散热和机柜承重都有额外要求。
4. 备份与冗余：生产环境通常需要预留故障卡替换或降级运行能力。
5. 运维人力：超大模型部署涉及分布式框架、监控、日志、告警、版本回滚和性能调优，运维复杂度高。

因此，做预算时不能用“一张卡多少钱，乘多少卡”来估算总成本。真正合理的算法应当是：

总成本 = 计算硬件成本
       + 高速互联成本
       + 存储与内存成本
       + 机房与电力成本
       + 部署与调优成本
       + 长期运维成本

六、不同目标下的部署建议

超大 MoE 模型本地部署并不是一个单纯的“能跑即可”问题。根据目标不同，最优方案也会变化：

1. 技术验证与小规模测试

如果是验证推理链路、评估路由行为或做小范围能力测试，不建议直接部署满血权重。可以使用低比特量化、减少专家副本或缩减上下文长度等方式，让模型在较小规模的集群上先跑通。

2. 面向离线批处理

如果请求不要求极低延迟，可以采用吞吐优先策略：增大 batch、降低并发响应要求，通过时间换空间，缓解通信与显存压力。这种场景下，硬件配置可以略低于理论峰值。

3. 面向在线高并发推理

在线场景对单请求延迟敏感，必须保证通信域足够大、KV cache 充足、调度稳定。这时部署架构通常需要预留至少 20% 至 30% 的显存与算力余量，避免流量尖峰导致排队或失败。

4. 混合部署方案

对于预算有限但有持续推理需求的场景，可将冷权重存储在高速持久化设备中，通过动态加载策略减少常驻显存。但这种方案会牺牲首 token 延迟，并且对存储带宽要求极高，需要做细致的收益评估。

七、从“能不能跑”到“能不能用”之间的差距

很多团队在评估超大 MoE 模型部署时，习惯先问“需要多少张卡”。但实际问题应该拆成三个更细的维度：

• 容量问题：显存是否足够装下全部权重和运行时状态？
• 带宽问题：专家通信是否能在延迟预算内完成？
• 稳定性问题：在持续高负载下是否会出现显存碎片、通信阻塞或节点掉线？

容量问题可以通过堆卡解决，带宽问题需要高速互联和合理拓扑，稳定性问题则依赖工程化部署与运维体系。三者缺一不可。

对于 2.8 万亿参数、896 个专家、每 token 激活 16 个专家的 MoE 模型来说，最核心的结论可以概括为：

量化只是降低门槛，真正决定本地部署可行性的，是高速通信域的规模与工程化能力。

如果做预算规划，建议按以下优先级逐步核算：

1. 单 token 路径上的显存峰值；
2. 多并发下的 KV cache 与 I/O 压力；
3. all-to-all 通信频率与通信域规模；
4. 满负载下的故障恢复与监控能力；
5. 长期运行的总拥有成本，而非一次性采购成本。

这样得到的结论，会比单纯计算“2.8 万亿参数压缩到多少 GB”更接近真实部署情况，也更能帮助决策者避免在错误指标上做出错误判断。