推理系统不是”谁更快”的问题，而是”分工协作、各司其职”。理解三层架构，才能选对工具。

大模型推理的三层架构

大语言模型（LLM）推理系统可以精确划分为三层架构：

层级	名称	解决的问题
L0 模型层	模型结构 + 权重	网络结构、参数、算子实现
L1 推理引擎层	vLLM / SGLang / TensorRT / MLC	如何让推理更快、更省显存、更高吞吐
L2 服务层	TGI / Infery / KServe	如何把模型变成稳定的 API 服务

理解这三层后，所有工具的关系一目了然。

推理引擎层（L1）：定位与主流方案

推理引擎层是大模型的 Runtime（运行时），负责高效调度、内存管理和批处理。

vLLM：推理 OS（操作系统级调度器）

vLLM 的核心能力：

PagedAttention（显存分页）
动态 Batching（并发处理）
高效 KV Cache 管理
FlashAttention

vLLM = 把 GPU 显存做成了”虚拟内存 + Kubernetes 调度器”。

适用场景：高并发 API 服务、多模型共存、长上下文、SaaS 场景。vLLM 是目前开源推理的事实标准。

SGLang：结构化输出场景的最强推理引擎

SGLang 在 vLLM 的并发模型上进一步优化，专注于结构化输出和多阶段推理：

Sub-Query Tree（树状并行执行）
Structured Output（JSON/函数调用）
FlashInfer + Kernel Fusion

SGLang = vLLM + 多阶段结构化推理优化 = 结构化输出第一。

适用场景：需要 JSON / 函数调用的 Agent 系统、工具调用 / 多轮模式。

TensorRT-LLM：企业场景吞吐量王者

TensorRT-LLM 以极致吞吐为目标，专为 NVIDIA GPU 优化：

FP8 / INT8 / INT4 量化加速
CUDA Kernel 编译优化
企业级 GPU 集群

TensorRT-LLM = GPU 编译器，极限优化吞吐，牺牲灵活性。

适用场景：大规模在线服务（每秒上千 RPS）、企业 GPU 集群。缺点：建模/编译复杂、动态性差、非 NVIDIA GPU 基本无法使用。

MLC LLM：跨后端推理编译器

MLC LLM 追求”Anywhere LLM”，让模型能在任何设备上运行：

WebGPU 推理（浏览器）
移动端 iOS/Android
LLVM/TVM 编译器体系

适用场景：移动端应用、浏览器推理、边缘设备（无 GPU）。

llama.cpp：轻量级 CPU/本地推理引擎

llama.cpp 是边缘设备和本地推理的首选：

CPU 高性能
GGUF 量化
便携、简单、全平台可用（树莓派也能跑）

适用场景：轻量模型、本地 App、插件、扩展、桌面软件等嵌入式场景。

服务编排层（L2）：模型 API 化与网关

服务层负责模型 API 化、扩容、负载均衡、限流、日志监控、多模型路由等。典型方案：

HuggingFace TGI：工程性好，自动 batching，支持多模型管理，适合企业 API 服务。
Infery：前端 + 后端一体推理网关，自动路由、监控、模型/版本管理，偏向产品化和企业可用。
OpenAI-Style Gateway / Ray Serve / KServe：多样化的 API 网关和服务编排方案。

工具对比表

工具	分类	最擅长的场景	不适合做什么
vLLM	推理引擎	高并发 API 服务	浏览器/移动端
SGLang	推理引擎	结构化输出 + Agent 系统	极端吞吐优化
TensorRT-LLM	编译器级推理引擎	企业级吞吐、FP8、NVIDIA GPU	多模型频繁切换
MLC LLM	编译器/跨平台	WebGPU / 移动端	大规模服务端
llama.cpp	轻量运行时	CPU 推理 / 本地软件	大吞吐场景
HF Transformers	框架	研究 / 原型开发	性能要求高的服务
TGI	服务层	模型 API 化	推理性能优化
Infery	服务层	企业多模型管理	底层算子优化

主流推理框架核心特性对比

特性	vLLM	SGLang	TGI	llama.cpp
模型兼容性	支持主流自回归模型，兼容 OpenAI API	支持多种开源模型，结构化输出	支持主流大模型，分布式部署	专为 LLaMA 系列设计，兼容 OpenAI API
量化支持	多种量化（AutoAWQ、bitsandbytes）	依赖后端，量化支持有限	丰富量化方案，支持多格式	原生 GGUF，多种低比特量化
KV-Cache 管理	PagedAttention 分页，Prefix 复用	跨请求缓存，RadixAttention	分页缓存，流水线并行	基础缓存，独立请求
并发与吞吐	连续批处理，高并发高吞吐	动态拼批，多线程并发	批处理，分布式并发	并发有限，适合低并发
部署方式	GPU/CPU，支持容器化	多平台，K8s/Docker	多后端，企业级云原生	轻量级，跨平台本地部署
接口兼容性	完全兼容 OpenAI API	类 OpenAI/结构化输出	RESTful API，社区适配 OpenAI	OpenAI API，Python 嵌入

推理框架选型流程

实际选型时，可结合以下关键维度快速判断：

硬件环境：CPU/Apple Silicon 优先 llama.cpp，GPU 场景优先 vLLM、TGI、SGLang。
模型规模：7B 以下本地优先 llama.cpp，大模型推荐 vLLM/TGI。
接口需求：OpenAI API 兼容优先 vLLM/llama.cpp，结构化输出优先 SGLang。
吞吐并发：高并发优先 vLLM/TGI，低并发本地优先 llama.cpp。
量化需求：极致量化优先 TGI/llama.cpp，vLLM 量化能力持续增强。
部署方式：云端容器化优先 TGI/vLLM/SGLang，本地轻量优先 llama.cpp。

容量与成本粗略估算公式

显存需求 ≈ 模型参数量 + 并发 × 每请求显存
最大并发 ≈ (GPU 显存总量 - 模型占用) / (输入长度 × 隐层维度 × 8 bytes)
吞吐量 ≈ 并发 × 平均输出 Token 数 / 平均响应时间
成本 ≈ 使用时长 × 单价 × 实例数 + 存储成本

以上公式仅供初步规划，实际需结合模型和硬件实测。

选型指南

本地开发 / 桌面应用：llama.cpp / MLC
Web App（浏览器）：MLC LLM (WebGPU)
企业级高并发 API 服务：vLLM 或 SGLang
Agent / 工具调用 / JSON 输出：SGLang
极限吞吐（上千 QPS）：TensorRT-LLM + Triton
简单部署：TGI
多模型管理、面向企业：Infery / AI Gateway

云原生工程师视角的终极类比

LLM 推理系统	云原生组件类比
vLLM	kube-scheduler + Kubelet（调度 + 运行时）
SGLang	kube-scheduler + Envoy Filter（结构化控制）
TensorRT-LLM	LLVM + GPU Driver（底层编译器）
MLC	WASM / Cross compiler（跨后端编译）
llama.cpp	containerd（轻量本地运行时）
TGI	Istio Gateway / APIServer（统一入口、路由）
Infery	企业 API Gateway + ModelOps

通过这些类比，可以快速定位每个系统的工程角色。

总结

大模型推理生态不是”谁更好”，而是”职责不同、场景不同”：

vLLM = 大模型推理的 Linux + Kubelet
SGLang = 结构化推理的 Envoy Filter
TensorRT-LLM = GPU 编译器（极限优化）
MLC = 跨平台运行时（WebGPU / 移动端）
llama.cpp = 本地轻量引擎
TGI / Infery = AI Gateway + Serving 层

大模型推理系统全景：从架构到选型