2026 年大模型推理加速已经从单点优化演变为系统级工程。投机解码Speculative Decoding、KV Cache 优化、PagedAttention、Continuous Batching 四大技术相互配合能让 LLM 推理性能提升 5-10 倍。本文从工程实战角度系统讲解这四项核心技术并给出 vLLM 0.9 SGLang 0.5 的配置调优指南。## 一、为什么 LLM 推理需要专门优化LLM 推理是访存密集型任务单 token 生成需要读取整个模型权重70B 模型 140GB。这意味着1.算力不是瓶颈——A100 算力 312 TFLOPS但实际推理只用 30%2.显存带宽是瓶颈——HBM 带宽 3.35 TB/s决定了实际吞吐3.Memory Wall——70B 模型 fp16 推理需要 140GB 显存单卡装不下这些特性决定了 LLM 推理优化不能照搬传统 DL 推理的思路如 TensorRT 静态图优化必须有专门的方案。## 二、KV CacheLLM 推理的核心数据结构### 2.1 KV Cache 原理LLM 自回归生成时每生成一个 token 都需 attention 所有历史 token。如果不缓存每步都重新计算O(n²) 计算量。KV Cache 思路把历史的 Key、Value 缓存起来生成新 token 时只计算当前的 Q、K、V。python# KV Cache 简化class KVCache: def __init__(self, num_layers, num_heads, head_dim, max_seq_len): self.keys torch.zeros(num_layers, max_seq_len, num_heads, head_dim) self.values torch.zeros(num_layers, max_seq_len, num_heads, head_dim) self.seq_len 0 def append(self, layer_idx, new_k, new_v): 追加新的 K、V self.keys[layer_idx, self.seq_len] new_k self.values[layer_idx, self.seq_len] new_v self.seq_len 1 def get(self, layer_idx): 获取历史 K、V return ( self.keys[layer_idx, :self.seq_len], self.values[layer_idx, :self.seq_len], )text### 2.2 KV Cache 显存占用KV Cache 占用的显存与序列长度 × 注意力头数 × 层数成正比。70B 模型、32K context 的 KV Cache 占用| 模型 | 32K context KV Cache 显存 ||------|------------------------|| Llama-3-8B (fp16) | 8 GB || Llama-3-70B (fp16) | 64 GB || Qwen-2-72B (fp16) | 70 GB |比模型权重还大KV Cache 优化是 LLM 推理的核心战场。### 2.3 KV Cache 优化技术#### PagedAttention分页管理传统 KV Cache 是连续显存浪费严重。vLLM 提出的PagedAttention把 KV Cache 分成固定大小的 block类似操作系统的虚拟内存pythonclass PagedKVCache: def __init__(self, num_blocks, block_size16): self.num_blocks num_blocks self.block_size block_size self.blocks torch.zeros(num_blocks, block_size, num_layers, num_heads, head_dim) self.block_table {} # seq_id - List[block_idx] def allocate(self, seq_id, num_tokens): 为序列分配 block num_blocks_needed (num_tokens self.block_size - 1) // self.block_size allocated [] for _ in range(num_blocks_needed): block_idx self.find_free_block() allocated.append(block_idx) self.blocks[block_idx].zero_() self.block_table[seq_id] allocated return allocated def append(self, seq_id, k, v): 追加 token 到 block block_table self.block_table[seq_id] # 找到当前 block last_block_idx block_table[-1] # 找到 block 内的位置 position (self.seq_len(seq_id) - 1) % self.block_size # 写入 self.blocks[last_block_idx, position] k效果显存碎片减少 80%单卡可服务并发数提升 3-5 倍。#### Prefix Cache前缀共享多请求共享相同前缀如 system prompt时KV Cache 完全可以共享pythonclass PrefixCache: def __init__(self): self.cache {} # prefix_hash - KV cache blocks def compute_prefix_hash(self, tokens): return hashlib.sha256(tokens.numpy().tobytes()).hexdigest() def get_or_compute(self, prefix_tokens): h self.compute_prefix_hash(prefix_tokens) if h in self.cache: return self.cache[h] # 命中直接复用 else: kv self.compute_kv_cache(prefix_tokens) self.cache[h] kv return kvtext效果相同 system prompt 的多请求TTFT 降低 70%。#### Quantized KV Cache量化压缩KV Cache 可以用 INT8/INT4 量化存储节省 2-4 倍显存pythonclass QuantizedKVCache: def __init__(self, quant_bits8): self.quant_bits quant_bits self.k_cache_quant None self.v_cache_quant None self.k_scale None self.v_scale None def quantize(self, k, v): 动态量化 if self.quant_bits 8: k_scale k.abs().max() / 127 v_scale v.abs().max() / 127 self.k_cache_quant (k / k_scale).round().to(torch.int8) self.v_cache_quant (v / v_scale).round().to(torch.int8) self.k_scale k_scale self.v_scale v_scale效果KV Cache 显存减少 50%吞吐提升 30-50%。KIVI、KVQuant 是 2026 年的代表性方案。## 三、投机解码Speculative Decoding### 3.1 原理投机解码是 2023 年提出的革命性思路用小模型打草稿大模型批量验证。text1. 小模型draft model快速生成 k 个候选 token2. 大模型target model一次前向计算验证 k 个 token 是否能接受3. 接受的 token 一次输出拒绝的 token 用大模型重新生成4. 重复pythonclass SpeculativeDecoder: def __init__(self, draft_model, target_model, k4): self.draft draft_model # 小模型如 Llama-3-8B self.target target_model # 大模型如 Llama-3-70B self.k k # 投机步数 def generate_step(self, input_ids): # 1. 小模型生成 k 个候选 draft_tokens [] draft_probs [] for _ in range(self.k): logits self.draft(input_ids) token, prob sample_with_prob(logits) draft_tokens.append(token) draft_probs.append(prob) input_ids torch.cat([input_ids, token.unsqueeze(0)]) # 2. 大模型一次前向验证 k 个 target_logits self.target(input_ids) target_probs softmax(target_logits, dim-1) # 3. 接受/拒绝判定 accepted 0 for i, draft_token in enumerate(draft_tokens): accept_prob min(1, target_probs[i][draft_token] / draft_probs[i][draft_token]) if random.random() accept_prob: accepted 1 else: # 拒绝用大模型的概率重采样 break return draft_tokens[:accepted]text### 3.2 投机解码选型2026 年主流投机解码方案| 方案 | Draft 模型 | 适用 | 加速比 ||------|-----------|------|--------||EAGLE-2| 轻量 Transformer | 通用 | 2.5-3x ||EAGLE-3| 极简线性层 | 通用 | 3-4x ||Medusa| 多头预测 | 通用 | 2-2.5x ||Lookahead Decoding| 树状生成 | 通用 | 2-3x ||Self-Speculative| 早期层退出 | 同模型 | 1.5-2x ||REST| 检索增强 | RAG 场景 | 2-4x |EAGLE-32026 年初发布是当前最快的方案70B 模型上达到 3.8x 加速。### 3.3 vLLM 投机解码配置bash# vLLM 启用 EAGLE-3 投机解码vllm serve meta-llama/Llama-3-70B-Instruct \ --speculative-model yuhuili/EAGLE-LLaMA3-Instruct-70B \ --num-speculative-tokens 5 \ --speculative-draft-tensor-parallel-size 1 \ --tensor-parallel-size 8 \ --gpu-memory-utilization 0.92效果70B 模型推理速度从 18 tokens/s 提升到68 tokens/s。## 四、Continuous Batching动态批处理### 4.1 传统 Static Batching 的问题传统批处理必须等所有请求完成才能处理下一批text[请求 A 100 token] [请求 B 200 token] [请求 C 50 token] ├─────────┤ ├────────────┤ ├────┤A 完成后 GPU 空闲等待 B 和 C问题长请求拖慢短请求GPU 利用率低。### 4.2 Continuous Batching 原理Continuous Batching 在每一步重新组合批次text时间步 1: [A, B, C]时间步 2: [A, B, C] C 完成时间步 3: [A, B, D] C 退出D 进入时间步 4: [B, D] A 完成vLLM、TGI、SGLang 都实现了 Continuous Batching吞吐提升 2-4 倍。### 4.3 vLLM 关键配置python# vLLM 启动参数vllm serve meta-llama/Llama-3-70B-Instruct \ --max-num-seqs 256 \ # 最大并发请求数 --max-num-batched-tokens 8192 \ # 每步最大 token 数 --scheduler-delay-factor 0.5 \ # 调度延迟因子越小越激进 --enable-chunked-prefill \ # 启用分块预填充 --max-model-len 32768text关键调优| 参数 | 推荐值 | 影响 ||------|--------|------||max-num-seqs| 128-512 | 并发能力依赖 GPU 显存 ||max-num-batched-tokens| 4096-16384 | 单步 token 处理量 ||scheduler-delay-factor| 0.3-0.7 | 调度激进程度 |## 五、推理引擎横评vLLM vs SGLang vs TGI### 5.1 性能对比2026 年 6 月测试条件Llama-3-70B-Instruct8xA100-80GB100 并发用户平均输出 256 tokens。| 引擎 | 吞吐 (tokens/s) | TTFT P50 | TTFT P99 | 显存峰值 ||------|----------------|----------|----------|---------|| vLLM 0.9 | 11,500 | 220ms | 580ms | 78GB || SGLang 0.5 | 13,200 | 180ms | 480ms | 76GB || TGI 3.5 | 9,800 | 280ms | 720ms | 80GB || TensorRT-LLM 0.13 | 12,400 | 200ms | 520ms | 79GB |SGLang 在 2026 年领先主要得益于 RadixAttention前缀树和 Compressive Memory。### 5.2 选型建议需要最高吞吐 复杂工作流→ SGLang需要稳定 生态丰富→ vLLMNVIDIA 专用 极致性能→ TensorRT-LLM简单部署 小规模→ TGItext## 六、高级优化Continuous Speculative Async Scheduling### 6.1 端到端优化pythonclass OptimizedInferenceServer: def __init__(self): # 1. PagedAttention 显存管理 self.kv_cache_manager PagedKVCacheManager( block_size16, num_blocks4096, ) # 2. 投机解码 self.speculative EAGLE3Decoder( draft_modelyuhuili/EAGLE-LLaMA3-Instruct-70B, k5, ) # 3. Continuous Batching self.scheduler ContinuousBatchScheduler( max_num_seqs256, max_num_batched_tokens8192, ) # 4. Prefix Cache self.prefix_cache PrefixCache(max_size_gb20) # 5. INT8 KV Cache 量化 self.kv_quant KIVIQuantizer(bits8) async def generate(self, request): # 1. 查找或计算 prefix KV prefix_kv self.prefix_cache.get_or_compute( request.system_prompt_tokens ) # 2. 加入调度队列 await self.scheduler.add_request( request, prefix_kvprefix_kv ) # 3. 等待生成完成 async for token in self.scheduler.stream(request.id): yield token### 6.2 关键监控指标pythonINFERENCE_METRICS { # 性能指标 ttft_p50: 首字延迟中位数, ttft_p99: 首字延迟 P99, itl_p50: Token 间延迟中位数, itl_p99: Token 间延迟 P99, tps_per_request: 单请求 token/s, tps_total: 总吞吐 tokens/s, # 资源指标 gpu_utilization: GPU 算力利用率, gpu_memory_used: 显存使用, kv_cache_used_blocks: KV Cache block 使用, kv_cache_hit_rate: 前缀缓存命中率, # 投机解码指标 speculative_acceptance_rate: 投机接受率, speculative_speedup: 投机加速比, # 调度指标 batch_size_avg: 平均批大小, batch_size_p99: P99 批大小, queue_length: 等待队列长度, queue_wait_p99: 等待时间 P99,}text## 七、生产案例70B 模型推理优化全过程### 7.1 优化前基线-引擎vLLM 0.7 默认配置-吞吐5,200 tokens/s-TTFT P991,200ms-显存占用82GB / 80GB接近 OOM### 7.2 优化步骤步骤 1PagedAttention Continuous Batchingbashvllm serve --max-num-seqs 128 --max-num-batched-tokens 4096- 吞吐5,200 → 8,400 tokens/s62%- 显存82GB → 76GB步骤 2INT8 KV Cache 量化KIVIbashvllm serve --kv-cache-dtype int8 --enable-kivitext- 显存76GB → 70GB- 吞吐8,400 → 9,800 tokens/s步骤 3投机解码EAGLE-3bashvllm serve --speculative-model yuhuili/EAGLE-LLaMA3-Instruct-70B \ --num-speculative-tokens 5- 吞吐9,800 → 14,200 tokens/s45%- TTFT P99580ms → 380ms步骤 4Prefix Cachepythonprefix_cache_size_gb20text- 同 system prompt 场景 TTFT380ms → 120ms- 整体吞吐14,200 → 16,800 tokens/s### 7.3 最终成果| 指标 | 优化前 | 优化后 | 提升 ||------|--------|--------|------|| 吞吐 | 5,200 | 16,800 |3.2x|| TTFT P99 | 1,200ms | 120ms |10x|| 显存占用 | 82GB | 70GB | -15% || 并发能力 | 64 | 192 | 3x |核心经验单项优化的乘数效应——单独看 PagedAttention、投机解码、Prefix Cache 各自提升 30-60%但叠加后总提升 200%。## 八、未来 12 个月的演进方向1.MoE 推理优化激活专家数动态调整、专家并行2.超长上下文1M Token 推理RingAttention、StripedAttention3.端到端编译TorchCompile、MLC-LLM、xFasterTransformer4.异构硬件CPU GPU NPU 协同推理5.推理训练融合在线学习、参数高效推理## 九、工程师的工具箱### 9.1 性能分析工具-vLLM Profiler内置 profiling-NVIDIA Nsight Systems底层 GPU 性能分析-PyTorch ProfilerPython 层分析-aicomboscopeLLM 专项分析### 9.2 调优清单- [ ] 启用 PagedAttention- [ ] 配置 Continuous Batching 参数- [ ] 启用 INT8 KV Cache 量化- [ ] 部署投机解码EAGLE-3 推荐- [ ] 配置 Prefix Cache- [ ] 监控 TTFT、ITL、吞吐三项核心指标- [ ] 定期做 A/B 测试验证优化效果## 一句话总结LLM 推理加速的本质是**“把硬件的每一滴算力都榨干”**——PagedAttention 解决显存碎片、投机解码减少计算量、Continuous Batching 提高利用率、Prefix Cache 复用已有计算。四项技术叠加能让单卡性能提升 3-10 倍。不优化就上线等于烧钱跑 30% 利用率的 GPU。## 常见踩坑-不要盲目调大 max-num-seqs——超过显存容量就 OOM必须实测-不要在所有场景都开投机解码——短序列场景投机开销可能大于收益-不要忽视 KV Cache 量化对精度的影响——必须做充分的精度验证-不要让投机解码的接受率低于 60%——低于这个值加速效果消失反而更慢-不要在生产环境用动态 shape——KV Cache 预分配更稳定