2026年10月22日

我们如何在 Cerebras 上部署万亿参数前沿模型Sarah Chieng

我们最常被问到的问题之一，就是如何在 Cerebras 晶圆级芯片上部署大型模型。单片 Cerebras WSE-3T 晶圆拥有 44 GB 片上内存，而万亿参数前沿模型 仅权重就需要数 TB 的存储空间。

在本文中，我们将解释如何把一个大型前沿模型拆分到多片 WSE-3T 晶圆上，从而以每秒 1000-2000+ tokens 的速度运行数万亿参数的模型。

我们将以开源模型 Kimi K3（约 3 万亿参数）作为示例进行说明。

读到最后，你将了解：

  • 我们如何将完整模型装入片上内存
  • 我们如何将模型映射到多片芯片上
  • 我们如何处理大量并发请求

以 Kimi K3 为例拆解

Kimi K3 是一个开源的 3T 参数模型，包含 69 个线性注意力层和 24 个稠密层。

它在 Terminal-Bench 2.1 上取得了 令人印象深刻的 88.3% （对比 GPT-5.6 Sol 的 88.8%），在 BrowseComp 上取得 91.2%（对比 GPT-5.6 Sol 的 90.4%）。这些结果表明其具备前沿水平的编程与智能体能力，在某些基准测试上甚至超越了领先的专有模型。 在此处了解更多关于 Kimi K3 的信息.

在本示例中，我们采用：

#1：每一层的大小

为了计算支持 Kimi K3 所需的 Cerebras WSE-3T 晶圆总数，我们先计算每个模型层的大小。

Kimi K3 拥有 3 万亿参数。如果全部 3T 参数均以 4 位存储，则原始参数负载为：

将该负载除以 93 层，得到：

#2：晶圆数量

现在我们已知每层约需 16 GB，就可以算出每片 44 GB 晶圆能容纳多少层。答案取决于层的类型：

  • 稠密层需要额外空间用于 KV 缓存，因为每个稠密（全注意力）层都要为每个活跃请求中的每个 token 存储键和值。因此，我们每片晶圆放置一个稠密层，并将剩余的 SRAM 留给其 KV 缓存。
  • 线性注意力层不需要额外空间用于 KV 缓存。线性注意力层不为每个 token 存储键和值，而是为每个请求维护一个小的、固定大小的状态，与上下文长度无关。这样每片晶圆就有空间容纳两个线性层（2 × 16 GB = 32 GB）。

因此，基于 Kimi K3 的 69 个线性层和 24 个稠密层，我们得到：

由此得到晶圆总数为 35 + 24 = 59 片晶圆。

#3：将晶圆连接起来

Cerebras 以流水线方式执行模型。在 Cerebras 编译器将模型层映射到各晶圆区域之后，运行时便会规划 token 在晶圆之间流动的路径。为实现超低延迟，晶圆之间只需传递激活值，这可以通过基于以太网的 RDMA 完成。每跳大约 2 微秒。

需要强调的是，由于每片 Cerebras 晶圆拥有 44 GB 片上 SRAM，而每层仅需 16 GB，我们通常能够将模型的完整层直接放在芯片上。

这意味着在大多数情况下，模型权重永远无需移动，层也不需要跨晶圆拆分。 只有激活值会从一片晶圆传到下一片。

#4：我们如何服务 1 个请求

现在晶圆已经连接在一起、模型也已布局完毕，我们可以把每片晶圆看作流水线上的一道工序：每道工序的模型权重保持不动，而请求的中间结果则依次流经各层工序。

例如，晶圆 1 运行模型第 1–2 层，并将激活值发送给晶圆 2。晶圆 2 运行第 3–4 层，并将结果传给晶圆 3，依此类推，直到最后一片晶圆生成下一个 token。

#5：我们如何服务大量请求

这引出了一个常见的误解。如果一个 token 必须依次经过每片晶圆，那么每片晶圆在等待轮到自己时岂不是处于空闲状态？实际上，系统岂不是以批大小为 1 在运行？

并非如此！如果我们一次只沿流水线发送一个请求，并等它完成后再开始下一个请求，那将是对流水线的低效利用。相反，我们让整条流水线始终充满不同的请求。由于模型已经拆分为多个流水线阶段，每个阶段都可以同时处理 不同的请求。

当阶段 3 为请求 A 处理一个 token 时，阶段 2 正在为请求 B 处理一个，阶段 1 正在为请求 C 处理一个。在我们的示例中，每个阶段是一层。在生产环境中，Cerebras 使用粒度细得多的阶段，且数量也多得多。

Video thumbnail正在加载播放器...

每个阶段还可以处理一个 微批次，即一小组请求，而不是单个请求。因此，在途请求数大致等于阶段数乘以微批次大小。

Video thumbnail正在加载播放器...

要理解其中的权衡：较小的微批次能让每个请求更快，而较大的微批次则能提高总吞吐量。

#6：我们 能 服务多少请求？

分配给 KV 缓存的片上内存量决定了最大并发请求数。每个在途请求都需要在每片稠密层晶圆上拥有自己的 KV 缓存，因此片上内存的大小设定了并发请求的上限。如上所述，我们只需计算稠密层的 KV 缓存需求。

对于每片已放置一个稠密层的 44 GB 晶圆，我们可以这样计算 KV 缓存的剩余空间：

晶圆总存储 - 一个稠密层的大小。在本例中：

计算并发请求数

要得出任意特定模型映射所支持的并发请求数，我们首先计算单个 256k 请求占用多少缓存：

然后，要计算该配置支持的总并发请求数，我们进行除法：

总并发请求数代表在任意时刻流经流水线的同时请求数量。与 GPU 批处理不同，这些请求不会相互等待完成，而是持续流经流水线。

当然，无论是并发数还是批大小，都不能确切告诉你一个推理系统的运行效率有多高。在评估推理系统的吞吐量时，更有意义的指标是在相同的输出生成速度下，每单位功耗的总 token 吞吐量（例如每秒每兆瓦的 token 数）。

如何扩展到 3T 参数以上

同样的方法也适用于更大的模型：计算权重和请求状态所需的内存，将模型分布到多片晶圆上，并将它们连接成一条流水线。每增加一片晶圆，都会贡献算力和片上内存，使我们能够容纳超出任何单芯片容量的模型。

感谢您与我们一同学习！有兴趣在 Cerebras 上部署模型，或使用我们的推理云进行构建吗？

设计：Halley Chang。感谢 Atharva Talpade、Zhenwei Gao、Angela Yueng、Jessica Liu、Joyce er、Emma Call 和 Rohan 的审阅与反馈。