1. 从“能用”到“好用”推理引擎选型的现实困境最近在折腾大模型本地部署的朋友估计都绕不开一个灵魂拷问我到底该用哪个推理引擎是社区里风头正劲的vLLM是学术圈新秀SGLang是NVIDIA亲儿子TensorRT-LLM还是那个“老而弥坚”的llama.cpp这感觉就像去4S店选车销售跟你讲了一堆参数什么零百加速、扭矩、热效率但真开起来堵在北京三环上你才知道哪个最适合自己。我手头有几台不同配置的机器一台双路RTX 3090的工作站一台海光DCU的国产化服务器还有一台只有CPU的旧笔记本。目标也很明确把Qwen3、Llama3这些主流模型跑起来不仅要能跑通还要跑得稳、跑得快、资源吃得少。在这个过程中我把这四个引擎都深度折腾了一遍从安装部署、模型加载、推理测试到生产环境适配踩的坑比写的代码都多。今天这篇我就从一个一线部署者的角度掰开揉碎了聊聊这“四强”到底该怎么选。这不是一份冷冰冰的Benchmark跑分报告而是一份带着温度、沾着泥土的实战心得。你会发现没有“最好”的引擎只有“最适合”你当下场景的那个。2. 核心特性与设计哲学它们到底想解决什么问题在深入细节之前我们必须先理解这四个引擎各自的“出身”和“抱负”。它们的底层设计哲学直接决定了其擅长和不擅长的场景。2.1 vLLM吞吐量之王与持续批处理的革命者vLLM的核心贡献是一个叫做PagedAttention的算法。你可以把它想象成计算机操作系统里的虚拟内存分页管理。传统的大模型推理就像你请了一个记忆力超强但有点“轴”的专家GPU每次对话推理请求都必须把整本百科全书模型的KV Cache完整地、连续地放在他面前。如果同时和多个专家对话多请求并行他们就会为了抢“桌面空间”GPU显存打起来导致很多专家闲着效率极低。PagedAttention 把这个过程“操作系统化”了。它把KV Cache切分成固定大小的“块”Block就像内存页。不同的对话请求可以共享这些块并且可以非连续地存放。这样一来GPU显存的利用率从“大通铺”变成了“高效公寓”碎片大大减少。这使得vLLM在处理高并发、流式输出、请求长度变化大的场景时吞吐量Tokens per Second能有数倍甚至数十倍的提升。它的设计目标非常明确最大化服务端的整体吞吐服务于云原生的大模型API服务。所以你会看到vLLM最早、最成熟的接口就是OpenAI兼容的API Servervllm.serve。注意vLLM对“投机采样”等高级解码特性的原生支持相对较晚它的强项在于利用PagedAttention把并行和调度做到极致。2.2 SGLang为复杂提示工程而生的“编程语言”如果说vLLM优化的是服务端资源那么SGLang优化的就是程序员的生产力。它的全称是Stochastic Graph Language核心思想是把大模型的推理过程特别是那些包含多轮对话、工具调用、分支判断的复杂提示Prompt抽象成一个有向无环图。举个例子一个复杂的Agent工作流可能包含“根据用户问题生成搜索关键词 - 调用搜索API - 根据搜索结果生成分析 - 如果分析不充分则进行第二轮搜索”。用传统的Python脚本写你需要手动管理对话历史、拼接Prompt、处理中间结果代码会变得冗长且易错。SGLang允许你用更声明式、更结构化的方式来描述这个工作流。它提供了像parallel、select、fork这样的原语让你能直观地表达并行、分支和循环。运行时SGLang的调度器会智能地分析这个计算图将可以并行的部分比如多个独立的工具调用批量发送给后端引擎它本身不负责具体计算后端可以是vLLM、Llama.cpp等从而提升整体执行效率。SGLang的终极目标是让复杂提示程序的编写和运行像写配置一样简单高效。它特别适合开发RAG系统、多模态Agent、自动化评测框架。2.3 TensorRT-LLM在NVIDIA硬件上榨干最后一滴性能这是NVIDIA的“亲儿子”是TensorRT生态针对大模型推理的垂直深度优化方案。它的工作流程非常“工程师化”编译 - 优化 - 部署。模型编译你需要将Hugging Face格式的模型如Qwen2-7B通过TensorRT-LLM提供的工具链编译成一个高度优化的TensorRT引擎文件.engine。这个过程会进行算子融合、内核自动调优、精度校准支持FP8, INT8量化等大量底层优化。运行时部署部署时你加载的是这个编译好的.engine文件而不是原始的PyTorch模型。运行时组件Triton Inference Server插件或独立的Python运行时负责执行这个高度优化的引擎。TensorRT-LLM的优势在于极致的单卡性能和延迟。由于是针对特定GPU架构如Ampere, Hopper和特定模型进行了“贴身”优化它的推理速度往往是所有方案中最快的。但它也有明显的代价使用复杂度高灵活性差。编译过程耗时动辄数小时且编译好的引擎与GPU型号、TensorRT版本甚至输入输出尺寸强绑定。模型有任何改动哪怕只是改一下最大生成长度都可能需要重新编译。它的定位很清晰对延迟和成本极度敏感的线上生产环境且硬件和模型相对固定。2.4 llama.cpp极简主义的跨平台捍卫者llama.cpp的故事始于一个简单的需求在MacBook上用CPU跑通LLaMA模型。它用纯C/C实现核心依赖极少主要是ggml这个张量库通过大量的手工汇编优化AVX2, AVX512, NEON来挖掘CPU、Apple Silicon甚至部分GPU通过CUDA/OpenCL后端的潜力。它的设计哲学是“KISS”。模型格式统一为自有的.gguf一种智能量化的二进制格式推理通过一个简单的命令行接口或轻量级C API完成。没有复杂的服务框架没有动态批处理一切追求极致的轻量和可控。llama.cpp的强项在于无与伦比的部署便利性一个可执行文件一个模型文件就能在任何有现代CPU的设备上运行。强大的量化支持其gguf格式集成了多种精妙的量化算法如IQ4_XS, Q8_0在精度损失极小的情况下将模型压缩到难以置信的大小如70B模型可压至4GB以下使其能在消费级硬件上运行。资源消耗极低纯推理时内存占用稳定没有Python进程的内存膨胀问题。它的弱项也很明显缺乏原生的高性能服务化能力如动态批处理、多路并发更适合单次推理、研究调试或资源极度受限的边缘场景。3. 实战部署与性能调优手把手带你避开深坑理论说再多不如动手跑一跑。下面我结合自己的踩坑经历分别聊聊这四个引擎在实战中的关键步骤和那些文档里不会写的细节。3.1 vLLM部署从快速入门到生产级稳定安装与环境准备官方推荐用pip安装但这里有个大坑vLLM对CUDA版本、PyTorch版本非常敏感。以最新的v0.26.1为例如果你用pip install vllm它可能会自动安装一个与你现有环境不兼容的PyTorch版本导致后续运行失败。推荐的做法是# 1. 首先确保有一个正确版本的PyTorch (例如 CUDA 11.8) pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # 2. 然后安装vLLM指定不安装其依赖的PyTorch pip install vllm --no-deps # 3. 再手动安装vLLM的其他核心依赖 pip install transformers4.36.0 accelerate0.25.0对于海光DCU或昇腾NPU等国产硬件vLLM社区有非官方支持但需要从源码编译并打上针对特定计算库如CANN的补丁。这个过程非常繁琐需要自行解决算子映射和内存地址映射问题如昇腾模型的权重地址映射除非有强烈需求否则不建议新手尝试。启动服务与基础使用最基本的启动命令很简单python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --port 8000但生产环境你需要关注更多参数--tensor-parallel-size 张量并行度多卡时必须设置。--gpu-memory-utilization GPU显存利用率目标默认0.9在显存紧张时可调低至0.8以避免OOM。--max-model-len 模型支持的最大上下文长度需要根据模型能力和你的需求设置设置过大会浪费显存。--disable-log-requests 生产环境建议关闭请求日志提升性能。性能调优与“输出不一致”问题有用户反馈vllm serve输出不一致这通常不是bug而是解码策略的配置问题。vLLM默认使用采样sampling而非贪婪解码greedy decoding。如果你需要确定性输出必须显式设置--temperature 0。# 在启动服务器时指定 --temperature 0 # 或在请求API时指定 curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-7b, prompt: Hello, world, temperature: 0, max_tokens: 50 }另外使用vllm bench进行基准测试时要区分“吞吐量”和“延迟”测试场景通过--request-rate或--num-prompts参数来模拟不同负载。3.2 TensorRT-LLM部署一次编译持续“飞翔”编译流程详解以在RTX 3090Ampere架构上编译Qwen2.5-7B-Instruct的FP16版本为例# 1. 拉取TensorRT-LLM代码并安装依赖这是一个漫长的过程 git clone https://github.com/NVIDIA/TensorRT-LLM.git cd TensorRT-LLM pip install -r requirements.txt # 2. 使用官方脚本编译模型 # 这里需要准备一个包含模型权重的目录 python scripts/build_wheel.py # 先构建TensorRT-LLM的wheel包并安装 cd examples/qwen # 修改配置脚本指定模型路径、精度、GPU架构等 # 然后运行编译脚本这可能会花费1-2小时 bash build.sh编译成功后你会得到一个.engine文件。这个文件是硬件和模型参数的“结晶”换一张不同架构的GPU比如从3090换到4090这个文件就不能用了。部署与推理编译后你可以使用TensorRT-LLM自带的Python运行时进行简单测试但生产环境强烈推荐集成到NVIDIA Triton Inference Server中。Triton提供了动态批处理、模型队列、监控等企业级特性。你需要编写一个Triton的模型配置config.pbtxt将TensorRT-LLM的后端插件配置进去。这个过程有学习成本但一旦跑通其稳定性和性能是非常可靠的。3.3 llama.cpp部署极致简约无处不在模型量化与转换llama.cpp只认.gguf格式。你需要从Hugging Face下载原始模型然后用convert.py脚本转换。# 克隆llama.cpp仓库 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp pip install -r requirements.txt # 下载原始Qwen2.5模型 (假设已通过git-lfs下载到./qwen2.5-7b-original) # 转换为F16格式的gguf python convert.py ./qwen2.5-7b-original --outtype f16 --outfile qwen2.5-7b-f16.gguf # 进一步量化成更小的IQ4_XS格式推荐精度损失小 ./quantize ./qwen2.5-7b-f16.gguf ./qwen2.5-7b-iq4_xs.gguf iq4_xsIQ4_XS是目前社区认为在精度和尺寸上平衡得非常好的量化格式7B模型可以压缩到不到4GB在RTX 3090上也能获得极快的推理速度。运行与交互推理可以直接用命令行# 交互式对话 ./main -m ./qwen2.5-7b-iq4_xs.gguf -n 512 --interactive # 作为简单的API服务器功能远不如vLLM强大 ./server -m ./qwen2.5-7b-iq4_xs.gguf -c 4096 --port 8080对于Qianfan-OCR这类多模态模型llama.cpp社区也有扩展支持但通常需要自己编译开启相关编译选项如-DLLAMA_BUILD_EXAMPLESON的版本并找到对应的模型转换脚本。3.4 SGLang部署编织你的提示词工作流SGLang的安装相对简单pip install sglang。它的核心不是部署一个模型服务而是编写和运行提示程序。一个简单的并行调用示例import sglang as sgl from sglang import function, system, user, assistant, gen, set_default_backend from vllm import AsyncEngineArgs, AsyncLLMEngine # 1. 设置后端这里用vLLM backend AsyncLLMEngine.from_engine_args( AsyncEngineArgs(modelQwen/Qwen2.5-7B-Instruct) ) set_default_backend(backend) sgl.function def parallel_qa(questions): with sgl.parallel(): for q in questions: with sgl.user(): sgl.print(Question: q) with sgl.assistant(): sgl.print(gen(answer, max_tokens100)) # 2. 运行 questions [什么是人工智能, 如何学习编程, 天气真好对吗] parallel_qa.run(questions)在这个例子中三个问题被并行地发送给vLLM后端处理而不是传统的串行for循环这在处理大量独立查询时能大幅缩短总耗时。与vLLM/llama.cpp后端协同SGLang的强大在于其后端抽象。你可以轻松切换后端# 切换到llama.cpp后端 from sglang.backend.runtime_endpoint import RuntimeEndpoint backend RuntimeEndpoint(http://localhost:8080) # 假设llama.cpp server在运行 set_default_backend(backend)这样你就可以用SGLang的高级编程接口去驱动一个由llama.cpp提供的基础推理能力的服务结合了易用性和部署灵活性。4. 横向对比与选型决策矩阵看完各自的细节我们来一场面对面的“PK”。下表从多个维度对比了这四个引擎特性维度vLLMSGLangTensorRT-LLMllama.cpp核心目标高吞吐推理服务复杂提示编程框架极致单卡性能极简跨平台推理性能强项吞吐量(多请求并行)程序执行效率(工作流优化)延迟与单请求速度低资源消耗量化后性能易用性中等API直观但生产调优需经验高(对开发者友好)低(编译部署复杂)极高(开箱即用)部署复杂度中等依赖Python生态低 (作为库集成)高(需编译绑定硬件)极低 (单文件)硬件支持NVIDIA GPU (主流)后端决定 (支持vLLM, llama.cpp等)NVIDIA GPU(深度绑定)全平台(CPU/Apple/NVIDIA/AMD)模型支持广泛 (Hugging Face格式)广泛 (依赖后端)主流模型 (需官方支持或自己写插件)广泛 (需转GGUF)服务化能力原生强大(动态批处理API Server)需结合后端需集成Triton弱 (基础HTTP Server)量化支持一般 (通过后端如AWQ)依赖后端强大(FP8, INT8, 编译时优化)顶级(GGUF格式多种算法)最佳场景云上多用户API服务高并发流式输出AI Agent复杂RAG自动化评测对延迟敏感的固定模型生产推理个人开发调试边缘设备CPU环境如何根据你的场景做选择场景一我要搭建一个类似ChatGPT的对外服务预计有很多用户同时聊天。首选vLLM。它的PagedAttention和持续批处理就是为这种高并发、长文本、流式输出的场景而生的。虽然初期调优有点麻烦但一旦稳定其吞吐量和资源利用率是其他方案难以比拟的。vllm serve提供的OpenAI兼容接口也让前端集成变得异常简单。场景二我在开发一个复杂的AI应用里面有很多“if-else”和并行工具调用的逻辑。首选SGLang。它能让你的代码从面条式的Prompt拼接中解放出来变得清晰可维护。后端可以灵活选择vLLM追求吞吐或llama.cpp追求部署简便。它的价值在于提升开发效率和复杂工作流的运行时性能。场景三我有一个固定的大模型部署在线上要求单次响应速度最快成本控制极严。首选TensorRT-LLM。忍受一次漫长的编译过程换来的是线上推理时极致的速度和最低的GPU资源占用意味着更低的云服务成本。适合模型和硬件环境长期不变的业务场景。场景四我只是个研究者/个人开发者想在笔记本哪怕是Mac上快速验证模型效果或者资源有限。首选llama.cpp。下载一个可执行文件找一个GGUF格式的模型几分钟内就能开始对话。它的量化能力能让你在消费级硬件上跑起巨大的模型对于学习和原型验证来说性价比无敌。场景五混合场景。组合使用。例如用SGLang vLLMSGLang处理复杂的业务逻辑和工作流vLLM作为高性能推理后端提供算力。或者用llama.cpp在开发机上进行模型测试和量化确定模型后再用TensorRT-LLM为生产服务器编译一个极致优化的版本。5. 进阶话题生态、问题排查与未来展望关于Ollama与vLLM的区别很多人问Ollama。Ollama更像一个开箱即用的模型管理器和运行器它底层经常调用llama.cpp或其它本地库。它提供了更友好的命令行和API适合不想折腾的普通用户。而vLLM是一个工业级推理引擎专注于解决高并发服务下的性能瓶颈。Ollama简单但功能上限和性能上限不如vLLMvLLM强大但需要更多的运维知识。两者定位不同。常见问题排查思路vLLM输出不一致首先检查temperature参数是否为0。其次确认是否开启了do_sample。确保所有请求的随机种子seed一致。vLLM部署OOM降低--gpu-memory-utilization检查--max-model-len是否设置过大使用--tensor-parallel-size将模型切分到多卡考虑启用--enable-prefix-caching如果支持。TensorRT-LLM编译失败99%的原因是因为环境不匹配。严格对照官方文档的CUDA、TensorRT、PyTorch版本要求。使用Docker镜像是最省事的方法。llama.cpp速度慢首先确认是否使用了正确的量化格式如IQ4_XS。在命令行中指定正确的线程数-t参数。如果有GPU确保编译时启用了CUDA支持并通过-ngl参数将部分层卸载到GPU。未来趋势的一点个人看法目前看来vLLM在高性能服务领域的领先地位短期内很难被撼动其生态也在不断扩大如对更多模型架构、更多解码算法的支持。SGLang代表了一种趋势即大模型推理的编程范式正在从“低级的文本拼接”向“高级的声明式编程”演进。TensorRT-LLM会继续在NVIDIA的硬件生态中扮演性能标杆的角色随着工具链的完善易用性可能会有所提升。llama.cpp则牢牢占据了轻量级、跨平台的生态位特别是其强大的量化技术让大模型在端侧运行成为可能生命力会非常顽强。对于大多数团队我的建议是从vLLM开始构建你的核心服务能力用SGLang来构建复杂的应用逻辑在性能瓶颈处用TensorRT-LLM进行攻坚同时用llama.cpp作为模型量化、测试和边缘部署的利器。技术选型不是找一把“银弹”而是为不同的任务挑选最称手的“兵器”。