TensorRT-LLM 架构与部署流程

一句话定位：走编译式优化路线的推理加速方案——把模型提前编译成针对特定 GPU 与配置高度特化的 Engine，换取极致性能，代价是编译耗时与灵活性下降。

1. 核心优化手段

• 图优化与算子融合：把多个小算子（如 LayerNorm + 残差、GEMM + 激活、Attention 相关算子）融合成单个 Kernel，减少 Kernel 启动开销与中间结果的 HBM 往返（同 3.7 的思路）。
• Kernel 自动选优（auto-tuning）：针对目标 GPU 架构与具体张量形状，在候选 Kernel 实现中实测挑选最快的一个，并固化进 Engine。
• 量化集成：内置 INT8 / FP8 / INT4（含 SmoothQuant、AWQ 等）支持，与图优化协同（见 4）。
• In-flight Batching：即 Continuous Batching 的实现（3.6），迭代级调度、完成即出队。
• 多 GPU 并行策略封装：内建张量并行（TP）与流水并行（PP）的切分与通信逻辑，用户无需手写 NCCL 通信（见 3.10）。

2. 部署流程

1. 模型转换：把 HuggingFace 等格式的权重转换为 TensorRT-LLM 的模型定义/检查点格式；
2. 构建 Engine：指定精度、最大 batch、最大输入/输出长度、并行策略等，编译生成 .engine 文件。此步会做图优化与 Kernel 选优，耗时较长（数分钟到数十分钟）；
3. 部署运行：加载 Engine 提供服务，生产上常配合 Triton Inference Server（用 Triton 做请求管理、动态批处理、多模型编排与监控）。

3. 代价与取舍

• 编译耗时：每次改模型、改精度、改最大长度或换 GPU 型号，通常都要重新编译；
• 灵活性下降：Engine 与”特定 GPU 架构 + 特定形状约束”绑定，不能像 PyTorch 那样随意改结构、动态调参；超出构建时设定的 max_batch/max_len 需重建。
• 因此选型逻辑很清晰：追求极致吞吐/延迟且模型与配置稳定的生产场景 → TensorRT-LLM；需要快速迭代、频繁换模型 → vLLM 等运行时方案更合适。

参考：NVIDIA TensorRT-LLM 官方文档与 GitHub