5.2 进阶路线与作者真心话：投机解码、prefix caching 与自研调度

5.2 进阶路线与作者真心话：投机解码、prefix caching 与自研调度

写这一节的时候我有点犹豫——进阶方向这种话题很容易写成"未来展望"的鸡汤，空喊几个名词然后劝你"持续学习"。我尽量避开这种坑。下面写的每个方向，都是我自己至少做过 POC、看过源码、或者帮团队评估过的，会讲清楚它解决什么问题、收益多大、坑在哪、什么场景值得追什么场景不值得。最后会留几句不太技术但我觉得比技术更重要的真心话。

方向一：投机解码（Speculative Decoding）

投机解码是这两年最火的推理加速方向之一，我自己在生产上做过验证，效果是真实的。但它的适用场景比很多人想象的窄。

原理简单讲——用一个小的"草稿模型"快速生成几个候选 token，再用大模型一次性验证这些候选，验证通过的 token 直接采纳。因为大模型验证多个 token 是一次 forward，比逐个生成快很多，所以总体能加速。加速比取决于草稿模型的"命中率"——草稿模型猜得越准，加速越多。

我自己在 DeepSeek V4 上做过实验，用 DeepSeek 的一个小尺寸模型作为草稿。结论是：在开放式生成任务上（对话、续写），命中率能到 60-70%，端到端加速 1.5-2 倍；在严格任务上（代码、数学），命中率掉到 30-40%，加速只有 1.1-1.2 倍，加上草稿模型本身的计算开销，有时候甚至更慢。所以投机解码不是通用加速，是任务相关的。

坑也很实在。第一，草稿模型选择是个艺术——太小学不到大模型的分布（命中率低），太大失去加速意义。第二，草稿模型和大模型要"分布对齐"，不然就算猜对了 token 验证也可能不通过（因为概率分布差异）。第三，目前 vLLM 的投机解码支持还在快速演进，配置略繁琐，效果也依赖具体版本。

我的判断是：如果你的业务是开放式生成为主、对延迟敏感，投机解码值得一试；如果是严格任务或者对吞吐（不是延迟）敏感，性价比不高。这块的未来方向是用模型本身做"自投机"——用模型较浅的层预测 token、深层验证，省掉独立草稿模型。这条路上 vLLM、SGLang 都在探索，值得关注。

方向二：Prefix Caching（前缀缓存）

这个方向我比投机解码更看好，因为它适用面广、收益稳定、副作用小。

原理——很多请求有公共前缀。比如 system prompt 在所有请求里都一样、多轮对话里历史轮次是重复的、few-shot 示例在多个请求里复用。这些公共前缀的 KV Cache 算一次就够了，后续请求直接复用，能省掉大量重复计算。

收益有多大？我实测过一组对话场景，公共 system prompt 占了整个 prompt 长度的 60%，开启 prefix caching 后 prefill 阶段延迟降了一半多。对于长 system prompt + 短用户输入的场景（比如带大量示例的 in-context learning），收益更显著，prefill 延迟可能降 80%。

坑主要在缓存命中策略。vLLM 的 prefix caching 默认按 token 序列做哈希匹配，要求前缀完全一致。但实际业务里，前缀经常有细微差异（比如时间戳、用户 ID 嵌在 system prompt 里），导致命中失败。我的做法是把会变化的字段挪到 prompt 后部，保证前缀稳定。还有一些场景需要"模糊匹配"（前缀大部分相似但不完全一样），这块目前框架支持有限，要自己写缓存逻辑。

另一个坑是缓存淘汰策略。prefix cache 占显存，缓存太多会挤压 KV Cache 池子，反而影响并发。vLLM 默认 LRU 淘汰，但 LRU 不一定最优（一些低频但重要的 system prompt 被淘汰掉就麻烦）。这块调优空间还有，目前没有标准答案。

我的建议是：prefix caching 默认就该开。它几乎没副作用（命中率低时退化成无缓存，不会更慢），命中率高的场景收益巨大。vLLM 里 --enable-prefix-caching 一行开启，没有理由不开。

方向三：Chunked Prefill 与调度策略优化

这是 vLLM 0.4+ 引入的特性，相对没那么出名但我自己用得很多。

传统的 prefill 是原子的——一个长 prompt 的 prefill 要一次性算完，期间 GPU 全部资源被占用，其他请求的 decode 被阻塞。这导致一个反直觉的现象：服务里混着长 prefill 请求和短 decode 请求时，短请求的延迟会被长 prefill 拖累。

chunked prefill 把长 prefill 拆成多个 chunk，和 decode 请求交错执行。这样长 prefill 不会独占 GPU，短 decode 请求能及时响应。我自己测过，混负载场景下 P99 延迟降了 30-40%，吞吐几乎不变（甚至略升，因为 GPU 利用率更均衡）。

这个特性已经基本成熟，vLLM 默认开启。坑不多，主要是要注意 --max-num-batched-tokens 这个参数——它决定一次 forward 处理多少 token，设大了 chunked prefill 优势不明显，设小了吞吐下降。我一般设 4096-8192，按业务调。

调度策略这块还有更前沿的方向，比如基于 SLA 的调度——根据请求的延迟要求分配优先级，紧急请求插队。这种调度 vLLM 原生不支持，需要自定义。我看过一些团队自己实现了，效果不错但工程复杂。这块目前还是前沿，等框架原生支持再追比较稳。

方向四：自研调度与自研推理引擎

讲到这，不得不聊聊"自研推理引擎"这个话题。我自己参与过两个团队的自研项目，体感是：90% 的团队不应该自研。

理由很实在——vLLM、SGLang、TensorRT-LLM 这些开源框架迭代极快，每两个月就有显著性能提升。自研引擎想跟上这个速度，需要持续投入一支专门团队。我看过几个自研项目，立项时性能领先 vLLM 20%，半年后反而落后 vLLM 30%，因为 vLLM 升级太快了。

什么情况下值得自研？我自己判断有几类：一是你有极其特殊的硬件（比如自研芯片），开源框架不支持；二是你的业务模式极端特殊（比如超长上下文、特定 batch 策略），开源框架优化不到位；三是你是云厂商，推理服务本身就是产品，自研有战略价值。其他情况，用开源 + 上层封装几乎总是更优解。

但"不自研引擎"不等于"完全不能改框架"。我经常鼓励团队做轻量的框架层定制——比如改 vLLM 的调度策略、加自定义 metric、改 KV Cache 管理逻辑。这种改动局限在几百行代码内，跟着 vLLM 主干升级的成本可控，又能解决具体业务痛点。我建议把这种定制和自研引擎区分开，前者是工程实践，后者是战略投入。

方向五：硬件协同与新型加速器

最后聊聊硬件方向。这一块我不是专家，只能讲讲我观察到的趋势。

Hopper 架构（H100）的新特性。Hopper 引入了 FP8 tensor core、transformer engine、TMA（Tensor Memory Accelerator）这些特性，专门为 transformer 推理优化。vLLM、TensorRT-LLM 都在适配这些特性，开启后吞吐和延迟都有显著提升。但用上这些特性需要框架支持，老版本 vLLM 用不全。

下一代架构（Blackwell 等）。新架构进一步强化了低精度计算（INT4/FP4 tensor core）、大显存（HBM3e）、chip-to-chip 互联。这些特性会改变推理的工程实践——比如 FP4 能用的话，INT4 量化可能就不再是显存优化的最优选择，FP4 直接更精准更快。但新架构普及还需要时间，目前看 2026 年下半年开始会有更多团队用上。

国产加速器。前面章节提过国产卡的适配，这块我持续关注。结论不变——理论性能不差，生态成熟度差，关键看未来一两年框架原生支持的进展。

CXL 与内存扩展。CXL 让 CPU 内存能像 GPU 显存一样被低延迟访问，理论上能突破"显存墙"。但目前看大模型推理用 CXL 还很早期，没有成熟方案。

作者真心话

技术方向讲完了，留几句不太技术的话，也是这本书最想传达的几个东西。

第一，部署的真正壁垒不是"知道某个参数"，是"面对陌生问题时的思维方式"。vLLM 的具体参数几个月后就过时了，DeepSeek V4 之后会有 V5、V6，但"先理解对象、再用数据定位、最后针对性调优"这套方法论不会过时。我帮人排查过无数次问题，从来不是因为我知道某个"秘密参数"，是因为我能从原理推到方案。

第二，对任何 benchmark 保持怀疑，包括本书里的。领域变化太快，论文数字、教程数字、官方数字都可能与你的实际情况有出入。养成"看完别人数字自己再测一遍"的习惯，是用这本书最正确的方式。

第三，原理比技巧值钱十倍。vLLM 的某个参数下个月可能改名，但 PagedAttention 的核心思想（把 KV Cache 像虚拟内存一样分页管理）未来十年都不会过时。所以读这本书如果你只能记住一件事，我希望是 PagedAttention 的原理，而不是某个具体配置。

第四，承认局限。我自己做了这么多年部署，依然经常遇到没见过的问题。技术领域没有"全能工程师"，只有"愿意从原理出发解决问题的人"。遇到没见过的问题不可怕，按方法论一步步推就能解决；可怕的是不懂原理瞎试，那叫碰运气。

第五，分享和记录。我自己的很多经验都是踩坑踩出来的，写出来不是炫耀，是希望后来的人少走弯路。你读完这本书、做完自己的部署，也建议把踩过的坑记下来——不是为了别人，是为了未来的自己。半年后你遇到同样问题，翻出自己的笔记比从头排查快十倍。

收尾

教程到这里就结束了。但教程结束的瞬间，才是真正学习的开始——下次你面对一个没部署过的大模型、一台陌生的硬件、一个奇怪的报错，能不能不慌、能不能从原理推到方案、能不能用数据定位问题，才是这本书有没有读进去的真正考验。

vLLM 会继续迭代，DeepSeek 会出新一代，硬件会更新换代，但你现在掌握的这套部署思维，是任何教程更新都夺不走的资产。希望这本教程能让你下次面对大模型部署时，能自信地说一句：我知道怎么把它跑稳、跑快、跑出性价比。

这就够了。