[1] vLLM Page Attention Continuous Batching

视频B站-怎么加快大模型推理10分钟学懂VLLM内部原理KV CachePageAttention文档vLLM官网文档vLLMvirtual LLM伯克利 2023 开源的大模型推理 / 服务框架SOSP 论文用于把开源 LLM 部署成高性能 API 服务核心创新PagedAttention分页注意力解决 KV‑Cache 显存碎片大幅提升 GPU 吞吐量、并发数。定位优先面向Decoder-Only模型生产级推理服务引擎不是训练框架只做推理 Serving。背景痛点传统 HuggingFace / TGI 旧方案Transformer 解码生成时每一步都要保存KV‑Cache每一层 Attention 的 K、V占用绝大部分显存。传统每个请求分配一整块连续显存请求长短不一、不断新建销毁 → 严重显存碎片大量显存浪费60‑80% 浪费并发上不去很容易 OOMOut‑Of‑Memory 爆显存。旧批处理等整批全部请求完成才接收新请求GPU 经常空闲。具体原因在大模型推理时按照可生成最长序列长度分配显存VRAM。造成三种类型的浪费预分配但不会用到预分配但尚未用到显存之间的间隔碎片不足以预分配给下一个文本生成导致KV Cache预分配显存的利用率只有20%-40%。vLLM解决方法Page Attention 分页注意力Sharing KV CacheContinuous Batching 连续批处理Page Attention 分页注意力(核心)借鉴OS中的虚拟内存和页管理技术把 GPU 显存切为很多固定大小物理 Block 块一般每块存 16 个 token 的 KV逻辑上每个对话序列 token 是连续物理显存上Block 可以分散、不连续每个请求维护一张block_table页表记录该请求的逻辑块对应显存中哪一个物理块按需分配生成到哪个 token才分配对应 Block请求结束Block 回收放回全局空闲池类比传统写文件必须分配一整块连续硬盘空间PagedAttention硬盘分很多扇区文件可以散落在不同扇区靠文件分配表记录位置。效果KV‑Cache 显存浪费从 60‑80% 降到 4% 以内同等 GPU 可承载并发大幅上涨。KV BlockvLLM默认block_size16可以启动参数--block‑size修改。对模型每一层每个 Block 保存block_size个 token全部头的 K 向量 全部头的 V 向量。举默认 161 个物理 Block 最多 16 个 token每个 token 保存该层所有注意力头的 K、V。❗不是 1 个 Block 只存 1 个头是该层Layers全部头16 份 token 的 K/V 全部塞在这个物理块。KV Blockblock_size 调参的权衡block_size 调大如 32block_size 调小如 8每个 Block 装更多 token块数量变少块表变短查表开销小块数量变多块表很长间接寻址、调度开销上升速度下降内部碎片变多很多 Block 用不满显存浪费增加碎片变少显存利用率更高虚拟内存在逻辑KV Cache中显存是连续的。虚拟内存vLLM框架会在后台维护一个逻辑KV Cache到实际物理显存KV Block的映射表优点按需分配不提前预分配按Block分配减少碎片大小虚拟内存方便实现调用将KV Cache的利用率从20%-40%提升到96%Sharing KV CachevLLM支持 KV Block 共享分两大类场景都建立在 PagedAttention 块 引用计数 ref‑count 写时复制 COW (Copy On Write)之上。Sharing KV CacheSharing KV Cache-COW分两大类场景场景 1同一个请求内部多分支Beam Search / Parallel Sampling默认就支持同一个 prompt同时生成多条候选输出beam 搜索、n1 并行采样。例子输入同一个 prompt同时生成 2 条候选回答。Prefill 阶段prompt 部分的 KV Block两份序列直接指向同一套物理 Block只算一次 prefill不复制多份 KV。ref_count 变成 2。Decode 阶段两条分支开始生成不一样的新词当某一个分支想要往 Block 追加新 token 的 KV 时检测到ref_count1这块被别人共享。写时复制 Copy‑on‑Write分配全新物理 Block把旧块内容拷贝到新块这个序列的块表切换指向新块旧 Block 继续留给另一条分支共享使用。只有发生分叉的那一刻才复制前面共同上下文全程共享节省大量显存。场景 2跨不同用户请求之间共享 —— Prefix CachingAPC-Automatic Prefix Caching 自动前缀缓存需要手动开启vLLM启动参数enable_prefix_cachingTrue多个完全独立的用户请求开头一大段 token 完全一模一样例如企业服务所有人共用一大段 system 系统提示词。例请求 A【系统提示词】用户A问题请求 B【系统提示词】用户B问题请求 A 先到达prefill 算出系统提示词对应的 KV 物理 Block。请求 B 过来token 开头完全一样vLLM 对每个 Block 做链式哈希发现已经存在一模一样内容的物理 Block。请求 B 的块表直接指向已经存在的物理 Block不重复做 prefill 计算不重复占用显存。ref_count 1。到 token 分叉的位置后面 Block 各自独立分配不再共享。还可以优化Beam search里的显存占用Continuous Batching 连续批处理动态批vLLM-Batch size用更大的batch size来处理请求从而提高吞吐量普通静态 batch必须等 batch 内全部请求生成结束才能塞新请求GPU 大量空转。vLLM 连续批只要某个请求生成结束立刻把新用户请求塞进 batch不用等待整批完成。结合 PagedAttention不同长度、不同生成进度的请求混跑GPU 尽量不空闲最大化 token/s 吞吐量。vLLM优缺点vLLM 主要能力原生 OpenAI 兼容 API 接口可直接对接 LangChain、LangGraph、RAG 系统支持流式输出vLLM分布式推理张量并行 TP、流水线并行 PP支持 70B、405B 大模型多卡运行丰富量化AWQ、GPTQ、INT4/INT8、FP8支持多 LoRA 同时加载服务前缀缓存 Prefix‑Caching多个请求共享相同 system promptKV 块复用减少重复计算支持推测解码、CUDA Graph 加速对接 K8s、监控指标适合线上生产部署vLLM优点高并发吞吐量极强同等硬件对比原生 transformers吞吐量提升数倍二十多倍线上 API 服务首选稀土掘金长上下文友好128K、256K 长对话 / RAG 场景显存碎片被抑制不容易 OOM生态好直接加载 HuggingFace 模型支持 NVIDIA、AMD 显卡工业界大量落地企业私有部署、RAG 后端、Agent 服务普遍使用缺点与局限只做推理不做训练可以 LoRA 推理服务不能做微调训练调试门槛比 TGI 高部分小众模型需要适配单机 CPU 上性能很差主要面向 GPUGGUF 支持属于实验特性生产慎用高并发下首 token 延迟 TTFT 会抬升需要调优参数vLLM vs TGI(HuggingFace) vs SGLang框架核心技术优势适合场景vLLMPagedAttention 连续批综合性能均衡社区最火通用大模型 API、RAG、Agent 线上服务TGI连续批普通 KV 管理HF 生态无缝、运维简单开箱即用小并发、快速原型HF 重度用户SGLangRadixAttention树状前缀缓存共享前缀复用更强Agent/Few‑shot 场景更省显存大量 system prompt、Few‑shot、Agent 集群Ollama侧重本地简单运行没有 PagedAttention不适合高并发线上服务适合本地调试 Demo。总结vLLM 是伯克利开源的高性能 LLM 推理服务框架核心是PagedAttention 分页注意力借鉴操作系统虚拟内存管理 KV‑Cache解决显存碎片化搭配连续批处理 Continuous Batching大幅提升 GPU 吞吐量与并发主要用于线上 API、RAG、Agent 部署不做模型训练。