BANYIXIA · TECH TALK
01 / 08
LLM 推理加速
vLLM 实战 + PagedAttention 原理
为什么裸 Transformer 推理一上 batch 就 OOM,而 vLLM 能把 70B 模型跑出 16 倍吞吐 — 我们从工程到原理走一遍。
讲者 林某 · banyixia 工程师
场合 2026 GTC China
时长 45 min
办一下 · 技术演讲稿 · tech-pres skill · 工程师风格
INTRO
02 / 08
为什么这个 topic 现在最重要
如果你做 ToB SaaS,LLM 推理成本已经是你云账单上最贵的一行。
- 38% · LLM 推理占 ToB SaaS 总云成本 (Anthropic 2026 Q1 公开报告)
- $0.001/call · SDR / Customer Support 等 high-volume 场景的 unit economics 红线,跨过这条线产品才有毛利
- OOM · 裸 PyTorch + HuggingFace Transformers,batch_size 一过 8 就在 A100 80G 上爆显存
- 结论 · 推理引擎选型不是「nice to have」,是 ToB 产品能不能挣钱的临界变量
本节 take-away
推理成本不是基础设施问题,是商业模式问题。
办一下 · 技术演讲稿 · tech-pres skill · 工程师风格
WHY
03 / 08
问题 · 三个根本矛盾
为什么单卡推理不能简单堆 batch_size?三个绕不开的矛盾。
CONFLICT 01
batch ↔ memory
batch 越大 throughput 越高,但 GPU memory 是硬瓶颈。70B 模型 fp16 权重 140GB,KV cache 还要再吃 30-50GB。
CONFLICT 02
seq_len 长尾
同一个 batch 内 request seq_len 差距 5-10x。padding 到最长那条,短 request 全程在算 zero token,GPU 算力浪费 60%+。
CONFLICT 03
KV cache 锁死
KV cache 占总 memory 的 70-80%。常规 PyTorch 用连续 tensor 存,一加载就按最长 seq_len 预分配,中途释放不了。
→ 三个矛盾相互纠缠,任何单点优化(更大显卡 / 量化 / 算子融合)都解不开。需要换一个 memory 管理范式。
办一下 · 技术演讲稿 · tech-pres skill · 工程师风格
WHAT
04 / 08
PagedAttention · 把 KV cache 当 virtual memory 管
UC Berkeley 团队 2023 年的核心 idea — 借 OS 的 virtual memory + paging 思路,重做 KV cache。
IDEA 01 · BLOCK
固定 16-token 切块
把每个 request 的 KV cache 切成固定大小的 block(默认 16 token / block),像 OS 的 page。block 之间在显存里不需要连续。
IDEA 02 · SHARE
block table 跨 request 共享
不同 request 如果有相同 prefix(system prompt、few-shot 示例),指向同一组 block。Prefix caching 命中率 60%+ 是常态。
IDEA 03 · ON-DEMAND
按需分配,零 padding
request 真长到第 N 个 token 才分配第 N/16 个 block。短 request 占用小,长 request 也不抢占,内存碎片率 < 4%。
一句话 take-away
让 KV cache 像 ext4 那样有 inode — 物理不连续,逻辑可寻址,按页分配按页回收。
办一下 · 技术演讲稿 · tech-pres skill · 工程师风格
HOW · ARCH
05 / 08
vLLM 架构 · 五个核心组件
请求从用户进入 vLLM 到流式回流的完整 5 跳路径。
办一下 · 技术演讲稿 · tech-pres skill · 工程师风格
HOW · CODE
06 / 08
vLLM · 10 行代码起一个 70B 服务
# vllm_demo.py — 4×A100 跑 Llama-2-70b 异步批量推理
from vllm import LLM, SamplingParams
# 1. 启动一个 70B 模型,fp16,tensor parallel 横切 4 卡
llm = LLM(model="meta-llama/Llama-2-70b-hf", tensor_parallel_size=4)
# 2. SamplingParams · max_num_batched_tokens 决定吞吐天花板
sampling_params = SamplingParams(temperature=0.7, top_p=0.95, max_tokens=512)
# 3. 异步批量推理 — vLLM 内部自动 continuous batching + PagedAttention
outputs = llm.generate(prompts, sampling_params)
for output in outputs:
print(output.outputs[0].text)
LINE 5 · LLM(...)tensor_parallel_size=4 横切 attention head 到 4 卡,通过 NCCL all-reduce 同步。
LINE 8 · SamplingParams真正决定吞吐的是引擎层 max_num_batched_tokens(默认 2048),非这里 max_tokens。
LINE 11 · generate(...)同步签名背后是异步队列,Scheduler 按 token-level 而非 request-level 编排,实现 continuous batching。
办一下 · 技术演讲稿 · tech-pres skill · 工程师风格
DEMO · BENCH
07 / 08
实测吞吐 · vLLM vs HuggingFace Transformers
BENCH SETUP
- HW
- 4 × A100 80G · NVLink
- Model
- Llama-2-70b-hf · fp16
- Batch
- 64 requests · concurrent
- Seq len
- avg 1024 · max 2048
- Warmup
- 50 req · 测 200 req 平均
同硬件、同模型、同 batch · 仅替换推理引擎。16.5x 提升的核心来源:零 padding 浪费 + continuous batching 让 GPU 利用率从 17% → 89%。
办一下 · 技术演讲稿 · tech-pres skill · 工程师风格
Q & A
08 / 08
预设问答 · 三个最常被问的
PagedAttention 跟 FlashAttention 是啥关系?替代还是配合?
配合,不冲突。FlashAttention 优化的是 attention 的 计算层 — 通过 tiling + 不存中间 softmax 减少 HBM 访问,降低单次 attention 算子耗时。PagedAttention 优化的是 KV cache 的 存储层 — 解决 memory 碎片和分配。vLLM 0.4+ 默认把两者叠起来用,kernel 内部既 page 又 flash。
vLLM 跟 TensorRT-LLM 怎么选?生产环境哪个更稳?
看 trade-off。vLLM 胜在易用 + 模型支持广 + 社区迭代快,Python 接口,改 sampling 改 schedule 一行代码。TensorRT-LLM 胜在峰值吞吐(约比 vLLM 高 15-25%)+ NVIDIA 深度优化的 fp8 / int4 kernel,但编译复杂,新模型支持滞后 1-2 个月。我们生产用 vLLM,只有单一模型长期服务的离线批处理场景才上 TRT-LLM。
中文场景吞吐还能怎么再优化?tokenizer 是不是有坑?
三招。① 换中文 tokenizer 友好的模型(Qwen / DeepSeek 的 vocab 对中文压缩比 1.4-1.7 token/字,Llama 是 2.3-2.8 token/字,直接省 40%+ token 数);② 开 prefix caching,system prompt 长的场景(RAG / agent)命中率能到 70%;③ int4 量化(AWQ / GPTQ),显存省 4x,吞吐再涨 1.8-2.2x,中文质量损失 < 1% PPL。
→ slides + 代码 demo + bench 数据 已开源 / 微信公众号「办一下工程笔记」回复 vllm 获取
办一下 · 技术演讲稿 · tech-pres skill · 工程师风格