大语言模型的推理速度直接决定产品体验与服务成本。一个70B模型如果没有优化，单请求延迟可能高达数分钟。本文系统梳理2026年最主流的LLM推理加速技术，从原理到工程实践，帮助你把推理速度压到极致。

理解LLM推理的两个阶段在深入加速技术之前，先理解LLM推理的基本结构。LLM的文本生成分为两个阶段：预填充阶段（Prefill Phase）：处理所有输入token，计算每个token的KV（Key-Value）向量，并生成第一个输出token。这个阶段是并行的，所有输入token同时处理，GPU利用率高。解码阶段（Decode Phase）：自回归生成，每次只产生一个新token，然后将其加入上下文继续生成下一个。这个阶段是串行的，GPU利用率极低——每次只处理一个新token，但需要访问所有历史token的KV向量。推理加速的核心难题就在解码阶段：它是memory-bound（内存带宽受限），而非compute-bound（计算受限）。## KV Cache：最重要的基础优化每个Transformer层在自注意力计算时，需要计算Query与所有历史token的Key做点积，再加权求和Value。如果没有缓存，每次生成新token都要重新计算所有历史token的K和V，复杂度是O(n²)。KV Cache的做法很简单：把已计算过的Key和Value缓存起来，下次直接复用。这使得每次解码步骤只需计算新token的KV，复杂度降为O(n)。KV Cache的内存占用估算：KV Cache大小 = 2 × num_layers × num_heads × head_dim × seq_len × batch_size × dtype_bytes以LLaMA-3 70B为例：- 80层，64个注意力头，128维head_dim- 序列长度4096，批大小1，FP16- KV Cache ≈ 2 × 80 × 64 × 128 × 4096 × 1 × 2 = 约10.7GB这意味着KV Cache会消耗大量显存，这正是PagedAttention要解决的问题。## PagedAttention：像OS管理内存一样管理KV Cache传统实现中，KV Cache为每个请求预分配一块连续的显存，大小等于最大序列长度。这导致两个问题：1. 内部碎片：实际序列比最大长度短，预分配的显存被浪费2. 外部碎片：不同请求大小不同，空闲显存无法被充分利用vLLM的PagedAttention借鉴操作系统的虚拟内存和分页机制：物理KV Cache被分成固定大小的"页"（Block），每页存储固定数量token的KV每个请求维护一个"页表"，记录其token到物理页的映射这样的好处：- 几乎零内存碎片（内部碎片最大为一页大小）- 支持高效的KV Cache共享（多个请求可以共享同一段前缀的KV Cache）- 显著提升GPU内存利用率，从而支持更大的批大小python# vLLM使用示例from vllm import LLM, SamplingParamsllm = LLM( model="meta-llama/Meta-Llama-3-70B-Instruct", tensor_parallel_size=4, gpu_memory_utilization=0.90, # 留10%给系统 max_model_len=8192, block_size=16, # 每个KV Cache页存储16个token)sampling_params = SamplingParams(temperature=0.8, max_tokens=512)outputs = llm.generate(prompts, sampling_params)## 投机解码（Speculative Decoding）：用小模型加速大模型投机解码是2023-2024年最重要的推理加速突破之一。核心思想：用一个小的草稿模型（Draft Model）快速生成多个候选token，再用目标大模型一次性验证所有候选。工作流程：1. 草稿模型自回归生成K个候选token（如K=5）2. 目标大模型并行处理这K个token（等同于一次prefill，GPU利用率高）3. 从左到右验证：如果草稿token被接受，继续；否则用目标模型的分布采样替换，并截断后续4. 验证通过的token直接使用，相当于用一次大模型推理得到了多个token加速比取决于草稿模型的预测准确率（接受率α）：理论加速比 ≈ (1-α^(K+1)) / ((1-α)(1 + K*overhead))当α=0.9时，K=5时理论加速比约为3-4倍。实践中常用的草稿模型选择：- 使用目标模型的早期层作为草稿模型（Eagle、Medusa等方法）- 使用同系列的小模型（如LLaMA-3 8B作为70B的草稿）python# 使用vLLM的投机解码llm = LLM( model="meta-llama/Meta-Llama-3-70B-Instruct", speculative_model="meta-llama/Meta-Llama-3-8B-Instruct", num_speculative_tokens=5, tensor_parallel_size=4,)## Continuous Batching：填满GPU的关键传统静态批处理（Static Batching）等所有请求完成后再开始新批次，导致GPU在等待最长请求时其他slot空闲。Continuous Batching（也叫In-flight Batching）的做法：某个请求生成完毕后，立即将新请求插入空出的slot，无需等待整批完成。这大幅提升了GPU利用率，是生产环境LLM推理的标配。vLLM、TGI（Text Generation Inference）等主流框架均已实现Continuous Batching。## FlashAttention：优化注意力计算的内存访问标准注意力计算的内存访问模式极其低效：需要将巨大的注意力矩阵写入HBM（高带宽内存），然后再读回来。FlashAttention通过精心设计的分块计算，大幅减少了HBM访问次数：标准注意力：O(N²) HBM读写FlashAttention-2：HBM访问减少5-9倍FlashAttention-3（针对H100优化）：进一步利用异步计算和张量核心FlashAttention不改变计算结果（数值等价），只是改变了计算顺序和内存访问模式。在实践中，几乎所有主流框架和模型都默认使用FlashAttention。## 量化推理：用精度换速度量化是降低推理成本的最直接方法。主流量化方案：| 方法 | 压缩率 | 精度损失 | 适用场景 ||------|--------|----------|----------|| FP16 | 基准 | 无 | 所有场景 || INT8（LLM.int8） | 2x | 极小 | 中等成本要求 || GPTQ | 4x | 小 | 离线批量推理 || AWQ | 4x | 小 | 离线/在线均可 || GGUF Q4_K_M | 4x | 小 | CPU/边缘设备 || FP8（H100原生） | 2x | 极小 | 数据中心高吞吐 |FP8量化是H100上的新利器，与INT8精度相当但有更好的硬件支持：python# vLLM FP8量化llm = LLM( model="meta-llama/Meta-Llama-3-70B-Instruct", quantization="fp8", tensor_parallel_size=4,)## 张量并行与流水线并行当单张GPU放不下模型时，需要分布式推理：张量并行（Tensor Parallelism）：将模型的每一层横向切分到多张GPU，每层需要All-Reduce通信。延迟最低，适合对延迟敏感的场景。流水线并行（Pipeline Parallelism）：将模型按层纵向切分，每张GPU负责若干层。适合超大模型和高吞吐场景，但有流水线气泡（pipeline bubble）开销。实践建议：- 4-8张GPU：优先张量并行- 更多GPU：张量并行+流水线并行混合- 推理服务：优先张量并行（更低延迟）## 推理引擎横评（2026年）| 引擎 | 优势 | 劣势 | 适用场景 ||------|------|------|----------|| vLLM | PagedAttention、高吞吐、生态最佳 | 部署复杂度中等 | 生产API服务 || TGI | HuggingFace生态、易用 | 性能略低于vLLM | 快速原型/小规模 || llama.cpp | CPU支持、量化丰富 | 单线程性能有限 | 本地/边缘部署 || TensorRT-LLM | NVIDIA官方优化、FP8 | NVIDIA专有 | 数据中心高吞吐 || SGLang | 复杂推理图、高性能 | 学习曲线陡 | Agent/多轮推理 |## 端到端优化实践：从瓶颈到方案真正做LLM推理优化，要先定位瓶颈：bash# 使用vLLM的性能分析工具python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Meta-Llama-3-70B-Instruct \ --enable-prefix-caching \ --enable-chunked-prefill \ --max-num-batched-tokens 8192 \ --tensor-parallel-size 4# 监控指标# - TTFT（Time To First Token）：首字延迟，反映prefill效率# - TPOT（Time Per Output Token）：每token延迟，反映decode效率 # - Throughput：每秒总token数，反映吞吐优化路径：1. TTFT高：优化prefill，启用Chunked Prefill，减少prompt长度2. TPOT高：优化decode，增大batch size，启用投机解码3. 吞吐低：增加并发，优化KV Cache利用率，启用prefix caching## 小结LLM推理加速是一个系统工程，没有银弹。2026年的最佳实践组合：- PagedAttention + Continuous Batching：基础必选，vLLM默认提供- FlashAttention-2/3：几乎零成本的注意力加速- INT8/FP8量化：在精度可接受时大幅降低成本- 投机解码：对延迟敏感的场景，有小模型时首选- Prefix Caching：有大量共享前缀时（如System Prompt）显著提速- 张量并行：多卡部署的标准方案掌握这些技术，才能在生产环境中真正把LLM推理成本压到合理水平。