课程导入：学习目标、课程大纲、TensorRT与TensorRT-LLM的定位与关系

1.1 本节学习目标与课程地图

在正式进入技术细节之前，我们首先需要建立一张清晰的认知地图。很多开发者初次接触 TensorRT 与 TensorRT-LLM 时，最常犯的错误是将两者视为“新老版本”或“替代关系”，但实际上它们是面向不同推理场景、不同抽象层级、不同优化粒度的两套独立工具链。本节的核心目标有三个：第一，明确两者的定位差异与协作方式；第二，建立课程的整体知识框架，让后续每一章的内容都能挂载到正确的认知节点上；第三，通过一个贯穿全课程的真实案例场景，帮助你在头脑中形成“何时用谁、如何衔接”的决策直觉。

下表列出了本课程 30 章的整体结构，你可以将其视为后续学习的索引。每一章都会围绕一个核心问题展开，并配有可运行的示例或对比实验。

模块 章节范围 核心主题
基础认知 第1-4章 定位差异、编译流程、IR与图优化、引擎序列化
TensorRT 深度 第5-12章 层融合、精度校准、动态形状、插件机制、DLA、性能分析
TensorRT-LLM 深度 第13-22章 KV Cache、PagedAttention、In-flight Batching、量化、多卡并行、模型仓库
工程落地与对比 第23-28章 延迟/吞吐基准、显存剖析、容器化部署、vLLM对比、故障排查
综合实战 第29-30章 端到端案例复盘、选型决策框架

1.2 核心原理：从“通用优化器”到“大语言模型专用推理栈”

要理解两者的本质差异，需要先看它们各自解决的问题域。TensorRT 是 NVIDIA 推出的通用深度学习推理优化器，它接收训练好的模型（如 ONNX、PyTorch 导出的权重），通过层融合、精度校准、内核自动调优等手段，生成针对特定 GPU 架构高度优化的推理引擎。它不关心模型是 CNN、Transformer 还是其他结构，它只关心计算图如何被更高效地映射到硬件指令上。

TensorRT-LLM 则完全不同。它并非从零构建的推理框架，而是在 TensorRT 之上构建的大语言模型专用推理栈。它内置了针对 Transformer 解码器结构的预定义模块（如 Attention、MLP、RMSNorm），并实现了 LLM 推理特有的运行时优化：KV Cache 管理、PagedAttention 显存调度、连续请求的 In-flight Batching、张量并行与流水线并行策略等。你可以将 TensorRT-LLM 理解为“为 LLM 量身定制的推理操作系统”，而 TensorRT 则是其底层的“汇编器与指令调度器”。

下图展示了从训练模型到最终线上服务的完整链路中，两者所处的层级与协作关系。左侧是传统 TensorRT 路径，右侧是 TensorRT-LLM 路径，中间是共享的底层硬件与驱动层。

训练模型 (ONNX / HF权重) TensorRT (通用优化器) 图优化 · 层融合 · 精度校准 · 内核调优 TensorRT 引擎 (.engine / .plan) 序列化后的优化计算图 + 内核选择 通用推理运行时 (TensorRT API) 适合 CNN / 传统模型 / 固定batch TensorRT-LLM (LLM专用栈) 内置 Transformer 模块 · KV Cache · 连续请求调度 LLM 引擎 (GPT / LLaMA / Mistral等) 支持 PagedAttention · In-flight Batching LLM 推理服务 (TensorRT-LLM Runtime) 支持流式输出 · 多卡并行 · 动态batch CUDA / cuDNN / cuBLAS 底层算子库与驱动 NVIDIA GPU (Hopper / Ada / Ampere) TensorRT-LLM 底层调用 TensorRT 构建引擎 左侧：传统 TensorRT 路径（通用） · 右侧：TensorRT-LLM 路径（LLM 专用） · 两者共享底层 CUDA 生态

从上图可以清晰看到，TensorRT-LLM 并不是替代 TensorRT，而是在 TensorRT 之上叠加了一层 LLM 专用的“智能调度层”。在实际部署中，TensorRT-LLM 会调用 TensorRT 的 API 来构建底层计算图引擎，但它的核心价值在于那些 TensorRT 本身不具备的 LLM 运行时特性——比如动态管理 KV Cache 的显存池、在请求级别进行调度而非 batch 级别、以及针对不同 LLM 架构的预置优化模板。

1.3 方法流程：一个典型 LLM 部署决策路径

为了让你更直观地理解两者的分工，我们来看一个典型的部署决策流程。假设你训练了一个 7B 参数的对话模型，需要上线服务。你会经历以下步骤：

  1. 模型准备：将 HuggingFace 格式的权重导出为 TensorRT-LLM 支持的格式（通常是 safetensors 或直接使用其内置的模型定义）。
  2. 构建引擎：调用 TensorRT-LLM 的 trtllm-build 命令，它会自动调用 TensorRT 的编译器，生成针对你 GPU 型号优化的引擎文件。此时你可以指定量化方式（如 FP8、INT4-AWQ）、张量并行度等参数。
  3. 运行时配置：启动 TensorRT-LLM 的 Python 或 C++ 运行时，配置 KV Cache 大小、最大序列长度、是否启用 In-flight Batching 等。
  4. 服务暴露：通过 OpenAI 兼容的 HTTP 接口或 gRPC 提供服务。

在这个过程中，TensorRT 负责“把计算图变成高效的 GPU 指令”，而 TensorRT-LLM 负责“让这些指令在服务海量并发请求时依然保持高吞吐和低延迟”。如果你只使用 TensorRT 而不使用 TensorRT-LLM，你将不得不自己实现 KV Cache 管理、动态 batch 调度等复杂逻辑——这正是两者最大的分工差异。

经验提示：如果你部署的是 CNN、BERT 编码器、或固定 batch 的推理服务，使用原生 TensorRT 往往更轻量、更直接。但如果你面对的是 自回归生成模型（GPT、LLaMA 等），且需要处理动态长度的请求、流式输出、高并发，那么 TensorRT-LLM 是更合适的选择。判断标准不是“哪个更新”，而是“你的模型是否具有自回归解码的循环结构”。

1.4 案例场景：同一模型，两种部署方式的对比

我们用一个具体的量化对比来加深理解。假设你有一个 FP16 的 LLaMA-7B 模型，显存占用约 14GB（权重）+ KV Cache 动态分配。下表展示了两种部署路径的典型差异：

对比维度 原生 TensorRT 部署 TensorRT-LLM 部署
需要手写 KV Cache 管理 是（需自行实现） 否（内置 PagedAttention）
动态 batch 支持 需通过插件或外部调度 原生支持 In-flight Batching
多卡张量并行 需手动切分权重并编写通信逻辑 一行配置 --tensor_parallel_size=2
流式输出 token-by-token 需自己管理生成循环 内置 streaming 接口
量化支持（FP8/INT4） 需额外使用 TensorRT 量化工具包 内置多种量化方案，直接指定

从这个对比可以看出，TensorRT-LLM 将 LLM 推理中“通用但繁琐”的部分（显存管理、调度、并行）全部封装好了，让你专注于模型本身和业务逻辑。而原生 TensorRT 则更像一块“白板”，适合对底层控制有极致需求的场景，但代价是需要自己实现大量 LLM 特有的运行时逻辑。

1.5 误区与复盘：最常见的三个认知偏差

在课程开始阶段，我们先纠正几个高频误区，避免你在后续学习中走弯路。

误区一：认为 TensorRT-LLM 是 TensorRT 的“升级版”。
事实：两者是不同层级的工具。TensorRT-LLM 依赖 TensorRT 作为底层编译器，但它的核心价值在上层调度逻辑。你无法用 TensorRT-LLM 去优化一个普通的 CNN 分类模型——它只接受 Transformer 解码器结构的模型。
误区二：认为 TensorRT-LLM 只能用于 NVIDIA 官方支持的模型架构。
事实：虽然官方预置了 LLaMA、GPT、Mistral、Falcon 等常见架构，但你可以通过继承基类实现自定义模型。不过，这需要你对 TensorRT-LLM 的内部抽象（如 Attention、GatedMLP）有较深理解，建议先掌握标准用法后再尝试扩展。
误区三：忽略“构建引擎”与“运行时”的区分。
事实：TensorRT-LLM 的构建阶段（trtllm-build）和运行阶段（TensorRT-LLM Runtime）是分离的。构建阶段生成引擎文件，运行阶段加载引擎并处理请求。很多初学者混淆两者，导致在运行时修改量化参数却发现不生效——因为量化参数在构建时已经固化到引擎中了。

复盘一下：如果你现在被问到“我的公司有一个基于 BERT 的文本分类模型，需要低延迟推理，应该选哪个？”，答案应该是原生 TensorRT，因为 BERT 编码器没有自回归循环，TensorRT-LLM 的调度优势无法发挥。而如果是一个对话机器人，需要处理多轮上下文和动态长度，那么 TensorRT-LLM 是更合适的选择。这个判断逻辑将贯穿整个课程。

← 上一章 📖 返回目录 下一章 →