实测！大模型推理性能暴增近 24 倍

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

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

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 的服务器与测试环境，联想凌拓提供高性能存储服务器，共同为测试落地提供坚实支撑。

详情请见后文：

测试设置

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

测试环境

超擎 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 算力调度平台。

模型部署

模型 Deepseek-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/v1
kind: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

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=False
LMCACHE_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 的元数据不同步的问题。

压测

• 使用 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

测试步骤和结果

测试目标

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

• 验证开启 KV Cache 后所带来的性能提升

• 测试不同的存储 IO 模式带来的性能提升的变化

• 测试不同网络带宽（相同的存储 IO 模式条件下）下带来的性能提升

测试步骤

• 测试主要集中在 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 轮的结果作为平均值；

指标选择

• TTFT（首 Token 响应时长）：TTFT 是本次测试关注的主要指标。通过复用 KV Cache 消除了 Prefill 阶段重新计算的时长，使得首 Token 的时间极大降低；

• Total token throughput（总体的 token 吞吐量）：伴随着首 Token 的响应时长的降低，系统的吞吐量会上升

测试结果

不同存储后端的比较

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 的推理性能，其收益受存储介质带宽、访问拓扑及上下文特征等多因素影响。在实际部署中，充分利用层级缓存策略、高性能网络设备、网络存储带来的加成效应，实现性能与成本的最佳配比。

 本文作者 

DaoCloud AI 基础设施平台技术专家