Bonus 3：LLM 推理优化全景手册

推理才是 LLM 应用真正的成本中心。训练是一次性的，推理是 7×24 每个请求都触发；产品体感 TTFT 200ms 还是 2000ms，决定用户留不留。裸跑 Hugging Face Transformers model.generate() 在 A800 上单流约 30 tok/s；vLLM / SGLang 这类专用引擎可以做到 500+ tok/s，显存利用率 95%+。

整篇围绕「同一张卡，怎么把 LLM 推理压到工程基线」展开：框架选型、量化、KV cache、speculative decoding，外加一组实测 benchmark 兜底。训练优化决定能不能做出来，推理优化决定养不养得起。

1. 主流推理框架全景

1.1 八大引擎对比

1.2 选型决策树

追求极致 latency, 全 NVIDIA + 愿意搞 Triton → TensorRT-LLM
通用 LLM serving, 中文 + 国产模型为主       → LMDeploy
通用 LLM serving, 国际生态                  → vLLM（默认）
prompt 大量复用 (RAG / agent)               → SGLang
端侧 / 笔记本 / CPU                         → llama.cpp / Ollama
HF Hub 强绑定                               → TGI

实战默认 vLLM 起步，把指标榨干后再考虑切 SGLang / TensorRT-LLM。

2. 实测：vLLM Concurrency Benchmark

测试环境：A800-SXM4-40GB · vLLM 0.6.5 · Qwen2.5-3B-Instruct（BF16）· max_model_len=2048 · gpu-memory-utilization=0.85。

2.1 测试代码

固定 8 条不同 prompts，流式 stream=True，max_tokens=128，按并发档位采集每请求 TTFT + TPOT：

import asyncio, time
from openai import AsyncOpenAI

client = AsyncOpenAI(base_url="http://10.43.165.182:8000/v1", api_key="not-needed")

async def one_call(prompt, max_tokens=128):
    t0 = time.perf_counter(); first_t = None; n_out = 0
    stream = await client.chat.completions.create(
        model="qwen2.5-3b",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=max_tokens, temperature=0.3, stream=True,
    )
    async for chunk in stream:
        if chunk.choices and chunk.choices[0].delta.content:
            if first_t is None: first_t = time.perf_counter()
            n_out += 1
    t_end = time.perf_counter()
    return {
        "ttft": (first_t - t0) * 1000,
        "tpot": (t_end - first_t) * 1000 / max(n_out - 1, 1),
        "total_ms": (t_end - t0) * 1000, "n_out": n_out,
    }

2.2 实测结果

2.3 数据解读 —— Continuous Batching 在表演

TPOT 不变是 vLLM 的「魔法」：传统 batched inference，batch=16 时单 token 生成时间应当接近线性增长（每步矩阵更大，显存带宽更紧）。但 PagedAttention 把 KV cache 分页，attention 计算在 batch 维度真正并行化，token 生成时间几乎独立于 batch size。

TTFT 上涨快不是 vLLM 的锅，是 prefill 本身计算密度高（整个 prompt 一次性进 attention），batch 越大 prefill 越慢。生产里要么（1）--enable-chunked-prefill 让 prefill 跟 decode 混合调度，要么（2）用 SGLang 的 prefix caching 把重复 system prompt 一次性命中，降低 prefill 量。

2.4 TCO 推算

• 单 A800 40GB 跑 Qwen2.5-3B（~6 GB BF16），conc=16 吞吐 588 tok/s
• 假设单请求 200 tokens 输出 → ~0.34s 输出 → 单卡稳态 ~2.9 req/s ≈ 250K req/day（24×7）
• 月成本按 A800 公有云 ¥15/h 估：¥10,800 → 每 request 约 ¥0.0014

这条数线是后面所有量化 / 蒸馏 / spec decoding 优化的对比基线。每砍掉 30% 单 request 成本，年化就是六位数。

3. 量化技术全景

3.1 主流量化方法

3.2 量化方式选择

H100/H200 + 极致吞吐       → FP8 (TensorRT-LLM)
A100/A800/L40 + 通用 LLM   → AWQ + Marlin (vLLM / LMDeploy)
RTX 3090/4090 个人推理     → AWQ 4bit
端侧 / Apple Silicon / CPU → GGUF Q4_K_M (llama.cpp)
显存极紧 W8A8 都量化       → SmoothQuant
训练就要量化感知           → QLoRA (NF4)

3.3 AWQ vs BF16

业内公认数据（vLLM 官方 benchmark + Qwen 团队论文）：

核心结论：A800 上 AWQ 把同尺寸模型显存压到 1/3，latency 反而降低（memory-bound 场景下 4bit 加载更快），质量损失 <1%。生产 LLM serving 默认就上 AWQ。

4. Speculative Decoding 全景

4.1 核心思想

慢路（target model, 7B）：   输出 1 token / step
快路（draft model, 0.5B）：  快速猜 N 个 token
然后 target 一次 forward 验证 N 个猜测 → 接受多少算多少

如果 draft 猜得准，N step 的工作量被压缩到 1 step，latency 直接 2-3×。

4.2 三种 speculative 方法

4.3 vLLM 开启 speculative decoding

# n-gram（零额外模型，最简，先试这个）
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --speculative-model "[ngram]" --ngram-prompt-lookup-max 4 --num-speculative-tokens 5

# draft model（经典）
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --speculative-model Qwen/Qwen2.5-0.5B-Instruct --num-speculative-tokens 5

# eagle（需要 EAGLE checkpoint）
vllm serve meta-llama/Llama-3.1-70B \
  --speculative-model yuhuili/EAGLE-LLaMA3.1-Instruct-70B --num-speculative-tokens 5

4.4 何时开 / 何时关

工程权衡：speculative decoding 不是「白送」的加速 —— 验证失败的 step 浪费两次 forward。代码/JSON 这种模式可预测的输出才划算，自由对话场景接受率低于 60% 就会负优化。

5. KV Cache 优化

KV cache 是 LLM serving 的「显存吞噬兽」。对 7B 模型，seq_len=2048 时单 sequence KV cache ≈ 1.5 GB。

5.1 PagedAttention（vLLM 原创）

把 KV cache 切成固定大小 block（默认 16 token / block），仿 OS 虚拟内存管理：

效果：同样显存能塞下 3-4× 并发请求（本次 conc=16 比 conc=1 吞吐 12.6× 一半归功于此）。

5.2 Prefix Caching

system prompt 通常几百 tokens 且大量请求复用。Prefix Caching 把 system prompt 的 KV cache 算一次，后续请求复用 —— vllm serve ... --enable-prefix-caching。RAG/Agent 场景 system prompt 占比 80% 时，TTFT 降 60-90%。

SGLang 的 RadixAttention 是 prefix caching 的「自动版」—— 基于 radix tree 自动识别共享前缀，不需要手动声明 cache。这就是 SGLang 在 RAG/Agent 场景能比 vLLM 快 1.5-2× 的原因。

5.3 KV Cache Offload / Quantization

显存装不下时把不活跃 sequence 的 KV cache swap 到 CPU memory —— vllm serve ... --swap-space 16（16 GB CPU swap）。代价是 swap 时 latency 抖动几百 ms，生产只用做峰值保护。

--kv-cache-dtype fp8_e5m2 让 KV cache 显存减半，质量损失 <1%。H100/H200 上几乎是免费午餐。

6. 端到端选型决策表

6.1 按场景选

6.2 综合优化清单

• 基础选 vLLM 起步（生态最大，坑最少）
• 必开 prefix caching（--enable-prefix-caching）+ chunked prefill（--enable-chunked-prefill）
• 必开 AWQ 量化（Qwen / Llama / InternLM 都有官方 AWQ 版）
• 试 speculative decoding（[ngram] 零成本，先试再说）；H 系列卡试 FP8 KV cache
• --max-num-seqs 256-1024、--max-num-batched-tokens 4096-8192（按显存和 prompt 长度调）
• 加 Prometheus + Grafana 监控（vllm_* metrics 全套），HPA 基于 vllm_num_requests_waiting

7. 一句话总结

PagedAttention 解决显存碎片 · Continuous Batching 解决调度并行 · AWQ 量化解决模型尺寸 · Speculative Decoding 解决 latency 上限 · Prefix Caching 解决重复 prompt。

这五项叠起来，单 A800 把 Qwen2.5-3B 推到 588 tok/s @ TPOT 24ms，这就是当下 LLM serving 的工程基线。

面试常见题

Q1：PagedAttention 到底解决了什么问题？

传统连续分配的 KV cache 每个 sequence 一上来就按 max_seq_len 预留显存（比如 2048 tokens 全留），实际只用 200 个 token 就结束的请求，剩下 1800 个 token 显存全是碎片，整卡显存利用率 ~30%。

PagedAttention 把 KV cache 切成固定大小 block（默认 16 token / block），仿 OS 虚拟内存做按需分配 + indirection 表。显存碎片从 60-80% 砍到 <4%，利用率拉到 95%。直接结果：同样显存能塞下 3-4× 的并发请求。

深问：为什么不直接动态分配？ —— attention kernel 要求 KV cache 物理连续才能高效访问，PagedAttention 在 CUDA kernel 里加了一层「block table」做间接寻址，付出极小 kernel 复杂度换来巨大显存收益。

Q2：Continuous Batching vs Static Batching 区别在哪？

Static batching 固定一批 N 个请求，全部跑完才开始下一批 —— 短请求被长请求拖死，GPU 利用率 30-40%。

Continuous batching（vLLM 默认）在每个 forward step 边界检查谁结束了、谁可以加入，新请求随时「插队」进当前 batch。短请求一结束就出，长请求继续跑，GPU 利用率 90%+。本质是「在 token 维度做调度」而不是「在 request 维度做调度」。这是 vLLM 单卡吞吐能从 30 tok/s 拉到 500+ tok/s 的核心机制之一。

Q3：TTFT 和 TPOT 是什么？怎么影响 SLO 设计？

• TTFT（Time To First Token）：用户按下 Enter 到看到第一个字的延迟，决定「响应感」。受 prefill 阶段（整个 prompt 一次性过 attention）影响最大。
• TPOT（Time Per Output Token）：每个后续 token 的平均生成时间，决定「打字速度」。受 decode 阶段 + batch size 影响。
• Throughput（tok/s）：单位时间总产 token 数，决定「单卡能养多少用户」。

生产 SLO 一般：TTFT p50 < 300ms / p99 < 1s（聊天体感临界点）；TPOT p50 < 50ms ≈ 20 tok/s（比人类阅读速度快才不卡顿）；单卡 throughput > 500 tok/s @ A800（经济性下限）。

三个指标互相打架：开 chunked prefill 会让 TTFT 抖动小但峰值 throughput 略降；开大 batch 会拉 throughput 但 TPOT 变差。按业务排优先级 —— 对话 → TTFT，批处理 → throughput，代码补全 → TPOT。

Q4：Speculative Decoding 的工程权衡有哪些？

收益：draft 猜对的 step 等于「N step 工作量压成 1 step」，理论上限 N×。代价四条：

1. 验证失败的 step 等于白跑 —— draft forward 一遍 + target 验证一遍，两边都白干
2. draft 跟 target 体量差太大接受率低 —— 0.5B 对 70B 接受率可能 <40%，反而拖慢
3. 高并发下边际收益小 —— batched decode 本来就把 GPU 喂饱了
4. 代码 / JSON / 表格场景接受率高（n-gram 60%+），自由对话低（30-40%）

落地原则：先用 [ngram] 零成本试，看接受率指标（vllm_spec_decode_num_accepted_tokens_total）；接受率 >50% 才考虑上 draft model 或 EAGLE。

Q5：怎么做 LLM 推理的 TCO 优化？

按性价比从高到低：

1. 量化（AWQ / FP8） —— 显存减 1/3 到 1/2，吞吐 +30-50%，质量损失 <1%。性价比最高，默认动作
2. Prefix caching —— RAG/Agent 场景 system prompt 复用，TTFT -60%，几乎零成本
3. Speculative decoding —— 代码 / JSON 场景 latency -50%，自由对话场景可能负优化
4. 模型蒸馏（7B → 3B 同任务） —— 成本 -50% 起步，但要训练投入 + 评测验证质量
5. Spot GPU / 低优先级实例 —— 公有云成本 -60-70%，要做好被抢占时的 graceful degradation

成本模型粗算：baseline（A800 跑 Qwen2.5-3B BF16）每 request ¥0.0014。加 AWQ 吞吐 +30% → ¥0.0011；再加 prefix caching（RAG prompt 复用 80%）→ ¥0.0005；再切 Spot GPU → ¥0.0002。一年下来差几十万。

下一步

推理优化的几条主线（量化、batching、KV cache、speculative）都铺完后，下一篇 Bonus 4 转向长上下文工程：100K+ context 怎么不爆显存、attention 复杂度怎么从 O(n²) 砍到 O(n log n)、RoPE / YaRN / Ring Attention 这些扩展技巧的工程取舍。