推理部署：vLLM 与多 LoRA 服务

一句话定义

vLLM 用 PagedAttention 与连续批处理把 GPU 推理吞吐提升一个量级，其 LoRA 扩展让一个基座按请求热切换多个 adapter，是微调模型上线的事实标准方案。

为什么重要

训练出的模型要到用户手里才算数。裸 transformers 吞吐低、并发差；vLLM 已是开源推理服务的默认选择，多 LoRA 服务则决定多任务微调的部署架构（kp-009 的取舍在这里落地）；压测与调参决定上线后是稳如磐石还是半夜 OOM。

前置知识

kp-028 的导出物（合并模型或 adapter）；kp-014 的模板一致性要求。

核心概念

• PagedAttention：把 KV cache 像操作系统内存分页一样管理，消除显存碎片，同一显存装下更多并发。
• 连续批处理（continuous batching）：新请求随到随插队，不等整批完成，吞吐远超静态批处理。
• 多 LoRA：--enable-lora 后按请求路由到不同 adapter，基座共享、热切换。
• 关键参数：gpu-memory-utilization（显存占用上限）、max-model-len（最大上下文）、max-num-seqs（并发序列上限）、max-lora-rank（adapter 秩上限）。

原理与机制

传统推理为每个请求整段预留 KV cache，碎片与等待让 GPU 空转；PagedAttention 按页分配使显存利用率接近 100%，连续批处理让 GPU 始终满载。压测关注两个指标：TTFT（首 token 延迟，交互体验）与 TPOT（每 token 生成时间，流式流畅度），吞吐在并发上升时先升后稳。多 LoRA 的代价：换载毫秒级开销，max-lora-rank 与并发 adapter 数占额外显存，超配高峰期 OOM。

模板一致性在服务层的落点：vLLM 的 OpenAI 兼容接口默认读取模型目录内的 chat template，导出物必须带全（kp-028 三件套），否则训练与推理模板不一致，微调成果直接清零。

图示

请求 ─► OpenAI兼容API ─► 调度器(连续批处理)
                            │
                 ┌──────────┼──────────┐
              基座权重(共享)  LoRA-A    LoRA-B   ← 按请求热切换
                            │
                       PagedAttention KV cache(按页分配)

直观类比

静态批处理像班车（人齐才发车，先到的等后到的）；连续批处理像地铁（随到随上）；PagedAttention 像把固定包厢改成灵活座位，同一节车皮装下更多乘客。

实例或案例

14B AWQ 模型在 48G 卡上的压测对照：transformers 原生服务 20 并发即排队、吞吐 300 tokens/s；vLLM 默认参数下 100 并发吞吐 2400 tokens/s、TTFT P99 1.8s。多 LoRA 场景：同一基座挂 6 个客户 adapter，48G 卡同时服务，新客户上线只传 adapter 文件，全程无重启。

操作步骤

# 合并模型服务
vllm serve ./merged-model \
  --served-model-name my-ft-model \
  --max-model-len 4096 --gpu-memory-utilization 0.9 --max-num-seqs 64

# 多 LoRA 服务
vllm serve ./base-model --enable-lora --max-lora-rank 32 \
  --lora-modules cs=./adapters/cs legal=./adapters/legal

1. 先用默认参数起服务，单请求冒烟（模板、eos、停止符核对）。
2. 压测：并发 1/8/32/64 各档记录 TTFT P50/P99、TPOT 与吞吐。
3. 按压测调参：延迟敏感降 max-num-seqs、吞吐敏感升 gpu-memory-utilization 到 0.9-0.95。
4. 生产化：健康检查端点、超时与重试策略、日志留痕、灰度与回滚预案。
5. 上线后跑一次线上真实流量抽样评测（kp-025），确认服务链路无质量损失。

排错清单

• 启动即 OOM：降 gpu-memory-utilization 或减 max-model-len（KV cache 随上下文暴涨）。
• 长请求全部超时：检查 max-model-len 与客户端 max_tokens 配置；流式输出确认未被代理缓冲。
• 多 LoRA 加载 adapter 失败：rank 超过 --max-lora-rank，或 adapter 目标模块与基座不匹配。
• 输出突然带模板标记：服务端与客户端模板不一致（kp-014 的线上形态）。
• 高峰期随机重启：OOM kill，压测并发上限要低于 OOM 边界 20% 并设排队。

常见误区

• 部署即起服务：不压测就上线，等于不知道自己系统的容量与失效模式。
• vLLM 万能：极端低延迟单流场景或特殊硬件，另有 TensorRT-LLM/llama.cpp 等选项，按约束选型。
• 模板由客户端渲染：一致性必须由服务端统一保障，客户端只传消息列表。

与其他知识点的关系

多 LoRA 的架构取舍见 kp-009；导出格式决定服务形态见 kp-028；模板一致性见 kp-014；上线前的评测验收见 kp-025。

延伸阅读

Kwon et al. 2023《Efficient Memory Management for Large Language Model Serving with PagedAttention》。

自测题

1. vLLM 吞吐提升的两大机制是什么？

答：PagedAttention（KV cache 分页管理，消灭显存碎片）与连续批处理（请求随到随处理，GPU 满载）。

1. TTFT 与 TPOT 分别衡量什么？

答：TTFT 是首 token 延迟（交互响应体验），TPOT 是每 token 生成间隔（流式流畅度）。

1. 多 LoRA 服务比逐个合并部署省什么、贵什么？

答：省基座显存（N 个任务共享一份基座）与迭代成本（上新任务只传 adapter）；贵在服务层复杂度、换载开销与并发 adapter 的额外显存。