大模型推理加速：从 KV Cache 到投机解码的工程实践
一、推理延迟的"最后一公里"：模型能力够，但速度不够
大模型应用落地的最大瓶颈往往不是模型能力，而是推理延迟。一个 70B 参数的模型，单次生成可能需要 5-10 秒，在实时对话和批量处理场景中都难以接受。用户对响应时间的容忍度通常在 2 秒以内，超过 5 秒就会产生明显的体验下降。
推理加速的核心矛盾在于：自回归生成的串行性——每个 token 的生成都依赖前面所有 token 的计算结果，无法简单并行化。解决这一矛盾，需要从计算复用（KV Cache）、计算投机（投机解码）、模型压缩（量化）三个维度同时发力。
二、推理加速技术栈全景
graph TB subgraph 计算复用层 A[KV Cache<br/>避免重复计算Key/Value] A1[PagedAttention<br/>显存分页管理] end subgraph 计算投机层 B[投机解码<br/>小模型猜+大模型验] B1[Medusa Heads<br/>多头并行预测] end subgraph 模型压缩层 C[量化<br/>INT8/INT4/FP8] C1[蒸馏<br/>知识迁移到小模型] end subgraph 系统优化层 D[Continuous Batching<br/>动态批处理] D1[Prefix Caching<br/>共享前缀缓存] end A --> A1 B --> B1 C --> C1 D --> D1 A1 --> E[端到端推理加速] B1 --> E C1 --> E D1 --> EKV Cache 是最基础也最有效的优化。自回归生成中，每一步都需要对前面所有 token 计算 Attention，而 Key 和 Value 矩阵在之前步骤已经计算过。KV Cache 将这些矩阵缓存下来，避免重复计算，将每步的计算量从 O(n²) 降低到 O(n)。
三、核心加速方案实现
3.1 KV Cache 与 PagedAttention
import torch from dataclasses import dataclass @dataclass class KVCache: """KV Cache 管理：支持 PagedAttention 的分页存储""" key_cache: torch.Tensor # [num_layers, max_pages, page_size, num_heads, head_dim] value_cache: torch.Tensor # 同上 page_table: dict[int, list[int]] # seq_id -> 页号列表 free_pages: list[int] # 空闲页列表 class PagedKVCacheManager: """分页 KV Cache：解决显存碎片问题""" def __init__( self, num_layers: int, num_heads: int, head_dim: int, page_size: int = 16, max_pages: int = 4096, dtype: torch.dtype = torch.float16 ): self.page_size = page_size # 预分配显存，避免动态分配的碎片问题 cache_shape = (num_layers, max_pages, page_size, num_heads, head_dim) self.key_cache = torch.zeros(cache_shape, dtype=dtype, device="cuda") self.value_cache = torch.zeros(cache_shape, dtype=dtype, device="cuda") self.page_table = {} self.free_pages = list(range(max_pages)) def allocate(self, seq_id: int, num_tokens: int) -> list[int]: """为序列分配 KV Cache 页""" num_pages = (num_tokens + self.page_size - 1) // self.page_size if len(self.free_pages) < num_pages: # 显存不足，触发驱逐策略 self._evict(num_pages - len(self.free_pages)) pages = self.free_pages[:num_pages] self.free_pages = self.free_pages[num_pages:] self.page_table[seq_id] = pages return pages def _evict(self, needed: int) -> None: """LRU 驱逐：释放最久未访问的序列的页""" # 按最后访问时间排序，驱逐最早的 sorted_seqs = sorted( self.page_table.items(), key=lambda x: x[0] # 简化：实际应按访问时间 ) evicted = 0 for seq_id, pages in sorted_seqs: self.free_pages.extend(pages) del self.page_table[seq_id] evicted += len(pages) if evicted >= needed: break3.2 投机解码
class SpeculativeDecoder: """投机解码：小模型猜测 + 大模型验证""" def __init__(self, draft_model, target_model, gamma: int = 5): self.draft_model = draft_model # 小模型（快速） self.target_model = target_model # 大模型（准确） self.gamma = gamma # 猜测token数 def generate(self, prompt_ids: list[int], max_tokens: int) -> list[int]: generated = list(prompt_ids) while len(generated) - len(prompt_ids) < max_tokens: # 步骤1：小模型快速生成 gamma 个 token draft_tokens = [] draft_probs = [] current = list(generated) for _ in range(self.gamma): next_token, prob = self.draft_model.predict_next(current) draft_tokens.append(next_token) draft_probs.append(prob) current.append(next_token) # 步骤2：大模型一次前向传播验证所有猜测token target_probs = self.target_model.predict_batch( generated, draft_tokens ) # 步骤3：逐个验证，接受或拒绝 accepted = 0 for i in range(self.gamma): # 接受条件：随机采样接受概率 # p_accept = min(1, target_prob / draft_prob) t_prob = target_probs[i][draft_tokens[i]] d_prob = draft_probs[i][draft_tokens[i]] accept_ratio = min(1.0, t_prob / (d_prob + 1e-10)) if torch.rand(1).item() < accept_ratio: generated.append(draft_tokens[i]) accepted += 1 else: # 拒绝后，从大模型的分布中采样一个token corrected = torch.multinomial( target_probs[i], num_samples=1 ).item() generated.append(corrected) break else: # 所有猜测都被接受，额外生成一个token extra = torch.multinomial( target_probs[self.gamma], num_samples=1 ).item() generated.append(extra) return generated[:len(prompt_ids) + max_tokens]四、推理加速的 Trade-offs 分析
投机解码的命中率：投机解码的加速比取决于小模型的猜测命中率。如果小模型与大模型的分布差异大，命中率低，反而增加计算开销（大模型需要额外验证）。实测中，7B 小模型 + 70B 大模型的平均命中率约 70%，加速比约 2-3x。但 1B 小模型的命中率可能只有 40%，加速效果有限。
量化的精度损失：INT4 量化可将推理速度提升 2-3x，显存减少 75%，但在复杂推理任务上精度下降 5-10%。INT8 量化精度损失约 1-2%，是更安全的选择。FP8 在 H100 等 GPU 上可获得硬件加速，但兼容性受限。
PagedAttention 的管理开销：分页管理引入了页表查找和显存分配的开销，在短序列场景（<128 tokens）中，开销占比可能达到 10%。长序列场景（>2048 tokens）中，显存节省带来的收益远大于管理开销。
Continuous Batching 的延迟抖动：动态批处理提升了吞吐量，但不同请求的生成长度差异会导致短请求等待长请求，增加尾延迟。需要配合抢占式调度来缓解。
五、总结
大模型推理加速是系统工程，单一技术难以解决所有问题。KV Cache + PagedAttention 解决显存瓶颈，投机解码突破自回归的串行限制，量化降低计算和存储开销，Continuous Batching 提升吞吐量。这些技术需要组合使用，并根据具体场景调优。
落地建议：先确保 KV Cache 正确实现（这是最基础的优化），然后引入 Continuous Batching 提升吞吐量，再根据延迟要求决定是否使用投机解码。量化作为最后的手段，在精度可接受的范围内使用。全程配合基准测试，量化每个优化的实际收益。
