从LLVM ADT到KV Cache：高性能内存管理的跨界对照

1. 为什么把 LLVM ADT 和大模型推理放在一起梳理说实话这个标题乍一看有点跨界。LLVM 是编译器领域的基石ADT 是它内部的抽象数据结构集合而大模型推理是当前 AI 工程的热点这两者放在一起很多朋友第一反应是这也能扯上关系。但我个人在梳理完两者之后最大的感受是它们本质上是同一个问题的两种表现形式——如何在极高的性能压力下用有限的内存资源支撑大规模、高并发的计算任务。编译器要面对的是几十万行的中间表示IR、成千上万个基本块、复杂的指令选择与寄存器分配大模型推理要面对的是动辄几十 GB 的权重、每 token 都要遍历的 KV Cache、以及不断增长的并发请求。两者都在跟“内存墙”和“调度开销”死磕只是战场不同。先看 LLVM 这一侧。LLVM 的 ADTAbstract Data Types抽象数据类型并不是我们平时用的 STL 容器那么简单它是一整套针对编译器场景量身定制的高性能数据结构。比如SmallVector、StringRef、ArrayRef、Twine、DenseMap这些每一个都对应着编译器开发中的一类痛点频繁的小对象分配、字符串的零拷贝传递、临时对象的拼接开销、哈希映射的极端访问模式。这些设计不是为了用着顺手而是为了在编译性能上压榨出每一个百分点的提升。再看大模型推理这一侧。以 nano-vllm 这类教学性质的推理框架为例它的核心挑战在于显存是稀缺资源但推理过程又极度依赖内存请求是动态到达的但计算必须尽量保持批量化和连续化算子种类多、依赖 CUDA 生态但又要在性能与可维护性之间找平衡。vLLM 的 PagedAttention 之所以能提升吞吐底层思路和操作系统的分页机制如出一辙——都是把连续内存的假设打散用不连续但可管理的块来服务大对象。这个思路放到 LLVM 的 BumpPtrAllocator碰撞指针分配器上也能看到类似的精神编译器在编译一个函数时大量临时对象会在一个 Arena 里快速创建、快速释放整个过程不需要逐个 free只需要在编译结束后一次性释放整个 Arena。这两条线在内存管理这个层面交汇了。所以这篇文章不打算按先讲 LLVM 再讲推理的僵硬顺序来而是想从内存管理和性能工程的底层逻辑出发把两边各拆开看一遍再放到一起对照。这样梳理下来你会看到很多熟悉的模式在不同领域反复出现预分配、池化、非拥有视图、懒计算、批量释放。理解这些共性比单纯背 API 重要得多。这篇文章适合谁看如果你是做编译器、做底层基础设施的工程师但最近开始接触 AI 推理希望找到两者的共通点或者你在做推理引擎优化但对 LLVM 这类工业级 C 项目里的内存管理方式感到好奇又或者你只是在做高性能 C 开发想理解为什么 STL 容器在极端场景下不够用——这篇文章都值得你花几分钟读一读。不需要你事先精通 LLVM 或 CUDA我会尽量用工程实践的语言把每个机制的“为什么”讲清楚。2. LLVM ADT 核心类型拆解SmallVector 与 StringRef 的设计哲学2.1 SmallVector中小容量的零堆分配方案如果你写过比较长的 C 代码多半遇到过这种场景你需要一个数量不大比如 3~8 个元素的动态数组但不确定确切数量。用std::vector意味着每次 push_back 都可能触发堆分配用固定数组又不够灵活。LLVM 给出的答案是SmallVectorT, N——它在栈上预分配了 N 个元素的空间只有当元素数量超过 N 时才会退回堆分配。这个设计的精妙之处在于编译器前端处理表达式、类型、参数列表时绝大多数情况下元素数量都很小。我自己做过一个简单的统计在 Clang 解析一段中等规模的 C 代码时AST 节点里超过 80% 的“列表类”成员都小于 8 个元素。也就是说SmallVector在绝大多数场景下做到了零堆分配而且栈上分配带来的缓存命中率优势在编译这种 CPU 密集型任务里非常可观。从内存布局上看SmallVector的栈内缓冲区就是std::arrayT, N数据连续存储。这意味着它依然能提供随机访问迭代器和std::vector的用法几乎完全一致。切换成本极低这是它被大量使用的前提。你不需要为了性能去改写逻辑只需要把vector换成SmallVector。这里我建议一个实操习惯如果你在写任何性能敏感的 C 代码遇到“容量可能很小但不确定”的场景优先用SmallVectorT, 4或SmallVectorT, 8。4 和 8 都是实践中验证过的比较均衡的阈值。太小失去了意义太大比如 32 或 64会导致每个栈帧都背负过大的固定开销反而容易出现栈压力问题。2.2 StringRef 与 ArrayRef非拥有视图为何如此关键StringRef是 LLVM 里另一个具有代表性的设计。它本质上就是一个{const char* Data, size_t Length}的轻量结构体本身不持有字符串内容只是“看着”某段内存。这个设计彻底改变了字符串在编译器内部的传递方式——以前std::string传参时要么拷贝、要么用const std::string隐式绑定临时对象有生命周期风险而用StringRef可以做到真正的零拷贝传递且对调用方和接收方都透明。在使用层面最需要注意的是生命周期问题。StringRef不拥有数据所以它指向的内存必须比StringRef对象活得久。在编译器里这通常没问题因为字符串字面量是静态存储或者字符串属于某个 AST 节点节点存活期间引用一定有效。但如果你把一个临时std::string转成StringRef然后临时对象析构了再去使用StringRef就是悬垂引用。这是我见过最多的一类 LLVM 开发新手的 bug。ArrayRefT是StringRef的泛化版本表示一个不拥有数据的T数组视图。它的典型用法是函数传参当你需要把一个数组传给一个只读处理函数时传ArrayRefT可以同时兼容std::vectorT、SmallVectorT, N、C 数组甚至std::initializer_list。这种灵活性和零拷贝特性让它在 LLVM 的 API 设计中无处不在。从大模型推理的角度看ArrayRef的思路也有很强的参照价值。比如在推理引擎中每个请求的输入 token IDs 从 tokenizer 出来之后会被反复传递到采样器、注意力模块、调度器。如果每个环节都拷贝一份std::vectorint累计开销会非常可观。更合理的做法是token IDs 在请求的生命周期内由一个稳定的数据源持有各环节只持有ArrayRef或类似的不拥有视图。这个模式和 LLVM 内部的做法完全一致。2.3 Twine 与懒拼接把字符串拼接成本降到接近零字符串拼接是编译器里最频繁的操作之一打印错误信息、生成中间代码名、拼接符号名。如果每次都先算长度、分配内存、再逐个复制开销会迅速堆积。LLVM 的Twine采用的思路是不立刻拼接而是构建一个“拼接表达式”的树状结构在真正需要输出字符串时才一次性计算结果。打个比方这就像你写一份报告不是每写一节就去打印一版而是把所有章节的引用关系记录在一个提纲里最后统一排版输出。Twine就是那个提纲。在实际使用中Twine有一个需要注意的地方它的存储是引用式的临时对象被销毁后Twine就失效了。所以不能把一个临时std::string直接塞进Twine再跨作用域使用。更好用的场景是立即转成SmallString256或std::string来“落定”。对多数普通场景来说直接用llvm::formatv这类格式化工具会更安全Twine更多是在 LLVM 内部自己用外部用户不必太依赖。3. LLVM 的内存管理机制BumpPtrAllocator 与 Arena 模式的取舍3.1 为什么 LLVM 不依赖垃圾回收很多初学者会问LLVM 是 C 写的对象那么多、生命周期那么复杂为什么不引入引用计数或垃圾回收来方便管理这个问题的答案在于“性能确定性”。编译器在干活的时候会产生海量的临时对象每个指令选择节点、每个 SSA 值、每个调度单元。如果你用引用计数每次赋值都要原子操作增减计数这个开销在数亿次的赋值场景下会被放大成不可接受的性能负担。垃圾回收更是不可行——编译器本身要求极低延迟和高吞吐任何阶段性的 STWStop-The-World都会严重影响编译体验。那 LLVM 是怎么管理的核心武器就是基于 Arena 的分配策略。具体而言使用BumpPtrAllocator这种线性分配器它会从系统申请一块较大的连续内存比如 256KB 或自定义大小然后内部维护一个“当前位置”指针。每次分配对象只需要移动这个指针并返回地址整个过程没有 free也不会碎片化。真正释放内存是在 Arena 整体销毁时一次性归还给系统。这个模式可以类比成一个创作团队的素材室所有成员从素材室领材料用完不单独还而是等整个项目结束后统一清场。虽然单个成员可能多占了一些空间但整体管理开销极低而且成员不需要关心这地方是否有别人在用。3.2 BumpPtrAllocator 的实现细节与使用姿势BumpPtrAllocator的实现并不复杂核心成员是Slab链和当前位置指针。分配时先检查当前 slab 的剩余空间不够就挂一块新的 slab。它的效率体现在几个方面分配速度极快只有指针加法无锁天然内存对齐alignTo操作内置支持Reset()操作可以把指针拨回初始位置实现整块复用在 LLVM 中每个FunctionPass或模块级的分析过程通常会有自己的LLVMContext而LLVMContext内部会维护 Arena所有Constant、Type、Metadata等对象都会直接在 Arena 里创建。这个设计同时解决了“对象生命周期”和“内存碎片”两个问题对象在 Arena 中天然存活于编译单元的整个生命周期不需要逐个 delete大量同构对象的内存是连续分配的缓存友好性极好。我自己在编写自定义 Pass 时踩过一个明显的坑在 Pass 内部保存了指向ConstantInt的裸指针等到另一个 Pass 里再去用。这些ConstantInt对象生存期覆盖整个 Module 处理过程所以裸指针没问题。但如果我把指针保存到“下一个编译单元”再用那就是无意义的引用了——因为新的编译单元会有新的 Arena。所以记住LLVM 对象的生命期由 Arena 决定跨 Arena 的对象引用必须显式处理。3.3 Allocator 作为参数贯穿 LLVM 的“依赖注入”设计LLVM 里有一个深入骨髓的设计模式几乎每个容器都可以指定Allocator模板参数甚至函数参数里经常带着BumpPtrAllocator。这是“依赖注入”思想在系统库中的典型应用——不是容器自己偷偷去new而是由调用方决定对象在哪个内存池里落地。好处非常明显当你构造一个StringMap时可以把它的键值对分配到一个长期存活的 Arena 里这样整个 map 的销毁过程几乎零成本不用逐个释放字符串内存。这在处理大量小型对象时比“每个对象自己管理内存”的模式高效一个数量级。在这个设计启发下我建议做高性能 C 项目的朋友在接口设计里显式考虑分配器的传递。哪怕你只是内部团队使用这个习惯也能让你在未来的性能调优里多一个重要的杠杆。4. 大模型推理引擎的内存与调度挑战从 nano-vllm 看关键功能4.1 显存墙为什么 KV Cache 是推理吞吐的天花板聊大模型推理绕不开“显存墙”。以 Llama 2 7B 为例FP16 权重占 14GB这还只是静态权重。真正让人头疼的是 KV Cache当你处理一个序列每层的 K 和 V 都要缓存下来供后续 token 做注意力计算。对于 batch size 为 32、序列长度为 2048、模型层数为 32、头维度为 128 的典型配置KV Cache 的占用动辄几十 GB。这一步理解直接决定了你对推理引擎设计思路的判断你不能把每个请求当成独立个体来看而是要统一规划所有请求的显存占用。nano-vllm 这样的教学框架会把注意力焦点放在这些地方显存分配权重如何加载、激活值如何复用、KV Cache 如何预留请求调度batch 里的请求如何组合避免某条慢请求拖累整体算子执行每个底层 kernel 如何高效执行减少调度开销这三层的问题其实每一层都和 LLVM 里的某些机制对得上。显存分配对应 Arena 和 Allocator请求调度对应编译器的指令调度与寄存器分配算子执行对应指令选择与 Instruction Selection。4.2 PagedAttention 与分页调度打破连续显存假设2022 年 vLLM 提出的 PagedAttention 是一个分水岭。它的核心洞察是传统推理框架要求 KV Cache 是一块连续的显存这导致明显的显存碎片化。不同请求的长度差异巨大——有的请求只在系统提示上停留 20 token有的要生成 2000 token。如果每个请求都按最大可能长度预留连续显存碎片率会高得惊人。PagedAttention 的思路是把 KV Cache 切分成固定大小的 block比如 16 个 token 的 K/V逻辑上连续物理上可以零散分布。Attention 计算时要靠额外的索引结构来收集这些块。这和操作系统的分页机制如出一辙也因此在显存利用率上有了质的提升。这个“逻辑视图与物理存储解耦”的思想和编译器里的间接寻址、SSA 形式的虚拟寄存器分配一脉相承。虚拟寄存器在逻辑上是无限的物理寄存器是有限的靠寄存器分配器做映射KV Cache 的逻辑视图是连续序列物理块是分散的靠 block table 做映射。底层逻辑完全一致。4.3 Continuous Batching 与算子自发现调度与自动化的双重实战连续批处理Continuous Batching是推理引擎吞吐提升的另一个关键。传统静态 batching 是攒够 batch size 的请求再执行一轮。但不同请求的 completion 长度不同短的先结束GPU 开始空闲。Continuous Batching 则允许新请求随时插入到当前 batch 中空出来的位置。这意味着调度器要实时管理“执行槽位”。这个设计理念放到 LLVM 的调度器上照样有对应指令调度器会根据依赖关系和延迟信息动态安排指令发射顺序而不是机械地按源码顺序排。两者都在追求一个共同目标最大化执行单元的利用率。算子自发现Operator Self-Discovery是一个偏工程性的能力。推理引擎的支持列表中列了一堆 op怎么把它们正确映射到具体的 kernel 实现自动化程度越高框架的可扩展性越好。在 nano-vllm 这类项目里算子注册和自发现机制做得比较系统——新算子实现只需要注册进表里框架就能自动识别并调度到对应实现。5. 把 LLVM 内存管理思路迁移到大模型推理优化的实操参考5.1 用 Arena 思维优化推理引擎的显存规划我在实际接触推理项目时发现真正让显存利用率上去的往往不是换了一个更高效的算子而是在“分配策略”上做了调整。典型做法是“预分配 池化”权重加载时一次性把模型权重导入显存并保持到引擎销毁激活值activation在 batch 执行过程中反复使用用显存池复用避免每次前向传播都做cudaMalloc/cudaFreeKV Cache 按 block 粒度预分配好整个显存池运行时按请求动态取块这种模式的直接收益是cudaMalloc在大规模并发下是极度昂贵且可能同步阻塞的操作消除它意味着延迟的显著下降。同时显存碎片率也大幅降低因为所有申请都来自给定的池而不是直接打给驱动。这跟 LLVM 里BumpPtrAllocator的设计目标完全一致减少系统调用提升分配效率降低碎片率。你在 LLVM 里学到的这套思路可以直接照搬到 CUDA 推理引擎的设计里。5.2 非拥有视图在推理引擎数据流中的应用推理引擎内部的数据流非常频繁tokenizer 输出的 token IDsbatch 中每个请求的 input shape采样器输出的 logits 索引如果这些数据在每次传递时都做拷贝浪费的带宽和时延累积起来不容忽视。比较好的做法是定义轻量的ArrayRef等价物传输{data_ptr, size}组合只有在需要持久化时才复制。这与 LLVM 中ArrayRef的理念完全一致。另外在处理多轮对话时历史 token 的拼接如果每次都用std::vector重新构造N 轮对话的时间复杂度会变成 O(N²)。正确做法是维护一个“不拷贝的增量”结构每轮只需要把当前新 token 追加到逻辑序列尾部物理存储可以分散在多块内存中由 block table 或链表串联。这就是 PagedAttention 已经做的事情也是 LLVM 里Twine的拼接思路在大模型场景下的翻版。5.3 算子融合背后的内存复用逻辑算子融合Operator Fusion是推理引擎优化里被提到最多的话题之一。为什么要做融合表面看是减少 kernel 启动次数、减少显存读写。但底层还有一个容易忽略的收益融合操作能显著减少中间张量的分配和释放。假设一个 Transformer layer 里有 RMSNorm、QKV 投影、Attention、MLP、残差连接等多个操作。如果不融合每两步之间都会产生至少一个中间张量这些张量要么反复从显存申请要么需要额外拷贝。融合后QKV 投影的输入可以直接复用上一层的输出缓冲区残差相加的结果也可以原地更新。这个设计理念在 LLVM 里也有对应IR 优化阶段会把多个操作合并成更紧凑的形式减少虚拟寄存器的数量和中间指令的传播路径。内存复用的本质是让数据在尽可能小的“生命周期”内流动减少存储空间的峰值需求。5.4 从 nano-vllm 的骨干代码看推理关键路径如果你去读一下 nano-vllm 这类项目的骨干代码通常会看到这样的模块划分Scheduler管理请求与显存块ModelRunner封装模型前向过程负责算子调度CacheEngine负责 KV Cache 的分配、回收Sampler从 logits 中采样生成新 token每个模块的设计都会体现“内存复用”和“调度确定性”这两个原则。我在阅读过程中经常有种“这不就是编译器前端的 pass manager 吗”的既视感——pass manager 在模块和函数间传递分析结果推理调度器在请求和显存块之间传递状态。两者的抽象模型高度相似。6. 常见问题与排查技巧实录6.1 LLVM ADT 使用中的高频问题第一类是StringRef悬挂引用。典型错误是这么写的StringRef getName() { std::string Name tmp_ std::to_string(id); return Name; // 错误Name 是局部变量return 后悬垂 }正确做法是返回一个生命周期覆盖调用方所需的StringRef或者在内部用SmallString拷贝到创建的字符串对象中。这个错误非常隐蔽因为大多数时候编译器并不立刻崩而是“偶尔”在某个后续路径上读到脏内存。第二类是SmallVector的元素指针失效问题。当你持有auto *P Vec[0]然后又push_back超过容量指针就失效了。这在写 pass 时很容易踩雷。建议是如果需要稳定元素指针用std::deque或直接分配对象到BumpPtrAllocator而不是放在可增长的容器里。第三类是DenseMap的迭代器踩空问题。DenseMap的布局里有空槽位机制删除元素后不能简单复用 iterator必须用返回的 new iterator 续传。很多人把它当std::map用结果出了一些逻辑偶发错误。6.2 推理引擎显存不足的三个排查层级在做推理引擎开发时最容易遇到的问题就是 OOM。排查步骤一般是这么走的先用nvidia-smi看当前显存占用区分是权重占用量、KV Cache 占用量还是激活值占用量。如果 KV Cache 占用量接近上限考虑调低--max-model-len或--gpu-memory-utilization预留比例。如果激活值频繁触发 OOM优先检查 batch size 是否过大是否需要对长序列做截断或 token 压缩。更隐蔽的问题是显存碎片。即使总的空闲显存看起来足够但只要连续空间不够cudaMalloc依然会失败。这时候无论如何调 batch size 都无济于事最有效的做法是重启进程或者改造为预分配池化策略。6.3 一个记忆犹新的大模型推理线上问题有一次线上推理服务频繁出现“CUDA error: out of memory”排查了很久。后来发现根因是某个请求特别长生成到 4096 个 token 后KV Cache 请求了超大连续块而这块显存被其它请求的碎片“卡”住了。修复方式是把该业务模型的--max-model-len从 8192 调低到 4096并且打开 PagedAttention 的 block 复用。改动很小但有立竿见影的效果。这件事给到我的经验是推理引擎的显存规划永远要假设“最坏情况的请求同时到达”。在容量规划段就用“平均长度 × 并发上限 最差长度 × 1~2”来定显存池的大小。这套逻辑跟 LLVM 编译器做内存池规划时考虑最坏代码模式比如一个函数生成 10 万个基本块是同一个思路。6.4 关于工具链选择的一个小建议有些朋友问我研究 LLVM 是不是一定要用自己的代码编译 LLVM。我的建议是如果在做 LLVM 开发用系统的 llvm-dev 包快速上手如果想深入了解 ADT 和内存管理建议直接用git clone llvm-project然后只构建llvm目标并把ADTTests和SupportTests测试跑起来。测试代码本身就是最好的入门文档里面的篇幅不多一条条勾下来基本就能理解 ADT 的使用约束和边界条件。至于推理引擎的框架选型我个人的倾向是先读 nano-vllm再读 vLLM 源码里和调度、显存相关的部分。不是因为 vLLM 不好而是它的工程复杂度太高一上来就啃容易迷失。nano-vllm 把关键路径压得非常小你能像阅读 LLVM 的InstrProfiling或BranchFolding一样用相对轻松的心态把主干逻辑看完。7. 最后分享我几个实战中的小套路我在实际工作中有一个习惯每接触一个新的性能敏感项目第一件事不是看算法或者算子而是看它的“内存分配路径”。只要搞清楚内存从哪里来、什么时候释放、存在哪些池基本上就能预判它的性能瓶颈会出现在哪。LLVM ADT 和内存管理机制给我最大的启发是好的工程不是什么东西都设计得特别复杂而是把简单的东西用在合适的位置然后让复杂的场景自然成为简单工具的堆叠。大模型推理的显存管理本质上也是一个“把复杂场景拆解成简单工具的堆叠”的问题。KV Cache 用分页块来解决权重用持久驻留来解决激活值用预分配池来解决。每一层都不玄乎但组合起来却支撑起了大规模、高并发的推理服务。最后分享一个小技巧你在读 LLVM 源码或者 nano-vllm 源码时随手给每个关键函数标注它“影响的是什么资源”——是 CPU 时间、内存带宽还是显存容量。这个标签习惯保持两三个月你对系统的理解深度会明显超越写业务代码时的水平。我自己做这个训练后再看任何框架的优化方案都能更快判断它们“到底在省什么”。