AI基础设施的双层瓶颈：从HBM存储到Arm开源软件栈的选型思考

前几天我同时看到了两个消息：一个是美光交出一份542亿美元营收规模的财报，另一个是谷歌把Axion相关软件栈往开源方向推了一大步。单看任何一个，都只是行业新闻，但放在一起，基本就把AI基础设施的两个层面摆到了台面上——底层硬件有瓶颈，上层软件也有瓶颈，而且这两层正在互相放大。

这篇文章想聊的，就是这两层瓶颈到底是什么、怎么形成的、对做AI训练和推理的人意味着什么，以及我在实际选型和落地过程中总结的一些经验。适合正在搭AI集群、准备采购硬件、或者评估开源方案的朋友参考，里面有原理也有实操，尽量说人话。

1. 美光542亿美元财报背后，是硬件层的“供给瓶颈”

1.1 从财报数字结构看AI存储需求的变化

先说美光这份财报。542亿美元这个量级，放在存储行业里属于相当醒目的数字。真正值得注意的不是总量，而是结构：数据中心相关的DRAM和NAND产品贡献了绝大部分增长，HBM（高带宽内存）更是被反复点名。

为什么会这样。AI训练集群里的GPU和加速器，本质上是一台台“喂数据”的机器，而数据要经过内存、存储介质才能进入计算单元。模型参数动辄几百亿、上千亿，显存装不下的部分要靠内存和存储来缓冲。所以AI越热，对DRAM的容量需求就越大，对HBM的带宽需求就更夸张。美光财报里那块增长最猛的业务，恰好就是整个AI基础设施里最紧缺的那一环。

另一个信号是DDR5渗透率的快速上升。AI推理服务器、云主机、甚至企业级数据库都开始批量转DDR5，但产能切换不是一夜之间完成的。旧产品还在退出，新产品供不上，这个空窗期内价格自然下不来。这不是某一家厂商的问题，是整个供应链从标准品向AI定制化产品转移的阵痛。

1.2 为什么说存储是“第一层瓶颈”

很多人一说AI基础设施瓶颈，先想到GPU缺货。但GPU只是瓶颈的入口，真正的“墙”，往往在存储。

可以从两个维度理解。第一个维度是带宽。假设你有一块A100或者H100，算力很强，但HBM的带宽是固定的，参数和中间结果必须流经内存才能进计算单元。如果数据过来得慢，GPU就只能等着。我习惯用厨师来类比：算力是灶台，存储是食材仓库，内存带宽是传菜口。灶台再多，传菜口只有一个小窗口，出菜速度照样上不去。

第二个维度是容量。大模型的KV Cache、训练日志、检查点文件，都极度吃存储空间。尤其在长序列推理场景下，KV Cache的增长是指数级的，你会发现GPU显存很快就满了，频繁被挤到DDR内存甚至NVMe盘上。一旦数据落到存储层，访问延迟会放大好几个数量级，整个系统的吞吐就垮了。所以存储层面一旦卡住，不是“慢一点”的问题，是可能直接把任务拖死。

1.3 财报透露的行业信号：谁在为瓶颈买单

看财报不能只看数字，要看钱从谁的口袋里掏出来。美光这一轮增长里，最大的买家是超大规模云厂商和AI算力租赁方，其次是大模型创业公司和传统企业里做AI改造的部门。

这些客户做的事情往往都是一样的：抢HBM产能、抢高端SSD、抢高密度内存条。于是我们看到一个现象——GPU采购周期已经够长了，现在连内存和存储也要提前预定。以前大家写采购方案，GPU到位了再看配套；现在反过来，存储供货周期可能比GPU还长，不能不考虑先锁产能。

对普通从业者来说，最直接的感受就是云实例涨价。云厂商把存储成本传导到实例价格里，训练和推理的成本预期就会被打乱。我自己的经验是，预算时至少留出20%的浮动空间给存储部分，否则机器到位了、存储不够，项目只能卡在原地。

2. 谷歌Axion开源：软件层的生态瓶颈，开始有人动手解了

2.1 Axion是什么，这次“开源”到底开源了什么

谷歌Axion是面向数据中心的Arm架构定制CPU，基于Neoverse V2核心设计，主打云原生和通用计算场景。所谓“谷歌AX开源”，更准确的说法是，谷歌把围绕Axion的软件栈、优化工具和适配方案逐步开放出来，让外部开发者可以在Arm CPU上更顺畅地跑AI负载和通用服务。

这里要澄清一个细节。芯片本身是一个硬件产品，真正决定它能不能用起来的是配套软件：操作系统适配、编译器优化、容器镜像、AI框架的支持、集群调度工具等等。Axion硬件再好，如果软件生态还像一座孤岛，别人就不敢碰。这次开源动作的核心价值，就是先把地基层的软件能力交出来，降低外部团队尝试和验证的门槛。

很多朋友看到“开源”两个字，第一反应是“代码免费了”。但这类基础设施级别的开源，代码从来不是重点，重点是它发出一个信号：这套硬件栈允许你深入研究、允许你自定义、允许你跟着社区一起修适配问题。这是一个生态从封闭走向协作的开始。

2.2 为什么软件生态是AI基础设施的第二层瓶颈

硬件层面的瓶颈很好理解，因为物理产能摆在那。但软件层的瓶颈往往更隐蔽，也更折磨人。

举一个很实际的例子。一个团队拿到了一批Arm服务器，第一周要干什么？不是跑模型，而是先折腾基础环境：操作系统版本能不能装、内核模块全不全、Docker能不能正常跑、PyTorch的Arm版本有没有预编译的wheel、GPU驱动和CUDA/ROCm之外的加速库能不能对上。这些工作在x86上几乎是顺理成章的，但在新架构上每一步都可能踩坑。

这就是第二层瓶颈的本质：算力、内存、存储这些硬件“买得到”，但让它们发挥出标称性能，需要大量的软件适配、算子优化和工具链开发。x86生态是几十年积累出来的，Arm服务器虽然在AWS、谷歌云里跑了很多年，但AI场景下的软件成熟度仍有差距。谷歌开放Axion生态，目的就是用开源的方式加速这段积累过程，让软件适配从“每个团队各自踩坑”变成“社区一起填坑”。

2.3 开源能改变什么，不能改变什么

开源这件事，能力和边界都要看清楚。它能改变的是信息不透明和适配成本过高的问题。比如一个优化算子如果发布了，其他人就不需要重复造轮子；一个已知的兼容性问题如果提交了issue，后来的人就能直接绕开。长期看，这种“经验外溢”会显著降低整个生态的使用成本。

但它不能改变什么呢？首先，它不能改变芯片产能和物理供应。Axion本身是云端的硬件产品，外部用户更多是基于这套软件栈去适配自己的Arm服务器，而不是去采购Axion芯片本身。其次，它不能压缩软件成熟需要的时间。哪怕代码全部开放，从“能跑”到“跑得好”，中间的稳定性验证、性能调优、生产环境检验，仍然需要按月甚至按年积累。

说白了，开源是一个“加速度”，不是“时光机”。它能缩短生态追平的时间，但不能跳过生态形成的过程。理解这一点，你就不会对任何一个开源项目产生不切实际的期待。

3. 两层瓶颈是连在一起的：算力买得到，系统跑不顺

3.1 硬件和软件的节奏，完全不在一个频率上

硬件瓶颈和软件瓶颈不是独立的，它们会互相纠缠。最直接的感受就是节奏错位：硬件供给是按季度、按年计的，某个型号的HBM寿命周期、某条DRAM产线的爬坡速度，都绑定在物理世界的规律上；而软件适配是按天、按周走的，社区提交一个PR、修复一个算子，可能只需要几天。

这就导致一个很尴尬的局面：你可能等存储等了半年，硬件终于到位了，结果软件栈还没适配好，集群跑不起来；又或者软件社区已经支持得很好，但硬件采购又被卡住，团队只能干等。我见过不少团队，把这两件事分开规划，结果项目上线时间被叠加延误，比单独一个大瓶颈更难受。

所以我认为，AI基础设施的整体规划，应该同时盯着两条时间线：一条是硬件产能和供货时间，另一条是软件生态的成熟度。前者看供应链，后者看开源社区的活跃度和版本发布节奏。只有两条时间线都能对得上，项目的交付时间才靠谱。

3.2 从一张采购清单看两层瓶颈如何同时发生

为了说清楚这个问题，我拿一个典型的中型推理集群来举例。假设你要部署一个支持数十路并发的大模型推理服务，核心硬件包括：若干块AI加速卡、配套的HBM或GDDR显存、大容量DDR内存、高速NVMe存储，以及换卡和组网用的网络设备。

看起来采购清单很简单，但落地过程会经历两个阶段。第一阶段叫“硬件等待期”。HBM被云厂商和大模型公司抢订，你排到货可能要到下个季度，DDR5和高端SSD也在涨价，预算需要反复调整。第二阶段叫“软件踩坑期”。机器到了以后，你要做容器化、跑推理框架、做性能调优。如果你的加速卡不是最常见的型号，或者你选了Arm架构的CPU，算子兼容和编译问题能花掉你意外的两周时间。

换句话说，大部分AI项目的延误，都不是某一个“大坑”造成的，而是硬件、软件两层瓶颈交替出现，每一层都拖一点时间，最后汇总成一个很难看的交付日期。

3.3 成本与效率的真实账本

除了时间，还要看钱。很多团队爱算一次性采购成本，忽略长期运行成本。我来列一个比较常见的成本结构：

这里我想特别提醒一项：软件适配的人力成本，往往被严重低估。硬件选型还能通过各种跑分横向对比，但软件适配很难提前量化。一个团队如果对Arm服务器没有经验，前两个月基本就是在交学费。这不是说不能选新架构，而是说要把这部分成本写进项目的财务模型里，而不是默认它为零。

4. AI基础设施选型的几条实操建议

4.1 内存和存储，别只看容量

很多采购清单里写存储，只写“多少T”，这是不对的。AI负载对存储的要求，不只是装得下，更要读得快、写得动。你可以按这几个维度去评估：

• 内存带宽：每块GPU配套的HBM带宽是多少，CPU侧的内存通道数和频率够不够支撑数据预处理。
• 存储IOPS：训练时要频繁读取训练样本和写检查点，随机读写能力和顺序读写能力差别很大。
• 延迟稳定性：推理服务对P99延迟敏感，存储的毛刺会导致整个服务超时。

我建议在采购前，用你真实的数据集和模型做一轮压测，而不是直接看厂商给的标称值。标称带宽和实际吞吐之间，往往差了一个“碎片化读写”的距离。实测结果才是写预算和报表的真正依据。

4.2 软件栈优先选“可迁移”的

如果你在评估Arm服务器或者任何非x86架构的AI硬件，软件栈的可迁移性应该放在比峰值性能更高的优先级。

怎么评估可迁移性？看几件事：主流的AI框架在这个架构上有没有官方或者社区维护的预编译版本；容器镜像能不能直接跑，还是要重新构建；常用的性能分析工具能不能正常抓取Profile数据；分布式通信库在这个架构下表现如何。

以我接触过的一些项目为例，PyTorch和JAX在Arm架构上的支持已经比以前好很多，但一些偏门库仍然只提供x86的二进制，需要自己源码编译。编译本身不是不行，但它会引入工具链版本不一致、依赖冲突等一系列连锁问题，建议你在POC阶段就把这几件事跑一遍，不要等到生产环境再发现。

4.3 开源方案评估的三个常见坑

这个部分是我最想写的，因为开源方案虽然好，但坑也不少。第一个坑是“文档快于代码”。有些项目的README写得非常漂亮，Star数也高，但实际拉下来发现功能不完整，文档里描述的能力还在开发中。评估的时候不要只看文档，要去看最近的commit和release记录，判断项目是不是处于活跃开发状态。

第二个坑是许可证问题。不同开源协议对商用、修改和分发的要求差异很大。如果没有法务资源，至少要把核心依赖的许可证列个清单，别等产品上线了再被翻出来。这里没有“哪个协议更好”的通用答案，只有“哪个协议更适合你的使用方式”。

第三个坑是维护者断档。很多不错的开源项目，核心维护者只有一两个人，一旦他们忙不过来，项目就可能陷入停滞。我个人的习惯是看三个信号：最近的commit是不是持续在增长，issue的平均响应时间是多长，以及有没有除作者以外的活跃贡献者。这三个信号比Star数和下载量更能反映项目的真实健康度。

4.4 我踩过的具体问题记录

讲几个我实际遇到的案例，都是很小但很典型的问题。有一次我在Arm架构服务器上部署推理服务，发现一个常用的数据处理库只支持x86的轮子，源码编译又因为缺少某个旧版依赖而反复失败。最后解决方案不是硬刚，而是换了一个功能相似但支持更好的替代库，代价是改了十几处调用代码。这件事给我的启发是：在新生态里，“临时换库”比“强行编译”更省时间。

还有一次，集群里某个监控组件在x86上跑得好好的，换到Arm上直接编译不过。我到GitHub issue翻了一圈才发现是已知问题，社区已经有人提了补丁，只是还没合并进主分支。这种问题不是技术难题，纯粹需要耐心和检索能力。如果你也在评估非x86架构，请预留至少一到两周的“软件适配缓冲期”，这是相当务实的预期管理。

5. 一点点个人体会

聊到最后，说一点我自己的体会。AI基础设施的硬件瓶颈，本质是物理世界的产能问题，短期很难绕过；而软件瓶颈，本质是协作生态的成熟问题，开源是当下最有效的解法。美光和谷歌这两个消息放在一起，恰恰说明这两层瓶颈正在被市场和技术同步看到，也同步去解决。

如果你也在做类似的选型和规划，最后再分享一个实用的小技巧：在采购需求书里，不要把“跑通”作为验收标准，要把“在目标架构上完成性能验证、并走通完整部署流程”写进去。性能测试分数和实际生产环境的差距，远比大多数人想象的大。把生态迁移成本提前写进需求，后续的执行会顺畅很多。