4、内存子系统建模（上）：全局内存带宽建模、L1/L2缓存命中率与延迟建模、内存合并访问分析

好，咱们今天聊聊内存子系统。说实话，这是GPU性能建模里最绕不开、也最容易翻车的一块。很多同学跑仿真时发现性能上不去，第一反应是“计算单元不够快”，但查到最后，十有八九是内存卡了脖子。我自己带项目那会儿，就吃过这个亏——一个看似完美的架构，结果带宽利用率不到30%，你说气不气人？

4.1 全局内存带宽建模：别被理论峰值骗了

先说说全局内存带宽。很多新人喜欢拿“理论带宽”说事，比如HBM2e标称1.6 TB/s，就觉得“哇，好快”。但实际跑起来呢？我见过最惨的一次，实测只有200 GB/s。为什么？因为理论带宽是理想情况下的极限，你得考虑一堆现实因素。

带宽建模的核心公式其实不复杂：

有效带宽 = 理论带宽 × 利用率因子
利用率因子 = f(访问模式, 冲突率, 协议开销)

我个人习惯把利用率因子拆成三块：

• 访问模式因子：连续访问 vs 随机访问，差距能有5倍以上
• Bank冲突因子：多个请求打到同一个bank，排队等着吧
• 协议开销因子：ECC校验、地址映射、刷新周期，这些都在吃带宽

举个例子。我做过一个项目，用的是GDDR6，理论带宽672 GB/s。但实际跑矩阵乘法时，因为数据布局没优化，bank冲突严重，最后有效带宽只有380 GB/s。嗯，这里要注意——别把理论值当设计目标，否则后面调优会哭的。

4.2 L1/L2缓存命中率与延迟建模：命中是福，miss是祸

缓存建模这块，说白了就是算两笔账：命中率多少？命中/未命中各花多少时间？

先看延迟。L1缓存，我一般建模为20-30个时钟周期。L2呢？100-200个周期。全局内存？那可就奔着300-500个周期去了。你想想看，一次L1 miss，代价是10倍以上的延迟。所以为什么大家都拼命优化数据局部性？就是这个道理。

命中率建模，我推荐用堆栈距离分析法（Stack Distance Analysis）。这个方法的好处是，你不需要跑完整程序，只需要分析访存地址流就能估算命中率。具体做法：

1. 收集程序的访存地址序列
2. 对每个地址，计算它到上一次访问之间的“距离”（中间有多少个不同地址）
3. 统计不同距离出现的频率
4. 根据缓存容量和关联度，映射出命中率

我曾经用这个方法帮团队优化过一个图像处理IP。原始设计的L1命中率只有65%，一分析发现，问题出在数据重用距离太大——每次访问的数据块之间隔了太多无关数据。调整了数据分块策略后，命中率直接跳到92%，性能翻了一倍。

延迟建模这块，我习惯用固定延迟+可变延迟的模型：

L1访问延迟 = 固定流水线延迟(10周期) + 命中判断延迟(5周期)
L1 miss延迟 = L1访问延迟 + L2访问延迟 + 填充延迟

嗯，这里要注意——填充延迟容易被忽略。当L1 miss发生时，需要从L2或内存取数据回来，这个“取数据”的过程本身就有延迟。而且如果多个miss同时发生，还会互相阻塞。我见过一个案例，就是因为没建模填充延迟，仿真结果比实际快了40%。

4.3 内存合并访问（Memory Coalescing）：别让带宽浪费在碎片上

内存合并访问，说白了就是把多个小请求合并成一个大请求。GPU的全局内存访问是以“事务（Transaction）”为单位的，一个事务通常是32字节或128字节。如果你让32个线程各自访问相邻的4字节数据，硬件可以合并成一个128字节的事务——效率极高。

但如果你让它们访问分散的地址呢？那就惨了。每个线程可能触发一个独立的事务，带宽利用率直线下降。

我举个例子。假设有32个线程，每个线程读一个float（4字节）：

• 合并访问：线程0读地址A，线程1读地址A+4，线程2读地址A+8... 硬件合并成1个128字节事务。效率：100%
• 非合并访问：线程0读地址A，线程1读地址A+1000，线程2读地址A+2000... 每个线程触发独立事务。效率：12.5%

为什么会这样？因为GPU的访存单元是按“对齐的128字节块”来工作的。你访问的地址越分散，浪费的带宽就越多。

建模合并访问时，我一般用合并度（Coalescing Ratio）这个指标：

合并度 = 实际事务数 / 理想事务数
理想事务数 = ceil(总数据量 / 事务大小)

合并度越接近1，说明访问模式越好。低于0.5就要警惕了，大概率有优化空间。

最后，给个简单的建模流程：

1. 分析线程束（warp）内每个线程的访存地址
2. 按128字节对齐分组，统计需要的事务数
3. 计算合并度
4. 根据合并度折算有效带宽

嗯，今天就先聊到这儿。下一节咱们继续讲内存子系统的下半部分——原子操作、内存屏障和一致性模型。这些坑更多，到时候我给你们讲讲我踩过的那些雷。