本站内容由 AI 生成,可能存在错误。如发现问题,欢迎到 GitHub Issues 反馈。

LLM 推理引擎全景:vLLM、SGLang、Ollama 与 TensorRT-LLM

LLM 推理引擎全景:vLLM、SGLang、Ollama 与 TensorRT-LLM

更新于 2026-04-05

为什么需要推理引擎

直接用 transformers.generate() 跑 LLM 推理有三个致命瓶颈:

  1. 内存浪费:为每个请求预分配 max_seq_len 的 KV Cache,实际使用往往不到一半
  2. 无法并发:一个请求占满 GPU,其他请求只能排队
  3. 吞吐量低:没有批处理优化,GPU 算力大部分时间在空转

推理引擎的核心任务就是解决这三个问题:高效管理内存、智能调度请求、最大化 GPU 利用率。

四大引擎与设计哲学

当前主流的四大 LLM 推理引擎各有侧重:

vLLM (UC Berkeley, 2023):以 PagedAttention 起家,核心目标是最大化 serving 吞吐量。借鉴操作系统虚拟内存的思想管理 KV Cache,消除内存碎片。生态最成熟,社区最大,OpenAI 兼容 API 使其成为云端部署的默认选择。

SGLang (LMSYS, 2023):强调可编程性与高性能的结合。RadixAttention 提供比 vLLM 更灵活的前缀缓存,独创的 DSL 编程模型支持复杂的多步推理流水线,Compressed FSM 实现最快的结构化输出。适合需要精确格式控制的复杂 LLM 应用。

Ollama + llama.cpp:本地优先、易用优先。一行命令安装运行,GGUF 量化格式支持 CPU 和消费级 GPU。牺牲极致吞吐换取开箱即用的体验,是个人开发者和本地实验的首选。

TensorRT-LLM (NVIDIA):NVIDIA 硬件生态的深度绑定。FP8 量化、inflight batching、custom kernels,在 H100/B200 上榨取最后一滴性能。代价是灵活性低、学习曲线陡、仅支持 NVIDIA GPU。

推理引擎特性对比点击引擎名称查看各维度评分吞吐量延迟易用性生态灵活性vLLMSGLangOllamaTensorRT-LLM

这四个引擎的设计哲学可以用一个三角形来理解:吞吐量、可编程性、易用性——任何引擎都无法同时在三个维度上做到极致。

推理引擎设计哲学定位吞吐量可编程性易用性TensorRT-LLM极致吞吐vLLM吞吐优先SGLang可编程+高性能Ollama易用优先

请求处理流程对比

三种引擎的请求处理流程反映了它们各自的设计优先级:

云端 Serving (vLLM)
vLLM 请求流程 — 吞吐优先API 请求OpenAI 兼容Scheduler调度 + 批处理PagedAttention分页 KV 管理GPU 推理Batch decodeStream 输出SSE 流式返回

vLLM 的流程以 Scheduler 为核心,所有优化都围绕”同一时刻塞进更多请求”展开。Ollama 的流程最短最直接,单请求模型适合交互式使用。SGLang 的流程多了 IR 编排和约束解码两个环节——它不仅在优化推理速度,还在优化”程序员怎么使用 LLM”。

关键技术概览

这些引擎的性能差异来自底层的关键技术创新。我们先建立全局认知,后续文章会逐个深入:

技术核心思想首创详解文章
PagedAttention虚拟内存分页管理 KV CachevLLM下一篇
Continuous Batching请求完成即释放,动态填入新请求Orca下一篇
RadixAttentionRadix Tree 管理前缀缓存SGLang前缀缓存
Constrained DecodingFSM 约束 + jump-forward 加速SGLangSGLang 编程模型
Chunked Prefill长 prompt 分块混合调度Sarathi调度与抢占

Static vs Continuous Batching 是理解所有引擎的基础——静态批处理必须等最慢的请求完成,GPU 大量空闲;continuous batching 则逐请求释放、逐请求填入:

Static Batching vs Continuous Batching切换查看两种批处理策略的时间线差异Static BatchingContinuous Batching0123456789101112Iteration (时间步)R1PrefillDecode空闲等待R2PrefillDecode空闲等待R3PrefillDecode空闲等待R4PrefillDecodeStatic Batching:所有请求必须等最长的完成 → GPU 利用率低、红色区域全是浪费

技术演进时间线

从 2022 年 Orca 开创 continuous batching 到今天,推理引擎领域经历了爆发式创新。各引擎从独立创新走向互相吸收——vLLM 加入了前缀缓存,SGLang 优化了批处理调度,TensorRT-LLM 也支持了 PagedAttention。

LLM 推理引擎技术演进Hover 查看里程碑详情2022.06Orca(Microsoft)2023.06vLLM(UC Berkeley)2023.10SGLang(LMSYS)2023.12TRT-LLM(NVIDIA)2024.03Chunked Prefill(Microsoft)2024.06SGLang FSM(LMSYS)2024.09vLLM v2(vLLM Team)2025.01框架融合(社区)

选型指南

不知道该选哪个?回答几个简单问题:

推理引擎选型指南回答几个问题,找到最适合你的引擎Q1: 你的部署环境?云端 GPU 服务器本地 / 笔记本

当然,这只是粗略指南。实际选型还需要考虑:模型大小、请求模式(长/短上下文)、SLA 要求、团队技术栈、硬件预算等因素。最稳妥的策略是先用 vLLM(生态最成熟),遇到瓶颈再评估 SGLang(结构化输出)或 TensorRT-LLM(极致性能)。

推荐学习资源

如果你想更深入地理解 LLM 推理引擎,以下是我们精选的资源:

经典论文

  • Kwon et al.《Efficient Memory Management for Large Language Model Serving with PagedAttention》 — vLLM 核心论文(SOSP 2023),提出 PagedAttention 算法,借鉴 OS 虚拟内存与分页机制管理 KV Cache,实现 2-4 倍吞吐量提升。
  • Zheng et al.《SGLang: Efficient Execution of Structured Language Model Programs》 — SGLang 论文,提出 RadixAttention 实现 KV Cache 前缀复用,以及压缩有限状态机加速结构化输出解码,在多种任务上实现高达 6.4 倍吞吐量提升。

博客与教程(图文并茂)

  • vLLM 官方博文《Easy, Fast, and Cheap LLM Serving with PagedAttention》 — 用图表直观展示 PagedAttention 的工作原理和性能对比,比论文更易消化的入门版本。(vllm.ai/blog/vllm)
  • LMSYS《Fast and Expressive LLM Inference with RadixAttention and SGLang》 — SGLang 官方博文,解释 RadixAttention 的 KV Cache 复用机制和前端 DSL 设计,配有架构图和性能对比。(lmsys.org/blog/2024-01-17-sglang/)
  • Anyscale《How continuous batching enables 23x throughput in LLM inference》 — 详解 continuous batching 机制(vLLM 和 SGLang 都采用),对比 static batching 的吞吐量差异,benchmark 多个框架。

官方文档与源码

  • vLLM GitHub 仓库 & 文档 — 涵盖 PagedAttention、continuous batching、CUDA graph、多种量化方法、多机分布式推理等特性。(github.com/vllm-project/vllm / docs.vllm.ai)
  • SGLang GitHub 仓库 & 文档 — 包含 RadixAttention、prefill-decode disaggregation、speculative decoding、多种并行策略等特性。支持 NVIDIA/AMD/Intel/TPU 多硬件后端。(github.com/sgl-project/sglang / docs.sglang.ai)

总结

推理引擎是 LLM 从”能跑”到”能用”的关键基础设施。理解它们的设计哲学和核心技术,是做好 LLM 工程的必备知识。接下来我们将深入每个关键技术:从 PagedAttention 的内存管理开始,逐步理解现代推理引擎的完整技术栈。

延伸阅读