TensorRT-LLM

推理引擎：LLM服务的核心基础设施 模型只是"大脑"，推理引擎是"神经系统"——它决定了模型服务能多快、能并发多少请求、成本多低。选对推理引擎，单GPU的吞吐量差异可达5-10倍。 三大主流引擎 vLLM：社区标准 架构特点： PagedAttention：操作系统级KV Cache管理 Continuous Batching：迭代级动态批处理 纯Python实现（核心算子用CUDA/Triton） 支持大多数主流开源模型 核心技术：PagedAttention 传统KV Cache: 请求A: [已分配 5/5 blocks] [等待分配...] 请求B: [已分配 3/3 blocks] → 内存碎片化，浪费30-60% PagedAttention: Block Pool: [A1][B1][A2][C1][B2][A3]... 每个请求通过页表映射到物理block → 零碎片，内存利用率接近100% 性能特征： 吞吐量：比HuggingFace Transformers高24倍 首token延迟：中等 显存利用率：90%+ 支持多模型共享GPU 优势： 社区支持最广，几乎所有模型首发支持 部署简单（一行命令启动） 持续迭代，功能快速扩展 劣势： 纯Python实现，某些热路径不如C++优化 不支持一些极致优化（如FP8推理） 调度策略相对简单 SGLang：结构化生成之王 架构特点： 前缀缓存（Prefix Caching）：跨请求共享计算 程序化生成：支持结构化输出约束 原生支持JSON/正则约束 C++核心，Python接口 核心技术：RadixAttention 请求1: "system: 你是助手\nuser: 天气" → 缓存KV Cache 请求2: "system: 你是助手\nuser: 股票" → 复用"system: 你是助手\n"的前缀KV Cache → 只需计算新的部分 多请求共享相同system prompt时，前缀缓存可节省50%+计算。 ...

推理引擎：大模型生产的最后一公里 模型训练完成后，推理引擎决定了它能否高效地服务用户。同样的模型，用不同的推理引擎部署，吞吐量可能相差5-10倍。vLLM、SGLang和TensorRT-LLM是当前最主流的三大推理引擎，各有特色。 三大引擎概述 vLLM vLLM由UC Berkeley团队开发，以PagedAttention技术闻名： from vllm import LLM, SamplingParams llm = LLM( model="meta-llama/Meta-Llama-3-70B", tensor_parallel_size=4, # 4卡张量并行 gpu_memory_utilization=0.90, max_model_len=8192, enable_prefix_caching=True, # 前缀缓存 swap_space=16, # CPU swap空间(GB) ) sampling = SamplingParams( temperature=0.7, top_p=0.9, max_tokens=512, ) outputs = llm.generate(["你好，介绍一下自己"], sampling) 核心技术： PagedAttention：虚拟内存式KV Cache管理 Continuous Batching：动态批处理 Prefix Caching：共享前缀缓存 支持多种量化（AWQ、GPTQ、FP8） SGLang SGLang由UC Berkeley团队（vLLM部分成员）开发，专注于结构化生成： import sglang as sgl @sgl.function def multi_step_reasoning(s, question): s += "请分析以下问题：" + question s += "第一步：理解问题" + sgl.gen("understanding", max_tokens=200) s += "第二步：分析方案" + sgl.gen("analysis", max_tokens=300) s += "第三步：结论" + sgl.gen("conclusion", max_tokens=200) # RadixAttention自动缓存前缀 engine = sgl.Engine( model_path="meta-llama/Meta-Llama-3-70B", tp_size=4, ) result = multi_step_reasoning.run(question="AI对就业市场的影响") 核心技术： RadixAttention：基于基数树的前缀缓存，比vLLM的前缀缓存更高效 结构化生成：JSON、正则表达式约束的生成 前端DSL：Python装饰器定义生成流程 多轮对话优化：对话前缀自动复用 TensorRT-LLM NVIDIA官方推理引擎，与硬件深度优化： import tensorrt_llm from tensorrt_llm.runtime import ModelRunner # 构建引擎（需先转换模型） builder = tensorrt_llm.Builder() config = builder.create_builder_config( max_batch_size=128, max_input_len=8192, max_output_len=1024, use_fp8=True, # FP8量化 use_paged_kv_cache=True, tokens_per_block=128, ) engine = builder.build_engine(model, config) # 运行推理 runner = ModelRunner(engine) outputs = runner.generate( input_ids=input_ids, sampling_config=sampling_config ) 核心技术： ...

引言 大模型的推理成本通常占AI总成本的70%以上。高效的推理框架不仅能够降低运营成本，还能提升用户体验。2026年，主流推理框架在性能、功能和易用性上都有显著提升。本文对vLLM、SGLang、TensorRT-LLM、TGI四大框架进行深度对比。 框架概览 vLLM 定位： 高吞吐、低延迟的LLM推理引擎 核心技术： PagedAttention：解决KV Cache碎片化问题 Continuous Batching：请求级动态批处理 Tensor Parallelism：模型并行 优势： 吞吐量比HuggingFace Transformers高24倍 社区最大，生态最丰富 支持多种量化格式（AWQ、GPTQ、SqueezeLLM） 局限： 主要优化标准生成场景 高级功能（如Speculative Decoding）仍在演进 SGLang 定位： 面向复杂推理场景的高性能框架 核心技术： RadixAttention：分层缓存的KV Cache管理 结构化输出：JSON、正则表达式约束 推理+训练一体化 优势： 复杂推理场景性能突出 结构化输出支持完善 支持Speculative Decoding 局限： 社区相对较小 文档和生态不如vLLM丰富 TensorRT-LLM 定位： NVIDIA官方的高性能推理优化库 核心技术： 算子级优化：针对NVIDIA GPU深度优化 量化：FP8、INT4、FP4支持 多GPU/多节点分布式推理 优势： NVIDIA硬件上的极致性能 工业级稳定性 与NVIDIA全栈生态集成 局限： 仅支持NVIDIA GPU 配置复杂，学习曲线陡 非NVIDIA硬件兼容性差 TGI (Text Generation Inference) 定位： HuggingFace的推理服务器 核心技术： 动态批处理 张量并行 连续批处理 优势： 与HuggingFace生态无缝集成 部署简单 支持Safetensors模型 局限： ...

引言 2026年，大模型推理引擎市场已经形成了vLLM、SGLang和TensorRT-LLM三足鼎立的格局。vLLM以易用性和社区生态取胜，SGLang以创新的RadixAttention和灵活编程模型见长，TensorRT-LLM则以极致的NVIDIA硬件优化称雄。本文将通过大量实测，全面对比三大推理引擎，帮助开发者选择最适合的推理解决方案。 推理引擎概述 核心差异 维度 vLLM SGLang TensorRT-LLM 定位 通用推理引擎 高性能+编程模型 NVIDIA专属优化 硬件支持 全平台 NVIDIA+AMD 仅NVIDIA 易用性 ★★★★★ ★★★★ ★★★ 性能 ★★★★ ★★★★★ ★★★★★ 社区生态 ★★★★★ ★★★★ ★★★ 企业支持 社区+企业 社区+创业公司 NVIDIA官方 技术路线 vLLM： 基于PyTorch，易用性优先 PagedAttention创新（内存效率） 支持最广泛的模型和硬件 SGLang： 创新的RadixAttention（前缀缓存） 灵活的编程模型（类似DSL） 针对多轮对话和RAG优化 TensorRT-LLM： 深度NVIDIA硬件优化 量化+内核融合+Fp8原生支持 企业级稳定性和支持 性能实测 测试环境 硬件：8×NVIDIA H100 80GB 模型：Llama 4 70B（INT8）、Qwen3.5 72B（INT8） 基准：生成速度、延迟、吞吐、显存效率 生成速度对比 Llama 4 70B（INT8，batch=1）： 引擎 生成速度 首token延迟 KV Cache效率 vLLM 0.6 142 tok/s 0.9s ★★★★ SGLang 0.3 165 tok/s 0.7s ★★★★★ TRT-LLM 0.9 155 tok/s 0.8s ★★★★★ Qwen3.5 72B（INT8，batch=1）： ...

NVIDIA 的推理加速王牌 TensorRT-LLM 是 NVIDIA 在大模型推理领域的旗舰产品。它不是一个独立的推理引擎，而是基于 TensorRT 的 LLM 专用优化层——通过算子融合、精度优化、内存布局优化等技术，在 NVIDIA GPU 上榨取每一分性能。 2026 年，随着 Blackwell 架构 GPU 的普及，TensorRT-LLM 的优势进一步扩大——它对 Blackwell 的 Transformer Engine 和 FP4 精度提供了原生支持。 2026 核心特性 性能优势 特性 TensorRT-LLM 2026 vLLM 0.8 SGLang 0.3 峰值吞吐量 8,500 tok/s 4,200 tok/s 4,800 tok/s 首 Token 延迟 0.15s 0.5s 0.35s FP4 支持 ✅ (Blackwell) ❌ ❌ FP8 支持 ✅ (Hopper) ✅ ✅ 算子融合 深度 基础 基础 模型编译 AOT 编译 JIT JIT 多 GPU TP + PP + EP TP + PP TP + PP Blackwell 架构优化 # Blackwell B200 上的 FP4 推理 import tensorrt_llm as trtllm # 编译模型为 FP4 精度 builder = trtllm.Builder() config = builder.create_builder_config( precision="fp4", # FP4 量化 plugin_config=trtllm.PluginConfig( attention_plugin=True, nccl_plugin=True, gemm_plugin=True, rmsnorm_plugin=True, # Blackwell 专属 transformer_engine=True, moe_plugin=True, ), max_batch_size=256, max_input_len=32768, max_output_len=4096, max_num_tokens=8192, use_paged_context_fmha=True, # Paged Attention use_context_fmha=True, # Flash Attention multiple_profiles=True, # 多优化 Profile tensor_parallel=8, # 8 路张量并行 pipeline_parallel=1, ) # 编译（AOT，提前编译为优化引擎） engine = builder.build( model_dir="Qwen/Qwen3-72B-Instruct", config=config, output_dir="engines/qwen3-72b-fp4" ) # 编译后的引擎不可移植，绑定特定 GPU 架构 # 但性能比 JIT 方案高 30-60% 部署流程 1. 模型编译 # 步骤 1：从 HuggingFace 模型编译 TensorRT 引擎 import tensorrt_llm as trtllm from tensorrt_llm.models import QWenForCausalLM # 加载模型配置 model_config = trtllm.ModelConfig.from_pretrained( "Qwen/Qwen3-72B-Instruct" ) # 编译配置 build_config = trtllm.BuildConfig( max_input_len=32768, max_output_len=4096, max_batch_size=128, max_num_tokens=8192, opt_batch_size=32, opt_input_len=4096, # 精度配置 precision="fp8", # fp4/fp8/fp16 int8_kv_cache=True, # KV Cache 量化 # 插件配置 plugin_config=trtllm.PluginConfig( paged_kv_cache=True, attention_plugin=True, gemm_plugin=True, nccl_plugin=True, rmsnorm_plugin=True, rotary_plugin=True, remove_input_padding=True, # 移除 padding 优化 ), # 并行配置 tensor_parallel=4, pipeline_parallel=1, # 高级优化 use_fused_mlp=True, # MLP 算子融合 use_fused_qkv=True, # QKV 融合 use_dynamic_shape=True, # 动态形状 weight_sparsity=True, # 权重稀疏化 ) # 编译引擎 builder = trtllm.Builder() engine = builder.build_model( model_config=model_config, build_config=build_config, output_dir="engines/qwen3-72b-fp8-tp4" ) 2. 启动服务 # 使用 Triton Inference Server 部署 # 模型仓库结构 models/ └── qwen3-72b/ ├── config.pbtxt ├── 1/ │ └── model.py └── engines/ └── qwen3-72b-fp8-tp4/ ├── rank0.engine ├── rank1.engine ├── rank2.engine └── rank3.engine # config.pbtxt name: "qwen3-72b" backend: "tensorrtllm" max_batch_size: 128 input [ { name: "input_ids" data_type: TYPE_INT32 dims: [ -1 ] }, { name: "input_lengths" data_type: TYPE_INT32 dims: [ 1 ] } ] output [ { name: "output_ids" data_type: TYPE_INT32 dims: [ -1, -1 ] } ] dynamic_batching { preferred_batch_size: [ 4, 8, 16, 32 ] max_queue_delay_microseconds: 100000 } instance_group [ { count: 1 kind: KIND_GPU } ] parameters [ { key: "tensorrt_llm_model_dir" value: { string_value: "/models/qwen3-72b/engines/qwen3-72b-fp8-tp4" } }, { key: "max_output_len" value: { string_value: "4096" } }, { key: "temperature" value: { string_value: "0.7" } }, { key: "top_p" value: { string_value: "0.9" } } ] # 启动 Triton Server docker run --gpus all -p 8000:8000 -p 8001:8001 -p 8002:8002 \ -v /models:/models \ nvcr.io/nvidia/tritonserver:25.06-py3 \ tritonserver --model-repository=/models \ --backend-directory=/opt/tritonserver/backends \ --log-verbose=1 3. 客户端调用 import tritonclient.grpc as grpcclient import numpy as np class TensorRTLLMClient: def __init__(self, url="localhost:8001"): self.client = grpcclient.InferenceServerClient(url) def generate(self, prompt: str, max_tokens: int = 512, temperature: float = 0.7, stream: bool = True): # Tokenize input_ids = self.tokenizer.encode(prompt) inputs = [ grpcclient.InferInput("input_ids", [1, len(input_ids)], "INT32"), grpcclient.InferInput("input_lengths", [1, 1], "INT32"), ] inputs[0].set_data_from_numpy(np.array([input_ids], dtype=np.int32)) inputs[1].set_data_from_numpy(np.array([[len(input_ids)]], dtype=np.int32)) outputs = [grpcclient.InferRequestedOutput("output_ids")] # 推理 result = self.client.infer( model_name="qwen3-72b", inputs=inputs, outputs=outputs ) output_ids = result.as_numpy("output_ids") # Detokenize return self.tokenizer.decode(output_ids[0]) 性能优化 精度对比 精度 显存 (72B) 吞吐量 质量损失 推荐 GPU FP16 145 GB 3,200 tok/s 0% A100 80GB×2 FP8 75 GB 5,800 tok/s <1% H100/H200 INT4 AWQ 42 GB 4,500 tok/s ~3% 任意 FP4 38 GB 8,500 tok/s ~5% B200 算子融合效果 优化 吞吐量提升 延迟降低 基础（无融合） 基准 基准 QKV 融合 +15% -8% + MLP 融合 +25% -15% + RMSNorm 融合 +30% -20% + Rotary 融合 +35% -22% + 全部融合 +42% -28% 多 GPU 扩展 # 张量并行 + 流水线并行配置 config = trtllm.BuildConfig( tensor_parallel=4, # 4 路张量并行 pipeline_parallel=2, # 2 路流水线并行 # 总共 8 GPU # 专家并行（MoE 模型） moe_config=trtllm.MoEConfig( num_experts=256, expert_parallel_size=8, moe_plugin=True, ), ) 并行策略 GPU 数量 吞吐量 扩展效率 TP=1 1 3,200 100% TP=2 2 5,800 91% TP=4 4 9,500 74% TP=8 8 15,200 59% TP=4+PP=2 8 14,800 58% 与 vLLM 对比 维度 TensorRT-LLM vLLM 峰值性能 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ 部署难度 高 低 模型支持 跟随 NVIDIA 跟随社区 编译时间 10-60 分钟 即时 灵活性 低（AOT） 高（JIT） 跨平台 仅 NVIDIA NVIDIA + AMD 生态 NVIDIA 生态 开源生态 成本 需要 NVIDIA GPU 任意 GPU 适用场景 最适合 极致性能需求：延迟和吞吐量最优 NVIDIA 纯净环境：充分利用 GPU 特性 固定模型部署：AOT 编译换取性能 大规模生产：Triton Server 集群部署 Blackwell 用户：FP4 独家支持 不太适合 快速迭代：每次模型变更需要重新编译 多 GPU 品牌：仅支持 NVIDIA 小团队：部署和调优门槛高 实验性模型：新模型架构支持滞后于 vLLM 成本敏感：需要 NVIDIA GPU 许可 总结 TensorRT-LLM 在 2026 年仍然是"NVIDIA GPU 上最快的推理引擎"。它的 AOT 编译、深度算子融合、FP4/FP8 支持，让它在峰值性能上领先 vLLM 60-100%。这个优势在 Blackwell 架构上更加明显。 ...

大模型推理引擎是 AI 基础设施的核心组件。2026 年，三大推理引擎——vLLM、SGLang、TensorRT-LLM——已形成三足鼎立格局。vLLM 凭借 PagedAttention 开创了高效推理范式，SGLang 以 RadixAttention 和结构化生成突围，TensorRT-LLM 则依托 NVIDIA 的硬件级优化。本文将在相同硬件上对三者进行全方位对比。 一、推理引擎概览 维度 vLLM SGLang TensorRT-LLM 开发者 UC Berkeley LMSYS/UC Berkeley NVIDIA 开源许可 Apache 2.0 Apache 2.0 Apache 2.0 核心技术 PagedAttention RadixAttention + 结构化生成 TensorRT 编译优化 支持模型 几乎所有主流模型 主流模型（覆盖中） 主流模型（覆盖窄） 部署复杂度 低（pip install） 低（pip install） 高（需编译） 社区活跃度 最高 快速增长 中等 二、核心技术解析 2.1 vLLM：PagedAttention vLLM 的核心创新是 PagedAttention——将 KV Cache 按 page 管理，避免显存碎片： 传统推理: KV Cache 连续分配 → 显存碎片 → 利用率 40-60% PagedAttention: KV Cache 分页管理 → 按需分配 → 利用率 90%+ 2026 版本新增： ...