1. 从AI算子的性能瓶颈说起为什么存储层次决定芯片上限干这行时间长了会发现一个特别有意思的现象很多刚接触Ascend 950的开发者第一反应都是去看算力指标什么FP16算力多少TFLOPS、INT8算力多少TOPS觉得数字大就万事大吉。可真到了算子迁移和性能调优的阶段真正卡住进度的根本不是算力而是存储和搬运。Ascend 950作为AI处理器的核心设计目标很明确在大模型训练和推理场景下把矩阵乘法和向量运算的吞吐量尽量拉满。但要撑起这些计算单元光有强大的Cube和Vector是不够的还得有一整套能跟得上消耗节奏的存储体系。如果数据喂不进去再高的理论算力也只是纸面数据实际跑起来会发现计算单元大量时间在空转等待数据利用率惨不忍睹。这篇文章想跟你聊的就是Ascend 950的存储层次和数据通路到底是怎么设计的。它的层级怎么划分、每一层负责什么、数据从HBM出发到真正被计算单元消费中间经历了什么。对于做算子开发、模型迁移或者性能调优的人来说这些内容直接决定了你怎么写代码才能把芯片跑满也决定了你在分析profiling数据时能不能一眼看出瓶颈在哪里。需要说明的是很多细节在不同软件版本和硬件配置下会有差异我会结合实际开发中的通用实践来展开尽量把原理和坑都讲清楚。2. 存储层次拆解从HBM到L0的每一层都在干什么2.1 全貌一条“容量越大越便宜、越靠近计算越昂贵”的链路Ascend 950的存储体系沿用了AI芯片领域非常经典的层次化设计思路从离计算单元最近、容量最小、速度最快的地方一直到离计算单元最远、容量最大、速度最慢的地方依次是L0 Buffer、L1 Buffer、L2 Cache最外层是HBM。这个设计思路本质上跟CPU的多级缓存是一样的逻辑但在AI芯片上做得更极端、更专用化。CPU的多级缓存对应用开发者是透明的你很少需要去手动管L1和L2但在Ascend 950上L0 Buffer和L1 Buffer是软件可管理的开发者在写算子代码时需要明确告诉芯片数据要放到哪一层、什么时候搬运、什么时候计算。这是Ascend架构跟CPU架构最大的不同也是很多从GPU转过来的开发者最不适应的地方。用一个不太严谨但很好懂的生活类比HBM相当于你家楼下的超大仓库什么都有但每次去取货要走路、要等电梯耗时很长L2 Cache相当于小区里的便利店规模小一些但下楼就到L1 Buffer相当于你家的冰箱常用的食材放在里面随取随用而L0 Buffer相当于你手边的操作台切菜、下锅都在这个台面上完成手一伸就够到完全不用走动。为什么要把层次搞得这么复杂核心原因是物理限制。芯片上的SRAM也就是L0和L1这类存储速度极快带宽极高但面积很大、成本极高不可能放得下几十GB的数据。而HBM容量大、成本低但访问延迟和带宽相比片上SRAM差了一个数量级。AI计算对数据的访问模式又非常规律极度适合做数据复用。把这两个因素放在一起层次化存储就成了最优解用容量小的片上存储装下当前计算需要的数据配合合理的调度让数据尽量在片上流转少去碰HBM。2.2 L0 BufferCube计算的心跳地带L0 Buffer是离计算单元最近的存储它并不是一个单一的大块存储而是被拆分成了几个功能不同的部分。其中跟矩阵计算强相关的包括L0A、L0B和L0C在一些资料里也叫L0A、L0B和累加器阵列。L0A和L0B分别对应矩阵乘法中两个输入矩阵的分块缓冲比如你要算一个M×N×K的矩阵乘L0A会负责存放A矩阵的一个分块L0B负责存放B矩阵的一个分块。L0C则是累加器存放矩阵乘的结果。之所以这么拆分是因为Cube单元的计算模式是固定的每次从L0A和L0B取出一块数据做乘累加结果直接写进L0C然后循环迭代累积。这里有个关键点值得注意L0A和L0B的带宽是跟Cube单元的算力严格匹配的。芯片设计者会精算每个时钟周期Cube需要消费多少字节的数据然后反推L0A和L0B需要提供多大的读带宽。所以在实际编程时只要你把数据正确搬到了L0A和L0B里面计算单元消费这部分数据的过程几乎是零额外开销的不需要你再去干预。跟矢量计算相关的还有一个UBUnified Buffer统一缓冲区它既做矢量计算的输入输出缓冲也承担了很多数据转换和中间结果落盘的角色。严格来说UB不属于L0这段的层级划分但它的访问速度和位置也非常靠近计算单元在很多资料里把它跟L0放在一起讨论也不奇怪。开发者最容易踩的坑是误以为L0A、L0B是可以直接随机访问的内存。实际上它们的访问模式高度受限更像是一种FIFO式或块式访问的结构。你写代码时需要考虑的是“这块数据怎么组织成矩阵分块搬进去”而不是“我能不能单独改里面某一个元素”。2.3 L1 Buffer与L2 Cache中间层的缓冲智慧L1 Buffer是L0和后端存储之间的中转站它的容量比L0大不少但又比L2 Cache小。它的核心作用是承接数据复用。举个例子在做卷积计算的时候同一个输入特征图的某个局部窗口会被卷积核多次使用在做Transformer的Attention计算时Q和K矩阵的中间结果往往需要反复被读取。如果不加L1这一层每次复用都要从L2或者HBM重新搬运浪费大量时间和功耗。把数据先放到L1再分批往L0搬就能把复用体系统一起来。再往外是L2 Cache。L2 Cache在Ascend 950上的角色更像一个统一的数据汇聚点所有从HBM读进来的数据、所有要写回HBM的数据都要经过L2。它既是缓存也是搬运通道的中转枢纽。L2 Cache对开发者来说通常是透明的硬件会自动维护它的命中与替换策略。但在某些场景下你也需要关注它的行为。比如在做大矩阵运算时如果每轮迭代的数据量已经超过了L2的容量缓存就会频繁失效数据反复从HBM搬运性能就会出现断崖式下降。这时候光靠硬件缓存机制救不了你需要在算法层面调整分块策略。2.4 一个表格看明白各层次的核心参数差异存储层级大致容量访问速度是否软件可管理主要用途L0A/L0B几十KB到几百KB级别极快是矩阵乘法输入分块L0C几百KB级别极快是矩阵乘法累加结果L1 Buffer几MB级别快是数据复用、卷积/Attention中间结果L2 Cache几十MB级别中等部分可管理统一数据汇聚、缓存HBM几十GB到上百GB较慢是模型权重、激活值、长期存储注意表格里的容量是相对量级不同配置会有差异。真正重要的是理解每层的“职责边界”L0负责喂饱CubeL1负责喂饱L0并减少重复搬运L2负责汇聚所有进出HBM的流量。理解了这层关系后面看数据通路就会顺理成章。3. 数据通路实战一条数据从HBM到Cube的完整旅程3.1 取数路径谁在负责把数据搬到正确的位置Ascend 950的数据通路设计核心是围绕着“搬运引擎”展开的。芯片上有专门的DMA搬运引擎负责在不同存储层级之间搬数据不需要计算单元操心。从HBM读取数据到L2通常是整块连续的大粒度搬运利用HBM的带宽优势尽量一次搬多一点。从L2到L1则要精细得多搬运引擎需要根据算子的数据访问模式决定从L2的哪些地址取数据、组织成什么形状、放到L1的哪个偏移位置。最严格的一条通路是L1到L0A/L0B的搬运。因为L0的容量非常小数据格式又必须严格对齐矩阵分块的要求所以这段搬运的地址计算和形状组织是最复杂的。不同Shape的矩阵乘、不同Padding方式的卷积在从L1往L0搬运时都会映射成不同的搬运指令序列。很多算子开发初学者会忽略一个细节Ascend 950的搬运引擎有一个“多级流水”的概念也就是说搬运数据到L0并不一定是一次性的。你可以先把数据的前半段搬到L0让Cube开始计算同时把后半段数据继续搬运进来。这就是经典的Ping-Pong缓冲思路让搬运和计算重叠起来隐藏数据搬移的延迟。3.2 写入路径计算结果如何安全回到HBM计算完成后数据要原路返回。Cube的计算结果先落到L0C然后由搬运引擎把L0C的数据搬回UB或者L1经过必要的后处理操作比如激活、归一化、量化再最终写回L2和HBM。这条写回路径上有一个常见问题写回的数据往往不是连续的大块而是计算产生的分散结果。比如在做分组卷积或者某些Attention变体时输出数据的排布跟输入数据的排布完全不同需要做格式转换。Ascend 950在硬件层面支持了一些常见的格式转换能力比如NCHW和NC1HWC0这种数据排布之间的转换、转置操作这些操作如果靠计算单元来一一处理会非常慢但用搬运引擎配合特殊的地址映射就能高效完成。开发者需要了解哪些转换是硬件加速的、哪些不是否则可能在不知不觉中写出一段性能极差的代码。3.3 用矩阵乘法案例串起整条通路拿一个大模型里最典型的GEMM通用矩阵乘法来举个例子。假设我们要算一个M4096、N4096、K4096的矩阵乘这对大模型FFN层来说是很常见的规模。第一步从HBM把A矩阵和B矩阵的切片读到L2。这一步通常由系统的调度模块负责因为数据量很大需要分多次读取每次读取一块确保L2存得下且后续搬运有足够的命中率。第二步从L2把A的一个Tile比如128×128的分块搬到L1B的对应分块也搬到L1。这里要选择合适的分块大小既要让L1装得下又要尽量提高数据复用的次数。如果分块太小重复搬运太多如果分块太大L1放不下会频繁挤占L2的带宽。第三步从L1把A的子块搬到L0A把B的子块搬到L0BCube单元开始做矩阵乘。假设L0A能装下64×64的A分块L0B能装下64×64的B分块那Cube每次就做64×64×64的乘累加结果累积到L0C。第四步L0C的结果搬回UB做一些Scale、加Bias、激活操作然后写回L2最终由L2刷回HBM。整个过程中Cube计算本身很快真正消耗时间的是各级搬运。一个优秀的实现会把上述几步做成流水线当Cube在计算第i个分块时搬运引擎同时在把第i1个分块从L1搬到L0而且还在把第i-1个分块的结果从UB写回HBM。三级流水全部重叠起来才能把芯片的性能用足。3.4 数据通路上的几个“堵点”需要提前知道数据通路上一旦出现堵塞问题通常出在这么几个地方。一个是L2到HBM的带宽打满这种情况往往是大模型场景下权重反复加载导致的能做的优化是在片上尽量多留复用的数据。一个是L1到L0的带宽不够这通常是因为数据格式没对齐或者分块策略不合理导致搬运效率低。还有一个是UB被读写冲突卡住矢量计算和搬运引擎同时操作UB时会有竞争需要合理安排时序。这些堵点并不是每次都立刻暴露成错误更多时候表现为性能不达标、profiling数据里某个环节耗时异常。所以建议在平时开发时就对数据通路有清晰认知遇到性能问题能快速判断到底是哪一段堵了。4. 算子开发与调优中的存储优化经验4.1 数据复用策略能少搬一次就少搬一次在Ascend 950上写算子存储优化的核心原则就一句话让每一字节从HBM进入片上存储的数据都被尽可能多地使用。听起来像废话但实施起来需要结合具体算子来拆解。以卷积为例一个输入特征图会被多个卷积核反复滑动扫描。如果你每个卷积核跑一遍都从HBM重新读取输入图带宽开销成倍增加。正确的做法是把输入图的一个分块加载到L1然后在L1上完成所有需要复用该分块的卷积核计算只把输出写回。具体实现时“分块大小”的选取是调优的关键。分块太小复用次数少带宽利用率低分块太大缓存放不下反而会引发频繁驱逐。我在实际调优时一般会先根据算子的访存量算一个理论最优值再在附近做网格搜索。比如某个算子的理论最优分块是256KB我会把128KB、192KB、256KB、320KB、384KB都跑一遍看看哪个实际性能最好因为理论计算没法完全模拟硬件调度和Cache替换的复杂行为。Attention算子的优化思路也是类似的QK^T的中间结果在计算Softmax时会被多次读取如果能把一整个分块的注意力分数放在UB里算完再写回就能省掉大量中间结果的搬运。这块已经有很多成熟的FlashAttention思路可以参考核心还是做分块和复用。4.2 乒乓缓冲与异步搬运让存储层次“无缝衔接”乒乓缓冲的原理特别简单准备两块缓冲区一块用来让计算单元读数据另一块用来让搬运引擎写数据下轮迭代角色互换。这样计算和搬运可以完全并行不需要等待对方结束。在Ascend 950上做乒乓要关注片上存储资源的分配。开发者通常在申请缓冲区时会把双缓冲或者多缓冲的地址空间一起申请下来然后在代码里用循环切换地址偏移。循环体里做的事情是触发下一块数据的搬运指令、等待当前块的计算完成、切换地址偏移。只要搬运时间不超过计算时间理论上计算单元就不会出现等待空隙。很多开发者在做乒乓时容易犯一个错误同步太频繁。比如每次迭代都等搬运完全结束才开始计算这样就退化成串行了乒乓效果完全消失。正确的做法是利用硬件提供的“事件”机制只在该等的点等待比如计算开始之前确保数据已经搬到位搬运启动之前确保上轮计算结果已经读完。给一个我常用的伪代码逻辑// 双缓冲buf[0] 和 buf[1] 交替使用 for (int i 0; i numTiles; i) { int bufIndex i % 2; // 搬运第 i1 块数据到 buf[(i1) % 2] if (i 1 numTiles) { dmaCopy(src (i 1) * tileSize, buf[(i 1) % 2], tileSize); } // 等待第 i 块数据搬运完成 waitDmaDone(bufIndex); // 当前块计算 compute(buf[bufIndex]); // 等待计算完成再进入下一次循环防止直接覆盖 waitComputeDone(bufIndex); }这里的核心要点是搬运下一次数据和计算当前数据是重叠的但同一块缓冲区的读写必须严格同步否则会出现数据竞争拿到半新不旧的脏数据结果完全不可控。4.3 存储方向上的常见优化手段速查优化手段适用场景核心收益注意事项分块复用卷积、矩阵乘减少HBM访存量分块大小需实测乒乓缓冲所有密集计算隐藏搬运延迟注意同步点设置格式转换合并有排布转换需求时减少UB中转次数优先用硬件支持的转换输出就地写回激活、归一化等算子省一次中间结果拷贝确认数据依赖无冲突多核并行分配大矩阵、Attention摊薄单核带宽压力注意核间负载均衡4.4 一个算例怎么估算分块大小不会爆L1假设你的L1 Buffer可用大小是2MB你现在要做K方向的分块。A矩阵的一个分块是128×64的FP16占128×64×2字节16KB为了流水线隐藏延迟需要双缓冲也就是32KB。B矩阵分块是64×64的FP16占8KB双缓冲后16KB。加上L0A、L0B、UB等必须预留的空间粗略估算最终能装下的K分块数大概是2MB除以32KB16KB再考虑一些预留空间差不多能支持30到40轮的K迭代。这里面一定要预留余量。我见过有人在理论计算上精确到字节结果一上板就报内存分配失败原因就是没算上指令缓冲区、对齐Padding、中间变量这些隐藏开销。稳妥做法是至少预留10%到20%的空闲空间给运行时使用。5. 常见问题与排查技巧实录5.1 典型问题性能上不去、利用率忽高忽低在Ascend 950上做算子调优时遇到最多的现象是理论算力看着很高但实际跑出的利用率不到50%甚至只有20%到30%。这个时候如果直接怀疑计算单元不行方向就错了。多数情况是数据通路没打通计算单元在空等数据。我自己的排查顺序大概是这样的先看profiling里Cube Utilization和Vector Utilization如果Cube利用率很低但搬运时间很长说明问题在数据供给端。再看L2到L0的搬运量是不是异常大如果是说明L1的复用没做好数据被反复从更远的层级读取。再检查L0到计算单元的搬运格式有时候是Shape不匹配导致硬件无法发挥最大搬运效率。5.2 一个内存踩踏导致的“灵异问题”有一次跑一个融合算子结果偶尔出错而且是那种跑十次错一次的随机错误特别难查。后来才发现是双缓冲的同步点设置不对上一次计算还没结束下一次搬运已经把同一块UB的内容覆盖了。排查思路是通过profiling看计算和搬运的时间线发现同一块缓冲区被两个引擎同时访问的时间段有重叠。这个问题的排查经验是遇到结果偶发出错时优先怀疑数据竞争尤其是有多级流水、乒乓缓冲、异步搬运的场景。检查同步事件的顺序、检查每个缓冲区地址是否被多个引擎同时访问比反复检查数学逻辑有用得多因为数学逻辑如果有错通常会稳定出错而不是随机出错。5.3 别被“理论峰值带宽”忽悠了很多芯片资料上会写HBM理论带宽有多少多少GB/s但实际能跑到的有效带宽往往要打个折扣。因为在真实场景里很难做到100%利用率的连续读取。内存刷新、地址冲突、读写切换损耗、缓存未命中各种因素都会吃掉一部分带宽。我在实际测试中测过很多次一个设计良好的数据搬运流程能跑到的有效带宽通常是理论值的70%到85%。如果发现你的程序有效带宽超过85%那说明已经非常优秀了不用再折腾搬运逻辑。要是长期在50%以下才需要认真审视数据通路。另外要特别注意读写切换对带宽的影响。HBM有个特性同一时间最好只做读或者只做写频繁切换读写方向会让总线需要额外的切换时间有效带宽大幅下降。所以在设计算子时尽量把读操作和写操作各自集中成段比如先集中从HBM读一批数据到L2再集中把结果写回避免读一拍写一拍地交错进行。5.4 一个调试小习惯先跑小规模再上大矩阵刚开始接触Ascend 950的存储和搬运时建议不要直接拿大模型的核心算子来调试。先用小规模的矩阵乘、简单的数据搬运测试代码跑通流程验证你对层级关系和同步机制的理解是对的再逐步放大规模。小规模调试的好处是问题容易定位。如果128×128的矩阵乘性能就不对那肯定不是分块策略的问题多半是搬运指令的参数设置有误。等小规模跑顺了再上大矩阵分块、复用、流水这些优化手段才能派上用场。我自己就是这么过来的省了非常多排查时间。6. 最后的几点体会Ascend 950的存储层次和数据通路本质上是在跟物理限制做对抗。它用清晰的层级划分、灵活的搬运引擎和可管理的片上存储换来了计算单元的高利用率。理解了这条数据链路上的每一个环节才能真正理解为什么有些算子跑得快、有些算子跑得慢也才能在写代码时做到心中有数。有一点我想特别强调芯片架构文档里的参数和真机行为之间永远存在一层“经验的距离”。你读了再多的架构说明如果不在真机上跑几个测试算子不亲手调一调分块大小、不等一次数据竞争的出现就很难真正建立体感。很多看起来很深奥的架构设计等你亲手踩过几个坑之后回头看会发现逻辑其实非常顺畅。最后分享一个我自己的习惯每次写新算子之前先花十几分钟在纸上画一下数据流图。A矩阵从哪儿来、搬去哪儿、怎么分块、Cube算完结果去哪儿、经过什么处理、最终写回哪个地址。这张图花不了多少时间但能在后续编码和调试中帮你避开无数思维混乱的坑。很多人觉得画图是形式主义实际上它是把你对存储层次和数据通路的理解固化成结构的过程值得坚持。 Ascend 950存储层次与数据通路解析：从HBM到L0的优化实践
1. 从AI算子的性能瓶颈说起为什么存储层次决定芯片上限干这行时间长了会发现一个特别有意思的现象很多刚接触Ascend 950的开发者第一反应都是去看算力指标什么FP16算力多少TFLOPS、INT8算力多少TOPS觉得数字大就万事大吉。可真到了算子迁移和性能调优的阶段真正卡住进度的根本不是算力而是存储和搬运。Ascend 950作为AI处理器的核心设计目标很明确在大模型训练和推理场景下把矩阵乘法和向量运算的吞吐量尽量拉满。但要撑起这些计算单元光有强大的Cube和Vector是不够的还得有一整套能跟得上消耗节奏的存储体系。如果数据喂不进去再高的理论算力也只是纸面数据实际跑起来会发现计算单元大量时间在空转等待数据利用率惨不忍睹。这篇文章想跟你聊的就是Ascend 950的存储层次和数据通路到底是怎么设计的。它的层级怎么划分、每一层负责什么、数据从HBM出发到真正被计算单元消费中间经历了什么。对于做算子开发、模型迁移或者性能调优的人来说这些内容直接决定了你怎么写代码才能把芯片跑满也决定了你在分析profiling数据时能不能一眼看出瓶颈在哪里。需要说明的是很多细节在不同软件版本和硬件配置下会有差异我会结合实际开发中的通用实践来展开尽量把原理和坑都讲清楚。2. 存储层次拆解从HBM到L0的每一层都在干什么2.1 全貌一条“容量越大越便宜、越靠近计算越昂贵”的链路Ascend 950的存储体系沿用了AI芯片领域非常经典的层次化设计思路从离计算单元最近、容量最小、速度最快的地方一直到离计算单元最远、容量最大、速度最慢的地方依次是L0 Buffer、L1 Buffer、L2 Cache最外层是HBM。这个设计思路本质上跟CPU的多级缓存是一样的逻辑但在AI芯片上做得更极端、更专用化。CPU的多级缓存对应用开发者是透明的你很少需要去手动管L1和L2但在Ascend 950上L0 Buffer和L1 Buffer是软件可管理的开发者在写算子代码时需要明确告诉芯片数据要放到哪一层、什么时候搬运、什么时候计算。这是Ascend架构跟CPU架构最大的不同也是很多从GPU转过来的开发者最不适应的地方。用一个不太严谨但很好懂的生活类比HBM相当于你家楼下的超大仓库什么都有但每次去取货要走路、要等电梯耗时很长L2 Cache相当于小区里的便利店规模小一些但下楼就到L1 Buffer相当于你家的冰箱常用的食材放在里面随取随用而L0 Buffer相当于你手边的操作台切菜、下锅都在这个台面上完成手一伸就够到完全不用走动。为什么要把层次搞得这么复杂核心原因是物理限制。芯片上的SRAM也就是L0和L1这类存储速度极快带宽极高但面积很大、成本极高不可能放得下几十GB的数据。而HBM容量大、成本低但访问延迟和带宽相比片上SRAM差了一个数量级。AI计算对数据的访问模式又非常规律极度适合做数据复用。把这两个因素放在一起层次化存储就成了最优解用容量小的片上存储装下当前计算需要的数据配合合理的调度让数据尽量在片上流转少去碰HBM。2.2 L0 BufferCube计算的心跳地带L0 Buffer是离计算单元最近的存储它并不是一个单一的大块存储而是被拆分成了几个功能不同的部分。其中跟矩阵计算强相关的包括L0A、L0B和L0C在一些资料里也叫L0A、L0B和累加器阵列。L0A和L0B分别对应矩阵乘法中两个输入矩阵的分块缓冲比如你要算一个M×N×K的矩阵乘L0A会负责存放A矩阵的一个分块L0B负责存放B矩阵的一个分块。L0C则是累加器存放矩阵乘的结果。之所以这么拆分是因为Cube单元的计算模式是固定的每次从L0A和L0B取出一块数据做乘累加结果直接写进L0C然后循环迭代累积。这里有个关键点值得注意L0A和L0B的带宽是跟Cube单元的算力严格匹配的。芯片设计者会精算每个时钟周期Cube需要消费多少字节的数据然后反推L0A和L0B需要提供多大的读带宽。所以在实际编程时只要你把数据正确搬到了L0A和L0B里面计算单元消费这部分数据的过程几乎是零额外开销的不需要你再去干预。跟矢量计算相关的还有一个UBUnified Buffer统一缓冲区它既做矢量计算的输入输出缓冲也承担了很多数据转换和中间结果落盘的角色。严格来说UB不属于L0这段的层级划分但它的访问速度和位置也非常靠近计算单元在很多资料里把它跟L0放在一起讨论也不奇怪。开发者最容易踩的坑是误以为L0A、L0B是可以直接随机访问的内存。实际上它们的访问模式高度受限更像是一种FIFO式或块式访问的结构。你写代码时需要考虑的是“这块数据怎么组织成矩阵分块搬进去”而不是“我能不能单独改里面某一个元素”。2.3 L1 Buffer与L2 Cache中间层的缓冲智慧L1 Buffer是L0和后端存储之间的中转站它的容量比L0大不少但又比L2 Cache小。它的核心作用是承接数据复用。举个例子在做卷积计算的时候同一个输入特征图的某个局部窗口会被卷积核多次使用在做Transformer的Attention计算时Q和K矩阵的中间结果往往需要反复被读取。如果不加L1这一层每次复用都要从L2或者HBM重新搬运浪费大量时间和功耗。把数据先放到L1再分批往L0搬就能把复用体系统一起来。再往外是L2 Cache。L2 Cache在Ascend 950上的角色更像一个统一的数据汇聚点所有从HBM读进来的数据、所有要写回HBM的数据都要经过L2。它既是缓存也是搬运通道的中转枢纽。L2 Cache对开发者来说通常是透明的硬件会自动维护它的命中与替换策略。但在某些场景下你也需要关注它的行为。比如在做大矩阵运算时如果每轮迭代的数据量已经超过了L2的容量缓存就会频繁失效数据反复从HBM搬运性能就会出现断崖式下降。这时候光靠硬件缓存机制救不了你需要在算法层面调整分块策略。2.4 一个表格看明白各层次的核心参数差异存储层级大致容量访问速度是否软件可管理主要用途L0A/L0B几十KB到几百KB级别极快是矩阵乘法输入分块L0C几百KB级别极快是矩阵乘法累加结果L1 Buffer几MB级别快是数据复用、卷积/Attention中间结果L2 Cache几十MB级别中等部分可管理统一数据汇聚、缓存HBM几十GB到上百GB较慢是模型权重、激活值、长期存储注意表格里的容量是相对量级不同配置会有差异。真正重要的是理解每层的“职责边界”L0负责喂饱CubeL1负责喂饱L0并减少重复搬运L2负责汇聚所有进出HBM的流量。理解了这层关系后面看数据通路就会顺理成章。3. 数据通路实战一条数据从HBM到Cube的完整旅程3.1 取数路径谁在负责把数据搬到正确的位置Ascend 950的数据通路设计核心是围绕着“搬运引擎”展开的。芯片上有专门的DMA搬运引擎负责在不同存储层级之间搬数据不需要计算单元操心。从HBM读取数据到L2通常是整块连续的大粒度搬运利用HBM的带宽优势尽量一次搬多一点。从L2到L1则要精细得多搬运引擎需要根据算子的数据访问模式决定从L2的哪些地址取数据、组织成什么形状、放到L1的哪个偏移位置。最严格的一条通路是L1到L0A/L0B的搬运。因为L0的容量非常小数据格式又必须严格对齐矩阵分块的要求所以这段搬运的地址计算和形状组织是最复杂的。不同Shape的矩阵乘、不同Padding方式的卷积在从L1往L0搬运时都会映射成不同的搬运指令序列。很多算子开发初学者会忽略一个细节Ascend 950的搬运引擎有一个“多级流水”的概念也就是说搬运数据到L0并不一定是一次性的。你可以先把数据的前半段搬到L0让Cube开始计算同时把后半段数据继续搬运进来。这就是经典的Ping-Pong缓冲思路让搬运和计算重叠起来隐藏数据搬移的延迟。3.2 写入路径计算结果如何安全回到HBM计算完成后数据要原路返回。Cube的计算结果先落到L0C然后由搬运引擎把L0C的数据搬回UB或者L1经过必要的后处理操作比如激活、归一化、量化再最终写回L2和HBM。这条写回路径上有一个常见问题写回的数据往往不是连续的大块而是计算产生的分散结果。比如在做分组卷积或者某些Attention变体时输出数据的排布跟输入数据的排布完全不同需要做格式转换。Ascend 950在硬件层面支持了一些常见的格式转换能力比如NCHW和NC1HWC0这种数据排布之间的转换、转置操作这些操作如果靠计算单元来一一处理会非常慢但用搬运引擎配合特殊的地址映射就能高效完成。开发者需要了解哪些转换是硬件加速的、哪些不是否则可能在不知不觉中写出一段性能极差的代码。3.3 用矩阵乘法案例串起整条通路拿一个大模型里最典型的GEMM通用矩阵乘法来举个例子。假设我们要算一个M4096、N4096、K4096的矩阵乘这对大模型FFN层来说是很常见的规模。第一步从HBM把A矩阵和B矩阵的切片读到L2。这一步通常由系统的调度模块负责因为数据量很大需要分多次读取每次读取一块确保L2存得下且后续搬运有足够的命中率。第二步从L2把A的一个Tile比如128×128的分块搬到L1B的对应分块也搬到L1。这里要选择合适的分块大小既要让L1装得下又要尽量提高数据复用的次数。如果分块太小重复搬运太多如果分块太大L1放不下会频繁挤占L2的带宽。第三步从L1把A的子块搬到L0A把B的子块搬到L0BCube单元开始做矩阵乘。假设L0A能装下64×64的A分块L0B能装下64×64的B分块那Cube每次就做64×64×64的乘累加结果累积到L0C。第四步L0C的结果搬回UB做一些Scale、加Bias、激活操作然后写回L2最终由L2刷回HBM。整个过程中Cube计算本身很快真正消耗时间的是各级搬运。一个优秀的实现会把上述几步做成流水线当Cube在计算第i个分块时搬运引擎同时在把第i1个分块从L1搬到L0而且还在把第i-1个分块的结果从UB写回HBM。三级流水全部重叠起来才能把芯片的性能用足。3.4 数据通路上的几个“堵点”需要提前知道数据通路上一旦出现堵塞问题通常出在这么几个地方。一个是L2到HBM的带宽打满这种情况往往是大模型场景下权重反复加载导致的能做的优化是在片上尽量多留复用的数据。一个是L1到L0的带宽不够这通常是因为数据格式没对齐或者分块策略不合理导致搬运效率低。还有一个是UB被读写冲突卡住矢量计算和搬运引擎同时操作UB时会有竞争需要合理安排时序。这些堵点并不是每次都立刻暴露成错误更多时候表现为性能不达标、profiling数据里某个环节耗时异常。所以建议在平时开发时就对数据通路有清晰认知遇到性能问题能快速判断到底是哪一段堵了。4. 算子开发与调优中的存储优化经验4.1 数据复用策略能少搬一次就少搬一次在Ascend 950上写算子存储优化的核心原则就一句话让每一字节从HBM进入片上存储的数据都被尽可能多地使用。听起来像废话但实施起来需要结合具体算子来拆解。以卷积为例一个输入特征图会被多个卷积核反复滑动扫描。如果你每个卷积核跑一遍都从HBM重新读取输入图带宽开销成倍增加。正确的做法是把输入图的一个分块加载到L1然后在L1上完成所有需要复用该分块的卷积核计算只把输出写回。具体实现时“分块大小”的选取是调优的关键。分块太小复用次数少带宽利用率低分块太大缓存放不下反而会引发频繁驱逐。我在实际调优时一般会先根据算子的访存量算一个理论最优值再在附近做网格搜索。比如某个算子的理论最优分块是256KB我会把128KB、192KB、256KB、320KB、384KB都跑一遍看看哪个实际性能最好因为理论计算没法完全模拟硬件调度和Cache替换的复杂行为。Attention算子的优化思路也是类似的QK^T的中间结果在计算Softmax时会被多次读取如果能把一整个分块的注意力分数放在UB里算完再写回就能省掉大量中间结果的搬运。这块已经有很多成熟的FlashAttention思路可以参考核心还是做分块和复用。4.2 乒乓缓冲与异步搬运让存储层次“无缝衔接”乒乓缓冲的原理特别简单准备两块缓冲区一块用来让计算单元读数据另一块用来让搬运引擎写数据下轮迭代角色互换。这样计算和搬运可以完全并行不需要等待对方结束。在Ascend 950上做乒乓要关注片上存储资源的分配。开发者通常在申请缓冲区时会把双缓冲或者多缓冲的地址空间一起申请下来然后在代码里用循环切换地址偏移。循环体里做的事情是触发下一块数据的搬运指令、等待当前块的计算完成、切换地址偏移。只要搬运时间不超过计算时间理论上计算单元就不会出现等待空隙。很多开发者在做乒乓时容易犯一个错误同步太频繁。比如每次迭代都等搬运完全结束才开始计算这样就退化成串行了乒乓效果完全消失。正确的做法是利用硬件提供的“事件”机制只在该等的点等待比如计算开始之前确保数据已经搬到位搬运启动之前确保上轮计算结果已经读完。给一个我常用的伪代码逻辑// 双缓冲buf[0] 和 buf[1] 交替使用 for (int i 0; i numTiles; i) { int bufIndex i % 2; // 搬运第 i1 块数据到 buf[(i1) % 2] if (i 1 numTiles) { dmaCopy(src (i 1) * tileSize, buf[(i 1) % 2], tileSize); } // 等待第 i 块数据搬运完成 waitDmaDone(bufIndex); // 当前块计算 compute(buf[bufIndex]); // 等待计算完成再进入下一次循环防止直接覆盖 waitComputeDone(bufIndex); }这里的核心要点是搬运下一次数据和计算当前数据是重叠的但同一块缓冲区的读写必须严格同步否则会出现数据竞争拿到半新不旧的脏数据结果完全不可控。4.3 存储方向上的常见优化手段速查优化手段适用场景核心收益注意事项分块复用卷积、矩阵乘减少HBM访存量分块大小需实测乒乓缓冲所有密集计算隐藏搬运延迟注意同步点设置格式转换合并有排布转换需求时减少UB中转次数优先用硬件支持的转换输出就地写回激活、归一化等算子省一次中间结果拷贝确认数据依赖无冲突多核并行分配大矩阵、Attention摊薄单核带宽压力注意核间负载均衡4.4 一个算例怎么估算分块大小不会爆L1假设你的L1 Buffer可用大小是2MB你现在要做K方向的分块。A矩阵的一个分块是128×64的FP16占128×64×2字节16KB为了流水线隐藏延迟需要双缓冲也就是32KB。B矩阵分块是64×64的FP16占8KB双缓冲后16KB。加上L0A、L0B、UB等必须预留的空间粗略估算最终能装下的K分块数大概是2MB除以32KB16KB再考虑一些预留空间差不多能支持30到40轮的K迭代。这里面一定要预留余量。我见过有人在理论计算上精确到字节结果一上板就报内存分配失败原因就是没算上指令缓冲区、对齐Padding、中间变量这些隐藏开销。稳妥做法是至少预留10%到20%的空闲空间给运行时使用。5. 常见问题与排查技巧实录5.1 典型问题性能上不去、利用率忽高忽低在Ascend 950上做算子调优时遇到最多的现象是理论算力看着很高但实际跑出的利用率不到50%甚至只有20%到30%。这个时候如果直接怀疑计算单元不行方向就错了。多数情况是数据通路没打通计算单元在空等数据。我自己的排查顺序大概是这样的先看profiling里Cube Utilization和Vector Utilization如果Cube利用率很低但搬运时间很长说明问题在数据供给端。再看L2到L0的搬运量是不是异常大如果是说明L1的复用没做好数据被反复从更远的层级读取。再检查L0到计算单元的搬运格式有时候是Shape不匹配导致硬件无法发挥最大搬运效率。5.2 一个内存踩踏导致的“灵异问题”有一次跑一个融合算子结果偶尔出错而且是那种跑十次错一次的随机错误特别难查。后来才发现是双缓冲的同步点设置不对上一次计算还没结束下一次搬运已经把同一块UB的内容覆盖了。排查思路是通过profiling看计算和搬运的时间线发现同一块缓冲区被两个引擎同时访问的时间段有重叠。这个问题的排查经验是遇到结果偶发出错时优先怀疑数据竞争尤其是有多级流水、乒乓缓冲、异步搬运的场景。检查同步事件的顺序、检查每个缓冲区地址是否被多个引擎同时访问比反复检查数学逻辑有用得多因为数学逻辑如果有错通常会稳定出错而不是随机出错。5.3 别被“理论峰值带宽”忽悠了很多芯片资料上会写HBM理论带宽有多少多少GB/s但实际能跑到的有效带宽往往要打个折扣。因为在真实场景里很难做到100%利用率的连续读取。内存刷新、地址冲突、读写切换损耗、缓存未命中各种因素都会吃掉一部分带宽。我在实际测试中测过很多次一个设计良好的数据搬运流程能跑到的有效带宽通常是理论值的70%到85%。如果发现你的程序有效带宽超过85%那说明已经非常优秀了不用再折腾搬运逻辑。要是长期在50%以下才需要认真审视数据通路。另外要特别注意读写切换对带宽的影响。HBM有个特性同一时间最好只做读或者只做写频繁切换读写方向会让总线需要额外的切换时间有效带宽大幅下降。所以在设计算子时尽量把读操作和写操作各自集中成段比如先集中从HBM读一批数据到L2再集中把结果写回避免读一拍写一拍地交错进行。5.4 一个调试小习惯先跑小规模再上大矩阵刚开始接触Ascend 950的存储和搬运时建议不要直接拿大模型的核心算子来调试。先用小规模的矩阵乘、简单的数据搬运测试代码跑通流程验证你对层级关系和同步机制的理解是对的再逐步放大规模。小规模调试的好处是问题容易定位。如果128×128的矩阵乘性能就不对那肯定不是分块策略的问题多半是搬运指令的参数设置有误。等小规模跑顺了再上大矩阵分块、复用、流水这些优化手段才能派上用场。我自己就是这么过来的省了非常多排查时间。6. 最后的几点体会Ascend 950的存储层次和数据通路本质上是在跟物理限制做对抗。它用清晰的层级划分、灵活的搬运引擎和可管理的片上存储换来了计算单元的高利用率。理解了这条数据链路上的每一个环节才能真正理解为什么有些算子跑得快、有些算子跑得慢也才能在写代码时做到心中有数。有一点我想特别强调芯片架构文档里的参数和真机行为之间永远存在一层“经验的距离”。你读了再多的架构说明如果不在真机上跑几个测试算子不亲手调一调分块大小、不等一次数据竞争的出现就很难真正建立体感。很多看起来很深奥的架构设计等你亲手踩过几个坑之后回头看会发现逻辑其实非常顺畅。最后分享一个我自己的习惯每次写新算子之前先花十几分钟在纸上画一下数据流图。A矩阵从哪儿来、搬去哪儿、怎么分块、Cube算完结果去哪儿、经过什么处理、最终写回哪个地址。这张图花不了多少时间但能在后续编码和调试中帮你避开无数思维混乱的坑。很多人觉得画图是形式主义实际上它是把你对存储层次和数据通路的理解固化成结构的过程值得坚持。