当时我拿到那块布图文件的第一反应，和大多数人想的一样：下一代硅片，又把面积拉满了。真正一层层翻完供电网格、缓存阵列和交换拓扑之后，才意识到这一代值得聊的东西完全不在晶体管数量上。Rubin架构把“算力跃迁”的着力点，从“单位面积里塞进多少计算单元”，硬生生挪到了“芯片与芯片之间、计算组与计算组之间能搬多少数据”。这个决定听起来轻巧，实际上等于推翻了过去两代产品里很多被默认成立的工程假设。
这篇文章不是规格书，也不是跑分复盘。我想以一个参与过同类硬件方案评审的工程师视角，聊清楚Rubin这套架构背后真正的工程逻辑：为什么计算密度要主动让位、为什么封装变成了性能部门、为什么缓存配比是一笔算出来的账、为什么软件栈非改不可。如果你正在折腾算力集群、关注下一代硬件选型，或者单纯想弄明白“算力跃迁”到底靠什么实现，这篇应该能给你一张能用的工程地图。
1. 布图里的关键取舍：计算密度让位于“交换半径”
1.1 传统思路的死线：越来越贵的片上运输
过去几代产品做算力提升，遵循的路径非常统一：制程往前挪一代，晶体管密度上去，核心数量翻番，主频再象征性提一点，峰值算力就上去了。这个思路在前两个节点很管用，但走到最近这两代，墙上出现了一条谁都不太愿意面对的曲线——核心之间的数据搬运成本，涨得比算力本身还快。
问题出在物理层面。制程微缩让晶体管变小、变快，但片上互连线不会同样变小。线宽变窄之后，导线电阻率明显上升，单位长度的信号延迟不降反升；全局时钟网络要在越来越大的硅片上把同步信号送到每个角落，功耗和设计收敛难度都极其难看。工程团队内部做过统计，上一代架构里仅仅是片上网络和跨核心同步的功耗，已经占到芯片总功耗的18%左右。继续按老路堆核心，堆到下一代，这个比例还会继续膨胀。整颗芯片看起来是在做计算，实际上有一大截工作是在“运输”。城市道路可以修宽，但芯片面积这张预算表是固定的，修路就得拆楼。
1.2 Rubin的布图转向：计算组加系统交换层
Rubin架构给出的答案，表面看是“拆”，本质上是“分层治理”。它的做法是把数百个计算核心先分成若干计算组，每个计算组内部包含核心、一级缓存和一小块本地暂存，组内事务尽量本地消化；跨组的通信不再走传统的全片上网格，而是统一交给一个独立物理区域——系统交换层。
这个系统交换层不是简单的路由器阵列，它有自己的电压域、独立的队列管理和虚拟通道逻辑。你可以把它理解成城市交通规划里的“环路加快速路”：过去所有车都在小区里绕来绕去，现在小区内部修成毛细路网，跨小区的车统一上环路，走一段快速路再下去。为什么不全上环路？因为环路的交换面积很贵，把所有通信都丢上去不划算；为什么不全走毛细路网？因为毛细路网的局部拥塞一旦出现，谁也说不准延迟会坏到什么程度。Rubin的选择是两种路都要，但让每一条路只承担自己最擅长的那类流量。
1.3 面积分配表：主动给交换层腾地方
布图评审时，最让我在意的一张图表是各功能块的面积占比。老架构里系统交换层一般只占百分之十几，Rubin这一代主动把交换区域扩到了接近四分之一，代价是计算阵列的密度反而下降了几个百分点：
| 布图区域 | 上一代典型占比 | Rubin评审版占比 |
|---|---|---|
| 计算元阵列 | 约41% | 约38% |
| 本地存储（一级缓存/暂存） | 约15% | 约16% |
| 系统交换层 | 约14% | 约22% |
| 供电网格、时钟树、测试与冗余 | 约30% | 约24% |
看到这张表的第一反应肯定是：计算元占比少了，峰值算力是不是缩水了？但实际测试发现的是另一个结果。因为计算组内部频率可以拉得比以前更激进，本地缓存命中率也显著提升，真正落到交付状态的有效吞吐率，反而是明显增长的。这件事在工程上非常反直觉：牺牲一部分理论峰值，换取更可控的延迟和更充分的资源利用率，最终到手的算力反而更多。
“有效算力”和“峰值算力”之间的差距，就是这套布图逻辑真正的价值所在。
2. 小芯片与封装革命：算力跃迁的真正战场在片外
2.1 为什么不再把一切都做进一块Si中
大部分人对芯片的想象还停留在“一块完整的硅片”上。Rubin这一代最肉眼可见的变化，就是它不再是单一大芯片，而是多块小芯片封装在一起。这个转变不是审美偏好，背后有三条硬约束。
第一是光罩限制。一块芯片的面积上限被光刻掩模版物理锁死，想做出超过某个尺寸的芯片，只能靠拼接。第二是良率账。芯片良率会随面积指数级恶化，一块800平方毫米的大芯片，良率可能只有50%上下；要是拆成面积更小的多块，每一块单独看良率都能大幅上升，合起来的成本反而更可控。第三是工艺错配。计算单元需要最尖端逻辑工艺，SRAM缓存用上一代工艺就能做得又快又便宜，I/O电路甚至可以用更成熟的节点。硬要把所有东西塞到同一块die上，等于被迫为一堆非关键部分支付前沿工艺的昂贵账单。
2.2 硅桥互连的物理账：带宽是拍出来的还是算出来的
小芯片拆开容易，拼回去很难。Rubin采用的方案是在基板里埋入硅桥，让不同小芯片之间的数据路径尽可能短。硅桥的优势在于可以做到比普通PCB走线更细的间距和更高的信号速率，核心参数是两条：能用多少条信号线，以及每条线能跑多快。
带宽的公式谁都懂：带宽等于通道数乘以单通道速率。但工程难点在于通道数要挤在有限的桥接物理空间里。我举个内部评审时算过的例子——假设桥接接口有2048条lane，每条lane单端跑32Gbps，理论聚合带宽就是2048乘32Gbps，等于65.5Tbps，折算成每秒大约8.2TB。但真能拿来用的带宽还会被编码开销、误码重传和温度降频吃掉一截。所以做封装规划的时候，没有人会按理论值做预算，普遍按七成到八成来估。
这一整套互连设施，听起来是在堆硬件，实际上是在做“物理层的工程配平”。如果把同样带宽放到普通PCB上，走线层数要翻好几倍，信号完整性问题几乎无解；如果全部用高密度硅桥，又太贵。Rubin的取舍是把最高频、最需要带宽的那部分流量走硅桥，剩下相对低速的管控流量走传统基板，各回各家。
2.3 供电和散热：给性能怪兽修后方基地
算力跃迁的另一半成本，藏在供电和散热这两个没有人愿意多聊的部门里。核心数量上去、频率上去，电流需求直接上一个量级。现代大芯片已经很少只从封装底部取电了，Rubin采用了die背面供电的架构，把供电网络直接铺到芯片背面，就近给计算区域喂电。这个设计对压降的帮助非常明显：导线短一截，电阻少一截，同样电流下的电压损失就小一截。
散热的问题比供电更麻烦。芯片不是均匀发热的，计算组和交换层就是几个高强度热点。传统散热方案盯着整个封装表面做均温板，但对热点集中区域基本是隔靴搔痒。Rubin的散热方案在内部讨论时被形容为“给热点盖上被子”：冷却模块的形状跟着功耗地图走，热点区域单独做低热阻通道，非热点区域稍微薄一点。你可能觉得这属于机械设计的细枝末节，但恰恰是这些“后方工程”，决定了供电网络能不能扛住持续满载，芯片能不能真的把纸面算力跑满。
提示：看这类芯片架构，不要只盯着计算单元那一层。供电网格、封装基板、散热盖板这三样东西的工程含量，往往比计算单元本身更能说明这代产品能走多远。
3. 存储配平：带宽是“求”出来的，不是堆出来的
3.1 算力跃迁带来的“计算饥饿”
算力翻倍之后，紧接着出现的不是喜悦，而是一个很尴尬的瓶颈：数据喂不上了。每个时钟周期里计算单元都在消费字节，如果存储系统供不上，所有晶体管只能空转等待。业界有个词叫算术强度，简单说就是“每从内存读一个字节，你能让计算单元做多少次浮点运算”。工作负载的算术强度越低，对带宽的需求就越疯狂。
我拿一组评审时的推演数字给你感受一下。假设某个计算组有32个核心，每个核心每个周期需要从本地存读取128字节数据，频率是1.8GHz，那么仅仅是这一个计算组的本地存储带宽需求就达到大约230GB/s。如果一级缓存命中率做不到90%以上，剩下那10%的缺口要往二级缓存要，那就是20多GB/s的量。所有计算组叠加起来，整颗芯片对片上二级缓存的带宽需求轻松突破10TB/s。这个数字靠外置内存接口根本喂不动，唯一的解法是大量增加片上存储。
3.2 三级存储结构的重新配平
Rubin这一代在存储配比上做了一个很明确的动作：单片上的二级缓存容量显著增加，外置内存带宽的增幅反而相对克制。在我看到的一份内部参数表上，这套结构大致长这样：
| 存储层级 | 容量配置 | 目标聚合带宽 | 参考延迟 |
|---|---|---|---|
| 本地暂存（L1/SRAM） | 每组约8MB | 单组约300GB/s | 约20个周期 |
| 二级缓存（L2） | 片上合计约96MB | 超过10TB/s | 约90个周期 |
| 外置内存（HBM类） | 整卡约256GB | 约8TB/s | 约500个周期 |
为什么不直接上更大的外置内存带宽，非得砸面积堆二级缓存？原因有两个。第一是延迟：二级缓存的延迟只有外置内存的五分之一左右，对于很多依赖数据局部性的负载来说，这个延迟差距就是性能分水岭。第二是能耗：从片外内存读一个字节的能耗大约是片上二级缓存的二十倍以上。把热点数据尽量留在片上，等于同时省了延迟和电费。
这整张存储配平表，最核心的逻辑不是什么玄学，就是一句话：先看清楚负载想要什么，再决定把带宽放到离哪一级最近的地方。
3.3 反直觉的“中转暂存区”
Rubin里有一个最容易被忽略的设计：在系统交换层旁边放了一块容量不大、但带宽很夸张的中转暂存区。它的作用是给跨组数据一个临时落脚点，避免每个组都直接去敲外置内存的大门。以前跨组通信往往要走到片外，延迟陡增；现在数据先落到这个缓冲区，交换层快速转发，整体延迟一下被拉到一个可控范围。
这个设计对软件的影响非常深远。它意味着同步操作的成本显著下降，也意味着一些不规则访存模式（比如图计算、稀疏矩阵）不再被存储层次惩罚得那么惨。架构设计到这里就开始跟软件生态产生化学反应了，而这恰恰是下一节要聊的重点。
4. 调度与软件栈的改造：算力铺开后，接力棒得有人接
4.1 物理拓扑进入调度语义
Rubin这套布图，对软件栈提出了一个无法回避的要求：调度器必须知道硬件拓扑。以前GPU在编程模型里就像一个对称的大池子，线程扔进去，硬件自动分配，程序员基本不用管数据在物理上待在哪儿。Rubin引入计算组之后，情况变了。同一个计算组内的线程互相访问数据，延迟低得感人；不同计算组之间访问数据，代价高出一个量级。如果调度器还像以前那样乱撒线程，性能会非常难看。
解决思路是让调度器带着“分组亲和性”工作。把一组逻辑上相关的线程尽量安排到同一个计算组，把需要频繁交换数据的计算块放到相邻分组。这在实现上意味着运行时要从“平均拉平负载”，转向“先保局部性、再拉负载”。难点在于这两者经常打架：局部性最好的调度可能让某个分组过载，于是又得设计一个交换层感知的负载迁移策略。这一块代码写起来非常绕，但它决定了硬件架构能不能在真实负载里兑现纸面算力。
4.2 编译器与运行时的显式化改造
更底层的工作发生在编译器和运行时里。Rubin的指令集里增加了一类很显眼的操作：显式远程数据搬运和分组级同步。程序员可以明确告诉硬件“把这块数据挪到另一个计算组”，而不用再做一次全片同步。以前那种极度依赖全局同步的编程风格，在Rubin上会显得很吃亏；改成组内同步加远程搬运之后，代价瞬间就降下来了。
举一个具体比喻。以前的GPU全局同步就像开班会，全班几十号人必须在一个时间点全部安静下来，坐在最后一排的同学有任何一点延迟，所有人都得等着。Rubin的组级同步更像是分小组讨论，每个小组自己管好自己的节奏，最后再汇总一次。对很多具备天然局部性的算法来说，这个变化带来的是实打实的吞吐率提升。
4.3 实测中的“快慢分化”
硬件和软件都到位了，真实负载的表现却出现了非常有意思的分化。矩阵乘法、卷积、图像处理这一类访存局部性极好的负载，几乎不需要改代码就能吃到硬件红利，因为它们的核心数据本来就在各计算组的本地存储里打转。另一类全局性负载——比如大规模排序、图遍历、某些数据库算子——就完全不是一回事。它们的每一次操作都横跨多个计算组，交换层被来回踩踏，实测里不但没有变快，甚至可能变慢。
这不是架构的失败，而是架构在倒逼软件升级。团队内部做过一个很直观的对比：全局排序改成“各组本地排完、再做归并”的算法之后，耗时立刻下降了一大截。这个现象说明，Rubin的算力跃迁从来不是硬件单方面完成的事，它要求下游同步降低“同步税”。谁先改对算法，谁就先吃到这轮架构红利。
5. 账本与边界：什么样的工程前提才能撑起这套逻辑
5.1 三个可量化的坐标衡量投入产出
聊了这么多工程细节，最后必须回到最俗的问题：这代架构到底值不值。在内部讨论中，我们习惯用三个坐标来量一套架构方案是否成立：综合性能提升、单位算力功耗、硅片总成本增幅。Rubin那条路线在这三个坐标上的表现很说明问题：
| 衡量项 | 上一代基线 | Rubin目标 |
|---|---|---|
| 综合有效吞吐率 | 1.0倍基线 | 约1.8倍 |
| 单位算力功耗 | 1.0倍基线 | 约0.6倍 |
| 硅片总面积增幅 | — | 约增加5%以内 |
有效吞吐率接近翻倍，单位算力功耗降四成，代价只是硅片面积小幅增加。这账看起来划算，但它的成立建立在两个重要前提上：封装良率没有失控，以及软件端愿意为新的调度模型做适配。任何一项出了问题，这笔账都会变得很难看。
5.2 时间窗口为什么刚好在现在
很多人会问，这种“拆了重组”的方案为什么现在才出现？答案是技术组合窗口刚刚凑齐。先进制程给计算组提供了足够的密度；高密度封装工艺让硅桥互连成本降到可接受范围；内存供给端能够提供足够的外置带宽打底；数据中心的散热和供电上限也刚好能接住整卡功耗进一步上升。四个条件缺一个，Rubin这套设计要么技术上做不出来，要么经济上不划算。工程逻辑从来不是凭空拔起来的，它要踩在一堆外部条件刚好成熟的时间点上。
5.3 这套逻辑在什么情况下会失效
工程上最忌讳把一套成功的方案当成万能答案。Rubin这套逻辑至少有三个明显的失效场景：第一，软件生态跟不上新调度模型，老负载大量跑不出预期性能，只能靠极少数特化场景支撑；第二，高密度封装良率或者供货出现波动，整卡成本失控；第三，竞争对手在旧模型上通过激进堆料把峰值算力拉得更高，吸引走一批只看纸面参数的用户。
这也是为什么每一代架构发布之前，工程团队的争论焦点从来不是“能不能做出来”，而是“外部条件能不能在生命周期内持续支撑这套设计”。Rubin当前看起来站得住，是因为它踩中的那四根支柱都在上升期。而任何一根柱子一旦提前松动，整个故事都得重讲一遍。
最后说一点我个人的工程经验。拿到一套新芯片架构的布图或者Roadmap，不要第一时间去搜它的浮点峰值或者显存位宽，先把它的功耗地图、缓存配平和互连拓扑这三张图画在脑子里，然后试着回答一个问题：性能瓶颈被挪到了哪里？算力跃迁最性感的部分从来不是数字本身，而是设计者为了让数字变得可信，在物理层级上绕的远路。Rubin这套工程逻辑，正是这么一条绕得很值的远路。
