先减少计算量，再提升计算效率；先优化单次推理，再优化批量服务；最后从单机优化走向集群级协同。
1. 模型与算法层：减少需要完成的工作
核心问题：模型计算太多、单次生成太慢、模型部署成本太高。
| 关键技术 | 解决的核心问题 | 主要收益与代价 |
|---|---|---|
| 量化（INT8、INT4、FP8 等） | 权重和激活占用显存大、数据搬运成本高 | 降低显存与带宽压力；可能损失精度，收益取决于硬件支持 |
| 剪枝与稀疏化 | 模型存在冗余参数或计算 | 减少有效计算；非结构化稀疏未必能转化为实际加速 |
| 知识蒸馏 | 大模型推理成本高、部署门槛高 | 用小模型逼近大模型能力；需要训练或蒸馏流程 |
| 投机解码（Speculative Decoding） | 自回归生成每个 Token 都需要串行执行 | 草稿模型先提议多个 Token，再由目标模型验证；可加速生成，效果取决于接受率和额外开销 |
| 早退、条件计算、MoE 路由 | 每个请求都执行同样规模的计算 | 让不同输入消耗不同计算量；引入路由、负载均衡或精度权衡 |
2. 数值精度与算子层：让硬件更高效地计算
核心问题：理论算力很高，但实际执行效率低；大量时间耗在内存读写、内核启动和中间结果处理上。
| 关键技术 | 解决什么问题 | 作用机制 |
|---|---|---|
| 混合精度计算 | 高精度计算耗时、占用资源多 | 根据算子选择 FP16、BF16、FP8 等精度 |
| 算子融合（Kernel Fusion） | 多个算子之间频繁启动内核、读写中间张量 | 将多个操作合并执行，减少启动和内存访问开销 |
| FlashAttention | 注意力计算的中间矩阵读写量过大 | 分块计算，降低高带宽显存与片上存储之间的数据交换 |
| 内核调优与自动选择 | 通用算子未充分利用特定 GPU 或加速器 | 针对形状、精度和硬件选择更合适的执行内核 |
| CUDA Graph 等执行图技术 | 高频小算子调用的 CPU 调度和启动开销较高 | 捕获并重放执行序列，降低重复调度开销 |
这里有一个重要原则：优化的不是 FLOPS 数字本身，而是有效硬件利用率。
如果算子受内存带宽限制，即使提高理论计算能力，也不一定能提升实际速度；如果算子太小、启动开销占比很高，融合或执行图可能比单纯提高算力更有效。
3. 内存与缓存层：减少重复计算和显存浪费
核心问题：大模型参数和上下文占用显存巨大，GPU 等待数据，长上下文和高并发难以承载。
| 关键技术 | 解决什么问题 | 典型价值 |
|---|---|---|
| KV Cache | 每生成一个 Token 都重复计算历史 Token 的 Key、Value | 缓存历史注意力状态，避免重复计算 |
| PagedAttention | KV Cache 连续分配造成显存碎片、预留浪费 | 按块管理 KV Cache，提高显存利用率与并发容量 |
| Prefix Caching | 多个请求重复使用相同系统提示词或前缀 | 复用公共前缀的计算结果，降低重复 Prefill 开销 |
| GQA / MQA | KV Cache 容量和读取带宽过高 | 减少 Key/Value 头数，降低缓存占用和访问压力 |
| CPU / SSD Offload | GPU 显存不足以容纳全部模型或缓存 | 将部分数据放到其他存储层；代价是传输延迟和带宽开销 |
以 KV Cache 为例，假设模型处理了一段很长的对话。没有缓存时，生成新 Token 需要重新计算历史序列对应的注意力状态；有缓存时，历史状态可以复用，只需处理新增 Token 及其与历史状态的交互。
但需要注意：KV Cache 不能消除长上下文的所有计算成本。 它主要避免重复计算历史状态，同时仍然需要读取历史 KV 并执行注意力计算。
4. 推理服务层：提高 GPU 的有效负载
核心问题：用户请求到达时间不一致、输入长度差异很大，GPU 容易出现空闲、排队或资源分配不均。
| 关键技术 | 解决什么问题 | 主要收益 |
|---|---|---|
| 动态批处理（Dynamic Batching） | 单个请求无法充分利用 GPU | 将多个请求合并执行，提升吞吐 |
| 连续批处理（Continuous Batching） | 传统批次必须等待所有请求结束才能补充新请求 | 请求完成后立即引入新请求，提高 GPU 利用率 |
| Prefill / Decode 分离 | 输入处理和逐 Token 生成的计算特征不同 | 分别调度和扩缩容，降低阶段之间的资源干扰 |
| Chunked Prefill | 长输入一次性处理会阻塞正在生成的请求 | 将长输入分块处理，改善延迟和调度公平性 |
| 负载均衡与请求路由 | 不同实例的上下文长度、缓存占用和负载不均 | 将请求分配到更合适的实例，改善尾延迟和资源利用率 |
特别要区分两个指标：
-
TTFT（Time To First Token）： 从请求进入系统到返回第一个 Token 的时间，受排队、输入处理和调度影响。
-
TPOT（Time Per Output Token）： 生成阶段每个输出 Token 的平均耗时，反映用户感受到的持续生成速度。
连续批处理通常着重提升整体吞吐与 GPU 利用率，但不保证所有请求的 TTFT 和 TPOT 都下降。高并发下仍需在排队、批次大小、显存占用和服务等级之间做权衡。
连续批处理通常着重提升整体吞吐与 GPU 利用率，但不保证所有请求的 TTFT 和 TPOT 都下降。高并发下仍需在排队、批次大小、显存占用和服务等级之间做权衡。
5. 分布式与集群层：突破单卡的容量和性能上限
核心问题：模型放不进单卡、单卡算力不够，或者单机服务无法满足整体请求规模。
| 关键技术 | 解决什么问题 | 代价或限制 |
|---|---|---|
| 张量并行（TP） | 单卡无法容纳或高效计算大型矩阵 | 需要跨卡通信；小批量下通信开销可能抵消收益 |
| 流水线并行（PP） | 模型层数太多，难以放入单卡或单个设备组 | 可能产生流水线气泡和阶段间等待 |
| 专家并行（EP） | MoE 模型包含大量分布式专家 | 专家计算分散到多卡，需处理路由和 All-to-All 通信 |
| 数据并行与副本扩展 | 单实例吞吐无法满足请求总量 | 增加模型副本；受到显存、通信、成本及负载分布限制 |
| Prefill / Decode 解耦部署 | 输入计算与生成计算相互争抢资源 | 可独立扩容和优化，但需要传输 KV Cache 并管理跨池调度 |
这些技术解决的问题并不相同：张量并行主要拆分单层计算，流水线并行主要拆分模型层，数据并行主要复制模型处理更多请求，而 Prefill / Decode 解耦主要针对两种不同计算阶段的资源匹配。
四、大语言模型推理中，为什么优化重点会发生变化？
LLM 推理可以分为两个主要阶段，这也是理解现代推理优化技术的关键。
refill：输入处理阶段
将用户输入的 Prompt 并行处理，计算各层隐藏状态并建立 KV Cache。
-
主要瓶颈：大规模矩阵计算、长输入处理、排队等待。
-
重点技术：批量矩阵计算、FlashAttention、Chunked Prefill、前缀缓存。
-
主要目标：降低 TTFT、提高输入处理吞吐。
Decode：逐 Token 生成阶段
模型反复生成下一个 Token，并持续读取权重和历史 KV Cache。
-
主要瓶颈：自回归串行依赖、显存带宽、KV Cache 访问。
-
重点技术：权重量化、KV Cache 优化、连续批处理、投机解码。
-
主要目标：降低 TPOT、提高生成吞吐。
这解释了为什么不存在一种适用于所有场景的最优优化技术：
-
输入很长、输出很短：通常需要重点优化 Prefill。
-
输入较短、输出很长：通常需要重点优化 Decode。
-
并发很高：需要重点关注批处理、显存容量和请求调度。
-
模型无法放入单卡：需要先解决量化、模型切分和分布式部署问题。
| 年份 | 代表技术 / 里程碑 | 主要解决的问题 |
|---|---|---|
| 2015 | 知识蒸馏（Knowledge Distillation） | 大模型部署成本高，通过小模型学习大模型的输出行为 |
| 2016--2018 | 整数量化、移动端推理优化 | 模型体积大、移动端算力和内存受限 |
| 2017 | Transformer | 建立现代大语言模型的核心架构，为后续推理优化奠定基础 |
| 2018 | TensorRT、ONNX 等推理部署技术逐步发展 | 模型框架与硬件执行之间缺乏高效、可移植的部署路径 |
| 2018--2019 | 混合精度、模型并行、TensorRT 优化 | 提高硬件利用率，突破单设备计算和内存限制 |
| 2019 | MQA（Multi-Query Attention）、Megatron-LM 张量并行 | 减少 KV 状态规模；支持 Transformer 跨 GPU 拆分 |
| 2020--2021 | 编译器优化、自动调优、结构化剪枝等持续发展 | 降低算子执行开销，减少冗余计算 |
| 2022 | FlashAttention | 减少注意力计算的显存读写和中间矩阵开销 |
| 2022 | LLM.int8()、GPTQ、SmoothQuant | 让大模型低精度推理更可行，降低显存与带宽成本 |
| 2022 | Orca、迭代级调度 | 缓解静态批处理等待整批请求结束造成的 GPU 空闲 |
| 2022--2023 | GQA、FlashAttention-2 | 减少 KV Cache 压力，提升注意力算子的执行效率 |
| 2023 | AWQ、GGUF 低比特量化生态 | 改善低比特量化效果，降低本地部署的硬件门槛 |
| 2023 | vLLM、PagedAttention | 缓解 KV Cache 内存碎片与分配浪费，提高并发服务能力 |
| 2023 | 投机解码（Speculative Decoding） | 减少目标模型逐 Token 串行执行的开销 |
| 2023--2024 | FP8 推理与硬件低精度计算普及 | 在适配硬件上提升计算效率、降低数据存储和搬运成本 |
| 2024 | Chunked Prefill、Sarathi-Serve | 减少长输入处理对其他生成请求的阻塞 |
| 2024 | SGLang、RadixAttention、前缀缓存 | 复用重复前缀计算，优化复杂请求的缓存管理 |
| 2024 | Medusa、EAGLE 等投机生成方法 | 提高候选 Token 的接受效率，进一步加速生成 |
| 2024 | DistServe、Splitwise 等 Prefill/Decode 分离架构 | 缓解输入处理与生成阶段之间的资源争抢 |
| 2024--2025 | 大规模 MoE 推理优化、专家并行 | 通过稀疏激活降低每个 Token 的计算量，同时管理分布式专家通信 |
| 2025 | vLLM 新一代引擎、FlashInfer 等优化库 | 将缓存、调度与注意力内核优化整合为更高效的执行系统 |
| 2025--2026 | KV Cache 池化、跨实例缓存复用、异构调度持续发展 | 降低多实例重复缓存和资源碎片，提升集群级资源利用率 |
二、按技术演进阶段理解历史
2015--2021
第一阶段：让模型能够高效部署
关键词：蒸馏、量化、剪枝、编译器、并行计算。
核心矛盾是模型规模与设备资源之间的矛盾，重点是减小模型、减少冗余、提高硬件执行效率。
2022
第二阶段：针对大模型计算与内存瓶颈优化
关键词：FlashAttention、LLM.int8()、GPTQ、SmoothQuant、Orca。
大模型推理开始同时面临注意力内存访问、低精度计算和动态请求调度问题。
2023
第三阶段：围绕 KV Cache 与生成速度重构推理服务
关键词：vLLM、PagedAttention、AWQ、投机解码、连续批处理。
优化重点从单个算子的速度，扩展到显存管理、并发调度和自回归生成效率。
2024
第四阶段：针对长上下文与异构负载优化
关键词：Chunked Prefill、前缀缓存、EAGLE、Prefill/Decode 分离。
核心矛盾转向长短请求混合、输入和生成资源冲突、重复上下文计算，以及首 Token 延迟与生成速度的平衡。
2025--2026
第五阶段：推理引擎与集群协同优化
关键词：统一内核库、跨实例 KV Cache、分离式部署、异构资源调度。
优化对象逐步从单卡、单模型、单实例扩展到整个推理集群的吞吐、延迟和成本。
三、从历史中提炼出的三个关键判断
-
2015--2021 年的技术并没有过时。 量化、蒸馏、编译器和并行计算仍然是现代推理系统的基础，只是面对 LLM 时有了新的实现方式。
-
2022--2023 年是现代 LLM 推理系统的重要转折点。 FlashAttention 重点解决注意力的内存访问问题；PagedAttention 重点解决 KV Cache 管理问题；投机解码则直接针对逐 Token 生成的串行限制。三者优化的是不同瓶颈。
-
2024 年以后，系统级协同的重要性明显提升。 当单个算子已经足够快时，长上下文、请求排队、跨卡通信、缓存复用与资源调度可能成为主要瓶颈。继续优化需要从单点加速转向全链路优化。
因此，如果要制作一张适合技术汇报的演进图，建议将横轴设置为年份，将纵向划分为五条技术路线：模型压缩、算子与硬件、缓存与内存、生成算法、推理服务与集群架构。这样既能体现历史先后关系，也能避免把不同类别的技术误认为相互替代的关系。