把开源模型从“能在笔记本上跑起来”变成“能稳定服务成百上千个并发用户”，需要专门的推理引擎。vLLM 是这一领域最流行的开源方案之一，它最初来自学术研究，核心贡献是 PagedAttention 显存管理技术和连续批处理调度，让同样的 GPU 能够服务更多请求。理解它的原理，能帮助你更好地部署和调优大模型服务。

推理服务的核心瓶颈

大模型生成文本时，需要为每个请求保存已处理 Token 的键值缓存（KV Cache），以避免重复计算。这部分缓存随着上下文长度增长而增长，往往占据大量显存。原理详见 KV Cache 详解。

传统的推理实现通常为每个请求预先分配一整块连续显存，大小按最大可能长度计算。问题在于：

  • 大多数请求实际用不到最大长度，造成大量浪费；
  • 不同请求的缓存大小不一，显存中出现碎片；
  • 显存被浪费，能同时处理的请求数就受到限制。

PagedAttention：借鉴操作系统的分页思想

操作系统管理内存时，会把内存划分为固定大小的“页”，程序使用的内存不必物理连续，通过页表映射即可。PagedAttention 把同样的思路用在 KV Cache 上：

  • 把缓存划分为固定大小的小块；
  • 每个请求按需申请新块，用多少分配多少；
  • 通过映射表记录每个请求的缓存块位置，块在显存中不必连续。

这样几乎消除了预分配造成的浪费和碎片问题，同样的显存可以容纳更多并发请求。此外，多个请求如果共享相同的前缀（例如相同的系统提示词），还可以共享对应的缓存块，进一步节省显存。

连续批处理：不让 GPU 空等

GPU 在批量计算时效率最高，因此推理服务通常会把多个请求合并成一批处理。传统的静态批处理要等整批请求全部生成完毕才能开始下一批，先完成的短请求只能空等，新到的请求也要排队。

连续批处理（也称动态批处理或迭代级调度）在每一步生成后都重新调整批次：已完成的请求立即移出，新请求随时加入。GPU 始终保持高负载，整体吞吐显著提升，用户的等待时间也更短。

部署时的关键参数

具体参数名称请以官方文档为准，以下是需要关注的几类配置：

  • 显存利用比例：允许推理引擎使用多大比例的显存，剩余部分留给其他用途；
  • 最大上下文长度：设置过大会减少可同时服务的请求数，应根据业务实际需要设置；
  • 最大并发序列数：限制同时处理的请求数量，平衡吞吐与单请求延迟；
  • 张量并行度：模型太大单卡放不下时，拆分到多张 GPU 上运行；
  • 量化方式：加载量化模型以节省显存，参见模型量化详解；
  • 前缀缓存：开启后可以复用相同前缀的计算结果，对固定系统提示词的场景收益明显。

性能调优思路

  1. 先明确目标：是追求最大吞吐（离线批处理），还是最低延迟（在线交互）？两者的最优配置不同；
  2. 用真实请求压测：用实际业务的输入输出长度分布进行压力测试，而不是使用固定长度的合成数据；
  3. 关注关键指标：首 Token 延迟、每 Token 生成间隔、每秒处理请求数、GPU 显存和算力利用率；
  4. 逐项调整：每次只改一个参数，观察指标变化；
  5. 考虑投机解码等加速技术：在延迟敏感的场景中进一步优化，参见投机解码。

与其他方案的对比

  • 本地轻量工具（如 Ollama）：上手简单，适合个人和开发测试，但高并发能力有限，参见用 Ollama 在本地运行大模型；
  • 其他高性能推理引擎：开源社区和硬件厂商也提供了多种推理框架，在特定硬件或特定场景下可能有优势，选型时应在自己的硬件和负载上实测对比；
  • 托管推理服务：免除运维负担，适合不想自建基础设施的团队。

小结

vLLM 通过 PagedAttention 解决了 KV Cache 的显存浪费问题，通过连续批处理让 GPU 持续保持高负载，两者结合显著提升了推理服务的吞吐。部署时根据业务目标设置上下文长度、并发数和量化方式，用真实负载压测调优，就能在有限的硬件上获得更好的服务能力。