鄂奎阿做性能优化这些年，我最大的感受是：很多人一听到“高性能计算”，脑子里第一个反应就是“核数够不够、主频高不高、GPU是不是顶配”。但真正跑过大规模程序的人都知道，大部分性能杀手根本不在算力上，而在访存。CPU占用率跑满，吞吐却死活上不去，perf一抓，cache miss高得离谱——这种情况我遇到过太多次了。
更值得注意的是，这个问题换了身衣服又出现在大模型推理里。vLLM 为什么那么强调优化大模型缓存命中率？因为 KV Cache 命中率高不高，直接决定推理服务的首字延迟和吞吐。高性能计算里的缓存优化，和 LLM 推理里的缓存优化，底层逻辑其实是同一个：怎么让访问速度快的存储层级多命中，怎么让慢速存储少拖后腿。
这篇文章就从我自己的调优实践出发，把高性能计算缓存优化这件事从 CPU 三级缓存一路讲到 vLLM 的 Prefix Cache，把所有“为什么这么做”都说清楚，最后附上我踩过的坑。适合正在做计算加速的开发者、跑推理服务的运维，以及所有被访存性能卡住的同学。
1. 缓存优化的本质：CPU三级缓存与KV Cache在解决同一个问题
1.1 命中率为什么是高性能计算的“隐形天花板”
先看一张存储层级的典型数据，不同架构有差异，但量级基本一致：
| 存储层级 | 容量 | 访问延迟 | 带宽特征 |
|---|---|---|---|
| L1 Cache | 32-64KB | 约1ns | 极高 |
| L2 Cache | 256KB-1MB | 约4-10ns | 高 |
| L3 Cache | 8-64MB | 约15-50ns | 中等 |
| DRAM | GB级 | 约80-120ns | 瓶颈所在 |
| SSD/HDD | TB级 | 微秒-毫秒级 | 极低 |
L1 和 DRAM 之间差了两位数的延迟。这个差距意味着什么？一个程序如果执行一亿次访存操作，L1 全命中大概 0.1 秒，DRAM 全缺失可能要 10 秒。CPU 再快，数据送不到寄存器里就是白搭。
很多数值计算程序表面上在拼命算浮点，实际干的事是“等数据”——等 DRAM 把数据搬到 Cache 里。这就是为什么有些并行程序开了 128 个核，加速比却只有 20 倍，瓶颈几乎总是访存。
1.2 时间局部性与空间局部性：最基础的两个抓手
缓存优化的理论根基就两个词：时间局部性和空间局部性。
- 时间局部性：同一份数据在短时间内被反复访问。比如内层循环里的累加变量、反复读取的权重矩阵，这类数据应该让它一直留在 Cache 里。
- 空间局部性：程序访问的内存地址是连续的。CPU 加载缓存时是以 cache line 为单位的（通常是 64 字节），一次加载 64 字节，如果你把 16 个 float 按顺序访问完，那就是一条缓存行覆盖了所有有效数据。
生活化一点理解：Cache 就是厨房里的操作台，DRAM 是冰箱。你想做菜，最理想的状态是操作台上已经摆好了接下来几步需要用的所有食材。如果每炒一个菜都要去开一次冰箱，时间全耗在路上了。
大模型的 KV Cache 本质上也是这个逻辑。自回归生成时，模型算过的历史 token 的 Key 和 Value 矩阵被存下来，后续每个新 token 都要和它们做注意力计算。这就是典型的时间局部性——同一批 K/V 会被反复使用。而 KV Cache 按顺序存储、按块管理，对应的是空间局部性。理解了这一点，你就明白为什么传统 HPC 和 LLM 推理的缓存优化是同一套思想在不同场景下的落地。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 传统HPC里真正拉高命中率的三个手段：数据布局、分块、内存系统调优
2.1 数据结构重排：从结构体数组到数组结构体
这是性价比最高的一步，经常一个改动就能看到几个数量级的变化。问题出在缓存行利用率上。
举个例子。假设你在做粒子模拟，每个粒子有位置和速度六个浮点：
c复制struct Particle {
float x, y, z;
float vx, vy, vz;
};
Particle particles[N];
现在你只需要更新粒子的 x 坐标：
c复制for (int i = 0; i < N; i++) {
particles[i].x += particles[i].vx * dt;
}
看起来没问题，但注意 CPU 加载缓存行是按 64 字节一行的。每访问一个 particle，整条缓存行就把 x、y、z、vx、vy、vz 全都装进来了，一共 24 字节，其中你只用了 8 字节。有效利用率只有三分之一。剩下的数据这次可能用不到，下次访问又是新的缓存行。
把结构体数组（AoS）改成数组结构体（SoA）：
c复制struct ParticleData {
float *x;
float *y;
float *z;
float *vx;
float *vy;
float *vz;
};
遍历 x 时，float x[N] 是连续的。缓存行里装的全是 x 分量，一个不浪费。这种布局下有效利用率接近 100%，访存带宽压力直接降三分之一以上。
如果结构体字段太多，还可以考虑 AAoS（Array of Array of Structures），按“每个字段分块存储”折中。实际选型要根据访问模式来，核心原则很简单：遍历哪个字段，就让哪个字段在内存里连续。
另外提一个多线程场景下的坑：伪共享（false sharing）。两个线程各自修改不同变量，但这两个变量恰好落在同一条缓存行里，那么每次修改都会导致缓存行在核间反复失效。解决办法是给每个线程的变量做 padding，把它补到 64 字节对齐，让它独占一条缓存行。
2.2 分块循环Tiling：让数据块在Cache里多待一会
分块是数值计算里特别经典的一招，主要用来优化矩阵运算这类高访存密集度任务。
拿最朴素的矩阵乘法来说：
c复制for (i = 0; i < N; i++)
for (j = 0; j < N; j++)
for (k = 0; k < N; k++)
C[i][j] += A[i][k] * B[k][j];
这个三层循环的访存模式很糟糕。B 的访问是逐列跳跃的（编译器可能优化一部分），整个矩阵一旦超过 L2 容量，每次内层循环都在反复从 DRAM 搬运数据。
分块的思路是，把矩阵切成小块，让每个小块在循环期间整个留在 Cache 里：
c复制for (i = 0; i < N; i += BS)
for (j = 0; j < N; j += BS)
for (k = 0; k < N; k += BS)
for (ii = i; ii < i + BS; ii++)
for (jj = j; jj < j + BS; jj++)
for (kk = k; kk < k + BS; kk++)
C[ii][jj] += A[ii][kk] * B[kk][jj];
BS 的选择很关键。太小，块之间的复用被打断；太大，块又放不进 Cache。一般经验是先看 L2 缓存容量，让 A、B、C 三个块加起来能塞进 L2 的一到两倍。比如 L2 是 2MB，用双精度算，BS 取 64 时，一块 64x64 的矩阵占 32KB，三个块 96KB，完全装得下。
记住一点：分块参数是不可移植的。同一套代码在 A 机器上跑得飞快，换到 L3 更小或者 Cache 组织方式不同的机器上可能更差。所以要么做成可配置参数，要么在启动时探测缓存大小动态决定。
2.3 大页与NUMA绑定：两个容易被漏掉的系统级因素
程序层面的布局改完了，接下来看系统。两个最实用的调优点：大页和 NUMA 绑定。
Linux 默认页大小是 4KB。程序访问大数组时，CPU 需要通过 TLB（页表缓存）把虚拟地址翻译成物理地址。TLB 容量有限，如果代码要访问 1GB 数组，按 4KB 页就是 262144 个页表项，TLB 根本存不下，于是每次访问都可能触发页表遍历，拖慢访存。
用 2MB 大页，同样 1GB 数组只需要 512 项，TLB 基本不会 miss。对遍历大数组的程序来说，这个改动有时能带来 10%-30% 的收益。
NUMA 则是多路服务器上的经典问题。每个 CPU 访问自己本地的内存快，访问远端 CPU 的内存慢，延迟差 1.5-2 倍。很多程序性能上不去，是因为内存被“首次 touch”的线程分配在了某个远端节点上。解决办法是让进程绑定 CPU 节点的同时绑定内存节点：
bash复制numactl --cpunodebind=0 --membind=0 ./your_application
还有一个细节是“首次 touch”原则：内存页的物理位置由第一次访问它的线程决定。所以在多线程程序里，尽量让每个线程先初始化自己需要的那块数据，再进入计算循环，否则后面访问时可能全在远端内存上。
3. 大模型推理场景：vLLM的KV Cache与Prefix Cache命中率优化
3.1 KV Cache：自回归生成里最值得缓存的东西
大模型推理是自回归的——每生成一个 token，要把新的 token 拼到序列后面，再重新算一遍注意力。如果每次都不做缓存，每个新 token 都要重新计算之前所有 token 的 Key 和 Value，计算量随序列长度平方级增长，完全没法看。
KV Cache 把这个过程优化成了：算完一个 token 的 K 和 V 后，存下来，后续新 token 只需要算自己的 Q/K/V，再和历史 K/V 做注意力运算。生成第 N 个 token 时，注意力计算量是 O(N) 而不是 O(N²)。
代价是显存。KV Cache 占用的显存跟序列长度和 batch size 成正比，动不动就是几个 GB。vLLM 的 PagedAttention 做得比较聪明，把 KV Cache 切分成固定大小的块，用页表把逻辑块映射到物理块，类似操作系统的内存分页，大幅减少了显存碎片和调度开销。
3.2 Prefix Cache的命中规则：块哈希、公共前缀与命中粒度
在传统 HPC 里，我们关注的是 CPU 缓存命中；在推理服务里，vLLM 关注的是 KV Cache 的复用，具体实现叫 Automatic Prefix Caching（统称 Prefix Cache）。
它的核心逻辑是：把 prompt 按固定 token 数切成逻辑块（默认 block-size 是 16），对每个逻辑块内容算哈希，请求到达时，从第一个块开始逐一在缓存哈希表里找匹配。如果某个块的哈希和缓存里已有的块一致，就直接复用那个块的 KV Cache；一旦某个块没命中，从那里开始后面的 KV 都要重新计算。
这里有一个非常关键的理解点：前缀缓存的命中单位是“块”，不是“token”。假设 block-size 是 16，两个请求前 15 个 token 完全相同，第 16 个 token 不同，那么这个块整体不命中，缓存完全失效。所以业务侧想让命中率高，就得让公共部分对齐到块边界。
另一个容易踩的坑是：只要前缀里某个 token 变了，后面所有的 KV 全部失效。比如你在 prompt 最前面拼了一个动态的时间戳或者随机数，那这个请求和之前任何请求都没有公共前缀，Prefix Cache 形同虚设。
3.3 配置与业务侧改造：实际提升命中率的做法
先从配置说起。vLLM 较新版本里可以通过启动参数开启前缀缓存，老版本是：
bash复制vllm serve meta-llama/Llama-3.1-8B-Instruct --enable-prefix-caching
新版本默认开启，具体取决于版本，自己确认一下启动日志里有没有 prefix cache 相关的输出即可。
配置只是基础，真正决定命中率的是请求的 prompt 结构。我见过一个团队跑聊天机器人，系统提示词每次都不一样，拼接顺序也不同，几百个请求下来命中率几乎为零。后来做了三件事，吞吐立刻上了一个台阶：
- 统一的 system prompt 放在最前面。所有请求复用同一套系统提示词，让它成为最长、最稳定的公共前缀。
- 动态参数放末尾。用户 ID、时间、随机数等变化内容放在 prompt 最后，不打断前面的公共前缀。
- prompt 模板结构固定。不要今天这个顺序明天那个顺序，否则公共部分也被打散。
举个例子，推荐这样组织 prompt：
code复制你是电商客服机器人，请严格按以下规则回答：
规则1：...
规则2：...
<系统设定结束>
用户问题：{query}
历史对话：{context}
固定框架始终不变，只有最后两行变，这样前缀缓存能覆盖到系统指令部分。
我实际测试过一组业务：请求里公共系统提示词约占 300 token，开启前缀缓存后，首 token 延迟从 400-500ms 降到 200ms 左右，吞吐提升接近一倍，而且显存占用大幅下降。当然这个数字跟具体模型和硬件有关，但趋势是一致的。
补一句，如果你跑的是多模态输入，图片部分无法直接复用 KV Cache 的前缀逻辑，前缀缓存的收益会明显缩水，这类场景要另想办法。
4. 命中率不等于性能：带宽、缺失代价与应用场景的权衡
4.1 平均访存时间公式：为什么命中率不是唯一指标
做性能优化的人都容易陷入“命中率焦虑”——总觉得把命中率拉到 99% 才算成功。但真正决定性能的不是命中率，而是平均访存时间：
AMAT = Hit Time + Miss Rate × Miss Penalty
命中率只是中间变量，Miss Penalty（缺失代价）同样关键。有的场景里，一次 cache miss 要付出几十甚至上百纳秒的代价；但如果访问模式足够连续，现代 CPU 的硬件预取器能提前加载好数据，实际 Miss Penalty 会变小。
某次调优里，我碰到一个程序命中率已经到 95% 了，但性能还是很差。perf 一查才发现，真正的问题是它访问了太多分散的内存区域，每次 cache miss 都升级成 TLB miss，缺失代价比同类程序高好几倍。后来把数据改连续，命中率的数字只涨了 2 个百分点，端到端性能却翻了一倍——问题根本不在命中率，而在缺失代价。
所以我的指标建议是：同时盯三个数——命中率、缺失代价、有效带宽。只优化命中率是射偏靶心。
4.2 一个真实优化案例：从命中率95%到系统吞吐翻倍
拆一个我调过的真实场景：批量图像处理管线。输入是一批图片，每张要做降噪、特征提取、压缩三步。管线本身不复杂，但处理速度上不去。
第一步，perf 采集。cache-misses 率大概在 6% 左右，看起来不算灾难，但进一步下钻到函数级发现，特征提取阶段每次访问像素邻域都在跨页，TLB miss 非常密集。
第二步，改数据布局。把原始的内存中按“图片逐行”存储改成“图块重排”——把一张图切成小块，处理时尽量让邻域像素待在同一个 cache line 和同一页里。这一步让 TLB miss 大幅下降。
第三步，把循环分块。对邻域滤波操作做了 Loop Blocking，让一个小图块反复被内层循环访问时始终留在 L2 里。
结果很有意思：cache-misses 率从 6% 降到了 4.5%，数字变化不大，但整体吞吐翻了一倍。因为访存从“到处乱撞”变成了“集中爆发”，预取器开始起作用，缺失代价几乎减半。
这件事给我的教训就是：优化访问模式比纠结命中率数字有意义得多。命中率是结果，不是目标。
5. 定位缓存瓶颈：从perf到cachegrind的排查方法
5.1 perf:先看全局，再逐层下钻
Linux 自带的 perf 是我做性能分析的第一把刀。最基础的一步：
bash复制perf stat -e task-clock,cycles,instructions,cache-references,cache-misses ./your_program
执行完会输出几个关键数字，重点看 cache-misses 和 cache-references 的比例。注意 perf 统计的 cache-misses 通常是最后一级缓存（LLC）的缺失，不是 L1。
比例没有绝对标准，但个人经验是：如果 miss rate 超过 5%-10%，而且程序访存密集，那缓存问题大概率是主要瓶颈。如果 miss rate 只有 1%-2%，那你再花大力气优化缓存就是浪费时间。
进一步定位到函数级别，可以用：
bash复制perf record -e cache-misses ./your_program
perf report
它会按照 cache miss 次数给你排序出热点函数，一目了然。一个常见现象是：热点函数集中在几个数据搬运的地方，而不是计算密度高的地方。
5.2 cachegrind与确定性分析：精细优化阶段的利器
perf 适合看真实运行，但它的缺点是受系统状态影响，结果不稳定。当你做 AoS 到 SoA 这类结构性改动时，想精确对比改动前后 L1/L2 命中率的变化，我会用 Valgrind 中的 cachegrind：
bash复制valgrind --tool=cachegrind ./your_program
它会模拟 CPU 的 I1、D1、L2 缓存行为，上报命中率和访存分布。好处是确定性——同样的输入、同样的机器，跑出来的结果可复现，改动前后对比特别可靠。坏处是慢，通常比原生执行慢 10-50 倍，所以适合小规模输入做对比，不适合线上大规模压测。
两个工具配合的思路：先用 perf 确认瓶颈在缓存，再用 cachegrind 验证哪个改动真正改善了访存模式。
到了 vLLM 推理服务层面，就不太适合用这些 CPU 工具了。KV Cache 的命中情况主要看 vLLM 暴露的统计指标，比如 prefix cache hit rate、每个请求被缓存覆盖的 token 数。在日志或 metrics 里能找到这些数据，如果完全没有，可以加上日志观察公共前缀的分布情况。
6. 踩过的坑与一条务实的优化路线
6.1 优化顺序不能错：先算法，再缓存，最后系统参数
很多人一上来就调分块参数、开大页，连热点在哪儿都不知道。我给的顺序是固定的：
- 先做 profiling，确认瓶颈是访存而不是算法复杂度。
- 算法层面如果有明显可改进的地方（比如把 O(N²) 降下去），先降复杂度。
- 再优化数据布局和访存模式，这是缓存优化的甜点区。
- 最后做系统级配置：大页、NUMA 绑定、编译选项。
缓存优化永远是“常数系数”优化，它解决的是“带宽很足但用不好”的问题，解决不了“算法复杂度爆炸”的问题。顺序反了，你会花大量时间在一个根本不是瓶颈的地方打转。
6.2 缓存策略的正确性边界与回归风险
这里说几个容易翻车的点。
第一，大模型 Prefix Cache 有语义安全的边界。跨用户共享缓存时，vLLM 在缓存块层面做了管理，但业务侧也要清楚：如果两个请求共享了系统提示词部分的 KV，但用户上下文不同，这不会串内容，因为 KV 只用于注意力计算，不影响生成逻辑。不过如果你的业务有租户隔离要求，建议评估一下前缀缓存是否要在租户维度做隔离，别为了性能牺牲合规。
第二，数据结构重排会牺牲代码可读性。AoS 的结构体直观，SoA 的数组组织看起来像“散装数据”。改完之后一定要注释清楚为什么这么排，否则三个月后你自己回来看代码都会懵。
第三，分块参数不能硬编码。你用 2MB L2 的机器调的 BS=64，换到 1MB L2 的机器上可能反而变慢。建议做成环境变量或者启动时自动探测，别上班代码写死。
第四，任何缓存优化都要有回归验证。至少盯三个指标：吞吐、端到端延迟、命中率。如果命中率上升但端到端延迟没变，说明改的是无关紧要的路径；如果延迟上升但吞吐上升，也要确认是均值变了还是长尾变了。
我做了这么多性能优化，最后总结就一句话：永远先把热点数据找出来，再谈优化方案。无论 CPU 缓存还是 KV Cache，只要访问模式没搞清楚，所有的优化都是盲打。反过来，一旦你会用“时间局部性和空间局部性”这两个视角去分析程序，你会发现传统 HPC 和大模型推理的缓存优化其实是一件事。