LLM 部署为何与众不同？

Why is LLM Deployment Different?

传统机器学习的推理很简单：

LLM 的情况并非如此，它们带来了几项挑战：

1）连续批处理（Continuous Batching）

前面我们看到，LLM 请求会在不同时间完成，如果批处理管理不当，就会导致 GPU 出现空闲。

vLLM 通过连续批处理（continuous batching）解决了这个问题，它会：

• 一旦序列命中 <EOS> 就立即将其移除

• 立即用新请求填补空出来的位置

这样一来，无需你修改任何代码，GPU 流水线就能始终保持满负荷运转。

2）PagedAttention

我们之前讨论过 KV 缓存如何随着每个 token 的生成而增长，以及连续内存分配是如何导致碎片化的。

vLLM 通过将 KV 缓存存储在一个个不连续的小分页（page）中，而不是单一的连续内存块中，来避免这个问题。

一张轻量级的查找表会记录每个分页的位置，使 vLLM 能够：

• 支持更大的批处理规模
• 避免内存碎片化
• 支持更长的上下文

——而这一切都发生在同一套硬件上。

3）智能调度（Prefill 与 Decode）

我们还在 LLM 优化那一节探讨过 prefill（追求吞吐量）与 decode（对延迟敏感）二者之间相互冲突的特性。

vLLM 的调度器（scheduler）会自动处理这个问题，具体做法是：

• 把 prefill 工作分组处理以提升效率
• 将 decode 步骤交错执行，以保持响应的灵敏度

这样你就能在不牺牲延迟的前提下获得高吞吐量。

4）前缀感知路由（Prefix-Aware Routing）

共享前缀（比如系统提示词）可以在多个请求之间复用，但前提是这些请求要运行在同一个副本（replica）上。

vLLM 通过前缀感知路由来处理这一点：它会把共享前缀的序列固定分配到同一个 worker 上，从而避免重复计算 KV 缓存。

这样既能降低计算开销，也能节省内存开销。

5）LoRA 与多模型支持

由于 LoRA 适配器（adapter）非常轻量，vLLM 只需加载一次，之后就能按请求逐一应用，而不会重复占用内存。

它还可以在同一个服务里托管多个模型，从而轻松支持：

• 个性化
• A/B 测试
• 多功能应用

而且开销极小。

6）熟悉的 OpenAI 兼容 API

由于 vLLM 暴露的 API 结构与 OpenAI 的 Chat Completions API 一致，迁移应用往往只需要改一下 base_url 就够了。

因此，不需要迁移 SDK，也不需要重写代码。

所有这些挑战解释了为什么会出现专门的推理引擎，也解释了为什么 vLLM、SGLang、TensorRT-LLM、LMCache 这类框架是必要的。

在本章中，我们会重点介绍 vLLM——它是目前实践中最简单、最快捷的 LLM 服务方式之一。