尧图网页设计 
LMCache 配置实战KV缓存命中率与PD分离怎么调才不踩坑【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache先说清楚 LMCache 是个什么角色它夹在推理引擎vLLM、SGLang 等和存储之间把 KV 缓存当作独立的一层来管理——复用、分层、跨实例共享、预填充和解耦都发生在这层里。写 LMCache 配置时最容易犯的错误是把每个参数都当成开关去翻而不是先想清楚自己处在哪种部署形态。所以下面所有内容都按场景走你处在哪个阶段就翻哪一节。完整参数表在 docs/source/api_reference/configurations.rst需要逐字段查的时候再看它。先决定YAML 还是环境变量LMCache 的参数有两种入口不是谁更高级而是各管一种场景YAML 配置文件参数多、有层级关系比如extra_config里还套参数时用文件。它版本可控、可以进代码库 review是生产部署的正解。LMCACHE_前缀环境变量适合容器化环境里快速覆盖个别参数比如把LMCACHE_MAX_LOCAL_CPU_SIZE提到环境变量里不为了改一个值去动挂载的配置。二者的优先级要记死一旦存在配置文件环境变量就完全不生效。这不是环境变量覆盖文件而是文件整个吞掉环境变量。所以别在 K8s 里既挂 configmap 又设一堆LMCACHE_变量然后疑惑为什么没生效——检查顺序时先看文件是否存在。单机起步一份最小可用的配置第一次接 LMCache 时建议从最少的参数开始跑通再加chunk_size: 256 local_device: cpu local_cpu: True max_local_cpu_size: 10这四行就是仓库里 examples/cache_with_configs/example.yaml 的全部内容解释一下每个值为什么是它local_cpu: True是最小缓存形态。不开 CPU 层的话 LMCache 基本没东西可缓存先保证这条链路通。max_local_cpu_size: 10单位是 GB。如果你的请求前缀经常超过 10 个块这里要跟着调大反过来如果机器内存就这么多先调小观察淘汰频率。chunk_size: 256决定缓存的切分粒度。不改时块大小是 256 个 token。它影响命中率的方式比较隐蔽块越大同一前缀的复用越整但部分复用的浪费也越大你的前缀重复模式偏长比如长文档问答就保持 256 甚至调大偏短就调小。local_device: cpu指定本地缓存放哪单机阶段用 CPU 内存即可别一上来就上磁盘。这份配置解决的问题只有一个让 KV 缓存先在进程外活下来后续所有高级功能都是在这条链路上长出来的。把 KV 缓存分层到 CPU、磁盘和远程缓存容量不够时往下加一层比横向买机器便宜。三层的定位可以压缩成一张表层级对应参数默认值什么时候该动CPU 内存max_local_cpu_size5.0 GB命中率正常但缓存总量装不下热数据本地磁盘local_diskmax_local_disk_size未启用CPU 层频繁淘汰、数据有明显的温冷分层远程存储remote_url未启用多实例要共享同一份缓存local_cpu: True max_local_cpu_size: 20 local_disk: file:///data/lmcache/disk max_local_disk_size: 100 remote_url: infinistore://192.168.1.100:50051取舍逻辑是访问频率定层级高频复用的热前缀留在 CPU几小时到几天内还可能被碰到的放磁盘跨实例共享的交给远程后端InfiniStore、Mooncake 这类examples/kv_cache_reuse/remote_backends/ 里有各后端的连接模板。一个容易忽略的点如果远程存储走压缩序列化remote_serde读取时会有反序列化开销短前缀、高 QPS 场景要实测再决定开不开。命中率偏低怎么查命中率上不去九成是块被提前淘汰或能复用的没被算作复用这两类问题。按症状走症状命中率整体低、且随流量上升恶化可能原因CPU 层太小热数据被冷数据挤出。调max_local_cpu_size经验值是模型 KV 缓存量的两倍起步确认是容量问题再加磁盘层。症状命中率低但缓存容量明显够用可能原因淘汰策略不匹配。cache_policy默认是 LRU适合对话类最近的前缀最可能再来的模式如果你的业务是批处理、访问顺序基本固定FIFO 反而更稳不因为偶发访问把还没轮到的块顶掉。LFU 留给热点非常稳定的场景一般用不上。症状长上下文、多文档拼接的请求命中率特别差可能原因每个完整前缀都要精确匹配才算命中两个只差后文的长请求互相帮不上忙。这时候开缓存融合enable_blending: True blend_recompute_ratios: 0.15 blend_check_layers: 2 blend_special_str: ### 融合允许部分命中——命中的块直接用剩下的重算。blend_recompute_ratios控制重算比例调低省算力但结果偏差风险变大blend_check_layers是检查层数层数越多判断越准但开销越大。参数语义可以在 lmcache/v1/config.py 里对跑通前建议先用blend_recompute_ratios: 0.15这类偏保守的值。cache_policy: FIFO save_unfull_chunk: False第二个开关针对另一类漏不完整的块默认也会存下来占空间且几乎不会命中命中率低又怀疑碎片浪费时把它关掉。多实例共享与 PD 分离怎么搭单机跑通后两条扩展路线横向多个推理实例共享一份缓存和纵向预填充与解码拆开。横向跨实例共享分两种拓扑。集中式是共享一个远端存储remote_urlremote_serdeexamples/kv_cache_reuse/share_across_instances/centralized_sharing/ 的示例就三个参数P2P 是各实例互相当 peer需要多配一组端口类参数enable_p2p: True p2p_host: localhost p2p_init_ports: 8200 p2p_lookup_ports: 8201 transfer_channel: nixl enable_controller: True controller_pull_url: localhost:8300p2p_init_ports和p2p_lookup_ports是多实例握手与查找用的改端口时两个节点要对称改。纵向PD 分离把 Prefill 和 Decode 放到不同节点各自只配自己的角色enable_pd: True transfer_channel: nixl pd_role: sender # 预填充节点解码节点写 receiver pd_proxy_host: localhost pd_proxy_port: 7500 pd_buffer_size: 1073741824 pd_buffer_device: cuda nixl_backends: [UCX] pd_max_prefill_len: 16384角色分工sender预填充端算完 KV 后经 NIXL 通道推给receiver解码端接管解码。两个参数最容易配错pd_buffer_size必须装得下单次预填充的 KV参考公式是(pd_max_prefill_len // chunk_size 1) * kv_size不够会直接分配失败pd_buffer_device写cuda用 GPU 显存做缓冲、延迟低但挤占显存显存紧就换 CPU。完整的一预填一解码部署模板在 examples/disagg_prefill/1p1d/配置加启动脚本多预填多解码的代理层参考 examples/disagg_prefill_mp/。运行期抓手内部 API 和插件上线之后不需要重启才能看状态。打开内部 API 服务器internal_api_server_enabled: True internal_api_server_host: 0.0.0.0 internal_api_server_port_start: 6999port_start是起始端口调度器进程占用它worker 进程往上排。打开后缓存命中、内存水位这类指标和运行时状态都能从 HTTP 端点拿接 Prometheus 之类的监控直接对接。插件则用于不想动 LMCache 源码的扩展比如自定义缓存策略或把指标喂给自家监控plugin_locations指向插件目录即可机制和用法参考 examples/runtime_plugins/。调优 checklist存在 YAML 配置文件时LMCACHE_环境变量全部失效——先查这个再查别的chunk_size跟着前缀长度模式走长文档场景别用太小CPU 层容量给到模型 KV 缓存量的 2 倍再观察别按够用给命中率低先分辨是容量不足还是策略不匹配再加层长上下文/多文档请求命中率差才考虑开 blending重算比例先保守PD 分离的pd_buffer_size按公式算最小值再上浮不够会分配失败显存紧张时pd_buffer_device从 cuda 换 cpu 换延迟P2P 多实例的端口参数两端对称修改碎片化严重就关save_unfull_chunk上线后开内部 API 服务器命中率低于预期先从监控数据找证据再动参数下一步按你的部署形态翻对应目录——单机从 examples/cache_with_configs/ 起步跨实例共享看 examples/kv_cache_reuse/PD 分离直接跑 examples/disagg_prefill/1p1d/ 里的启动脚本把仓库自带的示例当基线改比从零写配置稳得多。【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LMCache 配置实战：KV缓存命中率与PD分离怎么调才不踩坑
LMCache 配置实战KV缓存命中率与PD分离怎么调才不踩坑【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache先说清楚 LMCache 是个什么角色它夹在推理引擎vLLM、SGLang 等和存储之间把 KV 缓存当作独立的一层来管理——复用、分层、跨实例共享、预填充和解耦都发生在这层里。写 LMCache 配置时最容易犯的错误是把每个参数都当成开关去翻而不是先想清楚自己处在哪种部署形态。所以下面所有内容都按场景走你处在哪个阶段就翻哪一节。完整参数表在 docs/source/api_reference/configurations.rst需要逐字段查的时候再看它。先决定YAML 还是环境变量LMCache 的参数有两种入口不是谁更高级而是各管一种场景YAML 配置文件参数多、有层级关系比如extra_config里还套参数时用文件。它版本可控、可以进代码库 review是生产部署的正解。LMCACHE_前缀环境变量适合容器化环境里快速覆盖个别参数比如把LMCACHE_MAX_LOCAL_CPU_SIZE提到环境变量里不为了改一个值去动挂载的配置。二者的优先级要记死一旦存在配置文件环境变量就完全不生效。这不是环境变量覆盖文件而是文件整个吞掉环境变量。所以别在 K8s 里既挂 configmap 又设一堆LMCACHE_变量然后疑惑为什么没生效——检查顺序时先看文件是否存在。单机起步一份最小可用的配置第一次接 LMCache 时建议从最少的参数开始跑通再加chunk_size: 256 local_device: cpu local_cpu: True max_local_cpu_size: 10这四行就是仓库里 examples/cache_with_configs/example.yaml 的全部内容解释一下每个值为什么是它local_cpu: True是最小缓存形态。不开 CPU 层的话 LMCache 基本没东西可缓存先保证这条链路通。max_local_cpu_size: 10单位是 GB。如果你的请求前缀经常超过 10 个块这里要跟着调大反过来如果机器内存就这么多先调小观察淘汰频率。chunk_size: 256决定缓存的切分粒度。不改时块大小是 256 个 token。它影响命中率的方式比较隐蔽块越大同一前缀的复用越整但部分复用的浪费也越大你的前缀重复模式偏长比如长文档问答就保持 256 甚至调大偏短就调小。local_device: cpu指定本地缓存放哪单机阶段用 CPU 内存即可别一上来就上磁盘。这份配置解决的问题只有一个让 KV 缓存先在进程外活下来后续所有高级功能都是在这条链路上长出来的。把 KV 缓存分层到 CPU、磁盘和远程缓存容量不够时往下加一层比横向买机器便宜。三层的定位可以压缩成一张表层级对应参数默认值什么时候该动CPU 内存max_local_cpu_size5.0 GB命中率正常但缓存总量装不下热数据本地磁盘local_diskmax_local_disk_size未启用CPU 层频繁淘汰、数据有明显的温冷分层远程存储remote_url未启用多实例要共享同一份缓存local_cpu: True max_local_cpu_size: 20 local_disk: file:///data/lmcache/disk max_local_disk_size: 100 remote_url: infinistore://192.168.1.100:50051取舍逻辑是访问频率定层级高频复用的热前缀留在 CPU几小时到几天内还可能被碰到的放磁盘跨实例共享的交给远程后端InfiniStore、Mooncake 这类examples/kv_cache_reuse/remote_backends/ 里有各后端的连接模板。一个容易忽略的点如果远程存储走压缩序列化remote_serde读取时会有反序列化开销短前缀、高 QPS 场景要实测再决定开不开。命中率偏低怎么查命中率上不去九成是块被提前淘汰或能复用的没被算作复用这两类问题。按症状走症状命中率整体低、且随流量上升恶化可能原因CPU 层太小热数据被冷数据挤出。调max_local_cpu_size经验值是模型 KV 缓存量的两倍起步确认是容量问题再加磁盘层。症状命中率低但缓存容量明显够用可能原因淘汰策略不匹配。cache_policy默认是 LRU适合对话类最近的前缀最可能再来的模式如果你的业务是批处理、访问顺序基本固定FIFO 反而更稳不因为偶发访问把还没轮到的块顶掉。LFU 留给热点非常稳定的场景一般用不上。症状长上下文、多文档拼接的请求命中率特别差可能原因每个完整前缀都要精确匹配才算命中两个只差后文的长请求互相帮不上忙。这时候开缓存融合enable_blending: True blend_recompute_ratios: 0.15 blend_check_layers: 2 blend_special_str: ### 融合允许部分命中——命中的块直接用剩下的重算。blend_recompute_ratios控制重算比例调低省算力但结果偏差风险变大blend_check_layers是检查层数层数越多判断越准但开销越大。参数语义可以在 lmcache/v1/config.py 里对跑通前建议先用blend_recompute_ratios: 0.15这类偏保守的值。cache_policy: FIFO save_unfull_chunk: False第二个开关针对另一类漏不完整的块默认也会存下来占空间且几乎不会命中命中率低又怀疑碎片浪费时把它关掉。多实例共享与 PD 分离怎么搭单机跑通后两条扩展路线横向多个推理实例共享一份缓存和纵向预填充与解码拆开。横向跨实例共享分两种拓扑。集中式是共享一个远端存储remote_urlremote_serdeexamples/kv_cache_reuse/share_across_instances/centralized_sharing/ 的示例就三个参数P2P 是各实例互相当 peer需要多配一组端口类参数enable_p2p: True p2p_host: localhost p2p_init_ports: 8200 p2p_lookup_ports: 8201 transfer_channel: nixl enable_controller: True controller_pull_url: localhost:8300p2p_init_ports和p2p_lookup_ports是多实例握手与查找用的改端口时两个节点要对称改。纵向PD 分离把 Prefill 和 Decode 放到不同节点各自只配自己的角色enable_pd: True transfer_channel: nixl pd_role: sender # 预填充节点解码节点写 receiver pd_proxy_host: localhost pd_proxy_port: 7500 pd_buffer_size: 1073741824 pd_buffer_device: cuda nixl_backends: [UCX] pd_max_prefill_len: 16384角色分工sender预填充端算完 KV 后经 NIXL 通道推给receiver解码端接管解码。两个参数最容易配错pd_buffer_size必须装得下单次预填充的 KV参考公式是(pd_max_prefill_len // chunk_size 1) * kv_size不够会直接分配失败pd_buffer_device写cuda用 GPU 显存做缓冲、延迟低但挤占显存显存紧就换 CPU。完整的一预填一解码部署模板在 examples/disagg_prefill/1p1d/配置加启动脚本多预填多解码的代理层参考 examples/disagg_prefill_mp/。运行期抓手内部 API 和插件上线之后不需要重启才能看状态。打开内部 API 服务器internal_api_server_enabled: True internal_api_server_host: 0.0.0.0 internal_api_server_port_start: 6999port_start是起始端口调度器进程占用它worker 进程往上排。打开后缓存命中、内存水位这类指标和运行时状态都能从 HTTP 端点拿接 Prometheus 之类的监控直接对接。插件则用于不想动 LMCache 源码的扩展比如自定义缓存策略或把指标喂给自家监控plugin_locations指向插件目录即可机制和用法参考 examples/runtime_plugins/。调优 checklist存在 YAML 配置文件时LMCACHE_环境变量全部失效——先查这个再查别的chunk_size跟着前缀长度模式走长文档场景别用太小CPU 层容量给到模型 KV 缓存量的 2 倍再观察别按够用给命中率低先分辨是容量不足还是策略不匹配再加层长上下文/多文档请求命中率差才考虑开 blending重算比例先保守PD 分离的pd_buffer_size按公式算最小值再上浮不够会分配失败显存紧张时pd_buffer_device从 cuda 换 cpu 换延迟P2P 多实例的端口参数两端对称修改碎片化严重就关save_unfull_chunk上线后开内部 API 服务器命中率低于预期先从监控数据找证据再动参数下一步按你的部署形态翻对应目录——单机从 examples/cache_with_configs/ 起步跨实例共享看 examples/kv_cache_reuse/PD 分离直接跑 examples/disagg_prefill/1p1d/ 里的启动脚本把仓库自带的示例当基线改比从零写配置稳得多。【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考