选型 指南 · 阅读需 10 分钟

# 混合专家模型真正的代价。

像“235B-A22B”这样的名字包含两个数字，而几乎每个人都会看错该关注哪一个。其中一个决定您该租用什么，另一个决定它回答得有多快。两者之间可以相差 10 倍之多。

简短的答案

- **总参数决定服务器:** **DeepSeek V3 671B-A37B (MoE)** 采用 4-bit 精度、8k 上下文时需要 **386 GB**。若换成一个参数规模等于其*激活*参数的稠密模型，则只需要 22 GB — 少 **17.6×**。
- **激活参数决定速度:** 每个 token 只读取一小部分权重，所以它的生成速度比同等质量的稠密模型更快 — 但路由又把这项优势的很大一部分直接吃掉了。
- **能容纳它的最便宜节点:** [8 × NVIDIA A100 PCIe](https://gpuserver.io/zh/gpu/a100-80gb)，**$7,906**/月。这几乎从来都不是该租用的那一款。
- **值得租用的那一款:** [4 × NVIDIA B200 SXM6](https://gpuserver.io/zh/gpu/b200)，**$11,790** — 花 1.5× 的钱，换 2.8× 的吞吐量。

## 简要版本

混合专家模型把每一层的前馈网络拆分成许多小型网络，每个 token 只会经过其中少数几个。发布时的模型名称记录了两个事实：总参数，以及任意一个 token 会用到的激活参数数量。*第一个数字必须全部常驻显存，第二个数字则只按 token 读取。*这一句话就是本指南的全部内容，而把它理解反了，是我们在客户下单前见过代价最高的错误。

结果就是这类模型的成本形态很古怪：租用时按巨兽计价，运行时却像一个中等规模的模型。这究竟是划算还是陷阱，完全取决于这两个数字里，哪一个才是您的瓶颈。

**要为服务器选型？**用总参数。每一个专家都必须常驻显存，因为您无法提前知道下一个 token 会用到哪些专家。路由是按 token、在运行时决定的。

**想估算速度？**从激活参数量出发，然后大打折扣。生成阶段只读取激活权重，这正是关键所在——但路由、专家分发以及显卡之间的通信都不是免费的，而且在整个节点上扩展得很差。

**要面向长上下文或大量用户提供服务？**请看注意力设计，而不是参数量。本页面中参数量最大的模型，每个 token 的键/值缓存反而*最小*，超过某个长度之后，排名会被完全颠覆。

**只在乎质量？**一张显卡就能放得下的稠密模型，比拆分到 8 张显卡上的混合专家模型更容易操作、更便宜也更快。只有在没有任何稠密模型能给出您所需答案时，才选择 MoE，而不是因为这个名字听起来很厉害。

下面的运算，和[配置器](https://gpuserver.io/zh/configure)在同一份产品目录上运行的算法完全相同。如果您还没弄清楚一个模型到底需要多少显存，[应该先看那套公式](https://gpuserver.io/zh/guides/vram-sizing)——一旦模型变成了混合专家模型，本页面要讲的就是随之而来的变化。

## 解读型号名称

目前流通着三种命名法，它们编码的其实是同一对数字，这也是混淆始终存在的原因。一旦您能读懂这些名字，选型的问题就会迎刃而解。

235B-A22B 先总参数，后激活参数 三种命名法中最清晰的一种：2350 亿个参数常驻显存；对任意给定的 token，只会读取其中 220 亿个。字母 A 的意思是*激活*，而这个数字恰恰**不能**告诉您该租用什么。

671B-A37B 同一套命名规则，规模更大 在这个规模下，差距会被刻意拉到荒谬的程度：激活占比不到 6%。您需要什么样的服务器，跟这个 37 毫无关系。

8×22B 专家数量，再到专家规模 这是较旧的命名法，也是最容易误导人的一种。它既不代表 1760 亿参数，因为注意力层和嵌入层是共享的，而不是重复配置；也不代表 220 亿，因为每个 token 会激活两个专家，而不是一个。

A22B, A37B 是平均值，不是保证 激活参数量反映的是路由在典型文本上的开销，它并不是上限：如果某个批次的 token 恰好分散到很多专家上，会触及模型的更多部分，这正是实测吞吐量低于理论算术值的原因之一。

**我们选型目录中的混合专家模型，总参数与激活参数对比**

| 模型 | 总参数 | 每 token 激活参数 | 激活占比 |
|---|---|---|---|
| Mixtral 8×22B (MoE) 56 层 | 141 B | 39 B | 28 % |
| Qwen 3 235B-A22B (MoE) 94 层 | 235 B | 22 B | 9 % |
| DeepSeek V3 671B-A37B (MoE) 61 层 | 671 B | 37 B | 6 % |
| Llama 3.3 70B 稠密模型，作为对照 | 70 B | 70 B | 100 % |

最后一列才是需要记住的重点。稠密模型会读取它存储的一切；混合专家模型只读取其中一部分。这类模型身上所有古怪之处 — 好的和坏的 — 全都源于这一行。

## 您实际租用的显存

整个陷阱都体现在这一张表里。中间一列是模型在服务器上实际需要的数值；下一列则是如果读者只看激活参数数字、按字面意思去预算，会得到的结果。最后一列，就是为这种误读付出的账单。

**8k 上下文、4-bit 精度下实际需要的显存，与激活参数量所暗示的相比**

| 模型 | 4-bit 权重 | 所需显存总量 | 如果按它的激活规模计算 | 超支 |
|---|---|---|---|---|
| Mixtral 8×22B (MoE) | 71 GB | 83 GB 8k 时 | 24 GB | 3.4× |
| Qwen 3 235B-A22B (MoE) | 118 GB | 137 GB 8k 时 | 14 GB | 9.5× |
| DeepSeek V3 671B-A37B (MoE) | 336 GB | 386 GB 8k 时 | 22 GB | 17.6× |

把最后一列理解成一次选购失误。如果只按激活参数量来选型，会一开始去找一张单卡，结果却发现自己需要一整个节点 — 这不是稍微大一点的服务器，而是完全不同档次的服务器，价格也完全不同。

**不行，未使用的专家不能放在磁盘上。** 这是每个人都会想到的第一个念头，推理服务栈也确实提供这项功能。问题在于路由是按 token 决定的：每生成一个词，所需的专家集合就可能变化好几次，于是只保存了其中一部分专家的显卡，大部分时间都花在通过 PCIe 调入缺失的权重上，而不是真正计算。结果不是模型稍微变慢，而是速度只剩下原来的一小部分。卸载能让模型在放不下它的服务器上*跑起来*，却不能让它被真正*服务*好。

## 激活参数能换来什么

生成阶段受限于显存带宽：每生成一个新 token，都需要重新读取参与计算的那部分权重。混合专家模型只读取其中激活的那一部分，因此其速度上限由一个比模型体积小得多的数字决定。这部分承诺是真实的，也正是这类模型存在的意义所在。

下表把每一个模型都放在*同一台*服务器上 — [8 × NVIDIA A100 PCIe](https://gpuserver.io/zh/gpu/a100-80gb)，每月 $7,906，也就是我们产品目录中能同时容纳所有这些模型的最便宜节点。拿不同服务器上测得的吞吐量数字互相比较，等于什么都没比较。

**同一节点上的单流生成：混合专家模型对比稠密模型**

| 模型 | 总参数 | 每 token 读取量 | 预计 token/秒 |
|---|---|---|---|
| DeepSeek V3 671B-A37B (MoE) 混合专家模型 · 拆分到 8 张显卡 | 671 B | 18.5 GB | 37 单流 |
| Llama 3.1 405B 稠密模型 · 拆分到 8 张显卡 | 405 B | 202.5 GB | 19 单流 |
| Qwen 3 235B-A22B (MoE) 混合专家模型 · 拆分到 8 张显卡 | 235 B | 11.0 GB | 62 单流 |
| Mixtral 8×22B (MoE) 混合专家模型 · 拆分到 8 张显卡 | 141 B | 19.5 GB | 35 单流 |
| Llama 3.3 70B 稠密模型 · 单张显卡 | 70 B | 35.0 GB | 25 单流 |

最值得比较的两行，是规模最大的混合专家模型和规模最大的稠密模型，因为两者都被拆分到整个节点上。这个混合专家模型体量大得多，生成速度却依然更快，因为它每个 token 只读取自身的一小部分 — 这正是这种架构存在的意义所在。标注为*单卡*的那些行，含义有所不同：这些模型只占用节点中的一张显卡，其余 7 张仍然空闲，这是一台等着被选中的更便宜的服务器，而不是一台更慢的服务器。

**这些数字已经打了很大的折扣，而且理应如此。** 单纯按激活参数做算术，会严重高估混合专家模型的速度。我们这个估算器的第一版就是这么做的，结果相对于本页面最大模型的已发布实测数据，误差大约达到 5 倍。路由本身要占用一次单独的计算，专家还必须在每一层之间跨显卡交换激活值，而且批次实际涉及的专家数量，往往比平均值暗示的更多。现在这个估算器采用了一个刻意保守的修正系数，它是根据实测数据校准得出的，而不是随意选定的 — 这也是它读数偏低、而不是偏高的原因。请把这里的每一个数字都当作服务器要超越的下限，而不是用来规划的目标值。

这套运算掩盖的第二件事是：混合专家模型更难被妥善拆分。拆分到多张显卡上的稠密模型，每层只需同步一次；而混合专家模型还必须把 token 路由到持有对应专家的那张显卡，这是一种更难预测、模式也不同的通信。这是少数几种能让[互联的价格真正物有所值](https://gpuserver.io/zh/guides/nvlink-vs-pcie)、而不只是体现在账单上的工作负载之一。

## 变便宜的那一半

到目前为止，一切都是对大模型不利的消息。而这里有一项补偿，是任何对比都很少提及、却相当可观的一项：本页面参数量最多的模型，反而拥有每个 token *最小*的键/值缓存。缓存大小由注意力设计决定——层数、键/值注意力头数、头维度——这与注意力背后有多少专家无关。

**每个 token 的键/值缓存，以及在各个上下文长度下单流的开销**

| 模型 | 每 token 缓存 | 4k | 8k | 32k | 128k |
|---|---|---|---|---|---|
| Mixtral 8×22B (MoE) 8 个 KV 头 | 224 KiB | 0.9 GB | 1.8 GB | 7.0 GB | 28.0 GB |
| Qwen 3 235B-A22B (MoE) 4 个 KV 头 | 188 KiB | 0.7 GB | 1.5 GB | 5.9 GB | 23.5 GB |
| DeepSeek V3 671B-A37B (MoE) 潜在注意力 | 70 KiB | 0.3 GB | 0.5 GB | 2.2 GB | 8.8 GB |
| Llama 3.3 70B 8 个 KV 头 | 320 KiB | 1.3 GB | 2.5 GB | 10.0 GB | 40.0 GB |
| Llama 3.1 405B 8 个 KV 头 | 504 KiB | 2.0 GB | 3.9 GB | 15.8 GB | 63.0 GB |

这些列的数值都是按*单个并发请求*计算的。乘以同时使用该端点的人数之后，决定您该用哪台服务器的，将主要是最后一列的排名，而不是权重本身。

**DeepSeek V3 671B-A37B (MoE) 在列表中拥有最小的缓存，每个 token 仅 70 KiB。** 相比 Llama 3.3 70B（320 KiB），这是朝着更大模型方向的 **4.6×** 倍差距。它的做法是把键和值投影进一个共享的小型潜向量，而不是按注意力头分别存储，从而压缩缓存体积。于是，加载成本最高的模型，反而是运行成本最低的那个 — 这就是为什么它在长上下文下依然可用，也是为什么一旦同时服务的人数超过寥寥几个，整套运算就会反转。

实际的解读是：权重是固定的入场费，缓存才是运行成本。混合专家模型收取一笔巨大的入场费，之后每个用户的运行成本却很低；能力相当的稠密模型则正好相反。对您而言哪一种更划算，取决于并发数和上下文长度，而不是模型卡片上写的参数量。

## 哪些服务器能容纳它们

按 4-bit 精度、参考上下文长度计算，并选用我们产品目录中能容纳每个模型的最便宜节点 — 无论是单张显卡还是拆分到整个节点。这些只是入场门槛，并非推荐配置；原因见下一节。

**我们所出租配置中，能容纳每个混合专家模型的最便宜方案**

| 模型 | 所需显存 | 能容纳它的最便宜节点 | 每月 | token/秒 |
|---|---|---|---|---|
| Mixtral 8×22B (MoE) | 83 GB | [4 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) 共 96 GB · 每张显卡 24 GB | $564 | 4 |
| Qwen 3 235B-A22B (MoE) | 137 GB | [8 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) 共 192 GB · 每张显卡 24 GB | $1,106 | 10 |
| DeepSeek V3 671B-A37B (MoE) | 386 GB | [8 × NVIDIA A100 PCIe](https://gpuserver.io/zh/gpu/a100-80gb) 共 640 GB · 每张显卡 80 GB | $7,906 | 37 |

这些无一例外都是多卡节点，这就是本页面最诚实的结论：无论激活参数量把它们衬托得多小，我们产品目录中没有一款配置能在单张显卡上容纳这些模型。[完整产品目录](https://gpuserver.io/zh/#catalog)收录了其余配置，[配置器](https://gpuserver.io/zh/configure)则会针对您自己的模型和上下文运行同样的核算。

## 最便宜的节点，往往是错误的选择

放得下只是一个门槛，不是目标。一旦模型被拆分到某个节点上，吞吐量就取决于它所拆分到的那些显卡的显存带宽 — 而在所有同样跨过这道显存门槛的配置之间，单位价格对应的带宽可以相差两倍以上。下面是 DeepSeek V3 671B-A37B (MoE) 在每一个能容纳它的节点上的表现，按价格排序，唯一重要的那一列在最右边。

**能容纳 DeepSeek V3 671B-A37B (MoE) 的每一个节点，以及每 token/秒 对应的月租价格**

| 配置 | 显存 | 每月 | token/秒 | $/token/秒 |
|---|---|---|---|---|
| [8 × NVIDIA A100 PCIe](https://gpuserver.io/zh/gpu/a100-80gb) GN-A10080×8 | 640 GB | $7,906 | 37 | $213.68 |
| [8 × NVIDIA A100 SXM4](https://gpuserver.io/zh/gpu/a100-sxm4) GN-A100SXM×8 | 640 GB | $8,355 | 39 | $214.23 |
| [4 × NVIDIA H200 SXM5](https://gpuserver.io/zh/gpu/h200) GN-H200×4 | 564 GB | $8,405 | 62 | $135.56 |
| [8 × NVIDIA H100 PCIe](https://gpuserver.io/zh/gpu/h100-pcie) GN-H100PCIE×8 | 640 GB | $10,568 | 38 | $278.11 |
| [8 × NVIDIA H100 SXM5](https://gpuserver.io/zh/gpu/h100-sxm5) GN-H100SXM×8 | 640 GB | $11,509 | 64 | $179.83 |
| [4 × NVIDIA B200 SXM6](https://gpuserver.io/zh/gpu/b200) GN-B200×4 | 720 GB | $11,790 | 103 | $114.47 |
| [8 × NVIDIA H200 SXM5](https://gpuserver.io/zh/gpu/h200) GN-H200×8 | 1128 GB | $15,945 | 91 | $175.22 |
| [8 × NVIDIA B200 SXM6](https://gpuserver.io/zh/gpu/b200) GN-B200×8 | 1440 GB | $22,351 | 152 | $147.05 |

绿色单元格是列表中性价比最高的一行，却不是最便宜的一行。从 $7,906 换到 $11,790，账单会变成 1.5× 倍，吞吐量则变成 2.8× 倍 — 您付得更多，但每个 token 反而更便宜。按价格给产品目录排序、选第一台放得下的服务器，正是服务预算被多花一遍的方式。

关于这一列有一点提醒，它适用于您今后会读到的每一张单价/吞吐量表：这里用的是单流生成。在连续批处理下，每一行的总吞吐量都会成倍攀升，而且各行攀升的倍数并不相同 — 权重占用之外剩余显存越多的节点，能承载的并发序列也越多。排名是稳定的，绝对数值则偏保守。[这种总吞吐量背后的经济账](https://gpuserver.io/zh/guides/api-vs-self-hosting)另文详述。

## 混合专家模型什么时候才是正确答案

依次排列，找到第一条描述您情况的就停下。

1. **一张显卡就能放得下的稠密模型，已经够用了。**选它，不要回头。一张显卡意味着无需拆分、无需考虑互联问题、没有专家路由流量，而且服务器的价格只是一个节点的零头。大多数自认为需要前沿开源模型的产品，其实只需要一个出色的 32B 模型。
2. **您既需要质量，上下文又很长。**这正是混合专家模型真正称得上最佳选择的场景：权重只需付出一次，而较小的缓存意味着服务器能持续服务长对话而不崩溃。先按权重为节点选型，再对照缓存表核实您实际使用的上下文长度。
3. **您既需要质量，又要同时服务大量用户。**答案相同，理由也相同，而且这一优势会随并发数增长而增大。固定成本被摊薄到每一路请求上，而每路请求的成本则保持在低位。
4. **您需要这种质量，但只是偶尔需要。**那样您就是在租用一个大节点，只为了每周让它保持热机几个小时，这是对包月租期最糟糕的用法。要么把任务集中批量处理、一次性跑完，要么这一项改用托管端点，把自己的服务器留给稳定负载使用。
5. **您想微调一个这样的模型。**那是另一个问题，需要更大的服务器：训练会触及每一个专家，并且要为它们全部保存优化器状态，于是原本让推理捉襟见肘的显存占用，此时会变得高不可攀。对稠密模型做[适配器微调](https://gpuserver.io/zh/guides/lora-finetune)，对几乎所有人来说才是现实可行的路线。

无论您在哪一行停下，首先要核对的数字都是总参数量，按您打算使用的精度计算。本页面的其余内容 — 速度、缓存、每 token/秒 的价格 — 都只有在模型已经装进显存之后才有意义。[配置器](https://gpuserver.io/zh/configure)会针对我们出租的每一个节点运行完整核算，并且和上面几张表一样，对吞吐量估算施加相同的路由修正。如果您想先完整看一遍显存运算，[这有专门一篇指南](https://gpuserver.io/zh/guides/vram-sizing)；如果您还没定下数字格式，[这个选择要先于本文](https://gpuserver.io/zh/guides/awq-vs-gptq-vs-fp8)。

## 用真实服务器核对您自己的混合专家模型。

配置器收录了我们出租的每一个节点，套用与本页面相同的运算，在您支付任何费用之前，就能告诉您哪些节点能容纳您的模型。

[打开配置器](https://gpuserver.io/zh/configure) [阅读指南](https://gpuserver.io/zh/guides)

## 其他指南

- [成本 · 6 分钟 何时月付比按小时计费更划算 基于真实数字计算出的盈亏平衡点、按小时计价直到账单才会显现出的三项隐藏成本，以及让估算数字翻上三倍的闲置时间陷阱。 阅读指南](https://gpuserver.io/zh/guides/monthly-vs-hourly)
- [成本 · 9 分钟 自托管对比按 token 计费的 API 按 token 计费的 API 与租用 GPU 之间的盈亏平衡点，基于我们自己的价格与吞吐量计算得出——以及这套算法遗漏的四件事。 阅读指南](https://gpuserver.io/zh/guides/api-vs-self-hosting)
- [实践 · 11 分钟 在单个节点上部署 Llama 3.3 70B 从交付完成的服务器，到一个兼容 OpenAI 的推理端点：这中间有真正重要的启动参数，也有会悄悄把吞吐量拦腰砍半的那两个参数。 阅读指南](https://gpuserver.io/zh/guides/serve-llama-70b)

---

来源：https://gpuserver.io/zh/guides/mixture-of-experts/。本文件由与网站相同的数据生成；如果此处的数字与页面不一致，以页面为准，本文件视为过期——权威来源是 https://gpuserver.io/。