大模型推理引擎选型与调优：vLLM、SGLang、TensorRT-LLM、llama.cpp 实战对比

1. 推理引擎到底在解决什么问题先把话说直白一点推理引擎就是让大模型“跑起来”的那层软件。你训练完一个模型权重文件躺在硬盘上它自己是不会吐字的。推理引擎负责把权重加载进显存、把请求排队、把计算图调度到 GPU 上、把生成的 token 一个个拼回文本最后通过接口返回给你。听起来像是个“胶水层”但实际做下来这层胶水的质量直接决定了你的吞吐量、首 token 延迟、显存占用和单位成本。我接触推理引擎是从最朴素的transformers直接generate()开始的那时候一张卡跑一个请求GPU 利用率低得可怜batch 稍微大一点就 OOM。后来陆续上手了 vLLM、SGLang、TensorRT-LLM、llama.cpp 这几套才真正理解为什么“推理引擎”会成为一个独立赛道。它们解决的核心矛盾其实就一句话在有限的显存和算力下尽可能多地同时服务请求同时把每个请求的延迟压到可接受范围。这个矛盾拆开来看涉及几个关键技术点。第一是KV Cache 的管理这是显存占用的大头传统做法按最大长度预分配浪费极其严重vLLM 的 PagedAttention 就是冲着这个来的。第二是请求调度多个请求长度不一、到达时间不一怎么组 batch、怎么抢占、怎么保证公平这是 scheduler 的活。第三是计算优化包括算子融合、量化、CUDA Graph 捕获、投机解码等TensorRT-LLM 在这方面做得最激进。第四是部署形态你是要单机单卡、多卡张量并行还是要塞进手机里跑llama.cpp 就是为端侧和 CPU 场景而生的。适合读这篇内容的人我大致分三类。一类是刚把模型跑通、准备上生产环境的工程师你需要知道选哪个引擎、怎么配参数。一类是已经在用 vLLM 或 SGLang、但遇到性能瓶颈或调度异常的运维和开发你需要理解内部流程才能排查。还有一类是对比选型的技术负责人你要搞清楚这几个引擎的边界在哪别在错误的场景上硬套。下面我会按“整体设计思路 → 核心机制拆解 → 实操部署流程 → 问题排查”这条线展开中间会穿插大量我在实际项目里踩过的坑和验证过的参数。涉及具体版本的地方我会标注清楚因为推理引擎这个领域版本迭代极快vLLM 从 0.4 到 0.6 再到 0.27 这种跨度API 和行为都变了不少。2. 四大推理引擎的设计思路与选型逻辑2.1 vLLMPagedAttention 与 EngineCore 的分层架构vLLM 是目前社区热度最高的开源推理引擎它的核心卖点就是PagedAttention。这个概念借用了操作系统虚拟内存分页的思路传统 KV Cache 要求每个序列分配一块连续显存长度按max_model_len算一个 8K 上下文的模型哪怕你实际只生成 100 个 token那 8K 的显存也得先占着。PagedAttention 把 KV Cache 切成固定大小的 block默认 16 个 token 一块用 block table 做逻辑到物理的映射按需分配。实测下来同样的显存vLLM 能同时服务的请求数通常是朴素实现的 3 到 5 倍这个提升在长上下文场景下更明显。vLLM 新版本的架构做了比较大的重构核心是EngineCore这个概念。老版本里LLMEngine一把抓调度、执行、输出处理都在一起。新版本拆成了几层最上层是AsyncLLMEngine或LLMEngine作为对外接口中间是EngineCore负责核心的调度循环再往下是Scheduler和Executor。这个拆分不是纯粹为了好看而是为了支持多进程和异步。EngineCore可以跑在独立进程里通过 ZMQ 和前端通信这样前端处理 HTTP 请求的进程就不会被调度循环阻塞。具体到交互流程我按我理解的顺序捋一遍。请求从 OpenAI 兼容的 API server 进来经过 tokenize 之后变成一个Request对象塞进EngineCore的输入队列。EngineCore的主循环每一步做三件事先让Scheduler决定这一步要跑哪些请求、每个请求分配多少 block然后把调度结果交给ExecutorExecutor在 GPU 上执行模型前向产出每个请求的新 token最后把结果收集回来更新每个请求的状态完成的请求移出新 token 通过输出队列回传给前端。这个循环是持续跑的只要队列里有活就转。Scheduler的逻辑是 vLLM 里最值得细看的部分。它维护三个队列waiting等待调度的新请求、running正在跑的请求、swapped被换出到 CPU 的请求。每一步调度时它先看 running 队列里的请求能不能继续跑显存够不够分配新的 block能跑就优先跑因为已经跑了一半的请求中断了代价大。然后从 waiting 队列里按 FCFS 取新请求尝试分配 block。如果显存不够它会触发preemption把某些 running 请求换出swap 到 CPU或者直接重算recompute。这里有个关键参数max_num_seqs控制单步最多跑多少个序列设太小 GPU 吃不饱设太大容易 OOM需要根据模型大小和卡的内存调。2.2 SGLangRadixAttention 与结构化生成SGLang 的定位和 vLLM 有重叠但它的差异化在于RadixAttention和结构化生成。RadixAttention 的核心思想是用基数树radix tree来管理 KV Cache 的前缀共享。这个在多轮对话和 few-shot 场景下威力很大比如你有一个固定的 system prompt所有请求都带这段前缀RadixAttention 会让这些请求共享同一份 KV Cache不用每个请求都重新算一遍。vLLM 的 PagedAttention 也能做前缀共享但 SGLang 的 radix tree 在复杂前缀匹配上更灵活尤其是前缀有分支的情况。SGLang 另一个杀手锏是它的前端 DSL。你可以用类似 Python 的语法描述一个生成流程比如“先让模型输出 JSON 的 key再根据 key 决定后面生成什么”SGLang 的运行时能对这种结构化生成做优化减少不必要的解码。这个在 Agent 和工具调用场景下特别有用因为那些场景的生成往往有很强的结构约束。SGLang 和 vLLM 怎么选我的经验是如果你的场景是标准的“输入 prompt 输出文本”两者差距不大vLLM 生态更成熟、文档更全。如果你的场景有大量前缀共享多轮对话、固定 system prompt或者需要结构化约束生成SGLang 往往能快出一截。另外 SGLang 在某些模型上的 kernel 实现更激进比如它对 DeepSeek 系列的支持在早期比 vLLM 更早适配。2.3 TensorRT-LLM极致性能与编译代价TensorRT-LLM 是 NVIDIA 官方出的走的是“编译优化”路线。它会把你的模型编译成一个 TensorRT engine这个过程会做大量的图优化、算子融合、kernel 自动调优。编译一次可能要几十分钟甚至更久但编译出来的 engine 在 NVIDIA 卡上的性能通常是三者里最好的尤其是在 FP8、INT4 量化场景下。代价是灵活性差。模型结构变了要重新编译换卡要重新编译甚至换 TensorRT 版本都可能要重编。而且它对模型的支持不如 vLLM 广新模型出来往往要等官方适配。所以 TensorRT-LLM 适合那种模型固定、追求极致吞吐、有专门团队维护的场景比如大厂的在线服务。个人开发者和小团队用 vLLM 或 SGLang 的性价比更高。2.4 llama.cpp端侧与 CPU 场景的王者llama.cpp 和前三个不是一个路数。它用纯 C/C 实现支持 CPU、CUDA、Metal、Vulkan 等多种后端核心优势是量化和低资源占用。GGUF 格式就是它推起来的4-bit 量化后一个 7B 模型只要 4GB 左右内存能在普通笔记本甚至手机上跑。Android 版 llama.cpp 已经比较成熟配合 Termux 或者专门的 App 可以本地跑小模型。llama.cpp 的吞吐没法跟 vLLM 比它本来也不是为高并发设计的。但它的价值在于“哪里都能跑”。你做端侧应用、离线推理、隐私敏感场景llama.cpp 是首选。它的llama-server也提供了 OpenAI 兼容接口小规模自用完全够。引擎核心优势适用场景主要短板vLLMPagedAttention、生态成熟、易部署在线服务、通用场景极致性能略逊 TRT-LLMSGLangRadixAttention、结构化生成多轮对话、Agent、约束生成生态和文档相对少TensorRT-LLM极致性能、量化支持好模型固定的大规模服务编译慢、灵活性差llama.cpp端侧、CPU、量化本地、离线、移动端并发能力弱3. 核心机制拆解调度、显存与执行3.1 Scheduler 的抢占逻辑与参数调优vLLM 的 scheduler 抢占逻辑是我调试时花时间最多的地方。它的基本规则是running 队列里的请求优先显存不够时触发抢占。抢占有两种模式swap和recompute。swap是把被抢占请求的 KV Cache 从 GPU 拷到 CPU 内存等显存够了再拷回来recompute是直接丢掉 KV Cache等重新调度时把之前的 token 重新算一遍。swap省算力但费 PCIe 带宽recompute省显存但费算力。默认策略会根据情况选你可以通过--preemption-mode强制指定。这里有个很隐蔽的坑如果你的请求长度差异极大比如有的请求只要生成 10 个 token有的要生成 4000 个长请求很容易被反复抢占导致它的实际延迟爆炸。我遇到过一次一个长文档摘要请求在混合负载下跑了 3 分钟还没完查日志发现被抢占了十几次。解决办法是调大gpu_memory_utilization默认 0.9可以试 0.92 到 0.95但别太满要留空间给激活值或者用--max-num-seqs限制并发数给长请求留出空间。更精细的做法是用--scheduling-policy切换策略不过 vLLM 目前主要就是 FCFS公平性调度还在演进。max_num_batched_tokens这个参数也值得说。它控制单步最多处理多少个 token包括 prefill 和 decode。设大一点prefill 阶段吞吐高但 decode 阶段的延迟可能变大设小一点延迟低但吞吐下降。默认值通常是 2048 或 4096我一般会根据 SLA 调延迟敏感就调小到 1024 到 2048吞吐优先就调到 8192 甚至更高。这个参数和max_num_seqs要配合调两个都大容易 OOM。3.2 KV Cache 显存计算与 block 管理要调好 vLLM你得会算 KV Cache 的显存。公式不复杂每个 token 的 KV Cache 大小 2 × num_layers × num_kv_heads × head_dim × dtype_bytes。注意是num_kv_heads不是num_attention_heads因为 GQA分组查询注意力模型里 KV head 数比 Q head 少很多。以 Qwen3-0.6B 为例假设 28 层、8 个 KV head、head_dim 128、FP162 字节那每个 token 的 KV 是2 × 28 × 8 × 128 × 2 114688字节约 112KB。一个 8K 上下文的请求就要 896MB这还只是一个请求。vLLM 启动时会先加载模型权重然后根据gpu_memory_utilization算出可用于 KV Cache 的显存再除以每个 block 的大小block_size × 每 token KV得到总 block 数。你可以在启动日志里看到# GPU blocks: XXXX这行这个数字直接决定了你能同时跑多少请求。如果这个数字很小比如只有几百那说明显存被权重占太多了要么换更小的模型要么用量化要么加卡。block_size默认 16可以设成 8、32、64。设小了 block table 开销大设大了内部碎片多。一般 16 是平衡点除非你有特殊需求否则别动。有个细节block_size 影响 PagedAttention kernel 的效率某些卡上 32 可能比 16 快这个要实测。3.3 Executor 与多卡并行Executor是真正干活的层。单卡就是GPUExecutor多卡有RayGPUExecutor和MultiprocessingGPUExecutor。多卡并行走的是张量并行TP或流水线并行PP。TP 是把每一层的权重切到多张卡上每层计算时卡间要 all-reduce 通信PP 是把不同层放到不同卡上像流水线一样传。TP 通信量大但延迟低PP 通信量小但有流水线气泡。一般单机多卡用 TP跨机用 PP 或者 TPPP 混合。TP 的度数要和注意力头数匹配。比如模型有 32 个 attention head你 TP4那每张卡分 8 个 head没问题。但如果模型只有 8 个 head你 TP16那就分不了了vLLM 会报错。所以选 TP 度数前先看模型的 head 数。另外 TP 会带来通信开销TP2 通常有加速TP4 可能加速比就不到 2 了TP8 有时候反而更慢因为通信成了瓶颈。这个要实测别盲目加卡。4. 实操部署从 Docker 到生产环境4.1 Docker 镜像选择与模型加载vLLM 官方提供了vllm/vllm-openai镜像这是最省事的部署方式。但这里有个新手最容易困惑的问题镜像里带模型吗答案是默认不带。镜像里只有 vLLM 的代码和依赖模型要你自己挂载或者让它运行时下载。所以启动命令里通常要挂载一个模型目录或者设置HF_HOME让它从 HuggingFace 拉。以部署 Qwen3-Embedding-0.6B 为例假设你用vllm/vllm-openai:v0.27.1这个镜像版本号按你实际用的填命令大概是这样docker run --gpus all \ -v /data/models:/models \ -p 8000:8000 \ --shm-size 16g \ vllm/vllm-openai:v0.27.1 \ --model /models/Qwen3-Embedding-0.6B \ --served-model-name qwen3-embedding \ --task embed \ --max-model-len 8192 \ --gpu-memory-utilization 0.9几个点要注意。--shm-size一定要给够vLLM 多进程通信用共享内存默认 64MB 会直接崩我一般给 16g。--task embed是 embedding 模型专用的普通生成模型不用加。--served-model-name决定 API 里model字段填什么不设的话默认是模型路径很长很难用。如果是部署 DeepSeek 这种大模型模型文件可能上百 GB从 HuggingFace 拉很慢建议提前用huggingface-cli download下到本地再挂载。另外 DeepSeek 系列有些是 MoE 结构vLLM 对 MoE 的支持在较新版本才完善老版本可能跑不起来或者性能很差选镜像时要注意版本。4.2 关键启动参数与调优启动参数里除了前面说的gpu_memory_utilization、max_num_seqs、max_num_batched_tokens还有几个必调的。--dtype控制权重和计算的精度。默认auto会根据模型配置选。如果你的卡支持 BF16模型也是 BF16那就用 BF16。如果显存紧张可以用--quantization做量化vLLM 支持 AWQ、GPTQ、FP8 等。FP8 在 H100 这类卡上效果好老卡不支持。--tensor-parallel-size就是 TP 度数前面说过要和 head 数匹配。--enable-prefix-caching开启前缀缓存多轮对话场景必开能显著降低重复前缀的计算。但注意它和某些量化方式可能冲突开了之后如果报错就先关掉排查。--max-model-len是最大上下文长度。这个值直接影响 KV Cache 的 block 分配上限设太大浪费显存设太小长请求会被截断。要按你的实际业务设别直接抄模型的max_position_embeddings。--swap-space是 CPU swap 空间大小默认 4GB。如果你的请求长度差异大、抢占频繁可以调大到 16GB 或 32GB但前提是机器内存够。4.3 客户端接入与 Chatbox 配置服务起来之后验证最简单的方式是 curlcurl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3-embedding, messages: [{role: user, content: 你好}] }如果用 Chatbox 这类客户端配置里选 OpenAI 兼容Base URL 填http://你的IP:8000/v1API Key 随便填一个非空字符串vLLM 默认不校验模型名填--served-model-name设的那个。连不上先检查端口有没有映射对、防火墙有没有放行、--host是不是0.0.0.0默认就是。4.4 Windows 与 Android 场景vLLM 官方不支持 Windows 原生Windows 上要么用 WSL2要么用 Docker Desktop。WSL2 里跑 vLLM 是可以的但要注意 WSL 的内存限制默认可能只给一半物理内存要在.wslconfig里调。Docker Desktop 走 WSL2 后端GPU 直通需要装好驱动和 CUDA on WSL。llama.cpp 的 Android 版是另一条路。你需要交叉编译或者用预编译的二进制把 GGUF 模型推到手机存储然后用llama-server起服务。手机内存有限7B 的 Q4 量化模型大概占 4GB中高端机跑得动但速度也就每秒几个 token。适合做离线小助手别指望高并发。5. 常见问题与排查实录5.1 启动就 OOM 怎么办这是最高频的问题。排查顺序先看模型权重占了多少再看 KV Cache 能分多少。启动日志里会打印模型加载后的显存占用和可用 block 数。如果 block 数是个位数或者零说明权重就快把显存占满了。解决办法按优先级换更小的模型、用量化版本AWQ/GPTQ、降低gpu_memory_utilization反而可能更糟因为留给 KV 的更少正确做法是降max_model_len和max_num_seqs或者加卡。有个反直觉的点gpu_memory_utilization调高不一定好。它控制 vLLM 预留给 KV Cache 的比例但激活值、CUDA Graph 捕获也要显存。设成 0.95 有时候会在跑起来之后 OOM因为运行时还有额外开销。我一般从 0.85 开始试稳定了再往上加。5.2 新版本性能下降的排查vLLM 版本迭代快偶尔会出现“升级后反而变慢”的情况。我遇到过一次从某个版本升上去之后吞吐掉了 30%。排查思路先确认是不是默认参数变了新版可能改了max_num_batched_tokens的默认值或者调度策略。然后看是不是 CUDA Graph 没生效日志里搜capture相关。再就是看是不是新版本对某个 kernel 的实现变了这个只能对比 benchmark。应对策略是生产环境别追最新版用经过验证的稳定版。升级前先在测试环境跑 benchmark对比吞吐和延迟。如果确实新版有问题回退到旧版等社区修。GLM、MiniMax 这类模型用哪个 vLLM 版本最好查官方文档或者社区 issue别自己瞎试。5.3 请求卡住或延迟异常请求卡住通常是调度问题。先看日志里有没有反复的 preemption 记录如果有说明显存紧张导致请求被反复换出。调大gpu_memory_utilization或者降并发。如果日志里没有 preemption 但请求就是不动可能是max_num_seqs设太小请求在 waiting 队列里排不上。还有一种可能是某个请求的 prompt 特别长prefill 阶段占满了max_num_batched_tokens导致其他请求的 decode 被饿死。这种情况要开 chunked prefill--enable-chunked-prefill把长 prefill 切成小块和 decode 交替跑。5.4 常见问题速查表现象可能原因排查动作解决方向启动 OOM权重KV 超显存看 block 数日志量化/降 max_model_len/加卡吞吐低batch 太小看 GPU 利用率调大 max_num_seqs延迟高抢占频繁搜 preemption 日志调大显存利用率/降并发请求卡住长 prefill 饿死 decode看请求长度分布开 chunked prefill升级变慢默认参数或 kernel 变化对比 benchmark回退版本多卡不加速TP 通信瓶颈看卡间通信降 TP 度数或换 PP5.5 几个我踩过的坑第一个坑是--shm-size。我第一次用 Docker 部署没设这个服务起来跑几个请求就崩报共享内存相关的错。查了半天才反应过来是 Docker 默认 shm 太小。这个坑很隐蔽因为单请求测试可能不崩一上并发就挂。第二个坑是模型路径权限。挂载的模型目录如果权限不对容器里读不了报错信息还不直观。建议挂载前chmod -R 755一下。第三个坑是 embedding 模型和生成模型混用。vLLM 一个实例只能跑一种任务类型你不能在同一个服务里既做 embedding 又做生成。要分开起两个实例端口错开。第四个坑是max_model_len设太大。我一开始图省事直接设成模型的最大值结果 block 数少得可怜并发上不去。后来按实际业务最长请求设并发直接翻倍。这个参数不是越大越好是按需设。6. 一些实战体会推理引擎这个领域文档和实际行为之间总有 gap。我现在的习惯是任何参数调整都先在小流量上验证看日志里的 block 数、preemption 次数、GPU 利用率这几个指标再决定要不要推到生产。benchmark 工具推荐用 vLLM 自带的benchmarks/benchmark_serving.py能模拟真实请求分布比单纯压测有意义。选型上我的默认建议是通用场景 vLLM 起步遇到前缀共享或结构化生成再考虑 SGLang追求极致性能且有维护能力上 TensorRT-LLM端侧和离线用 llama.cpp。别一上来就追求“最强”先把业务跑通再根据瓶颈优化。大部分场景下把max_num_seqs、max_num_batched_tokens、gpu_memory_utilization这三个参数调明白性能就能提升一大截比换引擎的收益还大。最后分享一个小技巧vLLM 的日志级别用--disable-log-requests可以关掉每个请求的详细日志高并发下这个日志本身就很耗性能。但排查问题时记得打开不然你看不到 preemption 和调度细节。这个开关我一般是在稳定运行后关掉出问题再开。