vLLM、SGLang、TGI、llama.cpp怎么选？大模型部署框架对比

“模型已经下载好了，接下来用什么框架启动？”在本地大模型部署中，vLLM、SGLang、TGI 和 llama.cpp 经常被放在一起比较。但它们的目标硬件、模型格式、服务方式和优化方向并不完全一致。

先给结论：如果目标是 GPU 服务器上的高吞吐 API 服务，通常优先评估 vLLM 或 SGLang；如果重点是跨 CPU/GPU/Apple Silicon 等多种硬件、GGUF 量化和轻量本地运行，llama.cpp 更有代表性；TGI 曾是 Hugging Face 重要的生产推理工具，但 Hugging Face 当前官方文档已经明确标注其进入 maintenance mode，新项目应结合模型和功能需求重点评估 vLLM、SGLang 等仍在快速演进的 Runtime。

四个框架先看定位，不要先看“谁最快”

框架	主要定位	更适合	选型时注意
vLLM	高性能 LLM/VLM 推理与服务	GPU 服务器、企业 API、高并发、多卡	模型与硬件功能矩阵、版本变化较快
SGLang	高性能模型服务与复杂生成工作负载	LLM/VLM、Agent、结构化生成、服务优化	模型/Kernel/功能需要按版本核对
TGI	Hugging Face 文本生成服务工具	已有 TGI 生产环境、HF 体系遗留部署	官方已进入维护模式
llama.cpp	轻量、跨硬件的本地推理	GGUF、量化、CPU/桌面/边缘、CPU+GPU 混合	与数据中心高并发 Runtime 的目标不同

vLLM 适合什么场景？

vLLM 是面向大模型推理和在线服务的 Runtime。当前官方文档列出的核心能力包括 PagedAttention、continuous batching、chunked prefill、prefix caching、多种量化、speculative decoding，以及 Tensor、Pipeline、Data、Expert、Context Parallel 等分布式推理能力。

它还提供 OpenAI-Compatible Server，便于把本地模型作为标准 API 接入上层应用。

更适合以下场景：

单机或多机 GPU 服务器；
企业内部 OpenAI-Compatible API；
多用户并发推理；
大模型、多模态模型、Embedding 等统一服务；
需要 Tensor Parallel / Expert Parallel 等分布式推理。

但 vLLM 更新速度较快，不同 GPU、新模型、量化格式、MoE 和长上下文能力的支持状态需要以当前版本文档为准。

SGLang 适合什么场景？

SGLang 同样面向高性能模型推理和服务，并提供 OpenAI-compatible 接口。其生态中包含 Serving、Benchmark、结构化输出、缓存和面向复杂推理工作负载的优化工具。

从工程选型角度，SGLang 常与 vLLM 一起作为服务器级推理 Runtime 进行 A/B 测试，特别是在长 Prompt、Agent、结构化生成、特定模型或 Kernel 优化场景下。

不建议脱离模型和负载简单下结论“vLLM 一定快”或“SGLang 一定快”。不同版本、模型、输入输出长度和并发会改变结果。

TGI 现在还适合新项目吗？

Text Generation Inference（TGI）由 Hugging Face 推出，支持模型分片、Tensor Parallel、流式输出、量化、PagedAttention 等生产推理能力，并提供与 OpenAI Chat Completions 兼容的接口。

但 Hugging Face 当前官方文档已明确说明：TGI 进入 maintenance mode，后续主要接受小型 Bug 修复、文档和轻量维护，并推荐使用 vLLM、SGLang，以及 llama.cpp/MLX 等本地引擎。

因此：

已有稳定 TGI 系统：没有必要仅因为维护状态立即迁移，可评估现有模型、功能和生命周期。
新建长期演进平台：应把框架维护活跃度、模型支持速度和团队生态纳入选型。

llama.cpp 为什么和前三者不完全是同一类？

llama.cpp 的目标是以较少依赖在广泛硬件上运行大模型。官方项目支持多档低比特量化、CUDA、HIP、Metal、Vulkan、SYCL、CANN 等后端，并支持 CPU+GPU 混合推理。

其典型优势是：

GGUF 模型生态成熟；
可在 CPU、桌面 GPU、Apple Silicon、部分 NPU 等环境运行；
通过低比特量化降低内存/显存需求；
部署简单，适合个人、本地工具、边缘和资源受限环境。

llama.cpp 也提供 HTTP Server，但如果目标是数据中心 GPU 上的大规模多租户、高并发模型服务，通常还需要与 vLLM/SGLang 做同负载比较，而不能只看“都提供 API”。

模型格式会直接限制框架选择吗？

会。不同 Runtime 支持的模型格式、量化方式和自定义架构不同。

Hugging Face 原生权重通常更容易进入 vLLM/SGLang/TGI 路径；
GGUF 是 llama.cpp 生态中的核心格式；
GPTQ、AWQ、FP8、INT4、GGUF 等量化格式并非每个框架支持范围完全一致；
新发布模型可能先支持 Transformers，之后才被特定高性能 Runtime 纳入。

因此选型第一步不是装框架，而是先确认“目标模型 + 权重格式 + GPU/CPU 平台”的兼容矩阵。

多 GPU 部署怎么看？

vLLM 和 SGLang 更常用于服务器级多 GPU 推理，可通过 Tensor Parallel 等方式把模型分布到多张 GPU。TGI 也支持模型 Sharding。llama.cpp 可以使用 GPU Offload 和多 GPU，但其典型优化路径与数据中心 Runtime 不完全相同。

多 GPU 不只是框架参数问题，还需要同时确认：

模型是否适合当前并行方式；
GPU 之间的 PCIe/NVLink/NVSwitch 拓扑；
NCCL/通信库是否正常；
每张 GPU 的显存是否均衡；
Context 和 KV Cache 是否给并发留下空间。

如果都支持 OpenAI API，是不是就可以随便换？

OpenAI-Compatible API 可以降低上层应用改造成本，但“接口兼容”不等于功能完全一致。Tool Calling、Reasoning Parser、Structured Output、Multimodal、Embeddings、LoRA、日志、监控和安全机制的实现会因框架和版本不同而变化。

正式迁移前应使用真实应用请求验证参数、响应格式和边界行为。

按需求选框架，可以先这样判断

需求	优先评估	原因
数据中心 GPU 高并发 API	vLLM / SGLang	服务优化、并发、多卡和活跃生态
长 Prompt / Agent /复杂生成	vLLM / SGLang A/B	不同模型和版本性能差异需实测
已有 Hugging Face TGI 平台	TGI + 迁移评估	先保证业务稳定，再规划生命周期
CPU / Apple Silicon / 资源受限本地部署	llama.cpp	跨硬件、GGUF、低比特量化
模型大于单卡显存	先看模型兼容，再看多卡 Runtime	不能只依据框架名称做决定

框架选型最有效的方法：用同一负载做 A/B

建议固定：

模型和权重 Revision；
精度/量化方式；
GPU 数量和并行度；
Context、输入长度和输出长度；
并发或请求速率；
采样参数和工具调用模式。

重点记录 TTFT、TPOT/ITL、Output Throughput、E2E、错误率、显存占用和持续运行稳定性。对于生产系统，还需要评估监控、日志、安全、升级和回滚，而不是只比较单次 TPS。

常见问题 FAQ

Q1：vLLM 和 SGLang 谁性能更高？

没有脱离模型和负载的固定答案。应在相同模型、相同 GPU、相同输入输出和并发下测试。

Q2：TGI 已进入维护模式，是不是不能用了？

不是。维护模式不代表现有部署立即失效，但意味着新功能演进速度和长期生态需要重新评估，新项目应优先比较仍在快速更新的 Runtime。

Q3：llama.cpp 只能用 CPU 吗？

不是。llama.cpp 支持 CUDA、HIP、Metal、Vulkan、SYCL 等多种加速后端，也支持 CPU+GPU 混合推理。

Q4：框架能启动模型就代表适合生产吗？

不代表。生产还需要验证真实并发、长 Context、错误率、稳定性、监控、安全和升级策略。

赋创可提供的支持

赋创可结合客户模型版本、GPU/CPU 平台和真实业务请求，协助梳理 vLLM、SGLang 等推理软件栈，并通过同条件 A/B 建立部署与性能基线，为平台选型和后续扩展提供参考。

方案咨询

为模型和硬件选择合适的推理 Runtime

赋创可结合模型版本、GPU/CPU 平台、精度、Context、并发和业务接口需求，协助梳理推理框架与软件栈，并建立可复现的性能基线。

咨询算力方案浏览指南