本地部署万亿参数MoE大模型要花多少钱？

一、先明确问题性质：这不是“买几张卡”，而是一道存储墙工程题

在讨论如何本地部署一个2.8万亿参数量级的MoE大模型之前，先立三条基本原则，后面的所有推算都建立在这三条之上：

1. MoE的显存占用按总参数计算，激活比例只影响算力消耗。 该模型共896个专家，每个token仅路由激活16个，专家激活比例约1.79%。但路由结果依赖输入内容，推理前无法预知哪个token会命中哪个专家，因此896个专家必须全部驻留在可寻址存储中。换句话说，1.79%的激活比例省的是算力，不是显存。另外注意，这是“专家数量激活比例”，并不严格等于“参数激活比例”，因为共享层始终参与计算、各专家参数量也可能不均。
2. 量化感知训练决定了部署下限。 该模型从SFT阶段起就按MXFP4权重、MXFP8激活做了量化感知训练，意味着4-bit部署不是“牺牲精度换显存”的权宜之计，而是官方设计路径，也是一切估算的基准。
3. 权重正式发布前，一切数字都是估算。 下文的速度、显存、硬件配置均为基于公开架构信息的推算，实际落地前必须用基准测试逐项核验。

补充一点架构背景：这类新一代模型的注意力主干多采用线性注意力与门控型KV压缩注意力混合的设计，并引入注意力残差结构，KV cache的增长速度显著低于传统全注意力。这对部署是利好——但利好的是长上下文场景下的KV显存，而不是那1.5TB的权重本体。

二、显存下限测算：约1.5TB只是起点

MXFP4并非纯4-bit。按微缩放量化格式规范，每32个4-bit元素还要共享一个8-bit scale，等效每个权重4.25 bit。用一段伪代码把账算清楚：

# MoE权重显存下限估算（MXFP4 + 每32元素一个8bit scale）
total_params = 2.8e12
bits_per_weight = 4 + 8 / 32                  # = 4.25 bit
weights_gb = total_params * bits_per_weight / 8 / 1e9   # ≈ 1487.5 GB

1487.5GB只是“裸权重”下限，实际部署还要叠加：

• 非4-bit张量：embedding、路由器、各类归一化层、注意力高精度部分通常保留FP8/BF16，占比不高但绝对值可观；
• KV cache：每token约为 2 × 层数 × KV头数 × 头维度 × 精度字节数，压缩型注意力可将其压到每token几十KB量级，但10路并发 × 32K上下文仍可能累积到数十GB；
• 运行时开销：激活值工作区、图模式执行缓冲、all-to-all通信缓冲区，动辄数十GB。

综合来看，实际显存需求按1.6TB以上规划才稳妥。

做个对照：业界主流的六七百B参数量级MoE模型，FP8格式下约685GB；做4-bit量化后权重约335GB、加上激活约400GB，8张80GB级加速卡（共640GB显存）即可承载。而本文讨论的模型体量是它的4倍以上——这就是“满血部署”门槛的由来。

三、三档部署目标，对应三套预算

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

目标：把近1.5TB权重装进能寻址的存储，让模型吐出token，哪怕每秒只有个位数。

思路：GPU与CPU异构推理。MoE每层的共享注意力部分计算密集，留在GPU上吃高带宽；896个稀疏专家占大头存储但每次只激活16个，全部卸载到CPU内存，用大内存服务器喂养。开源社区已有成熟框架按此思路实现，核心手段是逐层调度与专家预取，尽量掩盖PCIe搬运延迟；还可以用NVMe做专家分层缓存与热度缓存，但速度会进一步下降。

参考配置：双路服务器、2TB DDR5内存，另配1~2张24~48GB级显卡负责注意力计算与调度。

速度与预算：每token需从内存读取约27GB数据（激活约50B参数 × 4.25bit），受内存带宽与调度开销限制，实际只有个位数tokens/s，首token等待可能到分钟级。整机加显卡预算约20万~40万元。适合技术预研、离线批处理和可行性验证。

档位二：单人使用，输出25 tokens/s

25 tokens/s大致是人的舒适阅读速度，这是“可用”的底线。关键变化在于：权重必须常驻显存，靠CPU内存兜底撑不起这个速度。

先算一笔带宽账：每token激活约50B参数，4-bit下读取量约27GB；若权重摊在24张卡上，每卡每token只需读约1.1GB，25 tokens/s对应每卡约28GB/s——远低于单卡高带宽显存数TB/s的上限。瓶颈不在带宽，而在把1.5TB塞进显存本身。

参考配置：1487.5GB ÷ 80GB ≈ 19张卡是纯权重下限，加上KV cache与运行时余量，按24张80GB级数据中心加速卡（3台8卡服务器）规划；若选用141GB级大显存单卡，可压缩到16张（2台服务器）；节点间配200G级RDMA网络。若模型附带多token预测或投机解码模块，还需为其权重与缓存额外预留显存。

预算：按近年市场行情，一台8卡80GB级服务器约200万~300万元，3台加上网络与存储，总投入约600万~1000万元。

档位三：10并发，人均25 tokens/s以上

聚合解码吞吐需≥250 tokens/s，还要叠加多路长上下文prefill的算力需求，这已经是小型推理集群的形态。官方建议用64张以上加速器组成的超节点，原因见下一节。若业务对量化精度还有下限要求，显存与卡数预算需按更高精度重新核算。

参考配置：8台8卡服务器（64卡）+ 400G级RDMA网络与交换设备 + 高性能并行存储 + 机房改造（供电、散热、承重）。

预算：硬件约2000万~3000万元，加上网络、存储与机房，总投入2500万元起步。别忘了隐性成本：64卡集群整机功耗约80kW以上，按PUE 1.3与工业电价折算，每年电费可达数十万元，且至少需要一名专职运维工程师。

四、为什么10并发必须上“超节点”？

大规模MoE推理对all-to-all通信带宽极度敏感。896个专家分布在几十张卡上，每个token路由后，要把激活值搬运到目标专家所在的卡，算完再搬回来，一去一回各是一次全局all-to-all。

• 若专家分布在普通以太网连接的多机上，网络延迟与带宽会直接吃掉GPU算力，卡越多浪费越严重；
• 超节点的本质，是用高带宽、低延迟的互联总线把几十上百张卡圈进同一个通信域，让这种搬运不出域，通信成本从“跨网络”降级为“域内转发”。

换句话说，档位二拼的是显存容量，档位三拼的是互联架构——这是两道完全不同的工程题。

五、容易被忽略的隐性成本清单

• 存储：权重文件约1.5TB，生产环境要多副本，需配对象存储或并行文件系统；
• 网络：400G交换机与光模块是“卖配件”式消费，几十万元很快花完；
• 电力与散热：如上所述，每年数十万元起步；
• 运维人力：大规模分布式推理的调试、监控、故障恢复都需要专人；
• 折旧风险：模型迭代速度快，硬件生命周期与模型生命周期错配，是自建最大的长期风险。

六、自建还是上云？先算TCO再拍板

三档方案对应三种画像：

档位	速度	预算量级	适合谁
异构能跑	个位数tps	20万~40万元	预研、离线任务
单人25tps	25 tps	600万~1000万元	长期高频的重度个人使用
10并发	10×25 tps	2500万元以上	有持续服务需求与运维团队

务实的建议是分阶段走：先按量租用云上算力验证业务价值——以百度智能云为代表的云厂商提供从单卡到多机多卡的GPU实例、专属资源池以及托管的大模型推理服务，按量计费、无需初始重资产投入；等并发、时延、数据驻留等需求被真实数据验证后，再决定是否自建。把API调用成本、云上租用成本与自建TCO（含电费、运维、折旧）放进同一张表里算，答案通常会自己浮现。

七、写在最后

• 所有数字均基于公开信息估算，权重正式发布后请用基准测试逐项核验；
• 先想清楚你要的是“能跑”“单人可用”还是“并发服务”，三者的预算差出一个数量级；
• MoE的显存账按总参数算，算力账按激活参数算——想清楚这一点，预算就不会算错方向。