推理性能与成本优化：延迟、吞吐与显存背后的原理
理解 Prefill/Decode、KV Cache、批处理、量化与缓存，建立性能优化的第一性认知
- 理解一次推理为什么分成 Prefill 和 Decode 两阶段
- 理解 KV Cache 的作用与显存代价
- 理解连续批处理如何提升吞吐
- 理解量化、缓存与模型分层的降本原理与取舍
优化性能前，先看懂一次请求在服务器里发生了什么
应用层觉得“慢”、觉得“贵”，落到推理引擎层面，成因都很明确。搞懂 Prefill、Decode 和 KV Cache，你才能跟工程团队聊到一块儿去，做产品决策的时候也能拿准取舍。
2.1 Prefill 与 Decode：两段速度特性完全不同
一次生成分两阶段：
Prefill（预填充）：一次性处理你输入的全部 Prompt，并行计算，计算密集。输入越长，这一阶段越耗时——这就是“首 Token 延迟（TTFT）”的主要来源。Decode（解码）：之后一个 Token 一个 Token 地自回归生成，每生成一个新 Token 都要把前面的内容再“过一遍”，访存密集。这决定了“生成速度（TPOT / Token 每秒）”。
首 Token 延迟主要由 Prefill 处理输入的时间决定。精简 Prompt、用检索只塞必要内容，不仅省钱，也直接缩短用户看到第一个字的等待时间。
用户抱怨“发送后要等很久才开始出字”，主要对应哪个阶段？
2.2 KV Cache：用显存换速度
Decode 每一步都要用到前面所有 Token 的注意力中间结果，也就是 Key 和 Value。每步都重算的话，代价极高。KV Cache 就是把这些结果缓存下来复用，能大幅加速。代价是要占显存，而且缓存大小会跟着上下文长度、并发数往上走。
这能解释几个现象：长对话更吃显存；并发越高显存压力越大；一些服务对“缓存命中的重复前缀”给折扣价（Prompt Caching），因为相同的系统提示/示例不用重复做 Prefill。
Prompt Caching 的产品价值
大量请求共享同一段长系统提示、少样本示例或工具说明时，开前缀缓存就行——这部分内容只计算一次，后续命中直接复用，既能降首 Token 延迟，又能省成本。
落地要点：把稳定不变的内容放在 Prompt 最前面、易变内容放后面，才能最大化前缀命中；频繁变动的拼接顺序会让缓存失效。
2.3 批处理：为什么并发上来后单请求可能变慢
推理引擎通过批处理（Batching）把多个请求拼在一起计算以提升 GPU 利用率；现代的连续批处理（Continuous Batching）允许请求动态加入/退出，不必等整批结束。批越大吞吐越高，但单请求可能排队、延迟上升。吞吐与单请求延迟之间需要根据业务（离线批量 vs 在线交互）权衡。
2.4 量化：用精度换体积与速度
量化就是把模型的权重、激活从高精度（比如 FP16/BF16）压缩到更低的比特位（INT8、INT4 这类），能明显省显存、提吞吐、降成本，代价是可能掉点效果。平时常说的量化还分两种：只量化权重的，和“权重+激活”都量化的。后者更难做，但提速效果更明显。
从产品角度说，量化不是越猛越好，得拿自己的评测集去比「压缩后效果掉了多少」。对效果敏感的复杂任务就留高精度，简单任务直接用量化小模型。
2.5 应用层降本提速组合拳
不碰底层推理框架，应用侧照样有不少优化空间：模型分层路由，简单任务走小模型；结果缓存，相同/相似问题直接返回；流式输出让用户“先看到字”，主观等待感大减；压缩历史与检索内容；能离线批处理的就不占在线实时资源；设置每用户限额，防止异常调用放大成本。
调优按这个顺序来：先搞零风险的应用层优化——精简上下文、加缓存、做分层路由；再动服务级的东西，比如批处理、前缀缓存；最后才碰模型级的，像量化、蒸馏、换模型。每一步都得用评测集和监控数据，验证清楚收益和副作用。
下列哪种应用层做法不能直接降低单次推理成本？
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
每个 token 投影出 Query、Key、Value 三个向量：用当前词的 Query 与所有词的 Key 算相似度得分，softmax 归一化成权重，再对 Value 加权求和，就实现了「理解当前词时该关注哪些词」。多头注意力让模型在多个子空间并行关注不同关系。其复杂度随序列长度平方增长 O(n²)，正是长文本的主要瓶颈。