本地部署万亿级 MoE 大模型：显存测算、硬件选型与成本分层指南

一、先明确边界：本文能回答什么，不能回答什么

在讨论具体数字之前，必须先划定讨论的边界。万亿级 MoE 大模型的完整权重与技术报告尚未公开时，任何关于吞吐、显存占用、硬件配置的数字都只能是基于公开架构信息的工程估算，而非实测结论。因此本文的方法论是：

• 可确定的部分：参数量与架构比例决定的理论显存下限、量化格式的位宽换算、MoE 推理的通信模式。
• 需估算的部分：运行时工作区、KV Cache、框架开销、通信缓冲。
• 必须实测核验的部分：实际吞吐（tokens/s）、并发扩展效率、量化后的精度损失。

建议读者在权重放出后，按本文给出的测算项逐条做基准测试校准，而不是直接采信任何单一数字。

二、理解容量：MoE 架构下显存到底被什么吃掉

2.1 总参数决定存储，激活比例决定算力

以总参数约 2.8 万亿的 MoE 模型为例，其典型结构是：每层包含数百个专家（如 896 个），每个 token 经路由后仅激活其中少量专家（如 16 个），专家激活比例约 1.79%。这里有一个极易混淆的点：

• 专家激活比例 ≠ 参数激活比例。共享专家、注意力主干、嵌入层等在各 token 间始终参与计算，因此严格意义上的参数激活比例会高于专家激活比例。
• 显存占用按总参数计算。推理时全部专家都必须常驻存储（或可快速换入），路由只是决定“这次算哪几个”，不减少存储需求。
• 算力消耗按激活部分计算。这决定了你需要的浮点算力规模，而非显存规模。

因此部署规划的第一原则是：先按总参数算显存，再按激活比例算算力，两者不能互相折算。

2.2 量化位宽换算：4-bit 不等于“参数量除以 2”

很多人会简单地用“参数量 × 位宽 ÷ 8”估算权重体积。对于带块级缩放因子的 4-bit 格式，这个算法会显著低估。以业界常见的 MXFP4 类格式为例，每 32 个 4-bit 元素附带一个 8-bit 缩放因子，等效位宽为：

等效位宽 = 4 + 8/32 = 4.25 bit
权重体积 ≈ 2.8e12 × 4.25 / 8 ≈ 1487.5 GB

这是裸权重的理论下限，尚未计入：

• 非 4-bit 量化张量（如层归一化、部分注意力组件保持更高精度）；
• 张量元数据、对齐填充；
• 运行时工作区（临时缓冲、通信缓冲）；
• KV Cache（随并发数与上下文长度线性增长）。

作为横向参照：一个约 670B 级别的 MoE 模型，在 FP8 下主参数加多 token 预测头约需 685GB；改用 4-bit 权重量化后仍需约 335GB 权重加数十 GB 激活缓冲，合计约 400GB 才能在 8 张 80GB 级加速器（合计 640GB）上留有余量地运行。万亿级模型体量约为其四倍以上，满血部署的显存下限由此可以直观推得——单机 8 卡远远不够。

2.3 一个实用的容量测算清单

建议按如下顺序逐项累加，形成自己的预算表：

组成项	估算方式	备注
量化权重	总参数 × 等效位宽 ÷ 8	注意缩放因子开销
非量化张量	按框架实现实测	通常为数 GB 到数十 GB
KV Cache	层数 × 头数 × 头维度 × 2 × 上下文长度 × 并发数 × 精度字节	并发目标直接放大此项
运行时工作区	框架相关，建议预留权重体积的 5%–10%	通信缓冲在大规模 MoE 中不可忽略
冗余与碎片	预留 10% 左右	避免显存碎片导致 OOM

三、通信：大规模 MoE 推理的真正瓶颈

MoE 推理的通信模式是 all-to-all：每个 token 路由后，其激活值需要被搬运到目标专家所在的设备上计算，算完再搬回。专家数量越多、分布越分散，这种搬运越频繁。

这带来两个直接后果：

1. 通信延迟会吃掉算力。即使单卡算力充足，若 all-to-all 跨越了低速互联边界，端到端吞吐会被通信拖住，表现为 GPU 利用率上不去。
2. 通信域大小决定可用拓扑。业界常见做法是用高带宽互联（如 NVLink 级别或同等高速互联）构建超节点，把数百个专家的分布控制在一个通信域内，使 all-to-all 不出域。官方对万亿级模型的部署建议通常在 64 张以上加速器组成的超节点量级，正是这个原因。

对自建部署者而言，这意味着：单纯堆叠普通以太网互联的机器，很难达到可用的推理吞吐，硬件预算中互联成本占比会显著高于中小模型部署。

四、按目标分层：三档配置的估算框架

4.1 第一档：只要能跑，不关心速度

目标：验证权重可加载、推理可出结果，用于研究、调试或演示。

思路：接受极低吞吐，甚至容忍部分专家换入换出（offload 到主机内存或本地高速存储）。可用较低量化等级（如 4-bit）压低权重体积，用更少的加速器配合大容量主机内存凑出“能加载”的最小配置。

估算要点：

• 权重体积约 1.5TB 量级，主机内存需能容纳未常驻部分；
• 加速器数量以满足“单卡可放下单层或部分专家”为准，通常需要多机多卡；
• 互联可用较低带宽方案，因为换入换出本身已是瓶颈，通信不再是主要矛盾；
• 吞吐可能低至个位数 tokens/s，交互体验差，但足以做正确性验证。

成本形态：以“凑容量”为主，加速器数量少但单机内存与存储配置高，整体投入相对可控，但可用性有限。

4.2 第二档：单人使用，输出速度达到 25 tokens/s

目标：单人交互式使用，输出速度达到 25 tokens/s 以上，体验接近可用。

思路：权重必须全部常驻显存，KV Cache 按单人短上下文预留，通信域需覆盖全部专家。

估算要点：

• 显存需求 ≈ 量化权重 1.5TB + 工作区与 KV Cache 余量，实际配置需明显高于理论下限；
• 25 tokens/s 是端到端指标，需扣除 prefill 与通信开销，因此单卡算力与互联带宽都要留足余量；
• 若采用 80GB 级加速器，按有效显存利用率 80% 计算，所需卡数约为 1.5TB / (80GB × 0.8) ≈ 24 张，考虑余量与拓扑约束，实际往往落在 32 张量级；
• 这一档要求全部专家在同一高速通信域内，超节点成为必选项。

成本形态：加速器数量进入数十张量级，互联成本显著上升，是“可用性”与“成本”的第一个平衡点。

4.3 第三档：10 并发，单路输出仍达 25 tokens/s 以上

目标：10 路并发请求下，每路输出速度不低于 25 tokens/s，且量化等级不低于 4-bit（如 MXFP4 权重配更高精度激活）。

思路：这是最接近生产可用的一档，核心变化在 KV Cache 与调度。

估算要点：

• KV Cache 随并发数线性放大。假设单路上下文 8K、模型层数与头配置处于万亿级 MoE 的常见区间，10 路并发的 KV Cache 可达数十 GB 到上百 GB 量级，必须在显存预算中单独列项；
• 批处理会提升算力利用率，但也放大通信量，all-to-all 的缓冲需求同步上升；
• 为维持单路 25 tokens/s，需要保证批内每路的解码延迟不被其他请求拖垮，调度策略与连续批处理能力变得关键；
• 加速器数量通常在第二档基础上再增加 50%–100%，即 48–64 张量级，具体取决于互联拓扑与框架效率。

成本形态：进入“小型集群”范畴，除加速器外还需考虑高速互联交换、供电与散热改造，总拥有成本（TCO）应按三年周期折算，而非只看采购价。

五、成本测算的正确姿势

不要只问“要花多少钱”，而要按下面的框架逐项填数：

1. 加速器采购或租用成本：按所需卡数 × 单价，注意高带宽互联版本单价更高。
2. 互联与交换设备：超节点方案中此项占比不可忽视。
3. 主机与存储：大容量内存、高速本地存储（用于权重加载与 offload）。
4. 机房条件：供电容量、散热能力，数十张高功耗加速器通常需要专门改造。
5. 软件与运维：推理框架适配、量化校准、基准测试与持续调优的人力成本。
6. 电力与折旧：按满载功耗 × 电价 × 运行时长估算，三年折旧是常见口径。

一个粗略的经验比例是：在数十卡规模的部署中，加速器本身约占总投入的一半到三分之二，互联、机房与运维占据其余部分。只看卡价会严重低估实际支出。

六、落地建议与核验清单

权重发布后，建议按以下顺序做核验，避免“纸面配置”翻车：

1. 加载测试：确认量化权重可完整加载，记录实际显存占用与理论值的偏差
2. 单路基准：固定输入长度与输出长度，测 prefill 与 decode 分段耗时
3. 通信剖析：抓取 all-to-all 耗时占比，判断是否受互联限制
4. 并发扫描：从 1 路逐步加到 10 路，记录每路 tokens/s 衰减曲线
5. 精度抽检：对比量化前后在代表性任务上的输出差异
6. 长稳测试：连续运行数小时，观察显存碎片与吞吐漂移

结论：万亿级 MoE 模型的本地部署，本质是一道“显存容量 + 互联带宽 + 并发预算”的三元约束题。第一档靠凑容量，第二档靠超节点常驻，第三档靠容量与调度的双重冗余。在权重与实测数据公开前，本文给出的所有数字都应视为预算框架的输入假设，而非结论；真正决定成败的，是权重发布后那套逐项核验的基准测试流程。