【infra之路】GPU 存储层次总结：L1 / L2 / HBM

核心参数对比

维度	L1 Cache	L2 Cache	HBM
管理粒度	128B Line	32B Sector	64--128B Burst
设计驱动力	Warp 执行模型	容量效率 + 工作负载特征	带宽密度 + 物理封装
服务对象	单 SM 内的单个 Warp	跨 SM 的全局流量	全芯片所有 SM
与通道宽度的关系	❌ 无关	⚠️ 历史相关，现已解耦	✅ 直接由其定义
典型延迟	~30 cycles	~200 cycles	~400+ cycles
典型容量 (H100)	256KB/SM (可配)	50MB	80GB
带宽瓶颈	Shared Mem Bank 冲突	Tag/Sector 查找吞吐	HBM Stack 数量 × 位宽

三者的设计哲学

L1 = 为计算而生

128B 是 "32 threads × 4B" 的物理投影。它不关心数据从哪里来、以什么粒度搬运，只关心一个 Warp 能否在一个事务内拿到完整数据。它是执行模型的延伸，不是存储系统的组件。
L2 = 为效率而生

32B sector 是容量、碎片、部分更新三者博弈的甜蜜点。它不再对齐任何单一硬件常数，而是对齐 GPU 工作负载的统计特征。Memory Controller 负责在它和 HBM 之间做粒度转换。
HBM = 为带宽而生

它的 burst size（64--128B）由物理封装决定的通道位宽 × Burst Length 直接给出。这是整个层次中唯一真正被"通道宽度限制"的层级。L1 和 L2 的设计都独立于它，最终由 Memory Controller 统一适配。

数据流视角：一次 L1 Miss 的完整路径

复制代码

Warp 请求 128B
    │
    ▼
L1 Miss → 向 L2 请求 4 × 32B Sector
    │
    ▼
L2 Hit? ──Yes──→ 返回 4 Sectors → 填充 L1 Line → 返回 Warp
    │No
    ▼
Memory Controller 将 4 Sectors 合并为 1×128B HBM Burst
    │
    ▼
HBM 返回 128B → 拆为 4 Sectors 填入 L2 → 再填入 L1 → 返回 Warp

关键洞察 ：128B 在这条路径中出现了三次，但含义完全不同------在 L1 是执行单元的数据需求 ，在 L2↔MC 接口是传输对齐边界 ，在 HBM 是物理总线的最小有效事务。同一个数字，三种完全不同的因果。

一句话总结

L1 的 128B 来自 Warp，L2 的 32B 来自工作负载，HBM 的 burst size 来自物理封装。三者数值上的巧合或倍数关系并非同源，而是各自独立优化后由 Memory Controller 在运行时缝合的结果------GPU 存储层次的精妙之处，恰恰在于每一层都为不同的目标而生，却能在数据流动中无缝协作。