Inference Optimization

Decode 是 memory-bound：continuous batching 是第一杠杆

背景与原理

推理分两段，瓶颈完全不同：prefill（处理 prompt）能并行算所有 token，是 compute-bound；decode（逐个生成）每步只算 1 个 token，却要把整个模型权重重新从 HBM 搬一遍——算术强度极低，GPU 的 Tensor Core 大半闲置，真正的瓶颈是显存带宽。这就是为什么 batch=1 时再贵的卡也跑不满。

解法是把多个请求的同一 decode step 拼成一个 batch：权重搬一次，同时为 N 个请求各算一个 token，吞吐近似线性放大。但传统 static batching 有致命缺陷——它等整个 batch 里最长的序列生成完才能释放，短请求被长请求拖死，GPU 利用率随生成进度暴跌。Orca（OSDI'22）提出 iteration-level scheduling（即 continuous batching）：每个 decode step 结束就动态踢出已完成的、塞入排队的新请求，GPU 永不空转。Anyscale 实测对比 HF 朴素实现达到 23× 吞吐。这是单一改动里收益最大的。

实战示例

# vLLM 默认就是 continuous batching，一行起服务
vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --max-num-seqs 256          # 并发请求上限，决定 batch 能多大

# 诊断你到底是不是 memory-bound / under-batched：
# 压测时盯 nvidia-smi —— 若 GPU-Util 高但 SM 算力占用低、显存带宽打满
# 且吞吐随 batch 几乎线性上涨 → 你被内存带宽卡住，加 batch 就赚
nvidia-smi dmon -s u        # 看 sm% 与 mem% 的差距

记住分工：throughput（吞吐）靠加 batch，latency（延迟）靠减 batch——这是一对零和。先想清你优化的是哪个。

KV cache 才是内存霸主：PagedAttention + prefix caching

背景与原理

continuous batching 想拉大 batch，但 batch 越大、序列越长，KV cache 吃的显存越多——长上下文下它能超过权重本身。大小估算（标准公式，非引用具体数字）：

KV_bytes ≈ 2 × n_layers × n_kv_heads × head_dim
           × seq_len × batch × dtype_bytes
# 「2」= K 和 V 两份；一条 8K 上下文的请求，KV 可达几百 MB

传统做法给每个请求连续预留「最大长度」的显存，但请求实际长度不一，导致 60-80% 显存被碎片和过度预留浪费——能放下的 batch 被白白压小。PagedAttention（vLLM 的核心，SOSP'23）照搬操作系统的虚拟内存：把 KV cache 切成固定大小的 block（页），非连续存储、按需分配，浪费降到 4% 以下，等价于 batch 翻倍、吞吐 2-4×。

第二招是 prefix caching：多个请求若共享相同前缀（system prompt、few-shot 示例、长文档），那段前缀的 KV 只算一次、跨请求复用。这正是 Anthropic prompt caching 在服务端的原理——你把稳定内容放前面、变动内容放后面，命中缓存就省掉重复 prefill。

实战示例

# vLLM 开 prefix caching + 量化 KV cache（再省一半显存）
vllm serve  \
  --enable-prefix-caching \    # 相同前缀的 KV 自动复用
  --kv-cache-dtype fp8         # KV 用 fp8，显存腰斩、吞吐再涨

# prompt 结构：稳定前缀在前，变动在后 —— 才能命中前缀缓存
[system + 工具定义 + few-shot]   ← 跨请求逐字节相同 → 缓存命中
[用户本轮输入]                   ← 每次不同 → 只 prefill 这一小段

Speculative decoding：小模型偷跑，吞吐翻倍且输出不变

背景与原理

关键洞察接着 §1：decode 时 GPU 算力本来就闲着，那不如一次 forward 多算几个 token 的概率。Speculative decoding（Leviathan et al., ICML'23）让一个便宜的 draft 模型先快速猜出 k 个候选 token，再让大模型一次并行验证这 k 个——接受最长的正确前缀，在第一个分歧点重采。draft 猜得准就一步前进多个 token，猜错也只是回退到正常速度。

最反直觉的一点：通过 rejection sampling，最终输出分布与原模型严格一致——这是无损加速，不是近似。加速比取决于 acceptance rate（draft 猜中率）与 draft/target 的成本比。Medusa（arXiv 2401.10774）更进一步：不用单独 draft 模型，给原模型加几个轻量 decoding head + tree attention 自己猜自己，省掉维护两个模型的麻烦，实测 2.3-3.6×。

实战示例

# vLLM：用小模型当 draft（必须同 tokenizer，小 10-20×）
vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model meta-llama/Llama-3.2-1B-Instruct \
  --num-speculative-tokens 5     # 一次猜 5 个，太多反而拖慢

# 无现成 draft 模型时，用 n-gram 投机（零额外模型，靠上文重复）
  --speculative-model "[ngram]" --ngram-prompt-lookup-max 4

选引擎与量化：vLLM / TGI / TensorRT-LLM 的工程权衡

背景与原理

三大开源引擎都实现了 §1-§3 的核心优化，差别在峰值性能 vs 部署灵活 vs 上手成本这三角的取舍：

• vLLM：PagedAttention 原生、迭代最快、Python 生态友好、上手最低。多数自建场景的默认起点。
• TGI（HuggingFace）：生产 ready、和 HF 生态/Endpoints 无缝、支持多后端（含 TRT-LLM）。要稳定运维选它。
• TensorRT-LLM（NVIDIA）：NVIDIA 卡上的极致性能，但需针对具体 GPU 架构预编译 engine，运维最重、灵活性最差。追求每瓦/每卡最高吞吐、且模型/硬件稳定时才值得。

第二大杠杆是量化：把权重从 fp16 压到 int4/fp8。因为 decode 是 memory-bound（§1），权重更小 = 搬运更快 = decode 直接加速，同时省显存能放大 batch。weight-only int4（AWQ / GPTQ）显存腰斩还提速；fp8（权重+激活）需 Hopper 及以上架构，精度损失更小。

实战示例

# 决策速记
快速验证 / 自建 / 迭代频繁     → vLLM
HF 生态 / 要稳定生产运维       → TGI
NVIDIA 卡榨干性能 / 模型稳定   → TensorRT-LLM

# 量化选型
显存紧、要塞下大模型           → AWQ int4（weight-only）
Hopper+、要精度也要速度        → fp8（权重 + KV cache）
vllm serve  --quantization awq   # 一个 flag 开