LLM 推理系统全栈地图

一套推理系统不是优化清单，而是一条受资源约束的数据流：请求进入调度器，模型执行 Prefill 和 Decode，状态进入 KV Cache，多卡之间交换激活或 Expert token，最终把 token 交付给用户。任何优化都应先指出它改变了哪段数据流、哪种资源压力和哪个服务指标。

1. 先看数据流，再看优化名词

一次生成的主路径可以压缩为：

请求
  → tokenize / admission
  → Prefill：把 prompt 变成首轮 hidden state 与 KV
  → Decode：读取权重与历史 KV，逐步产生新 hidden state
  → LM Head / sampling
  → token 交付

Token Flow 与 Hidden State负责模型内部数据流；本页只增加系统侧的三个环：

1. 调度环：哪些请求在本轮执行、各拿多少 token budget；
2. 状态环：KV 在哪里分配、共享、迁移、回收；
3. 分布式环：权重、激活、Expert token 或 KV 在哪些 rank 之间移动。

优化的第一问因此不是“要不要上量化”，而是：

当前等待发生在数据流的哪一段，限制它的资源是什么？

2. 四种压力是共同坐标

压力	先看什么	常见控制点	主责页
计算	Tensor Core 利用、算术强度、有效 FLOPs	更合适的 Batch、低精度计算、算子形状	Roofline
访存	HBM 流量、权重/KV 字节、Kernel memory stall	量化、KV 压缩、IO-aware Kernel、Batch 摊薄	量化、KV Cache
容量	权重、KV、workspace、碎片的作用域	Paged KV、并行切分、量化、准入与抢占	KV Cache、推理并行
通信	collective、点对点传输、拓扑和重叠	TP/EP/PP/CP、放置、通信 Kernel、P/D 传输	推理并行

Prefill / Decode 是提示，不是判决

Prefill 通常有更大的矩阵，Decode 通常反复读取权重和历史 KV，因此常被概括为“Prefill 偏计算、Decode 偏带宽”。这是一条有用的起点，却不是测量结果：

• 短 prompt、小 Batch 的 Prefill 也可能利用率很低；
• 大 Batch 的 Decode 会提高算术强度；
• 长上下文 Decode 的 KV 读取可能超过权重读取；
• MoE、跨节点并行和框架同步可能把瓶颈移到通信或运行时。

具体判断交给 Compute-bound vs Memory-bound，不要用阶段名称代替 Roofline、Trace 和负载信息。

3. 七层系统地图

层	回答的问题	代表控制点	深读入口
服务与负载	谁在何时请求什么？	SLA、流量整形、路由、P/D 资源比	Serving Stack
调度	本轮让谁执行多少？	Continuous Batching、Chunked Prefill、抢占	批处理与调度
状态与内存	KV 如何分配、共享和回收？	Paged KV、Prefix Cache、CoW、Swap	KV Cache
模型算法	从源头减少什么工作？	GQA/MLA、MoE、量化、投机解码	Attention 演化、MoE
Kernel / Runtime	如何少搬数据、少启动、少同步？	IO-aware attention、Fusion、Graph	Kernel / Runtime
并行	单卡放不下或算不过来时如何切？	DP/TP/PP/EP/CP	推理并行
硬件与互联	物理上限在哪里？	HBM、Tensor Core、NVLink、PCIe、IB	GPU Architecture、GPU Communication

“框架”不再单独承担所有知识。它的职责是把这些层组装成可部署的 Serving Stack；具体机制仍由各主责页解释。

4. 优化为什么会相互影响

4.1 容量 → Batch → 带宽摊薄

量化或 KV 压缩首先释放容量。容量变大后，调度器可能容纳更多并发；更大的有效 Batch 又能把一次权重读取摊给更多 token。于是观察到的吞吐提升可能来自两段：

字节减少
  → 单步读取更少
  → 可用显存增加
  → 有效 Batch 增大
  → 每 token 权重成本继续下降

报告收益时应把“直接字节收益”和“容量带来的调度收益”分开，不能只用位宽比解释端到端倍数。

4.2 Prefix Cache → Prefill 减少，但 Decode 不自动变快

Prefix 命中减少需要重新计算的 prompt 区间，主要影响 TTFT 和 Prefill 供给。它不会自动消除后续 Decode 的权重读取，也不保证 TPOT 同比例下降。Causal Attention 的命中面积由 命中面积模型解释，端到端修正由 TTFT/TPM 修正模型解释。

4.3 Chunked Prefill → 更平滑，但可能牺牲单请求完成时间

把长 Prefill 切成多个调度块，可以给 Decode 插队，降低 ITL 抖动；同时也增加调度次数，并可能改变 Kernel 形状。它是在延迟分布、吞吐和公平性之间做预算，不是免费的加速开关。基础入口见批处理与调度，实现与实验见 Chunked Prefill 深读。

4.4 并行 → 容量或计算改善，通信增加

增加 TP/EP 可以摊权重和计算，却会引入更频繁的 collective；PP 降低每 rank 层数，却带来流水线空泡。正确配置取决于模型、Batch、序列、拓扑和 SLA，不能从 GPU 数量直接推出性能。见推理并行。

4.5 Kernel 优化 → 局部时间下降，端到端受占比限制

若某 Kernel 占端到端时间的比例为 p，即使它无限加速，总体收益也受 1 / (1-p) 约束。更常见的情况是：

• Kernel 更快后，调度或通信成为新瓶颈；
• Fusion 减少 HBM 与 launch，却增加编译和支持成本；
• CUDA Graph 降低 CPU launch 开销，却要求更稳定的形状与执行路径。

统一判断方法见 Kernel / Runtime 优化。

4.6 投机解码 → 少做大模型串行步，但要付验证成本

投机解码把多个候选 token 交给目标模型并行验证。收益由候选成本、接受长度、验证效率和负载共同决定；接受率不是吞吐倍数。稳定原理见投机解码，具体 DSpark/MTP 见实现调研，Scheduler/KV 的提交边界见 vLLM Async Scheduling 源码分析。

5. 一套可复用的诊断顺序

第一步：固定 Case

至少固定：

• 模型与 checkpoint；
• 硬件、rank 数和拓扑；
• 输入/输出长度分布；
• 并发或到达过程；
• 精度、KV 格式和并行配置；
• TTFT、TPOT/ITL、吞吐、容量与错误率目标。

没有 Case 身份的“更快”不可比较。

第二步：分开服务结果与执行证据

服务层回答是否达标：

• TTFT；
• TPOT / ITL；
• 请求吞吐与 token 吞吐；
• P50 / P95 / P99；
• OOM、抢占、拒绝和稳定性。

执行层解释为什么：

• Queue / scheduler wait；
• CPU launch / sync；
• Kernel 与 HBM；
• KV 使用与碎片；
• collective 与网络；
• 不同 rank / worker 的不平衡。

第三步：找主压力

用 Roofline、显存账本、Timeline 和通信证据判断主压力属于计算、访存、容量、通信还是运行时。多项同时存在时，应先处理约束有效容量或关键路径的控制点。

第四步：选择最小干预

证据	优先尝试
权重/KV 字节主导	量化、KV 压缩、有效 Batch
KV 容量或碎片限制 Batch	Paged KV、Prefix/CoW、准入、并行切分
长 Prefill 干扰 Decode	Chunked Prefill、长短分流、P/D 分离
CPU launch / 小 Kernel 主导	Fusion、Graph、编译或批量化
collective 在关键路径	并行度、放置、拓扑、重叠
Decode 串行步主导	投机解码，并测候选与验证开销

第五步：用同一 Case 回归

一次实验只改变一个主要控制点。除了目标指标，还要检查：

• 尾延迟是否恶化；
• 质量是否变化；
• OOM、抢占或碎片是否上升；
• 收益是物理执行改善，还是流量/缓存命中变化；
• 瓶颈是否迁移。

6. 证据边界

特别要分开三类量：

1. 理论或配置值：根据模型结构、dtype、并行度计算；
2. 校准值：用指定硬件和 workload 拟合；
3. 生产观测值：带有时间窗、采样和请求分布。

三者可以互相校验，不能互相冒充。

7. 怎么继续读

如果只想建立完整坐标，按本系列继续：

1. Token Flow 与 Hidden State
2. Attention 架构演化
3. Compute-bound vs Memory-bound

如果正在解决具体问题：

• 显存 / 长上下文 / Prefix → KV Cache 专题
• 低精度 / 质量 / Kernel 是否真的执行 → 量化专题
• 排队 / ITL / Prefill 干扰 → 调度专题
• MoE / 多卡 / collective → MoE + 推理并行
• 小 Kernel / launch / HBM 往返 → Kernel / Runtime
• 一次多出 token → 投机解码
• 框架和 Serving 组合 → 推理框架对比 2026
• 动手改变参数看压力迁移 → 推理性能优化实验室

相关页面

• LLM 推理系统索引 — 所有专题、案例与来源的入口
• Agentic Infra 推理优化 — 一份来源摘要中的 Profiling 闭环
• Agentic AWP — 从观测走向 Breakdown 的来源摘要
• 模拟器建模指南 — 公式、作用域、配置与校准边界