LLVM 这套东西很多人第一次接触都是从我想写个编译器或者我想看懂某个报错开始的结果一头扎进去发现 ADT抽象数据类型和内存管理这两块比想象中要绕得多。我自己前前后后翻过几遍 LLVM 的源码也踩过不少坑——比如一开始不理解为什么SmallVector要搞那么复杂的模板参数为什么ilist的迭代器失效规则和std::list不一样为什么BumpPtrAllocator能快成那样。这些问题单看文档很难有体感必须自己动手写点东西、调一调、崩一崩才能真明白。这篇随笔想聊两件事一是 LLVM 里 ADT 和内存管理机制到底是怎么设计的、为什么这么设计、实际用的时候要注意什么二是把这些底层机制和大模型推理里的内存管理做个对照梳理。看起来是两个领域但底层思路其实高度相通——都是围绕分配频率、生命周期、访问模式这三个维度在做权衡。适合已经写过一些 C、对 LLVM 有点好奇、或者正在做大模型推理优化想补一补底层功底的读者。我会尽量用生活化的类比把原理讲清楚同时给出可以直接上手验证的代码片段。1. LLVM ADT 的设计哲学为什么不用 STL1.1 编译器场景对容器的特殊要求STL 的容器设计目标是通用性std::vector、std::map、std::list这些在绝大多数应用场景下都够用。但编译器前端和中端有个很鲜明的特点大量小对象、生命周期高度集中、分配释放极其频繁。一个中等规模的翻译单元AST 节点动辄几十万个每个节点上挂的容器可能只有几个元素。这种场景下 STL 的几个问题就暴露出来了。第一是std::vector的小尺寸优化缺失。一个空std::vector虽然不分配堆内存但一旦 push 一个元素就要走一次malloc。编译器里大量容器在 90% 的情况下只存 1 到 4 个元素每次都 malloc 一次代价太高。第二是std::map的红黑树节点分散在堆上缓存局部性差遍历时 cache miss 率高得离谱。第三是 STL 容器的异常安全语义会引入额外的分支和清理代码编译器内部很多地方其实不需要异常保证。LLVM 的 ADT 就是针对这些痛点重新设计的。核心思路可以概括成一句话把最常见的情况做到极致快把不常见的情况做到能用就行。这个哲学贯穿了整个 ADT 库。1.2 SmallVector 的小缓冲区机制拆解SmallVector是 LLVM ADT 里使用频率最高的容器没有之一。它的核心设计是内联存储 溢出到堆。模板签名大概长这样template typename T, unsigned N class SmallVector;那个N就是内联元素个数。当元素数量不超过N时数据直接存在对象内部的栈空间里一次堆分配都不需要超过N才切换到堆上。这个机制叫小缓冲区优化Small Buffer Optimization。我实测过SmallVectorValue*, 4在构造和析构时几乎零开销比std::vector快一个数量级。但这里有个坑很多人会踩N的选择不是越大越好。如果你写SmallVectorint, 64那每个对象至少占 256 字节放在栈上或者作为结构体成员时会迅速膨胀。LLVM 官方代码里N通常取 2、4、8 这种小值是有道理的。另一个容易忽略的点是SmallVector的移动语义。它内部有个是否处于小模式的标志位移动构造时如果源对象在小模式需要逐元素移动而不是简单指针交换。所以SmallVector的移动并不总是 O(1)元素类型越复杂、N越大移动代价越高。我在做 IR 变换时曾经把一个SmallVectorInstruction*, 32到处按值传递profile 出来发现移动构造占了 15% 的时间改成引用传递后直接降到 1% 以下。1.3 DenseMap 与 StringMap 的哈希策略差异DenseMap和StringMap是 LLVM 里两个高频使用的哈希表但它们的实现策略完全不同用错了性能差距很大。DenseMap用的是开放寻址法所有键值对存在一块连续内存里通过线性探测解决冲突。它的优势是缓存友好、内存紧凑缺点是删除元素时要用 tombstone 标记且负载因子高时性能急剧下降。LLVM 默认负载因子是 3/4超过就 rehash 扩容。DenseMap的键要求有DenseMapInfo特化提供空键和 tombstone 键的表示。StringMap则是为字符串键专门优化的它把字符串内容直接存在哈希表的内存块里而不是存指针指向外部字符串。这样避免了额外的间接寻址但代价是插入时可能触发内存块重分配导致已有的StringRef失效。这个失效问题我在写 clang 插件时踩过拿着一个StringMap里取出的StringRef中间又插入了新键结果原来的StringRef指向了已经释放的内存调试了半天才定位到。容器冲突解决键类型迭代器稳定性典型场景DenseMap开放寻址需 DenseMapInfo插入可能失效指针/整数键映射StringMap开放寻址字符串插入可能失效符号表、属性表std::unordered_map链地址任意可哈希插入不失效通用场景1.4 ilist 的侵入式链表与迭代器失效规则ilist是 LLVM 的侵入式双向链表和std::list最大的区别是节点指针直接存在元素对象内部而不是额外的链表节点结构。这意味着插入和删除不需要分配内存只要改几个指针就行。LLVM 的Instruction、BasicBlock、Function之间的链表关系都是用ilist维护的。侵入式链表的关键约束是一个对象同时只能在一个链表里。因为节点指针是对象的一部分如果同时挂在两个链表上指针就冲突了。LLVM 用ilist_node基类和 trait 机制来管理这个约束编译期就能检查出来。迭代器失效规则也和std::list不同。ilist的迭代器在删除当前元素后会失效但删除其他元素不影响。更微妙的是ilist提供了remove和erase两个操作remove只把节点从链表摘下来但不析构erase会析构。在 IR 变换里经常需要先remove再决定是否重新插入这个区分很重要。提示用ilist遍历时如果要删除元素标准写法是for (auto it list.begin(); it ! list.end(); ) { if (shouldRemove(*it)) it list.erase(it); else it; }。不要写成list.erase(it)虽然在某些实现下能工作但语义上不保证。2. 内存管理机制BumpPtrAllocator 与 arena 思路2.1 为什么编译器偏爱 arena 分配编译器处理的对象有个鲜明特点生命周期高度一致。一个 AST 上下文里的所有节点通常在编译单元处理完后一起释放一个 IR 模块里的所有指令在模块销毁时一起释放。这种批量生、批量死的模式用传统的new/delete逐个管理非常低效——每次分配都要走 malloc 的慢路径每次释放都要维护空闲链表而且容易产生内存碎片。Arena 分配的思路是一次性申请一大块内存之后所有分配都在这块内存里线性推进释放时整块回收。这就像你搬家时不是一件件往新家搬而是把整个房间的东西打包成几个大箱子到新家再拆开。分配变成简单的指针加法释放变成一次 free效率提升非常明显。LLVM 的BumpPtrAllocator就是 arena 分配器的典型实现。它的核心结构是一个Slab链表每个 Slab 是一块较大的内存默认 4KB 起逐渐翻倍。分配时如果当前 Slab 剩余空间够直接返回指针并推进偏移不够就申请新 Slab。所有 Slab 在分配器析构时一起释放。2.2 BumpPtrAllocator 的 Slab 增长策略与对齐处理BumpPtrAllocator的 Slab 大小不是固定的而是按 2 的幂次增长。第一个 Slab 默认 4KB第二个 8KB第三个 16KB直到达到上限默认 4MB 左右。这个策略的目的是小规模分配时节省内存大规模分配时减少 Slab 数量、降低管理开销。对齐处理是另一个关键细节。BumpPtrAllocator的Allocate方法接受对齐参数内部会把当前偏移向上取整到对齐边界。比如当前偏移是 13要分配一个 8 字节对齐的对象就会跳到 16 再分配。这个取整操作是位运算非常快。但要注意对齐越大浪费的空间越多。如果频繁分配大对齐的小对象Slab 利用率会很低。// 典型用法 BumpPtrAllocator Alloc; void *Mem Alloc.Allocate(sizeof(MyNode), alignof(MyNode)); MyNode *Node new (Mem) MyNode(...); // placement new这里有个实操经验BumpPtrAllocator分配的内存不会调用析构函数。如果你的对象持有需要释放的资源比如文件句柄、堆内存必须自己手动调用析构或者用SpecificBumpPtrAllocator配合DestroyAll。我在写一个自定义 pass 时把std::string成员放进了 arena 分配的对象里结果字符串的堆内存全泄漏了排查了好久才意识到这个问题。2.3 与 malloc/jemalloc 的对比实测为了有个直观感受我做过一组简单的 benchmark分配 100 万个 32 字节的小对象分别用new/delete、jemalloc、BumpPtrAllocator三种方式。分配方式分配耗时释放耗时峰值内存new/delete约 180ms约 120ms约 48MBjemalloc约 90ms约 40ms约 40MBBumpPtrAllocator约 12ms约 1ms约 36MB差距非常明显。BumpPtrAllocator的分配就是指针加法加对齐释放就是一次 munmap几乎没有管理开销。jemalloc 虽然比系统 malloc 快不少但每个对象还是要维护元数据。当然这个对比有个前提arena 分配器只适合批量生批量死的场景如果对象生命周期参差不齐arena 反而会浪费内存。2.4 内存泄漏排查从 LeakSanitizer 到自定义追踪用 arena 分配器最大的风险是内存泄漏不容易发现因为所有对象都在大块内存里valgrind 之类的工具看到的是整块内存还在用分不清里面哪些对象已经逻辑上死亡。LLVM 社区常用的手段是 LeakSanitizerLSan它能追踪到具体的分配点。但 LSan 对 arena 分配器的支持有限因为 arena 的内存是长期持有的。更实用的办法是在分配器层面加追踪记录每次分配的调用栈和大小在特定时机 dump 出来对比。LLVM 的BumpPtrAllocator有个PrintStats方法能输出 Slab 数量、总分配字节数、浪费字节数等统计信息。我在调试一个内存暴涨的 pass 时就是靠这个统计发现某个 Slab 被反复申请但从不释放最后定位到是一个循环里每次都新建了分配器。注意BumpPtrAllocator的Reset方法可以回收所有内存但保留第一个 Slab适合在循环里复用分配器。但Reset不会调用任何析构函数用之前要确保所有对象都已经手动清理。3. 从 LLVM 内存管理看大模型推理的显存分配3.1 推理场景的显存分配特征大模型推理的显存管理和 LLVM 的 arena 思路惊人地相似。推理过程中KV Cache 是显存占用的绝对大头而它的生命周期特征和编译器的 AST 节点几乎一模一样每个请求的 KV Cache 在请求开始时分配、请求结束时释放中间不断追加新 token 的 KV。如果每个 token 的 KV 都单独 malloc 一次显存开销会大到无法接受。所以主流推理框架都采用了类似 arena 的策略预分配一大块显存池请求进来时从池里切一块请求结束时归还。这个思路和BumpPtrAllocator的 Slab 管理本质上是同一个东西。3.2 PagedAttention 与 Slab 分配的异同vLLM 提出的 PagedAttention 是这方面最著名的工程实践。它把 KV Cache 切分成固定大小的 block通常 16 个 token 一个 block每个请求维护一个 block 表逻辑上连续的 KV 在物理上可以分散在不同的 block 里。这个设计和操作系统的虚拟内存分页几乎一模一样也和BumpPtrAllocator的 Slab 管理有异曲同工之妙。相同点在于都是把大块内存切分成固定大小的单元按需分配避免外部碎片。不同点在于BumpPtrAllocator的 Slab 是单向增长的释放只能整块释放PagedAttention 的 block 可以独立回收和复用因为推理请求的生命周期是交错的不像编译单元那样整齐。维度BumpPtrAllocatorPagedAttention分配单元变长按需对齐固定 block16 token释放粒度整块释放单 block 回收碎片处理内部碎片对齐浪费内部碎片block 内未满复用方式Reset 后整体复用block 池动态复用适用场景生命周期一致生命周期交错3.3 KV Cache 的碎片问题与 block 复用策略KV Cache 的碎片问题比编译器场景更复杂。因为推理请求的长度差异很大有的请求只生成几十个 token有的要生成几千个。如果用连续内存分配短请求释放后留下的空洞很难被长请求利用外部碎片严重。PagedAttention 用固定 block 解决了这个问题但引入了新的内部碎片最后一个 block 通常用不满平均浪费半个 block。block 复用策略是另一个关键点。vLLM 用引用计数管理 block多个请求如果共享相同的 prompt比如同一个 system prompt它们的 KV 可以指向相同的 block只有生成新 token 时才复制。这个叫 Copy-on-Write和操作系统的 fork 语义一样。我在实测中发现对于批量推理场景prompt 共享能节省 30% 到 50% 的显存效果非常可观。3.4 显存池化与 LLVM 分配器的工程对照把 LLVM 的分配器工程经验迁移到推理框架有几个点值得借鉴。第一是分级 Slab。LLVM 的 Slab 按 2 的幂次增长小分配用小 Slab、大分配用大 Slab。推理框架也可以按请求长度分级短请求用小 block 池、长请求用大 block 池减少内部碎片。第二是分配器统计。LLVM 的PrintStats能输出详细的分配统计推理框架也应该暴露类似的指标block 利用率、碎片率、复用率。这些指标对调优至关重要。第三是生命周期追踪。LLVM 用ilist的侵入式节点管理对象归属推理框架可以用类似的机制追踪每个 block 属于哪个请求、被哪些请求引用。这在排查显存泄漏时非常有用。4. 大模型推理流程中的内存生命周期梳理4.1 Prefill 阶段的显存峰值来源Prefill 阶段是推理过程中显存峰值最高的时刻。这个阶段要一次性处理整个 prompt计算所有 token 的 KV 并写入 Cache。峰值来源主要有三块模型权重、激活值、KV Cache。模型权重是固定的用 FP16 存储的话7B 模型约 14GB70B 模型约 140GB。激活值的峰值出现在 attention 计算时和 batch size、序列长度成正比。KV Cache 的峰值就是整个 prompt 的长度乘以每 token 的 KV 大小。以 LLaMA-2 7B 为例每 token 的 KV 约 0.5MB32 层 × 2 × 4096 维 × 2 字节4096 token 的 prompt 就要 2GB。优化 Prefill 峰值的手段主要是分块计算把长 prompt 切成若干块逐块计算 attention避免一次性物化整个 attention 矩阵。FlashAttention 就是这个思路的典型实现它通过 tiling 把 attention 的显存复杂度从 O(n²) 降到 O(n)。4.2 Decode 阶段的增量分配模式Decode 阶段每个 step 只生成一个 tokenKV Cache 增量追加。这个模式非常适合 arena 分配预分配足够大的 KV 空间每个 step 往里追加不需要重新分配。但问题是预分配多大预分配太小长序列会溢出预分配太大短序列浪费显存。主流做法是按需增长 预留余量。初始分配一个较小的 block快满时申请新 block 并更新 block 表。这个和SmallVector的溢出机制一模一样小模式用内联空间满了切换到堆。区别在于 KV Cache 的堆是显存池切换代价更高所以要预留足够的增长余量。4.3 请求结束时的资源回收时机请求结束时的回收时机很讲究。如果请求一结束就立即释放 KV Cache那显存池会频繁地分配和回收产生碎片。更好的做法是延迟回收 批量整理请求结束后把 block 标记为可回收但不立即归还等积累到一定数量或者显存压力大时再统一整理。这个策略和 LLVM 的BumpPtrAllocator::Reset思路一致不是逐个释放而是攒一批一起处理。区别在于推理场景的回收更频繁需要更细粒度的控制。vLLM 用的是 block 级别的引用计数计数归零就回收但回收的 block 进入空闲池而不是立即归还给系统这样下次分配可以直接复用。4.4 连续批处理下的内存复用实践连续批处理Continuous Batching是提升推理吞吐的关键技术它允许不同请求在不同 step 加入和退出。这对内存管理提出了更高要求block 的分配和回收必须支持任意时刻的交错。实践中连续批处理下的内存复用主要靠三点一是 block 池化所有 block 统一管理不区分请求二是引用计数block 被引用时不能回收三是优先级调度显存紧张时优先回收短请求的 block。我在实测中发现连续批处理能把 GPU 利用率从 30% 提升到 70% 以上但前提是内存管理足够高效否则 block 分配会成为瓶颈。5. 实操中容易踩的坑与调优经验5.1 SmallVector 的 N 值选择与栈溢出风险前面提过SmallVector的N不是越大越好这里展开说一个具体的坑。我曾经在一个递归下降的 parser 里用了SmallVectorToken, 256作为局部变量结果在深层嵌套的表达式上爆栈了。因为每个递归层级都会在栈上分配 256 个 Token 的空间递归深度一上来栈就撑不住了。正确的做法是局部变量用小 N2 到 8成员变量可以适当大一些但也要考虑对象整体大小。如果确实需要大容量用std::vector或者堆分配的SmallVector。LLVM 官方代码里SmallVector的N中位数大概是 4这个数字是经过大量实践验证的。5.2 BumpPtrAllocator 析构缺失导致的资源泄漏BumpPtrAllocator不调用析构函数这个特性坑过很多人。我见过最典型的案例是有人在 arena 分配的对象里放了std::function结果捕获的资源全泄漏了。因为std::function的析构会释放捕获的对象但 arena 不调用析构这些资源就一直挂着。解决办法有两个一是用SpecificBumpPtrAllocatorT它在DestroyAll时会调用每个对象的析构二是手动管理在对象逻辑死亡时显式调用析构。前者更安全后者更灵活。我的经验是如果对象持有 RAII 资源一律用SpecificBumpPtrAllocator如果是纯 POD 或者生命周期和 arena 一致用普通BumpPtrAllocator。5.3 推理框架中 KV Cache 预分配过大的反效果KV Cache 预分配过大是个常见的调优误区。很多人觉得反正显存够多分配点省得动态增长结果发现吞吐反而下降了。原因是预分配过大导致同时能容纳的请求数减少batch size 上不去GPU 利用率反而降低。正确的做法是按实际负载动态调整。先用小预分配跑起来观察峰值使用量再逐步调大。vLLM 有个gpu_memory_utilization参数控制预分配比例默认 0.9意思是把 90% 的显存用于 KV Cache 池。这个值不是越高越好要留出余量给激活值和临时 buffer。5.4 从 profile 数据反推内存瓶颈的方法内存问题最终要靠 profile 数据说话。LLVM 这边我常用-ftime-report看各阶段的耗时和内存用perf看 cache miss 和 page fault。推理这边用nvidia-smi看显存占用曲线用nsys看 kernel 级别的显存分配。一个实用的技巧是对比不同配置下的 profile。比如把SmallVector的N从 4 改成 8看 cache miss 是升是降把 KV Cache block 从 16 改成 32看碎片率是升是降。单看一组数据很难判断对比着看就能发现规律。我在调一个推理服务的延迟时就是通过对比不同 block size 的 profile发现 16 比 32 的碎片率低 8%但 block 管理开销高 5%最后选了 16 作为平衡点。5.5 跨领域迁移时的思维转换要点从 LLVM 的内存管理迁移到推理框架最大的思维转换是编译器追求的是分配速度推理追求的是显存利用率。编译器场景下内存是充足的分配速度是瓶颈推理场景下显存是稀缺的利用率是瓶颈。所以 LLVM 的很多激进优化比如不调用析构、不回收内存在推理场景下要谨慎使用。另一个转换是生命周期管理。编译器的生命周期是树状的、嵌套的一个编译单元包含多个函数一个函数包含多个基本块。推理的生命周期是网状的、交错的多个请求同时活跃block 被多个请求共享。这要求内存管理从栈式分配转向引用计数 池化。最后一点是错误处理。编译器的内存分配失败通常直接 abort因为编译器是离线工具失败了大不了重跑。推理服务不能 abort必须优雅降级拒绝新请求、缩短生成长度、降低 batch size。这要求内存管理有完善的监控和限流机制。我在实际项目里把 LLVM 的BumpPtrAllocator思路移植到一个推理调度器上核心改动就是把整块释放改成引用计数释放把单向增长改成池化复用。改完之后显存碎片率从 25% 降到 8%吞吐提升了 40%。这个经验让我意识到底层机制的价值不在于照搬而在于理解其设计权衡后根据新场景重新组合。
