推理加速-Speculative-PrefixCache与Chunked-Prefill

推理加速 · Speculative Decoding / Prefix Cache / Chunked Prefill / Eagle / Medusa定位03-部署-模型Serving 的算法纵深专章。03 讲了 Serving 栈四层 KV Cache 量化 FinOps工程口径本篇只挖**「让单次推理更快」的算法层**——为什么 Prefill 慢、为什么 Decode 难并行、四大加速流派怎么取舍。不含部署运维。风格说明机制型为主——从自回归解码的「内存墙」物理根因出发拆解 Prefill/Decode 两阶段瓶颈再逐个讲 Speculative Decoding含 Eagle/Medusa、Prefix Cache、Chunked Prefill 的原理、收益、陷阱。前置阅读01-TransformerAttention 与 KV Cache 是前提03-部署KV Cache/PagedAttention/量化的工程口径。1. 本质推理慢在哪里1.1 两阶段Prefill vs DecodeLLM 推理分两个阶段瓶颈完全不同阶段做什么计算量显存瓶颈延迟特征Prefill预填处理 prompt算所有 prompt token 的 KV大O(L²) attention高度并行KV 写入算力受限compute-boundTTFT首字延迟Decode解码逐个生成 token复用历史 KV小每步只算 1 个 token 的 attentionKV 读取显存带宽受限memory-boundTPOT每字延迟1.2 核心洞察Decode 是「内存墙」问题金句Decode 阶段每生成 1 个 token要把整个模型的权重 历史 KV从显存读到计算单元但只做极少量计算。GPU 算力大量闲置——不是算不过来是数据搬不过来。量化感知以 70B 模型、batch1、单步 decode 为例 - 模型权重读取: ~140GBFP16或 ~35GBINT4 - 实际计算: ~2 × 70G FLOPs矩阵向量乘很小 - GPU 算力利用率: 5%A100/H100 大量空转 - 瓶颈: 显存带宽~2TB/s on H100不是算力~1000 TFLOPS工程含义所有 Decode 加速算法的本质都是**「一次搬运多算几个 token」**——把闲置算力用起来。这是 Speculative Decoding 的物理动机。1.3 延迟分解面试必背端到端延迟 TTFT TPOT × output_tokens TTFTTime To First Token Prefill 时间 队列 网络 TPOTTime Per Output Token 每步 Decode 时间 客服 Agent 典型 SLA TTFT P99 800ms用户等首字 TPOT P99 45ms/token读起来不卡顿2. 加速技术全景图推理加速降低延迟提高吞吐Prefill 加速Decode 加速Chunked PrefillPrefix CacheSpeculative DecodingEagle/Medusa量化INT4/INT8/FP8Continuous BatchingPagedAttention增大 batch本章只讲降低单次延迟的算法左侧。吞吐优化Continuous Batching / PagedAttention已在 03-部署 详述不重复。3. Prefix Cache · 「相同前缀只算一次」对齐 03-部署 § Prefix cache。本节讲透原理与陷阱。3.1 原理问题多轮对话 / RAG 场景每次请求的 prompt 有大量相同前缀system prompt 长文档 历史轮但每次都重新 Prefill浪费算力。解决把已算过的前缀 KV缓存起来下次命中前缀时跳过 Prefill 直接复用。请求 1: [system][doc_A][user_q1] → Prefill 全算缓存 KV 请求 2: [system][doc_A][user_q2] → [system][doc_A] 命中缓存只 Prefill [user_q2]3.2 命中条件与实现要点Token 级精确匹配必须逐 token 完全相同才命中。差一个字、差一个 system prompt 顺序就 miss。位置编码依赖RoPE 等位置编码让 KV 与位置绑定所以前缀必须是从位置 0 开始的连续 token。LRU 淘汰显存有限按 LRU 淘汰冷前缀。实现vLLM、SGLang、TGI 均内置基于 PagedAttention 的 block 级哈希匹配。3.3 收益与陷阱维度收益TTFT长前缀场景可降 50-80%通用性适合 system prompt 固定 / RAG / 多轮陷阱应对动态 system prompt含时间戳/用户名导致永远 miss把静态部分放前面动态部分放后前缀太短收益不明显只缓存长度 阈值的前缀并发请求抢 KV 显存设缓存上限 LRURAG 场景金句「RAG 的 system prompt 长 chunk 是天然的前缀复用场景。检索结果相同的多轮对话Prefix Cache 几乎是白赚的 TTFT 优化。」4. Speculative Decoding · 「猜对了白赚猜错了不算」本章重点。这是 2023-2026Decode 加速最热的方向。4.1 动机让闲置算力干活Decode 每步只算 1 个 tokenGPU 算力闲置 95%。能不能一次并行验证多个候选 token把闲置算力用起来4.2 核心机制Draft VerifyTarget Model大/准Draft Model小/快Target Model大/准Draft Model小/快对比小模型 logits vs 大模型 logits拒绝后用大模型 logits 采样一个修正 token自回归生成 k 个候选 token快小模型提交 [t1,t2,...,tk] 给大模型一次并行验证 k 个位置并行大模型接受前 m 个匹配的 token拒绝第 m1返回最终 n 个 tokenn ≤ k1关键点Draft 模型生成 k 个候选——小模型自回归快但可能错。大模型一次并行验证——因为大模型前向时可以同时算每个位置的 logits验证 k 个候选只需1 次大模型前向而非 k 次。接受/拒绝规则重要若小模型概率q(x)≤ 大模型概率p(x)接受小模型没低估它。若q(x) p(x)以1 - p/q概率拒绝并从修正分布max(0, p-q)重采样。数学保证输出分布与大模型单独采样完全一致——加速但不改结果质量无损。4.3 为什么能加速小模型生成 k 个 token 很快小模型 decode 便宜。大模型验证 k 个候选 1 次前向并行而非 k 次串行 decode。若 k 个候选都对 → 一次拿到 k1 个 token等效 TPOT 降近 k 倍。即使部分错接受的前 m 个也是白赚的。加速上限取决于「小模型猜对率」和 k 大小。实测在代码/结构化生成场景猜对率高加速 2-3x开放创意写作猜对率低加速有限。4.4 Draft 模型的四种来源方案Draft 是谁优点缺点小模型经典同家族小模型如 Llama-70B Llama-7B通用需部署两个模型占显存Eagle自回归头与主模型共享 embedding/特征猜对率高额外开销小需训练 headMedusa多个并行头每个头预测 2/3/…位置无需额外模型猜对率低于 EagleLookup / N-gram用语料/上下文做 n-gram 查表零模型开销仅对重复/结构化文本有效Eagle 详解2024 主流原理训练一个轻量「自回归头」它复用主模型的隐藏状态hidden states只需一个小 MLP 预测下一个 token 的特征再过 LM head。为什么强因为直接拿主模型已经算好的特征不用重跑 embedding 层Draft 成本极低且猜对率高论文报告接受率 60-80%。适用已进入 vLLM 等推理引擎。Medusa 详解原理在主模型最后一层接多个并行头第一个头预测下一个 token主任务第二个头预测下下个第三个预测下下下个……一次前向同时得到多步候选。代价头之间不交流猜对率不如 Eagle但完全不增加 decode 步骤。4.5 适用场景与陷阱适合不适合代码生成强规则猜对率高开放创意写作猜对率低结构化输出JSON/schema 约束极短输出k 设小收益不显RAG/客服大量模板化回复batch 已很大时算力已不闲置陷阱应对Draft 模型与主模型分布差异大 → 接受率低用同家族小模型 / 训练 Eagle head小模型本身要占显存用 Eagle/Medusa 自带头不额外部署k 太大反而慢验证成本动态调 k根据近期接受率改变了采样逻辑与某些约束解码冲突选用支持 grammar 的 spec decoding 实现5. Chunked Prefill · 「长 prompt 不再阻塞」5.1 问题Prefill 是 compute-bound一个超长 prompt如 32K token 的 RAG会让该请求长时间占满 GPU拖慢同 batch 内其他请求的 Decode首字延迟被饿死。5.2 机制把一次大 Prefill切成多个 chunk与 Decode 请求混批调度传统[大 Prefill 32K 占满 GPU 500ms] → 其他请求 Decode 全等 Chunked[Prefill chunk 512][Decode batch][Prefill chunk 512][Decode batch]... 长请求的 Prefill 分摊短请求的 Decode 不被饿死5.3 收益TTFT 公平性短请求不会被一个长 prompt 拖死。GPU 利用率Prefillcompute-bound与 Decodememory-bound混批互补占用算力和带宽。vLLM 默认开启--enable-chunked-prefillchunk size 默认 512。5.4 陷阱chunk 太小 → Prefill 整体变慢多轮调度开销太大 → 退化成传统模式。与 prefix cache / continuous batching 的协同需调参。6. 四大技术对比与选型技术优化目标加速比无损额外开销适用Prefix CacheTTFT长前缀50-80%✅ 完全无损显存存 KVsystem prompt 固定 / RAG / 多轮SpeculativeEagleTPOT2-3x✅ 数学无损训练 head 少量算力代码/结构化/模板化Speculative小模型TPOT1.5-2x✅ 无损多部署一个模型有同家族小模型Chunked PrefillTTFT 公平性 利用率间接✅ 无损调度开销长短混合负载量化INT4/FP8TTFT TPOT 显存2-4x⚠️ 微损校准通用见 03组合使用生产实践常同时开Prefix Cache Chunked Prefill 量化Speculative 按场景开。四者正交收益可叠加。7. STAR 实战RAG 客服 Agent 的延迟优化情境S电商客服 Agentprompt 含 system 商品 KB 历史平均 2400 token。TTFT P99 1.8s超 SLA 800msTPOT 60ms超 45ms。自托管 Llama-3.1-70B AWQ on 2×A100。任务T不改模型、不加卡把延迟压回 SLA 内。行动A度量用 08-可观测 分解延迟发现 Prefill 占 TTFT 的 70%——因为每次都重算 2400 token。Prefix Cachesystem prompt 高频 KB chunk 前缀稳定开启 Prefix Cache命中后跳过 ~1800 token 的 Prefill。TTFT 降到 900ms。Chunked Prefill开启后长 prompt 不再饿死短请求TTFT P99 从 900ms 稳到 750ms。SpeculativeEagle客服回复有模板化特征接 Eagle headTPOT 从 60ms 降到 28ms。量化已有AWQ INT4未动。结果RTTFT P99 1.8s → 750msTPOT 60ms → 28ms未加卡未改模型全部通过推理引擎配置 Eagle head 实现。吞吐QPS同步提升 ~40%Chunked Prefill 提高利用率。8. 与相关章节的边界主题本章去这里看KV Cache / PagedAttention / Continuous Batching仅引用03-部署量化AWQ/GPTQ/FP8选型不展开03-部署多模型路由 / FinOps / $/task不展开07-Gateway延迟/成本可观测TTFT/TPOT trace仅引用08-可观测私有化 vLLM 部署不展开work/supplements/P2-0399. 面试速查 · 高频满分答Q1LLM 推理慢在哪里为什么 Decode 阶段 GPU 利用率这么低推理分 Prefill算 prompt和 Decode逐字生成。Prefill 是 compute-bound算力受限Decode 是 memory-bound显存带宽受限。Decode 每生成 1 个 token 要把整个模型权重 历史 KV搬到计算单元但只做极少计算GPU 算力利用率 5%——不是算不过来是数据搬不过来。这是 Speculative Decoding 的物理动机用闲置算力一次验证多个 token。Q2什么是 Speculative Decoding为什么能无损加速用一个小/快的 Draft 模型先猜 k 个候选 token再用大模型一次前向并行验证而不是 k 次串行。接受规则若小模型概率 ≤ 大模型概率则接受否则按1-p/q概率拒绝并从修正分布重采样。数学上保证输出分布与大模型单独采样完全一致——无损。加速来自小模型猜对的部分是白赚的。代码/结构化场景猜对率高加速 2-3x创意写作收益低。Q3Eagle 和 Medusa 有什么区别Medusa在主模型最后一层接多个并行头每个头预测不同步数的 token一次前向拿多步候选。简单、不额外部署模型但头之间不交流猜对率较低。Eagle训练一个自回归头复用主模型隐藏状态只加一个轻量 MLP 预测下一 token 的特征。因为直接拿主模型算好的特征Draft 成本极低且猜对率高60-80%是 2024 主流方案已进 vLLM 等引擎。Q4Prefix Cache 的原理和陷阱把已算过的前缀 KV 缓存下次命中就跳过 Prefill。适合 system prompt 固定 / RAG / 多轮场景TTFT 可降 50-80%。命中条件是 token 级精确匹配 从位置 0 开始。最大陷阱动态 system prompt含时间戳、用户名会导致永远 miss——要把静态部分放前面动态部分放后面。还要注意显存上限和 LRU 淘汰。Q5Chunked Prefill 解决什么问题解决「长 prompt 饿死短请求」。一个 32K 的 Prefill 是 compute-bound会占满 GPU 数百毫秒同 batch 的 Decode 请求全等。Chunked Prefill 把大 Prefill 切成多个小 chunk与 Decode 混批调度——长请求分摊、短请求不被饿死且 Prefillcompute-bound与 Decodememory-bound互补占用算力和带宽提高整体利用率。vLLM 默认开启。Q6你要优化一个 RAG 客服 Agent 的延迟怎么下手先用 trace 分解 TTFT 和 TPOT。①TTFT 高多半是 Prefill 重算开Prefix Cachesystem KB 前缀稳定长 prompt 混合负载开Chunked Prefill防公平性问题。②TPOT 高Decode memory-bound若回复模板化开SpeculativeEagle。③ 通用确认量化INT4/FP8已开。四者正交可叠加。我实测在 70B 模型上Prefix Cache Chunked Eagle 把 TTFT 1.8s→750ms、TPOT 60ms→28ms没加卡没改模型。一页 Checklist是否区分了 Prefillcompute-bound与 Decodememory-bound瓶颈Prefix Cache 是否开启前缀是否做到 token 级稳定Chunked Prefill 是否开启长短混合负载量化INT4/FP8是否已选型上线Speculative Decoding 是否对模板化/代码场景启用Eagle 优先Draft 模型是否与主模型同家族保证接受率是否有 TTFT/TPOT 的 P99 trace 度量08-可观测Continuous Batching PagedAttention 是否开启03-部署官方文档与源码一级依据推理加速· 本章算法机制依据官方源码L2与论文L3加速比为论文/社区实测口径实际因模型和负载而异。写作规范docs/official-sources-registry.md §0L1 · 官方文档vLLM Docs - Features (Prefix Caching / Chunked Prefill / Speculative)SGLang DocsNVIDIA TensorRT-LLM Developer GuideL2 · 官方源码vllm-project/vllmPrefix Cache / Chunked Prefill / Eagle 集成SGlang/SGLangRadixAttention 前缀缓存FUJI-AI/EagleEagle 自回归头TogetherAI/MedusaL3 · 论文Fast Inference from Transformers via Speculative Decoding (Leviathan 2023)EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty (Li 2024)Medusa: Simple LLM Inference Acceleration (Cai 2024)Efficient Memory Management for LLMs with PagedAttention (Kwon 2023)