本地部署万亿级MoE模型：显存账、速度账与成本账

一、先明确讨论边界

本文讨论的对象是一个总参数达到万亿量级、采用MoE（混合专家）架构的大模型本地化部署问题。截至相关权重与技术报告正式发布前，所有关于显存占用、吞吐速度、硬件配置的数字都属于基于公开架构信息的工程估算，而非实测结论。权重放出后，需要用基准测试逐项核验。这一前提非常重要，因为万亿级MoE的部署成本对量化格式、并行策略、互联带宽极其敏感，任何一项假设变动都会显著改变结论。

为避免空谈，下面按三个需求层次展开：

1. 只要能跑就行，不关心速度；
2. 单人使用，输出速度达到 25 tokens/s；
3. 10 并发，单人输出速度仍保持 25 tokens/s 以上，且量化等级不低于 4-bit。

三个层次对应三套完全不同的硬件预算，差距可能达到数倍。

二、万亿参数对显存意味着什么

2.1 MoE 的显存账按总参数算

一个总参数 2.8 万亿的 MoE 模型，假设包含 896 个专家，每个 token 激活其中 16 个，专家激活比例约 1.79%。这里必须区分两个概念：

• 专家激活比例：路由选中的专家数占总专家数的比例；
• 参数激活比例：实际参与计算的参数量占总参数量的比例。

二者并不等价。工程上最关键的一条规则是：MoE 部署的显存占用按总参数计算，激活比例只影响算力消耗，不减少存储需求。推理时全部专家都必须常驻可寻址的存储中，路由命中后再调出对应专家参与计算。换句话说，你不能只装 1.79% 的权重，那 896 个专家一个都不能少。

2.2 4-bit 量化的真实下限

该模型从 SFT 阶段就引入了量化感知训练，权重采用 4-bit 浮点格式、激活采用 8-bit 浮点格式。粗算一下：2.8 万亿参数转 4-bit，裸数据约 1400GB。但 4-bit 浮点格式并非纯 4 bit——按 OCP 规范，每 32 个 4-bit 元素附带一个 8-bit 的 scale（缩放因子），等效位宽为：

2.8e12 × 4.25 bit ÷ 8 ≈ 1487.5 GB

这还只是权重本身。实际部署还要叠加：

• 非 4-bit 张量（嵌入层、归一化层、部分注意力组件等）；
• 张量元数据与对齐填充；
• 运行时工作区（activation buffer、临时张量）；
• KV cache（随并发数与上下文长度线性增长）。

因此满血 4-bit 部署的实际显存需求大概率在 1.6TB 以上，而非 1400GB。作为参照，一个 671B 级别的 MoE 模型在 FP8 下主参数加多 token 预测参数约 685GB，4-bit 量化后权重约 335GB、激活约 37GB，合计约 400GB 才能在 8 张 80GB 加速卡（640GB）上跑起来。万亿级模型的体量是它的四倍以上，满血部署的显存下限由此决定。

2.3 为什么官方建议超节点

大规模 MoE 推理对 all-to-all 通信带宽极度敏感。896 个专家分布在多张卡上，每个 token 路由后都要把激活值搬到目标专家所在卡，算完再搬回。这个往返延迟会直接吃掉算力利用率。超节点的价值在于用高速互联（如 NVLink 或同等机制）把通信域做大，让专家搬运不出单个高带宽域，从而把通信开销压到可接受范围。这是万亿级 MoE 部署与普通稠密模型部署最本质的区别之一。

三、三个层次的硬件与成本估算

以下估算以 80GB 显存级别加速卡为基本单位，价格为市场区间示意，具体以实际采购渠道为准。

层次一：能跑就行，不关心速度

目标是最低成本让模型完成一次前向推理。可行路径是更激进的量化（如 2-bit 级别）加 CPU/GPU 混合卸载，把部分专家放在主机内存甚至 NVMe 上，按需换入。

• 显存需求：2-bit 量化下权重约 700～800GB，配合卸载可将常驻显存压到 8～16 张卡；
• 主机内存：建议 1.5～2TB 以上，用于存放卸载权重；
• 存储：NVMe 阵列 4TB 以上，权重加载与换页都依赖它；
• 成本区间：整机（含 8 卡 + 大内存 + 高速盘）大致在数十万元级别，若采用二手或租赁方案可进一步下探。

这一层次的现实预期是：单次生成可能要几十秒到几分钟，吞吐极低，只适合验证、演示或离线批处理，不具备交互价值。

层次二：单人 25 tokens/s

25 tokens/s 是流畅阅读的体验门槛，也是单人交互的合理目标。这个层次需要模型权重全部常驻显存，避免换页带来的抖动。

• 显存需求：4-bit 量化下约 1.6～1.8TB（含工作区与 KV cache），即 20～24 张 80GB 加速卡；
• 互联要求：卡间需要高速互联，至少保证专家并行的 all-to-all 不成为瓶颈；若跨节点，需要高带宽 RDMA 网络；
• 算力要求：万亿级 MoE 单 token 激活参数约数百亿量级，单卡算力足以支撑 25 tokens/s，瓶颈主要在显存容量与通信；
• 成本区间：8 卡整机按每台百万元级估算，3 台规模即数百万元级别；若采用按需租用，单价按卡时计，适合短期验证。

需要注意的是，25 tokens/s 是解码阶段速度，首 token 延迟（prefill）取决于输入长度，长上下文场景下 prefill 可能成为新的瓶颈，需要单独评估。

层次三：10 并发，每人 25 tokens/s

这是生产级要求，也是最贵的一档。10 并发意味着：

• KV cache 放大：按每并发上下文 8K～32K 估算，KV cache 从几十 GB 膨胀到数百 GB，且随上下文长度线性增长；
• 算力放大：总吞吐需达到 250 tokens/s，若单卡算力利用率 30%～50%，所需算力卡数量显著上升；
• 显存需求：4-bit 权重 1.6TB + KV cache 数百 GB + 工作区，建议 32～48 张 80GB 加速卡，并预留 20% 余量；
• 互联要求：必须使用超节点级高速互联，专家并行与张量并行混合切分，通信域尽量收敛在单节点内；
• 成本区间：整机集群千万元级别；若按云上按需实例估算，每小时成本与卡数成正比，长期运行需做容量规划与弹性伸缩。

一个实用的折中方案是：对并发做请求排队与动态 batching，把 10 并发的峰值摊平，用更少的卡配合更长的单请求等待时间换取成本下降——但这会牺牲部分用户体验，需要产品侧权衡。

四、成本之外容易被忽略的三笔账

第一笔是电与散热。 数十张高功耗加速卡连续运行，机柜功率密度很容易突破风冷上限，需要液冷或更高规格机房。这部分基础设施成本常被低估。

第二笔是运维复杂度。 专家并行的切分策略、路由负载均衡、故障卡摘除、权重版本管理，都需要专门的推理框架调优能力。人力成本往往超过硬件折旧。

第三笔是量化精度损失。 4-bit 量化在多数任务上表现可接受，但对数值敏感任务（如代码生成中的长链推理）可能出现质量下降。上线前必须做任务级评测，不能只看 perplexity。

五、落地建议

1. 先租后买：权重发布前用按需实例做基准测试，拿到真实的显存占用与吞吐曲线，再决定采购规模；
2. 按层次选型：验证阶段走层次一，交互演示走层次二，生产服务走层次三，不要一步到位；
3. 优先保证互联：万亿级 MoE 的瓶颈常常是通信而非算力，预算应向高速互联倾斜；
4. 预留 KV cache 空间：显存规划时把 KV cache 单独建模，按目标并发与上下文长度反推所需卡数；
5. 建立基准测试基线：权重发布后第一时间跑通三个层次的实测，用数据替换本文的估算值。

万亿级 MoE 的本地部署不是“买几张卡”的问题，而是显存容量、互联带宽、量化精度三者之间的系统工程权衡。把这三笔账算清楚，预算就不会失控。