超大规模 MoE 模型本地部署的硬件成本与分层规划

一、为什么“能不能部署”先看总参数，而不是激活参数

大规模稀疏 MoE 模型有一个容易误判的地方：很多人习惯用“激活参数”估算推理成本，但本地部署时，首先要解决的是“权重往哪里放”。

以万亿级 MoE 架构为例，如果总参数规模达到 2.8 万亿，专家数量接近 900 个，每个 token 只激活其中十几个专家，那么单次前向的算力消耗确实远低于稠密模型。但这并不意味着只需要按激活比例准备显存。推理过程中，路由器必须能够访问全部专家权重，才能根据 token 特征选择正确的专家路径。换句话说：

• 激活比例影响的是“算多少”；
• 总参数量影响的是“存多少”；
• 路由与通信设计影响的是“存完之后能不能高效取用”。

因此，在硬件规划阶段，第一步应按照总参数量计算权重存储下限，再根据量化格式、分组粒度、运行时开销和并发需求逐层上浮。

二、权重量化后的显存下限如何估算

2.1 从比特数到字节数

假设一个模型总参数为 P，采用 b-bit 量化存储，那么裸权重体积可以近似为：

权重裸体积 ≈ P × b / 8 字节

对于 2.8 万亿参数、4-bit 量化的场景：

2.8T × 4 / 8 = 1400GB

这只是一个理论下限，实际部署通常还要考虑以下因素：

1. 量化 scale 与 zero-point：分组量化或块量化会在每个块内附加 scale 参数。例如每 32 个元素共享一个 8-bit scale，实际等效位宽可能从 4.0 bit 上升到 4.25 bit 甚至更高。
2. 非量化张量：部分归一化层、嵌入层、路由器、偏置项可能保留 FP16、BF16 或 FP8，体积单独计算。
3. 对齐与碎片：显存分配通常按页或块对齐，实际占用高于算术值。
4. KV cache：长序列或多并发下，KV cache 可能成为额外的大头。
5. 运行时工作区：通信缓冲、激活暂存、内核启动 workspace 等。

以 2.8T 参数、4-bit 量化并按每 32 个元素附加 8-bit scale 计算，权重部分的等效体积约为：

2.8T × 4.25 / 8 ≈ 1487.5GB

再叠加非量化张量、KV cache 预留和运行时缓冲，单副本满血推理更容易落在 1.6TB 到 2TB 以上的显存区间。

2.2 为什么不能只看权重体积

很多初次做本地部署的团队只计算权重文件大小，但推理服务是持续运行的系统，不是一次性加载。真正决定能否稳定服务的，是峰值显存占用，包括：

• 权重常驻部分；
• 激活值随 batch 与序列长度变化；
• KV cache 随并发请求增长；
• 通信库与计算内核的临时缓冲；
• 多副本或滚动更新时的冗余。

因此在容量规划时，建议至少预留 20% 到 30% 的显存余量。对于万亿级模型，这意味着要多准备数百 GB 空间。

三、三个部署层次的硬件规划思路

用户通常关心三个层次：能跑、单人流畅、多并发生产级。

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

这一层的目标是验证模型能否加载并完成推理，适用于权重结构验证、单条请求功能测试或学术研究。

最低要求是总显存大于权重体积与最小运行时开销之和。如果按 4-bit 量化后权重约 1.5TB 计算，至少需要总显存超过 1.6TB 的加速器集群。

达到这一显存规模，常见做法有两种：

1. 多卡堆叠：例如单卡 80GB 显存，需要 20 张以上；单卡 141GB 或 192GB，则需要约 8 到 12 张。
2. 大显存推理卡：使用单卡 256GB 或 512GB 的推理设备，可能 4 到 8 张即可容纳。

但要注意，能加载不代表能高效运行。如果卡间互联带宽不足，一次前向可能耗时数分钟。因此这一层次适合功能验证，不适合对外服务。

3.2 层次二：单人使用，输出速度达到 25 tokens/s

当用户对交互体验有要求时，输出速度成为关键指标。单人输出达到每秒 25 个 token，意味着从解码到采样再到传输，单 token 总延迟需要控制在 40ms 以内。

影响输出速度的主要因素包括：

• 单 token 的计算量；
• 专家路由与卡间通信延迟；
• batch 规模与调度效率；
• 量化后内核的算力利用率。

在万亿级 MoE 模型中，虽然每个 token 只激活少量专家，但专家分布在多张卡上，路由后的 all-to-all 通信会成为瓶颈。如果卡间是慢速互连，即使单卡算力充足，通信等待也可能把单 token 延迟推高到数百毫秒。

为了实现 25 tokens/s，通常需要：

1. 高带宽卡间互连：使用 NVLink、PCIe Gen5 以上的高速总线或专用推理互连，确保 all-to-all 通信不成为主瓶颈。
2. 足够的计算吞吐：单并发条件下，需要激活参数对应的算力与显存带宽都能支撑目标输出速度。
3. 低延迟量化内核：使用 FP8 或 4-bit 量化内核，减少权重读取时间。
4. 合理的专家放置策略：尽量让常被同时激活的专家位于同一通信域或同一节点内。

这一层次的硬件量级不再只是显存问题，而是“显存 + 算力 + 互连”的综合问题。实际部署中，通常需要 8 卡以上的高速互连节点，且单卡显存不低于 141GB 或 192GB 更稳妥。

3.3 层次三：10 并发，单人输出速度仍保持 25 tokens/s

并发场景的本质是吞吐与延迟的平衡。10 个并发请求同时要求 25 tokens/s，意味着系统总输出速率需要达到 250 tokens/s。如果输入长度较长，预填充阶段还会引入额外波动。

并发部署的关键变化在于：

• batch 变大，算力需求近似线性上升；
• KV cache 总量显著增加；
• 调度策略必须兼顾延迟敏感请求；
• 单节点可能无法同时满足显存与算力要求，需要跨节点部署。

在这个层次上，单靠堆显存已经不够。必须将总吞吐需求换算为计算量：

总吞吐 ≈ 并发数 × 输出速度

10 并发 × 25 tokens/s 即 250 tokens/s。模型每输出一个 token 的算力消耗取决于激活参数、序列长度和 batch 效率。随着 batch 增大，显存带宽利用率可能提升，但通信冲突也会增加。

因此，10 并发 25 tokens/s 的部署通常建议采用多节点方案：

• 每节点 8 张加速器；
• 节点内高速互连，节点间使用高带宽低延迟网络；
• 权重按专家维度切分并分布到多个节点；
• 使用专门针对 MoE 的推理引擎进行专家并行与流水线调度。

这种形态已经接近小型推理集群，硬件规模可能达到 16 卡、32 卡甚至更多。

四、通信拓扑为什么比单卡算力更重要

MoE 推理有一个显著特征：每个 token 在每一层都要经过路由选择，将中间表示发送到对应专家所在的设备。对于 900 个专家、每 token 激活十几个专家的模型，这种 all-to-all 通信非常频繁。

如果 900 个专家分布在 64 张卡上，每个 token 每层都要与其中 16 个专家所在卡通信。一个完整前向可能包含数十层，通信次数会成倍增加。通信延迟直接影响端到端延迟，而通信带宽上限决定系统吞吐上限。

因此，在硬件选型时，应优先考虑：

1. 通信域越大越好：尽量让专家分布集中在高速互连域内。
2. 拓扑对 MoE 友好：胖树、全互连或高基数交换结构更适合 all-to-all 模式。
3. 避免跨机箱频繁通信：如果能将常共激活的专家组合放置在同一节点，可显著降低跨节点流量。

这也是为什么超大规模 MoE 推理往往不是“买几张卡插到主机里”，而是需要仔细设计超节点或推理集群。

五、成本估算的基本框架

在不涉及具体厂商报价的前提下，可以按硬件类别建立成本模型。

5.1 显存成本占比最高

对于万亿级模型，显存容量是刚性约束，直接决定起步硬件数量。以 4-bit 量化约 1.5TB 权重为基准：

• 若单卡有效显存为 80GB，则需要至少 20 张卡才能容纳权重，加上开销可能要到 24 张。
• 若单卡有效显存为 141GB，则需要约 11 到 12 张。
• 若单卡有效显存为 192GB，则需要约 8 到 9 张。

不同显存规格的卡单价差异较大，因此总成本并不与卡数线性相关。

5.2 互连与整机成本容易被低估

多卡训练或推理往往需要整机或超节点方案，而不是单卡自由组合。高速互连背板、交换机、光模块、电源与散热都会增加成本。对于 8 卡以上的系统，互连与机柜成本可能占总投入的 20% 到 40%。

5.3 层次一、二、三的成本跨度

• 能跑：最低只需满足显存要求，可能几张到十几张大显存卡即可，但不对速度负责。
• 单人流畅：需要加入高速互连和足够算力，成本往往是“能跑”的 1.5 到 3 倍。
• 多并发生产级：需要多节点、高性能网络和推理优化，成本可能再翻倍，并产生持续运维投入。

因此，在权重正式发布前，比较务实的做法是先确定目标并发与延迟，再反推算力、显存和互连，最后综合评估是一次性买断还是租用云上推理资源。

六、云上部署是否更划算

对于大多数开发者或中小企业而言，本地部署万亿级 MoE 模型不仅要承担硬件采购成本，还要面对供电、散热、机柜、运维与故障恢复等问题。除非有长期稳定的高并发需求，否则一次性投入很难摊薄。

云上推理通常提供：

• 按小时或按 token 计费的能力；
• 不同显存与算力规格的实例组合；
• 已优化的推理镜像与调度能力；
• 弹性扩缩容，避免为峰值常备大量硬件。

对于“偶尔验证”或“间歇性使用”的场景，云上按量付费往往比本地买卡更经济。对于“持续高并发”的场景，则可通过长期折扣或预留实例降低单位成本。选择本地还是云上，本质上取决于负载稳定性和利用率。

七、权重发布前可以做的准备工作

即使完整权重尚未发布，团队仍然可以提前完成大量规划工作。

7.1 建立显存与算力估算表

根据官方公布的总参数、专家数量、激活专家数、量化格式和最大序列长度，建立表格计算：

• 不同量化位宽下的权重体积；
• 不同 batch 与序列长度下的 KV cache；
• 峰值显存需求；
• 目标吞吐对应的理论算力要求。

7.2 验证推理框架对大规模 MoE 的支持能力

提前在中等规模 MoE 模型上验证所选推理框架的专家并行、路由通信和量化内核是否稳定。重点观察：

• all-to-all 通信效率；
• 长序列下 KV cache 管理；
• 4-bit 量化的精度损失是否在可接受范围。

7.3 小规模压测外推

如果无法直接测试万亿级模型，可以使用数百亿参数的 MoE 模型进行基准测试，记录单卡、4 卡、8 卡下的延迟与吞吐变化，外推更大规模的资源需求。外推时要注意通信模式的变化，但至少可以建立基本趋势判断。

八、总结

万亿级 MoE 模型的本地部署是一条明显分层的路径：

• 能跑只解决显存容量问题；
• 单人流畅要求显存、算力与互连同时达标；
• 多并发生产级则进入分布式推理集群的设计范畴。

在完整权重发布前，所有数字都应是估算值，而非采购依据。更稳妥的做法是：先根据总参数与量化格式建立容量模型，再结合目标吞吐推导算力与通信需求，最后通过中小规模基准测试校准假设。对于利用率不稳定或运维能力有限的团队，优先考虑云上弹性推理资源，通常比一次性采购大量本地硬件更具性价比。