企业官网建设流程全解析

你有没有遇到过这种情况：手里拿着一块标称几百TOPS甚至上千TOPS算力的AI芯片，结果跑起真实模型来，利用率连标称值的10%都不到。厂商没有虚标，代码也没有写错，真正的瓶颈往往不在计算单元本身，而是数据从内存搬到芯片内部这条路上堵死了。这就是AI芯片领域老生常谈却又绕不开的问题——存储层次（Memory Hierarchy）与内存墙（Memory Wall）。

最近很多人问我要怎么看AI芯片的规格书，为什么有的芯片算力不高但实际跑模型很强，有的芯片算力标得吓人却一跑就露馅。我通常都会先让他们放下算力数字，去看两样东西：片上存储有多大、片外带宽有多高。这篇文章我打算把AI芯片的存储层次设计思路、内存墙问题的本质、业界主流破局方案，以及我自己在实际项目中遇到的瓶颈定位方法一次讲清楚。内容会涉及一点量化算例，但保证不堆公式、不抄课本，适合正在做AI芯片选型、算子优化，或者想深入理解AI硬件底层的朋友阅读。

1. 为什么AI芯片会被“饿死”：内存墙到底是什么

1.1 一个芯片性能的“木桶理论”

先打个比方。把AI芯片想象成一个大型中央厨房，计算单元是大厨们，内存是仓库。大厨们炒菜再快，如果食材只能靠一个人推着平板车一趟一趟从仓库运过来，那整家店的出菜速度就被这辆平板车卡死了。厨房里能临时放食材的台面越大、推车运货越快，大厨们才越不容易空等。

AI芯片里的“大厨”是成千上万个乘加单元（MAC Array），“仓库”是片外的DRAM（比如HBM或DDR），“台面”是芯片内部的SRAM缓存和寄存器文件，“平板车”就是内存总线。很多时候我们只盯着“多少个大厨”看，也就是TOPS算力，却忘了问一句：食材运得过来吗？这就是内存墙问题的本质：计算能力增长太快，而内存带宽和容量的增长远远跟不上，导致系统整体性能被数据搬运锁死。

我在评估一款芯片时有个习惯，先粗略算一个数：芯片算力除以片外带宽。如果这个值很大，意味着芯片平均每秒钟需要处理的数据量非常惊人，而内存根本喂不饱它。这样的芯片在跑很多真实模型时，算力利用率都不会太好看。这不是芯片厂商设计失误，而是物理规律决定了在成本、面积、功耗的约束下，带宽不可能无限做大。

1.2 内存墙的本质：算力和带宽的剪刀差

内存墙这个词最早可以追溯到几十年前的计算体系结构研究，描述的是CPU时代就存在的矛盾：处理器性能每年提升百分之几十甚至翻倍，但内存带宽每年只增长百分之二三十，两者之间拉开了一条无法填平的鸿沟。到了AI计算时代，这个问题不但没有缓解，反而因为计算单元的并行规模被拉满而更加尖锐。

为什么AI芯片尤其吃亏？因为CPU时代还有很多应用是不那么依赖数据的，计算相对密集；但AI模型，特别是深度学习模型，本质上是数据密集型计算。一个卷积层要把输入特征图和权重从内存里搬进芯片，算完再把输出写回内存；一个Transformer模型更是每算一个token都要把几乎全部权重从头到尾读一遍。计算量增加了，访存量也跟着涨，但内存系统的发展速度跟不上计算阵列的发展速度。

有一个很直观的量化方式。假设某芯片算力是1000 TOPS（1e15次浮点运算每秒），片外内存带宽是2 TB/s（2e12字节每秒），那么芯片要求每个字节的数据至少要被重复利用500次（1000e12 / 2e12 = 500 FLOP/Byte），才能让计算单元不空转。这在很多算子身上根本做不到。后面我会专门讲这个算术强度的问题，并给出具体算例，现在先记住这个结论：内存墙的本质是，单个数据字节被重复利用的次数不够多，导致带宽成为系统吞吐的真正天花板。

2. AI芯片的存储层次：从寄存器到SSD的分工体系

2.1 存储层次如何分层：每一次降级都在牺牲速度换容量

AI芯片内部不会只有一级存储，而是按照“离计算单元越近越快、但容量越贵越小”的原则，构建出一整套金字塔结构。参考图如下（文字版）：

• 寄存器文件（Register File）：最靠近乘加单元，容量只有KB级别，访问延迟约1个周期，通常只能缓存正在计算的少数操作数和中间结果。
• 片上SRAM / 各级缓存：容量从几MB到几十MB不等，延迟从几个周期到几十个周期。在AI芯片里，这块通常叫片上缓冲区、Local Memory或SMEM，是数据复用、算子融合的主战场。
• 片外DRAM（HBM / DDR）：容量从几十GB到上百GB，但延迟已经到几百纳秒，带宽虽然比DDR时代强很多，但与片上SRAM相比仍是数量级的差距。
• 非易失存储（SSD）：容量可以到TB级别，但延迟在微秒到毫秒级，带宽只有几GB/s到十几GB/s。通常只做冷数据或者超大模型的权重复载，不会进入实时计算主路径。

每一级往下，容量变大、成本变低，但延迟和带宽都在恶化。CPU的缓存体系大家很熟悉，AI芯片的存储层次逻辑类似，但侧重点很不一样。CPU缓存强调的是随机访问性能，要应付各种程序分支和不确定性；AI芯片的存储调度则是高度可预测的，因为模型的计算流程和数据访问模式是编译期就能基本确定的，所以AI芯片的片上存储更多被设计成“显式管理的缓冲区”，而不是依赖硬件自动命中的缓存。

设计上的一个常见误区是试图把CPU那套复杂缓存逻辑直接搬到AI芯片上。AI计算的特点是规则的数据复用，你提前知道某个权重会被用多少次、某个输入特征图会在哪些位置被重复读取，所以完全可以在编译期规划好数据在片上怎么流转。用硬件自动缓存去猜数据访问模式，反而浪费面积和功耗。

2.2 关键指标与典型参数：容量、带宽、延迟

拿当前主流芯片举个例子，把不同层级的关键参数摆在一起看，存储层次的代价差异会非常清楚：

这里必须说明，具体数值会随工艺、架构和产品代际变化，但数量级差异是稳定的。一个特别值得注意的点是能效差异：从SRAM里读一次数据，比从DRAM里读一次数据省电一个数量级以上。而在AI芯片里，数据搬运消耗的能量往往比计算本身还高。我之前翻过一些功耗分析报告，很多算子跑下来，DRAM访问占掉的功耗比例惊人，远超MAC阵列。所以存储层次设计不仅影响性能，还直接决定芯片的能效表现。

HBM的延迟其实不低，和DDR差不多，都是几百纳秒量级，只是带宽做上来了。很多人误以为HBM是“低延迟”内存，其实它主打的是高带宽，延迟并没有本质突破。这也解释了为什么不能频繁依赖HBM做细粒度随机访问，必须靠片上缓存做数据聚合和复用。

2.3 AI芯片存储层次和CPU缓存的关键差异：不要照搬CPU那套

CPU的缓存体系经过几十年发展，已经非常成熟，但AI芯片不能简单照搬。区别至少有三点。

第一，访问模式的可预测性不同。CPU程序分支多、数据依赖随机，缓存靠硬件策略动态预测和替换；AI模型的计算图是静态的，每个算子读写哪些数据在编译期就能精确分析出来，因此很多AI芯片会把SRAM做成软件显式管理的缓冲区，让编译器分配数据块，避免硬件缓存命中率的不确定性。

第二，数据复用的维度不同。CPU缓存关注的空间和时间局部性比较泛化，一个数组元素被用几次难以精确推导；AI芯片关心的是卷积的滑动窗口复用、Transformer里注意力矩阵的分块复用，这些复用关系可以用数学精确建模，从而指导数据流编排。

第三，并行访问的规模不同。AI芯片动辄成百上千个计算单元同时工作，如果所有计算单元都去访问一个共享缓存，带宽和仲裁都是噩梦。所以现代AI芯片的片上存储往往是分布式的，每个计算簇有自己私有的SRAM，再向上挂一个共享的L2，形成两层甚至三层的片上存储结构。这比CPU那种多核共享L3的方案更强调“物理隔离+受控通信”。

早年我在评估一款边缘AI芯片时，发现它的L2缓存命中率高达95%以上，但算子性能依然很差。后来仔细看才发现，它的L2是多个计算簇共享的，带宽仲裁机制太弱，高命中率掩盖不了实际访存的拥塞。这个案例让我形成了条件反射：看AI芯片缓存，不能只看命中率，更要看片上存储带宽能够支持多少个计算簇同时吞吐。

3. 透过数据流看存储设计：为什么卷积和Transformer的存储需求不一样

3.1 数据复用是存储层次的灵魂

缓存容量再大，也装不下几十GB的模型权重；带宽再高，也架不住所有数据都从HBM读。存储层次能否发挥作用，核心就看一件事：数据能不能在片上被反复利用。

卷积算子是最典型的高复用场景。假设输入特征图是H×W×C，卷积核是K×K，输出通道数是M，计算量是2×H×W×M×K×K×C次浮点运算。而访问量主要来自三部分：输入特征图（H×W×C）、权重（K×K×C×M）和输出特征图（H×W×M）。因为每一组输出像素都是由同一个输入区域和同一组权重计算得到的，这些数据天然具备时间和空间局部性。如果分块策略得当，把一小块输入特征图和一小组权重先搬进SRAM，反复算完它们对应的所有输出，就能极大减少对片外内存的访问。这也是为什么卷积网络在传统GPU上比很多逐元素算子跑得高效得多。

Transformer和卷积很不一样。大模型的核心算子是GEMM（通用矩阵乘法），比如QKV投影、MLP全连接。GEMM的权重复用取决于batch size：batch越大，同一个权重矩阵会被多个输入样本复用，算术强度就越高。但到了自回归推理的decode阶段，batch size往往很小，极端情况batch=1时，每个权重数据只被使用一两次，几乎没有复用机会，内存带宽立刻成为瓶颈。这块后面我专门展开算一笔账。

3.2 典型数据流策略：权重固定、输入固定、输出固定

既然片上存储容量有限，那么在编排数据流时，就要决定哪一份数据是“待在原地不动的”，其他数据围绕它流转。学术界有一篇很有名的Eyeriss研究，把常见AI芯片数据流分成了三类：

• 权重固定（Weight Stationary，WS）：权重存放在各个计算单元本地的寄存器或SRAM里，输入激活数据在计算阵列中流动。这种方式适合卷积核复用，因为权重可以在一个batch里反复使用，不过输入激活的广播压力比较大。很多脉动阵列架构，比如Google TPU，就是这种思想的代表。

• 输出固定（Output Stationary，OS）：每个计算单元负责累积某个输出像素或输出块的部分和，权重和输入激活流经计算单元。这样输出数据不用频繁写回内存，适合输出特征图比较大、需要反复累加的场景。

• 输入固定（Input Stationary，IS）：输入特征图固定在计算单元里，权重数据流动。这种方式更适用于某些深度可分离卷积或者输入复用度极高的场景，但权重的广播压力会比较大。

实际商业芯片极少纯用某一种数据流，大多是混合策略。比如面向CNN的NPU，通常会吸收WS和OS的优点，根据不同的层配置不同的数据流转方式。这块设计深了就是一门大工程，但作为应用开发者，至少要知道一个道理：同一个算子，在不同数据流策略下，访存量可能差好几倍。这也是为什么有些芯片跑卷积很强、跑Transformer却很一般的深层原因之一，因为数据流策略与目标模型的匹配度不够。

3.3 Roofline模型：判断一个算子到底是算力受限还是带宽受限

做AI芯片性能分析，绕不开Roofline模型。它本质上是一张二维图：横轴是算术强度（每读一个字节数据，能做多少次浮点运算），纵轴是可达性能。实际应用的峰值性能，不可能超过“算力上限”和“带宽上限”两条线中的较低者。

举个例子。一块芯片FP16算力312 TFLOPS，片外带宽1.6 TB/s，那么它的拐点算术强度就是312e12 / 1.6e12 ≈ 195 FLOP/Byte。意思是：只有当你的算子每读入1字节数据至少能算195次浮点运算，计算单元才可能被喂饱；低于这个值，芯片就跑在带宽受限区，算力再高也白搭。

对照一下真实算子：优化良好的大矩阵乘法（GEMM）通过分块，算术强度能做到几百甚至上千FLOP/Byte，可以落在算力受限区；但很多逐元素操作（ReLU、LayerNorm、Softmax、加残差）算术强度往往只有个位数，属于极度内存受限。这解释了为什么你在GPU上跑一个包含大量逐元素算子的模型时，GPU利用率怎么调都上不去，因为这类算子本质是在“搬运数据”，不是在“计算”。

Roofline模型最大的价值在于：在优化前先用数学算清楚瓶颈在哪，而不是盲目调优。我以前犯过一个错误，看到一个自定义算子慢，就疯狂优化计算逻辑，结果一点效果没有。后来用Roofline一算，发现它明明躺在带宽受限区，真正该做的是减少访存量，比如做算子融合或数据格式优化。这个认知转换帮我省了大量无用功。

4. 打破内存墙的主流工程方案

4.1 把缓存做大：SRAM堆料派的思路

既然片外带宽是瓶颈，一个最直接的思路就是把能装数据的“台面”做大，让更多数据留在芯片内部。这就是SRAM堆料派的逻辑：把几十MB甚至上百MB的SRAM直接集成到芯片上，让模型权重和中间激活尽量在片上完成流转。

英伟达从A100到H100，L2缓存从40MB加到了50MB，别小看这点增量，对于某些访存模式它直接决定了能不能把关键热数据留在片上。更极端的例子是Cerebras，他们家的WSE系列直接把片上SRAM堆到了40GB以上，相当于是把一个大得多的“缓存”和计算阵列做在同一块晶圆上，片外DRAM的依赖被大幅降低。Graphcore的IPU也是类似思路，片上有数百MB的SRAM（超过900MB），通过大量片上存储来支撑MLIR模型的数据复用。

但堆SRAM不是没有代价。SRAM密度低、面积大、漏电功耗高，同样的硅片面积，做SRAM能装的比特数远少于DRAM。芯片成本、良率和散热都会被拖累。所以这不是一条无限可走的路线，SRAM应该给那些被高频访问、复用度高的数据，而容量大但复用度低的数据还是该放DRAM。

4.2 把带宽做大：从DDR到HBM

同一时间能搬多少数据，取决于总线位宽和频率。DDR内存位宽通常在64bit左右，带宽几十GB/s，对AI芯片来说远远不够。HBM的思路是用硅通孔把多层DRAM堆叠起来，同时把位宽做到1024bit以上，从而把带宽推到TB/s级别。

最近几代AI芯片几乎都标配HBM：A100搭载HBM2e，带宽约1.6TB/s；H100升级到HBM3，带宽约3.35TB/s；H200用上HBM3e，带宽更是到了4.8TB/s。带宽的数字确实在涨，但依然赶不上人们对算力的胃口。而且HBM的成本非常高，还要搭配先进封装，一颗芯片的成本大头常常就是HBM部分。所以“把带宽做大”这条路，对大多数人来说只看别人家的产品很爽，自己做的时候钱包很痛。

我在选择边缘设备时有一个经验：如果模型以CNN为主，DDR级别的带宽配合好的片上调度，通常也够用；但如果要跑大语言模型，哪怕只是7B级别，也尽量选带LPDDR5高带宽版本甚至专用NPU，否则decode速度会慢到让人怀疑人生。

4.3 把数据变小：量化与稀疏化

与其拼命把硬件做大，不如把数据本身变小。量化就是把权重和激活从FP32/FP16压到INT8、INT4甚至更低精度。精度降低后，总访存量直接成比例下降，内存墙的压力也就小了一大截。

这里有个容易忽略的点：量化带来的速度提升，很多时候不是算力提升导致的，而是带宽压力降低导致的。INT8在GPU上有专门的Tensor Core加速，INT8算力是FP16的两倍，但模型跑起来变快，相当一部分功劳来自访存减半。INT4权重量化（如GPTQ、AWQ这些方法）在大模型推理中能换来接近两倍到四倍的解码速度提升，核心逻辑就是把权重体积压缩，让同一片带宽能搬运更多有效参数。

稀疏化是另一条路。如果权重矩阵有一半是0，理论上就有一半的访存和计算是浪费的。但稀疏化的落地难度在于“非结构化稀疏”，零散分布的0很难被硬件高效利用，所以英伟达从Ampere架构开始力推2:4结构化稀疏，也就是每四个连续权重里强制恰好两个为0，硬件可以直接跳过一半的权重读取和计算。我在实际项目里做剪枝时踩过坑，盲目剪枝后的模型虽然稀疏度很高，但硬件不支持，速度纹丝不动。要让稀疏化真正减负，得顺着硬件的结构化模式去设计剪枝方法，而不是先剪完再指望硬件自适应。

4.4 把计算挪到数据边上：近存计算与存内计算

既然把数据搬到计算单元旁边很贵，那就把计算挪到数据所在的地方去。近存计算（Processing Near Memory）把计算逻辑和DRAM做在同一个封装里，减少数据搬运距离；存内计算（Processing In Memory）更进一步，直接让存储单元参与一些加减乘运算，数据压根不用搬出来。

这几年HBM-PIM、存内计算芯片都是研究热点，本质都是在和内存墙正面对抗。三星、SK海力士等厂商都在推进相关产品，一些初创公司也拿存内计算做AI推理加速，尤其在做大模型推理时显得很有想象力。不过这个方向目前还面临不少工程问题：存储单元里做计算，精度怎么保证？编程模型怎么设计？编译器怎么把算子映射进去？我在和一些做存算一体芯片的同行交流时，大家的共识是：存内计算对特定简单算子有奇效，但要承接完整的AI模型生态，路还很长。

4.5 算子融合与流水线重叠：系统层面的优化

很多时候内存墙不是芯片硬件问题，而是软件没把数据流转安排好。算子融合就是把多个算子的计算合并到一个kernel里执行，让中间结果留在片上SRAM或寄存器里，不经过片外内存的读写。比如把卷积后的批归一化和ReLU融合进卷积kernel，把ResNet的残差加也融合进去，能省掉好几次几十GB甚至上百GB的片外写入。

FlashAttention是这个思想的极致体现，它通过分块计算，把N×N的注意力分数矩阵永远维持在SRAM级别，而不是完整写到HBM里再读回来。对于长序列Transformer，这个优化能把访存量降低一个数量级甚至更多。类似的技巧包括kernel的自动融合、CUDA Graph捕获等，本质上都是让“计算与搬数据”的流水线重叠，尽量不让芯片等内存。

做AI芯片和应用开发的人，如果能熟练掌握算子融合和内存规划的思路，在绝大多数场景下能带来比换更强硬件更明显的收益。我在优化一个视觉模型时，光是把相邻的五个小算子融合成一个，推理延迟就掉了接近三成，而那块芯片硬件本身没有任何改动。

5. 实操中如何定位内存墙瓶颈：一个四步排查法

5.1 第一步：用Profile工具看DRAM吞吐和算力吞吐

在真正的硬件上定位内存墙，第一步不是猜，而是测。以NVIDIA环境为例，Nsight Compute里有一个很直观的工作负载分析视图，可以看到当前kernel的SM（Streaming Multiprocessor）吞吐和DRAM吞吐。如果DRAM Throughput长期维持在90%以上，而SM Throughput只有百分之三四十，那这个kernel就是典型的带宽受限，你把计算流水线优化得再漂亮也没用。

我给不少团队做过性能排查，很多人上来就贴代码问“为什么这么慢”，我一般都是先让他们跑一下profiling，把每个算子的时间占比和内存吞吐截图发我。很多时候结论一眼就能看出来：慢的算子全部躺在带宽受限区，优化的方向应该是减少访存，而不是加快计算。这一步说起来简单，但能坚持做的团队真的不多，太多人靠直觉优化，结果事倍功半。

5.2 第二步：核算目标算子的算术强度

看到了内存吞吐很高，接下来就要算清楚“为什么会这样”。把目标算子的FLOPs除以它实际从片外内存读写的数据量，得到算术强度，再和芯片的拐点值对比。

这里写个简单Python表达式，方便大家复现计算：

# 估算算子的算术强度并判断瓶颈 flops = 2 * batch * seq_len * hidden_size * (4 * hidden_size) # 比如一个Transformer MLP块的GEMM bytes_moved = (权重参数量 + 激活读写量) * 字节数/参数 arithmetic_intensity = flops / bytes_moved # FLOP/Byte peak_flops = 312e12 # 按A100 FP16稠密算力估算 peak_bandwidth = 1.6e12 # 按A100 HBM带宽估算 ridge_point = peak_flops / peak_bandwidth # 约195 FLOP/Byte if arithmetic_intensity < ridge_point: print(f"带宽受限，算术强度={arithmetic_intensity:.2f} FLOP/Byte") else: print(f"算力受限，算术强度={arithmetic_intensity:.2f} FLOP/Byte")

这段代码不是完整工程，但思路是对的。我想强调一个细节：算术强度要用真实访存量来算，而不是理论最小值。很多核心里有地址计算、数据格式转换、未融合的中间张量，实际搬到片外的数据量会远大于你预期的“最小必要量”。这也是为什么同样一个GEMM，有人能写到300 FLOP/Byte，有人只能写30。

5.3 第三步：对照算例看大模型推理的内存墙

我用一个非常经典的大模型推理场景来说明这个排查法。一个70B参数的模型，如果用FP16存权重，参数量是70×10^9个，每个参数占2字节，那么光权重就需要140GB。假设芯片是H100，HBM带宽3.35TB/s，理论上读取一遍全部权重需要140GB / 3.35TB/s ≈ 42毫秒，反向换算过来，生成一个token的上限就是1 / 0.042 ≈ 24 tokens/s左右。

你看看这个数字，H100的FP16稠密算力接近1000 TFLOPS，但跑70B模型decode时，如果不做量化、不用大batch，它能发挥的算力连1%都不到。因为decode阶段每个token都要读一遍全部权重，算术强度就只有2 FLOP/Byte左右，离A100/H100的Roofline拐点差一两个数量级。这可能是目前现实生活中最直观、也最昂贵的“内存墙”现场。

如果换成INT4量化，权重体积降到约40GB，理想情况下decode速度上限能提高到80多tokens/s，这就是为什么大模型部署几乎必配量化。它不是把模型“算得更准”或“算得更快”，而是把数据体积压下来，让内存墙后移。理解了这一点，你在做推理服务选型和调优时，思路会清晰很多。

5.4 第四步：确定优化路径，不要盲目堆硬件

定位到内存墙之后，优化路径就分三类：一是提高数据复用，比如调大batch size、做算子融合、优化访存顺序，让同一批数据在片上多算几次；二是减少数据体积，比如量化、剪枝、蒸馏；三是改造数据流策略，把访存模式改成分块友好型，避免随机访问小块数据。三步都做完仍然不够，再考虑换更高带宽的硬件。

我特别想提醒的是，在带宽受限场景下换“算力更强”的芯片往往没有意义。比如你跑一个小batch的Transformer推理，瓶颈在HBM带宽，从A100（1.6TB/s）换到H100（3.35TB/s）确实有提升，但如果换一块算力翻倍但带宽只涨一点的芯片，提升就非常有限。所以在选型时，我会把目标模型的关键场景跑一遍或估算一遍，确定它是算力受限还是带宽受限，再决定预算往哪放。

5.5 一个容易忽略的坑：缓存命中率高不等于没有内存墙

前面提到过，很多AI芯片会汇报缓存命中率，但命中率高不代表性能好。原因在于，缓存命中率衡量的是“有多少次访问被片上存储接住了”，但它不区分这些访问是请求了1个字节还是请求了一整块连续数据。如果代码在缓存里反复命中一个很小的数据块，命中率接近100%，但实际有价值的有效数据吞吐只有一点点，算力照样被荒废。

我在排查一个自研NPU算子时遇到过类似的情况：L2命中率99%，kernel却慢得离谱。后来发现是数据布局导致每个计算单元都在争抢同一段SRAM的同一块缓存行，形成了伪共享式的片上拥塞。命中了，但没完全命中，数据在缓存里被反复搬运。所以真正要盯的指标应该是“有效数据吞吐”和“带宽利用率”，而不是单纯的命中率。

6. 一些思维工具与个人体会

聊了一路存储层次和内存墙，如果想在工作中快速应用，我个人最推荐两个思维习惯。

第一个习惯是“先用Roofline模型框定瓶颈，再动手优化”。这听起来像常识，但实际执行中很少人做到。我曾经帮朋友调一个视频理解的3D卷积模型，模型在GPU上利用率只有15%，大家的直觉是要不要拆掉重写算子。我算了一下算术强度之后发现，问题出在数据排列让访存变成碎片化的小块请求，带宽利用率极低，根本不是算子本身的问题。后来只是调整了输入数据的分块和通道排布，就把整体推理速度拉起来了一倍多。这件事给我的启发是：不先算清楚瓶颈，再努力也是盲人摸象。

第二个习惯是“把数据搬运的成本刻在脑子里”。在AI芯片设计或者算子优化时，我习惯把每次HBM访问都想象成“很贵的一张账单”。一条优化策略如果能减少100MB的片外读写，通常比减少100M次的无效计算更有价值。因为计算在芯片内部，能量和时间成本相对低；数据搬运要跨过片内片外那道墙，付出的代价高一个数量级。这个“价值判断”会直接影响你的优化决策，比如你是花力气做算子融合，还是花力气调指令流水线。

这篇文章没有给你一份“万能优化清单”，因为内存墙的表现随模型、硬件、数据格式千变万化。但如果你能从存储层次的视角看待AI芯片，用数据和算例去分析瓶颈，再看什么方案都通透很多。我自己接手过不少“算力很高但跑不快”的项目，最后几乎都能用这套框架找到根因。希望你也能在下次面对一块新芯片或者一个慢算子时，多问一句：数据到底从哪来，到哪里去，在芯片哪一层停留了多久——答案往往就藏在存储层次里。