万亿参数大模型本地部署：显存测算与成本解析

一、先厘清问题：本地部署一个万亿级MoE模型，到底难在哪

讨论”本地部署要花多少钱”之前，必须先回答一个更基础的问题：钱主要花在什么地方。对稠密模型而言，答案相对简单——参数量乘以每参数量所需的字节数，再加上激活值和缓存。但对采用混合专家（MoE）架构的超大规模模型，显存预算的逻辑会发生几处关键变化，而这些变化恰恰是很多部署方案在估算阶段就翻车的原因。

本文以一个总参数 2.8 万亿的 MoE 模型为分析对象，从显存测算方法出发，逐步推导硬件门槛，最后给出成本估算框架。文中的测算方法具有通用性，读者可替换参数量、量化格式等变量，套用到自身的部署场景中。

二、MoE 架构对显存的真实含义

2.1 专家激活比例 ≠ 参数激活比例

该类模型采用 MoE 架构，在 896 个专家中，每个 token 仅激活 16 个，专家激活比例约为 1.79%。这里有一个极易被误读的点：1.79% 是专家数量维度的激活比例，不能简单等同于严格的参数激活比例。模型主干中还包含注意力模块、共享层、路由网络等非专家部分，这些参数在每次前向计算中都会被使用。

更重要的是，这个比例影响的是算力消耗，而不是显存占用。MoE 部署的显存预算必须按总参数计算：

• 全部 896 个专家的权重都必须完整驻留在存储（显存或可高速访问的介质）中，因为路由是动态的，任何一个专家都可能在下一个 token 上被选中；
• 推理时根据路由结果，将激活值搬运到目标专家所在的设备上完成计算，再搬运回来；
• 激活比例只决定每次计算实际调用多少参数，从而决定 FLOPs 和访存量。

一句话总结：显存按总参数买，算力按激活参数算。这个区别直接决定了硬件配置的量级。

2.2 主干架构对显存测算的影响

该模型的主干由 KDA（Kimi Delta Attention）与 Attention Residuals 构成，Gated MLA 是其中的组件。从显存测算角度看，需要关注的是这些组件是否引入了额外的、非权重类的常驻开销。注意力类结构通常会影响 KV cache 的规模——Gated MLA 这类带压缩/门控设计的注意力变体，其 KV cache 的组织方式与标准多头注意力不同，实际占用需按具体实现计算。这也提示我们：显存预算不能只算权重，KV cache 在大规模长上下文推理中可能占据相当可观的份额。

三、量化格式：从”裸数据下限”到真实占用

3.1 4-bit 权重的理论下限

该模型从 SFT 阶段就引入了量化感知训练，权重采用 MXFP4 格式，激活采用 MXFP8。先算最理想情况：

2.8 万亿参数 × 4 bit ÷ 8 = 约 1400GB

这是常被引用的”裸数据下限”。但它只是一个下限，真实部署中不可能达到。

3.2 块量化格式的 scale 开销

MXFP4 是块浮点格式：每 32 个 4-bit 元素附带一个 8-bit 的指数（scale）。按 OCP 规范计算，每个权重元素的有效位宽为：

4 bit + 8 bit ÷ 32 = 4 + 0.25 = 4.25 bit

于是权重部分的实际占用为：

2.8T × 4.25 bit ÷ 8 ≈ 1487.5GB

仅这一项就比裸数据下限高出约 6%。很多粗略估算会忽略这个 0.25 bit，在万亿参数规模下它就是数十 GB 的偏差。

3.3 容易被漏掉的五类开销

在上面 1487.5GB 之外，还有若干必须计入的项：

1. 非 4-bit 张量：embedding、layer norm、路由网络、部分注意力参数等通常不参与 4-bit 量化，精度更高、位宽更大；
2. 元数据：张量描述、分片索引、量化参数表等；
3. 对齐开销：显存分配器按块对齐，张量边界会产生碎片；
4. 运行时工作区：临时缓冲区、通信缓冲、算子 workspace；
5. KV cache：随并发数和上下文长度线性增长，是长上下文场景下最不可控的一项。

因此，一个可落地的估算公式应当是：

总显存 ≈ 权重(含scale) + 非量化张量 + 元数据与对齐
        + 运行时工作区 + KV cache + 安全余量

工程上通常还会预留 10%~20% 的安全余量，用于应对碎片化和峰值波动。按此推算，实际可用部署的显存需求会明显高于 1487.5GB。

四、横向对比：不同体量模型的部署门槛

用一个已公开的、体量约为该模型四分之一的 MoE 模型作为参照，可以更直观地感受量级差异。

该参照模型主参数约 671B，另有约 14B 的 MTP 参数，合计约 685B：

• FP8 格式下，权重约 685GB；
• 采用 4-bit 权重量化后，权重约 335GB，加上约 37GB 激活，合计约 400GB 即可在 8 张 80GB 加速器（合计 640GB）上运行。

对比之下，2.8 万亿参数约为该参照模型的 4 倍多。即便同样采用 4-bit 量化，权重占用也在 1.4TB 以上，加上各类开销后，单机 8 卡方案完全不可行。这正是”满血部署下限”由模型体量直接决定的原因。

模型规模	量化格式	权重粗略占用	典型硬件
约 685B	FP8	约 685GB	8×80GB 可承载
约 685B	4-bit + 激活	约 400GB	8×80GB 宽裕
2.8T	MXFP4	≥1487.5GB（不含其他开销）	需多机超节点

五、为什么必须上超节点：通信才是真瓶颈

显存装得下，只是第一关。官方建议此类模型采用 64 张以上加速器组成的超节点部署，核心原因不在算力，而在通信。

大规模 MoE 推理的通信模式是 all-to-all：

1. 每个 token 经路由网络选出 16 个专家；
2. 这些专家分布在多张卡上，激活值需要按路由结果发送到对应设备；
3. 目标设备完成专家计算后，结果再回传并聚合。

这意味着每一层、每一个 token 都要经历一次跨设备的全互连通信。896 个专家分布在数十张卡上，路由分布天然不均衡，热点专家所在设备会成为通信拥塞点。通信延迟无法被算力掩盖时，加速器利用率会显著下降——钱花在卡上，卡却在等数据。

工程上的应对手段包括：

• 专家并行（EP）与张量并行（TP）混合切分，控制单卡上的专家数量，平衡路由负载；
• 高带宽互联：节点内使用高带宽域内互联，节点间使用低延迟的 RDMA 类网络，保证 all-to-all 的带宽与尾延迟；
• 通信与计算重叠：将激活值传输与本地专家计算流水化，隐藏部分延迟；
• 路由均衡策略：通过容量因子、专家负载均衡损失等手段抑制热点；
• 分层/分组路由：优先将 token 路由到同节点专家，减少跨机通信。

这些手段都需要硬件层面的高带宽互联支撑。普通以太网或 PCIe 互联的多机拼卡方案，在万亿级 MoE 上往往因通信瓶颈而无法达到可用的吞吐。

六、成本估算框架：两条路径

6.1 路径一：自建硬件

自建成本可拆为四项：

1. 加速器：按 64 张起步，显存总量需覆盖 1.5TB 以上的权重加各类开销，并留出余量；
2. 互联网络：高带宽交换设备、RDMA 网卡、线缆，超节点场景下网络成本占比不容忽视；
3. 服务器与配套：CPU、内存、本地存储、机柜、供电与散热——万亿参数模型的供电密度通常需要液冷或高功率风冷改造；
4. 运维成本：机房、电力、故障率与备件，大规模集群的 MTTR 直接影响可用算力。

一个粗略的量级判断：硬件一次性投入通常在数千万元至亿元级人民币区间，具体取决于加速器单价、互联方案与冗余等级。这个数字随供应链波动较大，建议以当期报价为准，此处仅作量级参考。

6.2 路径二：云上租用

对多数团队而言，云上租用是更现实的选择，成本结构为：

• 按需实例：按加速器卡时计费，适合验证与短期任务；
• 预留/包年包月：长期稳定负载下单位成本显著下降；
• 超节点规格：多机高带宽互联的裸金属或集群规格，需按整节点租用；
• 存储与网络：模型权重动辄 1.5TB 以上，加载与分发需要高吞吐对象存储与内网带宽；
• 配套服务：监控告警、日志、容器平台等，按通用云服务计费。

成本估算的核心变量是利用率：租来的卡闲置就是纯亏损。建议先用小规模实例验证推理链路与吞吐，再根据实测的 tokens/s 和业务量反推所需卡数与租期。

6.3 三条降低成本的工程建议

1. 先问”是否必须满血”：很多业务场景并不需要 2.8 万亿全量参数。蒸馏、裁剪或使用更小规模的同系列模型，可以把成本降低一个数量级；
2. 量化到更低位宽需谨慎：MXFP4 已是量化感知训练的结果，进一步压缩需重新评估精度损失，不可想当然；
3. 把 KV cache 当作一等公民：长上下文、高并发场景下，KV cache 可能超过权重成为显存大头。采用分页管理、前缀缓存复用、合理的最大并发限制，往往比换硬件更省钱。

七、一份可执行的部署检查清单

在真正下单采购或开通资源前，建议按以下顺序逐项确认：

[ ] 1. 明确精度要求：是否接受 MXFP4/MXFP8，精度损失是否在业务容忍范围内
[ ] 2. 测算权重占用：总参数 × 有效位宽 ÷ 8，务必计入块量化 scale
[ ] 3. 补齐非权重大头：非量化张量、元数据、对齐、workspace
[ ] 4. 估算 KV cache：最大并发 × 最大上下文 × 每 token 每层 KV 字节数
[ ] 5. 汇总并加 15% 安全余量，得到显存下限
[ ] 6. 核对互联带宽：all-to-all 是否能被高带宽域承载
[ ] 7. 压测实际吞吐：以 tokens/s 而非理论 FLOPs 作为验收指标
[ ] 8. 对比自建与租用的三年 TCO，结合利用率做决策

八、结语

万亿参数 MoE 模型的本地部署，本质是一道显存、带宽、成本的三元约束题。显存决定了硬件下限，带宽决定了实际可用算力，而成本取决于利用率。把权重按总参数算、把量化 scale 算进去、把 KV cache 当大头看、把 all-to-all 通信当第一瓶颈对待——这四点做到了，估算就不会出现数量级的偏差。至于”要花多少钱”，答案不是一个固定数字，而是一条随精度要求、并发规模和部署形态变化的曲线；先算清显存，再谈钱，顺序不能反。