写这个系列到现在，主流推理引擎已经挨个上手过一遍：llama.cpp、Ollama、vLLM、SGLang，加上一直没单独成文的 TGI（Text Generation Inference）和 LMDeploy，恰好凑齐六家。单篇里各自说优点容易，真正难的是拉到同一张桌上比——本文就干这件事。
先亮结论，避免和稀泥：没有全能冠军，只有场景匹配。2026 年 10 月这个时点，格局比两年前清晰得多：TGI 已官宣进入维护模式，第一梯队收敛为 vLLM 与 SGLang 双雄，消费级本地是 llama.cpp 系的天下，LMDeploy 守着多模态与国产模型的特色阵地。全文按"评价维度 → 逐家点评 → 横评总表 → 选型决策树 → 自测基准方法"组织，版本与活跃度信息均按 2026 年 10 月口径核实。
1、评价维度先行
选型最常见的错误，是拿着别人的榜单直接投票。榜单往往只报一个吞吐数字，而吞吐恰恰是最容易随负载定义变化的指标。正确的顺序是反过来：先定维度，再看引擎。本文用八个维度做标尺，每个维度考察什么、为什么重要，先列成表。
| 维度 | 考察什么 | 为什么重要 |
|---|---|---|
| 吞吐 | 高并发下总 tokens/s | 决定一块 GPU 能扛多少请求 |
| 延迟 | 首 token 时间与单请求时延 | 决定交互体验是否可用 |
| 显存效率 | 同参数量下的最大并发与上下文 | 决定模型能不能塞进你的卡 |
| 量化支持 | 格式广度与档位密度 | 决定低端硬件的可用性 |
| 模型覆盖 | 新模型跟进速度 | 决定能否第一时间用上新货 |
| 易用性 | 安装、启动、文档门槛 | 决定接入与维护成本 |
| API 生态 | OpenAI 兼容度与客户端库 | 决定迁移与集成难度 |
| 维护活跃 | 发版频率与社区规模 | 决定三年后它是否还活着 |
六家选手的基本盘如下，版本号为 2026 年 10 月核实值。
| 引擎 | 出品方 | 2026-10 版本 | 一句话定位 |
|---|---|---|---|
| llama.cpp 仓库 | ggml-org | b 序号周更多版 |
消费级推理的地基 |
| Ollama 官网 | Ollama 团队 | 0.40.x |
本地开发体验之王 |
| vLLM 仓库 | UC Berkeley 起源 | v0.32.0 |
生产服务事实标准 |
| SGLang 仓库 | LMSYS 起源 | v0.5.22 |
Agent 负载专家 |
| TGI 仓库 | Hugging Face | 维护模式 | 高性能服务的先驱 |
| LMDeploy 仓库 | 上海 AI 实验室 | v0.18.0 |
多模态与国产模型阵地 |
2、轻量组 llama.cpp 与 Ollama
前面几篇的结论，在这里收拢成三句话。
第一句，llama.cpp 的护城河是量化与硬件覆盖。GGUF 单文件加从 Q2 到 FP8 的密集档位，让同一张 8 GB 显卡既跑得动 14B 的 Q3，也塞得下 7B 的 Q8；CPU 与 GPU 混合卸载（-ngl 参数）让没有独显的机器也能推理，同一份代码从树莓派覆盖到 H100。短板同样明确：多路并发下连续批处理的规模上不去，吞吐迅速劣化，张量并行基本不可用——它天生为单流低资源设计，别拿它当服务器引擎用。
第二句，Ollama 是把 llama.cpp 包装出最佳体验的产品层：模型库一条命令拉取、自动匹配显存、REST 与 OpenAI 兼容 API 开箱即用，0.40.x 的迭代节奏也足够健康。但它的调度器面向单用户交互设计，并发一高排队明显——包装层再好，也不会突破底下内核的天花板。
第三句是本节的明确判断：单机单人，从 Ollama 起步；要抠显存、抠量化档位，退回 llama.cpp 裸用。任何试图用 Ollama 撑线上并发的方案，都是在跟它的设计初衷作对。
3、vLLM 生产标杆的强与弱
强的部分无可争议。PagedAttention 加连续批处理的基本盘，加上几年迭代攒下的算子优化，让它在通用聊天、RAG（检索增强生成）摘要这类"长进长出"的高并发负载上吞吐稳居第一梯队；模型覆盖六家最广，新模型基本第一时间跟进；OpenAI 兼容 API 的事实标准地位，意味着主流客户端库、网关、框架默认对接的就是它。社区规模同样是最高的——v0.27.0 一个版本合入 561 个提交、242 名贡献者参与，到 2026 年 10 月已发到 v0.32.0，双周一个版本的节奏没有放缓迹象。
弱项也要说透。启动慢、预热久，框架自身的显存开销比 C++ 内核高一个量级；KV cache（键值缓存）池的预留不小，小卡上"能跑"和"能服务"是两回事；Agent 多轮场景的前缀复用效率不如 SGLang 的激进缓存；权重量化以 AWQ、GPTQ、FP8 为主，档位密度远不如 GGUF。没有特殊理由，生产默认选 vLLM；它被超越的场景，恰好就是上面列的这几条。
4、SGLang Agent 负载之王
SGLang 出身 LMSYS（Chatbot Arena 同门），靠 RadixAttention 前缀缓存起家：把所有请求的前缀组织成基数树，多轮对话里 system prompt 加历史轮次高度重叠，命中缓存的请求直接跳过 prefill，省下的不只是时间，还有大把预填充算力。Agent 负载恰好是前缀重叠的极端形态——同一段工具描述、同一份上下文被反复咀嚼几十轮，这正是 vLLM 朴素前缀缓存吃不下的部分。
它的第二张牌是结构化输出：基于约束解码（xgrammar 后端）的 JSON 生成又快又稳，Agent 要的函数调用参数、schema 化的工具响应都是它的主场。活跃度不用担心：PyPI 已到 v0.5.22，官方 Docker 镜像日更，NVIDIA NGC（GPU 容器目录）每月发布带全套加速库的容器。API 与 vLLM 高度兼容，迁移成本基本只剩换个端口。
短板：模型覆盖比 vLLM 窄一圈，热门模型都支持、长尾慢半拍；生产案例与运维文档的积累不如 vLLM 厚；新版要求 Python 3.11 起、镜像切到 CUDA 13 轮，环境门槛略高。Agent 多轮与结构化输出为主的负载，SGLang 是第一选择，没有之一。
5、TGI 先行者的谢幕
TGI 值得尊重：2023 年它率先把 Flash Attention 与连续批处理带进生产级 serving，Rust 路由器加 Python 推理后端的架构影响了后来所有同行。某种意义上，"text-generation-inference"这个名字本身就是这个品类的命名。
但比赛对它而言已经结束。Hugging Face 官方文档的表述如下。
TGI 自 2025 年 12 月 11 日起进入维护模式：此后仅接受缺陷修复、文档改进与轻量维护，不再规划新功能；官方建议新部署转向 vLLM 与 SGLang。
2026 年的当下，新项目选 TGI 没有一条站得住的理由——性能不占优、生态在收缩、文档与人才都在流向双雄。给存量部署的读者一句实话：不必恐慌性迁移，稳定版还会安全运行很久；但每一次扩容、每一次新模型接入，都应该成为迁往 vLLM 的排练。
6、LMDeploy 国产内核与多模态
LMDeploy 是六家里唯一非英文社区起家的第一梯队选手，出自上海人工智能实验室 InternLM 体系。它的底气是自研 TurboMind 内核（FasterTransformer 谱系）加 PyTorch 引擎的双引擎架构：前者默认接管能跑的模型，后者兜底新架构。2026 年 9 月底发布的 v0.18.0 维持着大约每月一个版本的节奏。
它有两张特色牌。其一，多模态：InternVL、Qwen-VL、DeepSeek-VL 这类视觉语言模型在 LMDeploy 上是一等公民，支持深度普遍先于其他引擎。其二，激进的显存与精度工程：KV cache int8 量化、W4A16 权重压缩，以及 2026 年主推的 MXFP4 混合精度——官方论文的口径是特定配置下吞吐做到 vLLM 的 1.5 倍（TurboMind 论文）。
短板由生态位决定：国际社区小、贡献者集中在内部团队、文档中英质量不均；模型覆盖对国产系最友好，对海外长尾模型跟进一般。主力模型是多模态或国产开源系时，认真评估 LMDeploy；纯英文生态的文本模型，仍优先双雄。
7、横评总表与选型决策
7.1、六家八维度总表
八张成绩单拆成两张表呈现，用"强 / 中 / 弱"三档定性——横评的意义在方向，不在小数点。
| 引擎 | 吞吐 | 延迟 | 显存效率 | 量化支持 |
|---|---|---|---|---|
| llama.cpp | 弱 | 强 | 强 | 强 |
| Ollama | 弱 | 强 | 强 | 强 |
| vLLM | 强 | 中 | 中 | 中 |
| SGLang | 强 | 强 | 中 | 中 |
| TGI | 中 | 中 | 中 | 中 |
| LMDeploy | 强 | 中 | 强 | 强 |
| 引擎 | 模型覆盖 | 易用性 | API 生态 | 维护活跃 |
|---|---|---|---|---|
| llama.cpp | 强 | 中 | 中 | 强 |
| Ollama | 强 | 强 | 强 | 强 |
| vLLM | 强 | 中 | 强 | 强 |
| SGLang | 中 | 中 | 强 | 强 |
| TGI | 中 | 中 | 中 | 弱 |
| LMDeploy | 中 | 中 | 中 | 中 |
几处容易误读的格子说明一下。llama.cpp 的吞吐标弱，专指多并发服务场景，单流速度它从不吃亏；TGI 各项标中，是性能仍在，但维护活跃一项弱足以一票否决；LMDeploy 的显存效率标强，靠的是量化工具链而不是调度器。
7.2、选型决策树
把上面的表压缩成一棵可以直接照着走的树。
用法是从上往下，第一个命中的叶子就是答案，不必来回比价。真正的灰色地带只有一处：Agent 负载但并发很低（比如个人跑的自动化脚本），此时 vLLM 与 SGLang 的差距被摊薄，跟着现有基础设施走即可。
8、自测基准方法论
公开榜单适合看相对位置，不适合做最终决策——榜单的 prompt 分布、上下文长度、并发模型几乎不可能与你的负载一致，而引擎间的差距恰恰对这些变量极度敏感。业界反复出现的"别再按榜单选型"，说的就是这个。榜单给方向，自测定生死。
自测只有三条纪律。
- 采样自己的真实 prompt，32～64 条，覆盖长短输入输出
- 固定模型、量化档位、上下文长度与同一块 GPU
- 每档并发预热一轮，正式跑三轮取中位数
落成一个统一脚本如下，对任何 OpenAI 兼容端点的引擎通用。
import time
import requests
from concurrent.futures import ThreadPoolExecutor
URL = "http://localhost:8000/v1/chat/completions" # 换成被测引擎端口
HEADERS = {"Authorization": "Bearer empty"}
PROMPTS = [open(f"prompts/{i}.txt", encoding="utf-8").read()
for i in range(32)]
def one(prompt):
body = {"model": "default",
"messages": [{"role": "user", "content": prompt}],
"max_tokens": 256, "stream": False}
t0 = time.perf_counter()
r = requests.post(URL, headers=HEADERS, json=body, timeout=600)
return time.perf_counter() - t0, r.json()["usage"]["completion_tokens"]
def bench(n):
t0 = time.perf_counter()
with ThreadPoolExecutor(n) as ex: # n 路并发打满
res = list(ex.map(one, PROMPTS))
wall = time.perf_counter() - t0
lats = sorted(x[0] for x in res)
toks = sum(x[1] for x in res)
print(f"c={n:2d} P50={lats[len(lats)//2]:6.2f}s "
f"吞吐={toks/wall:7.1f} tok/s")
for n in (1, 4, 16):
bench(n)
脚本记录两个数：单请求 P50 时延对应用户体验，总吞吐对应机器容量。要测首 token 时间，把 stream 改为 True，在收到第一个分片时打点即可。被测引擎要用统一参数启动，示例如下。
# vLLM：显式固定上下文长度，避免默认值偷偷打架
docker run --gpus all -p 8000:8000 vllm/vllm-openai:v0.32.0 \
--model Qwen/Qwen3-8B --max-model-len 8192
# SGLang：同模型同上下文，tag 按 PyPI 最新版固定
docker run --gpus all -p 8001:8000 lmsysorg/sglang:latest \
--model-path Qwen/Qwen3-8B --context-length 8192
两边除引擎本身外全部变量一致，对比才成立。一次典型自测的输出形态如下。
c= 1 P50= 1.84s 吞吐= 142.3 tok/s
c= 4 P50= 3.10s 吞吐= 521.7 tok/s
c=16 P50= 9.87s 吞吐= 1180.4 tok/s
解读这组数字的方法：看吞吐随并发的爬升是否还有余量，看 P50 在目标并发下是否越过体验红线。两个引擎对比时，小于 10% 的差距一律视为噪声，重跑三轮再下结论。
9、总结
六家横评收拢成四句话：生产通用负载，vLLM 是默认解；Agent 多轮与结构化输出，SGLang 无可替代；单机与消费级，Ollama 与 llama.cpp 各守一层；TGI 已谢幕，LMDeploy 以多模态与国产模型立身。维度先行、场景决策树、自测三纪律，是把这套判断迁移到自己环境的方法。
练习：把第 8 节的脚本跑两遍——同一个模型、同一批自己的 prompt，分别指向 vLLM 与 SGLang（或任选两个你犹豫中的引擎），记录并发 1、4、16 三档的 P50 与吞吐。对于正在选型的读者，建议先花半小时跑完这组自测，再回来核对本文的结论在你的负载上是否成立。
