超大 MoE 模型本地部署的硬件成本与分层方案估算

一、先厘清一个核心前提：万亿级 MoE 的本地部署，难点不在“跑”，而在“跑得好”

当前业内讨论较多的新一代超大规模混合专家模型，普遍具备万亿级总参数、稀疏激活、低激活比例、量化感知训练等特征。以近期受到关注的某 2.8 万亿参数模型为例，其设计目标是在保持较高生成质量的同时，通过稀疏专家结构降低单 token 推理算力。但这并不意味着本地部署门槛低，反而对显存总量、存储带宽、节点内互联和推理框架都提出了更高要求。

在具体计算成本前，必须先明确一个常被误解的点：MoE 模型的显存占用由总参数量决定，而不是由“激活参数”决定。一个 2.8 万亿参数的模型，即便每个 token 只激活其中约 1.79% 的专家，推理系统仍然需要把所有专家权重都放在可被快速寻址的存储中。换句话说，稀疏激活降低的是计算密度，而不是权重驻留需求。

因此，评估本地部署成本时，不能只看“每秒能生成多少 token”的算力指标，还要同时满足三个条件：

1. 所有权重可被完整加载；
2. 权重所在介质具备足够高的读写带宽；
3. 多卡之间的通信延迟不会在专家路由过程中形成严重瓶颈。

这三点共同决定了硬件选型、量化等级和部署方案的下限。

---

二、从权重量级出发：2.8 万亿参数到底需要多少显存或内存

2.1 总参数量与显存的直接关系

假设模型总参数为 2.8T，即约 2.8 × 10¹² 个参数。如果采用常规 FP8 精度存储，仅权重部分的理论体积约为：

2.8T × 1 Byte = 2800 GB

考虑到实际推理中还需要保留激活值、优化器状态、通信缓冲区和运行时元数据，FP8 全量部署至少需要 3 TB 以上的有效存储空间。这个数字远超单机 8 卡、甚至 16 卡常见 GPU 服务器的显存总和。

2.2 低比特量化后的权重体积

如果采用 4-bit 权重格式，理论裸权重可以压缩到约：

2.8T × 0.5 Byte = 1400 GB

但实际工业级 4-bit 格式往往不是单纯的 4-bit 存储。例如某些微缩放格式要求每 32 个 4-bit 元素携带一个 8-bit 缩放因子，等效位宽会从 4 bit 增加到约 4.25 bit。按照该口径重新计算：

2.8T × 4.25 bit ÷ 8 = 1487.5 GB

这还不包括：

• 非 4-bit 张量，例如路由网络、嵌入层、归一化层；
• 模型分片产生的对齐与重复数据；
• 推理时的 KV Cache；
• 多卡通信缓冲与工作区。

所以，即使采用较激进的 4-bit 权重格式，仅“装下”模型就需要至少 1.5 TB 以上的可用存储。如果还要保证推理速度，实际需要的显存或高速内存会更高。

2.3 和上一代 671B 模型的直观对比

为了更直观地理解这一量级，可以参考上一代 671B 稠密 MoE 模型的工程经验。该模型在 FP8 下主权重约 685 GB，4-bit 量化后也要约 335 GB 权重和 37 GB 激活，合计约 400 GB，才能在 8 张 80 GB 显存的加速卡上勉强运行。

而 2.8T 参数模型的体量是 671B 的四倍以上。即使考虑更先进的压缩方法，其最低部署门槛仍然会大幅超过单台普通 GPU 服务器的显存容量。这也是为什么官方部署建议会直接指向 64 卡以上超节点，而不是常见的单机 8 卡或 16 卡方案。

---

三、MoE 架构的隐性成本：专家路由与全互联通信

3.1 为什么大规模 MoE 对通信带宽极度敏感

在稠密模型中，每一层的计算都可以在单卡或少数几张卡内完成，通信需求主要集中在张量并行或流水线并行的边界。

而大规模 MoE 的推理过程是另一套逻辑：

1. 每个 token 进入 MoE 层后，先经过路由计算；
2. 路由模块从数百个专家中选出若干个；
3. token 的隐藏状态被发送到对应专家所在的物理设备；
4. 专家完成前向计算；
5. 计算结果再传回原始设备。

如果专家分布在几十张甚至上百张卡上，而每张卡只持有其中一部分专家权重，那么每个 token 的处理过程就会触发多次跨卡数据搬运。对于 896 个专家、每个 token 激活 16 个专家的结构来说，这种通信模式并不是偶发性的，而是每个 token、每一层都会发生。

3.2 为什么需要超节点而不是普通集群

普通的以太网或中等带宽互联在多机通信时，延迟通常显著高于单机内部互联。一旦专家路由路径经过多次跨机跳转，端到端延迟会迅速累积，最终导致每 token 生成时间被通信主导，而不是被计算主导。

因此，大规模 MoE 的高性能部署通常要求：

• 尽量将专家权重放在同一高速互联域内；
• 使用 NVLink、超高速交换机或同等机制构建大带宽、低延迟通信域；
• 避免 all-to-all 通信跨越过多网络层级。

这也是为什么 64 卡以上的超节点会成为此类模型部署的推荐起点。不是“需要 64 张卡才能放下权重”，而是“需要使用 64 张卡来获得可接受的通信和并行效率”。

---

四、层次一：只要能跑，不关心速度

对于个人研究者、教学实验或早期评估场景来说，第一目标是让模型能够输出 token，即使速度较低也可以接受。

4.1 显存不够时，能否用 CPU 内存补充

最直接的思路是异构推理：把计算密集但参数量较小的部分留在 GPU 上，把占据绝大部分存储但每次只激活少数的专家权重卸载到 CPU 内存中。

在这种方案中：

• 注意力模块、共享层、输入输出嵌入等计算密集部分适合保留在加速卡上；
• 大部分稀疏专家层可以放在主机内存中；
• 推理时根据路由结果，只加载被命中的专家权重到 GPU 进行计算。

这种思路在上一代 671B 模型社区实践中已经得到验证。例如双路高端服务器处理器搭配消费级或工作站级 GPU，可以运行 4-bit 量化的稠密 MoE 模型，虽然生成速度较低，但至少可以完成完整推理。

4.2 对 2.8T 模型而言，纯异构方案的难点在哪里

但将同一思路平移到 2.8T 参数模型时，问题会明显放大：

• 总权重超过 1.4 TB，即使放在 CPU 内存中，也需要至少 1.5 TB 以上的可用内存，一套双路服务器通常需要满载大容量内存条；
• 每次专家加载的粒度、缓存策略和内存带宽都会成为瓶颈；
• 即使只激活少量专家，单个专家的权重体积仍然不小，CPU 与 GPU 之间的搬运时间会显著拖慢速度；
• 路由模块本身也需要在 GPU 和 CPU 之间频繁交换数据。

因此，“能跑”的定义会被压缩到极低速度，例如每秒生成个位数 token，甚至更低。对于需要交互式体验的场景，这种方案几乎没有实用价值，但对于权重验证、单次推理、学术观察和早期研究仍有一定意义。

4.3 层次一的最低硬件形态参考

从工程可行性角度估算，层次一的最低配置可能需要满足：

• 至少 1.5 TB 以上可用 DRAM；
• 至少一张中高端 GPU 用于注意力与路由计算；
• 主板 PCIe 带宽越高越好，用于减少 CPU 与 GPU 之间的传输瓶颈；
• 推理框架需要支持 MoE 状态管理和按需权重加载。

整体硬件成本可能落在数十万元级别，主要开销来自大容量内存服务器和高端加速卡，而不是 GPU 数量本身。

---

五、层次二：单人可用，输出速度达到 25 tokens/s

对开发者、研究人员或重度个人用户来说，25 tokens/s 是一个较为实用的交互体验门槛。在这个速度下，模型可以在几秒内生成数百字答案，适合调试、写作辅助和自动化任务。

5.1 速度要求对显存介质提出更高约束

当目标不是“能跑”，而是“流畅输出”时，CPU 内存方案基本不可行。原因是：

生成速度 = 计算时间 + 权重搬运时间 + 通信时间

在异构方案中，权重搬运会占据绝对主导。即使单次前向计算很快，但每生成一个 token 都需要等待专家权重从内存加载到加速卡，整体吞吐会迅速下降到个位数 token/s。

因此，要在 25 tokens/s 下运行，必须大幅度减少跨介质搬运，尽可能让权重驻留在高带宽显存中。

5.2 是否必须所有权重都进入 GPU 显存

从理想部署角度看，至少所有会被频繁激活的权重和相关路由结构都应进入高速显存。对于超大规模 MoE，虽然每个 token 只激活少量专家，但从批次、时间片和缓存命中率出发，仍然需要足够的 GPU 显存来容纳大部分活跃权重。否则，即使平均激活比例很低，权重换入换出也会造成卡顿。

5.3 多卡共享是否可行

在单机内部，多张加速卡可以通过高速互联组成一个大的显存池。对于小型或中型 MoE，这种方案可以显著扩大可用显存。但当模型总权重超过 1.4 TB 后，单机 8 到 16 张卡仍然难以满足全部驻留需求。

假设单卡显存为 80 GB，8 卡总共只有 640 GB，加上量化后的模型权重已经接近 1.5 TB，显然无法完全驻留。16 卡 80 GB 也仅 1.28 TB，依然不够。因此，层次二的最小系统规模可能被迫上探到多机部署。

5.4 量化等级与速度的关系

在 25 tokens/s 的目标下，量化等级不宜过低。主要原因有两个：

1. 权重精度过低会影响生成质量，尤其在长文本、推理任务和代码生成场景中表现明显；
2. 某些低比特格式在反量化时会引入额外计算和访存开销，不利于持续高吞吐。

因此，层次二更可能采用中等量化水平，例如 4-bit 到 6-bit 之间的工业级量化方案，而不是在极低位宽下强行压缩模型体积。

5.5 预算与硬件形态估算

综合权重体积、通信需求和输出速度，层次二的部署可能需要：

• 多台高速互联服务器，总显存接近或超过 1.5–2 TB；
• 每台机器内部具备高速互联；
• 机间连接具备足够大的带宽和低延迟；
• 推理框架支持稳定的专家并行和权重分片。

整体预算可能进入数百万元级别，具体取决于加速卡单价、服务器配置和互联方案。值得注意的是，这里的成本并非线性增长：当从单机跨越到多机后，不仅硬件成本增加，部署复杂度和运维成本也会明显上升。

---

六、层次三：10 并发且单人输出速度不低于 25 tokens/s

层次三的要求是在保持输出质量与速度的同时，服务多个并发请求。这不仅对单请求延迟有要求，更对系统总吞吐、调度策略和通信效率提出更高挑战。

6.1 并发的本质是放大所有资源消耗

假设单个请求的生成速度是 25 tokens/s，那么 10 个并发请求的总吞吐就是 250 tokens/s。如果这 10 个请求同时处于解码阶段，系统需要同时处理：

• 10 份 KV Cache；
• 10 份独立的路由选择；
• 10 份专家计算请求；
• 10 份结果回传。

对于稠密模型，并发可以通过增大 batch size 来摊薄计算成本。但对于大规模 MoE，随着 batch size 增大，专家的负载会变得更加不均衡，通信次数也显著增加，系统效率可能下降。

6.2 为什么并发部署更难

在单请求场景下，系统可以选择最优路径，尽量减少不必要的通信。而多请求场景更接近大规模服务环境，系统必须面对：

• 不同请求的 token 长度不同；
• 不同请求的生成阶段不一致；
• 专家负载在时间轴上剧烈波动；
• 高速互联链路被多路请求同时抢占。

因此，层次三往往需要专门的服务化推理框架，具备动态批处理、请求排队、专家缓存和负载均衡能力。普通的单机推理脚本很难满足这种要求。

6.3 量化等级不能低于工程底线

层次三不仅关注“能生成”，还要求长期服务下的质量稳定。因此，量化等级不能无底线压缩。通常建议保持在不显著影响核心能力的工程等级之上，例如 4-bit 到 8-bit 之间的主流方案，并根据具体任务进行校准和验证。

---

七、成本构成的完整拆解

7.1 硬件成本

硬件成本主要集中在：

• 加速卡：数量和型号直接决定显存总量；
• 服务器：双路或多路 CPU 服务器，用于承载多张加速卡和高速互联；
• 内存：超大模型权重如果落在内存中，需要大量高容量内存条；
• 存储：模型权重、数据集、KV Cache 持久化和快照需要高速固态盘；
• 网络：多机部署时需要 400G、800G 或更高速率的 RoCE、InfiniBand 等高速网络。

以层次二和层次三为例，真正的成本往往不是一张或几张加速卡的价格，而是整套计算集群的成本。

7.2 互联成本

大规模 MoE 难以依靠传统以太网获得高性能。无论是超节点内部还是跨节点之间，都需要高密度、低延迟的互联方案。这部分成本通常与加速卡成本相当，甚至更高。

7.3 工程与运维成本

本地部署不只是购买硬件，还需要：

• 熟悉大规模并行推理的工程团队；
• 针对具体硬件的量化与调优；
• 推理服务搭建、压测和扩容；
• 故障恢复和版本升级机制。

对于大多数中小企业而言，这套运维成本可能比硬件更值得关注。

---

八、权重未发布前，如何做出更稳妥的决策

当前阶段，相关模型的完整权重和技术报告尚未正式发布。此时直接采购硬件存在较大不确定性。更稳妥的做法是：

1. 先通过官方接口或云上托管方式验证模型效果；
2. 等待实际权重放出后进行基准测试；
3. 重点关注显存占用、各层张量形状、通信模式和量化后质量变化；
4. 再根据实测数据确定最终硬件方案。

对于个人用户，可以先关注社区后续提供的低配部署方案，而不要在一开始就投入大量预算。对于企业用户，更建议采用可弹性扩展的路线，避免过早锁定硬件配置。

---

九、结论

万亿级 MoE 模型的本地部署已进入“系统工程”范畴，不再是简单的单机 GPU 问题。其核心难点包括总权重过大、对高速互联要求极高，以及并发场景下的调度复杂性。

从分层目标来看：

• 只要能跑：可通过 CPU 与 GPU 异构方案勉强实现；
• 单人 25 tokens/s：需要多卡甚至多机显存驻留；
• 10 并发 25 tokens/s：需要更成熟的服务化推理架构和完整的高速互联环境。

在实际权重开放之前，最合理的策略是保持技术跟踪、等待真实基准结果，并用分阶段方式规划预算。模型能力固然重要，但能否在可控成本下稳定部署，才是决定其能否进入生产环境的关键。