课程导入：vLLM简介、离线批处理与在线服务的区别、课程目标与学习路径

大语言模型（LLM）的工程化部署正在从“能跑通”走向“跑得快、跑得稳、跑得省”。vLLM 作为当前最主流的高性能 LLM 推理引擎之一，凭借 PagedAttention 显存管理、Continuous Batching 连续批处理、量化推理、分布式张量并行等特性，已经成为生产环境中部署 Llama、Qwen、DeepSeek、Mistral 等开源模型的首选方案。然而，很多工程师对 vLLM 的理解停留在“用命令行起一个 OpenAI 兼容服务”的层面，对离线批处理（Offline Batch Inference）与在线服务（Online Serving）两种模式的内在差异、适用场景、性能调优手段缺乏系统认知。本章作为整个课程的开篇，将帮助你建立 vLLM 的整体知识框架，厘清两种工作模式的本质区别，并规划一条从入门到实战的进阶路径。

1.1 vLLM 核心原理与设计哲学

vLLM 之所以能在众多推理框架中脱颖而出，根本原因在于它解决了 LLM 推理中最棘手的显存管理问题。传统推理框架在 KV Cache（键值缓存）管理上采用“预分配固定大小”的策略，导致大量显存被浪费，批处理规模受限。vLLM 引入了 PagedAttention 机制，将 KV Cache 划分为固定大小的块（Block），按需分配，类似操作系统中的虚拟内存分页管理。这一设计使得显存利用率提升数倍，从而允许更大的批处理规模，最终转化为更高的吞吐量。

除了 PagedAttention，vLLM 还实现了 Continuous Batching（连续批处理）。传统批处理必须等待一个批次中所有序列生成完毕才能释放资源，而连续批处理允许在序列级别动态调度——某个序列生成结束后，立即插入新请求，无需等待整个批次完成。这种细粒度的调度策略显著提升了 GPU 利用率，尤其适合在线服务场景中请求到达时间不均匀的情况。

核心特性	解决的问题	对双模式的影响
PagedAttention	KV Cache 显存碎片化与浪费	离线模式可处理更大数据集；在线模式可承载更高并发
Continuous Batching	批处理等待导致的 GPU 空闲	在线模式延迟更低；离线模式吞吐更高
Prefix Caching	重复前缀（如 System Prompt）重复计算	在线 Agent 场景收益显著；离线批量处理相同前缀时加速明显
量化支持	显存带宽与容量瓶颈	两种模式均可降低显存需求，离线模式更关注精度损失

1.2 离线批处理与在线服务的本质区别

离线批处理和在线服务虽然共享同一个推理引擎，但在设计目标、接口形态、性能指标、资源调度策略上存在显著差异。混淆这两种模式是初学者最常见的错误——用在线服务的思维去调优离线任务，或者用离线批处理的逻辑去设计在线 API，都会导致性能不达标或资源浪费。

离线批处理（Offline Batch Inference）的核心目标是“吞吐量最大化”。它接收一个完整的数据集（如 JSON 文件、文本列表），对每一条数据执行推理，最终输出结果文件。这种模式没有实时交互需求，用户不关心单条请求的响应时间，只关心“处理完这 10 万条数据需要多久”。离线批处理适合数据清洗、文档分类、批量翻译、离线打标、知识库构建等场景。

在线服务（Online Serving）的核心目标是“延迟可控 + 并发稳定”。它通过 HTTP 或 gRPC 接口对外提供推理能力，用户发送请求后需要等待响应。在线服务必须保证 P99 延迟在可接受范围内（通常小于 2-3 秒），同时能够应对突发流量。在线服务适合 ChatBot、Agent、RAG 问答、代码补全等交互式场景。

对比维度	离线批处理	在线服务
输入方式	文件/数据集批量加载	API 请求逐条到达
核心指标	吞吐量（Tokens/s）、总耗时	P50/P99 延迟、并发数、错误率
批处理策略	静态批处理，可预先规划 batch size	动态 Continuous Batching，实时调度
流式输出	通常不需要	必需（SSE 流式返回）
资源弹性	可离线排队，资源利用率优先	需预留峰值资源，弹性扩缩容
故障处理	失败任务可重试，不影响整体	单请求超时/失败需快速响应
典型接口	LLM.generate()	/v1/chat/completions

1.3 课程目标与学习路径规划

本课程的目标是让你在 30 章的学习后，能够独立完成以下工作：

1. 离线批处理实战：使用 vLLM 的 Python API 处理大规模数据集，掌握 batch size 调优、显存管理、结果持久化、断点续跑等技能。
2. 在线服务部署：基于 vLLM 启动 OpenAI 兼容服务，配置流式输出、并发控制、超时策略，并集成到业务系统中。
3. 性能调优：根据硬件环境（单卡/多卡）、模型规模（7B/70B）、业务场景（延迟敏感/吞吐敏感）选择最优配置。
4. 生产级运维：掌握监控指标（吞吐、延迟、显存、GPU 利用率）、压测方法、容器化部署、K8s 编排。
5. 高级特性：理解并应用量化推理、多模态模型支持、LoRA 适配器热加载、分布式推理等进阶能力。

为了达成上述目标，课程设计了“基础 → 离线 → 在线 → 调优 → 生产 → 高级”六阶段递进路径。每个阶段包含理论讲解、代码演示、实战案例和常见问题复盘。建议你按照顺序学习，但可以根据实际工作需求跳跃式选择重点章节。

阶段	章节范围	核心能力	实战产出
基础入门	第 1-4 章	环境搭建、模型加载、基本推理	本地跑通 Qwen2.5-7B 推理
离线批处理	第 5-10 章	LLM.generate、数据集处理、吞吐优化	批量处理 10 万条文本分类任务
在线服务	第 11-16 章	API 部署、流式输出、并发控制	部署高并发 ChatBot 服务
性能调优	第 17-22 章	显存优化、量化、并行策略	吞吐提升 3 倍以上
生产实践	第 23-27 章	Docker/K8s、监控、压测、灰度	生产级服务上线与运维
高级特性	第 28-30 章	多模态、LoRA、分布式推理	多模态模型服务部署

1.4 实战场景：从需求到模式选择

为了帮助你建立直觉，我们来看一个真实的需求分析案例。假设你所在的公司有一个智能客服项目，需要完成两项任务：

任务 A：将过去一年积累的 50 万条用户对话记录进行意图分类和情感分析，用于运营报表。这个任务没有实时性要求，每周执行一次即可。

任务 B：为线上用户提供实时智能问答服务，用户发送消息后需要在 2 秒内收到回复。

面对这两个任务，你应该如何选择 vLLM 的工作模式？

任务 A 显然选择离线批处理。50 万条数据如果逐条调用在线 API，不仅会产生巨大的网络开销，还会因为在线服务的并发限制导致处理时间过长。更优的做法是：编写 Python 脚本，使用 LLM.generate() 批量加载数据，设置合适的 batch size（例如 32 或 64），充分利用 GPU 并行计算能力。根据经验，使用单张 A100 处理 50 万条短文本（平均 100 tokens），大约需要 2-3 小时。如果使用 4 卡并行，可以缩短到 1 小时以内。

任务 B 必须选择在线服务。你需要启动 vLLM 的 OpenAI 兼容服务，配置流式输出（SSE），设置最大并发数（例如 100），并接入负载均衡。在线服务还需要考虑超时策略——如果某个请求超过 10 秒仍未完成，应该断开连接并返回错误，避免占用资源。

1.5 环境准备与常见误区

在开始后续章节之前，建议你完成以下环境准备：

• 硬件：至少一张 NVIDIA GPU（建议显存 ≥ 16GB），支持 CUDA 12.0 以上。
• 软件：Python 3.10+，PyTorch 2.1+，vLLM 0.6.0+（建议使用最新稳定版）。
• 模型：推荐从 Qwen2.5-7B-Instruct 或 Llama-3.1-8B-Instruct 开始，这两个模型对显存要求适中，社区资料丰富。
• 工具：Jupyter Notebook（用于交互式学习）、Docker（用于生产部署）、Prometheus + Grafana（用于监控，后续章节会用到）。