几年前我在机房给一台Arm服务器装机旁边的老师傅带着怀疑问我“这玩意儿跑数据库能用吗”当时我只能说边缘业务没问题核心业务不太敢放。现在再有人问这个问题我的回答通常变成“你先告诉我你准备让这台服务器上的CPU用几个Die。”这个转变背后正是Arm服务器CPU从“跑分好看”到“敢上生产”的关键——Chiplet多Die技术。这篇文章想拿HotChips 2026资料作为引子把Arm服务器CPU的Chiplet多Die技术路线、落地难点、选型思路和软件生态这些年在实际项目中沉淀下来的东西串一遍。如果你是做服务器选型、架构设计、底层运维或者云原生基础设施的这篇会比较对胃口哪怕你只是因为业务需要把Arm的Redis、MySQL、Nginx搬上生产环境也能从里面找到几条能直接用的经验。1. 传统单片SoC撞墙后Chiplet正好补上Arm的短板1.1 从手机SoC到数据中心Arm的处境完全不一样Arm架构在手机SoC领域统治了十几年一个SoC里放几个大核加一堆小核再加上GPU、NPU、基带整体功耗控制在几瓦到十几瓦这种设计思路非常成熟。但服务器不一样一台2U服务器里的CPU功耗普遍在200W以上内存通道要八通道甚至十二通道PCIe要几十个Lane还要支持CCIX、CXL这类高速互连。把手机SoC的设计方式放大几倍直接搬到服务器上会立刻撞上两个物理墙一是制造工艺的良率墙二是功耗密度墙。很多人以为Arm服务器CPU是“最近几年才冒出来”实际上Arm很早就想进服务器市场只是早期产品多源自手机SoC的延伸单个SoC在核心数、内存带宽、IO扩展上都不够看软件生态更是惨不忍睹。那时候别说Redis这类高性能中间件连装个主流Linux发行版都要折腾半天。1.2 Chiplet是结构选择不是一个营销词Chiplet中文通常叫芯粒或者小芯片本质是把一颗原本做在同一个大晶圆上的芯片拆成多个物理上独立的Die再通过先进封装技术把它们组合在一起对外看起来还是一颗完整的CPU。这个做法在消费级市场被AMD带火过在服务器领域则是所有高性能CPU厂商都在押注的方向。我理解Chiplet对Arm服务器CPU的意义不只是“多个Die拼接”这么简单。Arm的商业模式是IP授权厂商可以买CPU核、买互连IP、买内存控制器IP再自己组合出SoC。这种模块化基因和Chiplet天然合拍。过去大家觉得Arm服务器CPU核心数上不去现在通过多Die堆叠一个封装里塞上百核甚至两百核都不是新鲜事。核心数不再是短板反而是卖点。还有一个容易被忽略的点Chiplet思路让Arm服务器CPU更具差异化。x86阵营里Intel和AMD受制于自研CPU核的路线基本是“一套架构做全系产品”Arm阵营里Ampere、AWS Graviton、NVIDIA Grace这些产品的设计思路差异非常大。有的偏云实例的性价比有的偏AI计算的内存带宽有的偏整机柜的功耗控制。这种差异化的根源就是每个厂商都可以在不同Die上按需组合。1.3 x86带头趟雷反倒帮Arm验证了方向回看这几年的芯片行业x86厂商在Chiplet上踩过的坑其实等于帮Arm阵营做了预演。AMD从Zen 2开始把计算Die和IO Die分离后来的EPYC服务器CPU普遍采用多Die方案Intel也在用类似思路解决大芯片良率和扩展性问题。市场已经意识到完全靠自己造一颗超大单Die的芯片在先进工艺节点下越来越不划算。对Arm服务器CPU来说这形成了一种“后发优势”x86已经用多年教训验证了多Die架构的收益和风险Arm阵营可以直接吸收这些经验。比如IO Die的设计怎么避免成为瓶颈跨Die一致性怎么做才不会让性能大幅下降这些在公开资料里能找到很多真实案例。我在HotChips这类会议上看到的不少Arm服务器CPU架构都能看到对x86多Die方案教训的针对性设计。结论很简单Chiplet多Die不是Arm的备选项而是Arm服务器CPU走向高性能市场的必经之路。2. 多Die第一道坎Cache一致性与跨Die互连到底卡住什么2.1 一致性不是一个可以慢慢让步的问题多Die架构听起来简单——把几个Die拼起来就行。但CPU不是乐高积木多Die之间最核心的问题就是缓存一致性。简单解释一个系统里多个CPU核心同时读写同一块内存为了保证所有核心看到的数据是一样的必须有一套缓存一致性协议。单Die时代所有核心在同一个物理芯片内部连接延迟低协议开销小到了多Die时代核心分散在不同Die上一个Die里的核心修改了某块数据其他Die里的核心必须立刻知道否则就会读到旧数据。如果一致性处理不好最典型的后果就是数据库或者分布式系统里出现数据错乱。这不是“性能慢一点”的问题而是正确性的问题。服务器上有大量并发场景这种错误一旦出现就是灾难级别。2.2 延迟、带宽和NUMA效应我经常用一个生活化类比来解释多Die的挑战一个公司如果所有人都坐在同一个大开间里喊一嗓子就能交流如果把公司拆成十几个独立办公室大家交流就必须通过走廊速度变慢还容易堵车。多Die就是这些独立办公室Die之间的互连总线就是走廊。在多Die Arm服务器CPU上访问本地Die上的内存和访问对端Die上的内存延迟差距非常明显。本地访问加上Cache Miss带来的延迟可能是一百多纳秒跨Die访问往往到两三百纳秒如果再叠加跨Socket跨物理CPU延迟还会更高。这对延迟敏感型应用影响很大比如Redis这种纯内存计算跨Die访问会把P99延迟拉高。很多人在单核性能测试里看不出问题因为单核任务和数据都集中在同一个Die上。一旦跑多线程、大数据集的工作负载NUMA非统一内存访问效应就开始显现。运维和调优时必须了解目标CPU的NUMA拓扑否则性能会莫名其妙地下降一截。2.3 CHI、CXL、UCIe各管一段别搞混Interconnect这条技术栈上的名词非常多大家容易混淆。我在项目里常用下面这个表把协议分清楚协议/规范层级解决什么问题典型场景AMBA CHI片上互连协议处理器核心、缓存、内存控制器之间的Cache一致性通信Arm服务器CPU内部多Die互连CXL高速互连标准内存扩展、设备共享、缓存一致性跨设备/跨CPUCXL内存池、智能网卡、加速器连接UCIe物理层/封装互连标准不同芯片厂商的Die之间高速互连Chiplet之间的物理连接未来多厂商混搭NVLink-C2C片间互连技术CPU和GPU或两个CPU之间高带宽一致性互连NVIDIA Grace系列、Grace Hopper很多人以为UCIe就是“Chiplet的一切”其实UCIe更多是物理层和链路层的标准化让不同厂商的Die可以像USB设备一样互相连接。而CHI这类协议承担的是更上层的一致性逻辑。一个完整的Arm多Die系统往往是UCIe负责物理互连CHI和CXL负责更高层的协议和数据一致性。理解这一点看HotChips的架构图时会顺畅很多。3. 从HotChips资料里看到的主流多Die聚合路线3.1 路线一对称多Die直连统一地址空间对称多Die的方案是指封装里放多个计算能力完全相同的DieDie之间通过高带宽互连组成一个统一的地址空间。这种设计的好处是软件不用关心哪个Die上运行的核多一些整个CPU对外表现得更像一颗大核数芯片。在实际产品里这种方案常用于云厂商自研CPU或者大规模通用计算场景。它的问题在于当Die数量增加Die间的一致性协议开销会增长对互连带宽要求很高。如果互连带宽不够多线程性能可能不升反降。这也是为什么Arm在Neoverse系列中不断强调CMNCoherent Mesh Network这类互连IP的升级本质上就是为了让多Die调度更高效。3.2 路线二计算Die配IO Die把复杂度收敛到小范围这种方案在x86服务器CPU上很常见AMD的EPYC系列是典型代表。思路是把CPU核心放在一个或几个计算Die上把内存控制器、PCIe控制器、各种IO接口集中放到IO Die上。计算Die之间、计算Die和IO Die之间的通信走高速链路。好处很明显计算Die可以用更先进的工艺来压榨单核性能IO Die可以用相对成熟的工艺控制成本同时内存和PCIe通道的数量扩展变得非常灵活。Arm服务器CPU里也有产品在走这个思路。它的一个难点是如果IO Die的带宽和延迟设计不好会成为整颗CPU的性能瓶颈。3.3 路线三基础Die/桥接Die加UCIe面向开放的Chiplet生态再往后走就是更开放的Chiplet生态。一颗CPU封装里可以有来自不同厂商的计算Die、IO Die、加速器Die它们通过基础Die或者桥接Die完成互连。UCIe标准成熟后这种方案会越来越普遍。这个路线的优势是灵活性极高但也带来一个现实问题多厂商Die混搭后谁来定义一致性和安全边界谁来保证系统软件能统一管理短期内最成熟的还是单个厂商自研多Die但长期看开放Chiplet生态是行业趋势。3.4 三种路线的对照我把三种路线的关键差异整理成一个表方便团队内部评审时直接参考路线核心特征优势风险适合场景对称多Die统一地址空间多个同构计算Die软件适配简单扩展性强一致性开销高互连带宽要求高云实例、通用计算计算DieIO Die功能分DieIO集中成本控制好IO扩展灵活IO Die易成瓶颈Die间延迟敏感高密度服务器、存储、数据库基础DieUCIe开放生态多厂商混搭灵活度极高按需组合标准化还在推进系统复杂性高AI加速、异构计算、未来数据中心这个表不一定能覆盖所有产品细节但作为动手评估前的思维框架已经够用。我在给团队做技术分享时通常先给出这个表再让大家去查具体产品对应哪种路线这样去看HotChips资料就不会迷茫。4. 服务器商用价值良率、成本、功耗和配置自由度4.1 大晶圆良率不是“切开就能解决”讨论Chiplet成本时很多人有个误解单颗大Die良率低切小了良率就高所以多Die一定省钱。真实情况比这复杂。如果只是把固定面积的大芯片切成四个面积之和相同的小Die良率模型并不会明显变好。Chiplet真正的成本优势来自几个方向异构工艺计算Die用最新的5nm、4nm甚至3nmIO Die和内存控制器用相对成熟的工艺整体成本低于把所有东西都塞进先进工艺。已知好Die筛选每个小Die在封装前可以独立测试坏掉的部分能被提前淘汰不会把一整颗大芯片拖下水。配置组合灵活同一个小Die通过不同的搭配方式可以拼出不同核心数和功能的产品覆盖多个市场档位摊薄设计成本。所以“多Die省成本”不能简单理解成“良率变高了”而应理解成“每一分成本花得更有针对性”。4.2 云厂商为什么对多Die技术“上瘾”云厂商是Arm服务器CPU最大的推手之一AWS的Graviton系列就是典型例子。云厂商喜欢多Die架构核心原因是实例配置的自由度。云上卖的不是一颗CPU而是各种规格的虚拟机——2核、4核、8核、16核、32核、64核。如果一颗CPU是单Die大芯片规格切割只能依赖核心关闭的方式浪费晶体管和多核功耗多Die架构让云厂商可以更灵活地切分计算资源。另外多Die架构也方便把不同功能塞进同一个服务器平台。同一个封装里可以放CPU Die、AI加速Die、IO Die这样一台服务器既能跑通用计算也能跑特定工作负载资源利用率更高。对大规模数据中心来说这直接关系到每瓦性能和总拥有成本。4.3 功耗与散热多个Die不一样的发热曲线多Die对散热也有影响。以前一颗大Die的热量集中在一个点上散热器再强热点温度很难压住。多Die把计算核心分散在多个Die上热点更分散散热设计可以更均匀。但同时Die之间的高速互连是新增的功耗来源而且封装基板的散热路径变得更复杂。实际做整机设计时不能直接套用单Die CPU的散热方案。我在实测中遇到过一种情况同一台服务器单Die的Arm CPU温度分布比较集中换成多Die芯片后主板局部区域Die间互连带的温度明显偏高。如果散热器没有针对封装热图设计容易出现局部过热降频。所以选型时不光要看TDP数字还要看厂商给出的封装热阻和热分布图。5. 想把Arm服务器CPU真正用起来先过交叉编译和OS生态这几关5.1 交叉编译和“三套架构”的坑Arm服务器CPU运行的是aarch64指令集和x86_64完全不一样。绝大多数情况下你不能直接把x86上编译好的二进制拿到Arm服务器上跑必须获取源码在目标平台上编译或者使用交叉编译。这个话题的热度一直很高我打算把常见操作写清楚。最简单的交叉编译用例# 在x86的构建机上安装aarch64交叉编译工具链 sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu # 编译一个简单的测试程序 aarch64-linux-gnu-gcc -marcharmv8.2-afp16 -O2 -o hello hello.c # 用file命令确认产物架构 file hello # 输出一般是hello: ELF 64-bit LSB executable, ARM aarch64这里最容易踩的坑是-march参数。如果你的目标Arm服务器CPU支持SVE等新扩展但你编译时用的是基础armv8-a性能会差很多。反过来如果编译时启用了目标CPU不支持的扩展程序会在运行时触发非法指令。最稳妥的做法是先在目标机器上看/proc/cpuinfo或者用lscpu确认支持的特性再回去调整编译参数。5.2 让中间件跑起来Redis、Nginx、数据库的Arm版本现在很多主流中间件都提供官方arm64构建版本。比如Redis官方发布包和主流Linux发行版仓库里都有aarch64版本。你在Arm服务器上执行uname -m # 输出aarch64时确认当前是Arm架构 sudo dnf install redis # 或者 apt install redis-server redis-server --version如果系统启用了正确的软件源包管理器会自动安装aarch64的Redis。不要手动下载一个x86_64的RPM包强行安装那样基本装不上即使装上了也跑不起来。Nginx、MySQL、PostgreSQL这些也是一样的道理。因为这些中间件大多以源码形式分发编译时只要工具链和依赖库是aarch64编译产物就是arm64的。真正的坑往往不在这些大而全的中间件而在那些没有官方arm64预编译包的第三方扩展和工具库。比如某些需要C扩展的Python包在Arm服务器上执行pip install时可能需要本地编译缺依赖就报错。我曾经在生产环境遇到过一个服务代码在x86环境跑得好好的部署到Arm服务器后发现其中一个第三方库没有arm64的wheel包pip现场编译又缺gcc和头文件排查了半天。后来把构建依赖装齐才解决。这里建议团队在做Arm迁移前先跑一遍全量依赖清单标记出哪些包没有arm64预编译版本提前准备好编译环境。5.3 RPM、SSH升级和行业Linux发行版大部分主流Linux发行版都有完整的aarch64支持Ubuntu、Debian、openEuler、银河麒麟这些都提供Arm版本。如果你的服务器用的是银河麒麟这类面向行业场景的发行版升级SSH等基础组件时同样要特别注意包架构。打个比方你看到openssh-server-xxx.rpm这个安装包不看ARCH字段就下载结果系统是aarch64你下载了x86_64版本执行rpm -ivh会直接提示架构不匹配。正确做法是先确认系统架构再检查RPM包的架构# 确认系统架构 uname -m # aarch64 # 查看一个RPM包的架构信息 rpm -qip openssh-server-xxx.rpm | grep Architecture # Architecture: aarch64这类问题看起来小但在Arm服务器部署的早期特别常见。尤其是很多操作手册是从x86时代直接抄过来的不检查架构就下载安装包导致“升级失败”的假象。5.4 混合架构集群的日常运维现实中的数据中心很少完全抛弃x86大多数是Arm和x86混布。这种情况下运维比纯x86复杂不少。我建议至少做三件事所有物理节点打上架构标签不管是CMDB还是Kubernetes节点标签必须能一眼分清哪些节点是arm64。所有镜像构建使用多架构清单比如docker buildx build --platform linux/arm64,linux/amd64避免在集群里出现“有镜像但拉不下来”的情况。CI/CD流水线里增加arm64构建任务保证每次代码变更都有两套架构产物别等到上线前突然发现arm64镜像没构建。混合集群还有一个隐藏问题监控指标里如果混用了架构标签很多历史基线的对比会失真。比如x86节点的CPU idle在30%算正常Arm节点在50%也可能是正常。建议把架构作为监控标签单独统计别把两组数据揉在一起看。6. 采购和评估多Die Arm芯片时我习惯重点看这5个参数6.1 不要只看核数和主频先看互连带宽和一致性域很多采购清单第一行只写“XX核、YY线程、ZZ GHz”在多Die时代这是不够的。一颗128核的Arm CPU如果用4个Die组成每个Die 32核Die之间的互连带宽和一致性协议实现就非常关键。如果互连带宽设计不足跑跨Die多线程任务时性能会明显低于核数翻倍的理论预期。看芯片资料时重点看下面几个指标Die间互连总带宽、一致性域coherent domain的数量、跨Die访问延迟的典型值。这些参数在厂商的白皮书里不一定写得显眼但在HotChips演讲和芯片架构文档里通常能找到。6.2 内存通道和带宽不是只看DDR5频率服务器CPU的“八通道内存”和“十二通道内存”差距很大。多Die架构下内存控制器分布在不同Die上能不能让所有Die都完整访问所有内存会直接影响NUMA表现。我评估时习惯做一个内存带宽实测用Stream基准测试分别测单线程、全核访问、跨Die访问三种场景。很多问题在纯规格看不大出来一跑Stream就见分晓。另外如果目标场景对内存容量有硬性要求比如内存数据库或者大数据分析要特别注意CXL内存扩展的支持。CXL可以把内存池化缓解多Die架构下某些Die本地内存不足的问题但也要看CPU的CXL实现是否成熟。6.3 PCIe Lane数和IO扩展能力服务器CPU不只是算数更要接各种设备NVMe盘、GPU、网卡、加速卡。PCIe Lane数不够再强的计算能力也发挥不出来。多Die架构下PCIe控制器分布在IO Die或者专门Die上要确认所有PCIe Lane都能同时工作、互不干扰。现实里有些产品宣传PCIe 5.0 Lane很多但如果你把高速网卡和GPU同时插满某些Lane组会因为共享互连带宽降速。这就是我们常说的“规格性能和有效性能”的差距。最好找厂商要一份PCIe拓扑图或者在自己目标配置下实测带宽。6.4 基准测试拆分单核、单Die、跨Die、跨Socket选型时我最不看重的单一指标就是“CPU天梯图”上的总得分。天梯图适合给普通用户看不适合选型服务器CPU。原因很简单不同产品的多Die拓扑可能完全不一样总成绩掩盖了跨Die性能差异。我的建议是至少测四组数据单核性能看基础IPC和频率。单Die全核性能把进程绑在一个Die上。全封装多核性能让进程跑满所有Die。跨Socket性能模拟多路服务器场景。对比这四组数字能看出这颗CPU在多Die互连上做得好不好。如果全封装性能相比单Die性能没有线性增长那就要问一句Die间互连带宽是不是瓶颈6.5 NUMA拓扑和中断亲和性实测最后一步必须上机器实测NUMA拓扑。命令很简单lscpu -e # 查看每个CPU核心属于哪个NUMA节点 numactl --hardware # 查看可用内存节点和距离关系跑关键业务时建议把线程和内存通过numactl绑到同一个Die避免跨Die访问拉高延迟。例如numactl --cpunodebind0 --membind0 ./your_benchmark还有一种更极端的情况某些网络中断处理如果不做亲和性配置可能被分配到和网卡所在Die完全不同的核上导致收包延迟增加不少。这个在Arm服务器上并不少见调优时需要留意。7. 回到HotChips 2026资料怎么把会议资料转成团队能用的东西7.1 我建议按四个层次去整理资料HotChips资料确实值得被反复翻但直接丢给团队一大堆PDF没意义。我自己整理这类资料时会按四个层次拆第一层是“目标工作负载”也就是厂商这颗芯片为哪些场景优化——能效型云实例、AI推理、数据库还是网络吞吐。第二层是“架构拓扑”看它用了几个DieDie之间如何连接内存控制器和PCIe控制器在哪一侧。第三层是“互连与一致性”重点关注CHI、CXL、UCIe等协议的具体落地这是看清多Die能力的关键。第四层是“软件系统效应”也就是进入数据中心后怎么让操作系统、虚拟化、编译器发挥出它的特性。用这个框架去看HotChips 2026可能出现的Arm服务器CPU议题会很快发现每家厂商的差异化重点一是通信效率二是数据一致性三是生态适配。这些才是多Die技术最值得关注的价值点。7.2 团队分享时别把PPT念完就算完我的习惯是团队分享时不要贪多。一次只挑一个具体的Arm服务器CPU用上面四个层次讲清楚现场进行一场“架构师答辩式”的讨论。比如你看到一颗CPU用了计算Die加IO Die的路线就让大家想如果我的数据库业务对内存带宽特别敏感这个设计哪里好、哪里不适合我这种讨论比单纯看几十页PPT有效得多。分享前先把HotChips原始资料里涉及的关键指标抽象成一张A4纸列清楚产品名、技术路线、关键指标、和我们现有平台的差距然后让团队里每个人选择一个场景去评估。我们内部管这个叫“一小时架构对抗”效果还不错。7.3 我的资料追踪习惯和一个小建议给新接触Arm服务器CPU的人一个简单建议别只盯着新发布的产品重点看“上一年被吐槽的短板有没有被解决”。多Die技术在快速演进去年别人批评的是跨Die延迟高今年厂商可能就换了新的互连方案去年大家说生态不成熟今年主流发行版和中间件的arm64支持已经相当完善。用这个视角去看HotChips这类会议你会看到一条清晰的技术演进线而不是一堆孤立的新品发布。我自己的习惯是每次看完资料都会回到实际环境里做验证。光看架构图永远不知道一颗CPU好不好用把同一套业务负载跑在x86和Arm多Die机器上对比延迟分布和吞吐量心里才算有底。多Die技术的价值最终要落到“能不能在解决大规模问题的同时把功耗和成本控制住”上而这些只有在真实负载下才看得出来。