Cerebras 59 片晶圆部署 3 万亿参数模型解析

Cerebras 在官方博客中给出了一套把超大模型放上晶圆的完整拆解：以约 3 万亿参数的开源模型 Kimi K3 为例，通过按层切分、把权重固定在片上、只让激活值在晶圆之间流动，并用流水线方式同时处理多个请求，从而实现多晶圆协同推理。对开发者和运维来说，这篇文章的价值不在于某个具体吞吐数字，而在于它展示了一种与大显存 GPU 集群明显不同的工程思路：把“内存墙”问题转化为“切分和流水线”问题。

以下内容中，来源事实与编辑分析会明确区分。来源未给出的参数（如具体功耗、成本、SLA 和稳定性数据）不会臆造。

背景：为什么万亿参数模型需要被拆开

来源指出，单片 Cerebras WSE-3T 晶圆拥有 44 GB 片上内存，而万亿参数前沿模型仅权重就需要数 TB 空间。也就是说，单芯片在容量上无法容纳完整模型，必须跨多片晶圆部署。

Cerebras 选择的不是把单个层切到多片晶圆上，而是尽量让一整层完整落在单片晶圆内：按来源描述，Kimi K3 每个层在 4 位权重量化下约 16 GB，小于 44 GB 的片上容量，因此大部分情况下权重可以“常驻不动”，跨晶圆只传递激活值。这一点是其方案成立的关键前提。

核心变化：按层类型分配晶圆与并发上限

来源给出的拆解逻辑可以概括为三步：先算单层大小，再按层类型决定每片晶圆放几层，最后把晶圆串成流水线。

第一，层大小。 3 万亿参数按 4 位存储，再除以 93 层（69 个线性注意力层 + 24 个稠密层），得到每层约 16 GB。

第二，晶圆数量。 稠密层需要为每个活跃请求保存 KV cache，因此每片晶圆只放一层稠密层，剩余 SRAM 留给 KV cache；线性注意力层只需为每个请求维护固定大小状态，与上下文长度无关，因此每片晶圆可放两层（约 32 GB）。据此，69 个线性层需要约 35 片，24 个稠密层需要 24 片，合计 59 片晶圆。

第三，连接与执行。 编译器把层映射到不同晶圆区域，运行时用 RDMA over Ethernet 在晶圆间传递激活值，来源称每次跳转约 2 微秒。每个晶圆相当于流水线中的一个阶段，前一片算完把激活值交给下一片，直到最后一个阶段产出下一个 token。

并发方面。 来源强调这不是“批大小为 1”的串行系统：流水线中同时填入不同请求，每个阶段可处理不同请求的一个 token，也可以处理一个微批次。片上分配给 KV cache 的空间决定最大并发请求数：每片稠密层晶圆在放入一层后，剩余约 28 GB 用于 KV cache；按 256k 平均请求长度和 8 位 KV cache 估算，可支撑一定数量的并发请求。来源没有在正文中给出最终的并发数字，因此这里不代为推算。

影响分析：这套思路改变了什么

从编辑视角看，这套方案的意义主要体现在三个方面。

一是把内存容量问题转成拓扑问题。 传统 GPU 方案通常依赖张量并行、流水线并行和显存分层，权重和 KV cache 都要挤在有限的 HBM 里；Cerebras 的做法是让权重尽量“钉”在片上，跨芯片只走激活值，从而减少权重搬运带来的带宽压力。这对延迟敏感型推理尤其有吸引力。

二是并发模型不同于 GPU 批处理。 来源明确说，流水线中的请求不需要彼此等待完成，而是持续流过各阶段。运维人员需要理解：这里的“并发”更接近流水线在制品数量，而不是静态 batch。评估容量时，不能简单套用 GPU 的 batch size 思维。

三是评估指标被重新定义。 来源建议用“相同输出速度下每兆瓦 token 吞吐”来衡量推理系统效率，而不是只看并发数或 batch size。这个观点值得重视，因为它把能耗纳入了单位经济性，但来源未提供该指标的实测数值，读者不应把博客中的描述直接当作采购依据。

需要冷静看待的是：来源提到 Kimi K3 在 Terminal-Bench 2.1 和 BrowseComp 上的分数，并与 GPT-5.6 Sol 对比，但这些是模型能力评测，不等于部署方案的性能证明；来源也注明性能对比基于第三方基准或内部测试，实际推理加速会因工作负载、配置、日期和测试模型而异。

行动建议：开发者与运维可以做什么

对应用开发者： 如果考虑使用此类推理服务，应先用真实业务请求分布验证平均上下文长度假设。来源以 256k 作为平均请求大小做示例，这个假设对并发上限影响很大；实际业务如果长上下文占比高，KV cache 压力会显著上升。建议在接入前明确量化方式、上下文上限和并发配额，并要求服务方给出与你负载匹配的延迟分布，而不是只看峰值 token 速率。

对运维与平台团队： 把这类系统纳入容量规划时，至少关注四项：每请求的 KV cache 占用、稠密层晶圆数量对并发上限的约束、流水线阶段间的网络时延稳定性，以及故障时的降级策略。来源只描述了正常路径，未说明单晶圆故障、网络抖动或长尾请求对流水线的影响，这些需要在 PoC 中专项压测。

对架构决策者： 不要仅凭“1000–2000+ tokens/s”这类宣传性区间做选型。来源未给出该区间的测试条件、模型配置和请求分布，建议要求供应商提供同输出速度下的能效数据、SLA 条款和可复现的基准方法，并在自己的负载上做 A/B 对比。

通用建议： 把“权重常驻、激活流动”作为一种架构模式来理解，即使不使用 Cerebras 硬件，也有助于思考分布式推理中的权重放置、缓存分区和流水线填充问题。但任何跨平台迁移都不能假设收益可平移，必须以实测为准。

资料来源

How we deploy Trillion-parameter frontier models on Cerebras

本文由自动化系统筛选公开技术信息，并经 AI 辅助整理。