2026 主流 LLM 推理引擎横评：vLLM / llama.cpp / TensorRT-LLM / NInfer 怎么选
到 2026 年，LLM 推理引擎已经不再是 vLLM 一家独大——llama.cpp、TensorRT-LLM、SGLang、NInfer、LMDeploy、TGI …十几条赛道各自开花。原因是模型结构在变（稠密 → MoE → 多模态），硬件在变（A100 → H100 → B200 → Apple M5），部署场景在变（单卡本地 → 集群生产 → 边缘离线）。任何一家通吃都做不到。本篇作为推理引擎系列第 3 篇，把当下最常用的四条赛道vLLM、llama.cpp、TensorRT-LLM、NInfer横向放到一张桌子上，从定位、性能、硬件适配、部署难度、怎么选五个维度做横评，10 分钟内帮你挑到合适的引擎。
一、四大主流框架速览
vLLM：Berkeley 2023 年发起的 Python 框架，核心竞争力是 PagedAttention（KV cache 像虚拟内存一样分页管理）+ 连续批处理。模型支持最宽（Qwen / Llama / Mistral / DeepSeek / Gemma / Phi / InternVL 等几百种），OpenAI 兼容 API 即装即跑，2 分钟上线。零编译、文档全、社区大，是中小团队和 PoC 阶段的事实默认。冷启动约 60 秒；v0.18.0 的 MRV2 runner 在 GB200 上拿到 56% 吞吐增益。
llama.cpp：Gerganov 2023 年 3 月单文件 C/C++ 原型起步，2026 年 10 月 v0.4.1 已 109k+ Star，被 Ollama / LM Studio / GPT4All / HF Transformers 选为底座。核心竞争力是 GGUF 量化家族（Q2_K / Q4_K_M / Q5_K_M / Q8_0 / IQ4_XS）+ 全硬件覆盖（CPU / AVX / Metal / CUDA / HIP / SYCL / Vulkan 六条后端）。优势是什么机器都能跑：16GB 内存的 Mac mini 到 4×RTX 5090 工作站同一条二进制。冷启动 < 1 秒，KV 不够会软卸载到 CPU 不会硬崩——消费级硬件、桌面开发者、本地离线场景的唯一答案。
TensorRT-LLM：NVIDIA 自家的编译型引擎，先用 modelopt 量化为 FP8/INT4/FP4 checkpoint，再用 trtllm-build 编译成针对特定 GPU、batch、序列长度定制的 CUDA kernel 图。引擎一旦编出来就跑满 Tensor Core。Llama-3.3 70B FP8 / H100 上 100 并发 2,780 tok/s，比 vLLM 高 14%。代价是首次编译 23 分钟，每换一次模型就要重编；v1.0 起 PyTorch backend 成默认路径，去掉编译门槛但损失 20-30% 峰值吞吐。适合固定单模型、长周期、最高吞吐。
NInfer：社区 2026 年新冒头的轻量框架，专攻老卡 + NVFP4 4-bit，目标是把 V100/A10 这类已经没有新价值的卡重新榨干。在 V100-32GB 上跑 Llama-3.3 70B NVFP4 能挤出 150 t/s 实际吞吐 + 155K 上下文，比 llama.cpp 同一张卡快 4-5 倍。定位介于 llama.cpp（极致轻、但慢）和 TensorRT-LLM（极快、但只吃新卡）之间——是给“还想榨干老硬件”的团队留的一条退路。详情见系列第 2 篇。
二、性能 / 硬件 / 部署对比表
下面这张表用同一台 4× H100 80GB + Llama-3.3-70B-Instruct FP8 / 上下文 8K / 50 并发作为口径横向对比，数字取自 Spheron 2026 年 9 月的公开基准 + 社区实测，单卡小工作站的数字另起一列辅助参考。注意 TTFT（Time to First Token）代表首字延迟，Decode 速度代表稳定输出阶段的每秒 token 数。
| 维度 | vLLM 0.18 | TensorRT-LLM 1.2 | llama.cpp 0.4.1 | NInfer-V100-Duo |
|---|---|---|---|---|
| Decode 速度（4×H100, 50 并发） | 1,850 tok/s | 2,100 tok/s（+14%） | ≈ 700 tok/s（CUDA 后端） | — 不支持多卡张量并行 |
| TTFT p50（50 并发） | 380 ms | 340 ms | 580 ms | — |
| 单卡 70B Q4_K_M 实际吞吐 | ≈ 65 tok/s | ≈ 80 tok/s（编引擎） | 30-40 tok/s（CUDA） | 150 tok/s（V100 NVFP4） |
| 最大上下文 | 128K（H100） | 256K（多模态分块） | 512K（GGUF 元数据） | 155K（MTP 槽位复用） |
| 硬件覆盖 | NVIDIA / AMD ROCm | 仅 NVIDIA | CPU / Apple Metal / NVIDIA / AMD / Intel / Vulkan | NVIDIA Volta+ 老卡 |
| 部署难度 | 中等（pip + docker） | 高（quantize + build + serve 三步） | 极低（一条二进制） | 中等（预编译 artifact + 配置） |
| 冷启动 | ≈ 60 s | ≈ 90 s（已编引擎） / 28 min（首次编） | ≤ 1 s | ≈ 25 s（artifact 加载） |
| 模型支持广度 | ★★★★★ | ★★★ | ★★★★（GGUF 全档） | ★★（Llama/Qwen 系） |
| OpenAI API 兼容 | ✓ | ✓（v0.15+） | ✓（/v1 端点） | ✓ |
三、硬件适配矩阵
选型的第二根稻草是手上有什么硬件。四种典型部署的答案：
- 纯 CPU / 服务器：只有 llama.cpp 一条路，靠 SIMD 跑 GEMM，7B Q4_K_M 应急 5-8 tok/s；其他三家要么不支 CPU，要么慢到不可用。
- Apple Silicon（M1-M5）：llama.cpp + Metal 是首选，8B Q4_K_M 在 M4 Pro 上 30+ tok/s，是 macOS 口碑档；MLX / LM Studio 同底座。
- NVIDIA GPU（H100 / A100 / RTX 4090/5090 / B200 / GB200）：四家全员在场。通用 + 快速上线 → vLLM；固定模型 + 极限吞吐 → TensorRT-LLM；长共享前缀 → SGLang；V100/A10 榨老卡 → NInfer + NVFP4。Ada/Blackwell 需要 CUDA 12.8+ 拿峰值。
- AMD GPU（MI300X / RX 7900 XTX）：vLLM 对 ROCm 有官方支持（MI300X 192GB HBM3 跑 70B FP8 可用）；llama.cpp HIP 后端能跑但缺优化；TensorRT-LLM 仅 NVIDIA。SGLang 0.5.x 补齐 MI300X。
一句话：用什么硬件，决定你能选什么引擎。别反过来先选引擎再配硬件。
四、怎么选——四个具体场景
- 本地 / 个人笔记本：
ollama run qwen2.5:7b或 LM Studio，底层都是 llama.cpp + GGUF，零依赖零编译。 - 50-200 并发小型生产 / 多模型 PoC：默认 vLLM。冷启动 60 秒可塞 K8s HPA auto-scaling，配 nginx 反代即对外 OpenAI 兼容 API。
- 高并发单模型生产（≥ 50 并发、固定模型半年以上）：上 TensorRT-LLM。28 分钟首次编译换 14% 吞吐 + 12% TTFT 优化，夜间闲时编、pool 预编引擎可秒启；v1.0 起 PyTorch backend 稳定可用，必要时绕开编引擎。
- 多轮对话 / RAG / 长系统提示 chat 产品：选 SGLang。RadixAttention 共享前缀算一次复用 N 次，TTFT 在长 system prompt + 长 RAG 场景下比 vLLM 低 30-50%。
五、小夏点评
- vLLM = 通用基线。把“选引擎”默认决策成本降到接近 0——新模型当天支持、文档一搜就到、OpenAI API 一接就跑。80% 场景里它的吞吐不是最高，但“拿到模型 → 跑起来”这段路径最短。
- llama.cpp = 民主化。把“本地跑 LLM”从黑客玩具推进到桌面默认。macOS / 树莓派 / Steam Deck / 老服务器这些非数据中心场景里，它是唯一答案。
- TensorRT-LLM = 极限工程化。把模型变针对硬件深度定制的 kernel 图，用编译时间换峰值性能。NVIDIA 数据中心跑固定模型、规模到 100+ 卡时优势比单卡 14% 更大。
- NInfer = 老兵续命。新硬件没优势，但在 V100 / A10 / 1080Ti 这类被“判死刑”的卡上重新榨出生产级吞吐。
选引擎不是站队，而是匹配 workload 与硬件。开源推理没有银弹，但用对了位置的那一条，你就已经赢了 80% 项目。
六、给读者的建议
- 先看硬件再看引擎。V100 / A10 / 4090 / AMD 卡先排除 TensorRT-LLM；Apple Silicon / 纯 CPU 排除 vLLM / SGLang 默认 NVIDIA 模式。
- 看 workload 形状。请求共享前缀比例高（> 60%）→ SGLang；请求独立（≥ 80%，内容审核 / 日志分析）→ vLLM / TensorRT-LLM。
- 一句话总结：多模型快速上线 vLLM；固定模型极限生产 TensorRT-LLM；长前缀敏感 SGLang；老卡继续榨 NInfer；硬件受限 llama.cpp。
- 别迷信 benchmark。在你自己的硬件 + 自己的 trace上跑一遍才算数。
- 下一步读物：底层量化区别看系列第 1 篇 llama.cpp 深度（post 1659）；NVFP4 / V100 细节看第 2 篇 NInfer 体验（post 1654）。
本文素材综合 Spheron Blog《vLLM vs TensorRT-LLM vs SGLang: H100 Benchmarks 2026》基准、PremAI《10 Best vLLM Alternatives》吞吐表、Deploybase 引擎选型指南，及 vLLM / TensorRT-LLM / llama.cpp / NInfer 2026 季度发布说明，由小夏改写为中文 + 加点评，不逐字翻译。
