跳到主要内容

Memory 资源域

带宽与容量怎么作为 perf model 的输入——四档精度下访存延迟、容量墙、HBM/SRAM 层级、KV 作为资源各自怎么建

核心要点:

  • 访存延迟是 roofline 的另一条边,但"取哪条带宽"决定建模是仅相对还是绝对——peak / sustainable / attainable 三者差 20-40%
  • 容量墙(KV cache + 权重 + 激活放不放得下)是 perf model 最干净可信的产出,因为它只数字节、不碰时序假设
  • HBM 真实利用率受 bank conflict / row buffer miss / refresh 拉低,bank group 无交错时信道利用率上限 ≤ 50%
  • decode 阶段算术强度 $\approx 2/b$(b 是权重字节数),量化直接翻倍 AI——这是建模量化加速 decode 的核心机制
  • PagedAttention 把碎片从"60% to 80%"降到"less than 4%"(论文 verbatim),perf model 必须在容量墙上挂利用率因子
  • 业界专业 DRAM 仿真(Ramulator/DRAMsim3)做 cycle-approx 标定 + 解析模型做 DSE 是主流混合做法

名词定义​

名词定义
带宽 roofline访存边 $T = \text{bytes}/(\text{BW}\times\eta_M)$,与计算边取 $\max$
算术强度(AI)每字节访存对应的浮点运算数 FLOPs/byte
容量墙(capacity wall)KV cache + 权重 + 激活占满 HBM 时的并发与序列上限
Sustainable bandwidthSTREAM 类基准实测的可持续带宽,占 peak 比例反映 $\eta_M$
Bank conflict多个访问竞争 DRAM 同一 bank,触发串行化与额外延迟
Row buffer hitDRAM 同一 row 内连续访问命中,避免 activate / precharge 开销
内存碎片KV 预分配未充分利用的容量(vLLM 之前 60-80%,之后 < 4%)
Scratchpad软件显式管理的片上 SRAM,与 cache 的硬件管理对照

本篇范围​

Memory 资源域管"访存延迟与内存容量怎么作为 perf model 的输入"——输入是工作负载层产出的字节数与访问模式(由 knowledge/03-长上下文 等定义 KV 算法侧),输出是访存延迟、有效带宽折损、容量是否撑爆。

不包含:

三种"带宽"的区别(易混淆点)​

写访存模型公式之前,必须分清三类带宽,否则 $\eta_M$ 的物理意义糊掉:

类型定义典型来源
Peak bandwidthdatasheet 标称峰值,理论上界芯片规格表
Sustainable bandwidthSTREAM 类 benchmark 实测的稳态带宽STREAM Triad
Attainable bandwidth特定 kernel 在实际访问模式下的带宽NCU dram__bytes_* 计数

@tbl-ipm-m-bw-types 三种带宽的区别与来源

关键比例:

  • NVIDIA Grace CPU Benchmarking Guide verbatim:"STREAM TRIAD should score between 80% and 95% of the system's theoretical peak memory bandwidth"
  • GPU HBM 侧:A100 STREAM 实测约 1550 / 2039 GB/s ≈ 76%,H100 超 90%——通常高于 CPU DDR 的 60-80% 区间
  • 在 perf model 里,$\eta_M$ 的合理来源是 sustainable bw / peak bw 而非 attainable / peak,后者随 kernel 变化太大,不能作为全局标量

新人常犯错:看到"内存带宽利用率 60-80%"的说法,直接套到 GPU HBM 上——这个数字来自 CPU DDR 场景,对 H100 HBM 严重低估。

Analytical 档:roofline 访存边 + 容量墙​

主流 LLM analytical 工具在访存侧的差异,集中在 $\eta_M$ 的处理与容量墙是否显式建模。

四工具横向对比​

工具访存 roofline 形式$\eta_M$ 处理容量墙建模
LLM-Viewer[1]标准 roofline,peak BW无(裸峰值)无显式容量约束不等式
GenZ[2]双层 roofline,快/慢内存各 $\eta$实测标定:H100 $\eta_M = 0.70$(verbatim)通过 KV+权重字节预算间接表达
Calculon[3]$\text{throughput}(b) = \text{BW}\times\eta(b)$ 分段查表按 op 字节分段:A100 ≥ 100 MB→0.90 / ≥ 10 MB→0.75 / ≥ 1 MB→0.60 / < 1 MB→0.30训练侧建模为主,推理场景容量约束未单列
LLMCompass[4]放弃 roofline,tile-by-tile 仿真涌现而非预设枚举仿真判断 OOM,"memory capacity limits the batch size"

@tbl-ipm-m-analytical-tools analytical 档主流工具的 $\eta_M$ 与容量墙处理

GenZ 的 verbatim quote(Section IV-E):"we plug-in empirically measured efficiency factors of 60% for the GPU Tensor TFLOPs and 70% for GPU memory bandwidth"。Calculon 的 $\eta_M$ 分段曲线直接从 a100_80g.json 配置文件 verbatim 抄录,关键洞察是小 op 的 $\eta_M$ 远低于大 op(0.30 vs 0.90),这与 tile / wave quantization 在 compute 域的现象同源——本质都是粒度损失。

容量墙公式​

标准形式:

$$\begin{equation} b \cdot s \le \frac{M_{\text{HBM}} - M_{\text{weight}}}{2 \cdot L \cdot n_{kv} \cdot d_h \cdot \text{dtype}_{\text{bytes}}} \label{eq:ipm-m-capacity-wall} \end{equation}$$

其中 $b$ 是并发批量,$s$ 是序列长度,$L$ 是层数,$n_{kv}$ 是 KV 头数,$d_h$ 是头维度,$\text{dtype}_{\text{bytes}}$ 是数据类型字节。系数 2 是 K 和 V 两份。MLA 等压缩注意力把 $n_{kv}\cdot d_h$ 换成 latent 维度。

容量墙是 perf model 最干净的产出——它只数字节,不碰 $\eta$,不碰时序假设。跨芯片切分(TP/CP)通过把 KV 分摊到多张卡推高这堵墙,代价是引入卡间通信。

但 LLM-Viewer 代码计算了各层字节数却无显式容量约束不等式,硬件参数文件无 HBM 总容量字段——这表明纯 bottleneck 分类工具可以不要容量墙,但部署选型工具必须有。

内存碎片在 perf model 里的处理​

vLLM PagedAttention 论文[5] verbatim:

existing systems suffer from severe memory fragmentation and over-provisioning. They waste 60% to 80% of the available KV cache memory.

results in near-optimal memory usage, with less than 4% waste.

对 perf model 的影响:容量墙公式必须乘一个有效利用率因子 $\rho$:

$$\begin{equation} b \cdot s \le \rho \cdot \frac{M_{\text{HBM}} - M_{\text{weight}}}{2 \cdot L \cdot n_{kv} \cdot d_h \cdot \text{dtype}_{\text{bytes}}} \label{eq:ipm-m-cap-with-rho} \end{equation}$$

预分配年代 $\rho \approx 0.20\text{--}0.40$,分页后 $\rho \approx 0.96+$。LLM-Viewer / Calculon 无显式碎片建模,忽略它会在长上下文高并发下高估可服务并发。

为什么 decode 是带宽受限​

prefill 一次处理整段序列,QKV 投影是 GEMM(矩阵乘矩阵),算术强度高;decode 每步只生成一个 token,QKV 退化为 GEMV(矩阵乘向量),算术强度低。Calculon 给出解析公式 $\text{AI} = 2/b$(b 是权重字节),验证了"量化直接翻倍 AI"——这是 perf model 中"量化为何能加速 decode"的核心机制。

LLM-Viewer Table 1 实测 LLaMA-2-7B 全层 decode 算术强度 $\approx 1$ FLOP/byte(verbatim:"in the decode stage, all computations are memory-bound"),比 A100 turning point($\approx 156$)低两个数量级。结论:decode 延迟由"把权重和 KV 从 HBM 读一遍要多久"决定,几乎与算力无关——这是 perf model 里最可信的部分,因为它只碰带宽不碰标不准的算力。

Trace-Replay 档:实测带宽与 $\eta_M$ 反推​

profile-based 把 $\eta_M$ 标定从纸面挪到实测。

STREAM 与 NCU 的工具链​

STREAM benchmark[6]:四种 kernel(Copy/Scale/Add/Triad,字节计数 16/16/24/24 B),Triad 是标准报告用 kernel。流程:跑 STREAM Triad → 拿 bw_sustainable → $\eta_M = \text{bw\_sustainable} / \text{bw\_peak}$ → 代入 roofline attainable。

NVIDIA Nsight Compute 关键指标(均 verbatim):

  • DRAM 流量:dram__bytes_read.sum / dram__bytes_write.sum
  • L2 hit rate:lts__t_sectors_hit_rate.pct
  • L1/TEX bank conflict 示例:l1tex__data_bank_conflicts_pipe_lsu.sum

易踩坑:NCU 的"Memory Throughput"是多子系统 $\max$,不是单一 metric,不等同于 DRAM 带宽百分比——直接拿这个数当 $\eta_M$ 标定会偏。

CUPTI:per-kernel DRAM traffic 需走 Profiler Host API / Range Profiler(cuptiProfilerHostGetBaseMetrics() 枚举 dram__bytes_*)。Activity API 的 CUPTI_ACTIVITY_KIND_KERNEL 不直接携带 DRAM 字节字段——这是新人常错的一个 API 边界。

Vidur / vTrain 的 memory profile 用法​

两者都用 CUPTI 抓 kernel execution time 作黑盒,不做独立 DRAM bandwidth 标定:

  • Vidur[7] 用 random forest 对 batch / seqlen 参数插值,全场景误差 < 9%(verbatim)
  • vTrain[8] 用 kernel trace 查找表 + 通信解析模型(含 $\alpha$ 调参),但 $\alpha$ 针对网络带宽非内存带宽

判断:trace-replay 在 memory 域的实际做法是"绕开 $\eta_M$",直接把"端到端 kernel 时间"作为基本单元——这与 compute 域的 trace-replay 同构。代价是不可移植到新形状/新硬件,优势是回避了 $\eta_M$ 标定的全部不确定性。

Cycle-Approx 档:DRAM 控制器仿真 + SRAM 层级​

cycle-approx 档下,memory 资源域分两层各有专门工具:DRAM/HBM 控制器仿真器(Ramulator / DRAMsim3)管片外,SRAM/cache 仿真(gem5 Ruby、SystemC)管片内。

DRAM/HBM 控制器仿真​

Ramulator 1.0[9] 与 Ramulator 2.0[10]:

  • 1.0(CMU-SAFARI,IEEE CAL 2015):支持 DDR3/4、LPDDR3/4、GDDR5、WIO/WIO2、HBM 及多个学术提案;C++ trace-driven,FR-FCFS 调度可插拔;速度比 DRAMsim2 快 $2.5\times$
  • 2.0(IEEE LCA 2023):C++20 重构,组件接口化;新增 DDR5/LPDDR5/HBM3/GDDR6;streaming 190.8K req/sec(vs 1.0 156.7K、DRAMsim3 132.3K)

DRAMsim3[11](Li et al., IEEE CAL 2020):支持 DDR3/4、LPDDR3/4、GDDR5/6、HBM、HMC、STT-MRAM;含 thermal 模块;集成 API 为 AddTransaction + ClockTick + RegisterCallbacks 三调用模式。

集成模式:三种——嵌入式库(gem5 全系统)、standalone trace-driven(Ramulator 独跑)、SystemC 封装。对 LLM perf model 实用路径:perf model 生成 trace → Ramulator standalone 标定 → 反馈 $\eta_M$ 校准值。直接 cycle-approx 跑全部推理速度太慢,标定后回灌 analytical 是性价比最高的混合做法。

HBM 利用率的细粒度建模​

cycle-approx 才能捕获的关键效应:

  • Bank group 无交错:信道利用率上限 $\le 50\%$(Ramulator 文档有据数值)
  • Bank conflict:导致延迟增加数百至数千 ns 量级
  • Row buffer hit / miss:LLM 长序列大步长访问导致 row buffer hit 率低,bank group 并行是主要补偿
  • Per-bank refresh:减少 stall 但 overhead 因协议而异

这些效应解析 roofline 看不到——它们正是"为什么 $\eta_M$ 不是 1"的物理来源。cycle-approx 标定再反喂 analytical 的 $\eta_M$,就把这些机制折算成一个可用的标量。

解析模型 vs DRAM cycle-approx 仿真的取舍​

维度解析 BW × $\eta_M$Ramulator/DRAMsim3 standalone
速度秒级$\sim 100$K req/sec(慢 4-5 个量级)
能捕获主趋势bank conflict / refresh / command reorder 微架构效应
用途早期 DSE、相对排序$\eta_M$ 标定、局部延迟尖刺分析

@tbl-ipm-m-dram-tradeoff DRAM 解析模型与 cycle-approx 仿真的取舍

SRAM 层级与 scratchpad vs cache​

gem5 Ruby 内存层级仿真:能建 cache coherence(MOESI/MESI)、CHI 互联,定位是通用 CPU 系统仿真。对 AI 加速器有一个根本错位——AI 加速器的 SRAM 通常是软件显式管理的 scratchpad,不是硬件管理的 cache。

  • GPU(NVIDIA H100、AMD MI300):SM 内的 L1 / shared memory 部分可作 scratchpad(__shared__)部分作 cache,perf model 需要分清楚
  • TPU、华为达芬奇、Eyeriss:几乎全是 scratchpad,DMA 显式搬数据

对建模的含义:

  • scratchpad 建模 = 容量约束 + DMA 事件,不涉及 hit / miss 概率
  • cache 建模 = hit rate 概率 + miss latency,需 working set 分析

这两条路在 cycle-approx 档完全不同。用 gem5 Ruby 默认 cache 模型套到 NPU 上,会高估命中率、漏算 DMA 开销。

DMA 引擎建模​

scratchpad 架构下 DMA 是头等公民。常见建模做法:

  • Descriptor-based:DMA descriptor(src/dst/size)作为事件提交到 DMA 引擎模块,DMA 引擎按 channel 数并发处理
  • Trigger-based:计算 unit 显式发起搬运,DMA 共享 HBM 通道与计算时序协调

与计算的耦合:DMA 与计算是否 overlap,在 cycle-approx 档由事件驱动机制决定(同资源串行、不同资源并发,见 05 Scheduler 篇)——这与 compute 域的 SystemC AT 处理一致。

LLM-Specific 内存挑战​

KV cache 作为 perf model 的资源​

KV cache 字节公式见 。代入实例:Llama-2-7B FP16 $\approx 0.5$ MB/token。Layout 通常为 BNSD,PagedAttention 将其 block 化但不改变总字节公式。

在 perf model 中 KV 是双重资源:

  • 容量约束:决定 max batch × seq(容量墙)
  • 带宽约束:decode 每 step 全量读取,算术强度 $\approx 1$ FLOP/byte,memory-bandwidth bound

激活内存​

无 FlashAttention 时 attention score 是 $O(BS^2H)$ 二次爆炸,公式 $\text{Act} \approx B\cdot S\cdot H \cdot (34 + 5\cdot S\cdot n_{\text{heads}}/H)$。有 FlashAttention(现代推理默认)退化为 $O(S)$ 线性,约 $5\cdot B\cdot S\cdot d_{\text{model}}$ bytes。长上下文场景下 KV 是主导变量,激活是次要项——这是简化版 perf model 常省略激活内存的合理性来源。

PagedAttention 间接表访问开销​

精确 kernel 建模可加 $\lceil S/\text{block\_size}\rceil \cdot t_{\text{lookup}}$($t_{\text{lookup}} \sim 5\text{--}20$ ns)。系统吞吐模型用 $0.96\times$ HBM 有效容量 + 1-3% overhead factor 即可——粗模型粗用。

KV offloading 到 CPU DRAM / NVMe​

三层带宽典型值:

层带宽
HBM$\sim 3.35$ TB/s
CPU DRAM$\sim 64$ GB/s
NVMe$\sim 2$ GB/s

FlexGen[12] 实测数据。$t_{\text{reload}} = \text{KV\_bytes}/\text{BW(tier)}$:50 GB KV 从 NVMe reload $\approx 25{,}000$ ms,从 CPU DRAM $\approx 800$ ms。Overlap 把 additive 转为 $\max(\text{compute}, \text{transfer})$,NVMe 场景几乎无法隐藏延迟——这是部署选型的硬约束。

KV 量化建模​

字节减少通过替换 $\text{dtype}_{\text{bytes}}$ 实现:

  • FP8 → 50%(实测约 54%,含 scale overhead)
  • INT4 → 25%(group 量化实际约 26.6%)

反量化开销:dequant 计算在 SRAM 内完成,不产生额外 HBM 传输;FP8 H100 原生支持 overhead $\approx 0$,INT8 fused kernel overhead 6-58 ms。KV 量化(动态,per decode step)与权重量化(静态,离线)独立建模,两项直接相加。

范式有向图​

memory 域内各档与工具的标定依赖:

图 8.3: memory 域内的范式有向图(边=标定依赖)

关键观察:G5 这一档(cycle-approx)在 memory 域的产出有两类——HBM 控制器侧标定 $\eta_M$ 回喂 analytical,SRAM/DMA 侧给 event-driven 提供 scratchpad 占用与 DMA 时序画像。

升降档判据(memory 域)​

  • 回答容量问题:能不能放下、KV 增长多快、量化省多少——analytical 容量墙公式足够,不需要升档
  • 回答带宽问题(端到端预测):用 GenZ 风格的 $\eta_M$ 分段曲线 + STREAM 标定够,仅当 $\eta_M$ 系统偏差 > 15% 才需要升 cycle-approx 重新标定
  • 回答局部延迟尖刺(P99 / 长尾):必须 cycle-approx DRAM 仿真,因为尖刺来自 bank conflict / refresh,解析模型看不到
  • 回答 scratchpad / DMA 设计选择:必须 cycle-approx + 显式 DMA 建模,gem5 Ruby 默认 cache 模型不适用

Takeaway​

知识点核心结论
三种带宽peak / sustainable / attainable 区分清楚,$\eta_M$ 用 sustainable/peak
容量墙最可信的建模产出,只数字节,必须乘有效利用率 $\rho$
decode 带宽受限算术强度 $\approx 2/b$,量化直接翻倍 AI——这是量化加速的核心机制
内存碎片PagedAttention 60-80% → < 4%(论文 verbatim),perf model 必须挂 $\rho$
DRAM cycle-approxRamulator/DRAMsim3 用于 $\eta_M$ 标定,不直接做端到端
Scratchpad vs cacheAI 加速器多为 scratchpad,gem5 Ruby 默认 cache 模型套上去会失真
KV 多层存储HBM/DRAM/NVMe 带宽差 100-1000×,NVMe 不能隐藏延迟,部署硬约束

开放问题​

  • AI 加速器 scratchpad 在 SystemC AT 的标准建模模式尚无业界共识——学术工具各做各的(待 sub_3 调研补强后修订)
  • 多芯片场景下 HBM 带宽与片间 c2c 带宽是否互相竞争,在 perf model 里通常作为独立资源,真实情形可能耦合——见 04 Interconnect 篇
  • KV offloading 的 prefetch 调度策略对 perf model 的反作用(prefetch 失败导致 stall vs 命中 hides latency)尚无简洁的解析建模

参考资料​

  1. Yuan et al., LLM Inference Unveiled: Survey and Roofline Model Insights, 2024. https://arxiv.org/abs/2402.16363
  2. Bambhaniya et al., GenZ: LLM Inference Platform Analysis, 2024. https://arxiv.org/abs/2406.01698
  3. Isaev et al., Calculon: a Methodology and Tool for High-Level Co-Design of Systems and LLMs, SC 2023. https://arxiv.org/abs/2307.02047
  4. Zhang et al., LLMCompass: A Hardware Evaluation Framework for LLM Inference, 2023. https://arxiv.org/abs/2312.03134
  5. Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention, SOSP 2023. https://arxiv.org/abs/2309.06180
  6. McCalpin, STREAM Benchmark. https://www.cs.virginia.edu/stream/ref.html
  7. Agrawal et al., Vidur: A Large-Scale Simulation Framework for LLM Inference, MLSys 2024. https://arxiv.org/abs/2405.05465
  8. Bang et al., vTrain: A Simulation Framework for Evaluating Cost-effective and Compute-optimal LLM Training, MICRO 2024. https://arxiv.org/abs/2312.12391
  9. Kim et al., Ramulator: A Fast and Extensible DRAM Simulator, IEEE CAL 2015. https://users.ece.cmu.edu/~omutlu/pub/ramulator_dram_simulator-ieee-cal15.pdf
  10. Luo et al., Ramulator 2.0, IEEE LCA 2023. https://arxiv.org/abs/2308.11030
  11. Li et al., DRAMsim3: A Cycle-Accurate, Thermal-Capable DRAM Simulator, IEEE CAL 2020. https://user.eng.umd.edu/~blj/papers/cal2020.pdf
  12. Sheng et al., FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU, 2023. https://arxiv.org/abs/2303.06865

延伸阅读​