LMCache 配置实战长上下文推理提速降本的关键参数全解【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache长上下文推理的成本账大多亏在两笔上prefill 阶段把几万 token 从头算一遍以及 GPU 显存放不下 KV 缓存导致的反复重算。LMCache 就是一个插在推理框架如 vLLM外面的 KV 缓存加速层它把已经算好的 KV 缓存搬到 CPU 内存、磁盘乃至远端存储里请求再来时直接命中省掉重复计算。合理设置 LMCache 配置后同样的长文档问答、多轮对话场景TTFT 和算力开销都能明显压下去——仓库里自带的缓存模拟器实测曲线显示随着缓存容量增大token 命中率可以从接近 0 一路爬升到 80% 以上3 分钟写出一份能跑起来的起步配置LMCache 的配置有两种入口YAML 配置文件结构清晰适合固化到部署流程里完整参数规范可查 docs/source/api_reference/configurations.rst环境变量所有参数都支持LMCACHE_前缀比如LMCACHE_CHUNK_SIZE256对容器化部署特别友好注意一条优先级规则配置文件存在时同名环境变量会被忽略。两种写法混用时别指望环境变量能补漏它只在你没提供配置文件时才生效。最小可用的配置长这样# 起步配置命中率高、内存压力小 chunk_size: 256 # 缓存块大小token 数默认 256 local_cpu: True # 启用 CPU 内存缓存默认开启 max_local_cpu_size: 10 # CPU 缓存上限GB默认 5.0 local_disk: file:///data/lmcache/disk # 可选本地磁盘缓存 remote_url: infinistore://192.168.1.100:50051 # 可选远端存储同一份配置用环境变量表达export LMCACHE_CHUNK_SIZE256 export LMCACHE_LOCAL_CPUtrue export LMCACHE_MAX_LOCAL_CPU_SIZE10参数含义一句话版本chunk_size决定一个缓存块装多少 token直接影响命中粒度和内存占用max_local_cpu_size是 CPU 缓存的容量天花板GBlocal_disk用file:///路径格式指向磁盘目录remote_url用协议://host:port格式指向远端存储。仓库里 examples/cache_with_configs/ 有一份官方起步示例可以直接抄。 新手建议先用chunk_size: 256这个默认值跑通链路再根据命中率去动它。大模型场景可以试 512 或 1024。内存、磁盘、远端三级存储怎么搭LMCache 的存储是分层结构思路类似 CPU 缓存层级越快的层越小越贵越慢的层越大越便宜。CPU 内存延迟最低承接热数据。容量用max_local_cpu_size控制本地磁盘容量大承接温数据。用local_diskmax_local_disk_size配置远端存储可跨实例共享承接冷数据。用remote_url指向具体后端一个典型的三级组合local_cpu: True max_local_cpu_size: 20 # 热数据 20GB local_disk: file:///data/lmcache/disk max_local_disk_size: 100 # 温数据 100GB remote_url: mooncakestore://cache-server:6379 remote_serde: cachegen # 远端传输前先压缩序列化两条实用经验CPU 缓存容量建议至少是模型 KV 缓存的 2 倍否则还没攒出复用就被淘汰了数据要跨实例共享时remote_serde: cachegen这类压缩序列化能明显减少远端传输量远端后端的可选实现不少InfiniStore 和 MooncakeStore 都是常见选择examples/kv_cache_reuse/remote_backends/ 下有各后端的现成配置。LMCache 与 InfiniStore 配合时既能服务分离式集群prefill 节点与 decode 节点之间的 KV 传输也能服务普通集群做跨节点 KV 复用淘汰策略怎么选不踩坑缓存容量必然见顶cache_policy决定满的时候扔谁。可选值有 LRU、LFU、FIFO默认是 LRU。LRU最近最少使用默认值最省心。对话、Agent 这类最近活跃的数据最可能再来的场景闭眼选它LFU最不经常使用按访问频率淘汰。适合热点非常稳定的场景比如一批固定文档反复被查询缺点是冷启动阶段难以区分冷热FIFO先进先出最朴素。适合访问模式近似顺序、缓存条目生命周期短的场景批处理任务可以试⚠️ 常见坑命中率长期上不去时先别急着换策略。先查chunk_size是否和请求前缀长度错位太大会导致差几个 token 也算 miss再确认缓存容量有没有被无关流量挤爆。进阶调优NUMA 感知、优先级控制与缓存融合这三项都是默认不开、开了有收益的选项。NUMA 感知多路服务器上CPU 内存分属不同 NUMA 节点跨节点访问带宽明显下降。手动指定 GPU 与 NUMA 节点的绑定关系可以避免这个问题numa_mode: manual extra_config: gpu_to_numa_mapping: {0: 0, 1: 1} # GPU 0 只读 NUMA 0 的内存优先级控制priority_limit: 5表示只缓存优先级不超过 5 的请求。在线服务里高优流量付费用户、实时问答想独占缓存空间时用它可以把低优请求挡在缓存之外。缓存融合Cache Blending长上下文里不同请求常共享大量相同片段同一份系统提示、同一批文档但传统前缀匹配要求片段严格从头连续。融合技术允许把分散的缓存片段拼起来用只需对一小部分 token 重新计算来修正注意力结果enable_blending: True blend_recompute_ratios: 0.15 # 约 15% 的 token 走重算保证精度 blend_check_layers: 2 # 抽样检查前 2 层定位重算点 blend_special_str: ### # 片段边界分隔符examples/blend_in_process/ 里有完整的融合示例脚本。如果你的场景是很多请求共用同几份长文档这一项对命中率提升最直接。超长上下文的杀手锏分离式预填充当上下文长到单机显存装不下时LMCache 提供了 PD 分离Disaggregated Prefill把算 prefill和跑 decode拆到不同节点算好的 KV 缓存通过高性能传输通道直接搬给 decode 节点两边各自用最适合的硬件和 batch 策略。enable_pd: True pd_role: sender # 预填充节点填 sender接收端填 receiver transfer_channel: nixl # NIXL 传输通道 pd_buffer_size: 1073741824 # 1GB 传输缓冲 pd_buffer_device: cuda # 缓冲放 GPU 显存调参上两个点值得注意pd_buffer_size建议设成单次实际传输数据量的 2-3 倍留足余量分布式网络侧可以配nixl_backends: [UCX]启用 RDMA/UCX 类传输。一个硬约束要记住PD 模式和 P2P 共享互斥enable_pd: True时enable_p2p必须为 False。完整的 1P1D 与 XPYD 部署模板在 examples/disagg_prefill/含启动脚本可直接参考。多实例部署集中式共享与 P2P 两种玩法单个推理集群跑起来后下一个问题是多个 LMCache 实例能不能共享缓存可以有两种模式集中式共享所有实例把 KV 写到同一个远端后端Redis、InfiniStore、MooncakeStore 等任意实例都能命中别人算过的缓存。实现简单后端就是普通 KV 存储P2P 共享实例之间通过服务发现互相找到直接点对点传输 KV不依赖中心存储延迟更低P2P 模式的三个关键参数enable_p2p: True lookup_url: http://discovery-server:8080 # 服务发现地址 distributed_url: tcp://0.0.0.0:5555 # 节点间数据通信地址examples/kv_cache_reuse/share_across_instances/ 下分centralized_sharing和p2p_sharing两个子目录正好对应这两种模式的现成配置。选择口径很简单实例数量不多、已有统一存储基础设施 → 集中式实例多、对延迟敏感、带宽充足 → P2P。上线前自检清单监控、命中率目标与常见坑打开内部 API 服务器它是运行时观察 LMCache 状态的窗口默认关闭internal_api_server_enabled: True internal_api_server_host: 0.0.0.0 internal_api_server_port_start: 6999 # 默认端口起点API 服务器暴露了缓存命中率、内存占用、请求延迟等指标端点也支持运行时调参。配合 docs/source/production/observability/ 里的监控接入方案可以接进 Prometheus/Grafana 做长期观测。上线前过一遍这份清单命中率与容量命中率目标 70% 以上长期低于 50% 时先查chunk_size与请求前缀的对齐情况再考虑开缓存融合内存占用异常升高时把save_unfull_chunk设为 false不落盘不完整的小块分布式与网络P2P 模式下确认各节点时钟同步网络 MTU 配置一致PD 分离部署中prefill 侧延迟应控制在 decode 延迟的 50% 以内超了说明传输通道或缓冲要重新调完整参数定义都在 lmcache/v1/config.py 中文档站 docs/source/ 按主题拆成了存储后端、KV 缓存优化等章节。从起步配置跑通链路再按这份清单逐项收紧是踩坑最少的路径。【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
