晶圆级芯片新突破：垂直集成DRAM如何破解AI内存墙

如果你对 AI 芯片的关注还停留在“谁的核心数更多、谁的内存更大”这个维度CS-6 的公开信息可能会让你重新划重点。Cerebras 这次给出的关键信号不是某个夸张的晶体管总量而是“3D 堆叠、首次垂直集成 DRAM”这十个字。也就是说晶圆级芯片这条路走到了一个新的十字路口它开始主动重构自己体内的存储结构而不是继续用更大面积去堆更多逻辑核心。这件事的真正含义需要从晶圆级芯片为什么存在、内存墙为什么是硬瓶颈、以及垂直集成 DRAM 到底改变了哪条数据路径来理解。只看参数你会觉得这又是一次常规升级把视角拉到工作流和工程落地你会发现它可能改变很多东西。1. 晶圆级芯片解决的不是“做大芯片”而是“少搬数据”1.1 大模型训练真正的瓶颈往往不在算力而在内存墙先说一个被反复提及但依然容易被忽视的背景深度学习训练的性能上限很多时候不是由每秒多少万亿次浮点运算决定的而是由“数据能不能及时送到计算单元里”决定的。逻辑上计算单元要计算权重、激活值、梯度第一步必须先把它们从存储中取出来。这个“取数”过程有两个开销来源一是物理距离数据离计算核心越远延迟越高能效越低二是搬运的规模当数据量达到几十 GB 甚至上百 GB搬运路径上的带宽就会成为最细的瓶颈。在传统的冯·诺依曼架构里存储和计算是分开的。CPU 或 GPU 不断从主存里读取指令和数据再把计算结果写回去。这种架构用了几十年大家都习惯了但当模型规模涨到千亿、万亿参数时内存访问的代价已经远超计算代价。业内常说“搬运一个数据所消耗的能量比计算它高几个数量级”这句话不一定精确到具体数字但指向了一个明确的方向只要数据搬运的距离和频率降不下来算力再强也会被拖住。所以在评估 AI 加速硬件时不能只看 FLOPS。更关键的问题其实是每个算力单元距离它需要的数据到底有多近。1.2 Cerebras 选择“整块晶圆”本质上是把通信搬到芯片内部GPU 集群的方案是生产足够多的 GPU再通过 NVLink、InfiniBand、以太网把几千张卡连接起来。问题在于每一次跨卡通信都要经过芯片边界、PCB 走线、连接器、线缆、交换机数据和带宽在这里大量消耗。集群规模越大通信开销在训练总时间里的占比越高。Cerebras 的思路和这种分布式路线完全不同。它没有把计算任务分给成千上万块小芯片而是让一整片 12 英寸晶圆成为一颗巨型芯片。这样做的直接效果是原本需要靠外部网络完成的通信现在变成了芯片内部同一片硅上的走线连接。处理器核心之间的物理距离从“单机柜内的多张卡”缩短成了同一个硅片内的毫米级路径。有人把这种选择理解为“把一个大模型塞进一块大芯片”这在思路上太窄。更准确地说它是把通信层次压缩了原来要走网络的数据现在走片上总线原来要跨机架的同步现在变成片内同步。整张晶圆本质上是一个超大规模的片上系统省掉的是大量的数据进出芯片的环节。这也是为什么晶圆级芯片在理论上适合千亿、万亿参数模型的训练。这些模型的参数总量惊人但对算力系统来说真正致命的是频繁的同步和数据交换。如果能把交换路径缩短训练效率自然会上一个台阶。1.3 但这套方案绝不是没有代价把整片晶圆做成一颗芯片意味着它和成熟的小芯片路线完全不同。制造上的第一个挑战就是缺陷率。一片 12 英寸晶圆那么大任何一粒尘埃、任何一次光刻偏差都可能造成局部坏点。如果整片晶圆只能做一颗芯片那坏点是不是会让整片报废这正是晶圆级芯片一直被人质疑的地方。工程上能接受的思路是预留大量冗余核心芯片内部具备坏点隔离能力出厂时把有缺陷的核心关掉用剩余的核心继续工作。它不是靠“一颗坏点都没有”来保证良率而是靠容忍局部缺陷来维持整片可用。这种设计在逻辑上说得通但意味着芯片内部要额外配备大量可配置的互联和隔离机制这本身会占用面积也会提高设计复杂度。另一个大挑战是散热。一整片晶圆的功率密度远高于普通处理器如果采用传统封装散热思路热量很难从硅片内部顺利传导出来。公开讨论中Cerebras 使用的方案涉及大面积水冷和特殊散热结构。也就是说这类系统通常不是“插在哪台服务器里就能用”的设备而是需要整体机柜级集成甚至要提供配套的散热和供电基础设施。软件栈的成本也不能忽略。GPU 生态的并行编程模型、通信库、训练框架已经非常成熟而晶圆级芯片从一开始就面临“现有并行代码无法直接迁移”的问题。它的编程模型需要重新设计例如把张量并行、流水线并行等策略映射到片内互联拓扑上。这种软件投入在早期很容易被低估但恰恰是决定一个硬件能不能被真正用起来的关键。因此判断晶圆级芯片是否有价值不能只看它单点算力有多强还要看它能不能在一个完整的大模型训练流程中站得住脚。CS-6 把注意力放到内存结构本质上就是在回答这个更工程化的问题。2. 从 SRAM 到 DRAM存储层级的设计思路变了2.1 芯片内部的 SRAM速度快但面积和成本都太奢侈在 AI 芯片内部最靠近计算核心的存储是 SRAM。它速度快、延迟极低可以被直接包在计算单元旁边形成片上缓存。对 AI 任务来说SRAM 承担的角色非常像“近身小仓库”权重、激活值、流水线中间结果凡是高频访问的数据都希望放得越近越好。但 SRAM 有一个致命短板面积开销极大。一个 SRAM 单元通常需要 6 个或 8 个晶体管来存储 1 bit 数据而 DRAM 单元只需要 1 个晶体管加 1 个电容。这意味着在同样的芯片面积上SRAM 的容量远低于 DRAM而且单位容量的成本高得多。这也是为什么 GPU 的片上 SRAM包括寄存器文件、共享内存和各级缓存总共也只有几十 MB 到上百 MB 级别。它速度快但不够大。当模型的权重、KV Cache 达到几十 GB 甚至上百 GB 时靠 SRAM 全部放在片上是完全不现实的。于是大多数加速器只能把大容量数据放在芯片外的 HBM 里再通过高带宽接口往片内搬运。问题就在这里HBM 和片上 SRAM 之间隔着封装、基板、总线数据传输路径很长。带宽虽然高但和计算核心的需求相比仍然是一个周期性瓶颈。2.2 为什么这次盯上 DRAM容量、成本和数据密度综合考虑如果芯片能把 DRAM 也放进来存储系统的结构就会发生质变。DRAM 的单位面积容量远高于 SRAM因为它本质上是利用电容的电荷状态来存储数据面积更小。在 3D 堆叠方案里DRAM 又可以垂直堆叠多层不需要和逻辑电路抢同一层硅。这样一来芯片就能在保留大量 SRAM 作为高速缓冲的同时额外获得一块容量可观的 DRAM 存储空间而且这块 DRAM 距离计算核心的距离远比 HBM 到核心的距离短。从技术演进的逻辑看Cerebras 在 CS-6 里首次垂直集成 DRAM很可能就是在延续“把权重和中间状态放得更靠近核心”的思路。过去晶圆级芯片把大部分权重放在外部存储中通过权重流式传输进入计算核心如果垂直集成的 DRAM 能把这部分数据装载到片内那么数据传输路径、访问延迟、整体功耗都可能进一步下降。我不是说 CS-6 会彻底取消外部存储而是说它的存储层级从“外部 DRAM 片上 SRAM”的两级形态变成了“片内垂直 DRAM 片内 SRAM 外部存储”的多级形态。这种变化让系统有机会动态选择数据放在哪一层。这里需要把话说清楚3D 堆叠本身不是新概念。HBM 本质上就是多层 DRAM 垂直堆叠后通过硅通孔TSV连接到逻辑芯片。但 CS-6 的关键词是“晶圆级”和“垂直集成”这意味着不是把一颗普通逻辑芯片和 DRAM 堆在一起而是把一整块晶圆大小的计算芯片和 DRAM 层直接堆叠。它的连接密度、对准精度、热管理难度都比 HBM 方案上一个数量级。2.3 垂直集成 DRAM 的制造难度不是简单堆叠而是把两个世界焊在一起制造层面垂直集成 DRAM 也不是简单地把 DRAM 裸片“粘”在逻辑芯片上。常见做法会涉及晶圆对晶圆键合、硅通孔、混合键合等工艺。这些技术在高端封装领域已经逐渐成熟但用到晶圆级尺度难度会急剧放大。首先是热膨胀问题。硅在高温下会膨胀DRAM 层和计算逻辑层的材料即使都是硅系材料在经历多个工艺步骤和长时间高负载运行后也会出现应力差异。如果两层之间的连接点太密或太稀疏热应力可能引发可靠性问题。其次是良率叠加问题。计算晶圆本身要处理缺陷DRAM 层同样可能带来缺陷两个层的良率会叠加。如果某一层出现关键缺陷可能导致整颗芯片无法使用这就迫使厂商在设计中做更多的冗余和容错设计。散热就更关键了。计算层在工作时会产生大量热量如果 DRAM 层紧贴在计算层上方或下方它也会处于一个高温热环境中。DRAM 对温度比 SRAM 更敏感过热会导致刷新率上升、访问延迟变大甚至数据保持时间缩短。所以在垂直集成方案里散热通道的设计几乎和逻辑设计本身一样重要。正因为这些工程挑战这类方案长期以来只存在于实验室或小尺寸先进封装中。如果 CS-6 真的能够把晶圆级芯片和 DRAM 垂直集成落地那它代表的意义就不只是某一代产品的参数提升而是证明晶圆级芯片的存储架构走通了一条新路径。3. 垂直集成 DRAM 会改变哪些实际工作流3.1 训练流程里最直接的受益点可能是权重和激活值的本地化大模型训练时最沉重的数据流负载往往来自两类数据一是模型权重二是激活值。权重在训练过程中要反复参与前向计算、反向传播和优化器更新。过去部分方案采用权重流式加载也就是在需要时把权重从外部存储读入计算核心用完之后再释放。这种方式可以支持超大模型但外部存储和计算核心之间的带宽始终是隐形成本。如果 CS-6 能把权重放在芯片内垂直集成的 DRAM 里那么权重加载的路径会大幅缩短。训练时每一步迭代需要的数据可以像从自己口袋里取东西一样而不是跑到仓库去拿。激活值的压力同样很大。对于长序列、大 batch 的训练激活值的临时存储经常占几十 GB并且会非常频繁地被写入和读取。GPU 集群处理这种情况时经常需要把激活值切分到不同设备上导致通信开销。而在晶圆级芯片内部计算核心之间的互联远比外部网络快如果垂直 DRAM 能作为统一的激活值缓存区整个数据交换的代价会更可控。当然这只是一种工程上的合理推测。实际效果取决于具体实现包括 DRAM 容量、带宽、访问延迟、软件能否感知并调度。但方向是明确的训练系统的目标不是“把一切都堆在计算核心旁边”而是让最热的数据离核心最近。3.2 推理的长上下文与 KV Cache 会成为一个新增长点训练之外垂直集成 DRAM 对推理的帮助可能比训练更容易被感知。近年来的大模型推理越来越强调长上下文而长上下文对存储的要求不是线性的而是近乎爆炸式增长。每多一个 token模型就要为每个注意力头保存一组 Key 和 Value也就是所谓 KV Cache。上下文窗口从 4K 扩展到 128KKV Cache 的大小可能增长数十倍甚至上百倍。这会直接影响推理的吞吐量和响应延迟因为 KV Cache 必须被反复读取和更新。在 GPU 推理场景中KV Cache 通常会先存放在 HBM 中再在计算时读到片上缓存。一旦上下文过长或并发请求过多HBM 带宽就会成为推理吞吐的最大瓶颈。如果 CS-6 的垂直 DRAM 能容纳大量 KV Cache推理引擎就可以把更多注意力计算中的中间状态直接放在片内减少外部存储访问。这对高并发、长上下文的推理服务来说可能比单纯的算力提升更有价值。这里还要注意一个细节DRAM 比 SRAM 更容易出现访问延迟波动。在推理任务中如果延迟波动过大可能导致某些请求超过超时时间。因此软件栈很可能需要做显式的存储管理而不是把所有数据都当作统一透明的大池子。3.3 并行策略和软件栈需要配套调整硬件架构变了软件的并行方式通常也要跟着调整。在 GPU 集群上模型并行、张量并行、流水线并行的核心目标之一是减少通信量。并行切分策略的很多设计和通信拓扑强相关。而在晶圆级芯片上片内互联唾手可得通信成本远低于 GPU 集群中的跨卡通信。这意味着原本为了降低跨卡通信代价而做的复杂切分在 CS-6 这类芯片上可能变得不必要。举个例子一些模型并行策略要求把模型的每一层完整放在一张卡上以减少跨层通信。但在晶圆级系统上由于片内带宽极高模型可以被更自由地层级流水化。参数服务器、AllReduce、ZeRO 优化器状态切分等策略也都可以重新审视。很多为分布式而生的优化技巧在单颗大芯片内部可能不再有存在的必要。不过硬件能力是一回事软件生态能不能把它们释放出来是另一回事。垂直 DRAM 如果存在编译器、运行时、内核程序就要能感知它的容量、带宽和延迟特性并决定把哪些张量放到哪一层。这不是单纯靠一个缓存替换策略就能做好的事往往需要更多人工介入或更聪明的自动决策。如果一定要对这件事做一个判断我会认为CS-6 的真正价值不在于让单一能力变得更强而在于让大模型训练和推理的“数据放置策略”多了一层可选路径。硬件提供的是一块更富余的内存布局能不能用好还要看软件栈的成熟度。4. 工程落地前别急着把 GPU 思路搬过来4.1 先意识到这是“单点巨型系统”不是多卡集群在考虑是否采用 CS-6 这类方案时第一步不是对比参数表而是理解它会如何影响你的基础设施规划。GPU 集群的核心优势是弹性不够用就加机器坏了就替换单卡业务增长时可以横向扩展。但晶圆级系统更像是一个“超大单体”它不需要很多台设备互联但每一台的故障半径更大。如果一台设备挂掉可能就是一个数据中心规模的计算资源中断。当然它内部有冗余核心和容错机制但运维层面的语义还是和“多卡集群里掉一张卡”完全不同。从工程实践角度看晶圆级系统的部署更适合那些“模型非常大、训练周期非常长、希望把通信开销降到最低”的团队。如果你只是做中小模型的微调、推理 POC或需要频繁上线下线不同业务那这类系统未必是高效的选择。它更适合被定位成“生产级重点业务的核心算力”而不是一台随手可用的通用机器。4.2 拿到 CS-6 后第一批验证应该做什么即使不考虑具体购买决策只说工程接入我也会建议先用一个最小检查清单来确认它是否适合你的工作负载。这套清单可以在任何新硬件评估中使用但针对 CS-6 这类带垂直内存的系统需要重点关注存储层级。先测试模型装载是否顺利看看权重、优化器状态、KV Cache 在 DRAM 和 SRAM 之间的分布是否符合预期再运行一个小规模训练步骤观察吞吐曲线是否在最初几步内稳定下来然后做一次长时间稳定性测试核心是观察温度变化与访问延迟是否有明显相关性。这个过程要一步一步来不要试图把数据直接堆到最大规模。更推荐的方式是准备一个中等规模模型约等于目标模型 1/10 到 1/4 的参数规模。先用默认配置跑通一次训练或推理确认软件栈能识别全部内存资源。检查日志中是否有显式的内存卸载行为比如把某一部分权重从 DRAM 搬到外部存储。将批量大小或上下文长度提升一倍观察吞吐和延迟变化找到性能拐点。记录每次变更前后的数据移动路径判断是否发生了外部存储访问的明显增加。这套检查的核心目标只有一个尽早判断垂直 DRAM 在你的工作负载中是不是真正被用上了还是只是“看起来有但软件根本不会调度它”。注意不要一上来就把批量数和并发数拉满。新硬件评测时最危险的信号不是性能低而是流程看似顺畅实际数据都被卸载到了外部存储最终性能没有真实提升。4.3 排查链路如果性能不如预期按什么顺序定位性能不达预期时不要先怀疑硬件也不要先怀疑软件框架按照链路一层层确认。第一层看模型是否完整装载如果模型权重和 KV Cache 已经超出垂直 DRAM SRAM 的总容量系统必然会依赖外部存储。这种情况下任何性能优化都无从谈起。这一步通过日志和监视工具就能查。第二层看访问模式模型训练和推理里哪些张量是高频访问的它们到底在 DRAM 层、SRAM 层还是在外部存储如果高频访问数据频繁出现在外部存储路径上说明软件的内存分配策略可能需要调整。第三层看延迟和吞吐的关系垂直 DRAM 的容量大但延迟不一定比 SRAM 低。如果你发现单个步骤的延迟有明显增长可以观察是不是大量数据从 SRAM 层被换入换出。这里需要做细粒度的 profiling而不是只看端到端时间。第四层看散热和供电长时间跑高负载时如果功率或温度触碰限制系统会自动降频或调整调度策略导致性能波动。此时表现出的问题很可能不是计算瓶颈而是基础设施没有跟上。一般情况下按照“装载 → 寻址 → 调度 → 物理限制”的顺序排查比直接问“为什么这么慢”要高效得多。4.4 适用边界谁更应该关注 CS-6 这类垂直 DRAM 路线并不是所有 AI 工作负载都会从“垂直集成 DRAM”中同等受益。把适用边界写清楚比吹捧一个方案更重要。优先受益的场景通常是权重特大、KV Cache 特大、上下文极长、训练周期长的任务。比如万亿参数级模型预训练、超长文档理解、代码生成与仓库级分析、多模态大模型训练。这类任务对存储容量的需求远高于普通 transformer如果能减少数据进出芯片的次数收益会非常明显。不太必要的场景包括小模型微调、短文本分类、大量低并发在线推理、以及数据量很小但需要频繁切换模型的场景。对这些任务来说芯片再大、DRAM 再多可能都用不上。且晶圆级系统的成本、功耗、运维复杂度和单点故障风险都不会只为这些轻量任务而变得划算。如果你当前正处于技术选型阶段我更建议把判断标准从“谁的吞吐量高”调整为“谁在数据移动路径上更贴合你的模型结构”。对大模型时代来说存储和计算的物理融合程度可能比单纯的核心数量更能决定工作流的天花板。从 CS-6 公开信息透露的技术方向来看晶圆级芯片的下半场已经开始它不再只追求“更大”而是追求“更密”。把 DRAM 垂直堆叠进来让数据和计算之间的物理距离进一步缩短这才是一套可以长期演进的技术底座。下一次评估 AI 基础设施时记得先问一个问题模型要用的数据接下来会被放在哪里离计算最近这个问题的答案可能比任何浮点性能数字都更能说明未来方向。