LMCache 配置实战4 个阶段搭好你的 KV 缓存加速层【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCacheLMCache 是大模型推理栈里的 KV 缓存管理层把模型已经算过的 KV 缓存一段中间结果存下来、跨请求复用从而省掉重复的 prefill 计算、压低首 token 延迟TTFT。下面按「快速上手 → 单机调优 → 分布式共享 → 生产监控」四个阶段走一遍你只需要每个阶段写下必要的参数就能把配置搭对。阶段 1快速上手3 行 YAML 让缓存跑起来这一步解决的是让推理引擎第一次用上 KV 缓存的问题不用纠结任何高级项。安装很简单pip install lmcache即可然后把配置文件指向推理引擎。最小可用的配置长这样chunk_size: 256 # 缓存块大小每次存取 KV 的 token 粒度 local_cpu: True # 启用 CPU 内存作为缓存层 max_local_cpu_size: 10 # CPU 缓存上限单位 GB完整示例可以直接抄 examples/cache_with_configs/example.yaml。如果你更习惯环境变量所有参数都支持LMCACHE_前缀比如LMCACHE_CHUNK_SIZE、LMCACHE_LOCAL_CPU适合容器化部署注意一旦加载了 YAML 配置文件环境变量就会被忽略别混用两套。几个高频参数的按需查阅清单用到再回来查chunk_size默认 256缓存块越大命中率越高但内存碎片更明显local_disk: file:///path/to/cache加一层本地磁盘缓存配合max_local_disk_size控制上限remote_url接远程存储的入口格式为协议://host:portcache_policy淘汰策略可选 LRU / LFU / FIFO对话场景用默认 LRU 即可 这一阶段的目标只有一个确认日志里开始出现缓存命中再谈调优。阶段 2单机调优把命中率做上去这一步解决命中了但命中率不够高、或者内存占太多的问题。块大小、容量与淘汰策略chunk_size建议按模型规模选中小模型保持 256大模型可试 512 或 1024max_local_cpu_size经验值是模型 KV 缓存体积的 2 倍以上太小会频繁淘汰、命中率上不去内存紧张时把save_unfull_chunk设为False不缓存不满一块的尾巴能省下不少内存。⚠️ 注意开启缓存融合或分离式预填充时LMCache 会自动强制它回到True这是正常行为长上下文进阶开关缓存融合如果你的请求是多段文档拼起来的长 prompt典型如 RAG、多文档问答普通前缀缓存只能复用开头部分。缓存融合Cache Blending让任意位置的缓存块都能被复用牺牲少量重计算换质量enable_blending: True blend_special_str: # # # 用来切分可融合片段的标记串 blend_recompute_ratios: 0.15 # 约 15% 的 token 重算以恢复质量本地跑通流程可参考 examples/blend_in_process/多文档问答的基准配置在 benchmarks/multi_doc_qa/lmcache_blend.yaml。多 CPU 节点机器还可以把 NUMA 感知配成numa_mode: manual并在extra_config.gpu_to_numa_mapping里指定 GPU 与 NUMA 节点的对应关系提升内存带宽利用率。阶段 3分布式扩展让多实例共享一份缓存这一步解决多个推理实例各存各的、重复计算的问题分两条路共享现有缓存或者做分离式预填充。跨实例共享P2P 或集中式两种模式都有现成配置见 examples/kv_cache_reuse/share_across_instances/。P2P 模式的关键参数如下enable_p2p: True p2p_host: localhost p2p_init_ports: 8200 # 节点间建连端口 p2p_lookup_ports: 8201 # 缓存位置查询端口 transfer_channel: nixl # 用 NIXL 高性能传输通道搬 KV如果缓存量大到本地放不下就给remote_url配一个远程后端Redis/Valkey、Mooncake、InfiniStore、S3 兼容对象存储等都支持并指定remote_serde: cachegen这类压缩序列化降低传输与存储开销。分离式预填充Prefill 和 Decode 拆开跑超长上下文下把算 prefill 的节点和吐 token 的节点拆开能显著扩展上下文上限。预填充节点配置核心就这几项解码端角色改成receiver即可enable_pd: True pd_role: sender # 本节点是预填充端 transfer_channel: nixl pd_buffer_size: 1073741824 # 1GB 传输缓冲 pd_buffer_device: cuda nixl_backends: [UCX] # RDMA 场景走 UCX完整的 1 预填充 1 解码部署模板含启动脚本在 examples/disagg_prefill/1p1d/扩到多机就参考 examples/disagg_prefill/xpyd/。⚠️ 一个容易踩的坑pd_buffer_size要能装下整段 prefill 的 KV官方注释里给了公式buffer (max_prefill_len // chunk_size 1) * kv_size不够会分配超时。阶段 4生产监控看得到才管得住这一步解决上了线之后到底有没有效、出问题了怎么定位的问题。打开内部 API 服务器即可拿到运行时指标命中率、内存水位、请求级延迟等和日志级别控制internal_api_server_enabled: True internal_api_server_port_start: 6999 # 实际端口 起始端口 节点序号想接 Prometheus / Grafana / Tempo 做完整可观测栈直接看 examples/observability/ 里的 docker-compose 模板。想量化这块卡上到底能快多少可以用仓库自带的 TTFT 估算器出问题时按这个顺序排查最快命中率低 → 先看chunk_size是否匹配 prompt 结构长 prompt 场景开缓存融合内存占用过高 → 调小max_local_cpu_size、关掉save_unfull_chunk分布式偶发不同步 → 检查各节点时间同步和网络 MTU 是否一致下一步建议你这样做从阶段 1 的三行配置起步先拿lmcacheCLI 的ping/query确认缓存真的在写入和命中用 examples/ 下对应你场景的目录kv_cache_reuse、disagg_prefill、online_session做对照实验一次只改一个参数完整参数规范随时查 docs/source/api_reference/configurations.rst比死记硬背参数表更可靠【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
