vLLM 怎么配置 OffloadingConnector 把前缀缓存 KV 块卸载到 CPU 内存
发布时间:2026/9/12 13:56:33 作者:尧图编辑部 阅读量:1,286

vLLM 怎么配置 OffloadingConnector 把前缀缓存 KV 块卸载到 CPU 内存【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllmGPU 上的前缀缓存容量有限已经计算完成的 KV 块会被淘汰后续共享同一前缀的请求只能重新计算 prefill。vLLM 的OffloadingConnector解决这个问题它扩展前缀缓存把已完成的 KV 块在产生时就卸载到更慢但容量更大的层级CPU 主机内存以及可选的次级层级命中时再从卸载层级按需提升回 GPU。GPU 与 CPU 之间的传输使用 DMAcudaMemcpyAsync与模型计算异步并行执行因此 offloading 带来的 CPU/GPU 核心开销很小。按官方文档说明OffloadingConnector目前仅支持 CUDA、ROCm 和 XPU 平台。配置入口是vllm serve的--kv-transfer-config参数完整配置参考见 KV Offloading Usage Guide。配置单级 CPU 卸载主路径只使用 CPU 内存作为卸载层级时使用默认的CPUOffloadingSpec已完成的 GPU 块会被复制到 pinned host memory。文档给出的启动命令如下model替换为你要服务的模型名HuggingFace 模型 ID 或本地路径vllm serve model \ --kv-transfer-config { kv_connector: OffloadingConnector, kv_role: kv_both, kv_connector_extra_config: { block_size: 64, cpu_bytes_to_use: 1000000000 } }kv_connector_extra_config中与本路径相关的配置项键是否必填默认值说明spec_name否CPUOffloadingSpec不填即单级 CPU 卸载多级别改为TieringOffloadingSpeccpu_bytes_to_use是—所有 worker 合计预留的主机内存字节数注意不是 per-workerblock_size否GPU block size以 token 计的卸载块大小必须是 GPU block size 的整数倍与blocks_per_chunk互斥blocks_per_chunk否1以 GPU block 计的卸载 chunk 大小必须 0适用于 KV cache 各组 block 大小不同的模型eviction_policy否lru主层级淘汰策略内置lru/arc也可填自定义CachePolicy类名offload_prompt_only否true为true时只卸载 promptprefill块decode 块被跳过理解块大小的一个概念卸载操作的基本单位是chunk覆盖一组 token 的固定大小 KV 数据默认一个 chunk 对应一个 accelerator block调大blocks_per_chunk会得到更大的 I/O减少逐块的簿记开销但会增加查找粒度。决定cpu_bytes_to_use的大小官方 Tuning Tips 给出了两点明确依据该值是所有 worker 的总和不是每个 worker 一份给主机上其余负载留有余量。对单级仅 CPU部署应把cpu_bytes_to_use设得大于 GPU 上 KV cache 的总量。因为 offloading 是即时发生的CPU 层级偏小只会镜像 GPU 上已经持有的内容不会带来命中率提升。验证卸载是否生效文档给出的可观测路径是通过 KV cache events 观察块事件。默认情况下连接器对卸载块只发布占位事件在kv_connector_extra_config中把self_describing_kv_events设为true并且通过--kv-events-config开启 KV cache events即enable_kv_cache_events后连接器才会发出自描述的块粒度BlockStored/BlockRemoved事件包含组成块哈希、整个 chunk 的token_ids、每块block_size、父哈希及 group/cache-spec 元数据外部 KV-event 消费者据此可以索引到已卸载的块。注意该选项在未开启 KV events 时不产生任何效果。行为层面的判断依据来自文档描述命中卸载层级的块会被按需提升回 GPU后续共享同一前缀的请求因此可以跳过对应 prefill。若把 CPU 层级设得小于 GPU KV cache 总量则按上文说明不会改善命中率可据此检查cpu_bytes_to_use是否设小了。可选分支扩展到次级层级TieringOffloadingSpec如果需要比 CPU 更大的容量可把spec_name设为TieringOffloadingSpec并配置secondary_tiers列表。层级是有顺序的tier 0 先于 tier 1 被查询。注意只有 CPU 主层级能直接访问 GPU次级层级不能读写 GPU 内存所有 GPU 与次级层级之间的传输都经过 CPU 主层级中转。以 CPU 文件系统次级层级为例文档中的示例命令/mnt/kv_cache为示例目录按你的实际存储位置替换vllm serve model \ --kv-transfer-config { kv_connector: OffloadingConnector, kv_role: kv_both, kv_connector_extra_config: { spec_name: TieringOffloadingSpec, cpu_bytes_to_use: 10737418240, block_size: 16, eviction_policy: lru, secondary_tiers: [ { type: fs, root_dir: /mnt/kv_cache, n_read_threads: 32, n_write_threads: 16 } ] } }文件系统层级type: fs的关键字段root_dir必填vLLM 会在其下创建子目录、n_read_threads/n_write_threads默认均为 16按存储能支撑的并发调整prefill 命中率高时优先加大读线程、enable_kv_events默认false开启后对成功存储的块发布 medium 为STORAGE的BlockStored事件前提同样是全局开启了 KV events。配置 fs 层级后可以直接检查磁盘布局确认块已落盘。root_dir下会生成model_digest子目录/替换为_digest由运行配置推导其下按 rank 和块哈希分片存放.bin块文件及记录运行参数的config.json文档描述的实际布局root_dir/ model_digest/ config.json model_digest_rrank/ hhh/ # 块哈希的前 3 位十六进制 hh_ggroup_idx/ # 接下来 2 位十六进制 KV cache group 索引 hash_hex.bin # 完整块哈希十六进制同一模型、同一block_size、并行布局和 dtype 的运行共享同一个digest子目录改动其中任何一项会产生新子目录旧目录不会被自动清理。多个实例共享同一root_dir例如共享 PVC时默认情况下相同 token 内容会产生相同的块文件名若使用xxhash/xxhash_cbor作为--prefix-caching-hash-algo则必须在每个实例上设置相同的PYTHONHASHSEED。文档还定义了objS3 兼容对象存储经 NIXL OBJ 后端和p2p经 NIXL/RDMA 的跨实例共享含 P/D 分离两种次级层级配置项较多且各自有独立的使用前提本文不展开需要时直接查 完整参考。按请求限制卸载范围实验特性kv_transfer_params中的max_offload_tokens非负整数可以为单个请求封顶可卸载的 token 数只有请求的前max_offload_tokens个 token 会被卸载之后的块在 store 路径被跳过。适用于系统提示词等共享前缀值得缓存、请求特定后段不值得的场景设为0表示该请求完全不卸载省略该键表示不封顶。示例请求体文档示例{ model: model, prompt: ..., kv_transfer_params: { max_offload_tokens: 1024 } }非int、负数或bool值会被拒绝并告警按不封顶处理。文档明确标注该键为实验特性可能变化。限制与适用边界平台OffloadingConnector目前仅支持 CUDA、ROCm、XPU。offload_prompt_only默认truedecode 块默认不参与卸载。次级层级fs/obj/p2p没有直接 GPU 访问一切经由 CPU 主层级中转TieringOffloadingSpec会拒绝store_threshold 2的取值。前缀缓存只对 prefill 阶段省时不影响 decode 耗时没有共享前缀的流量不会从 offloading 中获益见 Automatic Prefix Caching 中对 APC 适用性的说明。OffloadingConnector列在分离式 Prefilling文档支持的连接器列表中该文档标注分离式 prefill 整体为实验特性max_offload_tokens单独标注为实验特性。更多配置项自定义淘汰策略、store_threshold、max_tracker_size、spec_module_path等和 P2P 层级的编排协议细节以 KV Offloading Usage Guide 为准。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考