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

简要版本

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

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

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

解读型号名称

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

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

您实际租用的显存

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

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

激活参数能换来什么

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

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

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

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

变便宜的那一半

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

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

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

哪些服务器能容纳它们

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

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

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

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

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

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

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

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

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

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