Arm服务器CPU的Chiplet多Die路线到底在解决什么问题先说个背景。做服务器底层和基础设施的同学这两年应该都躲不开一个组合词Arm服务器CPU。如果再多看两场HotChips的PPT你会发现更常被提到的已经是Chiplet和多Die了。我自己的习惯是从HotChips几十届的公开资料里挖架构细节这几年最大的感受就是Arm服务器CPU已经从“能不能用”进入了“怎么把一个个小芯粒堆出大规模算力”的阶段单Die的SoC反而成了少数派。这篇文章不打算给你念PPT而是想把Arm服务器CPUChiplet多Die这条线讲透为什么非要多Die不可、多Die到底难在哪、现在主流方案长什么样以及如果你想自己啃HotChips资料应该从哪个角度去读。无论你是做底层软件的、搞服务器选型的还是单纯想弄明白Arm服务器为什么突然变热都可以往下看。1. 为什么服务器CPU一定要走向Chiplet多Die架构1.1 单芯片的天花板光罩、良率与功耗三角芯片制造里有个很实在的物理限制叫reticle limit意思就是光刻机一次曝光能覆盖的最大面积大约在800平方毫米左右。你可以把它理解成一张饼皮一次只能擀这么大想再大就进不了烤箱了。传统的服务器CPU单芯片设计核心数一多、缓存一做大、IO一加满面积很容易顶到这张饼皮的边缘。面积到顶之后会带来三个连锁问题。第一是良率晶圆上单颗芯片面积越大碰到缺陷的概率就越高良率掉得厉害成本直接被拉高。第二是散热Die面积大意味着功率密度集中热点不好处理散热器、封装基板都要跟着升级。第三是灵活性单芯片把所有功能焊死在一起客户要32核还是128核只能通过不同的SKU去切但一颗Die的研发周期和流片成本是固定的想覆盖高中低端市场就得靠多颗不同Die成本翻倍。当年X86服务器CPU早就遇到这个问题了所以AMD的EPYC、Intel的Xeon都开始做chiplet化。Arm服务器CPU因为是后发反而少了很多历史包袱直接从多Die起步或者快速切换过来也是顺理成章的事。1.2 Chiplet的本质把一颗大芯片拆成几个小积木Chiplet的思路说白了就是“分而治之”不再追求用一颗巨大的Die装下所有功能而是把CPU核心、内存控制器、IO接口、加速器拆成多个小Die再用先进的封装技术把它们拼在一起从系统角度看仍然是一颗CPU。比如一颗128核的服务器CPU可以做两颗64核的Compute Die再加上一颗集中管理的IO Die或者System Die通过Die-to-Die互联把三颗拼起来。这样就绕开了单个Die面积限制每颗Compute Die的面积可以控制在300~400平方毫米良率显著提升成本反而更可控。多Die架构还有一个容易被忽略的好处混合制程。核心计算Die对性能要求高可以用最新的工艺节点IO Die对频率不敏感用成熟工艺就能省一大笔钱特殊加速Die甚至可以交给不同代工厂做再封装到一起。这在单芯片时代是不可想象的因为整颗Die只能用一个工艺节点。1.3 为什么Arm做Chiplet有天然优势Arm在服务器端的优势不是单核性能最强而是生态一致性。所有Arm服务器CPU都跑在ARM指令集上从手机SoC到服务器CPU用的都是同一个指令集家族这意味着Chiplet之间的互联协议、一致性协议、电源管理规范可以高度统一。再往深处说Arm的Neoverse系列从V1开始就不是为单一Die设计的它把一致性互联、内存子系统、IO扩展都做成了可配置的模块。芯片厂商拿到Neoverse的IP授权可以像搭积木一样往不同方向拼装这让Arm在Chiplet路线上走得比X86更顺。你去翻HotChips上几家Arm服务器厂商的PPT第一页几乎都是在讲“我们的多Die架构怎么把Neoverse核心拼起来”这就是生态带来的好处。2. 多Die服务器CPU的核心工程问题2.1 Die-to-Die互联一致性比带宽更头疼多Die拼在一起第一步要解决的是Die之间怎么通信。目前主流方案基本都是加Die-to-Die的物理接口比如台积电的CoWoS中介层、各种InFO-LSI方案、以及逐渐成为业界共识的UCIe标准。这些技术解决的是物理层传输带宽和延迟问题但光有物理连接远远不够架构层更麻烦的是缓存一致性。一台多Die服务器CPU所有核心共享一套物理地址空间A Die的核心访问B Die上的内存必须保证缓存里看到的数据是对的。这就需要在NoC片上网络上做分布式目录Directory把每个缓存行的归属权记录清楚跨Die访问走的是Socket间的通道。和传统的多路X86服务器相比多Die CPU内部的跨Die访问延迟要低得多但比起单Die内的访问还是有明显差距通常会有1.5倍以上的延迟差异。这里有个容易踩坑的点很多人以为多Die就是“把两个CPU粘在一起”直接用多路系统的思路去理解但在底层协议上完全不同。多路系统走外部总线比如UPI/CCIX多Die走的是片上一致性网络ARM CHI协议对操作系统和应用程序来说多Die的复杂度藏得更深带来的NUMA问题也更微妙。2.2 内存层级与NUMA陷阱服务器CPU多Die之后内存控制器几乎都是跟着Compute Die走的也就是每个Compute Die直接挂自己的DDR内存通道。这样做的好处是内存带宽能随着Die数线性扩展坏处是跨Die访问内存的延迟差异被放大了。举个例子一颗双Die CPU每个Die挂8通道DDR5本地内存访问延迟可能在120ns左右访问另一颗Die上的内存可能就要到160~180ns。对性能敏感的应用来说这个差距直接决定了任务调度策略操作系统必须知道NUMA拓扑尽量把内存分配在离核心最近的节点上否则性能掉个10%~20%很常见。所以多Die Arm服务器的BIOS和固件里通常会把NUMA信息暴露得很清楚Linux下可以用lscpu、numactl这些工具去看距离。实际部署的时候我建议把NUMA interleaving关掉让应用自己感知拓扑效果比系统自动均衡要稳得多。2.3 功耗、散热和封装协同设计多Die的功耗密度问题比单Die更突出。单颗Compute Die可以做到几百毫瓦到几百瓦但两颗Die叠在同一个封装里热点会重叠散热路径也更长。所以你会发现HotChips上各家方案的PPT里一定有一页专门讲封装和散热通常都是2.5D/3D封装加均热板加液冷适配。封装层面的选型也很关键。目前主流是硅中介层方案也就是把所有Die放在一块硅片上再通过硅通孔TSV连接到基板成本高但互联密度大、延迟低也有直接用有机基板做扇出布线的方案成本低但带宽上不去。Arm服务器CPU因为核心数量多、对带宽要求高绝大多数厂商选的都是中介层方案这就是为什么成本通常不低。从整机角度来看多Die还带来了电源供电的复杂度。每个Die的电压域和频率域可以独立调节电源管理系统要从“管一颗芯片的电压”变成“管三颗Die的电压和相互关系”这就对固件和电源管理控制器提出了更高要求。HotChips资料里如果出现“per-die DVFS”这个词指的就是这个能力它也是多Die能做好能效比的关键。2.4 良率与成本模型多Die到底省不省钱很多人第一反应是多Die把芯片拆小了良率上去了成本肯定低了。但实际情况没那么简单。小Die的良率确实高但你又多了封装测试的成本、Die-to-Die互联的良率损耗、以及基板涨价的问题。整体算下来只有在核心数很大比如96核以上的SKU上Chiplet才比单Die有明显成本优势。这也是为什么Arm服务器CPU一开始切入市场都是64核打底很少做低核数的产品。因为低核数单Die更划算Chiplet的优势发挥不出来。等到要用高核心数去打服务器市场的时候Chiplet多Die的成本模型才真正成立。所以你看各家产品线中低端可能还是单Die高端旗舰一定多Die这是由成本规律决定的不是厂商不想统一。3. Arm服务器阵营的代表性多Die方案3.1 Ampere从Altra到AmpereOne的强核路线Ampere在Arm服务器市场算是声音最大的玩家之一。初代的Altra系列是单Die设计走的128核路线当时就已经把Arm服务器的核心数拉到了一个让X86有点紧张的级别。后续的AmpereOne系列开始明确切入Chiplet多Die架构产品线规划里出现了多个Die组合的方案强调“可预测性能”——也就是每个核心的性能都很稳不搞超线程让云原生应用能够得到确定的算力。Ampere在多Die上的思路很有代表性它不追求单Die无限堆核而是用多颗中规模Die拼出大规模同时保持每个核心的频率和Cache配置基本一致。这带来的好处是软件不需要针对性做核心类型区分所有核心一视同仁对于容器调度和微服务场景非常友好。顺带说Ampere对内存带宽特别上心多Die方案里内存通道数量跟着Die数走所以高核心数的SKU配套的内存带宽非常夸张。这对跑数据库和内存计算类的负载很有帮助也是你在看它的PPT时要重点关注的数字。3.2 AWS Graviton系列云厂商自研算力的样板AWS的Graviton系列是云厂商下场做Arm芯片最成功的一个代表从Graviton1到后来的Graviton3、Graviton4几乎每一代都在HotChips上有完整的技术分享。Graviton系列的特点是和AWS的虚拟机服务深度绑定从处理器架构到Nitro系统都做了整体优化。Graviton在Chiplet上的布局不完全是“CPU多Die”它更显著的是把Nitro加速卡、网络虚拟化、存储虚拟化这些模块都做成独立的小芯片和主CPU协同工作。这样做的好处是数据通道不再占用CPU资源虚拟化开销被硬件卸载这也是云上跑Graviton实例时普遍觉得性能稳定的重要原因。如果去看HotChips上AWS分享的架构图你会发现它整个系统是一个典型的“CPU多加速器Chiplet”体系。我觉得这才是Arm服务器Chiplet的正确打开方式之一不是在SoC里硬塞功能而是把功能拆成小Die按需组合每个Die都做精做专。3.3 其他值得关注的路线除了Ampere和AWS近几年HotChips上还有几类方案值得关注。一类是面向超算和AI训练的ArmGPU融合Chiplet典型就是NVIDIA Grace系列它把Arm CPU和GPU通过高速一致性接口连在一起本质上也是一种异构Chiplet封装只是CPU和GPU各司其职。另一类是定制化方案的兴起。不少做云服务或通讯设备的厂商不再买通用Arm芯片而是直接找设计服务公司定制一颗“CPU Die自研加速Die”的组合通过Chiplet方式集成这样既保留了Arm生态又有了差异化。这类方案在HotChips上的篇幅不多但逐年增加信号很明确Chiplet越来越成为Arm服务器产业的一种标准打法而不是某个厂商的奇思妙想。4. HotChips资料包解读与研读指南4.1 资料包整体结构与内容说明这次整理到的HotChips资料实际上是一个跨年份的合集核心覆盖了近几届大会中和Arm服务器CPU、多Die、Chiplet相关的slides和论文其中也包含最新一届先期解禁的部分内容。整个资料包以PDF为主按“年份厂商主题”做了目录分类方便按图索骥。资料包大体分四块第一块是Arm官方和Neoverse相关的分享讲Arm对服务器CPU架构演进的整体规划第二块是头部云厂商的自研芯片方案比如AWS、以及类似的超大规模厂商的分享第三块是传统芯片厂商的Chiplet技术细节包括封装、Die-to-Die接口和一致性协议第四块是我额外收集的一些背景资料比如UCIe标准白皮书、Arm CHI协议摘要以及少量用来补概念的教程类文档。需要提醒的是HotChips的slides并不是标准的技术手册它更多是工程师之间的“内部交流”所以有些图标注不全、有些数字看起来非常理想化。看的时候不要把PPT里的示意图当成物理实现细节重点还是抓架构思路和性能趋势。4.2 从HotChips历年论文里能看到什么如果你从头到尾啃一遍这些材料最直观的收获是能建立一个“Arm服务器CPU从单Die走向多Die”的完整时间轴。早期几年的分享还集中在“Arm能不能做服务器CPU”“ISA够不够用”这些话题上到了近几届话题重心已经变成了“多Die一致性怎么做”“Chiplet互联IP怎么选”“超过128核怎么调度”。从技术角度看我建议重点看三样东西一是Die照片和floorplan这是理解一颗CPU怎么布局的最直接材料从中能看出缓存、互联、内存控制器、SerDes分别放在哪二是内存和互联带宽的测试数据HotChips里通常会有实测图表可以据此对比不同方案之间的真实差距三是软件生态相关的内容尤其是ATF固件、UEFI、Linux内核适配、虚拟化支持这些这些都是实际落地时绕不开的。还有一个小技巧很多论文最后几页会放“未来工作”和“挑战”里面往往是厂商最真实的需求表达。比如有的厂商提到“我们需要更低延迟的Die-to-Die接口”说明当前方案延迟还不够好有的提到“需要更细粒度的电源管理”说明现在功耗控制还比较粗糙。这些才是真正值得你花时间琢磨的行业信号。4.3 研读建议和踩坑提醒啃资料之前先给自己定一个目标是要了解架构演进趋势还是要搞清楚某一个具体技术比如UCIe怎么落地。目标不同读法完全不同。如果是入门我建议先看Arm Neoverse和各家旗舰CPU的概述把整体框架建立起来再回头看UCIe、CHI、封装技术这些细节。一上来就掉进协议细节里很容易劝退。一个常见的坑是混淆“多Die”和“多路”。HotChips里的Arm服务器CPU很多是多Die形态但它们在BIOS里通常体现为一个物理Socket和传统的双路、四路服务器是两回事。多路系统有Socket间协议和更深的NUMA层次多Die则更接近“单颗物理芯片内部的多分区”。调试和性能调优时一定要先分清楚自己的目标是哪种形态。还有一个我反复踩过的点厂商在HotChips上展示的“理论带宽”“峰值计算”这些数字都是模型的极端值真实应用里很难达到。比如PPT上说Die-to-Die互联带宽多少多少实际延迟和可达到带宽往往只有三分之一左右。所以看资料时可以记“上限数字”但不能拿它直接做容量规划最好多找几家的数据交叉验证。5. 对软件生态和日常开发的实际影响5.1 别把多Die当多路用软件生态可能是Arm服务器CPU多Die落地时最容易被低估的环节。很多跑在X86服务器上的中间件在Arm上重新编译后跑起来没问题但性能上不去问题往往就出在NUMA感知和线程亲和性上。因为多Die的延迟差异比单Die大线程被调度到远端Die上执行性能暴跌得非常明显。实际工作中我的建议是容器环境下一个Pod尽量绑定到一个NUMA节点数据库这类高并发应用打开NUMA亲和的配置项数据处理类应用根据数据结构选择内存分配策略。这些在X86时代是“可选优化”在Arm多Die上基本是“必选操作”。好在Linux主线和主流发行版对Neoverse系列的支持已经很成熟numactl、hwloc、cgroup这些工具都能正常工作主要是靠人工去配置。5.2 云上实例选择与性能调优如果你用云上的Arm实例情况会更微妙。云厂商会通过vCPU调度和内存分配尽量让你的虚拟机跑在同一个Die的范围内但你没法从虚拟机内部看到底层真实拓扑。这时候能做的是多测几个规格用sysbench、stream这类工具测延迟和带宽对比不同规格之间的差距。调优的时候有个方向容易被忽略PCIe和网卡的位置。多Die CPU里PCIe控制器通常分散在不同Die上你的虚拟机如果跑在A Die而网卡和NVMe SSD挂在B Die那么所有IO路径都会绕一圈跨Die访问网络和磁盘性能都会有损失。云厂商的智能调度通常能规避这个问题但自建集群时一定要看PCIe拓扑尽量把IO密集的虚拟机分配到离对应PCIe Root复杂最近的NUMA节点上。5.3 对编译优化和指令集适配的影响Arm服务器CPU还有一个绕不开的话题软件包的编译。多Die架构本身不改变ISA但会放大“跑没跑对指令”的差异。比如Armv9引入了SVE向量指令如果你的软件编译时没有开启相应的优化选项可能跑的是完全没向量化的路径性能差距在核心数一大、数据量一高的时候非常明显。具体操作上交叉编译时提前确认目标CPU特性比如Neoverse V2支持什么扩展、是否启用SVE都直接在GCC或Clang的参数里指定-mcpuneoverse-v2这样的选项。在X86上很多人习惯了二进制包通用的思路在Arm服务器上这种“不想多管”的代价会比X86大很多。所以企业做Arm迁移时最好专门配一套构建流水线针对不同代际的Arm CPU分别产出优化版本虽然前期成本高一点但上线后的性能差距值得这个投入。6. 常见问题与实战心得6.1 多Die Arm服务器CPU常见问题速查问题现象排查方向处理建议应用性能忽高忽低线程跨Die调度、内存不本地用numactl绑定节点检查容器CPU亲和性内存带宽和理论值差距大测试工具没绑核、拓扑未识别用lscpu -e看NUMA按拓扑重新压测网络/磁盘延迟异常高PCIe设备挂载在远端Die调整虚拟机/进程所在NUMA节点编译出的程序在部分机型上性能差未针对具体CPU微架构优化使用-mcpuneoverse-v2等对应选项重新编译固件/BIOS无法识别多Die拓扑固件版本旧、ACPI表格不完整升级到厂商最新固件确保SRAT/SLIT正常输出上面这些是我在自建Arm服务器集群和云上Arm实例调试过程中遇到过的真实问题。大多数排查工具在Linux下都很成熟关键是先有“多Die会造成性能差异”这个意识不然很容易把问题归到应用头上结果白折腾半天。6.2 整理HotChips资料时的一点个人体会这份HotChips资料我是分了好几轮才整理完的。第一轮先过目录摘要把和Arm服务器CPU、Chiplet、多Die强相关的文章挑出来第二轮看架构总览和die photo建立感觉第三轮才精读互联、一致性、内存子系统这些细节。这样做的好处是能在短时间内建立一个比较大的知识框架不至于一上来就被某个协议细节困住。另外我越来越觉得看HotChips这种厂商主导的资料不能只看它取得的成果更要看它回避了什么。比如某厂商PPT里详细讲了自己的多Die带宽有多猛但完全不提跨Die延迟和一致性开销这种情况就要警惕。把各家方案放在一起对比哪些是共性趋势、哪些是厂商差异化卖点其实一目了然。Arm服务器CPU的Chiplet多Die趋势已经非常明确了而且明显不是过渡方案。随着UCIe等互联标准逐渐成熟、封装成本进一步下降未来你会看到更多把异构加速器、专用IO、甚至内存都做成Chiplet形态的Arm服务器SoC。这篇内容讲了很多架构层面的事但说句实在话硬件再强最终还是要靠软件把这些Die用好。我个人的建议是如果你打算深度使用Arm服务器现在就可以开始把软件层面的NUMA感知、编译优化、固件和性能测试这套东西跑通。等技术全面铺开的时候你已经有了一套适配多Die的成熟工具链那时候的优势不只是单纯的“会装个系统”而已。