最近有两件事前后脚出现，放在一起看特别有意思。一边是全球头部的存储芯片厂商交出一份创纪录财报，单季营收站上500亿美元量级，几年之前这个数字几乎是天方夜谭；另一边是一家硅谷科技巨头把自己打磨多年的AI加速器核心开源了，连配套的软件工具链一起放了出来。表面上看，一个在卖存储，一个在做芯片和软件生态，井水不犯河水；但把两件事叠在一起，恰恰能看清AI基础设施眼下真正卡人的地方到底在哪。

我平时不太爱追着财报数字跑，但这次确实认真看了两圈，又结合团队里做模型部署的日常，越来越确认一个判断——AI基础设施存在两层硬瓶颈：第一层在硅片和存储器之间，业内常说的“内存墙”；第二层在芯片和开发者之间，也就是“生态墙”。这篇文章就把这两层瓶颈掰开揉碎讲清楚，也会聊聊普通工程团队在预算和人力都有限的情况下，能靠哪些具体动作把日子过下去。

1. 一份500亿美元财报，撞出第一层瓶颈：内存墙

1.1 存储从“卖库存”变成“卡脖子”，周期逻辑变了

存储芯片在过去二十年里是典型的周期行业。需求一旺，大家就疯狂扩产；扩产完供过于求，价格崩盘；崩盘后没人扩产，又慢慢供不应求。所以存储厂商的财报通常大起大落，投资者也早就习惯了。

但这一轮明显不一样。连续多个季度量价齐升，高带宽内存（HBM）被大模型训练和推理争抢，产能排到一年以后；连带着整条产业链上的先进封装、测试环节也跟着紧张。财报创纪录本身不是新闻，新闻是它背后的供需结构：AI算力对内存的需求，已经不是“多买几根内存条”能解决的，而是整个物理供应链都跟不上。当一个原本靠库存周转吃饭的行业突然变成“谁有货谁说了算”，这本身就是基础设施瓶颈最直接的信号。

1.2 内存墙怎么算出来的：700亿参数模型就是一面墙

业内聊“内存墙”聊了很多年，但大模型时代它终于变成了天天要面对的烦恼。想理解这堵墙，不用背术语，算一笔账就够了。

假设你手里是一个700亿参数的模型，权重用FP16保存，那么仅权重就需要约140GB显存。如果做推理，自回归解码的特点是每生成一个token，都要把全部权重从头到尾读一遍。想在单张加速卡上跑出每秒生成50个token，就需要内存带宽满足：

140GB × 50次/秒 = 7000GB/s，也就是7TB/s。

而目前主流加速卡的高带宽内存，带宽大约在3到5TB/s。这意味着单卡跑到50 token/s在物理上就过不去。要么上多卡并行，把权重拆开、让各卡分担读取量；要么做量化，把权重从FP16压到INT8甚至更低位，让每次读取的数据量直接减半、再减半。

训练侧就更加夸张。训练时显存里不只有权重，还有梯度、优化器状态和激活值。一个700亿参数的模型做全参数训练，单卡哪怕有80GB显存也远远不够，必须配合张量并行、流水线并行、数据并行和各类显存卸载技术，才能把训练塞进集群里。

所以内存墙从来不是单一维度的问题：容量不够，大模型装不下；容量够了的卡，带宽又顶不住高频读取；带宽够了，功耗又跟不上了。

1.3 比容量更麻烦的是数据搬运的“隐形电费”

很多人只把内存墙理解成“显存不够大”，其实功耗维度才是更隐蔽的杀手。芯片里做一次浮点运算消耗的能量，和从内存里搬一次数据消耗的能量相比，差了两个数量级。换句话说，AI计算的真正能耗大头不是“算”，而是“搬”。

加速卡要突破内存墙，只能在架构上想办法，比如把数据放到离计算单元更近的高速缓存里，但片上缓存容量有限，容不下动辄上百GB的模型权重；再比如把内存堆叠得更靠近芯片，HBM本身就是为了缩短物理距离而生的方案，但堆叠层数、良率、散热都有物理极限。

用一个生活化的类比：如果一个人上班路上80%的时间都花在挤电梯上，那他在工位上办公效率再高也没用。整个AI芯片行业现在的状态，就是大家都在想办法把“电梯”变得更宽更快，但电梯井的物理空间就那么大，预算和功耗也都卡在那。财报越亮眼，越说明这个供给缺口有多大。

2. 巨头开源的加速器核心，撕开第二层瓶颈：生态墙

2.1 开源一颗芯片，相当于把“半成品”展示给所有人

那边内存墙还没拆完，另一件事又来了：某科技巨头把自己研发多年的AI加速器核心连同配套软件栈一起开源。

硬件设计开源这件事本身不算新鲜，开源的指令集架构早就有了，但把一款成熟的商用加速器核心完全开放出来，意义不太一样。它相当于把自己最核心的“配方”公之于众，邀请所有开发者在这个基础上做二次开发。

可如果只把开源理解成“送芯片设计图”，那就看浅了。一颗芯片从点亮到能跑大模型，中间还隔着一整座软件栈：编译器要能把模型计算图映射到硬件指令，算子库要覆盖Transformer里各种常见算子，运行时要做内存管理和任务调度，调试工具要能回答“为什么性能上不去”这个问题。这些软件层面的工程量，往往比硬件设计本身还要大。巨头选择把它开源，本质上是在承认一件事：光靠一家公司，填不完所有生态的坑。

2.2 一张新加速卡要跑通主流模型，得闯五道关

我身边不少团队在评估新架构加速器的时候，都有一种“拿到手才发现真正的大工程在后面”的感觉。从一张新卡到模型稳定跑起来，至少要过五道关：

第一道，模型格式转换。主流深度学习框架训练出来的模型，要导出成目标硬件认识的中间格式。这个过程中会遇到各种奇奇怪怪的限制，某个算子的参数组合不被支持，整个图就导出失败。

第二道，算子映射。Transformer里到处都是矩阵乘法、归一化、注意力函数、激活函数。如果某个关键算子在新硬件的算子库里没有现成实现，就只能回退到CPU执行。CPU兜底的结果就是性能直接崩盘。

第三道，图编译。计算图进入编译器之后要经过算子融合、内存布局优化、内核选择。动态形状（比如变长输入序列）常常是这里的头号杀手，静态shape优化得好好的，一上动态就卡死。

第四道，精度对齐。混合精度下容易出现数值漂移，训练了几天突然发现loss曲线不正常，最后定位到某个算子的精度实现和原硬件不一致。

第五道，性能调优。模型跑起来只是起点，怎么把硬件的算力利用率从百分之十几拉到百分之五六十，这需要对着性能分析工具一点点抠。

这五道关每一关都可能消耗数周时间。很多团队拿到新卡后第一周基本都在折腾环境和工具链，模型本身反而没怎么看。这就是生态墙的现实：硬件再强，软件不顺手，就等于一块砖头。

2.3 开源不是做慈善，是生态战里最划算的投入

有人会问，这么核心的东西，为什么要开源？少赚授权费不说，还让竞争对手学走了。

我的看法是，开源的战略价值远大于保密价值。芯片不像软件可以快速迭代打补丁，它的价值高度依赖周边生态：有没有人愿意为它写编译器后端，有没有第三方框架愿意接进来，有没有开发者愿意在社区里答疑。如果什么都捂在自己手里，第三方没有动力适配，用户用起来处处受制，硬件的市场份额很快就见顶了。

开源是把适配门槛从“商业谈判”降到了“下载源码”，第三方框架、独立开发者、研究机构都可以低成本参与。人来得越多，生态越繁荣；生态越繁荣，硬件就越有吸引力。这和当年移动操作系统走开放路线、开源操作系统成为服务器主流是同一个逻辑。所谓“亏本买卖”，算的是未来十年的账。

3. 两层瓶颈不会单独出现，它们互相传导、彼此放大

3.1 模型参数在膨胀，内存带宽在爬坡，剪刀差越来越大

内存墙和生态墙不是两条平行线，它们会互相传导。

先看第一条传导链。大模型参数量在过去几年从十亿级冲到千亿级、万亿级，而内存带宽的年化提升只有百分之二三十。这个剪刀差导致一个结果：单位算力需要搬运的数据量越来越大。模型越“聪明”，对内存系统的要求就越苛刻，内存墙就更厚。

于是我们看到一个很有意思的行业现象：算力厂商拼命堆FLOPS，但用户在真实业务里感受到的性能提升并没有那么夸张。因为算力提升的很大一部分，都被数据搬运的代价吃掉了。就像给一辆车换了一台更大的发动机，结果变速箱和油箱还是原来的——油门踩到底，车速还是上不去。

3.2 硬件迭代按“月”算，软件成熟按“年”算，生态墙越垒越高

第二条传导链发生在硬件和软件之间。芯片架构基本是每年一代，快的甚至一年两代；但一套软件栈从“能用”到“好用”，往往需要三五年持续投入。新架构发布的时候，编译器、算子库、调试工具很难同步成熟。

结果就是“纸面性能”和“实测性能”的巨大落差。厂商roadmap上写着一个很漂亮的算力数字，但用户拿到手一跑真实模型，发现只有百分之三四十的利用率。这不是硬件造假，而是软件没有把硬件喂饱。

这种落差带来的连锁反应很实际：团队评估新架构时要预留更长的适配周期，项目排期就要往后拖；中小团队没有专职的底层优化人员，干脆继续用老架构。硬件再好，生态不跟上，就只能在少数大客户手里发挥价值。

3.3 扩产要时间，开源也要时间，短期别指望瓶颈自己消失

也有人说，存储大厂已经在扩产，科技巨头也开源了加速器核心，瓶颈是不是很快就会松开？

我的判断比较保守。存储扩产从建厂到稳定出货通常要两三年，新产能释放之前供需还是会紧；开源加速器核心虽然放出了设计图和工具链，但让社区真正用起来、把缺失的算子补齐、把文档和最佳实践攒起来，同样是以年为单位的事。

更关键的是，模型参数量还在往上走。瓶颈的绝对值并没有变小，只是大家开始正视它、给这个问题投入资源。对大多数从业者来说，眼下更重要的问题不是“瓶颈会不会消失”，而是“瓶颈还在的时候，我手里的任务怎么保质保量按时交付”。

4. 内存墙和生态墙都在，工程团队可以做的四件实事

4.1 选型时把内存带宽拔高到和算力同等重要的位置

很多团队选加速卡的时候，第一眼看FLOPS，第二眼看价格。我的建议是，把内存容量、带宽、功耗和软件成熟度也放进第一梯队指标。

我自己的习惯是，拿到一份新卡的参数表，先不算浮点，先算带宽和容量的组合够不够跑目标模型；如果带宽明显不够，那FLOPS再高也要打个大问号。

4.2 推理优化四板斧：量化、批处理、缓存、并行

在硬件层面无法突破内存墙的时候，软件和算法层面其实还有很大操作空间。我自己做推理调优时基本就是四板斧。

第一板斧是量化。700亿参数的模型用FP16要140GB，压到INT8只需要70GB，显存占用直接减半，内存带宽的需求也同步减半。配合KV Cache量化、激活量化，效果还能进一步放大。代价是精度损失和校准数据的维护，需要在实验里验证。

第二板斧是批处理。自回归解码的吞吐和batch size强相关。单条请求跑的利用率很低，把多路请求拼到一个batch里，权重读取一次能被多条请求复用，吞吐立刻上一个大台阶。现在主流推理引擎普遍支持连续批处理，不需要等整个batch结束，动态插队就可以。

第三板斧是缓存复用。KV Cache在多轮对话和长文档场景里占了相当大一块显存，也直接拉高带宽压力。合理管理KV Cache的生命周期、利用前缀命中复用早期Token的缓存，能显著降低无效读取。这里经常被忽略的坑是缓存策略和调度器的配合，处理不好反而引入额外开销。

第四板斧是并行切分。模型太大装不下一张卡，张量并行、流水线并行、数据并行各有适用场景。但并行不是免费的，卡间通信会反过来占用带宽资源。切分方案要和卡间互联的实际带宽匹配，否则并行收益会被通信开销吃干净。

这四板斧没有固定的执行顺序，通常的路线是先量化把模型塞进可用显存，再批处理冲吞吐，再用缓存优化抠延迟，最后用并行切分解决单机放不下的大模型。

4.3 评估新架构之前，先把软件栈检查清单过一遍

被生态墙坑过几次之后，我给自己团队定了一条规矩：评估任何新加速器，先给软件栈打分，再谈性能。

这套清单看起来基础，但能过滤掉大多数“看起来很美”的方案。我尤其看重调试工具：性能遇到问题时，如果工具链连“哪一段代码慢”都说不清楚，整个团队就只能黑盒调参。

4.4 监控体系从“看算力”升级到“看带宽和等待”

最后一个建议，是基础设施团队要做的事：监控体系不要只盯GPU利用率和显存占用，要把内存带宽利用率、通信占比、无效等待时间都纳进来。

排障的时候我习惯按三层来分析：第一层，看是不是数据搬运太慢——带宽利用率是否长期打满，是否有大量耗时花在读取参数上；第二层，看是不是计算内核本身不够快——某个算子是否长时间占用资源但吞吐上不去；第三层，看是不是通信和调度问题——多卡并行时卡间交互是否拖了后腿。

很多线上推理服务延迟升高，根因根本不在模型计算，而在KV Cache管理或者数据预处理的CPU瓶颈。没有这些监控数据，排查就只能靠猜。我之前帮一个团队定位推理慢的问题，兜兜转转好几天，最后发现瓶颈是内存分配策略导致频繁释放和重分配，而不是模型本身慢。这种问题如果监控指标齐全，半天就能定位。

回到开头那两件事。存储大厂财报创纪录，说明第一层物理瓶颈依然紧；巨头开源加速器核心，说明第二层生态瓶颈已经被所有人看清，并且开始有人下场补课。两件事合在一起，我的判断是：AI基础设施的瓶颈不会短期内消失，但行业的应对方向越来越清晰——硬件端想尽办法把数据搬得更快更省，软件端把适配成本一降再降。

我个人的体会是，越是在这种青黄不接的时期，越能看出一个团队的工程能力。那些能把现有硬件压榨到极限、能快速摸清新架构脾气的人，会比只会等下一代硬件的人走得远得多。下一步我准备找个时间把那个开源加速器核心的源码和工具链完整跑一遍，尤其想看看它在动态shape和混合并行上的真实表现。真要碰到值得写的内容，到时候再分享出来。