Chapter 07 · 主流推理引擎实战：vLLM、TensorRT-LLM、SGLang、llama.cpp

Guide

章节导读

现在你已经有了足够的系统视角，可以开始看不同框架为什么长成今天这个样子。重点不是记住每个 CLI 参数，而是用统一问题去问：它服务什么场景、押注什么优化、依赖什么硬件、暴露什么接口、适合什么团队。

这一章的核心问题

四条主流路线分别更适合什么场景，它们的工程偏好是什么。

你要形成的能力

在看到新框架时，能快速问出正确的比较问题，而不是只看 benchmark 排名。

阅读方式建议

先用统一对比维度看四个框架，再根据你的场景去做取舍判断。

Goals

本章目标

掌握比较推理框架的统一维度：场景、硬件依赖、优化重点、接口能力、部署复杂度。
理解 vLLM、TensorRT-LLM、SGLang、llama.cpp 各自更强在哪些工程场景。
学会把“框架热度”翻译成“工程适配性”，不被单一 benchmark 左右。
建立最小上手闭环：跑通、调用、观察、比较。

Prerequisites

前置知识

必须知道

吞吐、延迟、显存和并行是不同优化目标。
硬件平台会强烈影响框架能力边界。
推理服务不是单机脚本，而是要面对真实负载和接口需求。

建议知道

在线服务、本地推理、离线批处理的目标不同。
你已经对量化、缓存、调度等关键词有基本概念。
你愿意把选型当成约束匹配，而不是排名游戏。

本章不追求

不追求把四个框架所有能力一次性学完。
不追求跑出绝对 benchmark 冠军数字。
重点是建立比较方法。

Topics

正文主线

1. 框架比较应该先看哪些维度

一个有效的比较框架至少包含五个问题：它主要服务什么负载？它更依赖什么硬件或平台？它最强调哪类优化？它暴露什么接口与能力？它部署和维护成本高不高？如果这五个问题不先问，后面的比较大多会退化成“谁在某个帖子里更火”。

2. vLLM：以高吞吐 serving 为代表的路线

你可以把 vLLM 理解成“围绕高吞吐在线 serving 组织设计”的代表。它之所以常被提起，不是因为名字更响，而是因为它把请求调度、continuous batching、paged attention、缓存复用这些问题组织成了一条比较完整的系统路线。

如果你的关注点是高并发在线推理、OpenAI 风格接口或对 serving 吞吐的系统理解，它是很好的入口。

3. TensorRT-LLM：更贴近 NVIDIA 平台优化的路线

TensorRT-LLM 更像是“围绕 NVIDIA 硬件能力，把推理性能和部署能力压到很深”的路线。它天然更强调特定平台上的并行、量化、编译和部署实践。如果你的场景高度依赖 NVIDIA 平台、并且愿意接受更强的平台耦合来换取性能和工程整合度，它会很有吸引力。

4. SGLang：服务编排与高性能推理结合的路线

SGLang 在很多场景里不仅被当成推理框架看，也常被拿来理解服务编排、结构化输出和更复杂推理交互是怎样和高性能 serving 结合的。它适合你从“能力暴露 + 高性能服务”双重视角观察系统设计。

5. llama.cpp：轻量、本地、多后端适配路线

llama.cpp 的价值，不在于把所有大规模数据中心能力都搬过来，而在于它提供了另一条非常重要的视角：当场景变成单机、本地、CPU 或轻量 GPU、边缘设备时，推理系统该怎样重新做取舍。它是你理解“不同部署形态如何改变工程设计”的极好样本。

6. 选型不是寻找唯一正确答案

真正的选型通常是约束匹配：如果你追求高吞吐在线服务，可能更偏向某些路线；如果你依赖 NVIDIA 平台和更深层优化能力，会看另一些路线；如果你做本地、轻量或跨平台推理，优先级又不同。所以你最终要学会的，不是“背答案”，而是“复用问题模板”。

7. 试用框架时，先做最小闭环，不要先迷失在 benchmark

框架比较最容易走偏的地方，是一上来就搜 benchmark 排名。但如果你自己没有先跑通最小闭环，就不知道这些数字背后的配置条件、负载模式和平台约束。更稳的顺序是：先拉起最小服务、做一次最小调用、看清它暴露的接口和配置，再去读它的性能叙事。

这样你看到 benchmark 时，才知道哪些数字与你的场景有关，哪些只是特定平台或特定负载下的结果。

Decision

工程判断

先用工作负载筛框架

高吞吐在线服务、本地轻量部署、NVIDIA 平台深度优化，本来就不是同一张评分表。

先看主要负载和并发形态。
再看框架最强调的优化方向。
这样选型会快很多，也更少被营销词带偏。

平台耦合是收益，也是代价

越贴近特定硬件平台，通常越可能拿到更深的性能收益，但迁移成本和适配门槛也会同步提高。

问自己是否真的长期绑定这套平台。
问团队是否有能力维护更复杂的链路。
别为了追极致性能牺牲不必要的灵活性。

选型的终点是可落地，而不是概念最全

一个框架支持很多高级能力，并不代表它就是当前团队最合适的选择。真正重要的是：能否稳定接进你的服务、部署、监控和后续演进链路。

看接口兼容性。
看部署闭环是否顺手。
看你能不能解释它为什么适合当前场景。

Examples

场景拆解

A100 服务高吞吐判断

做一个在线聊天 API，目标是高并发和 OpenAI 风格接口

这类场景优先关注的是 serving 路线、请求调度和接口兼容性。你会自然更关注 vLLM 这类对在线服务叙事更完整的方案。

先验证服务接口和批处理能力。
再看吞吐、缓存和 benchmark。
最后比较部署和运维成本。

本地原型轻量判断

做本地原型或边缘演示，希望少依赖复杂 GPU 环境

此时你关心的是轻量、可移植、快速上手和量化实用性，而不是极致的集群吞吐。llama.cpp 的路线通常更贴近这个目标。

先看本地运行和量化支持是否顺手。
再看服务化能力是否足够。
不要用数据中心标准去否定本地路线的价值。

Diagram

图解实验室

这张图不试图排“谁最好”，只把四条路线的工程位置摆在一起，方便你先定位场景。

四条框架路线定位图

先问自己的负载、平台和部署目标，再去看哪张卡片最贴近你的约束。

先问自己的约束 你的主要场景是在线吞吐、本地原型、平台深度优化，还是服务编排能力？

↓

vLLM 更偏高吞吐在线 serving、请求调度和 OpenAI 风格接口。

TensorRT-LLM 更偏 NVIDIA 平台深度优化、量化、并行和部署整合。

SGLang 更偏高性能服务与能力编排结合，适合看服务能力如何暴露。

llama.cpp 更偏本地、轻量、跨后端和量化实用路线。

选型顺序 先看工作负载和平台，再看 benchmark、接口和功能表。

最终判断标准 不是概念最全，而是能不能稳定落进你的调用、部署和运维链路。

Key Points

关键表格与结论

框架	更典型的优势视角	你应重点关注什么	更适合什么学习目标
vLLM	高吞吐 serving、调度、分页缓存	请求管理、continuous batching、OpenAI 风格服务	理解在线推理系统主线
TensorRT-LLM	NVIDIA 平台深度优化	量化、并行、部署和平台能力耦合	理解硬件平台导向的优化路线
SGLang	高性能服务 + 能力编排	结构化输出、服务能力暴露、benchmark	理解服务能力和推理性能怎样一起设计
llama.cpp	轻量、本地、多环境适配	本地部署、量化实用性、服务端简洁实现	理解非数据中心场景下的工程取舍

结论 1

框架比较的本质不是“谁最好”，而是“谁更适合你的约束和目标”。

结论 2

一个框架越强，通常意味着它在某些维度押注越深，也可能带来更多平台或复杂度约束。

Tasks

动手任务

任务 1：建立四框架对比表

至少覆盖场景、硬件依赖、优化重点、接口能力、部署复杂度。最低完成标准是：你能用一页表格把四条路线区分开。

任务 2：为三个不同场景各做一次框架推荐

例如在线高吞吐服务、NVIDIA 生产环境、本地 CPU / 轻量推理。最低完成标准是：每个推荐都要写理由和放弃其他方案的原因。

任务 3：设计你自己的选型问题模板

最低完成标准是：下次看到新框架时，你可以直接按这套问题去判断它的位置。

任务 4：定义一个“最小上手闭环”

例如启动服务、发请求、看日志、记指标。最低完成标准是：不是只写“跑通 demo”，而是要有观测动作。

Milestones

阶段产出

产出 1

一张四框架对比表。

产出 2

一套你自己的框架选型问题模板。

产出 3

至少三个不同场景的推荐结论。

Self Check

自测问题

1. 如果有人问“哪个推理框架最好”，你会先反问什么？

这能检验你是否真的建立了场景优先的比较方法。
2. 为什么同一个 benchmark 结果不能直接推导出统一选型结论？

因为负载、平台、接口和运维约束通常都不相同。
3. 你能否分别说出 vLLM、TensorRT-LLM、SGLang、llama.cpp 更强的一面？

如果你只能记住名字而说不出工程特征，说明这章还没有学到位。
4. 你设计的最小上手闭环里，为什么一定要包含“观察结果”这一步？

因为推理系统学习不是把服务跑起来，而是理解它怎么表现。

Resources

常见误区

误区 1：把框架热度当作选型结论

热度只能说明社区关注，不能说明它适合你的目标和约束。

误区 2：只看单一 benchmark 排名

没有统一场景和负载约束的数字，几乎没有可比较意义。

误区 3：把“跑通 demo”当成掌握框架

你至少要能解释这个框架为什么这样组织能力、适合什么场景，才算真正理解。

最后一章会把这些理解收成真实工程闭环：如何部署、如何压测、如何看监控、如何开始读源码，以及如何设计一个能真正证明你学会了的毕业项目。