生产服务栈:KV 卸载与缓存感知路由

生产服务栈:KV 卸载与缓存感知路由

本节摘要:一个生产服务栈把路由器、引擎、可观测性接成一个 Kubernetes 部署——并把 KV 缓存当作可以离开 GPU 的资源。KV 卸载把 KV 缓存从 GPU 内存里抽出来,在查询与引擎间复用(CPU DRAM,再到磁盘/Ceph)。vLLM 的 production-stack 是参考部署;LMCache 是卸载层。vLLM 0.11.0 KV 卸载连接器(2026 年 1 月)经连接器 API(v0.9.0+)把它做成异步、可插拔。卸载路径通常对请求路径隐藏,但缓存未命中与提升会加端到端延迟。LMCache 即便没有共享前缀也有价值——当 GPU KV 槽用尽时,被抢占的请求可从 CPU 恢复,而非重算 prefill。已发表基准在 16× H100(80GB HBM)、跨 4 个 a3-highgpu-4g 上:当 KV 缓存超过 HBM 时,原生 CPU 卸载与 LMCache 都大幅提升吞吐;低 KV 占用时,所有配置接近基线、仅小开销。

对应原课程:Phase 17 · Lesson 18 · 18-vllm-production-stack-lmcache(原英文 phases/17-infrastructure-and-production/18-vllm-production-stack-lmcache/docs/en.md)。

学习目标

阅读完本节,你应当能够:

1. 画出 vLLM production-stack 的各层:路由器、引擎、KV 卸载、可观测性。
2. 解释 KV 卸载连接器 API(v0.9.0+)以及 0.11.0 异步路径如何隐藏卸载延迟。
3. 量化 LMCache 的 CPU-DRAM 何时帮(KV > HBM)vs 何时加开销(KV 小到装得下 HBM)。
4. 给定部署约束,在原生 vLLM CPU 卸载与 LMCache 连接器之间选型。

一、问题与直觉

你的 vLLM 服务显示 GPU 100% HBM 占用,并发一升就出抢占事件。请求被驱逐、重排队,你一分钟内把同一个 2K token 提示重 prefill 四次。GPU 算力花在冗余 prefill 上;goodput 远低于裸吞吐。

加 GPU 是线性成本。加 HBM 不可能。但 CPU DRAM 便宜——一个插槽 512 GB+,延迟比 HBM 差几个数量级,但放「临时暖」的 KV 缓存没问题。

LMCache 把 KV 缓存抽到 CPU DRAM,让被抢占的请求快速恢复,并让跨引擎的重复前缀共享缓存而不必各引擎重 prefill。

二、核心概念

vLLM production-stack

github.com/vllm-project/production-stack 是参考 Kubernetes 部署:

• 路由器 —— 缓存感知(第 11 节),消费 KV 事件。
• 引擎 —— vLLM worker,每 GPU 或每 TP/PP 组一个。
• KV 缓存卸载 —— LMCache 部署或原生连接器。
• 可观测性 —— Prometheus 抓取、Grafana 仪表盘、OTel trace。
• 控制面 —— 服务发现、配置、滚动更新。

以 Helm chart + operator 发布。

KV 卸载连接器 API(v0.9.0+)

vLLM 0.9.0 引入连接器 API,做可插拔 KV 缓存后端。你的引擎把 block 卸到连接器;连接器存它们(RAM、磁盘、对象存储、LMCache)。请求要某 block 时,连接器加载回来。

vLLM 0.11.0(2026 年 1 月)加异步卸载路径——卸载可在后台发生,使引擎在常见情况下不阻塞。端到端延迟与吞吐仍取决于工作负载形状、KV 缓存命中率与系统压力;vLLM 自家说明指出,自定义内核卸载在低命中率下会损吞吐,异步调度与投机解码有已知交互问题。

原生 CPU 卸载 vs LMCache

原生 vLLM CPU 卸载:引擎本地。把 KV block 存进主机 RAM。实现快、零网络跳。不跨引擎。

LMCache 连接器:集群规模。把 block 存进共享 LMCache 服务器(CPU DRAM + Ceph/S3 层)。任何引擎都能访问。已发 16× H100 基准。

单引擎有 HBM 压力选原生。多引擎共享前缀(RAG 共享系统提示、多租户共享模板)选 LMCache。

基准行为

16× H100(80 GB HBM)、跨 4 个 a3-highgpu-4g 测试:

• 低 KV 占用(短提示、低并发):所有配置接近基线,LMCache 加约 3~5% 开销。
• 中等占用:LMCache 在跨引擎前缀复用上开始帮忙。
• KV 超 HBM:原生 CPU 卸载与 LMCache 都大幅提升吞吐;LMCache 因跨引擎共享增益更大。

LMCache 何时是决定性的

• 多租户服务,系统提示跨租户共享。
• RAG,文档块跨查询重复。
• 同基座的微调变体(LoRA),基座模型 KV 复用砍冗余工作。
• 抢占重的工作负载:从 CPU 恢复比重 prefill 便宜。

何时不启用

• HBM 压力小——你付开销无收益。
• 短上下文(<1K token)——传输时间 > 重 prefill。
• 单租户单提示工作负载——无复用可捕获。

与分离式服务集成

第 17 节分离式服务 + LMCache 复合:从 prefill 池到 decode 池的 KV 传输,若未用就落进 LMCache;后续查询从 LMCache 拉。第 11 节缓存感知路由器可路由到本地或 LMCache 共享缓存匹配的引擎。

你该记住的数字

• vLLM 0.9.0:连接器 API 航运。
• vLLM 0.11.0(2026 年 1 月):异步卸载路径;端到端延迟影响依工作负载、KV 命中率、系统压力(非绝对保证)。
• 16× H100 基准:KV 占用超 HBM 时 LMCache 帮忙。
• 小 HBM 压力:无收益 3~5% 开销。

三、从零实现:KV 溢出模拟器

原课程 code/main.py 模拟带/不带 LMCache 的抢占重的工作负载,报告避免的重 prefill、吞吐增益、盈亏 HBM 利用率。下面给最小可读骨架。

def offload_benefit(hbm_capacity_gb, kv_per_request_gb, concurrency,
                    reuse_rate, re_prefill_cost_ms, cpu_restore_ms):
    """估算 KV 卸载的收益。

    参数:
      hbm_capacity_gb:    HBM 总容量 GB
      kv_per_request_gb:  单请求 KV GB
      concurrency:        并发请求数
      reuse_rate:         跨请求/引擎前缀复用率(0~1)
      re_prefill_cost_ms: 重 prefill 的 ms 成本
      cpu_restore_ms:     从 CPU 恢复的 ms 成本
    返回: (是否溢出 HBM, 每次抢占节省 ms, 每小时节省示例)
    """
    total_kv = kv_per_request_gb * concurrency
    spills = total_kv > hbm_capacity_gb
    save_per_preempt = re_prefill_cost_ms - cpu_restore_ms if spills else 0
    # 复用也省:复用请求跳过 prefill
    reuse_save = reuse_rate * re_prefill_cost_ms
    return spills, round(save_per_preempt, 1), round(reuse_save, 1)


# 案例:80GB HBM,每请求 0.4GB KV,200 并发,30% 复用
spills, save_pre, save_reuse = offload_benefit(80, 0.4, 200, 0.30, 600, 50)
print(f"溢出 HBM: {spills}, 每次抢占省 {save_pre}ms, 复用省 {save_reuse}ms")
​

💡 LMCache 不是「装上就快」。它的价值在两个场景:HBM 满了要抢占比恢复便宜,以及跨引擎/跨请求有共享前缀。两者都没有时,它只是 3~5% 开销。

四、框架对比:原生 CPU 卸载 vs LMCache 连接器

心法:单引擎抢占比重 → 原生;跨引擎复用 → LMCache。两者可叠加,但 LMCache 引入网络跳与单点,需 HA 设计。

五、可复用产物

本节产出 outputs/skill-vllm-stack-decider.md(原课程目录)。给定工作负载形状与 vLLM 部署,它在原生 / LMCache / 都不用间决定:

1. HBM 压力分析:KV 占用 vs HBM 容量,是否触发抢占。
2. 复用分析:跨请求/引擎的前缀复用率。
3. 方案推荐:原生(单引擎压力)/ LMCache(跨引擎复用)/ 都不用(低压力)。
4. HA 策略:LMCache 服务器的复制与回落到原生。

六、练习

1. 跑通模拟器:运行 code/main.py。在多高 HBM 利用率下 LMCache 开始划算?

2. 租户节省:某租户在 200 查询/小时上共享 6K token 系统提示。算每租户的 LMCache 预期节省。

3. HA 设计:LMCache 服务器是单点故障。设计 HA 策略(复制、回落到原生)。

4. 磁盘读时间:LMCache 存到转盘 Ceph。70B FP8 上 4K token KV(500 MB),读时间 vs 重 prefill 各多少?

5. 异步免费吗:论证 vLLM 0.11.0 异步路径是否「免费」——开销藏在哪?

本节要点回顾

1. 生产服务栈把路由+引擎+可观测+KV 卸载接成一套 K8s 部署:Helm chart + operator。
2. KV 卸载把 KV 当可离开 GPU 的资源:卸到 CPU DRAM 再到磁盘/Ceph。
3. 连接器 API(v0.9.0+)可插拔:0.11.0(2026-01)异步路径隐藏卸载延迟,但低命中率与投机解码有交互问题。
4. 原生 CPU 卸载是引擎本地:零网络跳,不跨引擎。
5. LMCache 是集群跨引擎:CPU DRAM + Ceph/S3 层,任何引擎可访问。
6. LMCache 在 KV 超 HBM 时决定性:抢占从 CPU 恢复比重 prefill 便宜。
7. 低压力时是开销:3~5% 开销无收益,短上下文传输税 > 重 prefill。
8. 与分离式 + 缓存路由复合:prefill→decode 的 KV 落 LMCache,缓存路由器路由到匹配引擎。
9. 16× H100 基准:KV 超 HBM 时原生与 LMCache 都大幅提升,LMCache 因跨引擎共享增益更大。

下一节,我们上一层抽象——AI 网关:看 LiteLLM、Portkey、Kong AI Gateway、Bifrost 如何把路由、限流、故障转移、计费归因、语义缓存统一在一个入口。