大模型推理引擎选型指南：vLLM、SGLang、TensorRT-LLM与llama.cpp部署实战

1. 推理引擎到底在解决什么问题先把话说直白一点推理引擎就是让训练好的大模型真正跑起来、能对外服务的那个“发动机”。你手里有一个几十GB甚至上百GB的模型权重文件它本身只是一堆数字不能直接回答问题。推理引擎要做的事情就是把这些权重加载进显存、管理好KV Cache、调度好每一个请求、在合适的硬件上把矩阵乘法算得又快又稳最后把token一个一个吐给用户。我刚开始接触这块的时候觉得“不就是加载模型然后generate吗”后来才发现里面的坑深得很。同样一个Qwen3-32B用不同的推理引擎部署吞吐量能差三到五倍首token延迟能差一个数量级。这不是夸张是实测数据。所以选对推理引擎、理解它的调度逻辑直接决定了你的服务能不能扛住真实流量。当前主流的推理引擎大致分几个流派。vLLM走的是PagedAttention加连续批处理Continuous Batching的路线核心优势是高吞吐、显存利用率高社区活跃度也是最高的。SGLang在vLLM的基础上做了RadixAttention对多轮对话和前缀共享场景优化明显结构化输出能力也很强。TensorRT-LLM是NVIDIA自家的走编译优化路线在特定硬件上性能极致但灵活性和部署复杂度是代价。llama.cpp则是另一条路主打CPU和边缘设备推理量化方案丰富甚至能在安卓手机上跑。这几个引擎没有绝对的优劣只有适不适合你的场景。下面我会把每个引擎的核心机制、部署实操、踩坑经验都拆开讲清楚。2. vLLM的核心架构与调度逻辑拆解2.1 EngineCore、Scheduler、Executor三者怎么配合很多人用vLLM就是一句vllm serve或者Docker起一个OpenAI兼容接口但一旦遇到性能问题就懵了。要排查问题必须理解vLLM内部的三个核心组件是怎么协作的。EngineCore是整个推理引擎的中枢它负责接收上层传来的请求管理整个生命周期。你可以把它理解成一个“总调度室”。它内部持有Scheduler和Executor的引用驱动整个推理循环。Scheduler是决策层。每个推理step开始前Scheduler要决定哪些请求可以加入这一批、哪些请求需要被抢占preemption、KV Cache的block怎么分配。vLLM的Scheduler采用的是连续批处理策略也就是说不是等一整批请求都结束才处理下一批而是每生成一个token就重新组批已经完成的请求立刻退出新的请求立刻补进来。这是vLLM高吞吐的核心原因。Executor是执行层。它拿到Scheduler给出的batch信息后负责实际调用模型做前向计算。在单卡场景下就是简单的模型forward在多卡场景下会涉及张量并行TP或流水线并行PP的通信协调。三者的交互流程大致是这样的EngineCore收到新请求交给SchedulerScheduler判断是否有足够的KV Cache block如果有就加入waiting队列并尽快调度Scheduler输出本step的scheduler_output包含要跑的序列组信息Executor根据scheduler_output执行模型前向产出logits采样器从logits中采样出token更新序列状态完成的序列退出释放KV Cache block循环回到第2步注意vLLM的Scheduler在显存不足时会触发抢占。被抢占的序列会被换出到CPU内存swap或者直接重算recompute。recompute模式下如果请求很长重算开销会非常大表现为延迟突然飙升。2.2 PagedAttention为什么能省显存PagedAttention是vLLM的招牌技术灵感来自操作系统的虚拟内存分页。传统做法是给每个序列预分配一段连续的显存来存KV Cache但序列长度不确定预分配多了浪费少了不够用而且碎片化严重。PagedAttention把KV Cache切成固定大小的block默认16个token一个block这些block在物理显存上可以不连续通过一个block table做映射。这样一来显存浪费从原来的60%-80%降到不到4%不同序列可以共享block比如相同的system prompt动态扩缩容变得非常自然实测下来同样一张A100 80G用HuggingFace Transformers直接推理只能跑一个7B模型且并发极低换成vLLM可以同时服务几十个并发请求吞吐量提升非常明显。2.3 新版本性能下降是怎么回事社区里经常有人反馈“vLLM升级到某个版本后性能反而下降了”。这个现象确实存在原因通常有几类第一默认配置变了。比如某个版本把max_num_seqs的默认值调低了或者把gpu_memory_utilization的默认值改了导致可用KV Cache变少。第二调度策略调整。V1引擎架构和V0有本质区别V1在部分场景下延迟更低但在极端高并发下可能不如V0稳定。第三CUDA Graph的捕获策略变化某些shape下没有命中CUDA Graph导致额外开销。我的建议是升级前一定要做基准测试不要盲目追新。固定一个稳定版本记录好吞吐和延迟基线升级后对比。如果下降明显先检查配置项是否变化再考虑回退。3. vLLM部署实操从Docker到生产环境3.1 Docker镜像选型与启动参数vLLM官方提供了vllm/vllm-openai镜像这是最常用的部署方式。关于“vllm docker镜像中带模型吗”这个问题答案是不带。镜像里只有推理引擎本身模型权重需要你通过挂载卷或者运行时下载的方式提供。一个典型的启动命令长这样docker run --gpus all \ -v /data/models:/models \ -p 8000:8000 \ --shm-size16g \ vllm/vllm-openai:v0.27.1 \ --model /models/Qwen3-32B \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 256 \ --dtype auto \ --served-model-name qwen3-32b几个关键参数解释一下。--tensor-parallel-size是张量并行数等于你用几张卡。--max-model-len是最大上下文长度这个值直接影响KV Cache的显存占用设太大容易OOM。--gpu-memory-utilization控制vLLM能用多少比例的显存默认0.9留10%给CUDA上下文和其他开销。--max-num-seqs是同时处理的最大序列数调大能提升吞吐但增加显存压力。--shm-size这个参数很多人会忽略。Docker默认的共享内存只有64MBvLLM在多进程通信时需要更大的共享内存不设置的话可能报错或者性能异常。我一般设16g起步。3.2 加载Qwen3-Embedding-0.6B这类小模型热词里提到了用vllm/vllm-openai:v0.27.1加载qwen3-embedding-0.6b。Embedding模型和生成模型的部署方式略有不同需要加--task embed参数docker run --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:v0.27.1 \ --model /models/Qwen3-Embedding-0.6B \ --task embed \ --max-model-len 512 \ --gpu-memory-utilization 0.3Embedding模型通常序列较短显存占用小gpu-memory-utilization可以设低一些。调用时用OpenAI兼容的/v1/embeddings接口即可。3.3 部署DeepSeek和GLM系列的注意事项DeepSeek系列模型尤其是MoE架构的在vLLM上部署有几个特殊点。MoE模型的专家层需要额外的显存和通信开销--tensor-parallel-size的设置需要更谨慎。如果显存不够可以考虑开启--enable-expert-parallel。另外DeepSeek的tokenizer有特殊配置确保vLLM版本支持该模型架构太老的版本可能直接报“unsupported architecture”。GLM系列比如热词提到的glm5.3对vLLM版本有要求。我的经验是先查vLLM的release notes和supported models列表确认目标版本是否已经合并了该模型的实现。如果没有要么等新版本要么用社区fork的镜像。不要硬试浪费时间。3.4 Windows上能不能跑vLLM“vllm windows”这个搜索词出现频率很高。直接说结论vLLM官方不支持原生Windows它依赖的很多底层库如flash-attn、vllm的CUDA kernel是为Linux编译的。Windows用户有几个选择用WSL2在WSL里跑vLLM这是最接近原生体验的方案用Docker Desktop for Windows底层还是WSL2换用llama.cpp它对Windows支持很好WSL2方案需要注意的是要确保WSL2能访问GPU需要安装正确的NVIDIA驱动和CUDA toolkit for WSL。显存是通过WSL的GPU passthrough访问的性能损失很小实测在5%以内。4. SGLang与vLLM的差异及选型建议4.1 RadixAttention解决的是什么问题SGLang最核心的差异化技术是RadixAttention。它用一棵基数树Radix Tree来管理KV Cache的前缀共享。什么意思呢假设你有100个请求system prompt都是一样的传统做法是每个请求各存一份KV Cache浪费大量显存。RadixAttention会自动识别相同前缀只存一份所有请求共享。这个优化在多轮对话、few-shot场景、Agent工具调用场景下效果极其明显。实测在system prompt占2000token、用户问题只有100token的场景下SGLang的吞吐能比vLLM高出2-3倍。4.2 结构化输出的能力对比SGLang另一个强项是结构化输出。它内置了基于正则表达式和JSON Schema的约束解码可以直接保证输出符合指定格式。vLLM也支持guided decoding通过outlines或xgrammar但SGLang的集成更原生性能开销更小。如果你在做Agent应用需要模型稳定输出JSON格式的工具调用参数SGLang在这方面的体验会更好。但如果只是普通对话两者差距不大。4.3 什么时候选SGLang什么时候选vLLM我的选型逻辑是这样的场景推荐引擎理由通用对话服务vLLM社区大、文档全、踩坑少多轮对话/AgentSGLang前缀共享优化明显结构化输出密集SGLang约束解码更原生需要最新模型支持vLLM新模型适配速度最快极致单卡性能TensorRT-LLM编译优化更彻底边缘/CPU部署llama.cpp量化方案最丰富SGLang和vLLM并不是互斥的很多团队两个都用根据业务场景分流。5. llama.cpp与边缘推理实践5.1 量化方案怎么选llama.cpp的核心竞争力在于量化。它支持从Q2到Q8多种量化级别还有K-quants和I-quants等改进方案。选量化的原则很简单在可接受的精度损失内选最小的。我的经验数据是Q4_K_M是性价比最高的档位7B模型量化后约4GB精度损失在可接受范围内。Q5_K_M精度更好但体积增加约20%。Q8_0几乎无损但体积接近FP16的一半优势不大。Q2和Q3量化损失明显除非显存极度受限否则不推荐。5.2 安卓版llama.cpp能干什么“llama.cpp android 版”这个搜索需求很真实。现在确实可以在安卓手机上跑小模型比如Qwen3-1.7B或Llama-3.2-3B的Q4量化版。体验嘛能用但别期待太高。旗舰机骁龙8 Gen系列跑3B模型大概能到5-10 token/s1.7B能到15-20 token/s。适合做离线翻译、简单问答这类场景。部署方式一般是通过Termux安装编译或者用社区打包好的APK。需要注意的是手机散热长时间推理会降频速度会明显下降。5.3 llama.cpp的服务化部署llama.cpp也提供了llama-server兼容OpenAI接口。对于小团队或者个人开发者如果只有CPU服务器或者消费级显卡llama.cpp的服务化部署是最省心的选择。编译简单、依赖少、量化模型体积小启动速度快。./llama-server \ -m /models/qwen3-7b-q4_k_m.gguf \ -c 4096 \ --host 0.0.0.0 \ --port 8080 \ -ngl 99 \ -t 8-ngl是卸载到GPU的层数99表示全部卸载。-t是CPU线程数一般设为物理核心数。6. 常见问题与排查技巧实录6.1 显存OOM了怎么排查OOM是部署推理引擎最常见的报错。排查思路按优先级来第一检查gpu-memory-utilization是否设得太高。0.95以上很容易OOM建议0.85-0.90。第二检查max-model-len是否过大。KV Cache的显存占用和这个值成正比公式是2 * num_layers * num_kv_heads * head_dim * max_model_len * dtype_size * num_seqs。第三检查是否有其他进程占用显存用nvidia-smi确认。第四如果是多卡TP检查每张卡的显存是否均衡。6.2 吞吐量上不去怎么优化吞吐量低通常有几个原因。batch size太小检查max-num-seqs是否设得太保守。KV Cache不够显存利用率没拉满可以适当提高gpu-memory-utilization。CUDA Graph没生效某些动态shape场景下CUDA Graph会失效可以尝试固定batch size。网络瓶颈如果是多机部署检查节点间通信带宽。6.3 首token延迟高怎么办首token延迟TTFT高通常是prefill阶段慢。优化方向开启chunked prefill把长prompt的prefill拆成多个chunk避免阻塞其他请求。vLLM通过--enable-chunked-prefill开启。另外如果prompt很长考虑用prefix cachingvLLM的--enable-prefix-caching可以缓存相同前缀的KV。6.4 模型加载失败或架构不支持这类问题一般是vLLM版本和模型不匹配。解决步骤确认模型的architecture字段看config.json去vLLM的supported models列表查如果不在列表里升级vLLM版本或者找社区适配。有时候需要加--trust-remote-code但要注意安全风险只对可信来源的模型开启。问题现象可能原因解决方向CUDA out of memory显存不足降gpu-memory-utilization、降max-model-len吞吐低batch小/KV不足调大max-num-seqs、提高显存利用率TTFT高prefill阻塞开启chunked prefill模型加载报错架构不支持升级版本或换引擎多卡通信慢NCCL配置检查NCCL环境变量和网络输出乱码tokenizer不匹配确认tokenizer配置实操心得每次改配置只改一个参数改完做基准测试记录数据。同时改多个参数出了问题根本不知道是哪个引起的。这个习惯帮我省了大量排查时间。7. 推理引擎选型的个人经验做了这么多部署我最大的体会是没有最好的引擎只有最合适的组合。线上服务用vLLM做主力Agent场景用SGLang做补充边缘设备用llama.cpp兜底特定硬件上TensorRT-LLM榨性能。这套组合拳打下来基本能覆盖90%以上的场景。另外版本管理非常重要。生产环境不要用latest标签固定版本号做好镜像归档。我见过太多因为自动拉取最新镜像导致服务异常的案例。基准测试要常态化每次变更都跑一遍数据说话。最后分享一个小技巧vLLM的metrics接口/metrics暴露了大量Prometheus格式的指标包括吞吐、延迟、KV Cache使用率、排队请求数等。把这些指标接入监控面板能提前发现很多问题。比如KV Cache使用率持续接近100%说明该扩容了排队请求数持续增长说明吞吐到瓶颈了。这些比看日志直观得多。