核心参数对比
| 管理粒度 | 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 存储层次的精妙之处，恰恰在于每一层都为不同的目标而生，却能在数据流动中无缝协作。
