Cerebras 部署万亿参数 AI 模型：59 晶圆流水线如何运行 3T 参数模型

Cerebras 发布了一篇逐步说明，解释其如何跨多个 WSE-3T 晶圆级芯片部署万亿参数前沿模型，并以约 3 万亿参数的开源模型 Kimi K3 作为实例。该部署方案构建了一个 59 晶圆流水线，使所有模型权重常驻于片上 SRAM，据 Cerebras 称，该方案能以每秒 1000-2000+ tokens 的速度运行多万亿参数模型。

Hacker News 上对该帖的讨论（292 分，100 条评论）更多聚焦于 Cerebras 未量化的权衡，而非流水线机制本身：量化与基准测试的对比、每 token 的功耗、59 晶圆流水线的故障域，以及预填充流量如何与解码共享同一互连。

核心约束：万亿参数模型需要 TB 级存储，而单晶圆仅有 44 GB

单个 Cerebras WSE-3T 晶圆提供 44 GB 的片上内存。万亿参数前沿模型仅权重就需要 TB 级存储，因此单个晶圆无法容纳。Cerebras 的解决方案是将模型拆分到多个晶圆上，并将其连接成流水线，使每个晶圆永久持有模型的一部分权重于片上 SRAM，而非从片外内存流式加载权重。

实例：Kimi K3，3 万亿参数，93 层

Kimi K3 是一个约 3 万亿参数的开源模型，由 69 个线性注意力层和 24 个密集（全注意力）层组成，共 93 层。Cerebras 的示例配置假设了三点：

• 平均请求大小为 256k tokens。
• 4 位权重量化，与 Hugging Face 实现中引用的方案一致。
• 8 位 KV 缓存。

步骤 1：每个模型层在 4 位权重下约为 16 GB

以 4 位存储 3 万亿参数，原始权重负载约为 1.5 TB。将该负载分配到 93 层，每层约 16 GB。

每层的大小决定了设计中的其他所有参数，因为它必须适配于晶圆的 44 GB SRAM 内。

步骤 2：模型映射到 59 个晶圆

单个晶圆上能容纳的层数取决于层类型，原因在于 KV 缓存：

• 密集（全注意力）层需要额外的空间用于 KV 缓存，因为每个密集层为每个活动请求中的每个 token 存储键和值。因此，Cerebras 将每个密集层放置在一个晶圆上，并将剩余 SRAM 用于该层的 KV 缓存。
• 线性注意力层不需要额外的 KV 缓存空间。线性注意力层不存储每个 token 的键和值，而是为每个请求保留一个小的固定大小状态，与上下文长度无关。这为每个晶圆容纳两个线性层留出了空间（2 x 16 GB = 32 GB）。

将该打包规则应用于 Kimi K3 的组成：

• 69 个线性注意力层，每晶圆 2 层 = 35 个晶圆（从 34.5 向上取整）。
• 24 个密集层，每晶圆 1 层 = 24 个晶圆。
• 总计 = 59 个晶圆。

步骤 3：晶圆通过 RDMA over Ethernet 连接，每跳约 2 微秒

Cerebras 以流水线方式执行模型。Cerebras 编译器将模型层映射到晶圆区域，运行时则映射 token 在晶圆间流动的路径。为降低延迟，晶圆间仅传递激活值，传输通过 RDMA over Ethernet 完成，每跳约 2 微秒。

使这一设计成本低廉的关键在于：每个晶圆拥有 44 GB 的片上 SRAM，而每层仅需约 16 GB。因此，Cerebras 表示整个层可以直接放在芯片上，模型权重无需移动，层也无需跨晶圆拆分。只有激活值在晶圆间传递。

步骤 4：服务单个请求类似于流水线作业

模型分布在相连的晶圆上后，每个晶圆充当流水线中的一个阶段。阶段的权重保持不变，而请求的中间结果在各阶段间流动。

具体示例中：晶圆 1 运行模型第 1-2 层，并将激活值发送给晶圆 2；晶圆 2 运行第 3-4 层，并将结果传递给晶圆 3；依此类推，直到最后一个晶圆产生下一个 token。Cerebras 指出，在生产环境中，它使用的阶段粒度更细，数量也远多于示例中每层一阶段的示意。

步骤 5：大量并发请求保持流水线满载，因此并非批大小为 1

Cerebras 明确回应了一个常见误解：如果 token 必须按顺序经过每个晶圆，那么每个晶圆是否会闲置等待，实际上以批大小 1 运行？答案是否定的。如果一次只发送一个请求，流水线将无法高效利用。相反，Cerebras 让整个流水线同时处理不同请求，由于模型已拆分为流水线阶段，每个阶段可以同时处理不同的请求。

当阶段 3 处理请求 A 的 token 时，阶段 2 可以处理请求 B 的 token，阶段 1 可以处理请求 C 的 token。每个阶段还可以处理一个微批次，即一小批请求，而非单个请求。在途请求数大致等于阶段数乘以微批次大小。

权衡随之而来：较小的微批次使单个请求更快，而较大的微批次提高总吞吐量。

步骤 6：并发请求数受密集层晶圆上的 KV 缓存内存限制

每个在途请求在每个密集层晶圆上都需要自己的 KV 缓存，因此片上内存决定了并发请求数的上限。由于线性注意力层每个请求仅保留固定大小的状态，因此只有密集层影响此计算。

对于每个已容纳一个密集层的 44 GB 晶圆，剩余 KV 缓存空间为总晶圆存储减去一个密集层的大小：

44 GB - 16 GB = 28 GB

Cerebras 随后计算单个 256k token 请求在 8 位精度下消耗的 KV 缓存量，并将 28 GB 的可用 SRAM 除以每个请求的占用空间，得出此映射下的最大并发请求数。在 Hacker News 讨论中，一位评论者将该结果解读为 190 个并发请求。

Cerebras 还提醒，并发性和批大小并非决定效率的关键指标。该公司认为，衡量推理吞吐量更有意义的指标是单位功耗的总 token 吞吐量，例如每兆瓦每秒的 token 数，并在相同的输出生成速度下测量。

扩展到 3 万亿参数以上使用相同方案

该方法可扩展到更大的模型：计算权重和请求状态所需的内存，将模型分布到晶圆上，并将晶圆连接成流水线。每个额外的晶圆既提供计算能力，也提供片上内存，这正是设计能够容纳超出任何单个芯片容量的模型的方式。

Cerebras 部署描述中的关键数字

数量	值
每个 WSE-3T 晶圆的片上 SRAM	44 GB
示例模型	Kimi K3，约 3 万亿参数，开源
层组成	69 个线性注意力层，24 个密集层（共 93 层）
4 位量化下的原始权重负载	约 1.5 TB
每层权重内存	约 16 GB
线性注意力层晶圆数	35（每晶圆 2 层）
密集层晶圆数	24（每晶圆 1 层）
总晶圆数	59
每个密集层晶圆上留给 KV 缓存的 SRAM	28 GB
晶圆间每跳延迟	约 2 微秒，RDMA over Ethernet
声称的生成速度	多万亿参数模型每秒 1000-2000+ tokens

Hacker News 对 Cerebras 帖子的质疑

全精度基准与 4 位量化的对比

部署示例基于 4 位权重量化，评论者指出了量化部署与宣传模型质量之间的差距。

引用全精度基准，然后直接使用 4 位量化

一位评论者描述了自己使用 Cerebras 实际提供模型的体验：“Cerebras 在纸面上很好，但我能合理访问的只有‘GPT OSS 120b、Qwen 3.8 27B’，这些对我的用途来说不够好。Openrouter 上的 nitro 能达到我的要求。虽然 TPS 慢了 5 倍。我试过 Cerebras 上的 GPT OSS 120b，速度飞快，但大部分是错的。”同一讨论中还有对公司定位和开发者关系的更直接评价，另一位评论者说：“哈哈，这些家伙之前提到过另一个愚蠢的量化方案。大多数模型至少从他们的网关来看更蠢了。”

“不同于 GPU 批处理”的说法未作解释

Cerebras 将其流式请求与 GPU 批处理进行对比，称其流水线中的请求“无需等待彼此完成”并“连续流经流水线”。一位评论者质疑了这一说法：

他们说的“不同于 GPU 批处理”是什么意思？这不是 GPU 的硬件限制吧？只是目前没有软件框架来实现这一点

该帖未明确这种区别是硬件特性还是软件和调度差异。

故障域：59 晶圆流水线没有明显的降级方式

讨论中最实质性的工程异议涉及可用性。在 GPU 上，跨多个节点的模型可以失去一个节点并降级运行。而在 Cerebras 上，模型实际上就是整个机架。

我想知道 59 晶圆流水线在故障域方面的代价。GPU 部署可以失去一个节点并降级；但在这里，模型就是机架，所以一个坏晶圆会导致整个系统宕机，而且必须端到端存活的流水线无法进行滚动升级。如何排空一个晶圆？

Cerebras 的帖子未涉及冗余、晶圆更换或实时多晶圆流水线的版本升级。

预填充流量在同一互连上的情况未涉及

2 微秒 RDMA 跳数被描述为激活值的晶圆间成本。一位评论者指出，该帖仅隐式涵盖了解码：

我相信解码部分，但文章没有提到他们如何在该互连上实现快速预填充 :/

KV 缓存能否放在更便宜的片外 DRAM 中？

一位评论者提议将 KV 缓存推送到更便宜的片外存储（如 DRAM），认为如果推理引擎先完成一个用户的解码再开始另一个，从 DRAM 获取 KV 缓存到 SRAM 的延迟将受到限制。另一位提出了操作上的推论：每个新请求的 KV 缓存必须从支持存储服务器加载，而该服务器本身需要大量 RAM 来容纳许多请求的活动缓存。

每 token 能耗（评论者估算）

利用帖子中的 59 晶圆配置，一位评论者给出了功耗估算：

按每个 WSE-3T 晶圆平均功耗 20 kW 计算，整个系统约为 1.18 MW。假设每秒 1500 tokens 和 190 个并发请求，则每 token 4.1 焦耳。对于这个规模的模型来说，我认为还不错？

按字面解读这些数字，59 个晶圆每个 20 kW 为 1.18 MW，1.18 MW 除以约 285,000 个聚合 tokens/秒（190 个并发请求，每个每秒生成 1500 tokens）约为每 token 4.1 焦耳。这些是评论者的假设，而非 Cerebras 发布的数据；帖子本身仅说明每兆瓦每秒 token 数（在相同输出生成速度下测量）是公平的比较基础。

每晶圆 44 GB 让一些读者觉得偏低

晶圆看起来很大。我惊讶它只有 44 GB 可用内存。这难道不有点……低吗？我不是硬件专家，但我会假设晶圆上能容纳更多内存？

Cerebras 的帖子未解释 44 GB 数字背后的 SRAM 密度权衡。

芯片拓扑及核心为何平铺为方形

晶圆级架构引发了一个更长的硬件问题，即数据如何实际流经芯片的二维处理元素（核心）网格，以及为何方形平铺占主导：

他们展示层从左到右由 PE 流式传输，但我想知道实际情况是否如此：也许通过对角线或其他具有更好数据流拓扑的形状更容易流式传输。[...] 对于 Cerebras 这样的流式架构，为什么不考虑其他类型的平铺，比如六边形网格？

该帖未讨论晶圆的物理布局、路由几何或时钟约束，因此该问题在讨论中未得到解答。

访问能力仍落后于宣传的能力

几位评论者（包括尝试过该服务的付费用户）报告了 1000-2000+ tokens/秒的声称与实际可运行内容之间的差距：

本周我尝试了 Cerebras 用于我的项目，他们的 27b 模型在 2000 tks 下会很完美。不幸的是，它达不到我想要的每秒 2k tokens。

其他人则要求帖子未提供的内容：更人性化的比较，而非基准数字。“我很投入，因为我认为这个硬件本质上……很酷。但有没有人做过更人性化的比较（不仅仅是基于基准）？有些因素让我选择 ChatGPT 而不是 Anthropic 订阅。并非全是绝对能力。”一位评论者用一句话总结了公司的处境：“Cerebras 是 AI 浪潮中的 Transmeta。”

需求侧：人们需要低延迟，而不仅仅是能力

讨论中反复出现的主题是，对于许多工作流，模型能力不再是瓶颈。“Opus 5.5 已经足够聪明，我们需要的是速度，”一位评论者写道，同时指出代理工作流还花费时间在测试和构建上，硬件速度无法解决。另一位将极端推理速度视为质的差异：“如果他们投入 100 倍的努力，在 10% 的时间内完成，或者想象 1% 的情况下工具调用时间成为瓶颈，那实际上可能会感觉像一种特别神奇的‘超级智能’。”

结论

Cerebras 的部署方法是一种静态、权重固定的流水线：4 位权重将每个模型层固定于片上 SRAM，59 个晶圆容纳 3 万亿参数模型，晶圆间仅通过 RDMA Ethernet 传递激活值，每跳约 2 微秒，并发性受限于每个密集层晶圆上留给 KV 缓存的 28 GB SRAM。已发布的说明是尺寸规划和映射的演练，而非基准报告，Hacker News 讨论中未解决的问题正是帖子未量化的部分：量化质量、晶圆间互连上的预填充行为、每 token 功耗，以及当单个晶圆故障时 59 晶圆流水线会发生什么。