LMCache CPU Offloading 实战指南将 KV Cache 卸载到 CPU 内存加速长上下文推理【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCacheLMCache 将 KV cache 视为可复用的第一等公民其中最基础、最常用的一类卸载目标是同机 CPU 内存。本指南以 vLLM v1 LMCache 为例完整演示如何通过环境变量或lmcache_config.yaml启用 CPU 内存后端覆盖离线推理LLM.generate、在线服务vllm serve curl两种场景并通过共享前缀多轮生成与超长上下文 TTFT两个实验验证卸载收益最后结合仓库源码剖析max_local_cpu_size、LRU 热缓存、Hugepages 等底层机制。读完你可以在自己的 GPU 上复现第二次生成加速 7 倍以上、超长上下文 TTFT 提升 44 倍的典型效果。注意本文档描述的是 LMCache 的 in-process进程内模式行为该模式已标记为 deprecated。生产环境请优先考虑特性更全、性能更好的 LMCache MP mode其对应文档见 L2 Storage 索引。什么时候需要卸载 KV CacheKV cache 是 LLM 推理期间在 GPU 显存中累积的中间张量随序列长度线性增长。当出现以下两种典型情形时仅靠 GPU 显存无法容纳 KV cache请求共享同一前缀长系统提示词、聊天应用中的历史会话、离线预处理数据的缓存——这些场景下大量 token 的 KV cache 是重复计算的GPU 显存有限长上下文如数万 token下 KV cache 总量超过显存容量无法全部驻留。将 KV cache 卸载到 CPU 内存后LMCache 可以在下一次请求到达时从 CPU 内存直接加载从而同时降低首 token 延迟TTFT与 GPU 重复计算开销。卸载目标不止 CPULMCache 还支持本地文件系统、Mooncake、InfiniStore、Redis、ValKey 等多种后端但 CPU 内存是延迟最低、配置最简单的起点。前置条件开始前请确认已安装带 LMCache 集成的 vLLM v1见 安装指南一台可运行 LLM 的 GPUCPU 卸载本身需要适量的系统内存见下文容量估算。离线推理用 CPU 卸载实现 KV 复用本小节演示在离线推理offline inference场景下如何用 LMCache vLLM 把 KV cache 存到 CPU 内存。示例脚本与 vLLM 仓库examples/others/lmcache/cpu_offload_lmcache.py中给出的用法一致。第一步设置 LMCache 环境变量import os # Set token chunk size to 256 os.environ[LMCACHE_CHUNK_SIZE] 256 # Enable CPU memory backend os.environ[LMCACHE_LOCAL_CPU] True # Set CPU memory limit to 5GB os.environ[LMCACHE_MAX_LOCAL_CPU_SIZE] 5.0三个变量的作用分别是LMCACHE_CHUNK_SIZE每个 KV chunk 包含的 token 数默认 256也是 KV cache 存取的最小粒度LMCACHE_LOCAL_CPU是否启用本地 CPU 内存后端默认即为TrueLMCACHE_MAX_LOCAL_CPU_SIZELMCache 预留的page-locked页锁定CPU 内存上限单位 GB默认 5.0。所谓 page-locked 是指内存页被固定可被 GPU 以 DMA 方式直接读写从而获得远高于普通内存的传输速度。这三个配置在源码中都有严格对应lmcache/v1/config.py 中chunk_size默认256、local_cpu默认True、max_local_cpu_size默认5.0并且全部支持环境变量注入。第二步配置 vLLM 接入 LMCachefrom vllm import LLM, SamplingParams from vllm.config import KVTransferConfig # Configure KV cache transfer to use LMCache ktc KVTransferConfig( kv_connectorLMCacheConnectorV1, kv_rolekv_both, ) # Initialize LLM with LMCache configuration # Adjust gpu_memory_utilization based on your GPU memory llm LLM(modelQwen/Qwen3-8B, kv_transfer_configktc, max_model_len8000, gpu_memory_utilization0.8)关键点kv_connectorLMCacheConnectorV1是 vLLM v1 中把 KV cache 传输交给 LMCache 的连接器kv_rolekv_both表示既保存store又加载loadKV cache。若只设为kv_producer/kv_consumer则分别只写或只读gpu_memory_utilization需要根据你的 GPU 显存调整例如 80 GB 的 A100/H100 可以调到 0.8–0.9。第三步运行推理并观察日志# Create example prompts with shared prefix shared_prompt Hello, how are you? * 1000 prompts [ shared_prompt Hello, my name is, ] # Define sampling parameters sampling_params SamplingParams(temperature0, top_p0.95, max_tokens10) # Run inference outputs llm.generate(prompts, sampling_params) for output in outputs: generated_text output.outputs[0].text print(fGenerated text: {generated_text!r})推理过程中 LMCache 会自动完成 KV cache 的保存与管理日志会输出类似LMCache INFO: Storing KV cache for 6006 out of 6006 tokens for request 0这表示该请求全部 6006 个 token 的 KV cache 已成功卸载到 CPU 内存。日志来自 vLLM 适配层 lmcache/integration/vllm/vllm_v1_adapter.py其中X out of Y tokens的X是本次实际写入的 token 数。第四步清理 LMCache 后端from lmcache.v1.cache_engine import LMCacheEngineBuilder from lmcache.integration.vllm.utils import ENGINE_NAME LMCacheEngineBuilder.destroy(ENGINE_NAME)LMCacheEngineBuilder是进程内模式下 LMCache 引擎的单例注册中心见 lmcache/v1/cache_engine.pydestroy会释放已创建的引擎实例与内存池。在线服务vLLM Server curl 验证缓存命中在线推理场景OpenAI 兼容服务的配置方式与离线完全等价只是把环境变量换成 YAML 配置文件。创建 lmcache_config.yamlchunk_size: 256 local_cpu: true max_local_cpu_size: 5除了这三个核心项LMCache 还支持通过lmcache_config.yaml扩展配置 chunk 大小、内存上限、存储后端等大量选项后文示例将逐一展开。启动 vLLM 服务LMCACHE_CONFIG_FILElmcache_config.yaml \ vllm serve \ Qwen/Qwen3-8B \ --kv-transfer-config \ {kv_connector:LMCacheConnectorV1, kv_role:kv_both }参数说明LMCACHE_CONFIG_FILELMCache 配置文件路径--kv-transfer-configvLLM 侧启用 LMCache 集成的开关kv_connector指定 LMCache 连接器kv_role设为kv_both同时保存与加载 KV cache。发送请求并观察命中日志curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen3-8B, prompt: |im_start|system\nYou are a helpful AI assistant.|im_end|\n|im_start|user\nWhat is the capital of France?|im_end|\n|im_start|assistant\n, max_tokens: 100, temperature: 0.7 }第一次请求冷缓存全部 miss后服务端日志LMCache INFO: Storing KV cache for 31 out of 31 tokens for request cmpl-274bcaa80837444dbf9fbba4155d2620-0 (vllm_v1_adapter.py:497:lmcache.integration.vllm.vllm_v1_adapter)再次发送完全相同的 curl 请求热缓存命中日志变为LMCache INFO: Reqid: cmpl-4ddf8863a6ac4dc3b6a952f2a107e9b2-0, Total tokens 31, LMCache hit tokens: 30, need to load: 14 (vllm_v1_adapter.py:543:lmcache.integration.vllm.vllm_v1_adapter)hit tokens: 30, need to load: 14的含义是该请求共 31 个 token其中 30 个命中了 CPU 内存中已有的 KV cache只需加载 14 个含 1 个新生成的 token 与部分 chunk 边界补齐前缀部分不再重复计算。这条命中/加载统计同样出自 vllm_v1_adapter.py其实现会对命中 token 数做min_retrieve阈值判断命中过少时跳过检索。实测收益共享前缀场景下的加速为了量化卸载收益官方示例脚本会生成多组共享前缀 不同索引的 prompt同一批 prompt 跑两遍对比第二遍热缓存相对第一遍冷缓存的加速比。硬件与模型选择脚本会自动根据 GPU 显存和计算能力挑选合适的 Qwen3 模型GPU 显存 / 架构自动选择的模型附加参数≥ ~36 GiB如 A100-80G、H100Qwen/Qwen3-8Bbf16无≥ ~24 GiB 且支持原生 FP8Ada Lovelace / Hoppersm_89如 L4、L40、RTX 4090Qwen/Qwen3-8B-FP8kv_cache_dtypefp8≥ ~10 GiB含不支持 FP8 的 Ampere 24 GiB 卡如 RTX A5000、RTX 3090Qwen/Qwen3-1.7B无脚本还会把 LMCache 的 pinned host buffer 上限自动钳制到系统 RAM 与RLIMIT_MEMLOCKulimit -l的约束之内因此在小内存主机上也能直接运行。完整示例脚本 cpu-offloading.py# SPDX-License-Identifier: Apache-2.0 This file demonstrates the example usage of cpu offloading with LMCache in vLLM v1. Note that lmcache needs to be installed to run this example. Learn more about LMCache in the LMCache project repository. import os import torch import argparse import time from lmcache.v1.cache_engine import LMCacheEngineBuilder from lmcache.integration.vllm.utils import ENGINE_NAME from vllm import LLM, SamplingParams from vllm.config import KVTransferConfig def parse_arguments() - argparse.Namespace: Parse command line arguments. parser argparse.ArgumentParser(descriptionCPU offloading example with LMCache) parser.add_argument(--num-prompts, typeint, default10, helpNumber of prompts to generate (default: 10)) parser.add_argument(--num-tokens, typeint, default10000, helpNumber of tokens per prompt (default: 10000)) parser.add_argument(--enable-lmcache, actionstore_true, helpEnable LMCache for CPU offloading (default: True)) return parser.parse_args() def pick_cpu_size_gb(workload_gb: float) - float: Clamp the LMCache pinned host buffer to fit system RAM and RLIMIT_MEMLOCK. cudaHostAlloc pins pages, so the buffer cannot exceed total RAM nor the per-process memlock limit (ulimit -l). On hosts where either is small, the original 1.5 GB per 10k tokens formula fails with cudaErrorMemoryAllocation. Args: workload_gb: Desired buffer size for the workload, in GiB. Returns: float: A buffer size in GiB that fits both caps, never below 1.0. import psutil ram_gib psutil.virtual_memory().total / (1024 ** 3) try: import resource memlock_soft, _ resource.getrlimit(resource.RLIMIT_MEMLOCK) memlock_gib ( float(inf) if memlock_soft resource.RLIM_INFINITY else memlock_soft / (1024 ** 3) ) except ImportError: # resource is POSIX-only; on Windows treat memlock as unbounded. memlock_gib float(inf) return max(min(workload_gb, ram_gib * 0.5, memlock_gib * 0.9), 1.0) def setup_lmcache_environment(num_prompts: int, num_tokens: int) - None: Configure LMCache environment variables. Args: num_prompts: Number of prompts to process num_tokens: Number of tokens per prompt workload_gb num_prompts * num_tokens * 1.5 / 10000 # 1.5 GB per 10k tokens cpu_size pick_cpu_size_gb(workload_gb) env_vars { LMCACHE_CHUNK_SIZE: 256, # Set tokens per chunk LMCACHE_LOCAL_CPU: True, # Enable local CPU backend LMCACHE_MAX_LOCAL_CPU_SIZE: str(cpu_size) # CPU memory limit (GB) } for key, value in env_vars.items(): os.environ[key] value def pick_model_and_kwargs() - tuple[str, dict]: Pick a Qwen model that fits the current GPUs memory and compute capability. Tiers: - 36 GiB - Qwen/Qwen3-8B (bf16) - 20 GiB and sm 89 - Qwen/Qwen3-8B-FP8 (native FP8) - 10 GiB - Qwen/Qwen3-1.7B - otherwise - RuntimeError Returns: tuple[str, dict]: (model id, extra kwargs to pass to LLM). Raises: RuntimeError: If no CUDA GPU is visible or it is too small. if not torch.cuda.is_available(): raise RuntimeError(No GPU available) total_gib torch.cuda.get_device_properties(0).total_memory / (1024 ** 3) major, minor torch.cuda.get_device_capability(0) sm major * 10 minor has_fp8 sm 89 # Ada Lovelace / Hopper if total_gib 36: return Qwen/Qwen3-8B, {} if total_gib 20 and has_fp8: print(f[fallback] GPU {total_gib:.1f} GiB sm_{sm}: using Qwen3-8B-FP8) return Qwen/Qwen3-8B-FP8, {kv_cache_dtype: fp8} if total_gib 10: print(f[fallback] GPU {total_gib:.1f} GiB sm_{sm}: using Qwen3-1.7B) return Qwen/Qwen3-1.7B, {} raise RuntimeError( fGPU has {total_gib:.1f} GiB; need at least 10 GiB for Qwen3-1.7B ) def create_test_prompts(num_prompts: int 10, num_tokens: int 1000) - list[str]: Create test prompts with index prefix and dummy body. Args: num_prompts: Number of prompts to generate num_tokens: Approximate number of tokens per prompt (using Hi as token unit) Returns: list: List of prompts with format [index] Hi Hi Hi... prompts [] dummy_text Hi * num_tokens for i in range(num_prompts): prompt f[Prompt {i}] {dummy_text} how are you? prompts.append(prompt) return prompts def initialize_llm(max_len: int 16384, enable_lmcache: bool True) - LLM: Initialize the LLM with a model auto-selected for the current GPU. Args: max_len: Maximum sequence length enable_lmcache: Whether to wire up the LMCache KV connector Returns: LLM: Configured LLM instance model_name, extra_kwargs pick_model_and_kwargs() ktc KVTransferConfig( kv_connectorLMCacheConnectorV1, kv_rolekv_both, ) if enable_lmcache else None return LLM( modelmodel_name, kv_transfer_configktc, max_model_lenmax_len, enable_prefix_cachingFalse, gpu_memory_utilization0.9, **extra_kwargs, ) def generate_and_print_output( llm: LLM, prompts: list[str], sampling_params: SamplingParams, ) - float: Generate text and print the results. Args: llm: LLM instance prompts: List of input prompts sampling_params: Configured sampling parameters Returns: float: Time taken for generation in seconds start_time time.time() outputs llm.generate(prompts, sampling_params) end_time time.time() for output in outputs: generated_text output.outputs[0].text print(fGenerated text: {generated_text!r}) return end_time - start_time def main() - None: Main execution function. # Parse command line arguments args parse_arguments() # Setup environment if LMCache is enabled if args.enable_lmcache: setup_lmcache_environment(args.num_prompts, args.num_tokens) # Create prompts and sampling parameters prompts create_test_prompts(num_promptsargs.num_prompts, num_tokensargs.num_tokens) sampling_params SamplingParams(temperature0, top_p0.95, max_tokens1) # Initialize model llm initialize_llm(enable_lmcacheargs.enable_lmcache) # First run print(\nFirst run:) first_run_time generate_and_print_output(llm, prompts, sampling_params) print(fFirst run time: {first_run_time:.2f} seconds) # Second run print(\nSecond run:) second_run_time generate_and_print_output(llm, prompts, sampling_params) print(fSecond run time: {second_run_time:.2f} seconds) # Print speedup if first_run_time 0: speedup first_run_time / second_run_time print(f\nSpeedup (first run / second run): {speedup:.2f}x) # Cleanup if LMCache was enabled if args.enable_lmcache: LMCacheEngineBuilder.destroy(ENGINE_NAME) if __name__ __main__: main()脚本要点每条 prompt 由[Prompt i]前缀 大量重复的Hi 构成所有 prompt 共享几乎相同的前缀第一轮llm.generate是冷缓存写第二轮是热缓存读两次耗时之比即加速比关闭 vLLM 原生 prefix cachingenable_prefix_cachingFalse确保收益完全来自 LMCache 的 CPU 卸载CPU 内存预算按经验公式1.5 GB per 10k tokens估算再用pick_cpu_size_gb钳制到系统 RAM 与 memlock 限制以内LMCacheEngineBuilder.destroy(ENGINE_NAME)在退出前释放引擎。运行与结果解读1. 不带 LMCache 运行python cpu-offloading.pySpeedup (first run / second run): 1.00x即使 vLLM 开启了 prefix caching两次运行也没有加速因为 KV cache 总量超过 GPU 显存根本无处可存无法复用。2. 启用 LMCache 运行python cpu-offloading.py --enable-lmcacheSpeedup (first run / second run): 7.43x第二次运行直接把共享前缀的 KV cache 从 CPU 内存读回跳过全部前缀重算获得约 7.4 倍的加速。这也说明当 KV cache 总量超过 GPU 显存时LMCache 的 CPU 卸载是让缓存放得下、用得上的关键手段。更长上下文的 TTFT 对比实验如果共享前缀还不够直观可以用超长上下文 流式输出感受更强烈的 TTFT 差异。完整的在线示例见 CPU RAM 后端文档这里给出核心步骤准备超长上下文约 38 万字节足够超出 GPU 显存能容纳的 KV cacheman bash man-bash.txt启动带 CPU 卸载的 vLLM 服务用cpu-offload.yaml配置文件等价于三个环境变量chunk_size: 256 local_cpu: true max_local_cpu_size: 5.0LMCACHE_CONFIG_FILEcpu-offload.yaml \ vllm serve \ meta-llama/Llama-3.1-8B-Instruct \ --max-model-len 16384 \ --kv-transfer-config \ {kv_connector:LMCacheConnectorV1, kv_role:kv_both}用流式请求连打两次同一长上下文分别记录冷/热 TTFT。官方示例在 L423 GB 显存上测得具体数字与你的硬件有关仅供参考Number of tokens in prompt: 15376 Cold TTFT: 6.537 seconds Warm TTFT: 0.147 seconds TTFT Improvement: 6.390 seconds (44.5x faster)服务端日志能清晰看到两条路径# 冷缓存miss 后按 chunk 逐段存储chunk_size2562048 是 256 的整数倍 LMCache INFO: Reqid: chatcmpl-8676f9b9ebf04c79a5d47b9ada7b65fd, Total tokens 15410, LMCache hit tokens: 0, need to load: 0 LMCache INFO: Storing KV cache for 2048 out of 12288 tokens for request chatcmpl-8676f9b9ebf04c79a5d47b9ada7b65fd LMCache INFO: Storing KV cache for 2048 out of 14336 tokens for request chatcmpl-8676f9b9ebf04c79a5d47b9ada7b65fd LMCache INFO: Storing KV cache for 1074 out of 15410 tokens for request chatcmpl-8676f9b9ebf04c79a5d47b9ada7b65fd # 热缓存几乎全部命中 LMCache INFO: Reqid: chatcmpl-136d9dac1ba94bd4b4ae85007e8ad437, Total tokens 15410, LMCache hit tokens: 15409, need to load: 1长上下文场景下 TTFT 提升尤为显著官方记录约 44.5x因为前缀越长、重复计算量越大而LMCache hit tokens: 15409说明第二次请求几乎只算了 1 个新 token。配置原理三个核心参数与后端源码配置参数与默认值CPU 卸载的完整配置定义集中在 lmcache/v1/config.py配置项YAML环境变量类型默认值说明chunk_sizeLMCACHE_CHUNK_SIZEint256每 chunk 的 token 数KV cache 存取粒度local_cpuLMCACHE_LOCAL_CPUboolTrue是否启用本地 CPU 后端默认开启max_local_cpu_sizeLMCACHE_MAX_LOCAL_CPU_SIZEfloat5.0预留的页锁定 CPU 内存上限GBlocal_cpu_use_hugepagesLMCACHE_LOCAL_CPU_USE_HUGEPAGESboolFalse是否使用 2 MiB 大页分配reserve_local_cpu_sizeLMCACHE_RESERVE_LOCAL_CPU_SIZEfloat0.0为系统其他进程预留的内存GB值得注意的源码细节max_local_cpu_size必须大于 0即使只用磁盘或远端后端CPU RAM 也会作为 GPU 传输的中转 buffer 被占用。源码 lmcache/v1/storage_backend/init.py 的注释明确写道local_cpu backend 总是被创建因为其他后端可能需要它作为 buffer且仅在max_local_cpu_size 0时才实际分配内存可以关掉local_cpu但保留 CPU bufferLMCACHE_LOCAL_CPUFalse时 CPU 内存不再作为 KV cache 的家但仍作为磁盘/远端传输的中转区系统内存自适应LocalCPUBackend在初始化时local_cpu_backend.py会把配置值钳制到系统可用内存 − 预留值避免分配失败。CPU 内存是热缓存配合 LRU 与预取当local_cpu: true与磁盘/远端后端Redis、Mooncake、Valkey、InfiniStore同时使用时CPU RAM 扮演热缓存hot cache角色存放来自磁盘与远端存储中最热最近访问的那部分 KV cache。缓存引擎同时提供prefetch 预取机制——如果预测某些 token 即将被请求例如结构化或 agentic 工作流可以提前把 KV cache 从磁盘/远端预载到页锁定 CPU 内存规避传输延迟。在 local_cpu_backend.py 的evict实现中可以看到CPU 热缓存在空间不足时通过 LRU 策略逐出并同步通知 batched msg sender 等下游组件当 CPU 内存需要用于磁盘/远端传输时同样会先 LRU 逐出本地 KV cache 腾出空间因此不会出现CPU pinned 内存耗尽的险情。Hugepages 支持降低 TLB 压力默认情况下 LMCache 用常规 4 KiB 页分配 CPU pinned 内存。当 KV cache 缓冲区达到数 GB 时启用 Linux hugepages2 MiB 页可以减少 TLBTranslation Lookaside Buffer压力、提升访存性能。系统级前置hugepages 必须在 LMCache 启动前由 OS 预先分配。所需页数 目标缓冲大小 ÷ 2 MiB 向上取整例如 5 GB 至少需要 2560 页# Allocate 2560 hugepages (5 GB) sudo sysctl -w vm.nr_hugepages2560 # Make persistent across reboots echo vm.nr_hugepages2560 | sudo tee -a /etc/sysctl.conf验证分配grep HugePages /proc/meminfo # HugePages_Total: 2560 # HugePages_Free: 2560LMCache 侧配置local_cpu_use_hugepages: true或环境变量export LMCACHE_LOCAL_CPU_USE_HUGEPAGEStrue限制对应源码 local_cpu_backend.py 中的显式校验hugepages 与 P2P 模式enable_p2p: true不兼容同时开启会直接抛出ValueError(Hugepages are not supported with P2P mode)hugepages 与共享内存设置shm_name不兼容非 CUDA 平台不支持 hugepages会自动回退到常规分配。支持的卸载目标一览LMCache 现已支持将 KV cache 卸载到以下目标本文的 CPU 内存是其中配置门槛最低的一个CPU memoryLocal file systemMooncake StorageInfiniStoreRedisValKey完整的后端清单见 Storage Backends 索引其中每个后端在 lmcache/v1/storage_backend/ 目录下都有独立实现。常见问题排查问题现象在 fork 出的子进程中初始化 vLLM/LMCache 报 CUDA 错误(EngineCore_DP0 pid55437) ERROR 10-04 14:44:47 [core.py:708] RuntimeError: Cannot re-initialize CUDA in forked subprocess. To use CUDA with multiprocessing, you must use the spawn start method原因Python 默认的fork多进程启动方式不允许在子进程中重新初始化 CUDA。解法一设置环境变量改用 spawn 方式export VLLM_WORKER_MULTIPROC_METHODspawn解法二把 vLLM/LMCache 的导入与调用全部收进if __name__ __main__:保护块if __name__ __main__: from vllm import LLM, SamplingParams from vllm.config import KVTransferConfig from lmcache.v1.cache_engine import LMCacheEngineBuilder from lmcache.integration.vllm.utils import ENGINE_NAME main()更完整的说明可参考 vLLM 官方文档的 Python multiprocessing 排障章节。实用提示若想反复运行query-twice.py这类脚本需要在两次运行之间重启 vLLM/LMCache 服务或改变传入上下文的文本前缀——因为 LMCache 已被上一次运行加热直接重跑会持续命中缓存--max-model-len与 GPU 显存相关显存更大的机器可以调高 max model length 并使用更长的上下文LMCache 的 TTFT 收益随上下文长度增加而更加显著若只关心前缀复用如长 system prompt、多轮聊天chunk_size可以保持默认 256若上下文极长可结合磁盘后端把冷数据下沉、让 CPU 只保留热数据形成 CPU热→ 磁盘/远端冷的分级缓存结构。小结本文完整覆盖了 LMCache CPU 内存卸载的三种用法离线推理、在线服务、以及可量化的收益实验。其核心机制可概括为三点页锁定 CPU 内存提供低延迟的 KV 中转与驻留max_local_cpu_size、按 chunkchunk_size粒度存取并支持 LRU 逐出与预取、通过 vLLM 的KVTransferConfig一行接入kv_connectorLMCacheConnectorV1。对于共享前缀 长上下文这类典型负载CPU 卸载让 KV cache 突破显存上限得以复用是实测 TTFT 提升 44 倍、二次生成加速 7 倍以上这类收益的直接来源。若需多机共享、更强的特性与性能请进一步阅读 LMCache MP mode 相关文档。【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考