每年芯片领域的 Hot Chips 会议一开基本就能看出接下来两三年高性能计算的走向。2026 年这届Cerebras 又把“晶圆级 AI”这个赛道拉回了聚光灯下。很多人第一次听到“wafer-scale AI”会觉得陌生简单说就是把整张晶圆做成一颗超级芯片而不是切成几百颗小芯片再去拼。这个思路听起来很直接但真正落地非常难。本文就以 Hot Chips 2026 上 Cerebras 展示的技术方向为线索把晶圆级 AI 芯片的原理、架构、软件栈、对比优势、工程挑战和后续趋势完整拆解一遍。不管你是做 GPU 集群训练的算法工程师还是做推理服务的基础架构开发或者只是对 AI 芯片感兴趣的开发者这篇文章都能帮你建立一张比较清晰的知识地图。1. 关于 Hot Chips 与 Cerebras1.1 Hot Chips 是什么级别的会议Hot Chips 是高性能芯片领域的老牌会议每年由 IEEE 和 ACM 相关组织承办地点基本都在斯坦福大学附近。它和很多学术会议不一样特点是“厂商讲自家真实芯片”而且讲得非常工程化架构图、内存层级、互联拓扑、功耗数字、实测性能都会放出来。所以业内经常把 Hot Chips 看作“芯片行业的技术风向标”。在这里能看到的不只是论文概念而是已经流片甚至已经商用的系统。Cerebras 已经是 Hot Chips 的常客从第一代 Wafer Scale Engine晶圆级引擎开始几乎每一代都会在这个会议上更新设计细节和用户案例。1.2 为什么 Cerebras 值得单独关注Cerebras 做的是非常“激进”的事情不把晶圆切成 die而是把整块晶圆做成一个完整的计算芯片。这意味着单个芯片的面积可以达到传统 GPU 芯片的几十倍片上存储和核间带宽也随之大幅提升。对大模型训练来说大模型最需要的三样东西是算力、显存、带宽。GPU 集群的方案是用高速网络把很多芯片连起来而 Cerebras 的思路则是用“单芯片”把所有计算资源集中在一起。在 Hot Chips 2026 上Cerebras 对外展示的内容主要围绕未来晶圆级 AI 的迭代方向展开包括如何继续扩大单芯片规模、如何解决多系统互联、如何在语言模型之外覆盖更多 AI 工作负载。这些方向对了解 AI 基础设施的演进非常有参考价值。2. 背景GPU 集群时代的算力瓶颈在哪里2.1 大模型训练面临的三个核心矛盾现在训练一个大语言模型主流方案还是搭建大规模 GPU 集群。这种方式能跑通但代价很高。我们把这层窗户纸捅破可以看到三个很明显的矛盾。第一个矛盾是内存墙。GPU 的单卡显存是有限的但模型的参数量增长非常快。模型参数、梯度、优化器状态都要塞进显存超过单卡容量就要做模型并行、流水线并行把这些数据拆分到多张卡上。拆分之后每一层计算完都要通过互联把结果传给下一张卡通信就成了瓶颈。第二个矛盾是通信墙。GPU 集群的规模越大通信拓扑越复杂。AllReduce、AllGather 这类集合通信操作会随着卡数的增加产生巨大的流量。即便用上了 NVLink、InfiniBand网络延迟和带宽仍然比不上芯片内部的互联。第三个矛盾是能耗墙。大模型训练集群的功耗非常高数据中心要做大量散热和电力配套。从算力利用率的角度看真正花在矩阵乘法上的时间占比远没有想象中那么高。业界经常提到的“算力利用率”下降原因就出在数据搬运和通信等待上。2.2 回到“单芯片”思路的意义既然多芯片互联有这么多开销那能不能把芯片做得足够大让计算和存储都放在同一片硅片上这就是晶圆级芯片的基本动机。Cerebras 的思路是通过特殊设计把一整片晶圆上的计算核心通过片上网络连接起来形成一个超大规模的单芯片系统。这样核心之间的通信不再走外部网络而是走片上互联。片上互联的带宽通常比外部网络高好几个数量级延迟也低很多。对需要频繁同步梯度的大模型训练来说这种结构天然有优势。3. 核心概念什么是晶圆级 AI 芯片3.1 从“切晶圆”到“不切晶圆”传统芯片制造的流程是在一片圆形晶圆上做出几十上百个 die然后切割、封装、测试。晶圆级芯片的做法是不切。整片晶圆直接作为一块完整的计算芯片使用上面排布大量计算核心、片上存储和互联网络。当然“不切”这件事说起来容易做起来有一堆工程难题。晶圆上任何一点制造缺陷如果放在传统方案里最多报废一个 die但在晶圆级方案里可能影响整片芯片。Cerebras 的设计里加入了大量的冗余和容错机制比如每个计算核心周围都有备用互联路径核心本身也可以动态屏蔽故障单元。另一个关键设计是供电和散热。传统芯片功率已经很高晶圆级芯片的面积是传统 GPU 的几十倍功率密度和散热方案完全不是同一个量级。Cerebras 使用了一种特殊的供电方式从晶圆背面直接注入电源同时配合水冷系统让这块“巨无霸”芯片保持可工作的温度。3.2 晶圆级引擎的三个关键设计目标我们可以把晶圆级 AI 芯片的设计目标归纳成三点。第一最大化片上存储带宽。大模型训练的很多算子比如 LayerNorm、Attention都需要频繁读写中间结果。片上存储离计算核心越近、带宽越高计算效率就越高。第二最小化跨核心通信开销。虽然晶圆级芯片不需要外部网络但片上通信仍然有距离远近的问题。Cerebras 的二维网格互联结构可以让数据在相邻核心之间快速传递减少跨长距离传输的频率。第三提升单芯片计算密度。单位面积上排列的计算核心越多整片晶圆提供的总算力就越高。这里考验的是核心设计、布局布线、功耗控制等多方面能力。3.3 与多芯片封装Chiplet的区别这里容易混淆的是 Chiplet 和晶圆级芯片的区别。Chiplet 是“把不同功能的裸片封装在一起”比如一个 CPU 计算 die 加一个 IO die通过先进封装互联。这种方案本质上还是多颗芯片只是封装得更紧密。晶圆级芯片则是“整片晶圆作为一个计算单元”没有封装和切割过程所有核心都原生在一块硅片上。两者的核心区别在于单芯片一致性和互联层级不同。Chiplet 仍旧要处理 die 之间的封装互联晶圆级芯片走的是片上网络不存在物理封装导致的引脚瓶颈。4. Cerebras 的架构与硬件设计思路4.1 从单片晶圆到完整系统只看裸芯片并不是全部真正用于训练的是一整套系统。Cerebras 的落地形态是 CS 系列系统把晶圆级引擎、供电、散热、服务器管理都整合到一台标准机柜尺寸的设备里。这种“单芯片系统”的部署方式很有意思。传统 GPU 集群要买很多台服务器组网、布线、运维都很麻烦晶圆级系统更像是一个超大号的“单卡训练机”软件层面可以直接把它当成一张拥有海量存储和算力的“超级加速卡”来使用。对很多研究团队和企业来说这大幅降低了并行编程的复杂度至少从概念上不再需要关心分布式通信细节。4.2 核心计算单元设计以公开资料来看Cerebras 的晶圆级引擎由大量同构核心组成每个核心都是为稀疏计算和神经网络算子优化的处理单元。每个核心内部有专用存储和可编程控制逻辑支持灵活的算子调度。它不是简单的 GPU 式大规模并行架构更像是“芯片上的集群”——成千上万个计算核心在片上网络上协同工作。这种架构的优点是数据流非常“局部化”。如果一个算子的输入数据已经在核心自带的存储里计算就完全不需要访问外部内存。4.3 存储与带宽真正的王牌如果要给晶圆级 AI 找一个最有说服力的卖点那就是存储带宽。GPU 的显存带宽虽然高但显存和计算核心之间的物理距离、封装限制都决定了带宽是有上限的。而晶圆级芯片把存储直接集成在计算核心旁边数据路径大大缩短。对大模型训练来说高带宽带来的直接收益是Attention 计算时Q、K、V 矩阵的读取速度更快。优化器状态的更新不需要频繁跨节点通信。模型并行时可以更容易地把数据放在靠近计算的位置。这也是 Cerebras 在多个公开测试中能以较少硬件完成大模型训练的关键原因之一。5. 软件栈与编程模型真正的护城河5.1 硬件之外编译器决定成败很多人以为 Cerebras 的难点全在硬件其实软件栈才是真正的门槛。一块再强的芯片如果开发者没办法方便地写程序就很难规模化落地。Cerebras 的软件栈重点做了一件事让开发者继续用 PyTorch 写模型不需要手动把模型拆到几千个核心上。这一步是“编译器”完成的。它会分析你的模型结构把算子映射到晶圆级引擎的具体核心上自动安排数据流和存储分配。对开发者来说看到的仍然是一个熟悉的深度学习框架接口。5.2 从 PyTorch 模型到晶圆级引擎的映射逻辑从原理上说映射逻辑可以拆成三步。首先是计算图分析。读取 PyTorch 模型把神经网络结构转换成中间表示识别出哪些层是计算密集型、哪些层是存储密集型。然后是资源分配。把不同的层分配到不同的核心区域尽量让数据在核心之间流动时路径最短减少跨核心通信。最后是调度优化。生成可执行指令决定每个核心在每一个时钟周期执行什么操作。这个流程听起来和 GPU 编译类似但尺度完全不同。GPU 是同一指令多数据流的模式而晶圆级引擎的每个核心都可以有更独立的控制逻辑调度空间更大编译器的优化空间也更复杂。5.3 一个简化理解用的开发流程示例下面的代码不是 Cerebras 官方 API 的完整用法而是用来说明“从模型到晶圆级芯片”的思维变化方向。# 示意代码展示从模型定义到晶圆级引擎执行的简化流程 # 实际开发请参考 Cerebras 官方文档与对应版本 SDK import torch import torch.nn as nn # Step 1: 用一个普通 PyTorch 定义模型 class TinyGPT(nn.Module): def __init__(self, vocab_size512, dim128, num_heads4): super().__init__() self.embedding nn.Embedding(vocab_size, dim) self.attention nn.MultiheadAttention(dim, num_heads, batch_firstTrue) self.linear nn.Linear(dim, vocab_size) def forward(self, x): x self.embedding(x) attn_out, _ self.attention(x, x, x) return self.linear(attn_out) model TinyGPT() # Step 2: 编译映射 # 这里的 compile 只是示意实际会打通到晶圆级引擎核心 compiled_model compile_for_wafer_scale(model) # Step 3: 执行训练 # 输入形状示意实际数据形状取决于模型配置 fake_input torch.randint(0, 512, (2, 64)) output compiled_model(fake_input) print(output.shape)这段代码的核心想表达的是用户侧的模型定义仍然可以是 PyTorch 风格晶圆级芯片的适配发生在编译层而不是让开发者重写整个深度学习框架。在实际使用中你需要根据 Cerebras 官方 SDK 的接口来替换上面的compile_for_wafer_scale函数。不同版本的 SDK 对 PyTorch 版本和模型算子支持程度不同务必以官方文档为准。5.4 分布式训练习惯的变化如果用 GPU 集群训练大模型你大概率写过 torchrun、DeepSpeed、Megatron-LM 这些工具。你要考虑张量并行、流水线并行、数据并行怎么组合要考虑通信拓扑怎么优化。晶圆级引擎的编程模型把这一层做了很大的简化。因为所有核心都在同一片芯片上数据并行带来的通信是在片上完成的不需要走外部网络。传统的“分布式训练工程师”角色在晶圆级方案中会更偏向“编译器性能优化工程师”。当然这不意味着完全不需要考虑并行策略只是处理层级从“跨节点”变成了“片上资源分配”工具链和思维方式都不一样。6. Cerebras 与 GPU 集群、TPU 的对比6.1 三种技术路线的取舍当前 AI 计算基础设施有三条明显路线。GPU 集群路线最成熟灵活度最高生态最强。从训练到推理、从大模型到多模态几乎所有框架都优先支持 GPU。缺点是通信成本高、部署运维复杂。TPU 路线是 Google 的自研芯片与自家框架深度绑定在 Google Cloud 上使用比较方便但外部开发者上手门槛较高。晶圆级路线是以 Cerebras 为代表的激进创新特点是单芯片规模巨大、片上带宽极高、并行编程简化但目前生态规模相对小适配的算子和模型需要逐步完善。6.2 对比表格维度传统 GPU 集群TPU 集群晶圆级 AI 芯片单芯片面积中等中等极大接近整片晶圆扩展方式高速网络互联多卡定制互联多卡单芯片内扩展 系统级互联通信瓶颈外部网络通信开销大相对可控片上通信优势明显软件生态最丰富相对封闭增长中以 PyTorch 为主部署形态多机多卡云端集群整机系统最主要优势生态成熟自研协同优化单芯片算力与带宽密度高最主要挑战通信和功耗平台绑定生态和成熟度仍需积累从表格里可以看出晶圆级 AI 芯片不是要替代所有 GPU 场景而是在“大模型训练 高带宽需求 并行通信瓶颈显著”的场景里提供一个新的选择。7. 晶圆级方案的挑战与限制7.1 良率与成本制造业的硬约束晶圆级芯片最直接的难点是良率。传统芯片制造中一小块缺陷可以报废一小颗 die。但晶圆级芯片如果出现大范围缺陷影响面会非常大。Cerebras 的应对思路是设计冗余和容错比如核心级的坏点隔离、网络路径的绕过机制。但这套容错设计本身就会消耗芯片面积和功耗。良率带来的成本压力也决定了晶圆级芯片不可能像 GPU 那样大规模铺开更偏向高价值的高性能计算场景。7.2 散热与功耗墙一块接近整片晶圆大小的芯片功率会相当可观。传统的风冷方案根本压不住必须使用更高精度的液冷或浸没式冷却。这意味着数据中心的硬件设施也需要跟着升级。如果一个客户没有液冷条件就算想部署晶圆级系统机房条件也不一定允许。功耗墙还影响性能扩展芯片面积变大功耗增长通常不是线性的。如何在功耗预算内最大化计算性能是所有大芯片设计都要面对的现实问题。7.3 软件生态与模型泛化早期的晶圆级芯片可能只适合某种特定模型结构但随着软件开发迭代现在已经能支持多种主流模型。不过和 CUDA 生态相比仍然有差距。算子覆盖度就是一个现实问题。PyTorch 里有大量算子不同版本还在不断新增。晶圆级编译器不可能在第一时间支持所有算子遇到不支持的算子时开发者要么改模型实现要么等 SDK 更新。从工程角度看一个大语言模型通常包含几十种算子Custom Op 和动态 shape 的处理是晶圆级软件栈需要重点优化的方向。8. Hot Chips 2026 释放的未来信号8.1 多系统互联从单芯片走向多芯片晶圆级芯片性能再强单系统总归有限。Hot Chips 2026 上比较明确的一个方向是多系统互联也就是把多台晶圆级系统通过高速网络组合起来支持更大的模型训练。这其实是一个很有意思的转变。之前 Cerebras 强调“单芯片解决通信问题”但当模型规模继续增长单一系统不够时仍然要回到多系统互联。只是互联层级更高、粒度更粗通信量比 GPU 集群内部要小得多。对开发者来说未来可能需要重新熟悉“多机并行”但在更高层次上做切分比如跨系统时只同步梯度系统内部仍然保持片上通信。8.2 推理市场与内存带宽优势除了训练Cerebras 也在把晶圆级方案推向推理场景。大模型推理最大的瓶颈往往不是算力而是显存带宽。推理时每个 token 都要读取完整的模型权重权重读取速度直接影响首 token 延迟和吞吐。如果晶圆级芯片的片上存储足够大可以把整个模型参数放进芯片自带存储里推理时不需要频繁访问外部 DRAM理论上可以显著提升推理吞吐、降低延迟。这也是 Hot Chips 2026 上讨论推理优化方案的重要原因。8.3 编程标准和中间表示的博弈另一个值得关注的趋势是 AI 芯片编程标准正在形成。过去各家芯片都有各自的编译器开发者被绑定在某一个硬件平台上。现在行业里出现了多种中间表示层比如 MLIR、Triton 等。Cerebras 如果能在软件栈上靠拢这些开放标准就能降低开发者的迁移成本。对开发者来说多学一种硬件平台不再那么痛苦。因为如果上层抽象足够通用换芯片只是换一个编译后端的问题。9. 作为开发者接下来可以做什么9.1 不急着换框架但要理解编译思维即使你现在用的是 NVIDIA GPU也不影响你学习晶圆级 AI 芯片背后的设计思想。很多高性能计算问题本质上不是“算子不够快”而是“数据搬运太慢”。晶圆级方案的思路是尽量把数据放在计算旁边。这个思路对你优化 GPU 代码、设计推理服务也有启发优先减少 H2D 拷贝、优先复用 Kernel 输出、优先利用共享内存。9.2 值得关注的技术信号如果你希望跟进晶圆级 AI 和 Cerebras 的进展可以关注几个方向的信息Cerebras 官方博客和 GitHub 仓库了解 SDK 更新和模型支持列表。Hot Chips 会议历年的论文和幻灯片里面有大量架构细节。MLIR 和 Triton 这类编译器项目的进展因为编译器生态会影响晶圆级芯片能否被更多开发者使用。大模型推理框架对“内存带宽”和“权重加载”优化方向的讨论这与晶圆级方案强相关。9.3 学习路线建议如果要从零开始补这块知识建议分几步走。第一步理解计算机体系结构尤其是内存层级和互联网络。晶圆级芯片的一切优势都建立在“数据离计算更近”这个原则上。第二步了解深度学习编译原理从 PyTorch 的 eager 模式到 TorchScript、Triton、MLIR 的演进明白为什么需要编译器。第三步阅读大模型并行训练的相关资料理解 GPU 集群在通信上面临的实际瓶颈再对比晶圆级方案你就能建立起相对完整的判断框架。10. 结语Cerebras 在 Hot Chips 2026 上展示的晶圆级 AI 路线本质上是在追问一个问题当模型规模持续膨胀、当多卡互联成为瓶颈我们能不能把芯片做得足够大让计算和存储的物理距离无限接近这个问题的答案是“确实可以但代价很高”。良率、散热、软件生态都是现实约束。但从另一个角度看晶圆级方案对通信瓶颈的颠覆性思考已经给整个 AI 基础设施行业提供了一条不同于 GPU 集群的路径。对于普通开发者现在不一定需要立刻切换到晶圆级平台但理解它的架构思想和软件栈设计可以帮你更好地把握 AI 计算底层的变化趋势。如果本文对你有帮助可以收藏备用后续再继续更新编译器与并行计算方面的实战笔记。