## 一、投机解码：让快的小模型"打草稿"，大模型"批改作业"

decode 慢的根源是串行：一次只能生成一个 token，每步都要把全部权重搬一遍。

投机解码（Speculative Decoding）的思路很妙：让一个便宜的小模型（draft）一次猜出 K 个候选 token，大模型（target）用一次前向把所有候选一次性验证掉。猜对的直接收下，猜错的位置从大模型的真实分布重新采样。

这里有个关键细节：验证不是简单的"对/错"，而是对每个草稿 token 按大模型的分布做 **rejection sampling 修正**。正是这个修正过程保证了输出分布和大模型自己逐 token 生成**完全一致（bit-exact）**，不是近似，是同一个分布（2026 年投机解码技术综述）。

![fig10-speculative.png](https://developer.qcloudimg.com/http-save/yehe-11479707/9cec15778184c4604003d4171f436965.png)

加速多少，取决于三个数：接受率 α（draft 猜中的比例）、猜测长度 K、draft 相对 target 的成本比 c。代入典型值 α=0.7、K=4、c=0.1，加速约 2 倍（来源：appscale 2026 分析）。也就是说同样的硬件，吞吐翻倍。

2026 年的主流方案对比（来源：CallSphere/appscale 2026 综述）：

| 方案                        | 思路                         | 接受率             | 额外开销      |
| ------------------------- | -------------------------- | --------------- | --------- |
| **EAGLE-3**（2025）         | 用 target 的深层隐藏状态做草稿头 + 草稿树 | 70–78%          | 需训练草稿头，小  |
| **Medusa-V2**             | 给 target 挂多个预测头，同时猜多个未来位置  | 60–70%          | 需训练头，部署简单 |
| **MTP**（DeepSeek V3/V4）   | 训练时就让模型学会一次预测多个 token      | 80%+            | 无，但要重训模型  |
| **自推测（Self-speculation）** | 用模型自己前面的 token 当草稿         | 40–55%（单一来源，参考） | 零额外内存     |

一个真实的生产案例：据报道（PayPal 技术论文与多家媒体），PayPal 在电商 agent 上实测 EAGLE-3，吞吐提升两到五成、延迟降低两到三成，输出质量无损；最震撼的是，一张 H100 用投机解码，追平了两张 H100 跑 NVIDIA NIM，推理 GPU 成本直接减半。注意这是领域模型实测，接受率只有约三成多，远低于通用基准的 70%+，说明真实收益必须自己测。

### 什么时候别用投机解码

- 高温采样（creative 场景）：draft 和 target 分歧大，接受率暴跌。
- 长上下文：接受率会随上下文变长而衰减。
- draft 太贵：7B 草稿配 70B target 基本没用，draft 成本占比必须很小。

## 二、量化：FP8 是安全默认，FP4 是 Blackwell 的王牌

量化是把权重从 FP16 降精度存储，换内存减半或减四分之一。2026 年的格局很清楚（来源：ai.rs、mubibai 等 2026 量化评测）：

| 精度                   | 适用硬件                 | 吞吐提升（vs FP16）        | 代价                     |
| -------------------- | -------------------- | -------------------- | ---------------------- |
| **FP8**              | Hopper（H100/H200）    | 1.4–1.7x             | 质量损失可忽略（0.3–0.5pp）     |
| **INT4**（GPTQ/AWQ）   | 任意 GPU               | 提速视场景（低并发 decode 明显） | 省显存但没有 4-bit 计算，先反量化再算 |
| **FP4**（NVFP4/MXFP4） | Blackwell（B200/B300） | 约 2–5 倍（视对比基线）       | 精度损失 1–3%，硬推理退化明显      |

![fig10-quant.png](https://developer.qcloudimg.com/http-save/yehe-11479707/85c0e70b175aa1c8503f43063beb320c.png)

三个关键判断：

**① Hopper 上用 FP8，别碰 INT4。** INT4 只省带宽、不省计算（权重要反量化回 FP16 才做矩阵乘），FP8 是 Hopper 原生精度，又快又准。

**② FP4 是 Blackwell 才有的玩法。** Blackwell 的第五代 Tensor Core 原生支持 FP4，带宽和计算一起省：MLPerf 实测相对 H100 FP16 最高约 5 倍，相对同卡 FP8 约 2 倍。但要注意：NVFP4 在通用任务上能恢复九成七的质量，硬推理任务（数学、逻辑）只恢复八成左右，MMLU-Pro 和数学竞赛类基准会掉到约 80%（2026 年 Qwen3-8B 实测）。做数学应用前必须自己测。

**③ 优先用模型官方发布的量化版。** 比如 Kimi K2 Thinking 的 MoE 组件直接发布 INT4 QAT（量化感知训练）版本，训练时就带着量化在练，精度接近 FP16。官方出了 QAT 版就别自己折腾 GPTQ/AWQ。

## 三、KV 池化：prefill 一次，处处复用

回到上篇的 KV Cache。每个请求都要重新算 prefill 生成 KV Cache，但很多 KV 是重复劳动：多轮对话的历史、RAG 检索的文档、所有人的系统提示，都是同一个前缀。

第二章下篇已经讲过 KV Cache 怎么在网络上传（NIXL、Mooncake 的分离式架构），这篇聚焦引擎侧的缓存复用。

**前缀缓存**：把相同前缀的 KV 缓存下来，新请求直接复用，跳过这段 prefill。SGLang 的 RadixAttention 用前缀树（radix tree）组织缓存，多轮对话、共享前缀场景吞吐能比 vLLM 高约 25–45%（视前缀命中率，来源：SGLang 论文与 2026 评测）。

**KV 池化**：把 KV Cache 从各 GPU 的私有显存里拿出来，放进一个统一的池子（GPU→CPU→NVMe→远端对象存储多级分层），引擎之间共享，像把散落各卡的行李寄存进统一仓库。

![fig10-kvpool.png](https://developer.qcloudimg.com/http-save/yehe-11479707/033bf201f38efb1db6dd6341dd7b90ca.png)

2026 年这条赛道的几个玩家（来源：各项目 2026 发布与评测）：

- **LMCache**：给 vLLM/SGLang 加 KV 复用层，TTFT 最多降五到九成；分层卸载（GPU→CPU→SSD→Redis/S3）加 CacheBlend 支持任意位置复用（不止前缀匹配）。2026 年 agent 多轮流量把传统前缀缓存打崩（命中率跌破两成），LMCache 用 CacheBlend 做到数倍提升。
- **Mooncake**（月之暗面开源）：以 KV Cache 为中心的分离式架构，128K 长上下文场景吞吐提升最高约 5–6 倍（复用它主要看缓存命中收益，架构细节见第二章下篇）。
- **NVIDIA Dynamo**：Smart Router 用 RadixTree 做前缀匹配，对话场景前缀共享率可达六到八成（第三方生产实测区间），配合分布式 KV Cache 管理器跨节点共享。
- **阿里云 Tair KVCache**：RDMA 全链路加速，长上下文 TTFT 降近八成、吞吐提升数倍。

KV Cache 正在从"用完即弃的临时缓冲"变成"和模型权重一样重要的资产"。谁缓存做得好，谁的单位 token 成本就低一截。

## 四、MoE 推理并行：万亿参数怎么在集群上跑

1 万亿参数的模型，任何单卡都装不下，必须并行。推理侧有五种基本并行策略（书第 15 章）：

| 策略           | 切什么          | 适合场景           | 代价                       |
| ------------ | ------------ | -------------- | ------------------------ |
| **张量并行 TP**  | 层内的权重矩阵      | 单层太宽放不下一张卡     | 每层都要 all-reduce，需 NVLink |
| **流水线并行 PP** | 按层切          | 模型太深           | 流水线气泡，逐 token 解码收益小      |
| **专家并行 EP**  | MoE 专家分布到不同卡 | 大 MoE 模型（关键策略） | 每层 all-to-all 通信         |
| **数据并行 DP**  | 复制整个模型，不同请求  | 扩吞吐最简单         | 内存×副本数                   |
| **上下文并行 CP** | 长序列切块        | 100k+ 超长上下文    | 注意力跨分区通信                 |

MoE 推理的核心是 **EP**：每个 token 只激活少数专家（如 top-2），专家分布在不同 GPU 上，token 通过 all-to-all 通信"打车"去找自己的专家。

![fig10-moe.png](https://developer.qcloudimg.com/http-save/yehe-11479707/dd96726d52f021e1a0af1c687f5a7587.png)

EP 有两大坑，对应两个关键参数：

- **容量因子（capacity factor）**：限制每个专家每批最多接多少 token（通常设为平均负载的 1.2–1.5 倍）。否则热点专家会被塞爆，成为 straggler，拖慢整个推理（书第 15 章）。
- **专家负载不均衡**：门控网络如果总把 token 路由到少数"热"专家，这些专家就成了瓶颈。解法是训练时的负载均衡损失，加推理时把热专家复制到多张卡分担。

实践中没人用单一策略：常见组合是 EP + TP + DP（EP 切专家、TP 切层内权重、DP 复制副本扩吞吐），必要时再加 CP 处理超长上下文，组成"5D 并行"（EP+TP+DP+CP 组合，DeepSeek 惯例另含 attention 层的 DP）。

## 五、顺序别搞反：先量化再投机

很多人一上来就冲投机解码，听起来酷。但我的经验是：量化优先于投机，先算账再炫技。

投机解码的收益高度依赖接受率，而接受率是你上线前算不准的（PayPal 实测只有约三成多，远低于论文里的 70%+）。量化则不同：FP8 的收益是确定的，风险是可控的，几乎零成本上手。

正确的顺序：先量化（确定的收益），再前缀缓存（看流量结构），然后投机解码（算清接受率再上）。PD 分离的落地细节见第二章下篇，这里不重复。

---

## 参考资料

- Chris Fregly, *AI Systems Performance Engineering*, O'Reilly Media（第 15 章并行、第 17 章分离式、第 18 章 KV Cache 调优）
- CallSphere：《Speculative Decoding in 2026: EAGLE-3, Medusa-V2, Self-Speculation》
- appscale：《Speculative Decoding in Production LLM Inference (2026)》
- PayPal 工程博客/技术论文（2026，投机解码生产实践，报道见 The Agent Times / Gentic News）
- ai.rs：《4-Bit Quantization Decoded: INT4 QAT, MXFP4, NVFP4》《Quantization Methods Compared》
- mubibai：《FP4 goes production: how MR-GPTQ and Blackwell killed the 4-bit quality penalty》（2026）
- LMCache / Mooncake / NVIDIA Dynamo / 阿里云 Tair KVCache 官方文档与 2026 评测
- ZOOZ Engineering：《LLM Inference Concepts and Optimization Techniques》（2026）

> 说明：图都为示例。投机解码接受率、量化精度数据来自 2026 年公开论文与评测，不同模型/负载下差异明显；PayPal 案例为媒体报道量级，具体数字以其官方披露为准，文中已标注"据报道"。


decode 慢的根源是串行：一次只能生成一个 token，每步都要把全部权重搬一遍。

AI Infra 系列 · 第四章 推理引擎 (下)：投机解码、量化、KV 池化、MoE 并行，一张卡当两张用

上篇讲了推理为什么慢、引擎怎么选。这篇给真刀真枪的四板斧：投机解码（让模型一次猜好几个 token）、量化（FP8/FP4 把权重塞进更小的盒子）、KV 池化（缓存复用，prefill 一次、处处复用）、MoE 并行（把 1 万亿参数的模型在集群上跑起来）。

运维开发工程师

人工智能

算法

云计算

投机解码用草稿模型加速生成，需注意接受率风险；FP8量化安全优先，FP4适合Blackwell；KV池化提升前缀复用效率，MoE并行需EP+TP+DP组合。建议先量化再投机，平衡收益与不确定性。

全链路加速

对象存储

负载均衡

DeepSeek

路由

Redis

2026上云采购 | AI焕新·智启新局

tione

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI Infra 系列 · 第四章 推理引擎 (下)：投机解码、量化、KV 池化、MoE 并行，一张卡当两张用-腾讯云开发者社区-腾讯云

AI Infra 系列 · 第四章推理引擎 (下)：投机解码、量化、KV 池化、MoE 并行，一张卡当两张用

AI Infra 系列 · 第四章推理引擎 (下)：投机解码、量化、KV 池化、MoE 并行，一张卡当两张用

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI Infra 系列 · 第四章 推理引擎 (下)：投机解码、量化、KV 池化、MoE 并行，一张卡当两张用

AI Infra 系列 · 第四章 推理引擎 (下)：投机解码、量化、KV 池化、MoE 并行，一张卡当两张用

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI Infra 系列 · 第四章推理引擎 (下)：投机解码、量化、KV 池化、MoE 并行，一张卡当两张用

AI Infra 系列 · 第四章推理引擎 (下)：投机解码、量化、KV 池化、MoE 并行，一张卡当两张用