vLLM 与 SGLang 的一切优化都发生在运行时：请求来了再调度、形状变了再适配。TensorRT-LLM 的血统告诉它另一种可能：如果模型、精度、GPU 型号、batch 范围都提前知道，为什么不把每一个 kernel 都提前选到最优？本章讲清这个哲学的收益、代价，以及它在 2025 年的自我修正。

1.1光谱：解释执行 ↔ 编译优化

把推理引擎放在一条光谱上：左端是「灵活通用」——PyTorch eager 逐算子解释执行；右端是「极致特化」——为一个具体 (模型 × 精度 × GPU × 形状范围) 组合生成不可移植的执行计划。vLLM/SGLang 靠 torch.compile 与 CUDA Graph 向右挪了几步（vLLM §4.4）；TensorRT-LLM 出生就在右端：

• 图级优化：整图可见才敢做的激进变换——跨算子融合、常量折叠、内存布局全局规划（层间张量的 NCHW/NHWC 选择、复用缓冲区）。
• kernel 逐形状实测选优（tactic tuning）：同一个 GEMM，cuBLAS、CUTLASS 不同 tile 配置、专用 kernel 谁快？在目标 GPU 上真跑一遍计时，赢家写进执行计划（第 3 章动画）。
• 硬件特性首发：FP8 Transformer Engine、Blackwell 的 FP4 tensor core、TMA——新硬件的软件栈先在 TensorRT 系落地，开源引擎随后跟进。

代价同样清晰：编译要时间（分钟到小时），产物绑定硬件与配置（换 GPU 型号要重编），灵活性受限（新模型结构、动态特性适配慢）。这笔账什么时候划算？部署规模大、模型稳定、追求每一个百分点——几千张卡跑同一个模型时，3% 的吞吐差异就是几十张卡的钱；反之，模型月月换、流量形状飘忽的场景，运行时引擎的敏捷更值钱。

1.2生态栈全图：从 CUDA 到 NIM

1.32025 转身：PyTorch 后端为什么成了默认

纯编译路线有个越来越疼的软肋：模型迭代速度。每个新架构（MLA、MoE 变体、多模态）都要先在 TRT-LLM 的图定义 API 里重写一遍、跑通编译——落后开源社区几周是常态。2025 年 NVIDIA 给出的答案是重构而非坚守：新增 PyTorch 后端（v0.17 起），并在 1.0 版将其提升为默认：

• 模型用 PyTorch module 直接定义——新模型适配速度向 vLLM 看齐，checkpoint 直接加载；
• 性能靠「组装」而非「整图编译」：TRT-LLM 多年积累的手写 kernel（attention、GEMM、量化、通信）以 custom op 形式挂进 PyTorch 图，配合 CUDA Graph 与可选的 torch.compile——放弃整图 tactic 调优，保留 kernel 库的精华；
• 运行时不变：in-flight batching、分页 KV、调度器等 C++ 运行时两条流程共用；传统 TRT engine 流程仍在（第 2 章对照），适合「模型极稳定、榨最后一滴」的场景。

上手体验已与 vLLM 高度接近：pip 装包、几行 Python、一个 OpenAI 兼容 server。差异藏在水面下——你选择的是哪条执行流程。本章把两条流程各跑一遍，建立「什么时候值得走编译那条路」的手感。

2.1安装与 LLM API

shell · 两种安装方式（NGC 容器最省心，CUDA 依赖全打包）

# 方式 A：pip（需本机 CUDA 环境匹配）
pip install tensorrt-llm

# 方式 B：NGC 容器（推荐）
docker run --gpus all --ipc=host -it nvcr.io/nvidia/tensorrt-llm/release

python · LLM API——与 vLLM 的 LLM 类几乎同构

from tensorrt_llm import LLM, SamplingParams

# 默认走 PyTorch 后端：无需构建 engine，直接加载 HF checkpoint
llm = LLM(model="Qwen/Qwen2.5-7B-Instruct")

outs = llm.generate(["用一句话解释 tactic 调优"],
                    SamplingParams(max_tokens=128))
print(outs[0].outputs[0].text)

shell · OpenAI 兼容 server

trtllm-serve Qwen/Qwen2.5-7B-Instruct --port 8000
# 客户端代码与 vLLM/SGLang 完全一致（base_url 指过来即可）

三大引擎的入口 API 已收敛到几乎无差别——这正是第 1 章「互相靠拢」的用户侧体现。差异要到启动日志里找：TRT-LLM 会打印 kernel 库加载、CUDA Graph 捕获与（engine 流程下的）构建/反序列化耗时。

2.2两条流程：PyTorch 后端 vs TRT engine

shell · engine 流程长这样（体验一次即可，感受「编译」的重量）

# 1. 转换 checkpoint 并构建 engine（在目标 GPU 上进行！tactic 是逐卡实测的）
trtllm-build --checkpoint_dir ./qwen_ckpt --output_dir ./engine \
  --max_batch_size 64 --max_input_len 4096 --max_seq_len 8192

# 2. 用 engine 启动（构建参数即运行上限：超出 max_* 的请求直接拒绝）
trtllm-serve ./engine --port 8000

注意 engine 流程把 vLLM 里的「运行时参数」变成了「构建时上限」——max_batch_size / max_input_len 在构建时冻结，运行时只能小于等于。这是编译哲学的直接体现：形状范围越窄，tactic 选得越准，但灵活性也随之交出。

2.3关键参数与 trtllm-bench

shell · trtllm-bench——官方压测三件套（结构同 vllm bench）

trtllm-bench --model Qwen/Qwen2.5-7B-Instruct throughput \
  --dataset ./dataset.jsonl
# 另有 latency 模式与 build 模式（扫构建配置找最优 engine）

动手实验建议：同一模型同一卡，① PyTorch 后端 vs engine 流程各压一次吞吐（预期：engine 略优但差距不大，构建耗时差距巨大）；② engine 流程把 --max_num_tokens 收窄一半再构建，看吞吐变化——体会「形状范围换性能」。压测指标体系与 vLLM §2.5 通用。

本章拆开编译派的心脏。即便你日常只用 PyTorch 后端，理解这套机制也有两重价值：engine 流程仍是极限性能的天花板参照；而 tactic 调优的思想（实测胜过启发式）正在被所有引擎以各种形式吸收。

3.1构建管线：从模型定义到 engine

3.2tactic 调优：让 kernel 赛马

一个 GEMM 在 GPU 上有几十种实现：cuBLAS 的通用版、CUTLASS 的各种 tile/stage 组合、针对特定形状的专用 kernel。启发式选择（按经验规则挑）常有 10%~30% 的误差；TensorRT 的做法简单粗暴——全部拉出来赛马，用秒表说话：

深入：赛马的代价与工程细节

构建时间从哪来：一个 LLM 有几百个算子 × 若干形状档位 × 每档几十个候选 × 每个候选要跑多次取稳定计时——乘起来就是那几十分钟。TensorRT 用 timing cache 缓解：同一形状的实测结果缓存复用，二次构建大幅加速。档位（optimization profile）：动态形状按 min/opt/max 声明范围，调优在 opt 点进行、保证 min~max 可用——范围声明得越窄，opt 点越准。与运行时派的和解：vLLM 的 CUDA Graph 按 batch 档位预录、FlashInfer 的 JIT 按形状编译 kernel，都是「提前为形状特化」的轻量版；TRT-LLM 的 PyTorch 后端反过来放弃全图赛马、只保留手工精选的 kernel 库——两边在中间点会师（第 1 章的判断在机制层的印证）。

3.3plugin：编译器画不出的图

编译器只会优化它认识的算子。attention 这种「带 online softmax 的融合怪」、MoE 路由这种「数据相关控制流」，图优化器既画不出也不敢动——TensorRT 的答案是 plugin 机制：把手写 CUDA kernel 包成黑盒算子插进图里，编译器负责其余部分的优化与衔接。TRT-LLM 本质上就是「一套 LLM 专用 plugin 全家桶」：attention plugin（分页 KV、FMHA）、GEMM/量化 plugin、通信 plugin（AllReduce）。讽刺而合理的是：性能最关键的部分恰恰全在编译器之外——这也解释了为什么 PyTorch 后端能「只带 kernel 库出走」而性能损失有限。

3.4运行时：in-flight batching 与老朋友们

运行时侧你会连续遇到老朋友，只是名字带着 NVIDIA 口音：

• in-flight fused batching = continuous batching（vLLM §3.3），FasterTransformer 时代就有的独立发明，请求逐 step 进出；
• paged KV cache = 分页显存（§3.2），带 KV reuse（块哈希前缀复用）与跨请求共享；
• chunked context = chunked prefill（§3.5）；
• capacity scheduler：调度器带两种守护策略——GUARANTEED_NO_EVICT（保守，绝不因显存抢占已admit的请求）与 MAX_UTILIZATION（激进，装得更满但可能抢占）——相当于把 vLLM 的抢占哲学做成了显式二选一；
• CUDA Graph：decode 按档重放（§4.4），PyTorch 后端的主要提速手段之一。

调度与显存管理的概念体系与 vLLM 完全同构——这正是「先学 vLLM 再学各家」路线的红利：到了 TRT-LLM 你只需要学名词映射表和二选一的策略开关。

量化的算法原理（GPTQ/AWQ 的数学、W/A/KV 三对象）在 vLLM 指南 §4.2 已经讲透。本章讲 TRT-LLM 侧的增量：官方工具链 ModelOpt、硬件原生格式的独家首发位，以及「量化 × 编译」的化学反应——新 tensor core 格式的收益，从来都是先在这里兑现。

4.1ModelOpt：量化的官方流水线

TensorRT Model Optimizer（nvidia-modelopt）是 NVIDIA 的统一模型优化库：量化（PTQ/QAT）、蒸馏、剪枝、投机头训练，一套 API 出多种格式。地位相当于 vLLM 生态的 llm-compressor，但覆盖格式更靠硬件前沿：

import modelopt.torch.quantization as mtq

# 校准 + 量化：一行换格式（FP8 / NVFP4 / INT4_AWQ / W4A8…）
model = mtq.quantize(model, mtq.NVFP4_DEFAULT_CFG, forward_loop=calib)
# 导出的 checkpoint 可直接被 TRT-LLM / vLLM / SGLang 加载 ——
# ModelOpt 是三家共用的上游，这正是「量化生态在收敛」的证据

值得注意的行业事实：HuggingFace 上大量 FP8/FP4 官方量化 checkpoint（含 DeepSeek、Llama 系）由 ModelOpt 产出，vLLM 与 SGLang 都能加载——工具链在上游统一，引擎在下游竞争 kernel 质量。验收方法学（任务指标 + 业务样本，勿只看困惑度）与 vLLM §4.2.3 完全通用。

4.2硬件量化阶梯：FP8 → NVFP4

选型速查（按卡型）：Ampere（A100/A10）→ INT8 SmoothQuant / INT4-AWQ；Hopper（H100/H200）→ FP8 默认、W4A8 进阶；Blackwell（B200/GB200）→ NVFP4。每档都记得叠 KV cache 量化（FP8）。与 vLLM 的差异不在格式清单（两边高度重合），而在新格式的落地时差——Blackwell 特性在 TRT-LLM 里成熟得最早，开源引擎通常晚一到两个季度追平。

4.3投机解码与其余加速件

原理全在 vLLM §4.1；TRT-LLM 的菜单差异：

• 草稿谱系最全的一家：独立 draft 模型（TRT-LLM 保留了这条 vLLM V1 放弃的路线）、EAGLE-3、Medusa、lookahead decoding，以及 ReDrafter（Apple 提出的 RNN 草稿头方案，TRT-LLM 是其主要落地）。
• 与编译的化学反应：engine 流程下草稿与验证的形状提前已知，tactic 可为「一次验证 k 个 token」的批形状专门调优——投机的「验证几乎免费」在编译派手里更接近字面意义。
• 其余清单：多 LoRA、结构化输出（guided decoding，接 xgrammar）、KV cache 卸载（GPU→CPU 分层，同 HiCache/LMCache 思路）——三家功能面持续趋同，差异看成熟度与文档。

TRT-LLM 的部署故事围绕规模展开：单机用 trtllm-serve，企业多模型用 Triton Server，数据中心级 PD 分离交给 Dynamo。源码则是 Python/C++ 混合体——读码策略必须先想清楚「读到哪层为止」。

5.1三种部署形态与多机多卡

多机多卡（MGMN）：TP/PP/EP 概念与通信账同 vLLM §6.2；TRT-LLM 用 MPI（mpirun/srun）拉起多进程，GB200 NVL72 这类 72 卡 NVLink 域上的 wide-EP 部署是它的主场——NVIDIA 自家硬件的参考实现总是最先出现在这里。PD 分离由 Dynamo 编排（KV 传输走 NIXL，与 vLLM/SGLang 同一套底层库——§6.3 的知识全部复用）。

深入：Dynamo 值得单独说两句

2025 年发布的 Dynamo 是 NVIDIA 对「编排层」的回答：Rust 写的数据面（低开销路由、KV 感知调度）+ Python 写的控制面，内置 PD 分离、KV cache 卸载管理（NIXL/对象存储分层）、按 SLO 的动态 P:D 配比。两个关键定位：① 引擎无关——后端可以是 TRT-LLM，也可以是 vLLM 或 SGLang（NVIDIA 想赢的是编排层与硬件，不押注单一引擎）；② 与 llm-d（K8s 原生、vLLM 社区主导）构成编排层的两强竞争。学习价值：读它的架构文档，能看到「集群级 KV 管理」这个新战场的完整问题清单——单机引擎的下一层楼。

5.2源码地图与读码策略

读码策略（与 vLLM/SGLang 不同之处）：这是个 Python 壳 + C++ 核的项目，「跟一条请求走到底」会在 Python/C++ 边界折返跑。务实的分层法：① 把 Python 层读通（llmapi → _torch 执行器）——足以理解架构与做应用层贡献；② C++ 的 batch_manager 用「带着 vLLM 调度器的心智模型对照读」——概念一一对应（vLLM §5.4 的伪代码在这里依然是地图）；③ kernels 目录仅在做性能工作时深入。指望像读 SGLang 那样两周通读全库是不现实的，设定读到哪层为止，是读这个库的第一决策。

5.3许可、社区与如何跟进

• 许可结构：TRT-LLM 本体 Apache 2.0，但依赖闭源的 TensorRT 二进制，部分 kernel 以预编译 cubin 分发——「开源但不完全开放」，商业使用无碍，深度定制受限于闭源边界。
• 社区形态：NVIDIA 主导开发，路线图不像 vLLM/SGLang 那样公开共治；issue 响应质量高但合入外部大改动的门槛也高。把它当「可读源码的商业产品」预期最准。
• 跟进节奏：官方文档 + release notes + NVIDIA 技术博客（新硬件的性能白皮书都先发那里）；版本已进入 1.x，NGC 容器按月滚动。

官方文档与代码

与其他指南共用的基础

推理物理、分页 KV、continuous batching、量化算法、投机原理、并行通信账——见 vLLM 指南；运行时调度的另一种做法见 SGLang 指南。建议闭环：学完本指南后重读 vLLM §4.4（CUDA Graph 与编译），你会对「运行时派向编译派借了什么」有全新体感。

术语表

正文里带虚线下划线的词可悬停查看解释；此处为本指南新增术语（与其他指南共用的术语见各自附录）。