Cerebras Deploys Trillion-Parameter AI Models

Cerebras 如何部署万亿参数 AI 模型

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 是一个开源的 3 万亿参数模型，包含 69 个线性注意力层和 24 个密集层。

在 Terminal-Bench 2.1 测试中，Kimi K3 以 88.3% 的成绩表现（对比 GPT-5.6 Sol 的 88.8%），在 BrowseComp 测试中以 91.2% 的成绩表现（对比 GPT-5.6 Sol 的 90.4%）。这些结果展示了前沿级别的编码能力和智能体能力，甚至在某些基准测试中超越了领先的专有模型。[了解更多关于 Kimi K3 的信息](#)

为便于说明，我们假设以下条件：

• 平均请求大小为 256k
• 使用 4 位权重量化（类似 Hugging Face 实现）
• 使用 8 位 KV 缓存

#1：每层的大小

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

Kimi K3 拥有 3 万亿参数。如果每个参数都以 4 位存储，原始参数负载为：

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

#2：晶圆数量

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

• 密集层需要额外空间存储 KV 缓存，因为每个密集层（全注意力层）需要为每个请求中每个 token 存储键和值。因此，每个晶圆仅放置一个密集层，并将剩余 SRAM 用于其 KV 缓存。
• 线性注意力层不需要额外空间存储 KV 缓存。线性注意力层为每个请求保留一个小型固定状态，与上下文长度无关。这使得每个晶圆可以容纳两个线性层（2 × 16 GB = 32 GB）。

$!

/$

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

这使我们总共需要 35 + 24 = 59 个晶圆。

#3：连接晶圆

Cerebras 以流水线方式执行模型。在 Cerebras 编译器将模型层映射到晶圆区域后，运行时会为 tokens 在晶圆间流动的路径进行映射。为了实现超低延迟，仅需在晶圆间传递激活值，这可以通过以太网上的 RDMA 实现，每跳延迟约为 2 微秒。

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

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

#4：如何处理单个请求

现在我们已经将晶圆连接在一起并完成模型布局，可以将每个晶圆视为流水线中的一个阶段：每个阶段的模型权重保持不变，而请求的中间结果会通过各层阶段传递。

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

#5: 我们如何服务多个请求

这引发了一个常见的误解。如果一个token必须按顺序通过每个晶圆，那么每个晶圆在等待轮到自己时不会处于空闲状态吗？从效果上看，系统难道不会以批量大小为1运行吗？

不是！如果我们一次只发送一个请求到流水线中，并在它完成后再开始下一个请求，这将是一种低效的流水线使用方式。相反，我们会用不同的请求始终保持整个流水线满载。由于模型已经被划分为流水线阶段，每个阶段可以同时处理不同的请求。

当阶段3为请求A处理一个token时，阶段2可以为请求B处理一个token，阶段1则为请求C处理。在我们的示例中，每个阶段对应一个层。在实际生产中，Cerebras使用更细粒度的阶段划分，并包含更多阶段。

加载播放器...

每个阶段还可以处理一个微批次（micro-batch），即一组小规模的请求，而不是单个请求。因此，正在处理的请求数量大致等于阶段数乘以微批次大小。

要理解这种权衡，较小的微批次会使每个请求更快，而较大的微批次会提高总吞吐量。

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

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

对于每个已有1个密集层的44GB晶圆，我们可以通过以下方式计算剩余的KV缓存空间：

总晶圆存储空间 - 一个密集层的大小。在这种情况下：

计算并发请求数量

要确定任何特定模型映射支持的并发请求数量，我们首先计算单个256k请求需要多少缓存：

然后，通过以下方式计算该配置支持的总并发请求数量：

总并发请求数量表示在任何时间点通过流水线的并发请求数量。与GPU批量处理不同，这些请求不会等待彼此完成，而是持续流经流水线。

当然，无论是并发性还是批量大小都无法准确说明推理系统的效率。在评估推理系统的吞吐量时，更有意义的指标是单位功率的总token吞吐量（例如每秒每兆瓦的token数），在相同输出生成速度下进行测量。

如何扩展到超过3万亿参数的模型

同样的方法可以扩展到更大的模型：计算权重和请求状态所需的内存，将模型分布在多个晶圆上，并将它们连接成流水线。每个额外的晶圆都会提供计算能力和片上内存，使我们能够处理超出任何单个芯片容量的模型。

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

• 通过我们的免费 API 入门：cloud.cerebras.ai
• 联系我们的销售团队：[email protected]

设计由 Halley Chang 完成。感谢 Atharva Talpade、Zhenwei Gao、Angela Yeung、Jessica Liu、Joyce Er、Emma Call 和 Rohan Gupta 的审阅与反馈。