大模型推理上下文管理与切换机制：KV Cache、显存与调度实战

做了几年大模型推理服务的工作，我越来越觉得"上下文"这个词被用得太随意了。业务同学说上下文是聊天记录，算法同学说上下文是 KV Cache，运维同学说上下文是显存里的那一堆数据。同一个词，三种理解，等线上出问题的时候，谁也说不清模型执行上下文到底该管什么、该怎么切。

这篇文章我把"模型执行上下文管理与切换机制"这件事，从系统工程师的视角完整讲一遍。既包括执行上下文的组成拆解，也包括多用户、多模型场景下上下文切换的机制设计和落地经验。内容主要面向正在做大模型服务部署、推理加速、模型网关的同学，也适合打算把推理服务从"单路跑通"推到"多路稳定"的团队参考。全文不贴框架源码，只讲原理和实操决策，你拿回去对着自己的服务排查，一定能用上。

1. 先搞清楚：模型执行上下文到底由什么组成

1.1 业务上下文和执行上下文，是两个不同维度

刚开始做服务化的时候，我犯过一个典型错误：把对话历史、用户 session 数据当成唯一需要管理的"上下文"。后来线上出现了一个诡异问题：用户发同样的话，请求时好时坏，有的推理结果语义对不上，有的首 token 延迟明显变高。排了很久才发现，问题出在推理服务的运行时状态上——同一份业务对话，落到不同的执行上下文里，表现完全不同。

所谓"模型执行上下文"，从系统的角度看，至少包含四层信息：

• 模型权重与计算图状态：已经加载的权重、算子图、算子编译缓存、CUDA kernel 的编译产物等；
• KV Cache：自回归解码时保存的中间 Key/Value 张量，这是大模型推理里最占资源、最影响切换成本的一层；
• 运行时资源状态：显存分配器状态、GPU stream 状态、CUDA context、TensorRT engine 的 profile、CUDA graph 捕获结果等；
• 业务会话状态：prompt 历史、采样参数、多轮截断策略、工具调用记录等。

业务上下文只是最上面那一层。真正影响性能、稳定性和响应速度的，是下面那三层。我在做推理网关调度时最深的体会是：如果你只按"业务会话"维度管理上下文，那你在资源维度上的切换开销几乎不可控。

提示：排查上下文类问题时，建议先区分"业务上下文错误"和"执行上下文错误"。前者表现为生成内容答非所问、记忆混乱；后者表现为性能劣化、CUDA 报错、显存异常。两类问题修起来完全是两条路。

1.2 KV Cache 才是切换成本的大头

很多人不理解为什么上下文切换这么贵，觉得无非是把对话历史再拼一遍。问题就出在 KV Cache 上。

自回归模型生成每个 token 时，都需要把当前 token 与之前所有 token 的关系算一遍。如果不缓存，每次生成都得重新处理整个输入序列，显存省了但计算量翻了几倍。所以主流推理框架都会把历史 token 经过 Attention 计算后的 Key 和 Value 向量缓存下来，这就是 KV Cache。

KV Cache 的占用有多大？可以算一笔账。假设一个 7B 参数的模型，32 层 Transformer，32 个 attention head，每个 head 的维度是 128，KV Cache 用 FP16 存储。那么每增加一个 token，缓存大小大约是：

2（K 和 V 两组）× 32（层数）× 32（head 数）× 128（head 维度）× 2 字节（FP16）= 512KB

也就是说，一个用户多轮对话累积到 2048 token，光 KV Cache 就要吃掉约 1GB 显存。如果服务里同时挂着 16 路这样的会话，光缓存就要 16GB。这个数据一摆出来，你就明白为什么上下文管理的第一优先级不是"存对话记录"，而是"管理 KV Cache 的存储、换入和换出"。

权重和计算图是"静态上下文"，整个服务启动时加载一次，切换模型才动它。KV Cache 是"动态上下文"，每个请求、每轮对话都在变，真正需要频繁切换的其实就是它。

2. 哪些场景逼着你做上下文切换

2.1