LLM 推理优化技术全景

本页系统讲解 LLM 应用生态概览中”部署运行”层的核心技术栈——LLM 推理优化。如果你刚接触这个领域，建议先读入门版 LLM 推理优化；本页是面向工程师的深度技术版，从算法层的投机解码，到计算层的 Flash Attention、调度层的 PagedAttention 与 Chunked Prefill、架构层的分离式推理，再到存储层的量化，覆盖 2023–2025 年的前沿进展。这些技术叠加起来才能让大模型在生产环境跑得又快又省。

核心直觉

推理优化 = 把大模型当一条流水线，从”算法—计算—调度—缓存—存储”五层逐层榨干效率。

KV Cache（键值缓存）：把已经算过的中间结果存起来，避免每生成一个词就重算一遍——用空间换时间的核心机制。
Flash Attention（闪速注意力）：注意力计算不省算力，省的是显存搬运——把大矩阵分块在小快内存里算，用”在线 softmax”技巧避免实例化完整注意力矩阵，将注意力显存从 $O(N^2)$ 降到 $O(N)$ 。
PagedAttention（分页注意力）：借鉴操作系统虚拟内存的分页思想，把 KV Cache 切成小块按需分配，消除碎片、提升显存利用率。
Continuous Batching（连续批处理）：请求不用等齐，谁算完谁先走、新请求随时插队，把 GPU 利用率拉满。
Chunked Prefill（分块预填充）：把长 prompt 切成等长小块，与 decode 请求”搭车”混批，让 prefill 的算力和 decode 的带宽都不浪费。
Speculative Decoding（投机解码）：用轻量模型先跑草稿、大模型批量验收，在不改变结果的前提下减少大模型串行次数。
Quantization（量化）：用更少位数（4-bit/8-bit）存权重与激活，显存和带宽同步下降，代价是精度的小幅损失。

原理详解

推理的两个阶段：Prefill 与 Decode

LLM 推理分为两个阶段，性能瓶颈截然不同：

Prefill（预填充）阶段：处理输入 prompt，一次性并行计算所有 token 的 KV 并缓存。这一步是计算密集型（compute-bound）的——大量矩阵乘法把 GPU 算力跑满，但只执行一次。对应的延迟指标是 TTFT（Time To First Token，首 token 延迟）。
Decode（解码）阶段：逐个生成输出 token，每步只处理一个新 token，但要读取之前全部的 KV Cache。这一步是访存密集型（memory-bound）的——计算量极小（只做一次矩阵-向量乘），但每次都要把巨大的 KV Cache 从 HBM（高带宽显存）搬进计算单元，GPU 算力大量闲置。对应的延迟指标是 TPOT（Time Per Output Token，单 token 延迟）。

Roofline 模型——判断计算还是访存是瓶颈的利器。定义算术强度（Arithmetic Intensity, AI）= 计算量 (FLOPs) ÷ 访存量 (Bytes)。GPU 的峰值算力为 $P$ (FLOPs/s)，峰值带宽为 $B$ (Bytes/s)，则拐点为 $P/B$ 。当 $AI > P/B$ 时，瓶颈在计算（计算密集）；当 $AI < P/B$ 时，瓶颈在带宽（访存密集）。以 A100 为例：FP16 峰值 312 TFLOPs/s，带宽 2.0 TB/s，拐点 $\approx$ 156 FLOPs/Byte。Decode 阶段每生成一个 token，算术强度约为 1–2 FLOPs/Byte，远低于拐点，是典型的访存受限。

绝大多数推理优化都围绕”如何让 Decode 阶段不再被访存卡脖子”展开。这也是为什么 KV Cache 与 Flash Attention 如此关键。

KV Cache

自回归生成中，每生成第 $t$ 个 token，注意力需要用到前 $t-1$ 个 token 的 Key 和 Value。如果每步都重算，复杂度随序列长度二次增长。KV Cache 把每层、每个头已计算出的 K、V 存下来，下一步直接复用，把每步计算降为线性复杂度。

代价是显存占用巨大：

KV Cache 大小公式：
$KV\ Cache = 2 \times n_{layers} \times n_{kv\_heads} \times d_{head} \times seq\_len \times batch\_size \times dtype\_bytes$
其中 $2$ 是因为需要存 K 和 V 两个张量。以 Llama-2-70B 为例（80 层、64 个 KV 头、 $d_{head}=128$ 、FP16），batch=1、seq=4K 时 KV Cache $\approx$ 10.5 GB；seq=128K 时暴增至 336 GB——远超模型权重本身的 140 GB。使用 GQA（Grouped Query Attention，分组查询注意力，用少量 KV 头服务大量查询头）可以将 KV 头数从 64 压到 8，KV Cache 缩减到原来的 1/8。详见 Llama 系列。

如何高效管理这块缓存（减少碎片、按需分配）正是 PagedAttention 要解决的问题。

Flash Attention 深度剖析

Flash Attention 是 IO 感知的注意力实现，是当前几乎所有高性能推理引擎的基石。下面从问题出发，逐步拆解其核心思想。

标准注意力的问题

标准注意力（naive attention）计算 $\text{Softmax}(QK^T) \times V$ 。中间产物注意力分数矩阵 $S = QK^T$ 的大小为 $N \times N$ （N 为序列长度），需要完整写入 HBM 再读回来做 softmax 再乘 V——反复读写这个 $O(N^2)$ 的矩阵成为瓶颈。例如序列长度 8K 时，FP16 下分数矩阵单份就有 1 GB，来回读写极慢。

根本矛盾在于：GPU 的计算单元（Tensor Core）极快，但数据要从 HBM 搬到片上 SRAM 才能计算，而 SRAM 极小（A100 上只有 192 KB/SM）。标准算法把整个 $N \times N$ 矩阵在 HBM 和 SRAM 间来回搬运，瓶颈在 IO 而非算力。

分块算法（Tiling）

Flash Attention 的核心洞察：不需要把整个注意力矩阵实例化到 HBM。算法将 Q、K、V 沿序列维度分成小块（block），每次只加载 Q 的一个块和 K、V 的一个块到 SRAM，在片上完成计算后直接输出结果到 HBM，中间的注意力分数矩阵从不落盘到 HBM。

分两重循环：

外层循环遍历 Q 的块（固定一个 Q 块 $Q_i$ ）。
内层循环遍历 K、V 的块（依次加载 $K_j, V_j$ ）。

对每个 $(Q_i, K_j)$ 对，在 SRAM 中计算 $S_{ij} = Q_i \times K_j^T$ ，做 softmax，乘 $V_j$ ，累加到输出 $O_i$ 。最终 $O_i$ 直接写回 HBM——全程不需要在 HBM 中存储完整的 $N \times N$ 矩阵。

但这里有一个关键障碍：softmax 需要先知道整行的最大值才能做数值稳定的归一化。如果逐块计算 $S_{ij}$ ，怎么知道整行的 max？这就是”在线 softmax”要解决的。

在线 Softmax（Online Softmax）

标准 softmax 的数值稳定公式是 $\text{softmax}(x_i) = \frac{\exp(x_i - m)}{\sum \exp(x_j - m)}$ ，其中 $m = \max(x)$ 。这要求先扫描整行求 max，再扫描一次求 sum，再扫描一次做除法——三遍扫描，且必须看到完整的行。

在线 softmax（也叫 incremental / running softmax）巧妙地将这个计算拆成可增量更新的形式：维护两个运行量——当前行最大值 $m$ 和当前行指数和 $l$ 。每处理一个新的分数块 $S_{ij}$ 时：

计算本块最大值 $m_{new} = \max(m_{old}, \max(S_{ij}))$ 。
修正之前的累加和： $l_{new} = l_{old} \times \exp(m_{old} - m_{new}) + \sum \exp(S_{ij} - m_{new})$ （乘以 $\exp(m_{old} - m_{new})$ 是为了把之前已累加的值重新缩放到以 $m_{new}$ 为基准）。
对输出 $O_i$ 做同样的重缩放： $O_{new} = O_{old} \times \frac{l_{old} \times \exp(m_{old} - m_{new})}{l_{new}} + \frac{\sum \exp(S_{ij} - m_{new}) \times V_j}{l_{new}}$ 。

这样每来一个 K/V 块就能增量更新，最终得到的 $O_i / l$ 就是精确的 softmax 结果。整个过程只需一遍扫描，且中间结果完全在 SRAM 中维护，不损失精度。

Flash Attention v2 的改进

Flash Attention v2（2023）在 v1 基础上优化了并行度和非矩阵运算占比：

减少非矩阵 FLOPs：v1 的在线 softmax 重缩放引入了额外乘法；v2 重新组织计算流程，把重缩放推迟到最后一步，减少了中间乘法次数。GPU 上矩阵乘（matmul）效率远高于逐元素运算，让尽量多的计算落在 matmul 上。
更好的并行划分：v1 沿 batch 和 head 维度并行，序列维度串行；v2 增加了沿序列维度（Q 块之间）的并行，更充分地利用 GPU 的多 SM 并行能力。这对长序列尤其重要。

Flash Attention v3：Hopper 架构深度优化

Flash Attention v3（2024，Tri Dao）专门针对 NVIDIA Hopper 架构（H100 GPU）设计，引入三项关键技术：

异步重叠（Asynchrony via Warpgroup Specialization）：Hopper 引入了 TMA（Tensor Memory Accelerator，张量内存加速器，硬件级的异步数据搬运单元）和 WGMMA（Warp Group Matrix Multiply-Accumulate， warp 组级别的异步矩阵乘指令）。FA3 将 GPU 上的 warp 分为生产者（负责用 TMA 异步从 HBM 加载 Q/K/V 块到共享内存）和消费者（负责用 WGMMA 做矩阵乘），两者通过异步信号重叠执行——数据搬运和计算真正并行起来，隐藏了内存延迟。
** softmax 与 matmul 交错（Interleaving）**：在 WGMMA 矩阵乘还在执行时，用另一个 warp 组并行做在线 softmax 的归约计算（max、sum、重缩放），进一步重叠计算。
FP8 低精度支持：Hopper 原生支持 FP8（E4M3/E5M2）张量核心计算。FA3 采用分块量化（block-wise quantization）+ 不相干处理（incoherent processing，用量化后的随机旋转矩阵分散误差），在 FP8 下达到接近 FP16 的精度。

性能数据：FA2 在 H100 上仅达到 35% 利用率（~400 TFLOPs/s）；FA3 在 FP16 下达到 740 TFLOPs/s（75% 利用率），FP8 下接近 1.2 PFLOPs/s——相对 FA2 加速 1.5–2.0 倍，且 FP8 的数值误差比朴素 FP8 实现低 2.6 倍。

内存复杂度： $O(N^2) \to O(N)$

标准注意力的 HBM 访问量为 $O(N^2 \cdot d)$ （反复读写注意力矩阵），显存占用为 $O(N^2)$ 。Flash Attention 将中间注意力矩阵完全留在 SRAM 中计算，HBM 访问量降为 $O(N \cdot d \cdot M)$ （M 为块大小，远小于 N），显存占用从 $O(N^2)$ 降为 $O(N)$ ——这是长上下文推理成为可能的根本前提。

PagedAttention（vLLM）

KV Cache 的传统管理方式是给每个请求预分配一整块连续显存（按最大长度预留），导致严重的内部碎片（请求没用到最大长度时浪费）和外部碎片。vLLM 的 PagedAttention 借鉴操作系统虚拟内存分页思想：

把 KV Cache 切成固定大小的”块”（block，类似内存页，通常存 16 个 token 的 KV）。
每个请求用一个”块表”（block table）做逻辑到物理的映射，逻辑上连续的 token 序列可以映射到物理上分散的块——按需分配、用多少分多少，几乎零碎片。
块可以在请求间共享（例如 beam search 的多条候选共享前缀），进一步提升利用率。

这让显存利用率从传统方案的 20–40% 提升到接近 100%，能并发服务更多请求，是 vLLM 高吞吐的基础。

Continuous Batching（连续批处理）

传统批处理要等一批请求全部生成完才一起返回，长尾请求拖慢整批。Continuous Batching（也叫 iteration-level / dynamic batching）改为逐 token 调度：每个解码步都重新组批——已完成的请求立即移出、把空出的位置给新请求。这样 GPU 始终被填满，没有”空转等长尾”的浪费，吞吐显著提升。配合 PagedAttention，vLLM 能做到接近理论峰值的吞吐。

Chunked Prefill：解决 Prefill 与 Decode 的互相干扰

问题：Prefill 与 Decode 为何”打架”

Prefill 是计算密集的，Decode 是访存密集的。当它们在同一个 batch 中执行时：

如果 batch 中混有 prefill 请求，GPU 算力被 prefill 占满，decode 请求被”挤出”调度窗口，延迟飙升。
如果只跑 decode，GPU 算力大量闲置（decode 算术强度极低），浪费算力。
单个长 prompt 的 prefill 耗时很长（如 4K token 的 prompt 可能需要数百毫秒），在此期间整个 batch 的所有 decode 都被阻塞。

SARATHI 的解决方案

SARATHI（2023）提出两个关键技术：

Chunked Prefills（分块预填充）：把一个长 prompt 的 prefill 拆成多个等大的 chunk（如每 chunk 512 token），每个 chunk 单独做一次前向。这样长 prompt 不再一次性阻塞整个 batch，而是分摊到多个迭代步中。
Decode-Maximal Batching（解码最大化批处理）：每个 batch 由一个 prefill chunk（占满 GPU 算力）+ 尽可能多的 decode 请求（“搭车”/piggybacking）组成。prefill chunk 提供计算量，decode 请求搭便车几乎不增加额外计算成本（因为 decode 是访存密集的，用的是 prefill 不需要的带宽资源）。

效果：LLaMA-13B 在 A6000 上 decode 吞吐提升最高 10 倍，端到端吞吐提升 1.33 倍；LLaMA-33B 在 A100 上 decode 吞吐提升 4.25 倍。

工业界落地

vLLM 从 0.4.x 版本开始内置 chunked prefill 支持（通过 --enable-chunked-prefill 参数开启）。SGLang 同样默认采用类似的调度策略。这使得在高并发场景下 TTFT 更稳定、decode 延迟更低。

分离式推理（Disaggregated Inference）

Chunked Prefill 在单机内缓解了 prefill/decode 干扰，但两者的资源需求本质上是矛盾的：prefill 需要高算力（计算密集），decode 需要高带宽（访存密集）。分离式推理（disaggregated inference）走得更远——把 prefill 和 decode 彻底分离到不同的 GPU 池。

Mooncake（Moonshot AI）

Mooncake 是 Moonshot AI 的生产级推理平台（服务 Kimi），采用 KVCache-centric Disaggregated Architecture：

分离的 Prefill 池与 Decode 池：prefill 请求发到 prefill 节点（配置高算力 GPU），decode 请求发到 decode 节点。两个池独立扩缩容，分别优化。
KVCache 中心化：prefill 完成后，KV Cache 通过高速网络传输到 decode 节点。Mooncake 还利用 GPU 节点上闲置的 CPU、DRAM、SSD 构建分层 KV Cache 池（GPU → DRAM → SSD），实现缓存复用与长上下文场景下的高效调度。
预测式早拒绝：面对过载场景（请求超出处理能力），Mooncake 根据预测提前拒绝部分请求，保证已接受请求的 SLO。

效果：在长上下文场景模拟中，吞吐提升最高 525%；实际生产负载下处理请求数增加 75%。

Splitwise（Microsoft）

Splitwise 提出相同的核心思路但侧重硬件异构：

prefill 阶段需要最新 GPU 的强大算力，decode 阶段不需要——decode 的计算量极小，可以用更便宜、功耗更低的硬件。
prefill 节点与 decode 节点之间通过 GPU 集群的高速背板互联（如 NVLink、InfiniBand）传输 KV Cache。

效果：相比传统同构集群，吞吐提升 1.4 倍且成本降低 20%；或相同成本和功耗下吞吐提升 2.35 倍。

为什么有效

分离式推理的核心逻辑在于资源匹配：prefill 榨干算力、decode 榨干带宽，两者不再互相妥协。代价是 prefill 到 decode 之间的 KV Cache 传输开销（需要高速互联网络），以及对全局调度器更高的要求（需要平衡两个池的负载、处理 KV 传输）。

高级投机解码（Advanced Speculative Decoding）

基本原理见解码策略与采样，此处聚焦 2024–2025 年的算法前沿。

标准投机解码用一个独立的小模型（draft model）自回归生成候选序列，再让大模型并行验证。痛点是：小模型和大模型的表示空间不一致，导致接受率（acceptance rate）不高，且小模型本身也有不可忽略的推理开销。2024 年以来的工作从不同角度解决了这些问题。

EAGLE：基于隐藏状态的投机

EAGLE 的核心洞察：特征层（feature level）的自回归比 token 层更简单。大模型倒数第二层的隐藏状态已经包含丰富的语义信息，从中预测下一步的特征比从 token ID 预测更容易。

EAGLE 的做法：

训练一个轻量的draft head（单层 Transformer + 投影），输入是大模型倒数第二层的隐藏状态（而非 token embedding），输出下一步的隐藏状态预测。
这个 draft head 自回归地连续预测多个隐藏状态，再映射回 token 做验证。
关键技巧：draft head 的输入包含”时间步前移一步的 token 序列”（即把已知 token 偏移一位），有效消除特征预测的不确定性。

效果：在 LLaMA-2-Chat 70B 上，延迟加速 2.7–3.5 倍，吞吐翻倍，且生成分布完全无损。

EAGLE-2 引入动态草稿树：根据 draft head 每步输出的置信度（概率分布）动态调整候选树结构，高置信度的分支多扩展、低置信度的早剪枝，进一步提升了有效接受 token 数。

EAGLE-3 进一步改进了训练目标和特征利用方式，在更小的开销下实现了更高的接受率。

Medusa：多头并行预测

Medusa 不训练独立的小模型，而是在大模型最后一层之上添加多个预测头（extra heads），每个头独立预测未来第 1、2、3… 个位置的 token（类似多头预测）。验证阶段用树注意力（tree attention）——把多条候选路径组织成树结构，一次前向并行验证所有候选。

Medusa 的优势是不需要单独的 draft 模型（额外参数极少），且多头的训练成本很低。典型加速 2–3 倍。

Lookahead Decoding：无需草稿模型

Lookahead Decoding 基于 Jacobi 迭代（Jacobi iteration）：从当前 token 出发，用大模型自身并行猜测未来 n 个 token（n-gram 风格），再验证。完全不需要 draft 模型或额外训练——直接复用大模型自身。代价是并行猜测的准确率低于专门的 draft head，但在结构化输出（如 JSON）等场景表现良好。

接受率与加速比分析

假设大模型每次前向验证 $\gamma$ 个候选 token，平均接受 $k$ 个（ $k \leq \gamma$ ），则：

加速比 $\approx k + 1$ （验证通过的 $k$ 个 + 大模型自行生成的 1 个，共 $k+1$ 个 token / 每次大模型前向）

如果不使用投机解码，每次前向只产出 1 个 token，因此加速比 = $k+1$ 。但由于验证步骤本身也有开销（处理 $\gamma$ 个而非 1 个 token），实际加速比会打折扣。

EAGLE 系列在代码生成等任务上 $k$ 可达 3–4，对应 3–5 倍加速；对话任务上 $k$ 通常为 2–3。

Prefix Caching 与 RadixAttention

在多轮对话、few-shot、RAG（见 RAG）等场景中，大量请求共享相同的前缀（system prompt、few-shot 示例等）。Prefix Caching 把已计算的前缀 KV Cache 缓存起来，新请求命中时直接复用，跳过 prefill。

SGLang 的 RadixAttention

SGLang 用基数树（Radix Tree，一种压缩前缀树）组织所有已缓存的前缀 KV：

每个树节点对应一段 token 序列，存储其 KV Cache。
新请求到来时，从根节点遍历树，找到最长公共前缀——命中部分直接复用 KV，未命中部分才需要 prefill。
树节点带有引用计数和 LRU（最近最少使用）淘汰策略，在显存不足时自动回收。

效果：对于共享 system prompt 的多轮对话和 few-shot 场景，吞吐提升最高 6.4 倍（相比无前缀缓存的基线）。

CUDA Graphs：消除 Kernel 启动开销

Decode 阶段每步执行大量小 CUDA kernel（矩阵乘、激活、归一化等），每个 kernel 的 CPU 端启动开销约 5–10 微秒，累积起来成为可观的延迟——尤其是 batch size 较小时，计算时间可能只有几十微秒，kernel 启动开销占比极高。

CUDA Graphs 的做法：预先录制一次 decode 前向的完整 kernel 序列（包括输入/输出地址），之后每步只需重放（replay）整个图——一次 API 调用替代数千次 cudaLaunchKernel，消除逐 kernel 启动开销。vLLM、TGI 等引擎在 decode 路径上默认启用 CUDA Graphs，对小 batch decode 延迟改善可达 20–40%。

MoE 推理优化

Mixture of Experts（MoE，混合专家模型）如 Mixtral 8x7B、DeepSeek-V3 等用稀疏激活提升参数量而不等比增加计算量。但 MoE 在推理时面临独特挑战：

显存占用：所有专家的权重都要常驻显存，即使每个 token 只激活 2 个专家。Mixtral 8x7B 总参数 47B 但每 token 只算 13B 的 FLOPs——大量参数是”死重”，白白消耗显存。
路由开销：每个 token 要经过 gate 网络计算路由（选哪几个专家），再分发计算，引入额外延迟和 kernel 开销。
负载均衡：实际推理中 token 分布不均，某些专家被频繁调用（热点），其他专家闲置——导致 GPU 利用率不均衡。serving 时需要全局调度（跨请求重组 batch）来平衡。

优化策略：

Expert Offloading（专家卸载）：把不常用的专家权重放在 CPU 内存或 SSD 上，按需加载到 GPU。需要精确预测哪些专家会被激活（pre-gating）并提前预取（prefetch），用计算掩盖传输延迟。
Expert Quantization（专家量化）：MoE 的稀疏性使得每 token 只用少量专家，量化带来的精度损失被稀释，因此 MoE 对量化更友好——INT4 量化的 DeepSeek-V3 等模型精度损失极小。
Batch 重组：将路由到同一组专家的 token 聚集在一起执行，减少 kernel 分发次数。

量化：GPTQ / AWQ / GGUF

量化把权重（和部分激活）从 FP16 压到 8-bit 或 4-bit，显存和带宽双减，是降本增效的存储层手段。三大主流方案：

GPTQ：后训练量化（PTQ），基于二阶信息（Hessian 矩阵的近似）逐层最小化量化误差，通常把权重压到 4-bit，精度损失小。适合服务端 GPU 部署。
AWQ（Activation-aware Weight Quantization）：观察发现并非所有权重同等重要——激活幅度大的通道对应的权重更敏感。AWQ 给这些”重要通道”的权重更高保护（per-channel scaling），从而在 4-bit 下保持精度，推理速度快且效果稳健。
GGUF（原 GGML）：llama.cpp 生态的量化格式，支持多种位宽（如 Q4_K_M），并支持 CPU 与 GPU 混合推理（部分层放 GPU、其余放 CPU）。它是边缘、消费级、离线部署的主流格式。详见小模型与端侧部署。

量化的代价是精度下降：4-bit 通常掉 1–3 个评测点，但对多数应用可接受；对精度敏感的任务可退到 8-bit 或用 QLoRA 微调补偿，见 PEFT 方法。

推理引擎对比（2025）

引擎	开发方	核心优势	典型场景	硬件支持
vLLM	UC Berkeley	PagedAttention + Continuous Batching + Chunked Prefill，社区生态最强	通用 API 服务、高并发	NVIDIA / AMD
SGLang	UC Berkeley / LMSYS	RadixAttention 前缀缓存 + 结构化生成 + 多模态	多轮对话、Agent、结构化输出	NVIDIA / AMD
TensorRT-LLM	NVIDIA	针对 Hopper/Ada 架构极致优化，FP8 推理，in-flight batching	追求极致吞吐的 NVIDIA 环境	NVIDIA only
TGI	HuggingFace	开箱即用、模型兼容性广、集成 Rust 推理服务器	企业级部署、快速原型	NVIDIA / AMD
DeepSpeed-FastGen	Microsoft	Dynamic Splitfuse（类似 chunked prefill），与 DeepSpeed 训练生态整合	训推一体的场景	NVIDIA

选型经验（2025 年实践）：通用部署首选 vLLM（生态最成熟）；多轮对话和 Agent 场景 SGLang 的 RadixAttention 优势明显；纯 NVIDIA 环境 + 极致性能选 TensorRT-LLM；需要快速部署多种模型选 TGI。

原理图解

推理优化技术栈分层

推理两阶段与瓶颈

动手实践

# 用 vLLM 高吞吐部署 Llama 模型（PagedAttention + Continuous Batching 内置）
from vllm import LLM, SamplingParams

# 加载 AWQ 4-bit 量化模型，开启吞吐优化
llm = LLM(model="TheBloke/Llama-2-13B-AWQ", quantization="awq",
          dtype="float16", gpu_memory_utilization=0.9,
          enable_chunked_prefill=True)  # 开启 chunked prefill

# 批量推理：vLLM 自动连续批处理，吞吐远高于逐条生成
params = SamplingParams(temperature=0.7, top_p=0.9, max_tokens=128)
prompts = ["写一首关于秋天的诗", "解释什么是注意力机制", "用 Python 实现快排"]
outputs = llm.generate(prompts, params)  # 一次性提交多个请求
for o in outputs:
    print(o.outputs[0].text[:80])  # 打印每条结果前 80 字

# 用 SGLang 部署，自动启用 RadixAttention 前缀缓存（适合多轮对话）
# 启动服务: python -m sglang.launch_server --model-path meta-llama/Llama-2-7b-chat-hf --port 30000
from openai import OpenAI

client = OpenAI(base_url="http://localhost:30000/v1", api_key="any")
# 多轮对话中，system prompt 和历史消息的 KV 自动复用
messages = [
    {"role": "system", "content": "你是一个专业的 Python 工程师。"},  # 前缀缓存命中
    {"role": "user", "content": "解释装饰器。"},
]
resp = client.chat.completions.create(model="default", messages=messages)
print(resp.choices[0].message.content)

实践要点

先选对引擎再调参：通用高并发选 vLLM；多轮对话/Agent 选 SGLang；纯 NVIDIA + 极致性能选 TensorRT-LLM；边缘/单机/离线选 llama.cpp（GGUF），详见小模型与端侧部署。
长上下文尤其依赖 KV Cache 优化：128K 上下文下 KV Cache 体积可能超过权重本身，PagedAttention、GQA（见 Llama 系列）和 Flash Attention 的线性显存是必需。
量化优先 AWQ/GPTQ：4-bit AWQ 在多数基准上性价比最高；MoE 模型对量化尤其友好（稀疏激活稀释误差）；若可离线微调，用 QLoRA 补偿精度损失。
Chunked Prefill 推荐默认开启：长 prompt 场景下显著改善 TTFT 和 decode 延迟稳定性，vLLM/SGLang 已内置支持。
Prefix Caching 对多轮对话收益巨大：共享 system prompt 的场景，RadixAttention 可省去重复 prefill，TTFT 降低数倍，配合流式输出体验更佳。
Speculative Decoding 看 draft 匹配度：EAGLE 系列用隐藏状态做 draft，接受率高于独立小模型方案；接受率过低（平均接受 token 数 $k$ 不足 1）反而变慢，需针对实际 workload 评估。
分离式推理适用于超大规模集群：当日均请求量达到千万级、长上下文占比高时，prefill/decode 分离部署（Mooncake 式架构）的吞吐收益才能覆盖 KV 传输开销。

典型应用

API 服务高并发：用 vLLM 部署开源模型提供 OpenAI 兼容 API，配合 Continuous Batching、Chunked Prefill 与 PagedAttention 支撑高 QPS。
降本部署：70B 模型 AWQ 4-bit 量化后单张 80GB 显卡即可加载，配合 GQA 与 Flash Attention 把吞吐拉到可用水平。
多轮对话平台：SGLang 的 RadixAttention 自动复用 system prompt 和历史消息的 KV Cache，TTFT 降低 3–5 倍。
MoE 模型服务：DeepSeek-V3 等 MoE 模型用 INT4 量化 + 专家批重组，在有限硬件上实现高吞吐。
长文档处理：Flash Attention 线性显存 + PagedAttention 分页，让百万 token 上下文成为可能，支撑 RAG 与代码库级理解。
实时低延迟场景：EAGLE 投机解码 + CUDA Graphs，将 decode 延迟压到硬件极限，支撑实时流式输出。

典型类库与工具

类库	语言	说明
vLLM	Python	PagedAttention + Continuous Batching + Chunked Prefill 高吞吐推理引擎，服务端首选
SGLang	Python	RadixAttention 前缀缓存 + 结构化生成，多轮对话和 Agent 场景优势明显
TensorRT-LLM	C++/Python	NVIDIA 官方推理加速库，FP8 + in-flight batching，针对 Hopper/Blackwell 极致优化
TGI	Python/Rust	HuggingFace 文本生成推理服务，支持多种量化与投机解码
llama.cpp	C++	轻量推理框架，GGUF 量化，CPU/GPU 混合，边缘部署主力
AutoGPTQ / AutoAWQ	Python	GPTQ 与 AWQ 量化模型制作工具链
FlashAttention	CUDA/Python	IO 感知的注意力实现（v2/v3），被主流框架广泛集成
DeepSpeed-FastGen	Python	Dynamic Splitfuse 调度，与 DeepSpeed 训练生态整合

术语表

术语	英文	解释
键值缓存	KV Cache	缓存已计算的 Key/Value，避免重复计算，用空间换时间
闪速注意力	Flash Attention	分块计算 + 在线 softmax，减少显存读写的 IO 感知注意力实现
在线 softmax	Online Softmax	增量式 softmax 算法，维护运行 max 和运行 sum，使分块计算成为可能
分页注意力	PagedAttention	借鉴虚拟内存分页管理 KV Cache，消除碎片（vLLM 核心）
连续批处理	Continuous Batching	逐 token 动态组批，请求完成即移出、新请求随时加入
分块预填充	Chunked Prefill	把长 prompt 的 prefill 拆成小块，与 decode 请求混合调度
分离式推理	Disaggregated Inference	Prefill 与 Decode 分离到不同 GPU 池，分别针对算力和带宽优化
投机解码	Speculative Decoding	轻量模型起草、大模型批量验证的无损加速方法
基数树注意力	RadixAttention	用基数树组织 KV Cache 实现自动前缀复用（SGLang 核心）
算术强度	Arithmetic Intensity	计算量与访存量之比 (FLOPs/Byte)，用于判断计算/访存瓶颈
量化	Quantization	降低权重/激活位宽（4-bit/8-bit）以省显存与带宽
预填充	Prefill	处理输入 prompt 并生成 KV Cache 的计算密集阶段
解码	Decode	逐 token 生成的访存密集阶段
首 token 延迟	TTFT (Time To First Token)	从请求发出到第一个 token 返回的延迟
单 token 延迟	TPOT (Time Per Output Token)	生成每个输出 token 的平均时间
CUDA Graphs	CUDA Graphs	预录制 kernel 序列后重放，消除逐 kernel 启动开销