LLM 推理正在打破 20 年的无状态系统设计范式

如果有人告诉你，二十年来几乎没变的 Web 系统设计原则正在被 LLM 推理悄然颠覆，你可能会觉得言过其实。但在深入了解 KV Cache 的工作原理后，这种说法并不夸张。

无状态设计的黄金法则

自 HTTP 协议诞生以来，"无状态" 一直是 Web 系统的设计金科玉律。每个请求都应自包含，服务器不保留请求间的上下文，水平扩展只需增加节点，路由策略简单明了。负载均衡器可以在任意节点间轮转，会话亲和性只在必要时才开启。这种范式让分布式系统变得可预测、易推理。

然而，LLM 推理带来了根本性的变化。

KV Cache：被忽视的有状态之源

当你向大语言模型发送一段 prompt，模型并非每次都重新计算所有历史 token 的注意力状态。取而代之的是，推理系统会维护一个 KV Cache（Key-Value 缓存），存储过去 token 的键值投影。

这个缓存有多重要？以 Llama 2 7B 为例，一个 2048 token 的序列需要约 1 GiB 的 GPU 内存来存储 KV Cache。这不是小数目。而且缓存大小随序列长度线性增长，在多轮对话场景中，每一轮新的输入都会在已累积的 KV Cache 基础上继续增长。

关键问题在于：传统的 HTTP 请求设计根本不假设这种状态的存在。当你做负载均衡时，你不知道哪个 Pod 持有与当前请求相关的缓存上下文；当你做水平扩展时，你不知道新 Pod 的冷启动将带来多长的 Time To First Token（TTFT）。

上下文窗口：被低估的硬边界

LLM 并不是无限接受输入的。大多数模型的训练上下文窗口是一个硬约束，例如 Llama 3 的 8192 token。当 KV Cache 接近或超过这个阈值时，生成质量会急剧下降 —— 不是因为 GPU 内存耗尽，而是因为位置编码（RoPE）在超出训练范围后会产生不可预测的旋转角度。

研究表明，当 KV Cache 累积超过 8800 token 时，模型开始出现明显的失败模式，比如逐字重复用户的 prompt；超过 15000 token 时，输出退化成为混乱的重复字符序列。这种退化与内存容量无关，纯粹是模型处理超长序列时位置编码失效的表征。

有状态路由：架构的根本性转变

传统的负载均衡采用轮询或简单的会话亲和。但 LLM 推理需要 "KV Cache 感知的路由"。llm-d 项目（由 IBM、Google、Red Hat 等推动的开源框架）展示了这一思路的实际效果：通过智能路由将请求导向已经持有相关缓存内容的 Pod，Cache Hit Rate 达到 87.4%，TTFT 从 2850ms 降至 340ms，性能提升 88%。

实现这一目标需要几个关键组件：EPP（External Processing Pod）作为智能调度器，在内存中维护全局 KV Cache 块位置索引；PrefixStore 缓存 tokenized prompt 前缀，避免重复的分词开销；基于最长连续前缀匹配的评分算法，优先选择缓存最热的 Pod。

这不是简单的配置变更，而是整个请求路由逻辑的重构。

缓存逐出：比想象中更复杂

当 KV Cache 超过容量限制时，需要逐出部分 token 状态。但研究揭示了一个反直觉的事实：即使是 99% 保留率的 AttentionTop 策略，在已接近上下文窗口极限的长序列上，也会导致严重的生成质量下降。

原因在于位置编码的完整性被破坏。KV Cache 中的每个 token 都携带着原始的位置信息（RoPE 编码），当我们删除非连续的 token 并重新压缩缓存时，模型面对的是一个位置信息被 "打乱" 的序列 —— 相邻的状态可能拥有相差甚远的原始位置索引。这会导致注意力机制产生混乱的依赖关系，最终输出退化。

相比之下，简单保留开头 2000 token 的 Gist 策略，在基线策略已失效的场景下仍能产生连贯、相关且有帮助的回复。这印证了一个关键原则：位置连续性比内容重要性更重要。

工程实践清单

将上述原理落地到生产环境，需要关注以下几个维度：

路由层：引入 KV Cache 感知的调度器，维护缓存块位置索引，支持基于前缀相似度的 Pod 评分。确保缓存命中的请求路由至持有相关状态的节点，冷启动请求可分散至空闲 Pod。

缓存层：配置 prefix caching 参数（如 vLLM 的 --enable-prefix-caching、--block-size=16），在多请求共享 prompt 前缀的场景下显著提升复用率。监控 cache hit rate，目标应超过 80%。

内存层：设定合理的 gpu-memory-utilization 阈值（如 0.7），为 KV Cache 预留足够空间。根据模型参数量级调整 max-model-len，避免上下文窗口超出导致的隐式退化。

逐出策略：优先采用保留位置连续性的策略（如固定窗口或 Gist），而非依赖注意力分数的复杂逐出。监控有效上下文长度，确保其始终低于模型的上下文窗口限制。

可观测性：部署 Grafana 仪表盘，追踪 cache hit rate、TTFT 分布、Pod 间流量分布、GPU 内存利用率等关键指标。异常值（如 cache hit rate 骤降）通常预示着缓存碎片化或逐出策略失效。

小结

LLM 推理对系统设计的挑战，远不止 "GPU 够不够" 这么简单。KV Cache 的有状态本质、上下文窗口的硬约束、位置编码的完整性要求，共同构成了对二十年无状态设计范式的根本性挑战。

将 LLM 推理系统视为有状态的、需要专门路由与调度的基础设施，而非简单的无状态 API，是工程团队需要完成的心智模型转换。这个转换没有银弹，但通过 KV Cache 感知路由、智能逐出策略与完善的监控体系，可以在这片新水域中构建出高效、可预测的服务。

资料来源：arXiv 2511.04686《Stateful KV Cache Management for LLMs》；Red Hat Developer《Master KV cache aware routing with llm-d》。

systems