27届大模型面试准备三十LLM 推理性能优化全栈——KV Cache、连续批处理、投机解码与 PD 分离前面 A25 讲过推理服务化与投机解码的服务架构视角A29 讲过长文本推理的注意力成本视角。这一篇把推理性能当成一条完整流水线来优化从一张显存账本出发看清钱到底花在哪再逐层叠加批处理、投机解码、算子/编译优化、服务架构和量化部署最后给出一套可落地的调优方法论。目标不是背名词而是建立延迟-吞吐-成本三角的权衡直觉。本文按目标三角 → 显存账本 → 批处理演进 → 投机解码深入 → 算子与编译 → 服务架构 → 量化部署 → 调优方法论展开结尾给面试速答和高频追问清单。一、推理优化的目标三角1.1 三个互相打架的指标推理优化永远在平衡三个量延迟首个 token 延迟 TTFT、每 token 间隔 ITL、总耗时、吞吐单位时间处理多少请求/token、成本每张卡每小时能服务多少请求。它们彼此制约——想压低单请求延迟往往要独占算力吞吐就掉想拉高吞吐就得多请求混跑单请求延迟就升。面试常考的为什么不能既要又要因为 GPU 算力和显存带宽是硬物理上限。优化不是打破物理而是把浪费的部分找出来还给我们。下面每一节都是在说哪里原本被浪费了。1.2 两个阶段的成本不同自回归生成分两阶段prefill处理整段输入 prompt可以并行算所有位置和 decode一个 token 一个 token 出每一步都要读全部 KV Cache。prefill 是 compute-bound算力密集decode 是 memory-bandwidth-bound带宽密集因为每出一个 token 都要把巨大权重和 KV 从 HBM 搬一遍。很多优化之所以要区分对待这两个阶段根子就在它们的瓶颈不同——PD 分离第六节就是顺着这个区分长出来的。二、显存账本钱花在哪了2.1 三笔账部署一个模型显存主要被三块吃掉模型权重参数量×精度字节、KV Cache随序列长度和并发增长见 A29 公式、激活与临时buffer。在长上下文、高并发场景下KV Cache 经常反超权重成为显存大头。把账算清楚是优化的第一步。例如一个 13B 模型用 FP16权重约 26GB但开 128K 上下文、并发 16 路时KV Cache 可能冲到几十 GB。如果显存被 KV 占满就不得不降并发吞吐跟着掉。所以压缩 KV是性价比最高的优化之一。2.2 KV Cache 量化把 KV Cache 从 FP16 量化到 INT8甚至 INT4/INT2 的稀疏化量化方案如 KVQuant能直接砍掉一大半显存等于同样显存下并发翻倍或上下文翻倍。代价是极小的概率质量损失实践中通常可忽略。权衡很划算KV 量化几乎不损效果却大幅释放显存是长上下文服务的标配。显存占用示意同一模型不同 KV 精度: FP16 KV: [################] 占满 → 并发 8 INT8 KV: [##########------] 省一半 → 并发 16 INT4 KV: [######----------] 省 3/4 → 并发 32 → 同样显卡吞吐随并发近似线性提升三、批处理演进从等最慢的到来一个跑一个3.1 Static / Dynamic / Continuous Batching最早是静态批处理凑满固定大小的 batch 才一起算慢请求拖死整批GPU 利用率低。动态批处理允许不等满就发但仍以整个序列结束为释放单位。连续批处理continuous batchingvLLM 的招牌更进一步在每一步 decode 后立刻把刚结束的请求换出、把新到的请求换入做到 token 级调度。连续批处理的关键是请求的释放单位从整个序列变成每个 token 步所以长短请求可以真正交织GPU 不再为空等慢请求而闲置。这是吞吐提升最大的单点优化之一也是现代推理引擎的分水岭。3.2 它为什么要配合 PagedAttention连续批处理要在显存里灵活换入换出不同长度的 KV如果 KV 是连续大块预留就会产生碎片和预留浪费。所以 vLLM 用 PagedAttention 把 KV 分页按需分配小块连续批处理才能既灵活又不爆显存。两者是配套的没有分页连续批处理会被显存碎片拖垮没有连续批处理分页的灵活性也发挥不出来。四、投机解码深入用草稿验证骗过自回归4.1 原理回顾与接受率A25 提过投机解码speculative decoding用一个小而快的草稿模型先猜 k 个 token再用大模型一次并行验证这 k 个把 k 个拼成输入大模型一次前向就能算出每个位置的条件概率全部接受就白赚 k-1 步。它不改变输出分布只是加速。加速比取决于接受率——草稿猜得越准接受越多加速越明显。经验上同系列小模型当草稿、或专门训练的草稿头如 Medusa 的多个非自回归头、EAGLE 用大模型自身特征做自回归草稿接受率能到 0.7~0.9端到端加速 2~3 倍很常见。4.2 草稿模型的几种形态形态做法特点独立小模型用 0.5B 草稿配 7B 主模型简单但分布偏差大、接受率有限Medusa给主模型加多个预测头并行猜未来若干 token不另起模型头轻量需微调EAGLE利用主模型倒数层特征自回归地出草稿接受率高训练成本适中自蒸馏草稿用主模型自己 distill 出草稿分布最贴近接受率最高4.3 什么时候投机解码不划算两个反例一是小模型本来就不慢投机解码的草稿开销反而亏二是草稿与主模型分布差太远、接受率极低等于白跑草稿。所以它是大模型 高可接受率场景的利器不是万能药。面试被问为什么不用投机解码加速小模型时答开销盖过了收益、接受率上不去即可。五、算子与编译优化把 GPU 喂饱5.1 算子融合与 CUDA Graph注意力、LayerNorm、激活函数这类小算子如果各自单独启动 GPU kernel大量时间浪费在 kernel 启动和 HBM 往返上。算子融合把多个小算子合成一个大 kernel减少往返和启动开销。CUDA Graph 则把一串固定的 kernel 启动录制成图之后整图重放消除每步的 Python/驱动调度开销——对 decode 这种每步结构固定的场景收益明显。5.2 FlashDecodingFlashAttention 主要优化 prefill。decode 阶段因为每步只算一个新 token 对全部历史 KV 的注意力单个 query 的并行度不足GPU 吃不满。FlashDecoding 把新 token 对长 KV的注意力在 KV 维度上分块并行再把结果 merge把 decode 阶段的 GPU 利用率显著拉高是长上下文 decode 加速的关键。六、服务架构优化PD 分离与并行6.1 为什么 Prefill 和 Decode 要分开prefill 是算力密集、能瞬时吃满 GPUdecode 是带宽密集、GPU 大量时间在等数据。如果把两者塞在同一块卡上交替跑prefill 的大块算力需求会抢占 decode 的带宽互相拖累导致 decode 的 ITL每 token 间隔剧烈抖动——用户体感就是输出一顿一顿。PD 分离把 prefill 和 decode 放到不同实例prefill 集群快速算完 KV 后把 KV 传给 decode 集群连续生成。这样 decode 的延迟更平稳整体吞吐也更高。传统同卡: [prefill 占满][decode 等][prefill 占满][decode 等] ← ITL 抖动 PD 分离: Prefill 集群: 算 KV 传给 Decode 集群: [稳稳出 token 出 token 出 token] ← ITL 平稳6.2 张量并行与多卡推理单卡放不下或不够快时用张量并行TP把一层权重切到多卡、流水并行PP把层切到多卡。推理侧 TP 更常见因为单层内算力可以并摊。难点在卡间通信all-reduce所以 TP 通常限定在同一节点内高带宽互联NVLink跨节点走 IB 会显著掉速。面试常问TP 和 PP 推理时怎么选追求单层内低延迟用 TP受通信带宽约束模型太深单卡放不下用 PP 补位。七、量化部署从训练后量化到混合精度7.1 权重量化 vs 激活量化W8A8权重和激活都 INT8是推理加速的甜点Tensor Core 对 INT8 有数倍算力且显存减半。更激进的 W4A16权重 INT4、激活 FP16如 AWQ、GPTQ能把 7B 模型压进一张消费级显卡代价是精度损失需靠重要权重保留更高精度的算法AWQ 的激活感知、GPTQ 的二阶补偿来抵消。7.2 量化怎么选方案显存速度质量适用FP16100%基准最佳不差钱、求稳W8A8~50%快几乎无损高并发服务首选W4A16(AWQ/GPTQ)~25%较快略损单卡省钱、边缘KV 量化省 KV略快几乎无损长上下文必开一个实战经验量化不是越狠越好。先上 W8A8 拿吞吐长上下文再叠加 KV 量化只有当显存真放不下时才上 W4。调量化要配评测集回测避免省了显存、烂了效果。八、调优方法论先量再改8.1 一张排障顺序表面对推理太慢/太贵不要上来就堆技巧而是按先测瓶颈 → 再对症下药的顺序测 TTFT 和 ITL判断是 prefill 慢还是 decode 慢看 GPU 利用率低则上连续批处理 提高并发看显存是否被 KV 占满是则开 KV 量化 PagedAttentiondecode 慢则试投机解码大模型场景成本高压则上 W8A8边缘/单卡上 W4延迟抖动则考虑 PD 分离。8.2 永远用数据说话每一招都有适用边界见前面各节的不划算反例。生产调优的铁律是每次只改一个变量用真实流量回测 TTFT/ITL/吞吐/成本/质量确认正向再叠加。靠听说某技巧快盲目堆常常相互抵消甚至变慢。九、生产落地一份推理优化作战手册9.1 不要凭感觉堆优化真实项目里最忌听说投机解码快就上、听说 W4 省显存就压。每一次优化都是权衡必须配真实流量的回测数据。一个稳妥的落地节奏是先上连续批处理 PagedAttention 把吞吐底座打好再开 KV 量化释放显存然后用 W8A8 换速度长上下文或成本敏感时再叠 W4 和投机解码最后延迟抖动再考虑 PD 分离。每一步都用 TTFT、ITL、吞吐、单请求成本、质量评分五条曲线验证正向再叠加下一步。9.2 一张场景化配方表场景首要优化次要优化高并发问答短 prompt连续批处理、W8A8KV 量化、CUDA Graph长文档/长上下文KV 量化、FlashAttention、PagedAttentionPrompt Cache、分块/ring大模型逐字生成慢投机解码接受率高的草稿W8A8单卡省钱边缘部署W4A16AWQ/GPTQKV 量化延迟抖动明显PD 分离限流、队列9.3 用分布式系统的纪律对待推理推理服务本质上是带大模型的分布式系统它有队列、有调度、有故障、有容量上限。把延迟抖动当 SLO 来守把成本当预算来管把显存当容量来规划。很多团队把推理优化当成调模型参数的玄学其实它更需要的是 SRE 的工程纪律——可观测、压测、容量规划、灰度。能同时讲清算法原理和系统纪律的候选人在推理侧面试里非常稀缺。9.4 成本建模先算账再优化任何优化都要回答省了多少钱。一个简单的成本模型是单请求成本 ≈ (输入 token × 输入单价 输出 token × 输出单价) 显存占用折算的卡时。优化要么降 token缓存、路由、压缩 prompt要么降卡时量化、批处理提吞吐要么提并发连续批处理摊薄固定开销。面试时能把一个 7B 模型、QPS10、平均 500 输出 token的月度成本粗算出来并说出三处可砍的点比背一堆名词更显老练。成本意识是区分会用模型和能把它跑成生意的关键。9.5 容量规划与压测上线前必须压测而不是凭感觉给资源。压测要看两个拐点一是吞吐拐点并发到多少时延迟开始陡增二是显存拐点上下文多长、并发多少时触发 OOM 或被迫降批。据此定单实例承载上限和扩缩容阈值。一个常见翻车是只在单请求下测过延迟一上真实并发就全盘崩——因为连续批处理下单请求延迟和吞吐是相互牵制的必须按真实流量形态压测。把容量水位线画清楚是推理服务稳定性的地基。9.6 两个真实踩坑案例案例一是投机解码反噬。某团队给一个本就不大的 7B 模型上投机解码期望加速结果草稿模型与主模型分布偏差大、接受率只有 0.3每步还多花草稿前向端到端反而慢了 15%。教训投机解码是大模型 高接受率的利器小模型上先算接受率再决定。案例二是量化翻车。另一团队为省钱直接上 W4没做评测回测结果在自家业务的长尾样本上准确率掉了近十个百分点才被发现。教训量化每降一档都要用真实业务集回测不能只看通用 benchmark。这两个案例都说明同一件事——推理优化必须先量后改、用数据收尾。9.7 缓存被低估的最强杠杆在所有推理优化里缓存常常是被低估、却性价比最高的一招。两类缓存最常见精确缓存命中完全相同的请求前缀比如固定的系统提示、常见问答直接复用 KV 与结果省掉整段计算语义缓存对意思相近的提问命中历史结果用向量相似度判断复用能挡掉大量重复query。在客服、问答这类问题高度重复的场景语义缓存能砍掉三成以上的实际计算量且几乎不损质量。它和量化、批处理不冲突是叠加在一切优化之上的免费午餐——前提是做好缓存失效与一致性管理避免返回过期错误答案。9.8 延迟拆解定位瓶颈从哪来优化前先拆延迟才知道该打哪。一次请求的端到端耗时大致能拆成几段排队等待前面请求没跑完连续批处理下的排队、prefill 计算处理输入、算力密集、逐 token decode每步读权重与 KV、带宽密集、网络与框架开销调度、序列化。如果 TTFT 高多半是排队或 prefill 慢解法在批处理与算力如果 ITL 高吐字慢多半是 decode 带宽受限解法在 KV 量化、投机解码、FlashDecoding如果整体波动大多半是 prefill/decode 互相抢占解法在 PD 分离。能对着一段真实 trace 拆出慢在哪一段、对应哪个优化是推理调优面试的加分项比泛泛说上个缓存专业得多。9.9 优化 ROI 排序先做性价比最高的如果时间有限按投入小、收益大排序优化该这么排第一优先是连续批处理 PagedAttention几乎是改个引擎配置就能拿到的吞吐跃升投入极小第二是 KV 量化几行配置省掉近半显存直接换并发第三是 W8A8 权重量化吞吐与成本双降第四才是投机解码仅大模型有用、要先验证接受率和 PD 分离架构改动大、收益在延迟稳定。这个排序的核心逻辑是先用配置级优化吃下大部分收益再用代码级/架构级优化啃硬骨头。面试被问资源只够做一件优化先做啥答连续批处理基本不会错因为它门槛最低、覆盖面最广。9.10 一个常见指标误解收尾提醒一个高频误解很多人把吞吐量高直接等同于体验好但吞吐和单用户体验是两件事。连续批处理把吞吐拉满代价是单请求在排队中等待TTFT 可能变长。如果业务是用户对着屏幕等第一个字TTFT 比吞吐重要这时该限并发保 TTFT而不是无脑堆吞吐。指标之间永远有 trade-off优化前先问这个场景最该保哪个指标——能这么反问的工程师才不会被吞吐翻倍的漂亮数字带偏。推理优化没有银弹只有对着业务目标做权衡。把这句话刻进脑子里就不会被任何一个新出的加速技巧带节奏而始终能回到我的业务到底要保延迟、吞吐还是成本这个原点做决策。这也是区分调参侠和系统工程师的分水岭前者追单个指标的数字后者守业务目标的平衡。十、三道高频推理面试题精讲10.1 算清一笔 KV 显存账面试官常让你现场估一个 7B 模型32 层、GQA 组数 8、每组维 128、FP16在 128K 上下文、batch1 时 KV Cache 多大公式2K,V× 层数 × 组数 × 每组维 × 序列长 × 字节数 2×32×8×128×131072×2 ≈ 17.2GB远超模型权重本身。结论长上下文的显存大头是 KV不是参数——所以 KV 量化 分页是必选项而不是可选项。能当场推下这个数字比背KV 很重要值钱得多。10.2 连续批处理为何提吞吐却可能降 TTFT连续批处理把释放单位从整序列降到每 token 步GPU 不再等慢请求吞吐上升但代价是新请求要排队等当前批次腾出调度槽TTFT 可能变长。所以优化前先问这个场景保吞吐还是保首字延迟问答接口保 TTFT限并发离线批量保吞吐堆并发。同一个技巧指标取向不同结论相反这正是推理优化的权衡本质。十一、面试速答 高频追问清单面试速答一句话版- 推理优化围绕延迟-吞吐-成本三角权衡prefill 算力密集、decode 带宽密集。- KV Cache 量化与 PagedAttention 省显存是长上下文/高并发的地基。- 连续批处理按 token 步调度把 GPU 空等降到最低吞吐提升最大。- 投机解码靠草稿并行验证白赚步数加速比取决于接受率大模型才划算。- PD 分离让 prefill/decode 互不拖累decode 延迟更稳量化按 W8A8→KV→W4 渐进上。高频追问清单1. prefill 和 decode 的瓶颈分别是什么为什么 PD 分离能稳 ITL2. 连续批处理相比静态批处理释放单位从什么变成什么为什么吞吐高3. PagedAttention 解决什么为什么必须和连续批处理配合4. 投机解码为什么不改变输出分布接受率受哪些因素影响5. Medusa 和 EAGLE 的草稿机制有何不同各自适合什么6. 权重量化 W4A16 和激活量化 W8A8 怎么选AWQ/GPTQ 怎么保质量7. KV Cache 量化在什么场景下收益最大有副作用吗8. CUDA Graph 和 FlashDecoding 分别解决哪类开销9. TP 和 PP 在推理时怎么分工为什么 TP 受通信带宽约束10. 给你一个7B 模型、128K 上下文、成本敏感的部署题你的优化顺序是