文档(金鹏): 2026-08-06 章节 48 篇文章摘要归档
- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
This commit is contained in:
@@ -0,0 +1,224 @@
|
||||
# 如何使用 NVIDIA Dynamo 减少 KV 缓存瓶颈
|
||||
|
||||
> **来源**：NVIDIA 技术博客
|
||||
> **作者**：未知
|
||||
> **发布日期**：2025-09-18
|
||||
> **原文链接**：https://developer.nvidia.cn/blog/how-to-reduce-kv-cache-bottlenecks-with-nvidia-dynamo/
|
||||
|
||||
---
|
||||
|
||||
随着 AI 模型变得更大、更复杂，推理，即模型生成响应的过程，正成为一项重大挑战。像 GPT-OSS 和 DeepSeek-R1 这样的大语言模型（LLM）严重依赖注意力数据（KV 缓存）来理解输入提示并进行上下文化，但高效管理这些数据正变得愈发困难。
|
||||
|
||||
本文将探讨如何在推理过程中将 KV 缓存卸载至成本效益更高的存储中，从而降低推理成本并提升用户体验。同时，本文还将阐述 NVIDIA Dynamo 的最新优化如何实现这一目标。
|
||||
|
||||
## 什么是 KV 缓存？
|
||||
|
||||
KV 缓存是在推理初始阶段创建的 LLM 注意力机制的核心数据结构，该阶段称为预填充。KV 缓存用于存储中间注意力数据，有助于模型在生成或响应阶段聚焦于输入中最为相关的部分。
|
||||
|
||||
然而，KV 缓存会随着提示长度呈线性增长，并且在生成过程中必须驻留在 GPU 显存中以实现快速访问。随着模型上下文窗口的不断扩展，有时甚至达到数百万个 token，KV 缓存便成为了一个严重的瓶颈。
|
||||
|
||||
## 为什么 KV 缓存是 LLM 推理的瓶颈？
|
||||
|
||||
GPU 显存有限且成本高昂。随着提示长度的增加，KV 缓存也会不断增大，在生成过程中需要占用更多内存。在多轮对话、深入研究和代码生成等应用场景中，KV 缓存必须在内存中长时间保留。当接近或达到 GPU 显存限制时，推理系统将面临权衡。他们可以：
|
||||
|
||||
- 删除 KV 缓存的部分内容，这会导致昂贵的重新计算
|
||||
- 限制提示词长度或上下文窗口，降低模型性能
|
||||
- 增加更多 GPU，增加运营成本
|
||||
|
||||
在 GPU 显存中长时间保留大量 KV cache 是不可扩展的，这迫使提供商在成本、延迟和功能之间进行权衡。
|
||||
|
||||
## Dynamo 如何帮助减少 KV 缓存瓶颈？
|
||||
|
||||
Dynamo 的最新版本支持 KV Cache 卸载功能，可将原本存储在有限 GPU 显存中的 KV Cache 实时传输至成本更低、容量更大的存储介质。该技术能够将 KV 缓存直接从 GPU 显存卸载到更具扩展性且经济高效的存储系统中，例如 CPU 内存、本地 SSD 或远程网络存储。借助 NVIDIA NIXL 这一低延迟传输库，Dynamo 能够在 GPU 显存与外部存储之间高效移动 KV 缓存块，整个过程无需中断模型推理，从而提升整体推理效率与资源利用率。
|
||||
|
||||
|
||||
|
||||
**图 1。KV 缓存卸载支持将 KV 缓存从有限的 GPU 显存即时传输到更经济高效的存储**
|
||||
|
||||
## KV 缓存卸载有哪些好处？
|
||||
|
||||
借助 KV 缓存卸载，推理服务提供商能够在不牺牲提示长度的前提下支持具有更长上下文窗口的模型。通过卸载 KV 缓存，可显著降低 GPU 显存占用，使集群能够同时处理更多用户请求，从而提升整体并发能力。这种方式减少了对额外 GPU 的需求，有助于降低基础设施成本。对于包含缓存输入 token 的提示，节省的成本可转化为折扣，惠及最终用户。
|
||||
|
||||
KV 缓存卸载还能避免昂贵的 KV 缓存重新计算，从而缩短响应时间并提升用户体验。最终，服务提供商将受益于更高的吞吐量和更低的单位 token 成本，进而增强推理服务的可扩展性与效率。
|
||||
|
||||
## 何时卸载 KV 缓存以重复使用
|
||||
|
||||
当 KV 缓存超出 GPU 显存，且缓存重用带来的收益超过数据传输开销时，将 KV 缓存卸载至 CPU 或外部存储将显著提升效率。这一策略在处理长上下文、高并发或资源受限的推理场景中尤为重要，例如：
|
||||
|
||||
- **长会话和多回合对话**：卸载可保留较大的提示词前缀，避免重新计算，并提高首个令牌延迟和吞吐量。
|
||||
- **高并发性**：空闲或部分对话可以移出 GPU 显存，允许活动请求在不达到内存限制的情况下继续进行。
|
||||
- **共享或重复内容**：跨用户或会话（例如系统提示和模板）重复使用会增加缓存点击率，尤其是在远程或跨实例共享时。
|
||||
- **受内存或成本限制的部署**：卸载到 RAM 或 SSD 可减少 GPU 需求，从而在不添加硬件的情况下允许更长的提示词或更多的用户。
|
||||
- **I/O 优化平台**：具有高主机设备带宽（例如 NVLINK C2C）或 GPU Direct Storage 的环境受益更多，因为传输延迟更低，并且可能与计算重叠。
|
||||
|
||||
## Dynamo 中的 KV 缓存卸载工作原理是什么？
|
||||
|
||||
Dynamo KV 块管理器（KVBM）是一个为缓存卸载和内存协调提供支持的系统，由三个主要层级构成：
|
||||
|
||||
- **模型集成层**：将 NVIDIA TensorRT-LLM 和 vLLM 等热门 AI 推理引擎（即将支持 SGLang）连接到 KVBM 系统。这消除了对特定模型集成的需求，并实现了跨不同引擎的一致功能。
|
||||
- **内存管理层**：处理内存的分配、组织和重用方式。它可以跟踪数据的所在位置，并使开发者能够在不影响整个系统的情况下自定义 KV 缓存卸载策略。
|
||||
- **使用 NIXL 的存储和数据传输层**：将 KVBM 连接到各种类型的存储，包括 CPU、SSD、文件系统和云平台。NIXL 支持跨机器的快速数据传输，并通过基于插件的系统简化了第三方存储提供商的集成。
|
||||
|
||||
|
||||
|
||||
**图 2。Dynamo KV 区块管理器与 LLM 推理生态系统的不同组件交互**
|
||||
|
||||
通过将内存管理与特定模型引擎分离，并标准化存储访问，KVBM 简化了集成与可扩展性。存储提供商不再需要为不同的推理引擎定制系统，因为 KVBM 负责处理翻译工作。该架构有助于提升性能、简化开发流程，并支持存储与计算的独立演进。
|
||||
|
||||
## Dynamo 如何与 LMCache 集成？
|
||||
|
||||
Dynamo 的核心设计原则是开放性，允许用户在内置功能与第三方集成之间自由选择。为此，Dynamo 集成了 LMCache，一个开源系统，用于在 CPU、本地及远程存储中缓存和重用 token。
|
||||
|
||||
LMCache 为 vLLM 等推理引擎提供 KV 缓存层。它能够将频繁使用的数据（例如对话历史记录或提示）从 GPU 卸载至成本更低的存储中，并针对大规模或重复性工作负载提供智能的驱逐与检索策略。对于使用 vLLM 的团队，LMCache 提供了一个强大的 KV 缓存管理解决方案，与 Dynamo 开放架构保持一致。
|
||||
|
||||
## 存储提供商如何利用 KV 缓存卸载？
|
||||
|
||||
Vast 测试了 NVIDIA Dynamo 与 Vast AI OS 之间的高性能集成，以实现 GPU 和存储之间持久性 KV 缓存的高效移动。通过在 Dynamo 中启用 GPU Direct Storage (GDS) 插件，Vast 在单个 NVIDIA H100 GPU 上实现了 35 GB/秒的吞吐量，充分表明 GPU 资源得到充分利用，同时验证了存储系统不会成为性能瓶颈。
|
||||
|
||||
在另一项测试中，Vast 验证了在 NVIDIA DGX H100 系统上使用 vLLM 和 LMCache 复用持久性 KV 缓存的效果。运行 Qwen3-32B 模型处理 130K token 提示时，系统从 Vast 存储中加载了预先计算的 KV 缓存，而非重新计算，从而显著缩短了首个 token 的生成时间（TTFT）。
|
||||
|
||||
WEKA 在实验室测试中，结合使用 NVIDIA Dynamo 以及由 WEKA 开发并开源的自定义 NIXL 插件，对 GPU 与存储之间的高性能 KV 缓存传输进行了评估。测试结果表明，WEKA 的增强内存网格能够以接近显存的速度将 KV 缓存从 token 仓库流式传输至 GPU，从而缩短首次 token 生成时间（TTFT），并提升推理工作负载的整体 token 吞吐量。
|
||||
|
||||
测试使用配备 8 个 H100 GPU 的 DGX 系统执行。该设置在 8 个 GPU 上实现了高达 270 GB/秒的读取吞吐量，证明 WEKA 基于 RDMA 的零拷贝数据路径能够满足分解推理对 token 传输的需求，而不会成为瓶颈。
|
||||
|
||||
这些测试结果凸显了将 KV 缓存卸载到存储的潜力，可支持分布式环境中大上下文、高吞吐量的生成式 AI 工作负载。
|
||||
|
||||
## 如何使用 Dynamo KVBM 管理 KV 缓存
|
||||
|
||||
要使用 KVBM 管理 KV cache 并在 vLLM 中执行 KV 卸载，请按以下步骤操作：
|
||||
|
||||
```
|
||||
# start up etcd for KVBM leader/worker registration and discovery
|
||||
docker compose -f deploy/docker-compose.yml up -d
|
||||
|
||||
# build a container containing vllm and kvbm
|
||||
./container/build.sh --framework vllm --enable-kvbm
|
||||
|
||||
# launch the container
|
||||
./container/run.sh --framework vllm -it --mount-workspace --use-nixl-gds
|
||||
|
||||
# enable kv offloading to CPU memory
|
||||
# 4 means 4GB of CPU memory would be used
|
||||
export DYN_KVBM_CPU_CACHE_GB=4
|
||||
|
||||
# enable kv offloading to disk
|
||||
# 8 means 8GB of disk would be used
|
||||
export DYN_KVBM_DISK_CACHE_GB=8
|
||||
|
||||
# serve an example LLM model
|
||||
vllm serve --kv-transfer-config
|
||||
'{"kv_connector":"DynamoConnector","kv_role":"kv_both",
|
||||
"kv_connector_module_path": "dynamo.llm.vllm_integration.connector"}'
|
||||
deepseek-ai/DeepSeek-R1-Distill-Llama-8B
|
||||
|
||||
# make a call to LLM
|
||||
curl localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{
|
||||
"model": "deepseek-ai/DeepSeek-R1-Distill-Llama-8B",
|
||||
"messages": [
|
||||
{
|
||||
"role": "user",
|
||||
"content": "In the heart of Eldoria, an ancient land of boundless magic and mysterious creatures, ..."
|
||||
}
|
||||
],
|
||||
"stream":false,
|
||||
"max_tokens": 30
|
||||
}'
|
||||
```
|
||||
|
||||
### 启用和查看 KVBM 指标
|
||||
|
||||
要通过 Grafana 控制面板启用指标收集和查看，请按照以下步骤操作：
|
||||
|
||||
```
|
||||
# Start the basic services (etcd & natsd), along with Prometheus and Grafana
|
||||
docker compose -f deploy/docker-compose.yml --profile metrics up -d
|
||||
|
||||
# start vllm with DYN_SYSTEM_ENABLED set to true and DYN_SYSTEM_PORT port to 6880.
|
||||
# NOTE: Make sure port 6880 (for KVBM worker metrics) and port 6881
|
||||
(for KVBM leader metrics) are available.
|
||||
DYN_SYSTEM_ENABLED=true DYN_SYSTEM_PORT=6880 vllm serve --kv-transfer-config
|
||||
'{"kv_connector":"DynamoConnector","kv_role":"kv_both",
|
||||
"kv_connector_module_path":
|
||||
"dynamo.llm.vllm_integration.connector"}'
|
||||
deepseek-ai/DeepSeek-R1-Distill-Llama-8B
|
||||
|
||||
# optional if firewall blocks KVBM metrics ports to send prometheus metrics
|
||||
sudo ufw allow 6880/tcp
|
||||
sudo ufw allow 6881/tcp
|
||||
```
|
||||
|
||||
通过 `http://localhost:3001` 查看 Grafana 指标（默认登录名：dynamo/dynamo），并查找 KVBM 控制面板。
|
||||
|
||||
### 基准 KVBM
|
||||
|
||||
当 vLLM 服务器准备就绪后，请按照以下步骤使用 LMBenchmark 对 KVBM 性能进行基准测试：
|
||||
|
||||
```
|
||||
git clone https://github.com/LMCache/LMBenchmark.git
|
||||
|
||||
# show case of running the synthetic multi-turn chat dataset.
|
||||
# we are passing model, endpoint, output file prefix and qps to the sh script.
|
||||
cd LMBenchmark/synthetic-multi-round-qa
|
||||
./long_input_short_output_run.sh \
|
||||
"deepseek-ai/DeepSeek-R1-Distill-Llama-8B" \
|
||||
"http://localhost:8000" \
|
||||
"benchmark_kvbm" \
|
||||
1
|
||||
|
||||
# Average TTFT and other perf numbers would be in the output from above cmd
|
||||
```
|
||||
|
||||
如需详细了解 LMBenchmark 的使用方法，请访问 LMCache/LMBenchmark GitHub 库。
|
||||
|
||||
请注意，如果如上一部分所述启用了指标，您可以在 Grafana 控制面板中观察 KV 卸载和 KV 载入情况。
|
||||
|
||||
为便于比较，您可以运行 `vllm serve deepseek-ai/DeepSeek-R1-Distill-Llama-8B` 来关闭 KVBM，以此作为基准。
|
||||
|
||||
## 如何使用 LMCache 和 vLLM 开始使用 Dynamo
|
||||
|
||||
通过设置环境变量来启用 LMCache：
|
||||
|
||||
- `export ENABLE_LMCACHE=1`
|
||||
|
||||
您可以通过环境变量来自定义 LMCache 的其他配置。
|
||||
|
||||
- `LMCACHE_CHUNK_SIZE=256` – 缓存粒度的令牌块大小（默认值：256）
|
||||
- `LMCACHE_LOCAL_CPU=True` – 启用基于 CPU 内存的后端进行卸载
|
||||
- `LMCACHE_MAX_LOCAL_CPU_SIZE=20` – CPU 显存限制（以 GB 为单位）（用户可根据可用内存将其设置为固定值）
|
||||
|
||||
对于高级配置，LMCache 支持多种存储后端：
|
||||
|
||||
- **CPU RAM**：快速本地内存卸载
|
||||
- **本地存储**：基于磁盘的持久性
|
||||
- **Redis**：分布式缓存共享
|
||||
- **GDS 后端**：用于高吞吐量的 GPU Direct Storage
|
||||
- **InfiniStore/Mooncake**：云原生存储解决方案
|
||||
|
||||
要开始使用 LMCache 和 vLLM 配合 Dynamo，请执行以下步骤：
|
||||
|
||||
```
|
||||
# start up etcd for KVBM leader/worker registration and discovery
|
||||
docker compose -f deploy/docker-compose.yml up -d
|
||||
|
||||
# build a container containing vllm and kvbm
|
||||
./container/build.sh --framework vllm
|
||||
|
||||
# launch the container
|
||||
./container/run.sh --framework vllm -it --mount-workspace
|
||||
|
||||
# run vllm with lmcache in aggregated inference
|
||||
./components/backends/vllm/launch/agg_lmcache.sh
|
||||
|
||||
# run vllm with lmcache in disaggregated inference
|
||||
./components/backends/vllm/launch/disagg_lmcache.sh
|
||||
```
|
||||
|
||||
请注意，必要的环境变量已包含在 `.sh` 脚本中，便于快速配置。请根据需要进行更新。
|
||||
|
||||
## 总结
|
||||
|
||||
随着大语言模型（LLM）的不断扩展，由于 GPU 显存有限且成本高昂，推理过程中管理 KV 缓存已成为一项重大挑战。NVIDIA Dynamo 通过支持将 KV 缓存卸载至 CPU 内存、SSD 和网络存储等更具可扩展性的存储选项，有效应对这一难题，该功能由低延迟的 NIXL 传输库提供支持。
|
||||
|
||||
Dynamo 与 vLLM 等热门推理引擎以及 LMCache 等开源工具无缝集成，可实现高效的缓存重用、减少重复计算，并更好地支持长上下文和高并发工作负载。Vast 和 WEKA 等存储提供商已成功集成 Dynamo，展示了高吞吐量存储系统如何在不成为瓶颈的前提下，高效地卸载和流式传输 KV 缓存。
|
||||
|
||||
这些功能使 KV Cache 卸载成为一种实用且可扩展的解决方案，能够降低推理成本、提升响应速度，并支持大规模生成式 AI 应用的更广泛部署。了解详情并开始使用 Dynamo。
|
||||
@@ -0,0 +1,78 @@
|
||||
# 📊 文章摘要：如何使用 NVIDIA Dynamo 减少 KV 缓存瓶颈
|
||||
|
||||
> **原文**：[2025-09-18_如何使用_NVIDIA_Dynamo_减少_KV_缓存瓶颈.md](./2025-09-18_如何使用_NVIDIA_Dynamo_减少_KV_缓存瓶颈.md)
|
||||
> **原文链接**：https://developer.nvidia.cn/blog/how-to-reduce-kv-cache-bottlenecks-with-nvidia-dynamo/
|
||||
> **来源**：NVIDIA 技术博客
|
||||
> **作者**：未知
|
||||
> **发布日期**：2025-09-18
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **缓存外移** — 将 KV 缓存从昂贵有限的 GPU 显存卸载至 CPU 内存、SSD 与网络存储，以存储成本换取 GPU 算力与并发能力。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文介绍 NVIDIA Dynamo 的 KV 缓存卸载能力：KV 缓存随提示长度线性增长且须驻留显存，在长上下文与高并发下成为推理瓶颈，迫使服务商在成本、延迟、功能之间权衡。Dynamo 通过 KV 块管理器（KVBM）的"模型集成层-内存管理层-NIXL 存储传输层"三层架构，将缓存实时卸载至 CPU、SSD 或远程存储，避免重新计算、提升并发、降低成本。文章给出卸载的适用条件（缓存重用收益超过传输开销）、与 LMCache 的集成方式、可复现的 vLLM 操作步骤，以及 Vast（单 H100 达 35GB/s）与 WEKA（8×H100 达 270GB/s）的实测数据。局限在于实测均出自存储厂商自报，缺少端到端成本收益量化。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **KV 缓存是显存瓶颈** — 随提示长度线性增长且必须驻留 HBM，长上下文下迫使在删缓存重算、限制上下文、增加 GPU 之间权衡 `[分类: 共识]`
|
||||
2. **KVBM 三层架构** — 模型集成层（TensorRT-LLM/vLLM，SGLang 即将支持）解耦引擎差异；内存管理层可自定义卸载策略；NIXL 传输层统一接入 CPU/SSD/文件系统/云存储 `[分类: 共识]`
|
||||
3. **NIXL 低延迟传输** — 支持跨机器快速传输与基于插件的第三方存储接入，卸载过程不中断模型推理 `[分类: 共识]`
|
||||
4. **卸载适用条件** — 仅当缓存重用收益超过传输开销时合算，典型场景：长会话、高并发、共享前缀、受内存/成本限制的部署、具备 GDS/NVLink C2C 的高带宽环境 `[分类: 共识]`
|
||||
5. **开放生态集成** — 集成开源 LMCache 为 vLLM 提供缓存层，支持 CPU RAM、本地存储、Redis、GDS、InfiniStore/Mooncake 等后端 `[分类: 共识]`
|
||||
6. **第三方实测数据** — Vast 在单 H100 上经 GDS 插件达 35GB/s；WEKA 在 8×H100 DGX 上达 270GB/s 读取，Qwen3-32B 处理 130K token 提示时复用预计算缓存显著缩短 TTFT `[分类: 争议]`（数据来自存储厂商自测）
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设 GPU 与存储之间具备足够带宽（GDS、RDMA 或 NVLink C2C），且传输延迟可被计算重叠掩盖；假设工作负载的缓存重用率足够高，使卸载收益超过开销。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
Vast 与 WEKA 的测试聚焦"传输带宽"而非端到端经济性，论证了存储系统不是瓶颈，但未直接证明"降低推理成本"；文章缺乏卸载前后 TTFT、吞吐与总拥有成本的对照数据，结论部分依赖推断而非证据。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
对无 GDS、NVLink C2C 等高速互连的普通环境，传输开销可能吞噬卸载收益，文中未给出量化判断标准；缓存一致性、多机同步、KV 块生命周期管理未展开；教程面向 vLLM，SGLang 等其他引擎支持尚不完整。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "在 GPU 显存中长时间保留大量 KV cache 是不可扩展的，这迫使提供商在成本、延迟和功能之间进行权衡。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- KVBM 三层架构清晰，存储与推理引擎解耦的设计思路有借鉴价值
|
||||
- 提供完整可复现的操作步骤与基准测试方法（LMBenchmark）
|
||||
- 明确给出"何时卸载"的边界条件，而非无条件的方案推销
|
||||
|
||||
**不足**：
|
||||
- 收益数据全部来自存储厂商自测，缺少独立第三方验证
|
||||
- 没有端到端成本模型，无法直接用于投资回报评估
|
||||
- 分布式场景下的缓存一致性与故障处理着墨甚少
|
||||
|
||||
**适用场景**：推理系统架构师、SRE 与平台工程师评估长上下文/高并发推理优化方案；希望动手复现 KV 缓存卸载的工程团队。
|
||||
|
||||
**关联建议**：可进一步阅读月之暗面 Mooncake 论文（全局调度+分布式 KV 缓存池）、NVIDIA Dynamo 官方文档与 LMCache GitHub 仓库；对比信通院 2026 报告中的多级存储与 PD 分离章节可获更完整上下文。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
Reference in New Issue
Block a user