本地部署万亿级MoE大模型：硬件门槛与成本拆解

一、先纠正一个常见误判

很多开发者在考虑本地部署大规模语言模型时，第一反应是“买几张高端显卡是不是就够了”。这个判断对于数十亿或数百亿参数的模型可能成立，但对于万亿级稀疏专家模型，结论完全不同。

本文以一类典型的万亿参数稀疏模型为分析对象：总参数约 2.8 万亿，每个 Token 实际激活约 1040 亿参数。即便如此，推理时仍必须加载全部权重，而不是只加载激活部分。

这就带来第一个核心约束：权重容量需求远超单机显卡能提供的范围。

二、权重容量到底有多大

该模型原生采用 4 位浮点格式存储权重。这不是训练后强行量化，而是模型设计时就采用的精度，因此 4 位权重属于官方精度，不是近似方案。

按照总参数 2.8 万亿、每参数 4 bit 计算：

2.8 万亿 × 4 bit ÷ 8 = 1.4 TB

也就是说，仅模型权重就需要约 1.4 TB 存储空间。

实际推理时，除了权重，还要考虑：

• 激活值
• 运行时开销
• KV 缓存或状态空间
• 通信缓冲区

对一个单用户请求而言，显存总需求大约会上升到 1.5 TB。这个数字是整个后续分析的基础。

三、“能跑”的最低硬件形态

既然需要约 1.5 TB 显存，单张显卡显然无法满足。常见的高端数据中心显卡单卡显存一般在 80 GB 到 192 GB 之间，因此必须多卡并行。

从容量角度粗略估算：

需要显存总量 ÷ 单卡显存容量 = 最少卡数

但这里有一个容易被忽略的问题：某些上一代或当前代显卡不能原生执行这种 4 位浮点格式。它们需要在运行时进行反量化，把权重临时转换为更高精度再计算。

这意味着什么？意味着虽然从容量上“能装进去”，但实际推理效率会明显下降。模型也许能加载成功，但生成速度可能慢到不具备实用价值。

更现实的最低配置，往往是新一代原生支持低精度计算的数据中心显卡，例如 8 卡并行组成单节点。这不是某个云厂商的推荐，而是业界主流推理框架在进行同类万亿模型部署时普遍采用的方案。

所以结论是：“能跑”本身就已经是服务器级项目，而不是普通工作站或单台高性能主机能完成的事。

四、单用户流畅体验需要什么

如果我们把目标从“能出字”提升到“单人使用达到每秒 25 Token 左右”，硬件门槛并没有下降，起点仍然是 8 卡新一代数据中心 GPU 节点。

原因很直接：这首先不是一个算力问题，而是一个容量问题。1.4 TB 的权重必须全部驻留显存，无法因为只有一个人用就缩减到两张或三张卡。

那 8 卡是否一定能稳定达到每秒 25 Token？

这取决于多个变量：

• 输入上下文长度
• 输出长度
• 是否开启长文本状态缓存
• 通信拓扑与卡间带宽
• 推理框架的调度实现

在没有公开实测数据的情况下，不能直接给出“保证达到”的结论。但从单路大模型推理的常见性能区间来看，每秒数十 Token 是一个合理目标。上线前必须按照真实上下文长度进行压测，不能只看理论值。

五、多并发场景：显存与吞吐要分开看

假设目标是 10 个并发用户，每个用户都希望获得每秒 25 Token 的体验，那么聚合输出速率要求是：

10 × 25 Token/s = 250 Token/s

这里有一个关键判断：并发提升不一定需要增加显存。

为什么？因为一个 8 卡节点在显存容量上，往往可以同时驻留多个推理请求。具体能驻留多少，取决于每个请求的上下文长度。如果上下文不是百万 Token 级别，理论上单节点可以同时处理的请求数可能远超 10 个。

因此，10 并发并不会直接迫使你增加第二台服务器。真正的问题在于：当 10 路请求同时生成时，系统能否保证每一路都稳定维持目标速率。

这是吞吐能力和调度性能问题，不是显存容量问题。影响它的因素包括：

• 批处理策略
• Token 级调度粒度
• 显存带宽利用率
• 算子融合程度
• 通信与计算的重叠效率

这些都必须通过实际压测获得，不能仅凭显存容量推算。

六、成本估算：只看云上时租

由于该级别的硬件属于数据中心专用，个人几乎无法直接购买。实际可行的方式是通过云平台按小时租用。

以某云平台公开的 GPU 实例价格为例，一款新一代数据中心 GPU 的 12 个月预留价格约为：

4.76 美元 / GPU / 小时

8 卡节点就是：

4.76 × 8 = 38.08 美元 / 小时

这个价格只是裸 GPU 实例费用，不包括：

• 存储
• 网络出口
• 镜像与快照
• 技术支持
• 带宽费用

如果按长租或包年模式，折算下来单节点年度成本会达到数十万美元量级。这也解释了为什么这类模型极少有团队选择完全自建本地环境，更多是采用云上按需租用或直接调用模型服务。

七、给开发者的实操建议

如果你的团队确实需要自建推理环境，建议按以下顺序推进：

1. 先确认精度与格式兼容性
   确认目标显卡是否原生支持模型权重格式。如果需要反量化，必须提前评估性能损耗。

2. 以容量为第一筛选条件
   先计算权重总量，再反推卡数与单卡显存。算力再强，装不下权重就没有意义。

3. 区分“加载成功”与“可用性能”
   能加载不等于能服务。必须定义清晰的服务等级，例如 P50、P95 延迟，再做压测。

4. 并发场景单独做吞吐测试
   显存够不代表吞吐够。多路并发下的 Token 调度效率，必须用真实负载验证。

5. 预算只按云上时租做基线
   在决定自建之前，先以云上 8 卡节点的时租价格作为决策基准，再考虑是否有长期成本优势。

八、结论

万亿级稀疏大模型的本地部署，本质上已经从“选显卡”变成了“规划服务器节点”。权重容量是最先出现的硬约束，其次是格式兼容性，最后才是算力与吞吐。

如果只是验证可行性，最低也需要一个 8 卡数据中心节点；如果追求单人流畅体验，硬件起点相同，但必须进行严格的性能压测；如果扩展到多并发，重点会从显存容量转移到调度与吞吐调优。

在动手之前，建议先用云上时租价格建立成本认知。只有把容量、性能、并发和预算四个维度放在同一张表中评估，才能避免“买回来跑不动”的常见陷阱。