大模型推理优化：量化、缓存与请求合并实现

讲解 vLLM 的量化、Automatic Prefix Caching 与 Speculative Decoding 配置，分别处理模型内存、相同前缀复用和 token 间延迟，并给出硬件核对与验证步骤。

大模型部署可用三条路径优化 vLLM：按 vLLM 量化说明以更小的内存占用换取模型精度，用 Automatic Prefix Caching 说明复用相同前缀的 KV cache，再通过 Speculative Decoding 文档配置中低 QPS、内存受限负载下的 token 间延迟优化。它们不是可以随意叠加的“万能开关”：量化先受硬件条件约束，APC 的收益取决于请求是否共享前缀，请求合并则应落实到 Speculative Decoding 的配置入口。

大模型部署前：先固定部署边界

开始前，把 GPU compute capability、模型原始精度与量化格式、本地模型目录或 repo_id、tokenizer 来源、上下文长度、输出形态和典型 QPS 写入部署单。同时记录业务是否反复提交同一长前缀、是否是多轮对话；这决定 APC 是否有可复用对象，也决定是否应验证 Speculative Decoding。

启动参数、认证方式和 API endpoint 应以所用 vLLM 版本的当前服务文档为准。下面只保留已给出的参数、配置键和路径片段，不补造模型名、JSON 字段或统一 endpoint。

量化：先核对硬件，再制作并加载模型

如果选择 FP8，FP8 W8A8 指南要求 W8A8 计算使用 compute capability >= 8.9 的 NVIDIA GPU；Turing/Ampere 可通过 Marlin kernels 运行 weight-only W8A16。不要把“模型能够读取”当成当前硬件具备 W8A8 条件。

制作与加载按同一量化流程执行：vLLM 和 llm-compressor 应使用独立环境；FP8_DYNAMIC recipe 面向 Linear layers、忽略 lm_head，不需要 calibration data。先安装工具：

pip install llmcompressor

文档给出的 recipe 定义是：

recipe = QuantizationModifier(
    targets="Linear",
    scheme="FP8_DYNAMIC",
    ignore=["lm_head"],
)

保存后的本地目录用下面的形式加载：

llm = LLM("./Meta-Llama-3-8B-Instruct-FP8-Dynamic")

若输入是 BF16/FP16 模型，也可把 --quantization="fp8_per_tensor" 作为加载参数，在不准备 calibration data 的情况下启用 FP8。在线 dynamic FP8 会在每次 forward pass 计算 activation 的最小值和最大值，因此文档也明确指出这种模式的 latency 改善有限。

缓存：开启 APC，并让请求真正共享前缀

在 Python engine 中，APC 使用说明使用 enable_prefix_caching=True 控制该功能。系统保存既有请求的 KV cache，新请求只有共享相同 prefix 时才能复用；它缩短 prefill，不缩短 decode。重复问题作用于同一长文档以及多轮聊天最符合条件，若答案很长或新请求没有共同前缀，文档明确指出不会获得 performance gain。

enable_prefix_caching=True

实现上，APC 设计文档说明每个 KV-cache block 会结合块内 tokens 和此前前缀进行哈希，而且只缓存完整 blocks。额外哈希值还包括 LoRA IDs、多模态输入哈希和用于隔离租户的 cache salts；仅有语义相似、但 token 前缀不同，并不等于可以复用。

从 v0.11 开始，默认哈希算法是 sha256。需要可复现的跨语言哈希时，可使用文档给出的参数组合：

--prefix-caching-hash-algo sha256_cbor

验证时，提交两条拥有相同长前缀、仅结尾不同的请求，并观察 prefill 是否复用；不要用生成阶段的长短来判断 APC 是否生效。

请求合并：配置 Speculative Decoding

本文不把“请求合并”解释为把不同用户请求直接拼成一个 prompt，而是限定为 Speculative Decoding 的配置能力。官方说明指出，EAGLE、MTP、draft models、PARD 和 MLP 等 model-based methods 可获得较大的延迟降低；n-gram 与 suffix decoding 的加速较温和，而且不会增加峰值流量期间的工作量。

所有 speculative decoding 设置都通过 --speculative-config 传入一个 JSON object：

--speculative-config "YOUR_VALUE"

YOUR_VALUE 必须替换为当前版本所选方法对应的完整 JSON 对象。所引官方页面没有提供通用对象示例，因此不要猜测方法字段或模型路径；服务返回文本也不足以证明 speculative decoding 路径已经启用，应按当前版本的启动日志和监控说明确认配置状态。

内存设置与上线验收

vLLM 内存配置文档给出的直接设置包括：用 CUDA_VISIBLE_DEVICES 选择设备，而不是在 vLLM 启动前调用 torch device functions；降低 max_model_len 和 max_num_seqs 可以减少内存使用。CUDA graphs 默认启用并占用额外显存，内存紧张时可评估 enforce_eager，它会完全关闭 graph capture。

CUDA_VISIBLE_DEVICES
max_model_len
max_num_seqs
enforce_eager

上线时每次只调整一类设置，并保存配置、启动日志、代表性请求和输出。量化应检查模型能否按指定目录加载；APC 应检查共同前缀的 prefill 复用；Speculative Decoding 则应检查完整 JSON 是否被当前版本接受。具体 endpoint 和指标名称若不在本文所列文档中，应回到当前版本继续核对。

本文步骤依据正文所链接的 vLLM 官方文档整理，未运行命令或进行性能测量；使用前应按当前版本重新检查参数、硬件兼容性和 JSON 字段。