推理加速

Flash Attention解决了什么问题？ 标准注意力计算需要将整个N×N的注意力矩阵存储在GPU高带宽内存（HBM）中。对于长序列，这个矩阵非常大——128K序列长度的注意力矩阵需要约64GB HBM。GPU核心（SM）与HBM之间的数据搬运成为瓶颈。 Flash Attention的核心创新：不在HBM中实例化完整注意力矩阵，而是在SRAM中分块计算。 GPU内存层次 理解Flash Attention需要先理解GPU的内存层次： SRAM (片上共享内存) ├── 延迟: ~20 cycles ├── 带宽: ~19 TB/s (A100) └── 容量: ~192KB per SM HBM (高带宽内存) ├── 延迟: ~200+ cycles ├── 带宽: ~2 TB/s (A100) └── 容量: 80GB (A100) 标准注意力的问题：在HBM中读写O(n²)大小的矩阵，受限于2TB/s的HBM带宽。 Flash Attention的解决思路：将计算分块，每块在SRAM中完成，减少HBM访问次数。 算法原理 标准注意力计算 S = Q @ K^T / √d # [N, N] 注意力分数 P = softmax(S) # [N, N] 归一化 O = P @ V # [N, d] 输出 问题：S和P是N×N矩阵，需要完整存储在HBM中。 ...

大模型推理的Speculative Decoding原理详解 大模型推理的最大瓶颈是自回归生成——每个token的生成都依赖前面所有token的KV Cache，无法并行。Speculative Decoding（投机解码）是2024-2026年最重要的推理加速技术之一，在质量无损的前提下将推理速度提升2-4倍。 核心思想 自回归生成的瓶颈 标准自回归生成是串行的：生成第N个token需要先完成第1到N-1个token的生成。每一步都涉及一个完整的forward pass，计算量约O(n×d²)，其中n是序列长度，d是模型维度。 这种串行性导致GPU利用率低——大部分时间在做矩阵乘法但不能并行化。一个大模型生成500个token需要500次forward pass。 Speculative Decoding的洞察 Speculative Decoding的核心洞察是：大模型的前向计算可以批量处理多个token。 具体方法： 用一个小模型（Draft Model）快速生成N个候选token 用大模型（Target Model）一次性验证这N个token 从验证后的分布中采样，保证输出分布不变 关键在于第2步——大模型一次forward pass可以同时计算N个位置的概率分布，因为这个计算不依赖这N个token本身（只依赖前面的token，而这些已经由小模型"占位"了）。 数学原理 修改的拒绝采样 Speculative Decoding的数学基础是一种修改的拒绝采样，确保输出分布和直接使用大模型完全一致。 设大模型在位置t的条件分布为p(x|context)，小模型为q(x|context)。算法步骤： 小模型生成token x₁, x₂, …, xₖ 大模型并行计算p(x_i|context)对所有i 对每个位置i： 如果p(x_i) ≥ q(x_i)：接受x_i（以概率min(1, p(x_i)/q(x_i))） 如果p(x_i) < q(x_i)：以概率(p(x_i)/q(x_i))接受，否则拒绝并从(p-q)分布中重新采样 一旦拒绝某个token，从该位置开始重新用小模型生成 关键特性：不管小模型质量如何，最终输出分布恒等于大模型的分布。如果小模型生成的token和大模型一致，加速效果好；如果不一致，大模型会拒绝并修正，不损失质量。 加速效果分析 加速比取决于小模型的"命中率"——即生成的token被大模型接受的比例。 设小模型命中率r，每次生成k个候选token。期望接受的token数 = 1 + r + r² + … ≈ 1/(1-r)。 如果r=0.5（命中率50%），加速比约2x 如果r=0.7（命中率70%），加速比约3.3x 如果r=0.8（命中率80%），加速比约5x 命中率主要取决于小模型和大模型的相似度——小模型越接近大模型的分布，命中率越高。 工程实现 Draft Model选择 选择合适的小模型是Speculative Decoding成功的关键： 同系列小模型：最常用的方案。如果Target Model是Llama-70B，Draft Model用Llama-7B。同系列模型共享tokenizer和架构，分布相似度高。 自蒸馏模型：将大模型蒸馏到小模型作为Draft Model。蒸馏使小模型分布更接近大模型，命中率更高。 ...

延迟的两个关键指标 LLM服务的延迟分为两部分： TTFT（Time To First Token）：从请求到第一个token返回的时间 TPOT（Time Per Output Token）：每个后续token的生成时间 用户感知延迟 = TTFT + (输出token数 × TPOT)。优化需要分别针对这两个指标。 TTFT优化 预填充优化 TTFT主要由预填充（处理输入prompt）时间决定： # 1. 分块预填充：避免长prompt阻塞短请求 vllm serve model --enable-chunked-prefill --max-num-batched-tokens 4096 # 2. 前缀缓存：共享系统提示词的KV Cache vllm serve model --enable-prefix-caching # 3. 减少输入长度：精简系统提示词 # 差：500 token的系统提示词 # 好：150 token的精简系统提示词 模型预热 async def warmup_model(model_name): """服务启动时预热模型""" # 预加载模型到GPU dummy_input = "warmup" await llm.generate(dummy_input, max_tokens=1) # 预填充常见前缀 common_prompts = [ "你是一个专业助手", "请根据以下信息回答问题", ] for prompt in common_prompts: await llm.generate(prompt, max_tokens=1) TPOT优化 推测解码 # vLLM启用推测解码 vllm serve model \ --speculative-model /models/draft-model \ --num-speculative-tokens 5 \ --speculative-draft-tensor-parallel-size 1 量化 # INT8量化（2倍加速，精度损失<1%） vllm serve model --quantization awq --dtype float16 # INT4量化（3倍加速，精度损失3-5%） vllm serve model --quantization gptq --dtype float16 KV Cache优化 # FP8 KV Cache（减少显存带宽压力） vllm serve model --kv-cache-dtype fp8 网络层优化 流式响应 # 流式响应让用户更早看到输出 @app.post("/chat") async def chat(): async def stream(): yield "data: " # 立即发送头部 async for token in llm.astream(messages): yield json.dumps({"content": token}) + "\n" return StreamingResponse(stream()) 连接复用 # 使用HTTP/2或WebSocket减少连接建立开销 import httpx # 全局复用客户端 client = httpx.AsyncClient( http2=True, limits=httpx.Limits(max_connections=100, max_keepalive_connections=20), keepalive_expiry=30, ) 调度优化 优先级调度 class PriorityScheduler: """交互请求优先于批处理请求""" async def schedule(self, request): if request.type == "interactive": # 交互请求：立即处理 return await self.process_immediately(request) else: # 批处理请求：低峰期处理 return await self.queue_for_later(request) 请求预取 class RequestPrefetcher: """预测用户可能的下一步请求，提前计算""" async def on_user_typing(self, session_id): """用户正在输入时，预计算可能的请求""" likely_queries = await self.predict_queries(session_id) for query in likely_queries[:2]: # 预计算2个最可能的查询 cache_key = f"prefetch:{session_id}:{query}" if not await self.cache.exists(cache_key): result = await self.llm.generate(query) await self.cache.setex(cache_key, 30, result) 端到端优化清单 优化项 TTFT改善 TPOT改善 实现难度 分块预填充 30-50% — 低 前缀缓存 40-60% — 低 量化 10-20% 50-100% 中 推测解码 — 50-100% 中 流式响应 感知80%↓ — 低 模型分层 20-40% 30-50% 中 监控 # 延迟分解监控 class LatencyBreakdown: def record(self, request_start, first_token, request_end): ttft = first_token - request_start total = request_end - request_start tpot = (total - ttft) / max(output_tokens - 1, 1) metrics = { "ttft_ms": ttft * 1000, "tpot_ms": tpot * 1000, "total_ms": total * 1000, } # 告警 if ttft > 2.0: # TTFT > 2秒 alert("High TTFT") if tpot > 0.05: # TPOT > 50ms alert("High TPOT") 结语 LLM服务延迟优化需要从TTFT和TPOT两个维度系统推进。分块预填充和前缀缓存是最有效的TTFT优化手段，量化和推测解码是TPOT的核心优化手段。流式响应虽然不改变实际延迟，但显著改善用户感知。 加入讨论 这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。 ...

自回归生成的根本瓶颈 LLM的自回归生成是一个严格串行的过程——每个token依赖前一个token的输出。在A100 GPU上，生成一个token的延迟约为15-30ms，其中计算只占一小部分，大部分时间花在权重加载上。这就是内存带宽限制：每生成一个token都要将整个模型权重从HBM读到计算单元，但只产生一个token的输出。 推测解码（Speculative Decoding）通过打破这一串行约束，实现了2-3倍的推理加速。 核心思想：Draft-Verify范式 推测解码的核心思想异常简洁： Draft阶段：用一个小而快的Draft模型快速生成一段候选序列 Verify阶段：用大模型一次性并行验证这整段候选序列 接受/拒绝：根据大模型的概率分布决定接受多少个候选token 关键洞察在于：大模型并行处理N个token的速度（一次前向传播）远快于串行生成N个token（N次前向传播）。即使候选序列有部分错误，只要平均接受率足够高，就能获得净加速。 数学基础：拒绝采样 推测解码使用拒绝采样确保输出分布与纯大模型生成完全一致。给定Draft模型的概率 q(x) 和大模型的概率 p(x)： 接受概率 = min(1, p(x) / q(x)) 如果 p(x) ≥ q(x)：总是接受（Draft模型低估了这个token的概率） 如果 p(x) < q(x)：以 p(x)/q(x) 的概率接受，否则拒绝并从调整后的分布中重新采样 def speculative_decoding_step(draft_model, target_model, prefix, n_draft=4): # 1. Draft模型自回归生成n_draft个token draft_tokens = [] draft_probs = [] for _ in range(n_draft): logits = draft_model(prefix + draft_tokens) prob = softmax(logits[-1]) token = sample(prob) draft_tokens.append(token) draft_probs.append(prob[token]) # 2. 大模型并行验证 target_logits = target_model(prefix + draft_tokens) target_probs = [softmax(target_logits[i]) for i in range(len(draft_tokens))] # 3. 接受/拒绝 accepted = [] for i, (token, d_prob, t_prob) in enumerate(zip(draft_tokens, draft_probs, target_probs)): if random() < min(1, t_prob[token] / d_prob): accepted.append(token) else: # 从调整后的分布重新采样 adjusted_prob = relu(t_prob - d_prob) adjusted_prob /= adjusted_prob.sum() accepted.append(sample(adjusted_prob)) break # 一旦拒绝，后续候选全部丢弃 return accepted 这个算法保证了输出分布与纯大模型采样的分布完全一致——无损加速。 ...

注意力计算的性能瓶颈 标准注意力计算的核心瓶颈不在于计算量，而在于显存访问。注意力矩阵 QK^T 的形状为 [n, n]，对于 n=8192 的序列，仅这个矩阵就需要256MB显存（FP32）。GPU的计算速度远超显存带宽——A100的计算能力为312 TFLOPS，而HBM带宽仅2TB/s。 这就是经典的"内存墙"问题：注意力计算大部分时间不是在算，而是在等数据搬运。 Flash Attention V1：分块计算的突破 Tri Dao在2022年提出的Flash Attention V1核心思想是：通过分块计算避免实例化完整的注意力矩阵。 在线Softmax Flash Attention的关键创新是在线Softmax算法。标准Softmax需要先遍历一次数据求最大值，再遍历一次计算指数和归一化。在线Softmax通过维护一个运行最大值和运行和，在单次遍历中完成Softmax计算： def online_softmax(blocks): """在线Softmax：逐块更新""" m = float('-inf') # 运行最大值 l = 0.0 # 运行和 result = None for block in blocks: block_max = block.max() # 更新全局最大值 new_m = max(m, block_max) # 修正之前的累积值 alpha = math.exp(m - new_m) beta = math.exp(block_max - new_m) l = alpha * l + beta * block.sum() if result is None: result = beta * block else: result = alpha * result + beta * block m = new_m return result / l 分块策略 将Q、K、V分别切分为块，每次只加载一小块到SRAM（GPU片上高速缓存）中计算。外层循环遍历K/V块，内层循环遍历Q块： for each K_j, V_j block: load K_j, V_j to SRAM for each Q_i block: load Q_i to SRAM compute S = Q_i @ K_j^T update online softmax statistics compute partial O = P @ V_j write O_i back to HBM 这种策略使得HBM访问量从O(n²)降低到O(n²d/M)，其中M是SRAM大小。对于典型配置，这相当于减少了10-20倍的显存访问。 Flash Attention V2：效率的进一步提升 V2在V1基础上做了几个关键优化： 减少非矩阵乘法运算 GPU上矩阵乘法（GEMM）的效率远高于其他运算（如rescale、softmax）。V2重新组织了计算顺序，将rescale操作推迟到最后，减少了中间的rescale次数。 并行化改进 V1主要沿序列维度并行化，V2增加了批次和头维度的并行化，使得在长序列场景下能更好地利用GPU的并行能力。 前向和后向的分配优化 V2重新分配了前向和后向传播中的工作负载，减少了线程块之间的同步开销。 Flash Attention V3：FP8与异步流水线 2024年发布的Flash Attention V3针对H100 GPU的FP8张量核心和异步执行特性进行了深度优化。 ...

引言 大模型的推理成本通常占AI总成本的70%以上。高效的推理框架不仅能够降低运营成本，还能提升用户体验。2026年，主流推理框架在性能、功能和易用性上都有显著提升。本文对vLLM、SGLang、TensorRT-LLM、TGI四大框架进行深度对比。 框架概览 vLLM 定位： 高吞吐、低延迟的LLM推理引擎 核心技术： PagedAttention：解决KV Cache碎片化问题 Continuous Batching：请求级动态批处理 Tensor Parallelism：模型并行 优势： 吞吐量比HuggingFace Transformers高24倍 社区最大，生态最丰富 支持多种量化格式（AWQ、GPTQ、SqueezeLLM） 局限： 主要优化标准生成场景 高级功能（如Speculative Decoding）仍在演进 SGLang 定位： 面向复杂推理场景的高性能框架 核心技术： RadixAttention：分层缓存的KV Cache管理 结构化输出：JSON、正则表达式约束 推理+训练一体化 优势： 复杂推理场景性能突出 结构化输出支持完善 支持Speculative Decoding 局限： 社区相对较小 文档和生态不如vLLM丰富 TensorRT-LLM 定位： NVIDIA官方的高性能推理优化库 核心技术： 算子级优化：针对NVIDIA GPU深度优化 量化：FP8、INT4、FP4支持 多GPU/多节点分布式推理 优势： NVIDIA硬件上的极致性能 工业级稳定性 与NVIDIA全栈生态集成 局限： 仅支持NVIDIA GPU 配置复杂，学习曲线陡 非NVIDIA硬件兼容性差 TGI (Text Generation Inference) 定位： HuggingFace的推理服务器 核心技术： 动态批处理 张量并行 连续批处理 优势： 与HuggingFace生态无缝集成 部署简单 支持Safetensors模型 局限： ...

引言 大模型的量化（Quantization）是将高精度浮点模型转换为低精度表示的技术。2026年，INT4量化已经从"实验性技术"成为"生产级方案"，让70B参数模型在消费级GPU上运行成为可能。 量化技术分类 按训练方式分类 量化方法 ├── 训练后量化（PTQ） │ ├── PTQ-W（权重量化） │ └── PTQ-A（激活量化） ├── 校准量化（Calibration-based） │ ├── LLM.int8() │ └── SmoothQuant ├── 感知量化（Aware Quantization） │ ├── AWQ（Activation-Aware） │ ├── GPTQ（Greedy Post-Training） │ └── QoQ（Quantization-out-of-Context） └── 量化感知训练（QAT） ├── QAT-F（全量化训练） └── LoRA-QAT（低秩量化） 按量化粒度分类 粒度 说明 精度损失 加速效果 逐层 每层一个缩放因子 低 中 逐通道 每个通道一个缩放因子 低 高 逐组 每组（如128个）一个缩放因子 中 最高 逐元素 每个权重一个缩放因子 高 有限 主流量化方案深度对比 AWQ（Activation-Aware Weight Quantization） 核心思想： 保护对激活值敏感的权重，对这些权重进行更精细的量化。 原理： ...

引言 Speculative Decoding（推测解码）是2026年最受关注的大模型推理加速技术之一。通过用小模型快速生成候选token、再用大模型验证的方法，它可以在不损失质量的前提下将推理速度提升2-4倍。本文将深入讲解Speculative Decoding的原理、实战部署和效果优化。 技术原理 核心思想 传统自回归解码：每次生成1个token → 慢 Speculative Decoding： 用小模型（draft model）快速生成K个候选token 用大模型（target model）并行验证这K个token 接受所有正确的token，从第1个错误token后重新生成 循环 关键：验证K个token只需1次前向传播！ 数学分析 假设： 大模型每次前向传播耗时：$T$ 小模型每次前向传播耗时：$t$（$t \ll T$） 接受率：$p$（通常0.6-0.8） 传统解码：每token耗时 $T$ Speculative Decoding：每token耗时 $\frac{T}{K \times p}$ 若 $K=5, p=0.7$，则加速比 = $\frac{5 \times 0.7}{1}$ = 3.5× 接受率分析 接受率取决于： 小模型质量：质量越高，接受率越高 任务类型：简单任务接受率高（0.8+），复杂任务低（0.5-） K值选择：K越大，总体接受率越低（因为错误累积） 实测接受率： 小模型 目标任务 平均接受率 Qwen3.5 3B 通用对话 0.72 Qwen3.5 3B 代码生成 0.65 Qwen3.5 7B 通用对话 0.78 Qwen3.5 7B 代码生成 0.72 Gemma 3 4B 通用对话 0.68 实战部署 方案1：使用vLLM的Speculative Decoding vLLM 0.4+原生支持Speculative Decoding。 ...

引言 2026年，大模型推理引擎市场已经形成了vLLM、SGLang和TensorRT-LLM三足鼎立的格局。vLLM以易用性和社区生态取胜，SGLang以创新的RadixAttention和灵活编程模型见长，TensorRT-LLM则以极致的NVIDIA硬件优化称雄。本文将通过大量实测，全面对比三大推理引擎，帮助开发者选择最适合的推理解决方案。 推理引擎概述 核心差异 维度 vLLM SGLang TensorRT-LLM 定位 通用推理引擎 高性能+编程模型 NVIDIA专属优化 硬件支持 全平台 NVIDIA+AMD 仅NVIDIA 易用性 ★★★★★ ★★★★ ★★★ 性能 ★★★★ ★★★★★ ★★★★★ 社区生态 ★★★★★ ★★★★ ★★★ 企业支持 社区+企业 社区+创业公司 NVIDIA官方 技术路线 vLLM： 基于PyTorch，易用性优先 PagedAttention创新（内存效率） 支持最广泛的模型和硬件 SGLang： 创新的RadixAttention（前缀缓存） 灵活的编程模型（类似DSL） 针对多轮对话和RAG优化 TensorRT-LLM： 深度NVIDIA硬件优化 量化+内核融合+Fp8原生支持 企业级稳定性和支持 性能实测 测试环境 硬件：8×NVIDIA H100 80GB 模型：Llama 4 70B（INT8）、Qwen3.5 72B（INT8） 基准：生成速度、延迟、吞吐、显存效率 生成速度对比 Llama 4 70B（INT8，batch=1）： 引擎 生成速度 首token延迟 KV Cache效率 vLLM 0.6 142 tok/s 0.9s ★★★★ SGLang 0.3 165 tok/s 0.7s ★★★★★ TRT-LLM 0.9 155 tok/s 0.8s ★★★★★ Qwen3.5 72B（INT8，batch=1）： ...

自回归生成是大模型推理的"阿喀琉斯之踵"：每生成一个token需要完整前向传播，无法有效利用GPU并行性。多Token预测（Multi-Token Prediction, MTP）通过在单次前向传播中预测多个未来token，突破这一瓶颈。到2026年，MTP已成为推理加速的标准技术之一。 1. 自回归生成的瓶颈 1.1 推理延迟分析 标准自回归生成的推理延迟： $$\text{Latency} = T \times (t_{prefill} + t_{decode})$$ 其中 $T$ 为生成长度，$t_{prefill}$ 为预填充延迟，$t_{decode}$ 为逐token生成延迟。由于KV Cache复用，$t_{decode}$ 主导整个生成过程。 以70B模型生成100个token为例： $t_{decode} \approx 30\text{ms/token}$（A100 80GB） 总延迟 $\approx 3\text{秒}$ 1.2 硬件利用率 自回归生成的硬件利用率极低： 阶段 FLOPs利用率 瓶颈 Prefill 60-80% 计算吞吐 Decode 5-15% 内存带宽 Decode阶段大部分时间花在从显存加载模型权重上，这是Memory-Bound而非Compute-Bound。 2. 多Token预测原理 2.1 核心思想 MTP的核心思想：在预测下一个token的同时，预测未来多个token。 训练目标从单步预测扩展到多步预测： $$\mathcal{L}{MTP} = \sum{k=1}^{K} \lambda_k \cdot \mathcal{L}(\hat{y}{t+k} | y{<t+k})$$ 其中 $K$ 为预测步数，$\lambda_k$ 为第 $k$ 步的权重。 2.2 架构设计 主流MTP架构有三种方案： 方案1：独立输出头 class IndependentHeadsMTP(nn.Module): def __init__(self, base_model, num_heads=4): super().__init__() self.base = base_model self.output_heads = nn.ModuleList([ nn.Linear(base_model.d_model, base_model.vocab_size) for _ in range(num_heads) ]) def forward(self, x): hidden = self.base(x) # [batch, seq_len, d_model] outputs = [] for head in self.output_heads: outputs.append(head(hidden)) # 共享hidden，独立head return outputs # [num_heads, batch, seq_len, vocab_size] 方案2：级联MTP（Meta的MTP方案） ...