知识全景图/ 软件工程与系统/ 人工智能全景图/ 推理计算、KV Cache 与吞吐延迟

LLM 推理计算、KV Cache 与吞吐延迟底层图谱

从 Prefill、Decode、Attention、KV Cache 到 Batching、量化和推测解码，理解 LLM 在线推理为什么慢、为什么贵、为什么尾延迟难控

阅读定位: 这一页补 AI 底层理解线里更硬核的推理计算直觉。它不讲 tokenizer 和词表细节、权重文件格式、模型服务平台的完整治理，也不替代成本工程、LLMOps 或一次请求链路专题；token 数从哪里来继续看 Tokenizer / token 预算，位置编码、RoPE、position ids 和长上下文外推继续看 位置编码 / RoPE，权重和 checkpoint 如何落到显存继续看 参数 / 权重 / Checkpoint，本页专注解释推理系统指标背后的计算、显存、带宽和调度约束。
一、一条推理请求的计算骨架
Prompt
输入 tokens
→
Prefill
一次读完整上下文
→
KV Cache
保存历史状态
→
Decode
逐 token 生成
→
Streaming
首 token / 流式
→
Metrics
TTFT / P95 / 成本
阶段它在做什么主要消耗用户侧表现
Tokenize把用户输入、历史、RAG 内容和工具结果切成 tokens；细节见 Tokenizer / 词表CPU 与少量前处理时间通常不显眼，但超长输入会放大后续成本
Prefill模型一次性读完整输入上下文，建立初始注意力状态计算量、显存带宽、KV Cache 初始化直接影响 TTFT，也就是首 token 之前的等待
Decode每一步生成一个新 token，并把它追加进上下文内存带宽、KV Cache 读取、逐步调度决定流式输出速度和总耗时
Post-process停词、结构化解析、安全过滤、日志和计费应用层 CPU、规则和存储影响最终返回与可观测性
二、Prefill vs Decode：两类完全不同的慢
Prefill 慢：输入太长
  • 它要处理用户 Prompt、系统 Prompt、历史对话、RAG 片段和工具返回
  • 上下文越长，首 token 之前的计算越重
  • 很多“模型没有反应”的体验，本质是 prefill 还没做完
  • 治理动作通常是上下文裁剪、摘要、Prompt Cache 和检索控制
Decode 慢：输出太长
  • Decode 是逐 token 循环，不能一次性把完整答案吐出来
  • 每生成一个 token，都要读模型权重和历史 KV 状态
  • 输出越长，总耗时越长，流式也会拖更久
  • 治理动作通常是 max tokens、停止条件、简洁格式和推测解码
两种慢要分开看
  • TTFT 高，优先看输入长度、队列、prefill 和缓存命中
  • 流式慢，优先看 decode token/s、输出长度和批处理调度
  • 总耗时高，可能是两者叠加，也可能是下游后处理阻塞
  • 只看平均耗时会掩盖真实瓶颈

一个实用判断

如果用户等很久才看到第一个字，先查 TTFT、输入 token 数和 prefill 队列；如果第一个字很快出现但答案慢慢挤出来，先查 decode 速度、输出 token 数和当前 batch 状态。

三、Attention 复杂度：为什么上下文长会慢

直觉版解释

Attention 的核心动作，是让当前位置去“看”前面相关位置。上下文越长，可看的位置越多，模型就要维护更多关系；位置编码和 RoPE 决定模型如何感知这些顺序与距离，细节见 位置编码 / RoPE。不要把它理解成读一篇文章只是线性扫一遍；在 Transformer 里，位置之间的相互关联本身就是计算对象。

为什么长上下文不只是多几个字

长上下文会同时拉高 prefill 计算、KV Cache 显存、批处理调度难度和队列等待。RAG 把十几段资料塞进 Prompt，往往不是免费提升准确率，而是在用延迟和成本换更多背景信息。

输入变化推理层变化典型后果治理方向
Prompt 变长Prefill 计算增加，首 token 前等待变长TTFT 上升，短交互体验变差Prompt 压缩、上下文摘要、模板瘦身
历史对话变长每轮都带入更多旧内容成本随对话轮次滚雪球记忆分层、窗口裁剪、长期记忆检索
RAG Top-K 过大检索片段占用大量上下文看似信息更多，实际可能稀释重点并拉高延迟重排、引用压缩、只传必要证据
长文档整篇塞入Prefill 与 KV Cache 压力同时增大GPU 容量下降，P95 / P99 更容易抖分段处理、Map-Reduce、结构化抽取
四、KV Cache：省计算，但吃显存
KV Cache 的作用
  • Decode 时不必反复重算所有历史 token 的 Key / Value
  • 它把历史状态存起来，让下一步生成能直接读取
  • 没有 KV Cache，长输出的重复计算会非常浪费
  • 它是高性能 LLM 推理的基础设施资产
显存压力从哪里来
  • 每个请求都要保存自己的历史 KV 状态
  • 上下文越长、并发越高、层数和 hidden size 越大，占用越高
  • 有时瓶颈不是算力不够，而是 KV Cache 把显存占满
  • 长上下文服务尤其容易被 KV Cache 卡住容量
为什么它影响调度
  • 请求还在生成，KV Cache 就不能随便释放
  • 长请求会占据更多显存时间，挤压短请求
  • 显存碎片和不同长度请求会让批处理更难排
  • PagedAttention 正是在治理这类问题

一句话理解 KV Cache

KV Cache 是用显存换计算：它让 decode 不用重复算历史，但会把长上下文和高并发变成显存管理问题。

五、Batch、序列长度与尾延迟的权衡
变量提高后通常发生什么收益风险
Batch size更多请求合在一起跑GPU 利用率和总体吞吐提升等待合批会增加排队时间，长短混批会拉高 P95 / P99
Sequence length每个请求带更多输入或生成更多输出能处理更复杂上下文和长回答Prefill、KV Cache 和 decode 总时间同步上升
并发数同时服务更多用户请求摊薄硬件成本，提高资源利用队列堆积、显存耗尽、尾延迟抖动
吞吐优先系统倾向于把 GPU 填满单位 token 成本更低交互式体验可能变差
延迟优先系统倾向于减少等待和小批快速返回TTFT 和 P95 更好GPU 利用率可能下降，单位成本上升
关键判断:

Batching 不是越大越好。离线批处理、后台总结、批量分类可以更偏吞吐；聊天、代码补全、客服助手更关注 TTFT、流式平滑度和 P95 / P99。

六、量化：优化显存和带宽，不是免费午餐
它优化什么
  • 降低权重占用，让更大模型或更大 batch 放进显存
  • 减少内存带宽压力，decode 阶段可能更快
  • 降低部署成本，让单卡或低规格 GPU 有机会承载服务
  • 常见方向包括 INT8、INT4、AWQ、GPTQ、GGUF 等
风险在哪里
  • 低精度可能损伤长文本、推理、代码或特定领域能力
  • 平均榜单不变，不代表你的业务任务不受影响
  • 不同模型、不同量化方法、不同硬件收益差异很大
  • 没有回归评测，量化优化就很容易变成隐性质量退化
怎么判断值不值
  • 看显存节省、tokens/s、TTFT、P95 和单位请求成本
  • 同时跑任务级评测，而不是只看通用 benchmark
  • 先灰度低风险流量，再扩展到核心业务场景
  • 准备回滚策略和版本对比记录
七、FlashAttention、PagedAttention、Speculative Decoding
技术它主要优化什么工程直觉适合观察的结果
FlashAttention Attention 计算的内存访问效率 不是改变模型含义，而是更聪明地组织计算和显存读写，减少中间结果搬运。 Prefill 性能、长上下文吞吐、GPU 利用率
PagedAttention KV Cache 的显存管理 像操作系统分页一样管理 KV Cache，减少碎片，提高可承载并发。 并发容量、显存利用率、长短请求混跑稳定性
Speculative Decoding Decode 阶段的生成速度 让小模型先起草多个 token，大模型批量验证；猜得准时，就能减少大模型逐步生成的等待。 输出 tokens/s、端到端延迟、质量回归、草稿命中率

不要把工程优化误解成能力增强

这些技术主要让同一个模型跑得更稳、更快或更省显存。它们通常不会凭空提升模型知识和推理能力；如果业务答案质量不行，仍然要回到模型、数据、RAG、Prompt、评测和产品流程。

八、自部署与 API 调用分别看什么指标
场景必须观察最好进一步拆分常见动作
自部署推理 GPU 利用率、显存占用、KV Cache 水位、tokens/s、TTFT、P95 / P99、队列长度、失败率 prefill 时间、decode 时间、batch size、sequence length、缓存命中率、不同模型版本 调 batch、分池、量化、扩容、上下文压缩、引擎升级、长短请求分流
闭源 API 调用 输入 / 输出 token、TTFT、总耗时、错误码、限流、重试、单位请求成本 按用户、产品、功能、模型、Prompt 模板、RAG 命中来源拆分 模型路由、Prompt 瘦身、输出长度控制、缓存、重试退避、供应商降级
混合架构 不同模型后端的质量、成本、延迟、可用性和命中比例 路由规则、Fallback 触发原因、灰度版本、任务类型分布 动态路由、SLA 分层、小模型优先、复杂任务升级、统一网关审计
8.1 推理计算证据包：把 GPU、KV Cache、队列和成本接进 Trace
证据节点必须记录的字段用来定位什么
prefill 计算input_tokens、sequence_length、prefill_ms、prompt_cache_hit、attention_backend首 token 慢是否来自长上下文、缓存未命中或 Attention 实现差异？
KV Cache 水位kv_cache_bytes、block_usage、eviction_count、reuse_rate、max_context显存压力、缓存逐出、长请求挤占和吞吐下降从哪里来？
batch 调度batch_size、active_sequences、waiting_queue、priority_class、scheduler_policyP95 / P99 尾延迟是队列、长短请求混跑还是优先级策略造成的？
decode 阶段output_tokens、tokens_per_second、decode_ms、speculative_accept_rate总耗时和单位 token 成本是否被输出长度或解码策略拉高？
资源与成本gpu_id / pool、gpu_util、memory_util、billable_units、cost_center某个租户、功能或模型版本是否消耗了异常资源？
请求血缘request_id、generation_id、route_id、engine_version、trace_id从产品坏例能否反查到具体模型池、推理引擎和计算状态？
九、常见误区
误区：长上下文只是价格贵一点
长上下文还会影响 TTFT、KV Cache、batch 调度和尾延迟。它不是账单问题，而是系统容量问题。
误区：KV Cache 是纯收益
KV Cache 节省重复计算，但显存占用很真实。上下文、并发和输出长度上来后，它会成为核心瓶颈之一。
误区：吞吐高就代表用户体验好
高吞吐可能来自更激进的 batching，但交互式产品更在意首 token、流式平滑和 P95 / P99。
误区：量化一定不影响质量
量化是否可用必须按任务评测。尤其是代码、数学、长文本和专业领域，不能只看平均 benchmark。
误区：API 用户不用懂底层推理
即使不自部署，输入 token、输出 token、TTFT、限流、重试和模型路由仍会决定成本和体验。
误区：推理优化只靠换引擎
引擎很重要，但 Prompt、RAG、输出格式、产品流程、路由和评测同样会改变推理负载。
十、回到 AI 主干
AI 全景 → 训练 / 推理 / Scaling → 参数 / 权重 → Position / RoPE → 一次请求的一生 → 模型服务 / 推理网关 → 成本 / 性能工程 → LLMOps / 评测观测

这张图在主干里的位置

如果说 一次请求的一生 解释请求链路，模型服务 / 推理网关 解释生产服务层，那么这一页解释链路中最贵、最容易抖的计算内核：prefill、decode、attention、KV Cache 和调度权衡。