弹性、故障与跨集群

部署维度之四：副本扩缩容、抢占、故障恢复、跨集群部署在 KV 视角下的额外问题。

1. 冷启动与"热身"

新副本上线时 KV 池是空的，命中率为 0。在亲和性强的负载下，新副本拉低整体命中率：

策略	思路
预热（Pre-warming）	启动后从 L4 KV 池或对等副本拉取热门 prefix
Gradual ramp-up	路由层逐步把流量给新副本，避免冷启动期的高 TTFT
Sticky migration	老副本的部分会话主动迁移到新副本，带 KV 一起搬

工业实践里完整 pre-warming 较少，更常见的是接受短暂的命中率下降，靠路由层的 cache-aware 逐步建立缓存。

2. 缩容与 KV 处置

被踢的副本上的 KV 怎么处理：

选项	适用场景
直接丢弃	流量回退场景，重新计算成本可接受
迁移到对等副本	需要保留亲和性，副本间通过 RDMA / 网络传输
下沉到 L3/L4	长会话 / 高价值前缀，下次有副本上线时召回

迁移路径上要处理：

• 进行中的 Sequence——drain 完成或 checkpoint 后迁移
• prefix cache 的去重——避免迁移到已有相同前缀的副本

3. 抢占（Preemption）

KV 容量不足时，调度器必须从现有 Sequence 中"抢"一些资源：

策略	描述	代价
Swap	把目标 Sequence 的 KV 换到 CPU DRAM	swap-in 延迟（μs–ms）
Recompute	丢掉 KV，下次重新 prefill	prefill 延迟（s 级）
Drop	直接退请求（用户体验最差）	用户可见失败

抢占的对象选择规则：

• 优先级（按 SLA / tenant 配额）
• 进度（已生成更多 token 的 Sequence 重算成本更高，倾向不动）
• 历史活跃度（短时间未活跃的 Sequence 优先 swap）

详细机制见 KV Offload 和 运行时架构。

4. 故障恢复

KV 是否需要持久化？取决于业务对会话恢复的要求：

场景	是否持久化 KV
无状态 API	否，重做 prefill 即可
长会话 Chat	视 SLA 而定，多数仍重算
长 Reasoning 推理	是，已生成的 decode 不可丢
离线批处理	是，便于断点续算

主流做法：把 KV 视为可重建的缓存——故障恢复就是重新 prefill，不专门做 KV checkpoint。少数对 reasoning 长 decode 友好的系统会做轻量持久化。

引擎进程崩溃

副本进程崩溃 → 该副本上所有 KV 丢失 → 路由器把流量切到其他副本 → 用户感知为短暂的 TTFT 抬升。

GPU 故障

GPU 卡故障是更严重的事件：

• 模型权重需要从其他卡或盘上加载
• KV 直接全失
• 通常处理为副本下线 + 替换

5. 抢占 vs 弹性扩容的边界

什么时候抢占、什么时候扩容，是个调度决策：

• 短突发：抢占 + swap，等待流量自然回落
• 持续过载：触发扩容，新副本上线分担流量
• 可预测峰值：定时预扩容（如商业场景的早高峰）

KVCache 视角的复杂性在于：扩容的副本要时间"热身"，所以扩容决策不能等到完全过载——要预测性扩容。

6. 跨集群 / 多区域

用户会话的局部性

• 用户通常稳定连接到最近的区域
• 长会话的 KV 自然落在该区域，跨区域迁移很少发生

灾备与多活

• 主备：备区域不维护 KV cache，用户切换时全部 cache miss → 重做 prefill
• 多活：多区域同步 prefix cache（成本高，仅对热门 prefix 做）

全球前缀缓存

理想中：跨区域的统一 KV 池。 现实中：基本不做——跨区域延迟（几十 ms）+ 带宽成本远高于"本地重算"成本，得不偿失。

7. 与 SLO 的耦合

KV 弹性策略与系统 SLO 直接相关：

SLO	影响弹性策略
TTFT 严格	不能容忍 swap-in 延迟 → 倾向直接 drop / 扩容
TPOT 严格	不能容忍抢占 → 倾向多副本
吞吐第一（离线）	大量 offload + recompute 都可以
成本第一	让 KV 占满，接受偶发抢占

不同 SLO 对应不同弹性配置，没有"一套通用最优策略"。

关联章节

• 抢占的具体机制：运行时架构 §Scheduler、KV Offload
• 路由层的扩缩容感知：路由与亲和性
• 与不同工作负载的契合度：工作负载维度、维度交叉 §3.3

版本历史

版本	日期	说明
v0.1	2026-05-14	框架搭建