外观
推理引擎选型对比
推理引擎选型不是选"最流行的"，而是选"最适配当前问题、硬件与团队能力的"——选错的代价是上线三周返工，选对的回报是性能与运维成本同时减半。
LLM 时代之后，推理引擎从 2 个（TensorRT、ONNX Runtime）暴涨到 10+ 个，每个都自称"最快"——vLLM 论文里比 HuggingFace 快 24×、TensorRT-LLM 在 NVIDIA 榜单上吞吐最高、SGLang 在复杂调度上吊打其他、llama.cpp 在端侧无人能敌……这些数字都对，但都不该成为你选型的依据。原因很简单：每个数字都是在它最擅长的场景测的，到你手上场景的迁移性几乎为零。
本文给出推理引擎选型的系统框架：先问 5 个问题、再对比 9 个引擎、最后按 3 个场景给决策。读完本文，你应该能针对任何推理需求，在 30 分钟内给出"选哪个引擎、为什么、风险在哪"的判断。这是 从零部署一个推理服务 与 作品集项目 的引擎决策依据。
一、选型总原则：先问五个问题
1. 五个真正的决策维度
GitHub star 数、NVIDIA 榜单第一、论文里 24× 加速——这些是结果指标，不是决策依据。真正决定选型的只有五个维度：
┌─────────────────────────────────────┐
│ 你要部署的模型 │
└─────────────────────────────────────┘
│ │ │ │ │
┌─────────────▼─┐ ┌──────▼──────┐ ┌──▼─────┐ ┌──▼──────┐ ┌──▼─────────┐
│① 模型类型 │ │② 硬件 │ │③ 部署形态│ │④ 性能目标│ │⑤ 团队能力 │
│ CNN/Transformer│ │ NVIDIA/AMD/ │ │ 在线/批/ │ │ 延迟优先 │ │ Python/C++/│
│ /LLM/Diffusion │ │ Intel CPU/ │ │ 流式/ │ │ vs │ │ 运维能力/ │
│ │ │ 移动端 │ │ 端侧 │ │ 吞吐优先 │ │ 时间预算 │
└────────────────┘ └─────────────┘ └─────────┘ └─────────┘ └────────────┘
│ │ │ │ │
└─────► 引擎家族 ◄──────┘- 模型类型：决定用哪个"引擎家族"。LLM → vLLM/TensorRT-LLM 系；经典 CV/NLP 模型 → ONNX Runtime/TensorRT；端侧 → llama.cpp/TFLite。
- 硬件：决定引擎的可用集合。NVIDIA → 所有引擎都行；AMD → vLLM/TensorRT-LLM 的 ROCm 分支；Intel CPU → OpenVINO；移动端 → TFLite/CoreML/llama.cpp。
- 部署形态：决定引擎的"最后一公里"。在线服务 → vLLM serve / TGI / Triton；离线批 → 任何引擎的 Python API；流式 → vLLM stream；端侧 → llama.cpp 静态库。
- 性能目标：延迟优先还是吞吐优先？延迟优先 → 投机解码 + 小 batch；吞吐优先 → continuous batching + 大 batch。
- 团队能力：决定工具复杂度的上限。Python 团队 → vLLM 上手快；C++ 团队 → TensorRT/TRT-LLM 不痛苦；运维薄弱 → 别碰需要 build engine 的方案。
2. 五问清单
Q1: 你的模型是 LLM（≥ 1B 参数，Transformer 解码器）吗？
是 → 进入 LLM 引擎选型（v2.1）
否 → 经典引擎选型（v2.2）
Q2: 你的硬件是什么？
NVIDIA GPU → vLLM/TensorRT-LLM/TGI/SGLang
AMD GPU → vLLM (ROCm) / TensorRT-LLM (ROCm, 不全功能)
Intel CPU → OpenVINO / ONNX Runtime
移动端 → TFLite / CoreML / llama.cpp
边缘设备（Jetson 等） → TensorRT / llama.cpp
Q3: 你的部署形态？
在线服务 → 需要 HTTP API + 并发管理
离线批处理 → 直接 Python API
流式生成 → 需要 stream 接口
端侧 App → 静态库 + 量化模型
Q4: 性能目标是延迟还是吞吐？
延迟优先（聊天、补全） → 投机解码 + 小 batch
吞吐优先（批处理、文档摘要） → continuous batching + 大 batch
都重要 → 上 autoscale，集群级解耦
Q5: 团队能力？
Python only → vLLM / TGI
Python + C++ → TensorRT-LLM / 自定义 kernel
有 NVIDIA 背景选 TensorRT 系，没有选 vLLM选型的最小可行动作
不要做"引擎调研 PPT"。按五问筛出 2 个候选引擎，各花 4 小时跑通最小可用原型，用 推理基准测试实践 的方法测一遍，选那个"原型最快跑通、运维最不难受"的。一次 8 小时的动手实验，胜过三周的趋势报告。
二、九大引擎横向对比
1. 对比表
下面是九个主流推理引擎的横向对比。维度选了七个最影响选型的：支持 LLM、量化方式、批处理策略、服务化、跨硬件、学习曲线、社区生态。
| 引擎 | LLM 支持 | 量化方式 | 批处理策略 | 服务化 | 跨硬件 | 学习曲线 | 社区生态 |
|---|---|---|---|---|---|---|---|
| vLLM | ★★★ 一级支持 | AWQ/GPTQ/FP8/INT8 | PagedAttention + continuous batching | 内置 OpenAI 兼容 API | NVIDIA / AMD (ROCm) | ★★ 易 | ★★★ 极活跃 |
| SGLang | ★★★ 一级支持 | AWQ/GPTQ/FP8 | RadixAttention + 复杂调度 | 内置 OpenAI 兼容 API | NVIDIA 主，AMD 部分 | ★★☆ 中 | ★★☆ 上升中 |
| TensorRT-LLM | ★★★ 一级支持 | INT8/INT4/FP8/SmoothQuant | In-flight batching | 通过 Triton | NVIDIA only | ★★★ 难（需 build engine） | ★★ 中等，NVIDIA 主导 |
| TGI (HuggingFace) | ★★★ 一级支持 | AWQ/GPTQ/INT8/FP8 | continuous batching | 内置 Rust HTTP 服务 | NVIDIA / AMD | ★★ 易 | ★★ 中等 |
| Triton (NVIDIA) | 不直接支持 LLM（作 backend 框架） | 通过 backend | 通过 backend | ★★★ 标准化 | NVIDIA / CPU / 任意 | ★★★ 难 | ★★★ 标准工业级 |
| ONNX Runtime | ★★ 较弱（非优化方向） | INT8/INT4 | 静态 / 动态 batch | 通过 Triton 或 Python | NVIDIA / AMD / Intel / 移动 | ★★ 易 | ★★★ 跨平台生态 |
| OpenVINO | ★★ 较弱 | INT8/INT4 | 静态 batch | 通过 OVMS | Intel CPU/GPU/VPU | ★★☆ 中 | ★★ Intel 主导 |
| llama.cpp | ★★★ 一流 | GGUF Q4_K_M 等多种 | 单请求为主，无 continuous batching | 通过 llama-server | NVIDIA / AMD / CPU / 移动 / Mac | ★☆ 极易 | ★★★ 端侧统治级 |
| TFLite | ★ 较弱 | INT8 / float16 | 静态 batch | 通过 ML Service / Task Library | Android / iOS / 边缘 | ★★ 易 | ★★★ 移动端标准 |
2. 引擎详解
vLLM
vLLM 是 2023 年由 UC Berkeley 出品的开源 LLM 推理引擎，凭借 PagedAttention 与 continuous batching 一战成名。它是今天云端 LLM 推理的事实标准。
优势：
- PagedAttention 解决了 KV cache 内存碎片，能接更多并发
- continuous batching 让多请求真正并行而不是排队
- OpenAI 兼容 API 开箱即用，迁移成本极低
- 社区极活跃，新模型 / 新量化方法上线快
劣势：
- 大 batch 时显存吃紧（默认 gpu_memory_utilization=0.9 占满）
- 复杂调度（多轮对话、structured output）不如 SGLang
- 部署复杂度比 TGI 略高（参数多）
适合：云端在线 LLM 推理的首选，从 0 到 1 的最稳路径。
SGLang
SGLang 是 2024 年崛起的新引擎，核心创新是 RadixAttention——把多轮对话、shared prefix 的 KV cache 复用做到极致。详见 批处理与请求调度 的"复杂调度场景"。
优势：
- RadixAttention 在多轮对话、shared prefix 场景吞吐显著高于 vLLM
- 原生支持 structured output（JSON mode、regex constrained generation）
- 复杂 prompt 编排（multi-turn + few-shot + RAG）的吞吐优势明显
劣势：
- 社区比 vLLM 小，生态插件少
- 学习曲线略陡，复杂 API 不如 vLLM 直观
- 单请求延迟与 vLLM 相当，没有碾压优势
适合：多轮对话、structured output、复杂 prompt 编排场景。
TensorRT-LLM
TensorRT-LLM 是 NVIDIA 官方维护的 LLM 推理引擎，基于 TensorRT 构建，目标是"NVIDIA 硬件上的极致性能"。
优势：
- 在 NVIDIA 硬件上吞吐通常比 vLLM 高 20–50%
- FP8 量化在 H100/H200 上拿 2× 加速（其他引擎尚不完整）
- 与 Triton 集成最完整，企业级部署最稳
劣势：
- 学习曲线最陡：需 build engine，调参参数上百
- 只支持 NVIDIA，硬件绑定深
- 社区小，新模型上线慢（要等 NVIDIA 适配）
- 调试难，报错信息晦涩
适合：NVIDIA 硬件、对延迟/吞吐极敏感、团队有 NVIDIA 工程背景的场景。
TGI
TGI（Text Generation Inference）是 HuggingFace 推出的 LLM 推理服务，定位与 vLLM 类似但更早。
优势：
- HuggingFace 生态原生支持，新模型上线最快
- Rust HTTP 服务，性能稳定
- 部署最简单（一行 docker 命令）
劣势：
- 性能通常比 vLLM 略低（10–20%）
- 复杂调度能力弱于 SGLang
- 商业使用需 HuggingFace 商业许可
适合：HuggingFace 生态深度用户、对部署简单度要求极高的场景。
Triton
Triton 是 NVIDIA 的通用推理服务框架，本身不是 LLM 引擎，但能作为 backend 框架集成 vLLM/TensorRT-LLM/ONNX Runtime 等多种引擎。
优势：
- 多模型多版本统一编排（LLM + embedder + reranker 共存）
- 标准 metrics 端口，与 Prometheus 无缝集成
- 多种 backend（Python / TensorRT / ONNX / vLLM）
- 企业级特性：模型 ensembling、灰度发布、A/B 测试
劣势：
- 学习曲线陡（配置复杂、概念多）
- 不直接提供 LLM 优化（要 backend 配合）
- 调试链路长
适合：多模型共存、企业级运维、需要统一 metrics 的中大型团队。
ONNX Runtime
ONNX Runtime 是微软出品的跨平台推理引擎，定位"模型格式标准化 + 跨硬件"。
优势：
- 跨平台最强（NVIDIA / AMD / Intel / 移动端通吃）
- 模型导出为 ONNX 后可在多引擎间迁移
- EP（Execution Provider）机制让硬件加速可插拔
劣势：
- LLM 优化不如 vLLM/TRT-LLM（不是它专注的方向）
- 模型导出 ONNX 后偶尔有数值漂移（详见 常见陷阱与反模式）
- 复杂模型导出失败率高
适合：经典 CV/NLP 模型跨平台部署、嵌入式推理、需要硬件可移植性的场景。
OpenVINO
OpenVINO 是 Intel 出品的推理引擎，专攻 Intel CPU/GPU/VPU。
优势：
- Intel CPU 上性能极强（AVX-512 优化深度）
- INT8 量化在 Intel 硬件上效果好
- 与 Intel 硬件生态（CPU/iGPU/Movidius VPU）无缝集成
劣势：
- 在非 Intel 硬件上完全无用
- LLM 支持弱（不是重点方向）
- 社区小，更新慢
适合：纯 Intel CPU 部署、边缘设备（Movidius）、企业内网部署（不能用 GPU）。
llama.cpp
llama.cpp 是 ggerganov 出品的 C++ LLM 推理引擎，端侧 LLM 的事实标准。
优势：
- 跨硬件最广（CPU / NVIDIA / AMD / Mac M 系列 / iOS / Android）
- GGUF 量化格式在保持质量的同时大幅压缩（Q4_K_M 通常 1/4 原大小）
- 单二进制无依赖，部署极简
- Mac M 系列上 Metal 后端性能吊打所有其他引擎
劣势：
- 不支持 continuous batching（单请求为主）
- 大 batch 性能远不如 vLLM/TRT-LLM
- 没有原生 HTTP 服务（llama-server 是简易版）
适合：端侧部署、个人设备、Mac 用户、低并发本地服务。
TFLite
TFLite 是 Google 出品的移动端推理框架，Android 端侧推理事实标准。
优势：
- Android 上系统级集成、性能最稳
- 与 TensorFlow 模型无缝迁移
- NNAPI / GPU Delegate 跨 SoC 适配
劣势：
- 不支持 LLM（不在这个赛道）
- iOS 上不如 CoreML
- 模型转换偶有问题
适合：Android 端侧 CV/NLP 模型部署、移动 App 集成。详见 移动端部署。
三、LLM 在线推理：三强争霸
LLM 在线推理是当前最热的赛道，三家主导：vLLM、TensorRT-LLM、SGLang。
1. 三家定位差异
| 维度 | vLLM | TensorRT-LLM | SGLang |
|---|---|---|---|
| 一句话 | "开源、易用、生态广" | "NVIDIA 上的极致性能" | "复杂调度专家" |
| 性能 | 中（比 TRT-LLM 低 10–30%） | 最高（NVIDIA 上） | 与 vLLM 持平或略高 |
| 易用性 | 最易（一行 CLI） | 最难（build engine） | 中（API 复杂） |
| 部署时间 | 1 小时 | 1–3 天 | 2 小时 |
| 适合团队 | 任何 Python 团队 | 有 NVIDIA 工程背景 | 有复杂 prompt 编排需求 |
| 典型用户 | 中小厂、初创 | 大厂、对延迟极敏感 | 多轮对话、structured output |
2. 三大场景选型
场景 A：从 0 到 1 上线 LLM 服务
首选 vLLM。
理由：
- 部署最简单（一行 CLI）
- 社区最活跃，遇到问题易找答案
- 新模型上线快（通常模型发布当天 vLLM 就支持）
- 性能虽不是最高，但 SLA 不到极致差异的水平
何时切换到 TensorRT-LLM：当 vLLM 性能无法满足 SLA、团队有 NVIDIA 工程背景、且部署预算 ≥ 1 周时。
场景 B：极致性能 / 成本敏感
首选 TensorRT-LLM。
理由：
- 在 NVIDIA 硬件上吞吐通常最高（详见 TensorRT-LLM 案例）
- FP8 在 H100 上拿额外 2× 加速
- 大规模部署（数十卡以上）时单实例性能差距被放大
何时切回 vLLM：当团队没有 NVIDIA 工程背景、当 build engine 失败率高、当新模型上线紧迫时。
场景 C：复杂调度场景
首选 SGLang。
理由：
- 多轮对话 + 共享 system prompt 场景，RadixAttention 让 KV cache 复用率显著提升
- structured output（JSON mode、regex constrained）原生支持
- 复杂 prompt 编排（few-shot + RAG + multi-turn）吞吐优势明显
何时切回 vLLM：当场景就是单轮问答、structured output 不重要、社区支持比性能差异更关键时。
3. 实战对比
同样的 Llama-2-7B-Chat，A100 40GB，32 并发，prompt 1024 / output 256：
| 引擎 | TTFT (ms) | TPOT (ms) | 吞吐 (tok/s) | 显存 (GB) |
|---|---|---|---|---|
| vLLM 0.6.3 | 200 | 20 | 1100 | 36 |
| TensorRT-LLM 0.13 | 180 | 16 | 1450 | 32 |
| SGLang 0.3 | 195 | 19 | 1150 | 35 |
数字仅供说明三家差异，绝对数字随配置变化大。复现方法见 推理基准测试实践。
别被单一 benchmark 骗了
上面数字只反映"单轮问答"场景。换成"多轮对话 + 共享 system prompt"场景，SGLang 可能反超 vLLM 50%。选型必须在你真实业务场景上 benchmark，不能照搬公开榜单。详见 推理基准测试实践 的"防作弊清单"。
四、经典模型服务：Triton + ONNX Runtime / TensorRT
非 LLM 模型（CV、NLP 经典模型、表格模型）的服务化，主路径是 Triton + ONNX Runtime 或 Triton + TensorRT。
1. 为什么是 Triton 而不是直接用引擎
经典模型服务的需求与 LLM 不同：
- 模型多（一个产品可能有几十个 CV 模型）
- 单模型推理快（毫秒级），开销主要在服务层
- 多版本共存（A/B 测试、灰度发布）
Triton 解决的是"多模型多版本的统一编排"，性能反倒是次要。详见 Triton 推理服务。
2. ONNX Runtime vs TensorRT
| 维度 | ONNX Runtime | TensorRT |
|---|---|---|
| 跨硬件 | ★★★ NVIDIA/AMD/Intel/移动 | NVIDIA only |
| 性能 | 中（NVIDIA 上比 TRT 低 10–30%） | 最高（NVIDIA 上） |
| 模型支持 | 几乎所有框架导出都行 | 复杂模型偶有 op 不支持 |
| 部署 | 简单（无 build engine） | 需 build engine |
| 适合 | 跨硬件、跨平台 | 纯 NVIDIA、对延迟极敏感 |
3. 实战选型
单一 NVIDIA 硬件 + 延迟极敏感 → TensorRT + Triton
跨硬件（含 CPU / 移动端） → ONNX Runtime + Triton
模型多 + 多版本共存 → Triton（无论后端）
团队没 NVIDIA 背景 → ONNX Runtime五、端侧：llama.cpp / TFLite / CoreML
端侧推理的约束完全不同于云端：内存紧、电量敏感、算力受限、要兼容多 SoC。详见 llama.cpp 与 GGUF 与 移动端部署。
1. 三家定位
| 引擎 | 平台 | 主要模型类型 | 备注 |
|---|---|---|---|
| llama.cpp | iOS / Android / Mac / Linux / Windows | LLM (1B–7B 量化后) | LLM 端侧统治级 |
| TFLite | Android / iOS（次之） | CV / NLP 经典模型 | Android 系统级集成 |
| CoreML | iOS only | CV / NLP / 小型 LLM | Apple 系系统集成 |
2. 实战选型
iOS 上跑 LLM → llama.cpp（Metal 后端）+ GGUF Q4_K_M
Android 上跑 LLM → llama.cpp（OpenCL 后端）+ GGUF Q4_K_M
Android 上跑 CV 模型 → TFLite + NNAPI / GPU Delegate
iOS 上跑 CV 模型 → CoreML（Apple 硬件优化最好）
跨平台 (iOS+Android) → llama.cpp（最统一）3. 端侧独特考量
- 内存预算：iPhone 15 Pro 8GB，模型最多占 2–3GB（系统其他进程要内存）——7B 模型 Q4 后 4GB，得选 1.5B
- 电量：连续推理 30 分钟掉电，要有低电量降速策略
- SoC 适配：Apple A17 / Snapdragon 8 Gen 3 / 天玑 9300 性能差 2–3×，要运行时检测后端
- 隐私合规：端侧推理是合规优势（数据不出端），但模型权重保护是另一挑战
详见 作品集项目 的"端侧 LLM App"项目，与 部署设计原则 的"显存预算先算清"。
六、选型决策树
把上面所有内容浓缩成一棵决策树：
你要部署的模型是什么？
│
├─ LLM (≥ 1B 参数)
│ │
│ ├─ 在云端
│ │ │
│ │ ├─ NVIDIA + 团队有 NVIDIA 背景 + 性能极敏感
│ │ │ → TensorRT-LLM
│ │ │
│ │ ├─ 多轮对话 / structured output / 复杂 prompt
│ │ │ → SGLang
│ │ │
│ │ └─ 其他情况（默认）
│ │ → vLLM
│ │
│ ├─ 在端侧
│ │ │
│ │ └─ → llama.cpp + GGUF
│ │
│ └─ 在 Intel CPU
│ → vLLM CPU 后端 / OpenVINO
│
├─ 经典 CV/NLP 模型
│ │
│ ├─ 在 NVIDIA GPU
│ │ ├─ 性能极敏感 → TensorRT + Triton
│ │ └─ 性能够用 → ONNX Runtime + Triton
│ │
│ ├─ 在 Intel CPU → OpenVINO + OVMS
│ │
│ └─ 在移动端
│ ├─ Android → TFLite
│ ├─ iOS → CoreML
│ └─ 跨平台 → ONNX Runtime Mobile / llama.cpp
│
└─ Diffusion 模型（图像生成）
│
└─ 在云端 → TensorRT for Diffusion / vLLM-like 服务（Stable Diffusion 专用）
在端侧 → CoreML（iOS）/ NCNN（Android）决策树的用法
按这棵树走，能避开 80% 的选型错误。剩下 20% 是边界情况（多模态、特殊硬件），需要查具体 案例研究。决策树不应替代动手 benchmark——筛出 2 个候选后，仍要用 推理基准测试实践 的方法实测对比。
七、常见的"选型反模式"
下面是真实见过的几种选型失败模式：
1. "NVIDIA 榜单第一选它"
TensorRT-LLM 在 NVIDIA 公开榜单上吞吐第一，但榜单测的是离线批处理——你的场景是在线服务，p99 延迟可能比吞吐更重要。榜单只测一个维度，业务场景测的是另一个维度。详见 推理基准测试实践 的"测什么"。
2. "团队只懂 Python 选 vLLM"
vLLM 确实易上手，但当你的业务需要 FP8 量化、需要 H100 极致性能时，没 NVIDIA 工程背景的团队硬上 TensorRT-LLM 反而更慢——build engine 失败率高、调参时间长、上线遥遥无期。选型要服从团队能力，不服从社区情绪，这是 部署设计原则 的"团队栈要尊重"。
3. "新模型上线紧迫选 vLLM"
vLLM 上新模型确实快，但当你团队已经积累了一堆 TensorRT 部署脚本与监控时，为了一个新模型改用 vLLM，等于换技术栈——监控、运维、灰度全要重做。新模型适配成本 < 整套运维重做成本，这种情况下应该等 NVIDIA 适配 TensorRT-LLM 而不是换引擎。
4. "端侧选 vLLM"
vLLM 不是为端侧设计的——没有 Metal/OpenCL 后端、没有手机内存预算概念、没有电量优化。强行用 vLLM 在 iPhone 上跑 LLM，性能比 llama.cpp 差 10–20×。端侧就是 llama.cpp 与 GGUF 的天下。
5. "用 ONNX Runtime 跑 LLM"
ONNX Runtime 不是 LLM 优化方向——它的强项是经典模型跨平台。强行用它跑 LLM 会发现：不支持 continuous batching、没有 PagedAttention、KV cache 管理原始。性能比 vLLM 低 5–10×。详见 ONNX Runtime 跨平台。
八、延伸阅读
- 什么是推理加速 —— 引擎在推理栈的位置
- 总体架构解剖 —— 引擎与上下游的关系
- vLLM 与 PagedAttention —— vLLM 引擎深入
- TensorRT-LLM —— TRT-LLM 引擎深入
- ONNX Runtime 跨平台 —— ONNX Runtime 引擎深入
- OpenVINO 与 CPU 推理 —— OpenVINO 引擎深入
- llama.cpp 与 GGUF —— llama.cpp 引擎深入
- Triton 推理服务 —— 编排层深入
- 从零部署一个推理服务 —— 选型后的端到端落地
- 推理基准测试实践 —— 选型对比的方法论
- 调参与性能调优 —— 引擎选定后的调参
- 部署设计原则 —— 引擎选型的纪律
- 常见陷阱与反模式 —— 选型反模式的完整版
- 批处理与请求调度 —— 各引擎的批处理差异
- 模型服务化与编排 —— 编排层基础
参考资料
- vLLM Documentation —— vLLM 官方文档
- SGLang: Documentation —— SGLang 官方仓库
- TensorRT-LLM: Documentation —— TRT-LLM 官方文档
- TGI: Text Generation Inference —— HuggingFace TGI 仓库
- Triton Inference Server: User Guide —— Triton 官方文档
- ONNX Runtime: Documentation —— ONNX Runtime 官方文档
- OpenVINO: Documentation —— OpenVINO 官方文档
- llama.cpp: GitHub —— llama.cpp 仓库
- TensorFlow Lite: Documentation —— TFLite 官方文档
- MLPerf Inference: Language —— 跨引擎标准化基准