LLM 推理内核拆解KV Cache、Prefill 与 Decode 的优化逻辑一、部署大模型先搞懂推理在发生什么很多团队部署大模型时只关心两件事模型能不能跑起来、响应快不快。至于推理过程中到底发生了什么往往是一团迷雾。这种认知模糊带来的后果很实际模型跑起来了但吞吐上不去加显卡也提升有限参数调优全靠试错。要想真正理解 LLM 推理优化必须钻到推理的内部看清每一次生成 token 的旅程。本文从自回归生成机制讲起拆解 KV Cache 的显存逻辑、Prefill 与 Decode 两阶段的资源特征再引出 vLLM 等推理框架的核心优化思想。理解了这些底层机制你才能看懂所有优化技术到底在攻什么瓶颈。二、自回归一个 token 一个 token 地挤所有主流大模型都是自回归autoregressive的生成时模型每次只预测下一个 token把这个 token 拼到已有序列后面再预测下一个如此循环直到遇到结束符或达到长度上限。这个机制决定了两个基本事实。第一生成 N 个 token 需要 N 次前向计算延迟天然与输出长度线性相关。第二每次生成时模型需要重新看整个已生成序列——这就引出了 KV Cache 的存在意义。三、注意力机制与 KV Cache用显存换时间3.1 注意力在算什么Transformer 的注意力机制中每个 token 都会计算三个向量Query查询、Key键、Value值。计算第 t 个 token 的输出时用它的 Query 与前面所有 token 的 Key 做相似度计算决定看谁再用相似度加权 Value决定取多少信息。关键观察来了生成第 t 个 token 时前面所有 token 的 Key 和 Value 都已经算过了而且计算结果不会变。如果每次生成都重新计算一遍就是纯粹的浪费——这正是 KV Cache 出现的原因。3.2 KV Cache 的代价KV Cache 把每个已生成 token 的 Key 和 Value 缓存下来生成时直接复用。这极大地省去了重复计算但代价是显存。KV Cache 有多大以 7B 参数模型为例假设 32 层、40 个注意力头、头维度 128每个 token 的 KV Cache 需要 32 × 2 × 40 × 128 × 2 字节FP16≈ 1.3MB。看起来单 token 不大但注意这个数字是每个 token 都要占的而且长上下文和高并发会把它放大到恐怖的程度——一个 27B 模型在长序列、高并发下KV Cache 占用甚至可能超过权重本身。这就是推理优化的核心矛盾权重是固定成本KV Cache 是随并发和序列长度增长的动态成本。谁能把 KV Cache 管好谁就能在同样的硬件上服务更多用户。四、Prefill 与 Decode两个阶段、两种瓶颈4.1 两个阶段的资源特征一次推理过程可以拆成两个截然不同的阶段Prefill预填充处理用户输入。把整个输入序列一次性喂给模型并行计算所有位置的注意力生成首批 KV Cache。这个阶段的特点是计算密集、一次性完成、GPU 算力消耗大。Decode解码逐字生成回复。每次只生成一个 token复用已缓存的 KV。这个阶段的特点是内存密集、逐步进行、每次只算一个 tokenGPU 利用率天然偏低。4.2 为什么这个区分很重要因为两个阶段的资源需求相反Prefill 吃算力Decode 吃内存带宽。如果一张卡上同时跑多个请求Prefill 和 Decode 会互相竞争资源——Prefill 请求占满算力时Decode 请求的 token 生成就变慢KV Cache 占满显存时新请求连 Prefill 都排不进来。理解了这一点就理解了为什么很多优化技术连续批处理、Chunked Prefill、Prefill-Decode 分离都在围绕如何调和这两个阶段的资源冲突展开。五、传统推理框架的三大痛点在用优化框架之前先看清传统推理比如直接用 Hugging Face Transformers 跑的问题所在痛点一静态批处理。请求到达后按固定 batch 处理一个 batch 全部完成才接收新请求。请求长短不一短请求要干等长请求算完GPU 算力大量浪费在等上。痛点二KV Cache 预分配。为每个请求预先分配一整块连续显存分配多了浪费、少了扩容困难请求结束后释放的空间不连续新请求用不上——显存碎片化严重。痛点三显存预估难。模型要占多少显存、KV Cache 要占多少估算不准就只能在够用和浪费之间反复横跳。六、vLLM 的核心优化三个关键机制vLLM 之所以成为开源推理框架的主流选择是因为它针对上述痛点做了三个教科书级的优化。6.1 PagedAttention像操作系统一样管显存PagedAttention 是 vLLM 的核心灵感来自操作系统内存分页。它把 KV Cache 切成固定大小的 block块每个 block 可以存放在任意物理位置通过索引表把逻辑上的连续序列映射到物理上分散的块。这个设计的收益是双重的一是显存碎片问题大幅缓解——块可以动态分配和回收请求结束释放的块能立刻被其他请求复用显存利用率接近 100%二是按需分配——只有实际用到的块才占显存不预分配大块空间同一张卡能塞进更多请求。6.2 Continuous Batching让 GPU 永远别闲着传统静态批处理让 GPU 等最慢的请求连续批处理Continuous Batching则彻底改变思路请求不用等一个固定 batch 结束哪个请求生成完了就立即移出新请求立刻补进来。用一个餐厅类比传统批处理是一次只服务一桌客人上完一桌再接待下一桌连续批处理是后厨同时处理多桌订单哪个菜先熟就先出锅。这个机制对高并发在线服务的吞吐提升是数量级的也是 vLLM 脱颖而出的基础能力。6.3 Chunked Prefill拆开大请求填满小缝隙连续批处理解决了请求间的等待但还有一个内部矛盾一个超长的 Prefill 请求会独占 GPU 算力很久期间 Decode 请求只能干等。Chunked Prefill 的解法是把大 Prefill 请求切成多个小块交错执行——先算一块 Prefill再趁机生成几个 Decode token再算下一块。这样算力在 Prefill 和 Decode 之间持续流转GPU 利用率和整体吞吐显著提升。七、vLLM 之外的优化技术全景vLLM 解决了显存管理和批处理的基础问题但推理优化的版图远不止于此量化压缩把权重从 FP16 压到 INT8/INT4如 AWQ、GPTQ显存占用直接砍半甚至更多。精度损失可控是扩大并发规模的最直接手段。Speculative Decoding用一个小的草稿模型先猜多个 token大模型一次验证——猜对了就能一次生成多个 token延迟显著下降。它用小模型的便宜猜测换大模型的昂贵验证是延迟优化的利器。Prefix Caching多个请求共享相同的系统提示词或文档前缀时KV Cache 可以复用重复的 Prefill 计算直接省掉。多轮对话和 RAG 场景收益尤其明显。Prefill-Decode 分离部署把 Prefill 和 Decode 放到不同的 GPU 或不同的服务实例上分别优化——算力卡专注处理输入带宽卡专注生成 token。这是服务大型模型时的高级部署形态。多 GPU 并行张量并行把单层拆到多卡和流水线并行把层分段到多卡解决单卡放不下的问题。配合 KV Cache 的分布式管理可以服务更大模型、更大并发。八、从原理到实践的认知升级理解了上述机制再看推理框架的选型就有了清晰的判断标准看它怎么管 KV Cache碎片与利用率、怎么处理批处理静态还是连续、怎么调和 Prefill/Decode 冲突、怎么配合量化与缓存。评测一个框架不要只看单请求延迟要看同硬件下的吞吐和同并发下的延迟稳定性。实践中的常见误区也顺带澄清几个一是只调参不理解机制——max_tokens、温度这些参数影响的是生成行为不是框架瓶颈二是忽视显存规划——KV Cache 要按并发数 × 平均序列长度预算而不是只看权重大小三是迷信单指标——延迟、吞吐、成本是三角关系要根据业务场景取舍。九、结语LLM 推理优化的本质是把权重固定、KV 动态的显存结构、和Prefill 算力密集、Decode 带宽密集的计算结构与硬件的真实能力对齐。vLLM 等框架的出现让这种对齐从手工作坊变成了标准化工程。对开发者而言掌握推理内核的收益是长期的你看得懂吞吐报告上的数字意味着什么能判断加卡还是调参哪个更有效能在大模型部署这个领域建立真正的专业判断力。这是从会用工具到能驾驭系统的关键一步。
LLM 推理内核拆解KV Cache、Prefill 与 Decode 的优化逻辑一、部署大模型先搞懂推理在发生什么很多团队部署大模型时只关心两件事模型能不能跑起来、响应快不快。至于推理过程中到底发生了什么往往是一团迷雾。这种认知模糊带来的后果很实际模型跑起来了但吞吐上不去加显卡也提升有限参数调优全靠试错。要想真正理解 LLM 推理优化必须钻到推理的内部看清每一次生成 token 的旅程。本文从自回归生成机制讲起拆解 KV Cache 的显存逻辑、Prefill 与 Decode 两阶段的资源特征再引出 vLLM 等推理框架的核心优化思想。理解了这些底层机制你才能看懂所有优化技术到底在攻什么瓶颈。二、自回归一个 token 一个 token 地挤所有主流大模型都是自回归autoregressive的生成时模型每次只预测下一个 token把这个 token 拼到已有序列后面再预测下一个如此循环直到遇到结束符或达到长度上限。这个机制决定了两个基本事实。第一生成 N 个 token 需要 N 次前向计算延迟天然与输出长度线性相关。第二每次生成时模型需要重新看整个已生成序列——这就引出了 KV Cache 的存在意义。三、注意力机制与 KV Cache用显存换时间3.1 注意力在算什么Transformer 的注意力机制中每个 token 都会计算三个向量Query查询、Key键、Value值。计算第 t 个 token 的输出时用它的 Query 与前面所有 token 的 Key 做相似度计算决定看谁再用相似度加权 Value决定取多少信息。关键观察来了生成第 t 个 token 时前面所有 token 的 Key 和 Value 都已经算过了而且计算结果不会变。如果每次生成都重新计算一遍就是纯粹的浪费——这正是 KV Cache 出现的原因。3.2 KV Cache 的代价KV Cache 把每个已生成 token 的 Key 和 Value 缓存下来生成时直接复用。这极大地省去了重复计算但代价是显存。KV Cache 有多大以 7B 参数模型为例假设 32 层、40 个注意力头、头维度 128每个 token 的 KV Cache 需要 32 × 2 × 40 × 128 × 2 字节FP16≈ 1.3MB。看起来单 token 不大但注意这个数字是每个 token 都要占的而且长上下文和高并发会把它放大到恐怖的程度——一个 27B 模型在长序列、高并发下KV Cache 占用甚至可能超过权重本身。这就是推理优化的核心矛盾权重是固定成本KV Cache 是随并发和序列长度增长的动态成本。谁能把 KV Cache 管好谁就能在同样的硬件上服务更多用户。四、Prefill 与 Decode两个阶段、两种瓶颈4.1 两个阶段的资源特征一次推理过程可以拆成两个截然不同的阶段Prefill预填充处理用户输入。把整个输入序列一次性喂给模型并行计算所有位置的注意力生成首批 KV Cache。这个阶段的特点是计算密集、一次性完成、GPU 算力消耗大。Decode解码逐字生成回复。每次只生成一个 token复用已缓存的 KV。这个阶段的特点是内存密集、逐步进行、每次只算一个 tokenGPU 利用率天然偏低。4.2 为什么这个区分很重要因为两个阶段的资源需求相反Prefill 吃算力Decode 吃内存带宽。如果一张卡上同时跑多个请求Prefill 和 Decode 会互相竞争资源——Prefill 请求占满算力时Decode 请求的 token 生成就变慢KV Cache 占满显存时新请求连 Prefill 都排不进来。理解了这一点就理解了为什么很多优化技术连续批处理、Chunked Prefill、Prefill-Decode 分离都在围绕如何调和这两个阶段的资源冲突展开。五、传统推理框架的三大痛点在用优化框架之前先看清传统推理比如直接用 Hugging Face Transformers 跑的问题所在痛点一静态批处理。请求到达后按固定 batch 处理一个 batch 全部完成才接收新请求。请求长短不一短请求要干等长请求算完GPU 算力大量浪费在等上。痛点二KV Cache 预分配。为每个请求预先分配一整块连续显存分配多了浪费、少了扩容困难请求结束后释放的空间不连续新请求用不上——显存碎片化严重。痛点三显存预估难。模型要占多少显存、KV Cache 要占多少估算不准就只能在够用和浪费之间反复横跳。六、vLLM 的核心优化三个关键机制vLLM 之所以成为开源推理框架的主流选择是因为它针对上述痛点做了三个教科书级的优化。6.1 PagedAttention像操作系统一样管显存PagedAttention 是 vLLM 的核心灵感来自操作系统内存分页。它把 KV Cache 切成固定大小的 block块每个 block 可以存放在任意物理位置通过索引表把逻辑上的连续序列映射到物理上分散的块。这个设计的收益是双重的一是显存碎片问题大幅缓解——块可以动态分配和回收请求结束释放的块能立刻被其他请求复用显存利用率接近 100%二是按需分配——只有实际用到的块才占显存不预分配大块空间同一张卡能塞进更多请求。6.2 Continuous Batching让 GPU 永远别闲着传统静态批处理让 GPU 等最慢的请求连续批处理Continuous Batching则彻底改变思路请求不用等一个固定 batch 结束哪个请求生成完了就立即移出新请求立刻补进来。用一个餐厅类比传统批处理是一次只服务一桌客人上完一桌再接待下一桌连续批处理是后厨同时处理多桌订单哪个菜先熟就先出锅。这个机制对高并发在线服务的吞吐提升是数量级的也是 vLLM 脱颖而出的基础能力。6.3 Chunked Prefill拆开大请求填满小缝隙连续批处理解决了请求间的等待但还有一个内部矛盾一个超长的 Prefill 请求会独占 GPU 算力很久期间 Decode 请求只能干等。Chunked Prefill 的解法是把大 Prefill 请求切成多个小块交错执行——先算一块 Prefill再趁机生成几个 Decode token再算下一块。这样算力在 Prefill 和 Decode 之间持续流转GPU 利用率和整体吞吐显著提升。七、vLLM 之外的优化技术全景vLLM 解决了显存管理和批处理的基础问题但推理优化的版图远不止于此量化压缩把权重从 FP16 压到 INT8/INT4如 AWQ、GPTQ显存占用直接砍半甚至更多。精度损失可控是扩大并发规模的最直接手段。Speculative Decoding用一个小的草稿模型先猜多个 token大模型一次验证——猜对了就能一次生成多个 token延迟显著下降。它用小模型的便宜猜测换大模型的昂贵验证是延迟优化的利器。Prefix Caching多个请求共享相同的系统提示词或文档前缀时KV Cache 可以复用重复的 Prefill 计算直接省掉。多轮对话和 RAG 场景收益尤其明显。Prefill-Decode 分离部署把 Prefill 和 Decode 放到不同的 GPU 或不同的服务实例上分别优化——算力卡专注处理输入带宽卡专注生成 token。这是服务大型模型时的高级部署形态。多 GPU 并行张量并行把单层拆到多卡和流水线并行把层分段到多卡解决单卡放不下的问题。配合 KV Cache 的分布式管理可以服务更大模型、更大并发。八、从原理到实践的认知升级理解了上述机制再看推理框架的选型就有了清晰的判断标准看它怎么管 KV Cache碎片与利用率、怎么处理批处理静态还是连续、怎么调和 Prefill/Decode 冲突、怎么配合量化与缓存。评测一个框架不要只看单请求延迟要看同硬件下的吞吐和同并发下的延迟稳定性。实践中的常见误区也顺带澄清几个一是只调参不理解机制——max_tokens、温度这些参数影响的是生成行为不是框架瓶颈二是忽视显存规划——KV Cache 要按并发数 × 平均序列长度预算而不是只看权重大小三是迷信单指标——延迟、吞吐、成本是三角关系要根据业务场景取舍。九、结语LLM 推理优化的本质是把权重固定、KV 动态的显存结构、和Prefill 算力密集、Decode 带宽密集的计算结构与硬件的真实能力对齐。vLLM 等框架的出现让这种对齐从手工作坊变成了标准化工程。对开发者而言掌握推理内核的收益是长期的你看得懂吞吐报告上的数字意味着什么能判断加卡还是调参哪个更有效能在大模型部署这个领域建立真正的专业判断力。这是从会用工具到能驾驭系统的关键一步。
