【infra之路】12-投机解码、量化与推理引擎对比

学习目标掌握三种推理加速手段——投机解码加速 Decode、量化减少计算量和显存、以及主流推理引擎的架构差异和适用场景选择。这是推理系统阶段的最后一课把前面所学的 Prefill/Decode、PagedAttention、Continuous Batching 全部串起来。第一部分投机解码Speculative Decoding1.1 Decode 阶段的瓶颈Decode 阶段每生成 1 个 token 都要做一次完整的前向传播而每次前向传播的计算量其实很小只有 1 个 token 的矩阵乘法GPU 的计算单元远远没有被填满。瓶颈在于显存带宽——需要读取整个模型的权重和 KV Cache但只做很少的计算。LLaMA-7B Decode 一次前向传播: 需要读取: 模型权重 ~14 GB KV Cache随序列增长 实际计算: 1 个 token 的矩阵乘法 ≈ 几十 GFLOPS A100 的计算能力: 312 TFLOPS 计算单元利用率: 1% 这就是 memory-bound 的含义GPU 大部分时间在等数据从显存搬到计算单元1.2 投机解码的核心思想既然一次前向传播只生成 1 个 token 太慢能不能一次生成多个 token 候选然后批量验证朴素 Decode: 步骤1: 前向传播 → 生成 token_1 步骤2: 前向传播 → 生成 token_2 步骤3: 前向传播 → 生成 token_3 步骤4: 前向传播 → 生成 token_4 步骤5: 前向传播 → 生成 token_5 共 5 次前向传播生成 5 个 token 投机解码: 步骤1: 用小模型draft model快速生成 5 个候选 token 步骤2: 用大模型target model一次性验证这 5 个 token 结果: 接受其中 3 个正确的共 2 次前向传播生成 3-4 个 token1.3 Draft Model草稿模型投机解码需要一个小而快的 draft model它和 target model 共享同一个词表tokenizer但参数量小得多Target model: LLaMA-70B大、慢、准确 Draft model: LLaMA-7B小、快、大致准确 或者: Target model: LLaMA-7B Draft model: LLaMA-68M极小、极快Draft model 不需要完美只要和 target model 的输出分布有一定重合就行。1.4 验证机制大模型验证小模型生成的 token 序列不是简单地对或错而是用概率对比来保证输出分布和直接自回归生成完全一致小模型生成: [the, cat, sat, on] 大模型验证: 位置1: 大模型 P(the) vs 小模型 P(the) 如果大模型概率 ≥ 小模型概率 → 一定接受 如果大模型概率 小模型概率 → 以 P_target/P_draft 的概率接受 位置2: 如果位置1被接受继续验证 cat 位置3: 如果位置2被接受继续验证 sat ... 遇到第一个被拒绝的位置 → 重新采样停止 算法伪代码: for t in range(K): # K 是投机长度 r random_uniform(0, 1) if r min(1, P_target(x_t) / P_draft(x_t)): accept x_t else: reject x_t resample from (P_target - P_draft) 的归一化差值分布 break数学保证经过这个验证机制最终输出的 token 序列和直接用大模型自回归生成的分布完全一致。不会牺牲任何精度。1.5 加速比分析假设: K 5每次投机 5 个 token draft model 速度 target model 的 10 倍 接受率 α 0.770% 的 token 被接受 朴素 Decode 生成 N 个 token: 时间 N × T_target 投机解码生成 N 个 token: 每次投机: K 次 draft 前向 1 次 target 前向批量验证 每次接受的 token 数: K × α 1最后重新采样的也算 1 个 5 × 0.7 1 4.5 个 token 时间 K × T_draft T_target 5 × 0.1T 1T 1.5T 每 token 平均时间: 1.5T / 4.5 0.33T 加速比: T / 0.33T ≈ 3 倍实际加速比通常在1.5-3 倍取决于Draft model 和 target model 的分布重合度越高接受率越高Draft model 相对速度越小越快投机长度 K太长接受率下降太短收益小1.6 变体Self-Speculative Decoding不需要额外的 draft model用 target model 自身的早期退出层或跳层方式做 draftDraft: 只用 target model 的前 8 层 一个轻量 LM Head 快速生成候选 Verify: 用完整的 32 层 target model 验证 好处: 不需要额外加载一个模型节省显存第二部分模型量化Quantization2.1 为什么要量化LLM 推理的两个瓶颈都可以用量化缓解显存瓶颈: 模型权重太大放不下 FP16: 7B × 2 bytes 14 GB INT8: 7B × 1 byte 7 GB INT4: 7B × 0.5 byte 3.5 GB 计算瓶颈: 矩阵乘法太大算得慢 FP16 × FP16 乘法 → FP16 累加 INT8 × INT8 乘法 → INT32 累加GPU 有专用 INT8 计算单元速度快 2 倍2.2 量化的基本概念量化就是把高精度的浮点数映射到低精度的整数FP16 → INT8对称量化: 原始值范围: [-max, max] 映射到: [-127, 127] scale max / 127 quantize(x) round(x / scale) # FP16 → INT8 dequantize(q) q × scale # INT8 → FP16近似还原 精度损失: 每个值的误差 ≤ scale/2 如果 max 1.0scale ≈ 0.0078误差 ≤ 0.00392.3 权重量化 vs 激活量化命名规则: W{weight精度}A{activation精度} W16A16: 权重 FP16激活 FP16无量化 W8A16: 权重 INT8激活 FP16只量化权重 W8A8: 权重 INT8激活 INT8两者都量化 W4A16: 权重 INT4激活 FP16W8A16只量化权重——最常见的方案因为权重是静态的可以离线量化精度损失很小。推理时权重从 INT8 反量化回 FP16 再做计算。减少显存占用但不加速计算。W8A8权重和激活都量化——权重和激活都保持 INT8 格式矩阵乘法直接用 INT8 Tensor Core 计算速度翻倍。但激活是动态变化的需要在线量化运行时动态计算 scale更难保持精度。2.4 主流量化方法SmoothQuantW8A8核心问题激活值中有少量outlier异常大的值直接量化会把大部分正常值的精度压得很低。激活值分布: 正常值: [-0.1, 0.1]99% 的值 outlier: [5.0]1% 的值 直接 INT8 量化: scale 5.0 / 127 ≈ 0.039 正常值 0.05 → round(0.05/0.039) 1 → 反量化 0.039误差 22% 精度损失巨大SmoothQuant 的做法把激活的 outlier 迁移到权重上Y X · W 引入平滑因子 s: Y (X · diag(s)^{-1}) · (diag(s) · W) X_smooth · W_smooth s_j max(|X_j|)^α / max(|W_j|)^{1-α} # α 通常 0.5 效果: X_smooth 的 outlier 被缩小了 → 量化更精确 W_smooth 的 outlier 增加了 → 但权重是静态的可以离线处理GPTQW4A16 / W8A16基于Optimal Brain Quantization框架的权重量化逐列量化权重矩阵: 1. 量化第 j 列 2. 计算量化误差 3. 用 Hessian 信息把误差补偿到后面的未量化列上 4. 继续量化第 j1 列 效果: 每个量化步骤的误差被后续列吸收总体误差最小化GPTQ 是离线完成的量化一次后保存 INT4/INT8 权重文件推理时反量化回 FP16 计算。AWQW4A16核心观察不是所有权重都同等重要。显著性通道salient channels的权重对模型质量影响很大不能粗暴量化。权重矩阵 W 的每一列对应一个通道 某些通道对应激活值大的方向特别重要 AWQ 的做法: 1. 找到显著性通道通过激活值的统计 2. 对显著性通道乘以一个大的缩放因子 3. 量化显著性通道的值更大量化误差相对更小 4. 推理时反量化后再除以缩放因子AWQ 比 GPTQ 更简单、更快而且在 4-bit 量化下精度更好。2.5 量化精度对比方法精度速度提升显存节省适用场景FP16基准100%1×0%精度敏感场景W8A16 (GPTQ)~99.5%1×50%显存受限W4A16 (AWQ)~98%1×75%消费级 GPUW8A8 (SmoothQuant)~99%1.5-2×50%高吞吐部署FP8 (H100 原生)~99.5%1.5-2×50%H100 集群2.6 KV Cache 量化除了模型权重KV Cache 也可以量化来节省显存FP16 KV Cache: 每 token 每层 16 KB INT8 KV Cache: 每 token 每层 8 KB减少 50% vLLM 配置: kv_cache_dtypeauto # FP16 kv_cache_dtypefp8 # FP8H100 支持 kv_cache_dtypeint8 # INT8KV Cache 量化的精度损失通常很小因为 K 和 V 的分布相对稳定。第三部分主流推理引擎对比3.1 vLLM架构特点: - PagedAttention 的提出者 - Continuous Batching - 支持 Tensor Parallel / Pipeline Parallel - 支持多种量化格式GPTQ, AWQ, FP8 - Python 为主的代码架构 核心优势: - 显存利用率高PagedAttention - 社区活跃生态丰富 - 易用性好API 兼容 OpenAI 格式 - 支持模型种类多 不足: - Python 调度器有一定开销 - 前缀缓存能力不如 SGLangvLLM 的使用fromvllmimportLLM,SamplingParams llmLLM(modelmeta-llama/Llama-2-7b-hf,tensor_parallel_size1,gpu_memory_utilization0.9,max_model_len4096,quantizationawq,# 可选enable_chunked_prefillTrue,# 可选)paramsSamplingParams(temperature0.7,top_p0.9,max_tokens512)outputsllm.generate([请解释什么是 AI Infra],params)3.2 SGLang架构特点: - RadixAttention高效前缀缓存 - 结构化生成JSON schema、正则约束 - 数据并行推理多实例负载均衡 - Zero-overhead scheduling 核心优势: - 共享前缀场景吞吐高 2-5 倍RadixAttention - 结构化生成速度快、准确 - 多轮对话场景表现好 - 支持 data parallelism多 GPU 各跑一个实例 不足: - 社区生态比 vLLM 稍小 - 学习曲线略高SGLang 的使用importsglangassgl# 启动服务# python -m sglang.launch_server --model meta-llama/Llama-2-7b-hf --port 30000sgl.functiondefqa(s,question):ssgl.system(你是一个AI助手)s用户: question\ns助手: sgl.gen(answer,max_tokens512)stateqa.run(question什么是PagedAttention)print(state[answer])3.3 TensorRT-LLM架构特点: - NVIDIA 官方出品深度 CUDA 优化 - 编译式推理模型先编译成优化后的 engine - In-flight batching类似 Continuous Batching - 深度 kernel fusion注意力、LayerNorm、量化 kernel 核心优势: - 单 GPU 延迟最低kernel 级优化 - 支持 NVIDIA 全系列 GPUT4 → H100 - FP8/INT4 量化支持最完善 - 和 Triton Inference Server 深度集成 不足: - 需要编译 engine部署流程复杂 - 模型更新需要重新编译 - 主要面向 NVIDIA GPU不支持其他硬件 - 文档不如 vLLM 友好TensorRT-LLM 的使用# 1. 转换模型为 TensorRT-LLM 格式python convert_checkpoint.py--model_dir/path/to/llama-7b\--output_dir./llama-7b-trt--dtypefloat16# 2. 编译 enginetrtllm-build--checkpoint_dir./llama-7b-trt\--output_dir./llama-7b-engine\--max_batch_size32--max_input_len4096# 3. 推理python run.py--engine_dir./llama-7b-engine\--input_text什么是AI Infra3.4 三者对比总结维度vLLMSGLangTensorRT-LLM核心技术PagedAttentionRadixAttentionKernel Fusion显存管理PagedAttentionBlockRadix Tree Paged预分配 In-flight前缀缓存基础支持强RadixAttention基础支持结构化生成不支持强JSON/Regex不支持延迟中等中等最低吞吐量高高共享前缀场景更高高易用性高中低社区活跃度最高高中适用 GPUNVIDIA AMDNVIDIANVIDIA only部署复杂度低低高需编译3.5 选型建议场景 1: 通用部署追求易用性 → vLLM 一行命令启动OpenAI 兼容 API社区文档丰富 场景 2: 共享前缀多system prompt、few-shot → SGLang RadixAttention 在这种场景下吞吐优势明显 场景 3: 结构化输出JSON schema、function calling → SGLang 内置结构化生成支持速度快且准确 场景 4: 追求极致延迟NVIDIA GPU → TensorRT-LLM Kernel 级优化单请求延迟最低 场景 5: 多模型服务、需要负载均衡 → SGLangdata parallelism或 vLLM 外部 LB 场景 6: 企业级生产部署 → TensorRT-LLM Triton Inference Server 完善的监控、版本管理、模型热更新第四部分推理系统全景图把整个推理系统的知识串起来用户请求到达 │ ▼ ┌──────────────────────────────────────────────────────────┐ │ 调度器Scheduler │ │ - 等待队列管理 │ │ - Continuous Batchingiteration-level 调度 │ │ - 优先级 抢占Preemption │ │ - Chunked Prefill避免长 prompt 阻塞 Decode │ └────────────────────────┬─────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────┐ │ 显存管理Block Manager │ │ - PagedAttention虚拟内存 Block Table │ │ - RadixAttention前缀缓存 Radix Tree │ │ - KV Cache 量化FP16 → INT8/FP8 │ │ - 抢占时 Swap/Recompute │ └────────────────────────┬─────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────┐ │ 模型计算Model Execution │ │ - Prefill: 一次处理整个 promptcompute-bound │ │ - Decode: 逐 token 生成memory-bound │ │ - 量化: W8A8 / W4A16 / FP8减少计算和显存 │ │ - 投机解码: draft model 生成 target model 验证 │ │ - Kernel 优化: FlashAttention / FlashDecoding / Fusion │ └────────────────────────┬─────────────────────────────────┘ │ ▼ 生成结果返回面试高频问题Q1: 投机解码会牺牲精度吗不会。验证机制在数学上保证了输出分布和直接自回归生成完全一致。只是通过提前猜测批量验证的方式把多次小前向传播合并成少数大前向传播。Q2: 什么时候量化会导致明显的质量下降通常 8-bit 量化W8A8/W8A16质量损失很小1%。4-bit 量化W4A16在小模型7B上可能有感知差异大模型70B几乎无感。2-bit 及以下会明显退化。量化后建议跑 benchmark如 MMLU、HumanEval验证。Q3: vLLM 和 SGLang 能同时用吗不能直接在同一个进程中使用但可以部署多个实例做负载均衡。SGLang 本身支持 data parallelism——多个 SGLang 实例各跑一个模型副本共享请求队列。Q4: TensorRT-LLM 为什么延迟最低三层优化1) Kernel fusion——把多个小 kernelLayerNorm、Softmax、Residual Add融合成一个大 kernel减少 kernel launch 和显存读写2) 编译优化——静态图编译消除 Python 调度开销3) 深度量化——FP8/INT4 直接用 Tensor Core 计算硬件级加速。总结技术解决的问题核心机制加速比投机解码Decode 阶段 GPU 利用率低小模型快速生成 大模型批量验证1.5-3×W8A8 量化计算慢INT8 Tensor Core 加速矩阵乘法1.5-2×W4A16 量化显存大权重压缩到 4-bit推理时反量化显存节省 75%KV Cache 量化KV Cache 显存占用大FP16 → INT8/FP8显存节省 50%PagedAttention显存碎片化虚拟内存 Block Table吞吐提升 2-4×Continuous BatchingGPU 空闲等待请求级动态调度吞吐提升 3-10×RadixAttention重复计算前缀前缀缓存 Radix Tree吞吐提升 2-5×