# 2026 主流 LLM 推理引擎选型：vLLM / SGLang / LMDeploy / KTransformers / TensorRT-LLM 到底怎么选

> 没有最快的推理引擎，只有最适合你场景的引擎。本文拆解 5 大主流推理引擎的核心技术（PagedAttention、RadixAttention、TurboMind 双引擎、CPU 极致优化、NVIDIA 内核融合），整理社区实测吞吐 / 延迟 / 显存数据，给出选型决策树与 6 个踩坑记录，帮你把"选引擎"这笔账算明白。

# 2026 主流 LLM 推理引擎选型：vLLM / SGLang / LMDeploy / KTransformers / TensorRT-LLM 到底怎么选

> 结论先行：没有"最快"的引擎，只有"最适合你场景"的引擎。
> - **NVIDIA 卡 + 延迟敏感（金融、实时对话）** → **TensorRT-LLM**
> - **高并发 + 长文本在线服务** → **vLLM**（社区事实标准，多硬件）
> - **复杂逻辑 / 结构化生成（JSON、多步推理、Agent）** → **SGLang**
> - **没有 GPU / 边缘设备 / 低功耗** → **KTransformers**（CPU 极致优化）
> - **国产化算力（昇腾等）/ 多模态全家桶** → **LMDeploy**
> - **单张 5090 要榨极限性能（单卡 + Qwen 系列）** → **NInfer**（C++/CUDA 手写 kernel，2026 新引擎）
> - **消费级单卡 + 大内存跑"服务器级"大 MoE（125B）** → **Strata**（整机分摊，一键安装）
>
> 模型权重只是"静态数据"，推理引擎才是决定你"跑得快不快、稳不稳、贵不贵"的发动机。同一个 27B 模型，换引擎吞吐量能差 5-6 倍——选错引擎，比选错显卡还亏。

## 1. 为什么引擎比显卡更该先选

很多人把预算砸在显卡上，却默认用 `transformers` 或随便一个框架起服务。实测里最常见的翻车：

- 用 HuggingFace `transformers` 直接起推理服务——**原型开发够快，生产环境吞吐效率低**，GPU 利用率经常停在 60% 以下，大量时间耗在 memory copy 和 kernel launch 开销上。
- 把 `llama.cpp` 当通用推理引擎跑长上下文——它的 **KV Cache 是静态分配**的，启动时按 `max_seq_len` 锁一大块显存，哪怕你当前只用了 10K，256K 的坑位也提前占死。
- 消费级卡上硬上 vLLM 默认配置跑 128K+ 上下文——显存占用 98%、GPU 利用率却只有 60% 多。

问题不在显卡，在引擎的**调度哲学**不同：KV 缓存怎么管、批处理怎么调度、算子怎么融合、能不能多硬件。下面逐个拆。

## 2. 五大引擎核心技术拆解

| 引擎 | 核心创新 | 硬件支持 | 部署复杂度 | 生态集成 |
|------|---------|---------|-----------|---------|
| **vLLM** | PagedAttention（KV 分页，显存碎片 <5%）+ 连续批处理 | NVIDIA / AMD / Intel | 中等 | LangChain 原生 + Prometheus |
| **SGLang** | RadixAttention（前缀树 KV 复用）+ 结构化生成 | 以 NVIDIA 为主 | 低（纯 Python） | 需封装适配 LangChain |
| **LMDeploy** | TurboMind 双引擎（C++/CUDA 计算图融合 + PyTorch 引擎） | NVIDIA + 国产 GPU（昇腾） | 中等 | RESTful / gRPC |
| **KTransformers** | CPU 极致优化（AMX 加速）+ 零 GPU 依赖 | CPU / 嵌入式 | 极低 | 无主流生态，需定制 |
| **TensorRT-LLM** | NVIDIA 内核融合 + INT4/FP8 量化 + 预编译引擎 | **仅 NVIDIA** | 高（需预编译） | Triton 推理服务器 |

### vLLM —— 社区事实标准，PagedAttention 是它的看家本领

- **PagedAttention** 借鉴操作系统虚拟内存的分页思想：把 KV 缓存切成固定大小的块，动态分配和回收。传统 attention 处理变长序列会产生 60-80% 的显存浪费，vLLM 把它压到 4% 以内，GPU 显存利用率从 30-40% 拉到 80% 以上。
- **连续批处理**：新请求可以实时插入正在执行的批次，GPU 计算资源始终饱和。
- 多硬件支持（NVIDIA/AMD/Intel）+ 张量并行多卡近乎线性扩展，是"大多数团队的安全选择"。

### SGLang —— 为"复杂逻辑"而生

- **RadixAttention** 用前缀树（Radix Tree）组织 KV 缓存，自动识别并复用相似请求的前缀，减少约 70% 的重复计算。
- **结构化生成**：用声明式语法描述复杂生成逻辑，JSON 输出、多步推理、外部 API 调用这类任务，端到端延迟比 vLLM 低约 40%。
- 纯 Python、部署门槛低。但**长序列吞吐量显著落后 vLLM**（见下表）。

### LMDeploy（InternLM）—— 国产算力 + 多模态全家桶

- **TurboMind 双引擎**：高性能引擎（C++/CUDA，计算图融合 + 内存池管理）+ PyTorch 兼容引擎（调试友好）。
- 内置完整工具链：量化压缩（INT4/INT8/FP16）→ 服务部署（RESTful / gRPC）→ 性能监控调试，一个框架跑全流程。
- 深度适配国产 GPU（昇腾），多模态（文本/图像/视频）支持。

### KTransformers —— 没有 GPU 也能跑大模型

- **零 GPU 依赖**：靠 CPU（尤其 AMX / AMX-tile 加速）极致优化，树莓派这类边缘设备都能跑，功耗 <10W。
- 适合无 GPU 环境、边缘计算、低功耗场景。代价是吞吐量只有 GPU 框架的约 1/5。

### TensorRT-LLM —— NVIDIA 生态的性能天花板

- NVIDIA 深度优化：内核融合 + INT4/FP8 量化 + 预编译引擎，做到纳秒级延迟，充分发挥单卡算力。
- **仅支持 NVIDIA 平台**，国产 GPU 或非 CUDA 环境用不了；部署需预编译，门槛高，但配 Triton 有企业级 SLA 保障。

## 3. 2026 两条"单卡极限 / 消费级整机"新路：NInfer 与 Strata

上面五个是"通用引擎"——拼的是覆盖面（多硬件、多模型、高并发）。2026 年冒出来两个反着来的：**NInfer 拼深度（单卡 + 特定模型榨极限），Strata 拼"消费级硬件跑服务器级模型"**。它们是两条独立路线，不是前五个的竞品。

### NInfer —— 单张 5090 的极限推理引擎（C++/CUDA 从头写）

- **定位**：为单张 RTX 5090 特化的单 GPU 引擎（官方仓库 `Neroued/ninfer`，Apache-2.0，约 2.6k star），跑 Qwen 3.5 Dense / MoE 架构，支持文本/图像/视频输入，暴露 OpenAI 兼容（`/v1`）与 Anthropic 兼容（`/v1/messages`）API。
- **为什么能榨极限**：C++/CUDA 手写 kernel，没有通用抽象层的 launch overhead 和内存拷贝税；直接吃 Blackwell 的 GDDR7 高带宽与 NVFP4/FP8 原生格式；按 Qwen 模型结构特化 KV 布局、专家路由与量化 kernel。
- **官方实测（RTX 5090，一手数据）**：
  - 并发解码（MTP3 推测解码）：Qwen3.8-27B NVFP4 在 C=1/2/4/8 并发下达 **147.7 / 291.0 / 522.2 / 922.4 tok/s**；Qwen3.6-27B NVFP4 C=8 可达 **1,146.9 tok/s**；MoE 的 35B-A3B C=8 达 **1,380.7 tok/s**。
  - 单请求长上下文：26 万 token 级 prefill 仍有 2,100-4,000 tok/s；24 万 token 上下文窗口 + MTP3 推测解码（draft 1-5 窗口）。
- **硬件边界（重要，一手证据）**：官方 README 明确"requires a single NVIDIA GeForce RTX 5090"，构建会**拒绝 `sm_120a` 以外的 CUDA 架构**，产品边界写死"one RTX 5090... per Engine、no multi-GPU"。即**当前 NInfer 只针对 5090**，不是 5090/5080 全 Blackwell 通用，也没有官方多卡支持。
- **为什么"单卡 + 单模型"反而快**：通用引擎为兼容 N 种硬件 × M 种模型，必须在抽象层做兼容，代价是 kernel 不能特化；NInfer 只深做 Qwen 系列 + 单张 5090，kernel 能针对这张卡的 GDDR7/NVFP4 和这个模型的结构定制，省掉通用层税。

### Strata —— 消费级单卡 + 大内存跑"服务器级" 125B MoE

- **定位**：`Niko1221/Strata`（MIT，约 4.6k star），把 125B 参数、含 24576 个专家的 MoE 模型（Qwen3.8-Flash-Next）落到一张 12-24GB 的 N 卡 + 64GB 内存的普通主机上，一键安装。
- **核心思路（整机分摊）**：GPU 只常驻最常用的一小撮专家、全部专家放内存、CPU 与 GPU 并行计算、SSD 存查表，再用 MTP（小模型猜词、大模型一次校验）一步产出多个词。基于 llama.cpp/ggml 构建，官方 credits 把 NInfer、Splash、HyperQwen 列为思路来源——**Strata 把 NInfer 这类"单卡榨性能"思路扩展到"整机分摊 125B MoE"的场景**。
- **官方实测（RTX 5070 12GB + 64GB 内存，一手数据）**：写出答案 60-95 tok/s、读 prompt 2,000+ tok/s（32K 输入）。
- **和 NInfer 的区别**：NInfer 是"一张卡 + 一个模型，榨极限吞吐"（偏引擎层）；Strata 是"整机（卡+大内存+SSD）分摊一个超大 MoE"（偏完整方案）。前者要 5090，后者 12GB 卡 + 64GB 内存就能跑 125B。
- **注意**：Strata 是"一次处理一个请求"的设计，不适合高并发对外服务；NInfer 虽是单 GPU，但启动时可配 1-8 个活动请求的有界并发（bounded FIFO），比 Strata 多一点点并发能力，但都不是服务网关。

## 4. 实测数据对比（社区公开测试汇总）

> 说明：以下数字来自中文社区公开测试汇总（CSDN 等），**非官方基线**，会随硬件型号、驱动版本、量化精度、序列长度浮动，仅作量级参考。

### 对比 A：四引擎同硬件（Llama-3-8B / A100-80G）

| 指标 | vLLM | SGLang | KTransformers | TensorRT-LLM |
|------|------|--------|--------------|-------------|
| 吞吐量（tokens/s，短序列） | 182 | 210 ↑15% | 35（CPU） | 250 ↑37% |
| 首 Token 延迟 TTFT（ms） | 48 | 39 ↓19% | 120 | 32 ↓33% |
| 显存效率 | 占用降 70% | 树结构开销 +15% | 无显存需求 | 量化模型显存降 60% |
| 长序列 8K 吞吐 | ✅ 142 req/s | ❌ 仅 44 req/s | ❌ 不支持 | ✅ 优化 attention |

关键观察：
- **短序列 / 结构化任务**：SGLang、TensorRT-LLM 延迟更低；**长序列**：vLLM 明显领先（142 vs 44 req/s）。
- TensorRT-LLM 综合性能最优，尤其 FP8 量化下大模型（Llama-405B）吞吐可达 vLLM 的约 2.1 倍——但代价是"仅 NVIDIA"。
- KTransformers 在纯 CPU 下 35 tokens/s，比 GPU 框架低一个量级，但它是"唯一能在无 GPU 环境跑大模型"的选择。

### 对比 B：LMDeploy vs vLLM vs SGLang

- **吞吐量**：128 并发下 LMDeploy 约 420 tokens/s，vLLM 约 230 tokens/s——LMDeploy 约 1.8 倍优势，主要来自 TurboMind 的持续批处理（Persistent Batching）+ 异步执行流水线 + 高性能 CUDA kernel。
- **分布式延迟**：8 卡 A100 下，vLLM 的 P99 尾延迟控制在 200ms 以内，比 LMDeploy 低约 70%，张量并行多卡扩展近乎线性（通信延迟仅占约 8%）。
- **内存效率**：SGLang 在结构化生成任务上内存占用可低至其他框架的约 1/6（前缀 KV 复用减少约 70% 重复计算）。

一句话：**LMDeploy 吞吐领先、vLLM 分布式延迟领先、SGLang 结构化任务效率领先**——各占山头，没有全能王。

## 5. 选型决策树

```
你要部署 LLM 推理服务
│
├─ 是 NVIDIA 卡 且 延迟敏感（金融交易/实时对话）？
│   └─ 是 → TensorRT-LLM（性能天花板，需预编译）
│
├─ 高并发 + 长文本在线服务（智能客服/长文档）？
│   └─ 是 → vLLM（PagedAttention 高吞吐，多硬件）
│
├─ 复杂逻辑 / 结构化生成（JSON/程序合成/多步 Agent）？
│   └─ 是 → SGLang（RadixAttention，延迟低）
│
├─ 没有 GPU / 边缘设备 / 低功耗？
│   └─ 是 → KTransformers（CPU 优化，树莓派可跑）
│
├─ 手里就是一张 RTX 5090，要跑 Qwen 系列，追求"这台机器上最快"？
│   └─ 是 → NInfer（C++/CUDA 手写 kernel，单卡极限；但当前只支持 5090，非全 Blackwell）
│
├─ 单卡显存不大（12-24GB）但有 64GB 内存，想跑 125B 级大 MoE？
│   └─ 是 → Strata（整机分摊，一键安装；但一次一个请求，不适合高并发）
│
└─ 国产化算力（昇腾等）/ 多模态全家桶？
    └─ 是 → LMDeploy
```

补充三点：
- **协议融合是趋势**：vLLM 和 SGLang 可以通过 API 组合（SGLang 前端 + vLLM 后端），兼顾吞吐和结构化生成。
- **MoE 模型**（如 DeepSeek 671B）：TensorRT-LLM 对 MoE 量化支持最佳；vLLM 需优化专家路由调度；KTransformers 靠 CPU+AMX 是"消费级硬件硬扛超大 MoE"的代表路线；Strata 是"整机分摊超大 MoE"的另一条路线。
- **单卡极限 vs 通用引擎要分清**：NInfer（单卡 + Qwen 系列榨极限）和通用引擎（vLLM/SGLang）不可直接比吞吐——比的是"同一张 5090 + 同一个 Qwen 模型下谁更快"，不是"谁覆盖面广"。

## 6. 踩坑记录

1. **别用 `transformers` 直接上生产**。它适合快速原型，生产环境吞吐低、GPU 利用率低。要上量就上 vLLM/SGLang/TensorRT-LLM。
2. **llama.cpp 跑超长上下文要手动管显存**。默认静态 KV 分配会提前锁死显存，长上下文场景要么换引擎，要么显式调 `max_seq_len`。
3. **消费级卡 + 长上下文 = 显存峰值杀手**。27B FP16 光权重就 ~54GB；256K 上下文的 KV Cache 粗估就要十几 GB，常规实现根本撑不住。要么量化、要么分页 KV（vLLM/SGLang）、要么量化 KV。
4. **TensorRT-LLM 有平台枷锁**。仅 NVIDIA，且要预编译。国产卡/Intel 卡团队别硬上。
5. **KTransformers 别指望速度**。它是"有没有"的解，不是"快不快"的解，纯 CPU 吞吐比 GPU 低一个量级。
6. **换引擎要重新压测**。同一模型换引擎，吞吐/延迟/显存都会变，别拿 A 引擎的基线去套 B 引擎。
7. **NInfer 别拿通用引擎基线套它，也别期待它跑别的卡/模型**。当前官方边界写死"单张 5090 + Qwen 系列 + 构建拒绝非 `sm_120a` 架构"，跑非 Qwen 模型或 5080 及老卡不是它的设计目标。
8. **Strata 别拿去做高并发对外服务**。它是"一次处理一个请求"的整机分摊设计，适合本地单用户/低并发；要对外 API 网关就上 vLLM/SGLang。首次启动会卡 1-3 分钟（往内存加载 35-55GB），等，别关窗口。

## 7. 参考来源

> 硬件规格以各引擎官方 GitHub 仓库 README 与官方文档为准；NInfer / Strata 数字为**官方 README 一手实测**（NInfer：RTX 5090；Strata：RTX 5070 12GB + 64GB），会随驱动/CUDA/量化/上下文浮动；其余吞吐量 / 延迟为**中文社区公开测试汇总**，非官方基线，仅作量级参考。

- vLLM（官方仓库，PagedAttention / 连续批处理）：https://github.com/vllm-project/vllm
- SGLang（官方仓库，RadixAttention / 结构化生成）：https://github.com/sgl-project/sglang
- LMDeploy / InternLM（官方仓库，TurboMind 双引擎）：https://github.com/InternLM/lmdeploy
- KTransformers（官方仓库，CPU/AMX 优化）：https://github.com/kvcache-ai/ktransformers
- TensorRT-LLM / NVIDIA（官方仓库，内核融合 / 量化）：https://github.com/NVIDIA/TensorRT-LLM
- FlagAttention / FlagOpen（官方仓库，FlashAttention 加速）：https://github.com/FlagOpen/FlagAttention
- NInfer（官方仓库，单卡 5090 C++/CUDA 引擎，含性能实测表）：https://github.com/Neroued/ninfer
- Strata（官方仓库，125B MoE 消费级整机分摊，含 README 实测表）：https://github.com/Niko1221/Strata
- 引擎基础 llama.cpp / ggml：https://github.com/ggml-org/llama.cpp


---
来源：https://laobanclaw.top/articles/engines-2026-inference-framework-selection/（AI 军火库）