在大语言模型推理过程中，KV 缓存是决定系统吞吐量的关键瓶颈。随着输入上下文长度从数千 tokens 扩展至数十万甚至百万级别，KV 缓存的内存消耗可能从数十 GB 跃升至上百 GB，这一数值甚至会超越模型权重本身的内存占用。Nano-vLLM 作为轻量级推理引擎，针对这一挑战设计了独特的内存优化策略，其核心思路围绕分块管理、动态淘汰与选择性压缩展开。本文将从物理内存布局出发，深入剖析 nano-vLLM 与 vLLM 在 KV 缓存管理上的设计差异，并给出可落地的工程参数配置建议。
物理内存布局：连续张量与分块策略
Nano-vLLM 采用了一种高度聚合的物理内存布局，将所有 transformer 层的 KV 缓存存储在一个连续的大张量中。这一设计的张量维度为 [2, num_hidden_layers, num_kvcache_blocks, block_size, num_kv_heads, head_dim]，其中维度 0 用于区分 key（索引 0）和 value（索引 1），维度 1 表示 transformer 解码层的数量，维度 2 是总块数，维度 3 是每个块的 tokens 数量，维度 4 是每个 GPU rank 的 key-value 注意力头数，维度 5 是每个头的嵌入维度。
这种连续张量设计的优势在于内存访问的局部性与前缀共享的便利性。ModelRunner 在 allocate_kv_cache() 方法中完成张量分配后，每个注意力模块通过视图（view）机制获取其对应层的缓存切片，存储为 k_cache 和 v_cache 属性。物理块大小在 nano-vLLM 中默认为 256 tokens，这一数值在内存碎片化风险与访问效率之间取得了平衡。总块数由可用 GPU 内存动态决定，计算公式为 (gpu_memory - model_weights_memory - other_overhead) / (block_size * per_token_memory)。
相比之下，vLLM 采用的 PagedAttention 方案则基于非连续的物理内存管理。vLLM 将物理 GPU 内存预先分配为固定大小的块（KVCacheBlock），每个块拥有唯一 ID、哈希值和引用计数，这些块通过双向链表组织以支持 O (1) 时间复杂度的分配与淘汰。空闲块由一个专门的队列管理，同时存在从哈希键到块 ID 的映射（用于前缀缓存）以及从请求 ID 到块 ID 的映射（用于请求隔离）。这种分页式设计与操作系统的虚拟内存机制有异曲同工之妙，能够更灵活地处理不同长度的序列，减少因预分配过大连续内存而产生的浪费。
动态内存管理：淘汰策略与优先级机制
当并发请求数量增加或单个请求的序列长度扩展时，KV 缓存的容量终将触及上限。nano-vLLM 与 vLLM 在处理缓存淘汰时采用了不同的策略哲学。
vLLM 的 KVCacheManager 实现了多层抽象，支持 LRU（最近最少使用）和基于引用计数的淘汰策略。当一个序列完成或某些块不再被需要时，其引用计数会递减；当引用计数归零时，块被返回到空闲队列以供重用。调度器通过 kv_cache_manager.get_computed_blocks() 查询缓存命中情况，对于前缀相同的请求可以直接复用已有块，避免重复计算。vLLM 还支持前缀缓存（prefix caching），通过哈希键快速识别可共享的历史上下文。
PagedEviction 算法提出了一种更精细的块级淘汰策略，专门针对分页内存布局优化。该算法的核心思想是结构化地评估每个块的重要性，而非孤立地判断单个 token。PagedEviction 通过分析注意力分布，识别出哪些块包含高影响力的 token，然后在淘汰时优先移除低影响力块。由于其设计完全兼容 PagedAttention 的 CUDA 内核，无需对核心计算逻辑进行修改即可部署。在 LongBench 基准测试中，PagedEviction 相比基线方案实现了更高的内存利用率，同时在长上下文任务上保持了更好的准确率。
Nano-vLLM 的连续张量设计在淘汰策略上的选择相对受限，因为连续内存的物理特性使得局部释放变得困难。然而，通过引用计数机制和显式的内存视图管理，nano-vLLM 仍然能够实现高效的块级重用。在实际部署中，建议为 nano-vLLM 配置 reference_count_threshold 参数：当某个序列的引用计数低于设定值（例如 2）时，触发后台回收任务，将未使用的块标记为空闲。
压缩技术：量化与选择性留存
除了分块与淘汰，另一类重要的内存优化手段是 KV 缓存的压缩。KVCrush 是 Intel 提出的基于注意力头行为相似性的压缩技术，其核心洞察在于：不同注意力头对历史 token 的关注模式往往高度相似，因此可以通过聚类与合并来消除冗余。KVCrush 将总缓存预算划分为「重要 token 存储区」和「代表性 token 存储区」两个部分，前者用于存放由 H2O、SnapKV、PyramidKV 等重要性评估算法识别的高价值 token，后者则存储能够代表特定语义区间的压缩表示。实验结果表明，KVCrush 可将 LongBench 基准上的 KV 缓存大小压缩至原来的四分之一，同时将精度损失控制在 1% 以内，整体推理延迟增加不超过 0.5%。
KVQuant 则从量化角度切入，专注于低精度 KV 缓存表示。该方法引入了四项关键技术创新：针对 key 激活的按通道量化（per-channel quantization）以匹配不同通道的分布特性；RoPE 嵌入前的 key 量化以减少位置编码对量化的干扰；非均匀 KV 缓存量化，根据层敏感性自适应调整数据类型；以及按向量的密集 - 稀疏混合量化，孤立处理离群值以减少量化范围的偏斜。KVQuant 在 3-bit 量化精度下实现了困惑度下降小于 0.1% 的效果，使得在单张 A100-80GB GPU 上服务 LLaMA-7B 模型时，上下文长度可扩展至 100 万 tokens，在 8 GPU 系统上更可支持 1000 万 tokens。
需要特别指出的是，这些压缩技术与 vLLM 的分页机制具有良好的兼容性。KVCrush 和 KVQuant 都可以作为 PagedAttention 之上的附加层，在不破坏原有内存管理逻辑的前提下进一步降低内存占用。
工程落地：参数配置与监控要点
基于上述技术分析，以下是生产环境中部署 KV 缓存优化策略时的关键参数建议与监控指标。
块大小配置是首要考量因素。256 tokens 的默认块大小适用于大多数中长上下文场景（4096 至 32768 tokens）；对于超长上下文（超过 100k tokens），建议将块大小调整为 512 或 1024 以减少块表管理开销；对于极短上下文（低于 2048 tokens）的高并发场景，可考虑 128 tokens 的小块以提高缓存复用率。块大小的选择应通过实际负载测试确定，核心指标是缓存命中率的提升与块表内存开销的平衡。
淘汰阈值设定直接影响缓存利用率与请求延迟的权衡。对于 vLLM，建议将 max_num_seqs 设置为 GPU 显存允许的最大值（例如 A100-80GB 上 LLaMA-7B 可设至 200 以上），同时配置 block_size 为 32 或 64 以支持更细粒度的内存分配。PagedEviction 的淘汰策略建议在 eviction_ratio=0.2（即当缓存使用率超过 80% 时启动淘汰）和 importance_threshold=0.1（低于该重要性的块优先淘汰）作为起点参数。
压缩参数配置需要根据精度容忍度调整。KVCush 的压缩比建议从 2x 开始逐步提升，观察长上下文问答任务的准确率变化；对于精度敏感的应用（如代码生成或数学推理），压缩比不宜超过 4x。KVQuant 的量化位数建议从 4-bit 开始，若困惑度上升超过 0.2，则回退至 8-bit 或混合精度方案。
监控指标应覆盖内存使用与缓存效率两个维度。关键指标包括：缓存命中率（cache hit rate），目标是 >60% 对于有大量前缀共享的对话场景；内存使用波动率（memory usage volatility），过高波动可能暗示淘汰策略过于激进；每请求平均 KV 缓存大小（KB per request），用于容量规划与成本核算；以及淘汰触发频率（eviction frequency），反映缓存容量的紧张程度。建议将这些指标接入 Prometheus/Grafana 监控体系，设置告警阈值（如缓存命中率 <40% 或内存使用率>90% 持续 5 分钟）。
技术选型建议
对于新部署的 LLM 推理服务，优先推荐 vLLM + PagedAttention + PagedEviction 的组合路径，这一组合在生产环境中有最成熟的社区支持与丰富的调优经验。对于内存极度受限的边缘部署场景，可考虑在 vLLM 基础上叠加 KVCrush 或 KVQuant，以空间换性能。Nano-vLLM 的连续张量设计更适合对延迟极敏感、对吞吐量要求相对宽松的在线推理场景，其简洁的内存视图机制有助于减少分页带来的间接访问开销。
无论选择哪种技术路线，KV 缓存的内存优化都不是一次性的配置任务，而需要结合实际工作负载特征持续调优。建议建立定期的缓存行为分析机制，观察不同时间段、不同请求类型的缓存命中率变化趋势，并据此微调块大小、淘汰策略与压缩参数。唯有将技术选型与持续优化相结合，才能在大语言模型推理的高内存压力下实现稳定、高效的服务运行。
参考资料
- nano-vLLM KV Cache Architecture，https://deepwiki.com/liguodongiot/nano-vllm/3.2-kv-cache-architecture
- PagedEviction: Structured Block-wise KV Cache Pruning for Efficient LLM Inference, arXiv:2509.04377v1
- KVCrush: Key Value Cache size-reduction using similarity in head-behaviour, arXiv:2503.00022v1
- KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization, arXiv:2401.18079v4
- vLLM KV Cache Management, vLLM Forums