4、架构差异：TensorRT与TensorRT-LLM的整体架构对比
核心原理：从“通用优化器”到“大模型专用引擎”
要理解TensorRT与TensorRT-LLM的本质区别，首先需要明确二者的定位。TensorRT是NVIDIA推出的通用深度学习推理优化器，它面向CNN、RNN、Transformer等各类模型，通过层融合、精度校准、内核自动调优等手段，将训练好的模型编译为针对特定GPU高度优化的推理引擎。而TensorRT-LLM则是在TensorRT基础上，专门为大语言模型（LLM）打造的推理框架，它并非简单的“TensorRT的大模型版本”，而是在架构层面引入了大量针对自回归生成、KV Cache、动态形状等LLM特性的专用组件。
从整体架构看，TensorRT采用“模型→图优化→平台适配→可执行引擎”的静态流水线。其核心组件包括：模型解析器（支持ONNX、UFF等格式）、图优化器（执行层融合、精度选择）、TensorRT运行时（负责引擎加载与执行）。引擎一旦编译完成，其计算图结构、内存布局、内核选择均被固定，适合延迟敏感且输入形状相对固定的生产环境。
TensorRT-LLM则采用“模型定义→按需编译→动态批处理→流式生成”的架构。它在底层仍然调用TensorRT的优化能力，但上层构建了完整的LLM推理栈：模型仓库（内置GPT、LLaMA、ChatGLM等主流架构）、注意力优化层（如FlashAttention、PageAttention）、KV Cache管理器、连续动态批处理调度器以及paged KV cache等。这些组件在通用TensorRT中并不存在，因为通用推理不需要管理“生成过程中的历史token缓存”。
方法流程：两种架构下的推理执行路径
在TensorRT中，一次推理的执行路径非常直接：输入张量 → 引擎执行（逐层调用预编译内核）→ 输出张量。整个过程不涉及序列生成、缓存管理或动态调度。开发者需要预先指定最大batch size和输入维度，引擎在编译时据此分配固定大小的显存池。如果实际请求的batch size超过预设值，引擎会直接报错或需要重新编译。
TensorRT-LLM的执行路径则复杂得多，其核心是生成循环（generation loop）。以自回归解码为例，其流程可概括为：
- 请求接入：客户端发送prompt，调度器将其加入等待队列。
- KV Cache分配：为每个请求分配paged KV cache块，记录初始prompt的key-value状态。
- Prefill阶段：一次性处理整个prompt，计算并存储所有token的KV值，生成第一个输出token。
- Decode阶段：每次仅处理一个token，利用上一步的KV cache增量计算，循环直到生成结束符或达到最大长度。
- 动态批处理：调度器在每个解码步骤中，将多个处于decode阶段的请求合并为一个微批（micro-batch），共享GPU计算资源。
- 流式输出：每生成一个token即可通过HTTP/WebSocket推送给客户端，无需等待全部生成完毕。
这种架构差异直接决定了二者的适用场景。TensorRT适合单次前向推理（如目标检测、图像分类），而TensorRT-LLM则针对多轮、流式、高并发的文本生成进行了深度定制。
案例/场景：同一模型在不同架构下的表现差异
假设我们需要部署一个7B参数的LLaMA模型，分别使用TensorRT和TensorRT-LLM进行推理服务。下表展示了关键差异：
| 对比维度 | TensorRT（通用路径） | TensorRT-LLM（专用路径） |
|---|---|---|
| 模型导入方式 | 需先将PyTorch模型导出为ONNX，再转换为TensorRT引擎 | 直接加载HuggingFace格式权重，内部自动完成转换与优化 |
| 动态序列长度 | 不支持，需固定输入长度（如512 token） | 原生支持可变长度，每个请求可独立设置max_new_tokens |
| 批处理策略 | 静态批处理：所有请求必须同时到达，batch size固定 | 连续动态批处理：请求可随时加入/离开，GPU利用率更高 |
| KV Cache管理 | 无此概念，需自行管理历史token的拼接 | 内置paged KV cache，显存利用率提升数倍 |
| 流式输出 | 不支持，必须等完整输出序列生成后一次性返回 | 支持token级流式输出，首token延迟可低至数十毫秒 |
| 多GPU并行 | 需手动切分模型，且不支持张量并行的自动配置 | 内置张量并行/流水线并行，一行配置即可启动多卡推理 |
实际测试中，在相同A100 GPU上部署LLaMA-7B，TensorRT-LLM的吞吐量可达TensorRT通用方案的2~3倍，且显存占用降低约40%。原因在于TensorRT-LLM避免了重复计算历史token的KV值，并通过动态批处理填满了GPU计算间隙。
误区/复盘：常见架构理解偏差
误区一：认为TensorRT-LLM只是TensorRT的“模型库扩展”
实际上，TensorRT-LLM在架构上新增了调度器、KV Cache管理器、生成循环等TensorRT完全没有的组件。即使你将LLM导出为ONNX并用TensorRT编译成功，也无法获得动态批处理、流式输出和paged KV cache等能力。这些功能必须在框架层面实现，而非简单的算子优化。
误区二：忽略“编译期”与“运行期”的职责划分
TensorRT将大量优化放在编译期（如内核选择、内存规划），运行期只做简单执行。而TensorRT-LLM将更多智能放在运行期——调度器需要实时决定哪些请求合并、KV cache如何分配、是否抢占低优先级任务。这种“运行期动态决策”是LLM推理框架的核心设计哲学，也是与通用TensorRT最本质的架构差异。
复盘建议：当你在实际项目中选型时，如果模型是非自回归结构（如BERT、ViT、ResNet），TensorRT足够且更轻量；如果模型是自回归LLM，务必使用TensorRT-LLM。不要试图用TensorRT手动实现KV cache和动态批处理——那将需要重写整个推理循环，且性能远不如专用框架。
从架构演进的角度看，TensorRT-LLM代表了推理框架从“静态图优化”向“动态状态管理”的转变。它不再将模型视为一个固定的计算图，而是视为一个有状态的生成过程，需要同时管理计算资源、缓存资源和请求调度。理解这一架构差异，是正确选型和优化LLM推理性能的前提。