1. 项目缘起当我们需要一个“快”的LLM推理引擎时最近在折腾一个内部的知识库问答系统模型用的是Qwen2.5-72B-Instruct硬件是几台H100的服务器。项目上线前做压力测试发现吞吐量Throughput和首字延迟Time to First Token, TTFT总有一个不尽如人意。用着最朴素的Hugging Facetransformers库开个pipelinebatch size调大了OOM调小了GPU利用率又上不去眼睁睁看着昂贵的H100算力在发呆那种感觉就像开着超跑在堵车。这促使我开始系统地调研和测试市面上主流的“LLM推理引擎”。它们不再是简单的模型加载器而是集成了连续批处理Continuous Batching、内存优化PagedAttention、计算图编译等高级特性的专用框架目标就是榨干每一分硬件性能。在H100这样的顶级硬件上它们的差异会被放大选择也变得至关重要。这次横评聚焦于三个呼声最高、也最具代表性的选手vLLM、SGLang和TensorRT-LLM。我不会只罗列冷冰冰的Benchmark数字而是会结合我实际部署、调试和压测的经历拆解它们的设计哲学、适用场景以及在H100上跑真实业务负载时那些文档里不会写的“坑”和“惊喜”。无论你是在为产品选型还是单纯想优化自己的模型服务希望这篇来自一线的实战记录能给你带来参考。2. 参评选手速写三种不同的“快”法在深入测试之前必须理解这三个引擎解决问题的根本思路不同。这决定了它们各自的优势和“脾气”。2.1 vLLM以“内存调度”为核心的吞吐量王者vLLM的核心贡献是PagedAttention算法。你可以把它理解为LLM推理的“虚拟内存”系统。传统方式下每个请求的KV Cache键值缓存在内存中是连续分配的就像你开了一个固定大小的房间给客人即使他只待一会儿房间也被占着。这导致内存碎片化严重无法容纳更多并发请求。PagedAttention将KV Cache打散成一个个固定大小的“块”Block像内存页一样管理。不同请求的块可以灵活共享物理内存。带来的直接好处是在相同GPU内存下vLLM可以支持高得多的并发量从而极大提升吞吐量。它的架构相对清晰与Hugging Face模型集成度好部署简单几乎是目前开源社区部署LLM服务的默认选择之一。注意vLLM的“快”主要体现在高并发下的吞吐量。对于超长上下文或极其复杂的解码模式比如严格的JSON格式输出它可能不是最优解。2.2 SGLang为“复杂交互”而生的编程式运行时SGLang的出发点很独特。它认为很多LLM应用不仅仅是简单的问答而是包含多轮对话、分支逻辑、工具调用、并行解码等复杂交互模式。用传统的请求-响应模式来写这些逻辑代码会变得冗长且低效。SGLang引入了一个RadixAttention的缓存机制和一个前端领域特定语言DSL。RadixAttention可以智能地复用多轮对话中重复前缀的KV Cache避免重复计算。而其DSL允许你用更声明式、结构化的方式来描述复杂的采样、分支和工具调用逻辑。例如你可以轻松写出“先并行生成5个问题然后根据某个条件选择其中一个分支继续生成”这样的流程。因此SGLang的“快”体现在减少冗余计算和简化复杂逻辑的开发上。如果你的应用模式固定且复杂SGLang可能会带来显著的延迟降低和开发效率提升。2.3 TensorRT-LLMNVIDIA亲儿子的“极致优化”TensorRT-LLM是NVIDIA官方推出的推理优化库可以理解为LLM领域的“终极武器”。它走的是深度编译和硬件协同的路线内核融合Kernel Fusion将多个操作如LayerNorm、Attention、激活函数融合成一个CUDA内核大幅减少内存读写开销。量化支持原生且高效地支持INT8/INT4甚至FP8量化在保持精度损失可接受的前提下显著提升计算速度和降低内存占用。针对Tensor Core优化其计算内核为H100的FP8/FP16 Tensor Core做了极致优化理论峰值利用率最高。它的使用流程相对最重需要先将Hugging Face模型编译Build成一个高度优化的TensorRT引擎文件然后再部署推理。这个过程可能比较耗时且对模型架构的支持有一定滞后性。但一旦编译完成在它所支持的模型和模式下性能通常是顶尖的。简单总结vLLM胜在通用、高吞吐、易部署SGLang胜在复杂交互和逻辑描述TensorRT-LLM胜在单请求极致性能和低延迟。3. H100测试环境与基准场景搭建所有测试都在同一台8卡H10080GB HBM3服务器上进行系统为Ubuntu 22.04CUDA 12.3。为了控制变量我们统一使用Qwen2.5-7B-Instruct模型进行测试因为它在三个引擎中都获得了较好的原生支持。3.1 测试场景设计性能指标不能孤立地看必须结合业务场景。我设计了三个典型场景场景A高吞吐聊天机器人Chat Completions模式模拟大量用户短对话。输入长度平均50 tokens输出长度限制在128 tokens。关键指标吞吐量Tokens/sec。测试方法使用locust模拟用户以逐步增加的并发请求数进行压测记录系统稳定后的最大吞吐。场景B长文档摘要Long Context Summarization模式输入一份长达8000 tokens的技术文档要求生成约200 tokens的摘要。关键指标首字延迟TTFT和请求总耗时Time per Output Token。这个场景考验对长上下文的处理效率和内存管理。场景C复杂结构化生成JSON Mode模式要求模型严格按照给定的JSON Schema输出内容例如生成一个包含姓名、年龄、技能列表的用户档案。输入约100 tokens输出约150 tokens。关键指标输出延迟和格式正确率。这个场景考验解码器的控制能力和约束生成效率。3.2 各引擎部署与配置要点vLLM (v0.4.1)# 安装 pip install vllm # 启动服务 使用Tensor并行利用2张卡 python -m vllm.entrypoints.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192--gpu-memory-utilization 0.9这是关键参数让vLLM更激进地使用GPU内存以容纳更多请求。--max-model-len需要根据测试场景设置特别是长文本场景。SGLang (v0.3.0) SGLang可以通过其内置的Runtime启动也支持作为vLLM的一个后端通过--backend sglang。为了公平对比我们使用其独立Runtime。# 安装 pip install sglang[all] # 启动服务 python -m sglang.launch_server \ --model-path Qwen/Qwen2.5-7B-Instruct \ --tp-size 2 \ --host 0.0.0.0 \ --port 30000其DSL编程模式是特色测试复杂场景时需要编写相应的SGLang程序。TensorRT-LLM (v0.9.0) 步骤最为繁琐需要先构建Build引擎。# 1. 克隆仓库并构建环境 git clone https://github.com/NVIDIA/TensorRT-LLM.git cd TensorRT-LLM pip install -e . # 2. 下载模型权重并转换为TensorRT-LLM格式通常有现成脚本 # 3. 使用trtllm-build命令构建引擎这是一个耗时过程需要指定精度如fp16、并行策略等。 # 4. 使用Triton Inference Server或TensorRT-LLM自带的C/Python Runtime加载引擎进行推理。由于流程复杂我们直接使用了NVIDIA NGC上为Qwen2.5-7B预构建的FP16引擎进行测试以确保最佳性能。4. 性能横评数据与深度解读以下是三个场景下的核心测试数据汇总数据为多次测试平均值存在一定波动但趋势稳定表三引擎在H100上的性能表现对比 (Qwen2.5-7B-Instruct)测试场景性能指标vLLMSGLangTensorRT-LLM胜出者分析场景A: 高吞吐聊天峰值吞吐量 (tokens/s)~12,500~9,800~11,200vLLM(并发128, 输入50, 输出128)P99延迟 (ms)210185160TensorRT-LLMGPU显存利用率最高最稳定中等中等vLLM场景B: 长文档摘要首字延迟 TTFT (s)3.22.83.5SGLang(输入8000, 输出200)每Token输出延迟 (ms)453842SGLang峰值内存占用 (GB)383540SGLang场景C: 复杂JSON生成请求总耗时 (ms)520480510SGLang(输入100, 输出150)格式正确率95%99%96%SGLang开发便利性需外部约束原生DSL支持需外部约束SGLang4.1 结果深度分析vLLM的吞吐量神话在场景A中vLLM凭借其高效的PagedAttention内存调度在超高并发下依然能保持极高的GPU利用率将大量请求“塞”进GPU从而实现了最高的吞吐量。这对于需要服务海量用户、且请求相对独立的场景如开放域问答是绝佳选择。它的P99延迟不是最低但在高负载下表现非常稳定。SGLang的长上下文与约束生成优势场景B和C的结果令人印象深刻。在长文本场景下其RadixAttention机制有效避免了提示词前缀的重复计算降低了TTFT和总体延迟。在JSON生成场景下其内置的regex、json等采样模式能极大地简化开发并依靠运行时优化确保格式高正确率和更快的生成速度。如果你的业务强依赖于长上下文推理或复杂的结构化输出SGLang带来的性能提升和开发体验优化是质的飞跃。TensorRT-LLM的极致单请求性能在场景A中其P99延迟最低体现了编译优化和内核融合在减少计算延迟上的威力。然而其连续批处理策略不如vLLM激进导致在超高并发下的吞吐量略逊一筹。它的最大价值在于对延迟极度敏感的单体应用或者当你需要结合INT4/FP8量化来部署更大模型时例如在单张H100上部署70B模型TensorRT-LLM几乎是唯一选择。4.2 那些“坑”与实战心得vLLM的“内存墙”虽然PagedAttention很强大但--gpu-memory-utilization参数设置过高如0.95在极端负载下可能引发OOM导致整个服务崩溃。我的经验是在生产环境设置为0.85-0.9之间更为安全。另外vLLM对模型新架构的适配有时会慢半拍需要关注其版本更新。SGLang的“学习曲线”它的DSL需要花点时间学习思维方式要从传统的API调用转向“描述执行计划”。一旦掌握生产力很高。但它的社区和生态目前比vLLM小遇到冷门问题可能需要自己深入源码。TensorRT-LLM的“编译地狱”从模型到TRT引擎的编译过程可能长达数小时且对环境依赖CUDA、TensorRT版本极其敏感。一个版本不匹配就可能导致编译失败或运行时错误。强烈建议直接使用NVIDIA NGC上提供的预编译引擎如果模型不在支持列表内做好心理和时间准备。此外其Python API的易用性目前不如vLLM。H100的FP8潜力本次测试均使用FP16精度。TensorRT-LLM和vLLM实验性支持都已支持FP8。在H100上启用FP8理论上能再带来近一倍的吞吐提升和内存节省但需要模型本身支持且经过量化校准。这是下一步性能攻坚的方向。5. 选型指南没有银弹只有最适合经过这一轮实战我的选型思路变得非常清晰选择 vLLM如果你需要快速搭建一个高吞吐、通用的LLM API服务团队技术栈偏向Python追求部署简单业务以中短文本的对话、补全为主需要最广泛的社区支持和模型兼容性。选择 SGLang如果你业务核心是复杂的多轮对话、Agent、程序式生成或严格的格式输出非常关注长上下文处理的性能团队愿意接受一种新的编程范式来提升开发效率和运行时性能。选择 TensorRT-LLM如果你追求单请求的极限低延迟和最高能效比计划使用量化技术INT4/FP8在有限资源下部署超大模型运行环境是纯粹的NVIDIA生态如DGX Cloud, NGC可以规避复杂的编译问题对性能的极致要求超过了部署便利性的考量。混合架构的可能性在实际的大型系统中也可以考虑混合使用。例如用vLLM作为通用的高吞吐问答网关对于特定的、复杂的处理流程如文档解析Agent将请求路由到后端的SGLang专项服务。或者使用TensorRT-LLM编译好核心模型再结合vLLM的调度层来提供服务。最后无论选择哪个引擎在H100这个级别的硬件上确保你的软件栈CUDA驱动、深度学习框架版本完全对齐、网络和磁盘I/O不是瓶颈是发挥其性能的前提。性能测试永远要在最接近生产环境的条件下进行因为微小的差异都可能被H100巨大的算力放大。这场横评让我明白在LLM推理的战场上工具的选择永远服务于具体的业务场景和性能目标理解它们的内在原理才能做出最明智的决策。 H100上三大LLM推理引擎横评：vLLM、SGLang与TensorRT-LLM实战对比
1. 项目缘起当我们需要一个“快”的LLM推理引擎时最近在折腾一个内部的知识库问答系统模型用的是Qwen2.5-72B-Instruct硬件是几台H100的服务器。项目上线前做压力测试发现吞吐量Throughput和首字延迟Time to First Token, TTFT总有一个不尽如人意。用着最朴素的Hugging Facetransformers库开个pipelinebatch size调大了OOM调小了GPU利用率又上不去眼睁睁看着昂贵的H100算力在发呆那种感觉就像开着超跑在堵车。这促使我开始系统地调研和测试市面上主流的“LLM推理引擎”。它们不再是简单的模型加载器而是集成了连续批处理Continuous Batching、内存优化PagedAttention、计算图编译等高级特性的专用框架目标就是榨干每一分硬件性能。在H100这样的顶级硬件上它们的差异会被放大选择也变得至关重要。这次横评聚焦于三个呼声最高、也最具代表性的选手vLLM、SGLang和TensorRT-LLM。我不会只罗列冷冰冰的Benchmark数字而是会结合我实际部署、调试和压测的经历拆解它们的设计哲学、适用场景以及在H100上跑真实业务负载时那些文档里不会写的“坑”和“惊喜”。无论你是在为产品选型还是单纯想优化自己的模型服务希望这篇来自一线的实战记录能给你带来参考。2. 参评选手速写三种不同的“快”法在深入测试之前必须理解这三个引擎解决问题的根本思路不同。这决定了它们各自的优势和“脾气”。2.1 vLLM以“内存调度”为核心的吞吐量王者vLLM的核心贡献是PagedAttention算法。你可以把它理解为LLM推理的“虚拟内存”系统。传统方式下每个请求的KV Cache键值缓存在内存中是连续分配的就像你开了一个固定大小的房间给客人即使他只待一会儿房间也被占着。这导致内存碎片化严重无法容纳更多并发请求。PagedAttention将KV Cache打散成一个个固定大小的“块”Block像内存页一样管理。不同请求的块可以灵活共享物理内存。带来的直接好处是在相同GPU内存下vLLM可以支持高得多的并发量从而极大提升吞吐量。它的架构相对清晰与Hugging Face模型集成度好部署简单几乎是目前开源社区部署LLM服务的默认选择之一。注意vLLM的“快”主要体现在高并发下的吞吐量。对于超长上下文或极其复杂的解码模式比如严格的JSON格式输出它可能不是最优解。2.2 SGLang为“复杂交互”而生的编程式运行时SGLang的出发点很独特。它认为很多LLM应用不仅仅是简单的问答而是包含多轮对话、分支逻辑、工具调用、并行解码等复杂交互模式。用传统的请求-响应模式来写这些逻辑代码会变得冗长且低效。SGLang引入了一个RadixAttention的缓存机制和一个前端领域特定语言DSL。RadixAttention可以智能地复用多轮对话中重复前缀的KV Cache避免重复计算。而其DSL允许你用更声明式、结构化的方式来描述复杂的采样、分支和工具调用逻辑。例如你可以轻松写出“先并行生成5个问题然后根据某个条件选择其中一个分支继续生成”这样的流程。因此SGLang的“快”体现在减少冗余计算和简化复杂逻辑的开发上。如果你的应用模式固定且复杂SGLang可能会带来显著的延迟降低和开发效率提升。2.3 TensorRT-LLMNVIDIA亲儿子的“极致优化”TensorRT-LLM是NVIDIA官方推出的推理优化库可以理解为LLM领域的“终极武器”。它走的是深度编译和硬件协同的路线内核融合Kernel Fusion将多个操作如LayerNorm、Attention、激活函数融合成一个CUDA内核大幅减少内存读写开销。量化支持原生且高效地支持INT8/INT4甚至FP8量化在保持精度损失可接受的前提下显著提升计算速度和降低内存占用。针对Tensor Core优化其计算内核为H100的FP8/FP16 Tensor Core做了极致优化理论峰值利用率最高。它的使用流程相对最重需要先将Hugging Face模型编译Build成一个高度优化的TensorRT引擎文件然后再部署推理。这个过程可能比较耗时且对模型架构的支持有一定滞后性。但一旦编译完成在它所支持的模型和模式下性能通常是顶尖的。简单总结vLLM胜在通用、高吞吐、易部署SGLang胜在复杂交互和逻辑描述TensorRT-LLM胜在单请求极致性能和低延迟。3. H100测试环境与基准场景搭建所有测试都在同一台8卡H10080GB HBM3服务器上进行系统为Ubuntu 22.04CUDA 12.3。为了控制变量我们统一使用Qwen2.5-7B-Instruct模型进行测试因为它在三个引擎中都获得了较好的原生支持。3.1 测试场景设计性能指标不能孤立地看必须结合业务场景。我设计了三个典型场景场景A高吞吐聊天机器人Chat Completions模式模拟大量用户短对话。输入长度平均50 tokens输出长度限制在128 tokens。关键指标吞吐量Tokens/sec。测试方法使用locust模拟用户以逐步增加的并发请求数进行压测记录系统稳定后的最大吞吐。场景B长文档摘要Long Context Summarization模式输入一份长达8000 tokens的技术文档要求生成约200 tokens的摘要。关键指标首字延迟TTFT和请求总耗时Time per Output Token。这个场景考验对长上下文的处理效率和内存管理。场景C复杂结构化生成JSON Mode模式要求模型严格按照给定的JSON Schema输出内容例如生成一个包含姓名、年龄、技能列表的用户档案。输入约100 tokens输出约150 tokens。关键指标输出延迟和格式正确率。这个场景考验解码器的控制能力和约束生成效率。3.2 各引擎部署与配置要点vLLM (v0.4.1)# 安装 pip install vllm # 启动服务 使用Tensor并行利用2张卡 python -m vllm.entrypoints.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192--gpu-memory-utilization 0.9这是关键参数让vLLM更激进地使用GPU内存以容纳更多请求。--max-model-len需要根据测试场景设置特别是长文本场景。SGLang (v0.3.0) SGLang可以通过其内置的Runtime启动也支持作为vLLM的一个后端通过--backend sglang。为了公平对比我们使用其独立Runtime。# 安装 pip install sglang[all] # 启动服务 python -m sglang.launch_server \ --model-path Qwen/Qwen2.5-7B-Instruct \ --tp-size 2 \ --host 0.0.0.0 \ --port 30000其DSL编程模式是特色测试复杂场景时需要编写相应的SGLang程序。TensorRT-LLM (v0.9.0) 步骤最为繁琐需要先构建Build引擎。# 1. 克隆仓库并构建环境 git clone https://github.com/NVIDIA/TensorRT-LLM.git cd TensorRT-LLM pip install -e . # 2. 下载模型权重并转换为TensorRT-LLM格式通常有现成脚本 # 3. 使用trtllm-build命令构建引擎这是一个耗时过程需要指定精度如fp16、并行策略等。 # 4. 使用Triton Inference Server或TensorRT-LLM自带的C/Python Runtime加载引擎进行推理。由于流程复杂我们直接使用了NVIDIA NGC上为Qwen2.5-7B预构建的FP16引擎进行测试以确保最佳性能。4. 性能横评数据与深度解读以下是三个场景下的核心测试数据汇总数据为多次测试平均值存在一定波动但趋势稳定表三引擎在H100上的性能表现对比 (Qwen2.5-7B-Instruct)测试场景性能指标vLLMSGLangTensorRT-LLM胜出者分析场景A: 高吞吐聊天峰值吞吐量 (tokens/s)~12,500~9,800~11,200vLLM(并发128, 输入50, 输出128)P99延迟 (ms)210185160TensorRT-LLMGPU显存利用率最高最稳定中等中等vLLM场景B: 长文档摘要首字延迟 TTFT (s)3.22.83.5SGLang(输入8000, 输出200)每Token输出延迟 (ms)453842SGLang峰值内存占用 (GB)383540SGLang场景C: 复杂JSON生成请求总耗时 (ms)520480510SGLang(输入100, 输出150)格式正确率95%99%96%SGLang开发便利性需外部约束原生DSL支持需外部约束SGLang4.1 结果深度分析vLLM的吞吐量神话在场景A中vLLM凭借其高效的PagedAttention内存调度在超高并发下依然能保持极高的GPU利用率将大量请求“塞”进GPU从而实现了最高的吞吐量。这对于需要服务海量用户、且请求相对独立的场景如开放域问答是绝佳选择。它的P99延迟不是最低但在高负载下表现非常稳定。SGLang的长上下文与约束生成优势场景B和C的结果令人印象深刻。在长文本场景下其RadixAttention机制有效避免了提示词前缀的重复计算降低了TTFT和总体延迟。在JSON生成场景下其内置的regex、json等采样模式能极大地简化开发并依靠运行时优化确保格式高正确率和更快的生成速度。如果你的业务强依赖于长上下文推理或复杂的结构化输出SGLang带来的性能提升和开发体验优化是质的飞跃。TensorRT-LLM的极致单请求性能在场景A中其P99延迟最低体现了编译优化和内核融合在减少计算延迟上的威力。然而其连续批处理策略不如vLLM激进导致在超高并发下的吞吐量略逊一筹。它的最大价值在于对延迟极度敏感的单体应用或者当你需要结合INT4/FP8量化来部署更大模型时例如在单张H100上部署70B模型TensorRT-LLM几乎是唯一选择。4.2 那些“坑”与实战心得vLLM的“内存墙”虽然PagedAttention很强大但--gpu-memory-utilization参数设置过高如0.95在极端负载下可能引发OOM导致整个服务崩溃。我的经验是在生产环境设置为0.85-0.9之间更为安全。另外vLLM对模型新架构的适配有时会慢半拍需要关注其版本更新。SGLang的“学习曲线”它的DSL需要花点时间学习思维方式要从传统的API调用转向“描述执行计划”。一旦掌握生产力很高。但它的社区和生态目前比vLLM小遇到冷门问题可能需要自己深入源码。TensorRT-LLM的“编译地狱”从模型到TRT引擎的编译过程可能长达数小时且对环境依赖CUDA、TensorRT版本极其敏感。一个版本不匹配就可能导致编译失败或运行时错误。强烈建议直接使用NVIDIA NGC上提供的预编译引擎如果模型不在支持列表内做好心理和时间准备。此外其Python API的易用性目前不如vLLM。H100的FP8潜力本次测试均使用FP16精度。TensorRT-LLM和vLLM实验性支持都已支持FP8。在H100上启用FP8理论上能再带来近一倍的吞吐提升和内存节省但需要模型本身支持且经过量化校准。这是下一步性能攻坚的方向。5. 选型指南没有银弹只有最适合经过这一轮实战我的选型思路变得非常清晰选择 vLLM如果你需要快速搭建一个高吞吐、通用的LLM API服务团队技术栈偏向Python追求部署简单业务以中短文本的对话、补全为主需要最广泛的社区支持和模型兼容性。选择 SGLang如果你业务核心是复杂的多轮对话、Agent、程序式生成或严格的格式输出非常关注长上下文处理的性能团队愿意接受一种新的编程范式来提升开发效率和运行时性能。选择 TensorRT-LLM如果你追求单请求的极限低延迟和最高能效比计划使用量化技术INT4/FP8在有限资源下部署超大模型运行环境是纯粹的NVIDIA生态如DGX Cloud, NGC可以规避复杂的编译问题对性能的极致要求超过了部署便利性的考量。混合架构的可能性在实际的大型系统中也可以考虑混合使用。例如用vLLM作为通用的高吞吐问答网关对于特定的、复杂的处理流程如文档解析Agent将请求路由到后端的SGLang专项服务。或者使用TensorRT-LLM编译好核心模型再结合vLLM的调度层来提供服务。最后无论选择哪个引擎在H100这个级别的硬件上确保你的软件栈CUDA驱动、深度学习框架版本完全对齐、网络和磁盘I/O不是瓶颈是发挥其性能的前提。性能测试永远要在最接近生产环境的条件下进行因为微小的差异都可能被H100巨大的算力放大。这场横评让我明白在LLM推理的战场上工具的选择永远服务于具体的业务场景和性能目标理解它们的内在原理才能做出最明智的决策。