大规模 LLM 推理部署实战并行、投机解码、缓存与成本优化Maths, CS AI Compendium 第 17 章【免费下载链接】maths-cs-ai-compendiumBecome a cracked AI/ML researcher/engineer with this unconventional textbook covering maths, computing, and ML with intuition.项目地址: https://gitcode.com/GitHub_Trending/mat/maths-cs-ai-compendium导读本文将系统讲解如何把一个大模型从单卡跑通推进到服务百万级用户的生产规模涵盖推理阶段的张量/流水线/序列并行、投机解码speculative decoding、前缀缓存与 KV 缓存驱逐策略、主流推理框架选型、成本优化以及生产监控指标。读完你可以掌握一套从 GPU 分配、框架选型到单位 token 成本核算的完整部署决策框架并拿到可直接运行的模拟实验代码。本文是 Maths, CS AI Compendium 开源教材中 AI Inference 章节 的最后一篇与前四篇量化、高效架构、服务与批处理、端侧推理共同构成完整的推理优化知识链。为什么推理效率直接决定 AI 产品的经济性先看一组数量级估算一台 H100 以交互式延迟服务一个 70B 模型大约只能同时承载~100 个并发用户要服务 1000 万用户就需要约10 万张 H100按云上算力租赁价格折算一年成本约为30 亿美元。这意味着每提升 1 个百分点的效率就能节省数千万美元。推理优化不是学术问题它直接决定了 AI 产品的商业模式能否成立。这也是本仓库第 17 章AI Inference把量化 → 高效架构 → 服务批处理 → 端侧推理 → 规模化部署排成一条完整流水线的根本原因。本文讨论的每一项技术——并行切分、投机解码、前缀缓存、成本核算——都是在同一个 GPU 预算下服务更多用户的手段。推理阶段的模型并行当模型超过单卡显存时必须把模型切分到多张 GPU 上。第 6 章训练分布式 中介绍的并行策略在推理阶段依然适用但权衡点完全不同——训练关注吞吐与收敛推理额外受延迟约束。张量并行Tensor Parallelism张量并行Megatron 风格把单个权重矩阵切分到多张 GPU。以线性层 $Y XW$ 为例权重 $W$ 按列切分到 $N$ 张 GPU每张 GPU 计算部分结果最后通过 all-reduce 汇总$$W [W_1 | W_2 | \cdots | W_N], \quad Y_i X W_i, \quad Y \text{concat}(Y_1, \ldots, Y_N)$$推理时只要模型放不进单卡张量并行就是默认方案。一个 FP16 的 70B 模型需要 140 GB 显存用张量并行切分到 2 张 80 GB 的 H100 上即可承载。张量并行的代价是每层都会引入一次 all-reduce 通信通过 NVLink约 900 GB/s通信每层仅增加约0.1 ms通过 PCIe约 32 GB/s通信每层增加约3 ms。对于 80 层的 70B 模型跑在 2 张 GPU 上NVLink 总共只增加约 8 ms而 PCIe 要增加约 240 ms。这就是多卡推理中 NVLink 极其重要的原因——它决定了张量并行能否保持交互式延迟。流水线并行Pipeline Parallelism流水线并行把不同层分给不同 GPUGPU 1 处理第 0-39 层GPU 2 处理第 40-79 层token 依次流过整条流水线。推理阶段流水线并行的特点是延迟高于张量并行每个 token 都必须完整穿过整条流水线但通信开销更低GPU 之间只传递激活值没有 all-reduce。因此它更适合互连较慢的场景——比如跨节点、没有 NVLink 的机器组。序列并行Sequence Parallelism当序列极长时KV 缓存本身可能放不进单卡即使模型参数可以。序列并行把 KV 缓存按序列位置切分到多张 GPU每张 GPU 只存序列某一段的 key 和 value。注意力计算时每张 GPU 在自己的缓存段上计算部分注意力分数再通过一次归约合并结果。它主要用在 128K token 的长上下文推理中——此时 KV 缓存已经超过单卡显存上限。KV 缓存的内存占用公式详见量化章节的编码任务可据此估算何时必须启用序列并行。投机解码让小模型打草稿大模型做校验投机解码是目前影响最大的 LLM 推理优化之一。核心洞察解码慢是因为一次只生成一个 token而每个 token 都需要大模型做一次完整前向传播。但一个小模型可以快速生成候选 token大模型则可以并行校验多个候选。算法流程草稿模型小、快例如 1B 参数自回归地生成 $k$ 个候选 token目标模型大、准例如 70B对整段草稿序列只跑一次前向传播计算每个候选 token 的概率每个候选在目标模型概率足够高时被接受被拒绝的候选从目标模型分布中重新采样平均每个验证步骤可接受多个 token加速比近似为$$\text{Speedup} \approx \frac{k \times \text{acceptance_rate}}{\text{cost_ratio}} \approx 2\text{-}3\times$$为什么无损拒绝采样机制保证了输出分布与目标模型完全一致——投机解码是无损的输出在统计上与单独运行目标模型完全相同只是更快。这一点是它区别于简单蒸馏/近似方案的关键。主流变体MedusaCai et al., 2024不训练独立草稿模型而是在目标模型上添加多个轻量头同时预测多个未来 tokenEAGLELi et al., 2024训练一个轻量草稿头利用目标模型的隐藏状态预测未来 token接受率高于独立草稿模型自投机解码Self-speculative decoding目标模型自身通过提前退出草稿阶段只跑前几层生成草稿再用完整模型验证并行解码Parallel decoding并行生成多条续写候选树一次性验证整棵树。吞吐更高但分支的 KV 缓存会占用更多内存。前缀缓存共享上下文只算一次大量请求共享相同前缀系统提示词、few-shot 示例、常见查询模式。前缀缓存为这些前缀保存 KV 缓存并在请求间复用。系统提示词缓存如果每个请求都以同样的 2000 token 系统提示词开头这 2000 个 token 的 KV 缓存只计算一次即可被所有请求共享。对 80 层的 70B 模型每个请求可省约200 MB。基数树缓存Radix tree cachingSGLang把缓存前缀组织成基数树trie。新请求到达时找到最长的已缓存前缀匹配从那里开始生成跳过匹配前缀的全部计算。收益对于长共享前缀的应用带系统提示词的聊天机器人、共享检索片段的 RAG前缀缓存可将TTFT 降低 50%-90%并节省等比例的 GPU 算力。前缀缓存与服务章节介绍的 PagedAttention 共享页相互配合copy-on-write 复用共享前缀页是生产推理中成本最低、收益最直接的优化之一。KV 缓存驱逐注意力在实践中的稀疏性除了量化 KV 缓存和使用 GQA/MLA 缩小缓存KV 缓存驱逐策略会主动移除未来不太可能被注意到的缓存 token。H2OHeavy-Hitter OracleZhang et al., 2023观察到注意力分数服从幂律分布一小部分 token重击者获得了绝大部分注意力其余大部分 token 得到的注意力可以忽略。H2O 保留两类 token近期 token最近 $w$ 个 token 的滑动窗口类似 StreamingLLM重击者 token按所有历史解码步的累计注意力分数排序的 top-$k$。既不是近期、也不是重击者的 token 被驱逐。这让 KV 缓存保持固定大小同时保留真正影响生成的 token。H2O 用20% 的内存即可达到接近完整 KV 缓存的质量。ScissorhandsLiu et al., 2023思路类似但使用更精细的重要性指标当前步获得高注意力的 token 被保留而连续 $T$ 步未被注意的 token 被驱逐从而适应生成过程中不断变化的注意力模式。动态驱逐 StreamingLLM把注意力锚永久保留前几个 token与动态驱逐保留近期 重击者 token结合是超长生成中内存效率最高的方案可以在质量有限退化下实现无限长度生成。所有驱逐方法的共同洞察LLM 注意力在实践中是稀疏的——尽管架构会对全部缓存 token 计算注意力但实际注意力权重高度集中在少数子集上驱逐其余 token 对输出质量影响极小。推理框架选型LLM 服务生态已收敛到少数几个主导框架选型取决于你的硬件、延迟/吞吐目标与工作负载特征框架优势最适合vLLMPagedAttention、连续批处理、高吞吐通用 LLM 服务追求最高吞吐TensorRT-LLMNVIDIA 优化内核、FP8、in-flight batchingNVIDIA GPU 上的极致性能SGLang前缀缓存RadixAttention、快速结构化生成共享前缀多、输出受限的应用llama.cppCPU/Metal/CUDA/Vulkan、GGUF 量化、可移植消费级硬件、端侧推理TGIHuggingFaceAPI 简单、易部署、模型库集成快速部署、HF 生态Ollama一行命令下载并服务模型个人使用、本地开发ExLlamaV2极致量化优化EXL2 格式显存受限的 GPU 推理vLLM是生产 LLM 服务的默认选择支持连续批处理、PagedAttention、张量并行、投机解码、LoRA 服务以及绝大多数开源模型其 PagedAttention 与调度原理详见服务与批处理章节。TensorRT-LLM在 NVIDIA 硬件上达到最高原生性能同 GPU 下比 vLLM 快 10%-30%但灵活性较低、定制困难。SGLang在结构化输出JSON、指定格式的代码或共享前缀场景表现突出归功于其 radix attention 缓存与受限解码引擎。成本优化把单位 token 成本打下来规模上来后推理成本主导 ML 预算。以下是文档给出的策略清单按需选择 GPU不是每个模型都需要 H100。量化后的 7B 模型在 A10G约 $1/小时上就跑得很好不必用 H100约 $8/小时。让 GPU 匹配工作负载。抢占式实例Spot instances云厂商以 60%-90% 折扣提供闲置 GPU 容量AWS Spot、GCP Preemptible。实例可能被中断适合批处理推理配合中断处理保存状态、在新实例上恢复也可以服务交互流量。自动扩缩容Autoscaling根据流量调整 GPU 数量——高峰扩容、夜间缩容。可由 Kubernetes HPAHorizontal Pod Autoscaler或云原生自动扩缩容AWS SageMaker、GCP Vertex AI实现。批处理与利用率GPU 利用率从 30% 提到 90%单位 token 成本就降 3 倍。连续批处理、智能调度和 PagedAttention 都在提升利用率详见服务与批处理章节。量化INT4 相比 FP16 省 4 倍内存 → 模型可以装进更小的 GPU → 成本降低 2-4 倍同时相同批次能容纳更多请求 → 吞吐更高 → 单位 token 成本更低。量化方法体系见量化章节。文档给出的单位 token 成本基准近似值2026 年供数量级参考实际价格随时间与区域波动部署方案每 100 万 token 成本GPT-4o API$2.50Claude 3.5 Sonnet API$3.00Llama-70B on H100vLLMFP16$0.50Llama-70B on H100TRT-LLMINT8$0.25Llama-8B on A10GvLLMINT4$0.05Llama-3B 端侧llama.cpp$0硬件摊销注意上表中的 API 价格为公开市场价格的数量级参考并非本仓库实测数据但量化 更小 GPU 更高利用率的相对成本关系每降一档精度约省 2 倍、换更小 GPU 再省数倍是稳定的工程规律。生产监控在用户感知到劣化之前发现问题生产推理需要持续监控在用户受影响之前捕捉劣化延迟监控跟踪 TTFT 与 TPOT 的 p50、p95、p99为 p99 超过 SLO 设置告警。p99 飙升通常意味着KV 缓存内存压力抖动、长请求独占批次、或 GPU 热降频。吞吐监控跟踪每张 GPU 每秒 token 数。下降通常意味着批处理效率降低大量短请求导致批次利用率低、序列变长每个请求占用更多 KV 缓存内存、或硬件问题GPU 处于 ECC 纠错模式运行变慢。GPU 利用率跟踪 SM 占用率、显存利用率与显存带宽。低 SM 占用 高显存占用 内存受限需要更高带宽或量化高 SM 占用 低显存占用 计算受限需要更多 FLOPS 或更小模型。这与第 16 章 roofline 模型的诊断方法一脉相承。模型质量监控跟踪每请求指标响应长度、在留出集上的困惑度、用户反馈信号。质量劣化可能源于数据漂移请求分布变化、KV 缓存量化误差在长对话中累积、或服务管线 bug。成本监控按模型、按 GPU 类型跟踪单位 token 成本。若成本上升而吞吐没有上升排查效率回归新模型版本内存占用更高、批次配置不佳、GPU 未充分利用。工具基础设施指标用 Prometheus Grafana见第 15 章vLLM/TRT-LLM 自带 metrics 端点模型级指标用自定义日志。编码任务在 Colab 或 Notebook 中亲手验证任务 1模拟投机解码用快速草稿函数和慢速目标函数测量一次性生成并验证多个 token 带来的加速import random import time def target_model(tokens): Slow but accurate model. Returns probability of each candidate token. time.sleep(0.01) # simulate 10ms per forward pass # For simulation: accept tokens that are even numbers return [0.9 if t % 2 0 else 0.1 for t in tokens] def draft_model(): Fast but approximate model. Generates one candidate token. time.sleep(0.001) # simulate 1ms per token return random.randint(0, 9) def standard_decoding(n_tokens): Generate one token at a time with the target model. tokens [] for _ in range(n_tokens): time.sleep(0.01) # target model generates 1 token tokens.append(random.randint(0, 9)) return tokens def speculative_decoding(n_tokens, k4): Generate k draft tokens, verify with target, accept/reject. tokens [] total_target_calls 0 while len(tokens) n_tokens: # Draft: generate k candidates quickly candidates [draft_model() for _ in range(k)] # Verify: one target model call for all k candidates probs target_model(candidates) total_target_calls 1 # Accept tokens until one is rejected for i, (tok, prob) in enumerate(zip(candidates, probs)): if random.random() prob: tokens.append(tok) if len(tokens) n_tokens: break else: # Resample from target distribution tokens.append(tok 1) # simplified resampling break return tokens, total_target_calls n 50 start time.time() _ standard_decoding(n) standard_time time.time() - start start time.time() _, target_calls speculative_decoding(n, k5) spec_time time.time() - start print(fStandard: {standard_time:.2f}s ({n} target calls)) print(fSpeculative: {spec_time:.2f}s ({target_calls} target calls)) print(fSpeedup: {standard_time / spec_time:.1f}x)这个模拟忠实还原了投机解码的核心思想草稿函数每次只花 1ms 生成候选目标函数每批 10ms 校验多个候选最终加速比取决于接受率。真实系统中的实现vLLM、TensorRT-LLM 的投机解码、Medusa/EAGLE 变体遵循同样的 Draft → Verify → Accept 循环。任务 2估算不同优化策略的部署成本def serving_cost_analysis( model_name, params_B, precision_bits, gpu_name, gpu_mem_gb, gpu_cost_per_hr, target_throughput_tps, ): Estimate serving cost for an LLM deployment. model_size_gb params_B * 1e9 * precision_bits / 8 / 1e9 gpus_for_model max(1, int((model_size_gb * 1.2) / gpu_mem_gb 0.99)) # 1.2x for KV-cache # Rough throughput estimate (memory-bandwidth limited) tokens_per_gpu 500 / (params_B * precision_bits / 16) # normalised to 500 tok/s for 7B FP16 total_throughput tokens_per_gpu * gpus_for_model replicas max(1, int(target_throughput_tps / total_throughput 0.99)) total_gpus gpus_for_model * replicas cost_per_hr total_gpus * gpu_cost_per_hr cost_per_1M_tokens cost_per_hr / (total_throughput * replicas * 3600 / 1e6) print(f{model_name} {precision_bits}-bit on {gpu_name}:) print(f Model size: {model_size_gb:.0f} GB → {gpus_for_model} GPU(s)/replica) print(f Throughput: {total_throughput:.0f} tok/s/replica) print(f Replicas for {target_throughput_tps} tok/s: {replicas}) print(f Total GPUs: {total_gpus}) print(f Cost: ${cost_per_hr:.0f}/hr, ${cost_per_1M_tokens:.2f}/1M tokens) print() print( Cost Comparison \n) # Baseline: FP16 on H100 serving_cost_analysis(Llama-70B, 70, 16, H100, 80, 8.0, 1000) # Quantised: INT8 on H100 serving_cost_analysis(Llama-70B, 70, 8, H100, 80, 8.0, 1000) # Quantised: INT4 on A100 serving_cost_analysis(Llama-70B, 70, 4, A100, 80, 4.0, 1000) # Smaller model: 8B on A10G serving_cost_analysis(Llama-8B, 8, 4, A10G, 24, 1.0, 1000)这个成本模型把本文所有主题串在一起精度precision_bits决定模型占用与吞吐基线GPU 选型gpu_cost_per_hr决定单价KV 缓存按 1.2 倍系数计入显存对应量化章节对 KV 缓存的强调最终以每 100 万 token 成本作为跨方案比较的统一标尺。你会看到同一 70B 模型从 FP16 降到 INT8、INT4或者换成更小的 8B 模型 A10G单位 token 成本出现数量级差异——这正是本文开篇每个百分点的效率都值数千万美元的微观体现。延伸阅读量化本文成本优化中INT4 vs FP16的基础含 GPTQ/AWQ/GGUF 等全套方法高效架构StreamingLLM、GQA/MLA、稀疏注意力的原理是 KV 缓存优化与驱逐策略的上游服务与批处理PagedAttention、连续批处理、调度策略与 TTFT/TPOT 指标的定义基础端侧推理当规模与成本目标指向设备端时的压缩管线与运行时分布式训练张量/流水线并行的训练侧起源与 all-reduce 通信原语部署与 DevOpsPrometheus Grafana 等监控基础设施的落地方法。【免费下载链接】maths-cs-ai-compendiumBecome a cracked AI/ML researcher/engineer with this unconventional textbook covering maths, computing, and ML with intuition.项目地址: https://gitcode.com/GitHub_Trending/mat/maths-cs-ai-compendium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考