AI Agent 技术疾速发展，催生了对于超长上下文与信息处理的迫切需求，这使得大模型推理在性能与算力层面遭遇了严峻瓶颈。当前主流的 KV-Cache 方案虽能通过缓存中间数据到显存，以此提升推理速度，但有限且昂贵的显存占用，成为制约高效推理的关键瓶颈。

为应对上述挑战，Nvidia、DaoCloud 等伙伴，基于开源社区先进的 LMCache 高效缓存的技术，构建软硬件协同优化架构，实现了对 KV Cache 的高效分层存储与调度，在大幅缓解显存压力的同时，有效提升模型生成速度，并联合超擎数智、联想凌拓等厂商投入数千万元设备和资源展开优化实测。结果显示，基于该方案的推理性能显著提升：在中等长度上下文（约10K tokens）的典型场景中，首 Token 响应时间大幅缩短，吞吐量更是实现近 24 倍提升。这一成果为 KV Cache 分层存储方案在生产环境的稳定落地，以及长上下文场景下大模型推理的规模化应用，奠定了坚实基础。

01 KV-Cache 及其应用挑战

在走进测试之前，首先我们来了解一下到底什么是 KV-Cache 及其技术原理？

KV-Cache（键值缓存）是大语言模型（LLM）在推理过程中注意力机制的核心数据结构之一。举例说明，如你给模型输入：“我想吃水果，推几种”（假设这句话包含 7 个 token）。它一共包含两个阶段：

• 预填充阶段（Prefill）：模型会先把这 7 个 token “一次性” 处理完 —— 计算每个 token 的 Key 和 Value，然后全部存进 KV Cache 里。这一步是为了 “吃透” 你给的初始上下文，相当于 “把起点信息记牢”。
• 生成回复阶段（Decode）：模型先生成首个回复 token，比如 “苹果”（假设一种水果词汇，是一个 token）。计算 “苹果” 的 Key 和 Value，存进 KV Cache（现在 Cache 里有初始 7 组+“苹果”，共 8 组）；

再生成第二个token “橙子”：只需要计算 “橙子” 的 Key 和 Value，不用重新算前面已有的 8 组 KV，直接从 Cache 里拿，快速完成和 “橙子”“水果” 等的关联计算，算完后把 “橙子” 的 KV 也存进去；以此类推，直到生成完整回复（比如 “苹果橙子，都是富含维 C 的健康水果。”）

整个过程里，KV-Cache 就像“实时更新的备忘录”：初始输入一次性记全，后面每生成一个新 token，只算新的 KV 并补充进去，前面的信息直接复用 —— 这样就省了大量重复计算，让生成速度快很多。但问题是：你输入、输出的话越长（比如写一篇长文章），KV-Cache 里存的 Key 和 Value 就越多，会占满模型的 “高速内存”（GPU 显存），这就成了麻烦。LMCache 则通过将部分缓存数据从 GPU 卸载（offload）至 CPU 内存或远程存储（如 NVMe-oF、网络存储），有效解决了这一问题。

为推进技术从理论走向落地，验证相关能力，Nvidia、DaoCloud、超擎数智、联想凌拓等厂商进行了软硬件协同联合实测，其中，DaoCloud 重点负责测试设计、模型部署、LMCache 缓存策略配置、压测执行及性能数据分析等工作，Nvidia 提供 GPU、交换机等硬件及技术支持，超擎数智供应搭载高性能 GPU 的服务器与测试环境，联想凌拓提供高性能存储服务器，共同为测试落地提供坚实支撑。

详情请见后文：

02 测试设置

本次测试以企业多轮对话为模拟场景，其所需环境配置如下：

1.测试环境

超擎 CQ7688-L * 1：搭载 NVIDIA H20 GPU，8U8 卡 NVLink，8U 空间内搭载 1 块 NVIDIA Hopper 架构 HGX-8GPU 模组，系统支持 4.0Tbps 网络带宽，包含 8 张东西向 400Gbps Bluefield-3 SuperNIC 加上 2 张南北向 400Gps BlueField-3 DPU；

ROCE 交换机 * 6：采用 NVIDIA 第五代 Spectrum 以太网交换机，计算网络和存储网络均采用 SN5600 进行组网；

存储服务器：

1. 采用联想问天 WR5220 G3 高性能存储服务器，基于 RDMA 的 NFS 协议挂载到本地，最大读带宽可达 400Gbps；

2. 基于 RDMA 的 NVMe-oF 协议挂载到本地的网络存储，最大读带宽可达 800Gbps；

软件平台：采用 DaoCloud 提供的 d.run 算力调度平台。

模型部署

模型 D****eepseek-R1-0528 使用镜像 lmcache/vllm-openai:v0.3.3 部署，对应的 vllm 版本是 v0.10.0.x，使用 CUDA 12.8。

我们使用 TP8 部署，关闭了 vllm 前缀缓存，以减少测试干扰，由于是单机系统，所以直接使用P/D一体的配置（kv_role=kv_both）, 通过Kubernetes 启动参数如下：

apiVersion: apps/v1kind:Deployment...spec:template:    ...    spec:      containers:      -name:vllm        image:lmcache/vllm-openai:v0.3.3        command:        -"/opt/venv/bin/vllm"        -"serve"        -"/mnt/DeepSeek-R1-0528"        -"--host"        -"0.0.0.0"        -"--port"        -"8000"        -"--tensor-parallel-size"        -"8"        -"--no-enable-prefix-caching"        -"--disable-log-requests"        -"--kv-transfer-config"        -'{"kv_connector":"LMCacheConnectorV1","kv_role":"kv_both"}'        securityContext:          runAsNonRoot:false        env:        ...# 指定LMCache的配置环境变量，详见下文        resources:          limits:            nvidia.com/gpu:8        ...        volumeMounts:        -name:cache-volume          mountPath:/path/to/cache    # path for kv-cache offload        -name:dshm          mountPath:/dev/shm        -name:udev-volume          mountPath:/run/udev      # for GDS          readOnly:true        -name:model-pv          mountPath:/mnt/DeepSeek-R1-0528      volumes:      -name:cache-volume        nfs:                 # <--- 如果使用NVMe-oF,则可挂载hostPath           server:$NFS_IP          path:$NFS_PATH          mountOptions:            -vers=3            -proto=rdma        # essential for GDS            -nconnect=8            -sync      -name:udev-volume    # for GDS        hostPath:          path:/run/udev          type:Directory      ...      -name:dshm        emptyDir:          medium:Memory          sizeLimit:10.24Gi

2.LMCache 配置

通过调整 LMCache 的设置，可以切换不同的 Offload 介质：

• 比如可以只用内存/只用存储，或者同时使用内存和存储（内存作为 L2 级缓存，而存储作为 L3 级缓存）

此外，LMCache 对存储的 IO 读写， 还提供不同的 IO 模式：

• LocalDisk模式(下文称“Non-GDS模式” ) 是一个通用的、兼容性强的存储 I/O 方式，不仅仅是访问本地磁盘，也可以是 OS 能够访问的任何文件系统路径，包括挂载到本地的远程存储，数据路径是 GPU->CPU->Storage。
• GDS 模式利用 NVIDIA 的 GPUDirect Storage (GDS) 技术，实现了数据从兼容的存储直接传输到 GPU 显存，相比 LocalDisk 模式，绕过了 CPU，从而获得更低的延迟和更高的吞吐量。

本文的后端存储统一采用高性能的网络存储, 通过 BlueField-3 网卡和 Nvidia GPU 之间实现 GDS 的高速直通， 并利用 Spectrum 交换机在存储和 GPU 机器之间提供稳定和高性能的传输。

在测试中，对 CPU offload（内存）和存储 offload（外部挂载）以及不同的读写模式， 所带来的大模型推理的性能差异进行了对比。

LMCache 的配置都可以通过环境变量的方式添加到 vLLM 启动命令之前：

如果仅使用“CPU-Offload”模式（仅用 RAM）做 L2 缓存时，配置如下

LMCACHE_USE_EXPERIMENTAL=True LMCACHE_CHUNK_SIZE=256             # 示多少token作为一个Chunk，用于在IO存储时的优化LMCACHE_MAX_LOCAL_CPU_SIZE=100     # 这个范例 使用100G的内存上限，来做L2 KV-Cache缓存

在“Non-GDS”模式下 时配置如下：

LMCACHE_LOCAL_DISK=\"file:///mnt/cache/deepseek-r1-file/\" LMCACHE_MAX_LOCAL_DISK_SIZE=5000.0

在使用 GDS（GPU Direct Storage）作为存储后端时，需要关闭 CPU offloading：

LMCACHE_CUFILE_BUFFER_SIZE="8192" LMCACHE_LOCAL_CPU=FalseLMCACHE_GDS_PATH=\"/mnt/cache/deepseek-r1-gds/\"LMCACHE_EXTRA_CONFIG='{\"create_lookup_server_only_on_worker_0\":true}'

LMCACHE_EXTRA_CONFIG=‘{“create_lookup_server_only_on_worker_0”:true}’ 是为了解决 TP 下每个 rank 的元数据不同步的问题。

3.压测

• 使用 vllm 提供的 bench 命令来进行压测
• 使用 random 生成的数据集，可以对输入长度有更精确的控制（例如 100k 的长度）
• 为了排除一些随机性的干扰，保证每轮请求的 prompt 相同，在多轮间使用相同随机种子 seed；

如下：

vllm bench serve \  --model /models/DeepSeek-R1-0528 \  --dataset-name random \  --seed "$SEED" \  --num-prompts 50 \  --max-concurrency 16 \  --random-input-len "$input_len" \  --random-output-len 1

03 测试步骤和结果

1.测试目标

在同样的高性能网络存储下：

• 验证开启 KV Cache 后所带来的性能提升
• 测试不同的存储 IO 模式带来的性能提升的变化
• 测试不同网络带宽（相同的存储 IO 模式条件下）下带来的性能提升

2.测试步骤

• 测试主要集中在 KV Cache 缓存的利用效率上，为了避免算力成为测试的瓶颈，所以大部分场景下测试 Prefill 场景（输出长度是1）；
• 上下文长度分布选取 100，1k，10k，50k，100k，不同场景上下文长度变化较大，作为参考：

• 多轮对话场景：初期轮次平均在 500～2K，中后期能达到 5K–10K tokens；

• AI辅助编程场景：平均在 4K–16K tokens，极端情况能达到 50k 以上；

• RAG 会选取多个文档一起发送，长度一般会在 8K~32K 之间；

• 针对每一个长度和后端，使用相同的输入 重复测试 10 轮，并取第 2~9 轮的结果作为平均值；

3.指标选择

• TTFT（首 Token 响应时长）：TTFT 是本次测试关注的主要指标。通过复用 KV Cache 消除了 Prefill 阶段重新计算的时长，使得首 Token 的时间极大降低；
• Total token throughput（总体的 token 吞吐量）：伴随着首 Token 的响应时长的降低，系统的吞吐量会上升

4.测试结果

不同存储后端的比较

LMCache 支持不同的存储后端，对接不同的存储介质和存储协议，因此首先对不同的存储介质进行了基准测试。

主要选取如下几种场景对比，进行测试：如下图：

• 不开启 KV Cache 复用（如下图红色）
• 使用 CPU RAM 做 KV-Cache Offload（我们设置每个 Rank 的可用 RAM 大小为 100G，如下图例 cpu, 绿色）
• 对接网络带宽 400Gbps 的高速网络存储，并使用“Non-GDS”的存储模式（下图例（non-gds），深蓝色）
• 对接网络带宽 400Gbps 的高速网络存储，并使用“GDS”的存储模式（ 下图例（gds），靛蓝色）

测试结果如下，图片使用相同的 Prompt 测试了 10 轮，每轮 50 条请求，并选取 2~10 轮的结果的平均值来绘制。

图 2 是 TTFT 的延迟对比（Y 轴数值越低越好），图 3 是 token 吞吐的对比（Y 轴数值越高越好）

从图 3 可以看到相对于没有 KV Cache 复用的情况下，KV-Cache Offload带来的吞吐量最大有近 24 倍的提升；发生在上下文长度 10k（104），使用 CPU offloading 的场景。 但是随着上下文长度增长（>=100k），总的 KV Cache 存储量的增加，由于内存缓存区空间耗尽，这时 CPU offloading 的价值不在，基本上没有 Cache 被重用，和重算的效果相同，这时大容量网络存储的优势就体现出来，在超长上下文下，在 Nvidia Spectrum 网络加成下的高速网络存储的吞吐增益达到近 10 倍。

图 2：不同介质的 Mean TTFT 比较

图 3：不同介质的 Total Token Throughput 比较

测试结果也显示出 GDS 的存储 IO 模式，效果基本上始终好于“Non-GDS”的模式，相比而言在 Throughput 上有 32.5%~96.6% 的增长。

图 4：相较于无 KV Cache 不同介质带来的 Throughput 提升

不同网络带宽带来的推理性能增益的比较

通过调整 GPU 节点和网络存储之间的网络带宽，测试不同带宽之间的 TTFT 和 Throughput 时：

模型的推理性能随网络带宽增加，这个现象在所有输入长度下都呈现正相关的趋势， Throughput 有 9%~29% 的增加。

图 5：不同带宽的 Mean TTFT 比较

图 6：不同带宽的 Total Token Throughput 比较

图 7：高带宽相较于低带宽的 Throughput 的提升

04 总结

通过一系列针对 LMCache 的基准测试，系统验证了 KV Cache 的性能收益及其在不同存储后端、带宽和网络拓扑下的表现差异。整体来看，启用 KV Cache 后系统的推理性能得到显著提升，尤其在中等长度上下文（约 10K tokens）场景下，TTFT 明显下降，吞吐量最高可达近 24 倍提升。

CPU offloading 在用户数不多或者上下文短的场景下，作为 L2 缓存，带来极高的 offload 性能，这也是受益于 RAM 的高读写性能和带宽。但是 RAM 的大小终究有限，在并发量和上下文变长的情况下，RAM 的用尽是必然的情况。这时候高性能网络存储作为 L3 缓存，是平衡成本和性能的最佳选择，在本试验中，最多有 12 倍的推理性能提升。

在不同后端读写模式的对比中，GDS（GPUDirect Storage）表现最优，相较于Non-GDS模式，在 Throughput 上可提升 32.5%–96.6%。这说明在具备高带宽、低延迟访问路径的网络存储系统中，LMCache 能更充分发挥其异构缓存层的优势。

网络带宽对性能的影响也十分直接——除极短输入（100 tokens）外，带宽提升与系统吞吐量基本呈正相关，在大多数场景下可带来 9.1%–28.6% 的增益。

综上所述，LMCache 能够有效提升 LLM 的推理性能，其收益受存储介质带宽、访问拓扑及上下文特征等多因素影响。在实际部署中，充分利用层级缓存策略、高性能网络设备、网络存储带来的加成效应，实现性能与成本的最佳配比。

那么，如何系统的去学习大模型LLM？

作为一名深耕行业的资深大模型算法工程师，我经常会收到一些评论和私信，我是小白，学习大模型该从哪里入手呢？我自学没有方向怎么办？这个地方我不会啊。如果你也有类似的经历，一定要继续看下去！这些问题啊，也不是三言两语啊就能讲明白的。

所以我综合了大模型的所有知识点，给大家带来一套全网最全最细的大模型零基础教程。在做这套教程之前呢，我就曾放空大脑，以一个大模型小白的角度去重新解析它，采用基础知识和实战项目相结合的教学方式，历时3个月，终于完成了这样的课程，让你真正体会到什么是每一秒都在疯狂输出知识点。

由于篇幅有限，⚡️ 朋友们如果有需要全套 《2025全新制作的大模型全套资料》，扫码获取~

👉大模型学习指南+路线汇总👈

我们这套大模型资料呢，会从基础篇、进阶篇和项目实战篇等三大方面来讲解。

👉①.基础篇👈

基础篇里面包括了Python快速入门、AI开发环境搭建及提示词工程，带你学习大模型核心原理、prompt使用技巧、Transformer架构和预训练、SFT、RLHF等一些基础概念，用最易懂的方式带你入门大模型。

👉②.进阶篇👈

接下来是进阶篇，你将掌握RAG、Agent、Langchain、大模型微调和私有化部署，学习如何构建外挂知识库并和自己的企业相结合，学习如何使用langchain框架提高开发效率和代码质量、学习如何选择合适的基座模型并进行数据集的收集预处理以及具体的模型微调等等。

👉③.实战篇👈

实战篇会手把手带着大家练习企业级的落地项目（已脱敏），比如RAG医疗问答系统、Agent智能电商客服系统、数字人项目实战、教育行业智能助教等等，从而帮助大家更好的应对大模型时代的挑战。

👉④.福利篇👈

最后呢，会给大家一个小福利，课程视频中的所有素材，有搭建AI开发环境资料包，还有学习计划表，几十上百G素材、电子书和课件等等，只要你能想到的素材，我这里几乎都有。我已经全部上传到CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

相信我，这套大模型系统教程将会是全网最齐全 最易懂的小白专用课！！