我们通常收到的一个问题是，如何在 Cerebras 硅片级芯片上部署大型模型。单个 Cerebras WSE-3T 硅片有 44 GB 的片上内存，而万亿参数的前沿模型仅其权重就需要几个 TB。在这篇文章中，我们将解释如何将大型前沿模型拆分到多个 WSE-3T 硅片上，以每秒处理 1000-2000+ 个 tokens 的速度运行多万亿参数模型。我们将使用开放源代码模型 Kimi K3（约 3 万亿参数）作为示例。到最后，您将了解：如何将完整模型放入片上内存；如何将模型映射到多个芯片；如何处理高并发请求。 分解 Kimi K3 Kimi K3 是一个开放源代码的 3T 参数模型，具有 69 个线性注意力层和 24 个密集层。对于这个示例，我们使用：256k 的假定平均请求大小；4 位权重量化（类似于 Hugging Face 的实现）；8 位 KV 缓存。 #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 在硅片之间流动的路径。为了实现超快延迟，仅需要在硅片之间传递激活，这可以通过 Ethernet 的 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 使用更细粒度的阶段，并且更多。 每个阶段也可以处理一个微批量，即一小组请求，而不是单个请求。因此，在飞行中的请求数大约是阶段数乘以微批量大小。 要理解这个权衡，较小的微批量使每个请求更快，而较大的微批量则提高总吞吐量。 #6: 我们可以处理多少个请求？分配给 KV 缓存的片上内存量决定了最大并发请求数。每个在飞行中的请求在每个密集层的硅片上都需要自己的 KV 缓存，因此片上内存的大小设定了并发请求的上限。如上所述，我们只需要计算密集层的 KV 缓存需求。