副标题2026 年的 LLM 推理引擎格局已经清晰——vLLM 是生产部署的事实标准SGLang 在 Agent 和结构化输出场景独占鳌头TensorRT-LLM 是 NVIDIA 硬件上的性能天花板。本文从架构哲学、调度策略、KV Cache 管理、编译优化到实测性能做一次三强全面对比。一、引子三个引擎三套哲学先说结论、再讲细节。2026 年的推理引擎图谱三者的定位早已分道扬镳vLLMSGLangTensorRT-LLM出身UC Berkeley (2023)Stanford (2024)NVIDIA (2023)核心理念调度引擎语言调度引擎编译引擎优化重心KV Cache 管理 调度KV Cache 管理 结构化输出GPU Kernel 编译 融合模型兼容最广HuggingFace 90%很广vLLM 基础上扩展有限主流架构 手动适配部署复杂度低中高性能上限高很高最高注意如果你还没读过本系列的 第 17 篇建议先回去看——那篇深入拆解了 PagedAttention、Continuous Batching 和 RadixAttention 的底层原理。本篇是它的续篇在理解原理的基础上看三个引擎如何把这些技术落地以及在实战中怎么选。二、架构哲学三条完全不同的路线三个引擎的差距根源在它们对推理引擎该做什么的定义完全不同。2.1 vLLM调度优先的通用引擎vLLM 的定位是“GPU 上的操作系统调度器”——核心工作是管理好显存、排好批次、调度好请求。它不强求极致性能但追求开箱即用HuggingFace 上下载的模型90% 以上加载就能跑生态兼容OpenAI API 格式、LoRA 热切换、多模型并行硬件广泛NVIDIA、AMD、Intel、AWS Trainium、Google TPU 都支持vLLM 的架构决策是把调度做到极致计算交给别人的 kernel——它用 PagedAttention Continuous Batching 最大化 GPU 利用率但 attention 计算本身用的是 FlashAttention 或别人的 kernel。这层调度和计算分离的设计让它适配性极强但也意味着在特定硬件上跑不出 NVIDIA 原生的极致性能。2.2 SGLang语言是一等公民SGLang 的出发点是“推理引擎不应该只调度张量它应该理解程序的意图。”SGLang 引入了一套前端 DSL领域特定语言让你可以用声明式的方式描述 “我要先做 prompt A、然后调 tool B、再用结果约束生成格式 C”。引擎收到这个程序后可以分析哪个前缀可以被缓存自动插入结构化约束解码跨请求优化调度顺序这个设计决策的后果是SGLang 在三个引擎中最重——它不仅管调度还管语言解析、约束执行和推理优化。但也是这个重让它在 Agent、多轮对话、RAG 场景下能比 vLLM 快 3-5 倍。SGLang 在调度层继承了 vLLM 的大部分设计PagedAttention、Continuous Batching但在 KV Cache 管理上改用RadixAttention第 17 篇详述在多轮对话/Agent 场景有质的优势。2.3 TensorRT-LLM编译器路线把 GPU 榨干TensorRT-LLM简称 TRT-LLM的定位完全不同——它是一套编译器。你把模型定义和配置扔进去它花 15-30 分钟编译出一个高度优化的 GPU 可执行程序然后上线运行。编译路线的好处算子融合多个小 kernel 合并成一个大 kernel减少 kernel launch 开销内存规划提前算好每层的显存分配运行时零动态分配量化原生FP8/INT4 直接在 Tensor Core 上算不需要反量化自动调优对当前硬件做 auto-tuning选最快的 kernel 实现代价是换模型、换 GPU、改精度——都要重新编译调试困难编译出来的不是人能看懂的代码只支持 NVIDIA GPU三者路线对比vLLM: 调度层极致优化← 计算层借别人的 kernel SGLang: 语言层前端 DSL→ 调度层RadixAttention→ 计算层 TRT-LLM: 编译层全链路融合→ 运行时几乎无调度开销三、调度与批处理Continuous Batching 的三副面孔第 17 篇讲过 Continuous Batching 的核心思想——每步 token 后重新组批长 prompt 切碎混排。但三个引擎在具体怎么排上有不小差异。3.1 vLLM最成熟的调度器vLLM 的调度器三层结构等待队列 ─→ 调度策略 ─→ 当前运行集 ─→ 模型前向 │ └→ 抢占策略recompute / swap调度策略要点Decode 优先所有正在生成 token 的请求优先调度Chunked Prefill 填空用剩余的 token 预算调度 prefill chunk配额控制max_num_seqs最大并发请求数和max_num_batched_tokens每步最大 token 数双重限制抢占策略显存不够时默认recompute丢弃 KV Cache后续重新 prefill可选swapKV Cache 换出到 CPU 内存vLLM 的调度器经过两年生产验证在各种极端场景下都有不错的鲁棒性。3.2 SGLang更激进的调度SGLang 在调度层做了几个关键改进更小的调度粒度vLLM 以请求为单位调度SGLang 以token 为单位调度配合 RadixAttention 的 page_size1SGLang 可以精确到每个 token 的调度优先级Prefill 和 Decode 分离Disaggregated Prefill解耦后prefill 节点专注 compute-heavy 的前向decode 节点做 memory-bound 的自回归不同节点可以有不同的 batch 策略和硬件配置前瞻调度Lookahead SchedulingSGLang 在调度当前步时预读下一步的请求队列如果发现后续请求与当前请求共享前缀可以提前合并调度3.3 TensorRT-LLM最底层的调度TRT-LLM 的调度叫In-Flight BatchingIFB——和 Continuous Batching 本质相同但实现更底层。关键差异 1调度在内核里vLLM 和 SGLang 的调度器在 Python 层TRT-LLM 的调度器在 C runtime 层深度嵌入到 CUDA stream 管理中。这意味着调度决策可以和 kernel 执行 pipeline 在一起。关键差异 2两个关键参数max_batch_size最大并发请求数max_num_tokens每步最大 token 数这两个参数决定了 TRT-LLM 的资源预算。配大了浪费显存配小了限制吞吐。生产调优的核心工作就是做这两者的 grid search。关键差异 3三种调度策略策略行为适用场景GUARANTEED_NO_EVICT默认请求一旦开始绝不驱逐延迟敏感在线服务MAX_UTILIZATION尽可能多的请求可能驱赶吞吐优先批处理STATIC_BATCH传统静态批处理不推荐生产使用双参数调优实测效果Llama 3.3 70B4×H100max_batch_size 64 → 1944 tok/s (baseline) max_batch_size 512 → 2467 tok/s (27%) max_num_tokens 2048 → 2474 tok/s 组合调优 → 3074 tok/s58% 总提升三引擎调度对比一览特性vLLMSGLangTensorRT-LLM调度实现层PythonPythonC Runtime调度粒度请求级Token 级请求级 kernel 级Prefill/Decode 分离❌计划中✅ 原生支持✅Disagg 模式长 prompt 切分Chunked PrefillChunked PrefillChunked Context抢占策略Recompute / SwapRecomputeEvict / Guarantee调优复杂度低中高需 grid search四、KV Cache 管理从原理到实践第 17 篇深入解释了 PagedAttention 和 RadixAttention 的原理。这里只聚焦三引擎在工程实现上的关键差异。4.1 前缀缓存机制的对比vLLMSGLangTensorRT-LLM机制哈希表 Block 级Radix Tree Token 级Block 级block_reuse匹配精度16-token Block逐 tokenBlock 级淘汰策略平坦 LRU树感知 LRU先删叶子优先级驱动多轮对话优势1xbaseline3-5x~1.2x有限复用一个典型 RAG 场景的数据100 并发60% 文档重叠无缓存: 225K token/批的 prefill vLLM APC: 125K token/批优化 -44% SGLang: 65K token/批优化 -71% TRT-LLM: 120K token/批block_reuse 开启后的近似值SGLang 的 RadixAttention 在高并发共享前缀场景下优势明显而且差距随着前缀长度增加而扩大。4.2 TensorRT-LLM 的 Paged KV CacheTRT-LLM 也支持 Paged KV Cache有两个重要参数{kv_cache_config:{free_gpu_memory_fraction:0.85,enable_block_reuse:true}}enable_block_reuse开启后TRT-LLM 会缓存共享前缀的 Block。但和 SGLang 的 Radix Tree 不同TRT-LLM 的复用是 Block 级的只能在 16-token 边界上匹配精细度不如 SGLang。五、编译优化TensorRT-LLM 的杀手锏这是三个引擎最大的性能差距来源。5.1 TensorRT-LLM 的编译流程TRT-LLM 部署一个模型需要经过模型权重 配置 ↓ 图构建build graph将 PyTorch/FasterTransformer 模型转成 TRT-LLM 内部 IR ↓ 图优化graph optimization算子融合、死代码消除、常量折叠 ↓ 自动调优auto-tuning对每个 fused kernel 搜索最优配置block size, grid size... ↓ 内存规划memory planning提前分配所有 tensor 的物理地址 ↓ 序列化serialization生成 .engine 文件部署时加载编译完成后推理时的调度开销基本归零——所有资源分配在编译期就确定了。典型编译时长模型GPU编译时间Llama 2 7BH1005-10 minLlama 3 70BH10015-25 minMixtral 8x7BH10020-35 min5.2 vLLM 和 SGLang 的编译策略vLLM 和 SGLang 不做 AOTahead-of-time编译。它们采用折中方案CUDA Graph 捕获在推理启动前对固定 batch size 的模型前向做一次 CUDA Graph capture将多次 kernel launch 打包成一个 graph减少 CPU→GPU 通信开销问题只在固定 batch size下有效batch 变化需要重新 capture无 CUDA Graph: 每次迭代 N 次 kernel launch每个算子一次 有 CUDA Graph: 每次迭代 1 次 graph launchgraph 内部包含所有 kernelFlashAttention / PagedAttention kernel这些 kernel 本身是高优化的手动实现但每个 kernel 之间仍是独立的——缺少 TRT-LLM 的跨算子融合vLLM/SGLang 的 CUDA Graph 策略预设一批 batch size如 1, 2, 4, 8, 16, 32…每次推理前选最接近的已捕获 graph多出的 token 做 paddingSGLang 0.6 引入了 FlashInfer 作为 unified kernel backend让 attention 的 kernel 融合度更高。5.3 这个差距实际有多大一个典型的 decode 迭代vLLM/SGLang: Layer 0: launch RMSNorm → launch Attention → launch Add → launch FFN → ... Layer 1: launch RMSNorm → launch Attention → launch Add → launch FFN → ... ... 32-80 层 → 每次迭代约 100-200 次 kernel launch TensorRT-LLM (编译后): 每次迭代 → 1-2 次 fused kernel launch合并了相邻的小算子 → CPU 调度开销接近于零在 batch size 较小时1-16kernel launch 开销占比显著此时 TRT-LLM 的融合优势最明显。随着 batch 增大计算本身成为瓶颈融合收益相对降低。六、量化FP8/INT4 的原生计算 vs 后量化这是一个经常被低估的差异点。6.1 TensorRT-LLM量化就是计算精度TRT-LLM 在做编译时会为量化精度专门生成计算 kernelFP16 engine: 用 FP16 Tensor Core 计算 FP8 engine: 用 FP8 Tensor Core 计算H100 原生支持 INT4 engine: 用 INT4 Tensor Core 计算Blackwell 原生支持 INT8 engine: 用 INT8 Tensor Core 计算所有架构都支持这意味着TRT-LLM 跑 FP8 时计算和存储都在 FP8不需要反量化。H100 的 FP8 Tensor Core 算力是 FP16 的 2 倍这是实打实的吞吐翻倍。6.2 vLLM 和 SGLang量化主要是省显存vLLM 和 SGLang 的量化实现主要来自AWQ / GPTQ等权重量化方案存储 FP16 权重 → INT4 权重4x 压缩 计算时 INT4 → 反量化 → FP16 → FP16 matmul省了显存但计算时先反量化再计算——INT4 的算力优势没有直接转化为速度优势因为计算还是 FP16 的。你省的是 HBM 带宽少读了 4x 的权重不是计算 FLOPs。vLLM/SGLang 量化流程 从 HBM 读 INT4 权重 → 反量化为 FP16 → 在 FP16 Tensor Core 上计算 TRT-LLM FP8 流程 从 HBM 读 FP8 权重 → 直接在 FP8 Tensor Core 上计算 → 省带宽 省计算H100 FP8 TFLOPs 2× FP16 TFLOPs6.3 实际影响场景vLLM AWQTRT-LLM FP8差距DeepSeek V4-Flash 284B (4×H100)1,850 tok/s2,312 tok/s25%显存占用同同FP8 也是 1 byte/param—精度损失极小AWQ 校准1%—TRT-LLM 的 FP8 同时省带宽和省算力而 AWQ 只省带宽。这就是为什么 TRT-LLM 在支持 FP8 的硬件上总是最快的。七、性能基准对比一张表看清差距7.1 小模型单卡测试H100Qwen2.5-7BFP8/BF16输入 512 tokens输出 256 tokens并发vLLMSGLangTRT-LLM1611,200 tok/s12,800tok/s (14%)14,500tok/s (29%)6418,400 tok/s21,600tok/s (17%)23,800tok/s (29%)12822,100 tok/s27,300tok/s (23%)26,500 tok/s (20%)P99 延迟并发vLLMSGLangTRT-LLM16680 ms620 ms540 ms641,240 ms980 ms860 ms1282,800 ms1,900 ms2,100 ms分析中低并发16-64TRT-LLM 的编译优化和 FP8 原生计算带来稳定的吞吐优势高并发128SGLang 的 RadixAttention 前缀复用效果显著吞吐反超 TRT-LLMP99 延迟最优7.2 大模型多卡测试DeepSeek V4-Flash 284B MoE4×H100FP8引擎吞吐 (tok/s)TTFT (ms)TPOT (ms)P99 延迟TRT-LLM FP82,3128918210 msSGLang FP82,1509222195 msvLLM AWQ1,85010525240 msTRT-LLM 的 FP8 优势在 MoE 模型上同样明显而 SGLang 在尾延迟控制上更好RadixAttention 减少调度抖动。7.3 RTX 4090 单卡测试Qwen2.5-1.5B指标TRT-LLMSGLangvLLMTTFT 均值224.0 ms179.2 ms531.1 msTTFT 最小值223.5 ms38.6 ms缓存命中506.3 msTTFT 最大值227.7 ms480.6 ms缓存未命中555.1 ms抖动范围4 ms441 ms49 ms这个测试揭示了三个引擎的极端差异TRT-LLM延迟最低且最稳定抖动仅 4ms适合延迟敏感场景SGLang缓存命中时极快38.6ms缓存未命中时波动大vLLM延迟最高但胜在稳定性和兼容性八、部署运维实战8.1 部署复杂度vLLM最简单: pip install vllm vllm serve meta-llama/Llama-3.1-8B --port 8000 → 5 分钟内启动 SGLang也简单: pip install sglang python -m sglang.launch_server --model meta-llama/Llama-3.1-8B → 5 分钟内启动 TRT-LLM最复杂: # 1. 拉 Docker 镜像 docker pull nvidia/cuda:12.8-devel # 2. 安装 TRT-LLM pip install tensorrt_llm # 3. 将 HuggingFace 模型转成 TRT-LLM 格式 python examples/llama/convert_checkpoint.py --model_dir ... --output_dir ... # 4. 编译 engine trtllm-build --checkpoint_dir ... --output_dir ... --model_config config.json # 5. 启动服务 python examples/run.py --engine_dir ... → 首次部署 30-60 分钟8.2 模型变更成本场景vLLMSGLangTRT-LLM换模型权重重启即换重启即换重新编译15-30 min换精度FP16→FP8换权重即可换权重即可重新编译换 GPU 架构不需要改不需要改重新编译加 LoRA adapter运行时热切换 ✅运行时热切换 ✅需要重新编译 ❌这是 TRT-LLM 最大的痛点编译后一切都被固定了。如果你有三套模型要部署就得编三次。如果每个模型还要跑 FP16 和 FP8 两种精度编译次数×2。8.3 硬件支持矩阵硬件vLLMSGLangTRT-LLMNVIDIA H100/B200/RTX✅ 最佳✅ 最佳✅独占必须 NVIDIAAMD MI300X✅ 社区支持❌ 有限❌Intel Gaudi 3✅ 社区支持❌❌Google TPU✅ 实验性❌❌华为昇腾 910B⚠️ 第三方移植❌❌Apple SiliconMPS⚠️ 实验性❌❌vLLM 在硬件兼容性上有明显优势——社区驱动的 ROCm、Intel XPU、TPU 后端持续在完善。九、选型决策框架9.1 一张速查表你的需求首选备选原因快速上线、原型验证vLLMSGLang部署最简单兼容性最好Agent / 多轮对话SGLangvLLMRadixAttention 多轮 3-5×结构化输出JSONSGLangvLLM Guidance原生约束解码极致吞吐、8×H200TRT-LLMSGLangFP8 原生计算 10-30% 领先低延迟对话类TRT-LLMSGLang编译融合无调度抖动LoRA 多适配器切换vLLMSGLang原生支持运行时热切换国产 GPU 部署vLLM—唯一有社区移植的引擎模型频繁换 / A/B 测试vLLMSGLang重启即换不用等编译混合模型服务vLLMSGLang多模型并行最成熟9.2 务实路径从 vLLM 起步用 SGLang 补齐 Agent大多数团队的进化路线第一阶段vLLM - 快速上线第一版 API - 用 AWQ/GPTQ 量化降低显存需求 - 确认推理成为瓶颈后进入下一阶段 第二阶段vLLM SGLang 混用 - 简单场景单轮生成、批量推理继续用 vLLM - Agent 场景、高并发前缀共享场景切换到 SGLang - 两个引擎可以跑在同一套 GPU 集群上 第三阶段可选引入 TRT-LLM - 当性能需求超过 vLLM/SGLang 能提供的 - 且模型固定不再频繁迭代 - 重点场景只部署在 NVIDIA 最新硬件上 - vLLM/SGLang 仍作为灵活性兜底9.3 一个决定性的问题在你纠结选哪个引擎之前先回答这个问题你的模型明年还长这样吗如果答案是否定的 →选 vLLM。灵活性比那 20-30% 的性能提升值钱得多。如果你在做一个 Agent 平台对话流程非常复杂 →选 SGLang。RadixAttention 结构化输出是别家没有的硬核优势。如果你在做一个长期稳定的 SaaS模型固定不变NVIDIA 硬件专享 →可以考虑 TRT-LLM但要算清楚编译维护成本。十、总结核心数据回顾维度vLLMSGLangTensorRT-LLM通用吞吐7B, H100, 64并发18.4K tok/s21.6K tok/s (17%)23.8K(29%)大模型吞吐284B MoE, 4×H1001.85K tok/s2.15K tok/s2.31Ktok/s高并发 P99 延迟128并发2,800 ms1,900 ms2,100 ms延迟抖动4090, TTFT49 ms441 ms4 msAgent/多轮/结构化一般最佳不支持部署到上线5 min5 min30-60 min模型变更成本重启重启重新编译硬件兼容最广NVIDIA 为主仅 NVIDIA给读者的建议不要为了 20% 的性能提升选一个你最不熟悉的框架。vLLM 和 SGLang 之间的差距大部分场景在 15-25% 之间往往小于你调优提示词、优化 batch 策略、选择合适的量化方式带来的收益。三引擎的格局和它们的定位非常吻合vLLM 是够用灵活——适合大多数人和大多数场景。SGLang 是场景特化——如果你正好在它擅长的领域Agent/结构化/多轮它能给你别处拿不到的收益。TRT-LLM 是性能天花板——但它有价格灵活性、兼容性、运维便利性。先看清自己的需求再选引擎。如果看不清楚从 vLLM 开始总是对的。附录进一步阅读LLM 推理引擎架构——vLLM / SGLang 的核心设计vLLM 论文 (SOSP 2023)SGLang 论文 (NeurIPS 2024)TensorRT-LLM 官方文档EVAL #001: LLM Inference Engine Showdown — vLLM vs TGI vs TRT-LLM vs SGLangThe Best LLM Inference Engines in 2026TRT-LLM vs vLLM vs SGLang: What to Choose in 2026
LLM 推理引擎三强争霸——vLLM vs SGLang vs TensorRT-LLM
副标题2026 年的 LLM 推理引擎格局已经清晰——vLLM 是生产部署的事实标准SGLang 在 Agent 和结构化输出场景独占鳌头TensorRT-LLM 是 NVIDIA 硬件上的性能天花板。本文从架构哲学、调度策略、KV Cache 管理、编译优化到实测性能做一次三强全面对比。一、引子三个引擎三套哲学先说结论、再讲细节。2026 年的推理引擎图谱三者的定位早已分道扬镳vLLMSGLangTensorRT-LLM出身UC Berkeley (2023)Stanford (2024)NVIDIA (2023)核心理念调度引擎语言调度引擎编译引擎优化重心KV Cache 管理 调度KV Cache 管理 结构化输出GPU Kernel 编译 融合模型兼容最广HuggingFace 90%很广vLLM 基础上扩展有限主流架构 手动适配部署复杂度低中高性能上限高很高最高注意如果你还没读过本系列的 第 17 篇建议先回去看——那篇深入拆解了 PagedAttention、Continuous Batching 和 RadixAttention 的底层原理。本篇是它的续篇在理解原理的基础上看三个引擎如何把这些技术落地以及在实战中怎么选。二、架构哲学三条完全不同的路线三个引擎的差距根源在它们对推理引擎该做什么的定义完全不同。2.1 vLLM调度优先的通用引擎vLLM 的定位是“GPU 上的操作系统调度器”——核心工作是管理好显存、排好批次、调度好请求。它不强求极致性能但追求开箱即用HuggingFace 上下载的模型90% 以上加载就能跑生态兼容OpenAI API 格式、LoRA 热切换、多模型并行硬件广泛NVIDIA、AMD、Intel、AWS Trainium、Google TPU 都支持vLLM 的架构决策是把调度做到极致计算交给别人的 kernel——它用 PagedAttention Continuous Batching 最大化 GPU 利用率但 attention 计算本身用的是 FlashAttention 或别人的 kernel。这层调度和计算分离的设计让它适配性极强但也意味着在特定硬件上跑不出 NVIDIA 原生的极致性能。2.2 SGLang语言是一等公民SGLang 的出发点是“推理引擎不应该只调度张量它应该理解程序的意图。”SGLang 引入了一套前端 DSL领域特定语言让你可以用声明式的方式描述 “我要先做 prompt A、然后调 tool B、再用结果约束生成格式 C”。引擎收到这个程序后可以分析哪个前缀可以被缓存自动插入结构化约束解码跨请求优化调度顺序这个设计决策的后果是SGLang 在三个引擎中最重——它不仅管调度还管语言解析、约束执行和推理优化。但也是这个重让它在 Agent、多轮对话、RAG 场景下能比 vLLM 快 3-5 倍。SGLang 在调度层继承了 vLLM 的大部分设计PagedAttention、Continuous Batching但在 KV Cache 管理上改用RadixAttention第 17 篇详述在多轮对话/Agent 场景有质的优势。2.3 TensorRT-LLM编译器路线把 GPU 榨干TensorRT-LLM简称 TRT-LLM的定位完全不同——它是一套编译器。你把模型定义和配置扔进去它花 15-30 分钟编译出一个高度优化的 GPU 可执行程序然后上线运行。编译路线的好处算子融合多个小 kernel 合并成一个大 kernel减少 kernel launch 开销内存规划提前算好每层的显存分配运行时零动态分配量化原生FP8/INT4 直接在 Tensor Core 上算不需要反量化自动调优对当前硬件做 auto-tuning选最快的 kernel 实现代价是换模型、换 GPU、改精度——都要重新编译调试困难编译出来的不是人能看懂的代码只支持 NVIDIA GPU三者路线对比vLLM: 调度层极致优化← 计算层借别人的 kernel SGLang: 语言层前端 DSL→ 调度层RadixAttention→ 计算层 TRT-LLM: 编译层全链路融合→ 运行时几乎无调度开销三、调度与批处理Continuous Batching 的三副面孔第 17 篇讲过 Continuous Batching 的核心思想——每步 token 后重新组批长 prompt 切碎混排。但三个引擎在具体怎么排上有不小差异。3.1 vLLM最成熟的调度器vLLM 的调度器三层结构等待队列 ─→ 调度策略 ─→ 当前运行集 ─→ 模型前向 │ └→ 抢占策略recompute / swap调度策略要点Decode 优先所有正在生成 token 的请求优先调度Chunked Prefill 填空用剩余的 token 预算调度 prefill chunk配额控制max_num_seqs最大并发请求数和max_num_batched_tokens每步最大 token 数双重限制抢占策略显存不够时默认recompute丢弃 KV Cache后续重新 prefill可选swapKV Cache 换出到 CPU 内存vLLM 的调度器经过两年生产验证在各种极端场景下都有不错的鲁棒性。3.2 SGLang更激进的调度SGLang 在调度层做了几个关键改进更小的调度粒度vLLM 以请求为单位调度SGLang 以token 为单位调度配合 RadixAttention 的 page_size1SGLang 可以精确到每个 token 的调度优先级Prefill 和 Decode 分离Disaggregated Prefill解耦后prefill 节点专注 compute-heavy 的前向decode 节点做 memory-bound 的自回归不同节点可以有不同的 batch 策略和硬件配置前瞻调度Lookahead SchedulingSGLang 在调度当前步时预读下一步的请求队列如果发现后续请求与当前请求共享前缀可以提前合并调度3.3 TensorRT-LLM最底层的调度TRT-LLM 的调度叫In-Flight BatchingIFB——和 Continuous Batching 本质相同但实现更底层。关键差异 1调度在内核里vLLM 和 SGLang 的调度器在 Python 层TRT-LLM 的调度器在 C runtime 层深度嵌入到 CUDA stream 管理中。这意味着调度决策可以和 kernel 执行 pipeline 在一起。关键差异 2两个关键参数max_batch_size最大并发请求数max_num_tokens每步最大 token 数这两个参数决定了 TRT-LLM 的资源预算。配大了浪费显存配小了限制吞吐。生产调优的核心工作就是做这两者的 grid search。关键差异 3三种调度策略策略行为适用场景GUARANTEED_NO_EVICT默认请求一旦开始绝不驱逐延迟敏感在线服务MAX_UTILIZATION尽可能多的请求可能驱赶吞吐优先批处理STATIC_BATCH传统静态批处理不推荐生产使用双参数调优实测效果Llama 3.3 70B4×H100max_batch_size 64 → 1944 tok/s (baseline) max_batch_size 512 → 2467 tok/s (27%) max_num_tokens 2048 → 2474 tok/s 组合调优 → 3074 tok/s58% 总提升三引擎调度对比一览特性vLLMSGLangTensorRT-LLM调度实现层PythonPythonC Runtime调度粒度请求级Token 级请求级 kernel 级Prefill/Decode 分离❌计划中✅ 原生支持✅Disagg 模式长 prompt 切分Chunked PrefillChunked PrefillChunked Context抢占策略Recompute / SwapRecomputeEvict / Guarantee调优复杂度低中高需 grid search四、KV Cache 管理从原理到实践第 17 篇深入解释了 PagedAttention 和 RadixAttention 的原理。这里只聚焦三引擎在工程实现上的关键差异。4.1 前缀缓存机制的对比vLLMSGLangTensorRT-LLM机制哈希表 Block 级Radix Tree Token 级Block 级block_reuse匹配精度16-token Block逐 tokenBlock 级淘汰策略平坦 LRU树感知 LRU先删叶子优先级驱动多轮对话优势1xbaseline3-5x~1.2x有限复用一个典型 RAG 场景的数据100 并发60% 文档重叠无缓存: 225K token/批的 prefill vLLM APC: 125K token/批优化 -44% SGLang: 65K token/批优化 -71% TRT-LLM: 120K token/批block_reuse 开启后的近似值SGLang 的 RadixAttention 在高并发共享前缀场景下优势明显而且差距随着前缀长度增加而扩大。4.2 TensorRT-LLM 的 Paged KV CacheTRT-LLM 也支持 Paged KV Cache有两个重要参数{kv_cache_config:{free_gpu_memory_fraction:0.85,enable_block_reuse:true}}enable_block_reuse开启后TRT-LLM 会缓存共享前缀的 Block。但和 SGLang 的 Radix Tree 不同TRT-LLM 的复用是 Block 级的只能在 16-token 边界上匹配精细度不如 SGLang。五、编译优化TensorRT-LLM 的杀手锏这是三个引擎最大的性能差距来源。5.1 TensorRT-LLM 的编译流程TRT-LLM 部署一个模型需要经过模型权重 配置 ↓ 图构建build graph将 PyTorch/FasterTransformer 模型转成 TRT-LLM 内部 IR ↓ 图优化graph optimization算子融合、死代码消除、常量折叠 ↓ 自动调优auto-tuning对每个 fused kernel 搜索最优配置block size, grid size... ↓ 内存规划memory planning提前分配所有 tensor 的物理地址 ↓ 序列化serialization生成 .engine 文件部署时加载编译完成后推理时的调度开销基本归零——所有资源分配在编译期就确定了。典型编译时长模型GPU编译时间Llama 2 7BH1005-10 minLlama 3 70BH10015-25 minMixtral 8x7BH10020-35 min5.2 vLLM 和 SGLang 的编译策略vLLM 和 SGLang 不做 AOTahead-of-time编译。它们采用折中方案CUDA Graph 捕获在推理启动前对固定 batch size 的模型前向做一次 CUDA Graph capture将多次 kernel launch 打包成一个 graph减少 CPU→GPU 通信开销问题只在固定 batch size下有效batch 变化需要重新 capture无 CUDA Graph: 每次迭代 N 次 kernel launch每个算子一次 有 CUDA Graph: 每次迭代 1 次 graph launchgraph 内部包含所有 kernelFlashAttention / PagedAttention kernel这些 kernel 本身是高优化的手动实现但每个 kernel 之间仍是独立的——缺少 TRT-LLM 的跨算子融合vLLM/SGLang 的 CUDA Graph 策略预设一批 batch size如 1, 2, 4, 8, 16, 32…每次推理前选最接近的已捕获 graph多出的 token 做 paddingSGLang 0.6 引入了 FlashInfer 作为 unified kernel backend让 attention 的 kernel 融合度更高。5.3 这个差距实际有多大一个典型的 decode 迭代vLLM/SGLang: Layer 0: launch RMSNorm → launch Attention → launch Add → launch FFN → ... Layer 1: launch RMSNorm → launch Attention → launch Add → launch FFN → ... ... 32-80 层 → 每次迭代约 100-200 次 kernel launch TensorRT-LLM (编译后): 每次迭代 → 1-2 次 fused kernel launch合并了相邻的小算子 → CPU 调度开销接近于零在 batch size 较小时1-16kernel launch 开销占比显著此时 TRT-LLM 的融合优势最明显。随着 batch 增大计算本身成为瓶颈融合收益相对降低。六、量化FP8/INT4 的原生计算 vs 后量化这是一个经常被低估的差异点。6.1 TensorRT-LLM量化就是计算精度TRT-LLM 在做编译时会为量化精度专门生成计算 kernelFP16 engine: 用 FP16 Tensor Core 计算 FP8 engine: 用 FP8 Tensor Core 计算H100 原生支持 INT4 engine: 用 INT4 Tensor Core 计算Blackwell 原生支持 INT8 engine: 用 INT8 Tensor Core 计算所有架构都支持这意味着TRT-LLM 跑 FP8 时计算和存储都在 FP8不需要反量化。H100 的 FP8 Tensor Core 算力是 FP16 的 2 倍这是实打实的吞吐翻倍。6.2 vLLM 和 SGLang量化主要是省显存vLLM 和 SGLang 的量化实现主要来自AWQ / GPTQ等权重量化方案存储 FP16 权重 → INT4 权重4x 压缩 计算时 INT4 → 反量化 → FP16 → FP16 matmul省了显存但计算时先反量化再计算——INT4 的算力优势没有直接转化为速度优势因为计算还是 FP16 的。你省的是 HBM 带宽少读了 4x 的权重不是计算 FLOPs。vLLM/SGLang 量化流程 从 HBM 读 INT4 权重 → 反量化为 FP16 → 在 FP16 Tensor Core 上计算 TRT-LLM FP8 流程 从 HBM 读 FP8 权重 → 直接在 FP8 Tensor Core 上计算 → 省带宽 省计算H100 FP8 TFLOPs 2× FP16 TFLOPs6.3 实际影响场景vLLM AWQTRT-LLM FP8差距DeepSeek V4-Flash 284B (4×H100)1,850 tok/s2,312 tok/s25%显存占用同同FP8 也是 1 byte/param—精度损失极小AWQ 校准1%—TRT-LLM 的 FP8 同时省带宽和省算力而 AWQ 只省带宽。这就是为什么 TRT-LLM 在支持 FP8 的硬件上总是最快的。七、性能基准对比一张表看清差距7.1 小模型单卡测试H100Qwen2.5-7BFP8/BF16输入 512 tokens输出 256 tokens并发vLLMSGLangTRT-LLM1611,200 tok/s12,800tok/s (14%)14,500tok/s (29%)6418,400 tok/s21,600tok/s (17%)23,800tok/s (29%)12822,100 tok/s27,300tok/s (23%)26,500 tok/s (20%)P99 延迟并发vLLMSGLangTRT-LLM16680 ms620 ms540 ms641,240 ms980 ms860 ms1282,800 ms1,900 ms2,100 ms分析中低并发16-64TRT-LLM 的编译优化和 FP8 原生计算带来稳定的吞吐优势高并发128SGLang 的 RadixAttention 前缀复用效果显著吞吐反超 TRT-LLMP99 延迟最优7.2 大模型多卡测试DeepSeek V4-Flash 284B MoE4×H100FP8引擎吞吐 (tok/s)TTFT (ms)TPOT (ms)P99 延迟TRT-LLM FP82,3128918210 msSGLang FP82,1509222195 msvLLM AWQ1,85010525240 msTRT-LLM 的 FP8 优势在 MoE 模型上同样明显而 SGLang 在尾延迟控制上更好RadixAttention 减少调度抖动。7.3 RTX 4090 单卡测试Qwen2.5-1.5B指标TRT-LLMSGLangvLLMTTFT 均值224.0 ms179.2 ms531.1 msTTFT 最小值223.5 ms38.6 ms缓存命中506.3 msTTFT 最大值227.7 ms480.6 ms缓存未命中555.1 ms抖动范围4 ms441 ms49 ms这个测试揭示了三个引擎的极端差异TRT-LLM延迟最低且最稳定抖动仅 4ms适合延迟敏感场景SGLang缓存命中时极快38.6ms缓存未命中时波动大vLLM延迟最高但胜在稳定性和兼容性八、部署运维实战8.1 部署复杂度vLLM最简单: pip install vllm vllm serve meta-llama/Llama-3.1-8B --port 8000 → 5 分钟内启动 SGLang也简单: pip install sglang python -m sglang.launch_server --model meta-llama/Llama-3.1-8B → 5 分钟内启动 TRT-LLM最复杂: # 1. 拉 Docker 镜像 docker pull nvidia/cuda:12.8-devel # 2. 安装 TRT-LLM pip install tensorrt_llm # 3. 将 HuggingFace 模型转成 TRT-LLM 格式 python examples/llama/convert_checkpoint.py --model_dir ... --output_dir ... # 4. 编译 engine trtllm-build --checkpoint_dir ... --output_dir ... --model_config config.json # 5. 启动服务 python examples/run.py --engine_dir ... → 首次部署 30-60 分钟8.2 模型变更成本场景vLLMSGLangTRT-LLM换模型权重重启即换重启即换重新编译15-30 min换精度FP16→FP8换权重即可换权重即可重新编译换 GPU 架构不需要改不需要改重新编译加 LoRA adapter运行时热切换 ✅运行时热切换 ✅需要重新编译 ❌这是 TRT-LLM 最大的痛点编译后一切都被固定了。如果你有三套模型要部署就得编三次。如果每个模型还要跑 FP16 和 FP8 两种精度编译次数×2。8.3 硬件支持矩阵硬件vLLMSGLangTRT-LLMNVIDIA H100/B200/RTX✅ 最佳✅ 最佳✅独占必须 NVIDIAAMD MI300X✅ 社区支持❌ 有限❌Intel Gaudi 3✅ 社区支持❌❌Google TPU✅ 实验性❌❌华为昇腾 910B⚠️ 第三方移植❌❌Apple SiliconMPS⚠️ 实验性❌❌vLLM 在硬件兼容性上有明显优势——社区驱动的 ROCm、Intel XPU、TPU 后端持续在完善。九、选型决策框架9.1 一张速查表你的需求首选备选原因快速上线、原型验证vLLMSGLang部署最简单兼容性最好Agent / 多轮对话SGLangvLLMRadixAttention 多轮 3-5×结构化输出JSONSGLangvLLM Guidance原生约束解码极致吞吐、8×H200TRT-LLMSGLangFP8 原生计算 10-30% 领先低延迟对话类TRT-LLMSGLang编译融合无调度抖动LoRA 多适配器切换vLLMSGLang原生支持运行时热切换国产 GPU 部署vLLM—唯一有社区移植的引擎模型频繁换 / A/B 测试vLLMSGLang重启即换不用等编译混合模型服务vLLMSGLang多模型并行最成熟9.2 务实路径从 vLLM 起步用 SGLang 补齐 Agent大多数团队的进化路线第一阶段vLLM - 快速上线第一版 API - 用 AWQ/GPTQ 量化降低显存需求 - 确认推理成为瓶颈后进入下一阶段 第二阶段vLLM SGLang 混用 - 简单场景单轮生成、批量推理继续用 vLLM - Agent 场景、高并发前缀共享场景切换到 SGLang - 两个引擎可以跑在同一套 GPU 集群上 第三阶段可选引入 TRT-LLM - 当性能需求超过 vLLM/SGLang 能提供的 - 且模型固定不再频繁迭代 - 重点场景只部署在 NVIDIA 最新硬件上 - vLLM/SGLang 仍作为灵活性兜底9.3 一个决定性的问题在你纠结选哪个引擎之前先回答这个问题你的模型明年还长这样吗如果答案是否定的 →选 vLLM。灵活性比那 20-30% 的性能提升值钱得多。如果你在做一个 Agent 平台对话流程非常复杂 →选 SGLang。RadixAttention 结构化输出是别家没有的硬核优势。如果你在做一个长期稳定的 SaaS模型固定不变NVIDIA 硬件专享 →可以考虑 TRT-LLM但要算清楚编译维护成本。十、总结核心数据回顾维度vLLMSGLangTensorRT-LLM通用吞吐7B, H100, 64并发18.4K tok/s21.6K tok/s (17%)23.8K(29%)大模型吞吐284B MoE, 4×H1001.85K tok/s2.15K tok/s2.31Ktok/s高并发 P99 延迟128并发2,800 ms1,900 ms2,100 ms延迟抖动4090, TTFT49 ms441 ms4 msAgent/多轮/结构化一般最佳不支持部署到上线5 min5 min30-60 min模型变更成本重启重启重新编译硬件兼容最广NVIDIA 为主仅 NVIDIA给读者的建议不要为了 20% 的性能提升选一个你最不熟悉的框架。vLLM 和 SGLang 之间的差距大部分场景在 15-25% 之间往往小于你调优提示词、优化 batch 策略、选择合适的量化方式带来的收益。三引擎的格局和它们的定位非常吻合vLLM 是够用灵活——适合大多数人和大多数场景。SGLang 是场景特化——如果你正好在它擅长的领域Agent/结构化/多轮它能给你别处拿不到的收益。TRT-LLM 是性能天花板——但它有价格灵活性、兼容性、运维便利性。先看清自己的需求再选引擎。如果看不清楚从 vLLM 开始总是对的。附录进一步阅读LLM 推理引擎架构——vLLM / SGLang 的核心设计vLLM 论文 (SOSP 2023)SGLang 论文 (NeurIPS 2024)TensorRT-LLM 官方文档EVAL #001: LLM Inference Engine Showdown — vLLM vs TGI vs TRT-LLM vs SGLangThe Best LLM Inference Engines in 2026TRT-LLM vs vLLM vs SGLang: What to Choose in 2026
