TensorRT-LLM 优化：精通 NVIDIA 推理技术栈

更新于 2025 年 12 月 11 日

2025 年 12 月更新： TensorRT-LLM 在 H100 上使用 FP8 实现 10,000+ 输出 tokens/秒，首 token 延迟低于 100ms。生产部署报告吞吐量比原生 PyTorch 提升 4 倍。内核融合将 LayerNorm、矩阵乘法、激活函数合并为单个 CUDA 内核。Inflight batching 最大化 GPU 利用率。Hopper/Blackwell 上的 FP8 注意力机制带来额外加速。

NVIDIA 的 TensorRT-LLM 提供了其他方案难以匹敌的原始推理性能。在使用 FP8 精度的 H100 GPU 上，该框架在峰值吞吐量时实现每秒超过 10,000 个输出 token，首 token 延迟低于 100 毫秒。¹ 生产部署报告相比原生 PyTorch 推理吞吐量提升高达 4 倍。这种性能是有代价的：TensorRT-LLM 比 vLLM 等用户友好的替代方案需要更多配置专业知识和更长的优化周期。

对于坚定使用 NVIDIA 硬件并愿意投入工程时间进行优化的组织来说，TensorRT-LLM 能够从昂贵的 GPU 基础设施中榨取最大性能。理解该框架的架构、量化选项和调优参数，使团队能够构建通过卓越的 token 经济性来证明高端硬件投资合理性的推理系统。

架构与核心优化

TensorRT-LLM 构建于 NVIDIA 的 TensorRT 推理优化器之上，通过 transformer 专用优化扩展了编译框架。该库提供用于模型定义的 Python API 以及用于生产部署的 C++ 运行时组件。

内核融合： TensorRT-LLM 将多个 transformer 操作合并为单个优化的 CUDA 内核。LayerNorm、矩阵乘法、偏置加法和激活函数一起执行，而不需要单独的内核启动和内存传输。融合减少了内核启动开销并消除了中间张量的实体化。²

自定义注意力内核： 手工优化的多头注意力和分组查询注意力实现利用 Tensor Core 指令实现最大吞吐量。Flash Attention 变体在保持数值精度的同时减少内存带宽需求。Hopper 和 Blackwell GPU 上的 FP8 注意力内核提供额外加速。

Inflight batching： 传统的静态批处理强制批次中的所有请求等待最长序列完成。Inflight batching 在每个生成步骤将新请求添加到运行中的批次，同时处理上下文和生成阶段。³ 这种方法通过在单个请求完成时保持计算单元忙碌来最大化 GPU 利用率。

分页 KV 缓存： 受操作系统虚拟内存启发，分页注意力以非连续块分配 KV 缓存，而不是需要连续的内存区域。⁴ 块级分配使具有公共前缀的请求能够共享 KV 缓存，并实现接近零的内部碎片内存浪费。

性能对比：TensorRT-LLM vs vLLM

两个框架都针对生产级 LLM 推理，但架构差异创造了不同的性能特征：

TensorRT-LLM 在默认配置下持续优于 vLLM，在短序列上提供 1.34 倍的吞吐量提升，在长序列上提供 2.72 倍更好的每输出 token 时间。⁵ 在 B200 GPU 上，TensorRT-LLM 对 Blackwell 架构的深度优化进一步扩大了性能差距。

vLLM 在开发者体验方面具有优势：⁶ - OpenAI 兼容 API，可直接替换 - 无需编译步骤，部署更简单 - 自动模型优化，默认配置合理 - 更广泛的硬件支持，不局限于 NVIDIA GPU

建议： 当最大化硬件效率足以证明工程投入合理时，部署 TensorRT-LLM。当需要更快上线或在较小规模运营（绝对性能不如开发速度重要）时，选择 vLLM。

量化策略

TensorRT-LLM 支持广泛的量化选项，以在精度与性能和内存效率之间进行权衡。选择正确的量化方法取决于批次大小、精度要求和目标硬件。

FP8 量化（推荐首选）

FP8 在性能提升和精度损失最小化之间提供最佳平衡：⁷

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat fp8 \
    --kv_cache_dtype fp8 \
    --output_dir $OUTPUT_PATH

FP8 量化需要校准以确定适当的缩放因子。校准过程在代表性样本上运行推理以测量激活范围：

from tensorrt_llm.quantization import QuantConfig, CalibConfig

quant_config = QuantConfig(
    quant_algo="fp8",
    kv_cache_quant_algo="fp8"
)

calib_config = CalibConfig(
    calib_dataset="cnn_dailymail",
    calib_batch_size=8,
    calib_num_samples=512
)

FP8 提供中等性能提升，精度影响非常小，只需几分钟即可完成校准。Hopper 和 Blackwell GPU 提供硬件 FP8 支持；Ada GPU 支持 FP8 但效率较低。

INT4 AWQ 用于内存受限部署

当内存限制模型大小时，INT4 激活感知权重量化将权重压缩到 4 位，同时保持可接受的精度：⁸

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat int4_awq \
    --awq_block_size 64 \
    --tp_size 4 \
    --output_dir $OUTPUT_PATH

INT4 AWQ 在小批次场景（批次大小 ≤ 4）中表现出色，此时推理变为内存受限。权重加载时间主导计算，因此激进的权重压缩提供显著加速。对于大批次，随着计算密度增加，INT4 AWQ 的性能优势会减弱。

INT8 SmoothQuant 用于平衡优化

SmoothQuant 将量化难度从激活转移到权重，实现有效的 INT8 量化而不会显著损失精度：

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat int8_sq \
    --kv_cache_dtype int8 \
    --output_dir $OUTPUT_PATH

INT8 SmoothQuant 提供中等性能提升和中等精度影响。组织应首先尝试 FP8，如果 FP8 结果不满足要求再回退到 INT8 SQ。

量化选择框架

NVIDIA 推荐以下优先级顺序：⁹

1. FP8 - 最佳性能/精度权衡，需要 Hopper/Blackwell
2. INT8 SmoothQuant - Ada GPU 或 FP8 精度不足时的良好替代方案
3. INT4 AWQ/GPTQ - 内存受限场景的最大压缩

对于 KV 缓存，由于在大多数情况下精度影响较低，Hopper 和 Ada GPU 上推荐 FP8 量化而非 INT8。

生产部署配置

最优的 TensorRT-LLM 部署需要根据工作负载特性调优多个参数：

引擎构建配置

trtllm-build \
    --checkpoint_dir $CHECKPOINT_PATH \
    --output_dir $ENGINE_PATH \
    --max_batch_size 256 \
    --max_num_tokens 8192 \
    --max_input_len 4096 \
    --max_seq_len 8192 \
    --gemm_plugin auto \
    --use_paged_context_fmha enable \
    --workers 8

max_batch_size： 最新版本默认为 256。实现最大吞吐量的生产部署通常增加到 2048，充分利用 inflight batching 能力。¹⁰

max_num_tokens： 控制每批次迭代处理的总 token 数。默认 8192 在吞吐量和内存消耗之间取得平衡。内存受限部署可减少此值；增加时需谨慎监控。

use_paged_context_fmha： 启用分页注意力以实现高效的 KV 缓存管理。使用 inflight batching 时必需。该实现预分配 KV 缓存内存，大约需要比模型权重多 60% 的 VRAM。¹¹

Triton Inference Server 集成

生产部署通常使用带有 TensorRT-LLM 后端的 NVIDIA Triton Inference Server：

model_repository/
└── llama-70b/
    ├── 1/
    │   └── model.py
    ├── config.pbtxt
    └── tensorrt_llm/
        └── 1/
            ├── config.json
            └── engine/

Triton 提供多模型编排、请求队列、指标收集和 Kubernetes 原生扩展。预构建的 NGC 容器包含启用了 inflight batching 和分页 KV 缓存支持的 TensorRT-LLM 后端。

内存规划

部署前估算内存需求：

总 VRAM = 模型权重 + KV 缓存 + 激活内存 + 运行时开销

模型权重 (FP8)：参数数 × 1 字节
模型权重 (INT4)：参数数 × 0.5 字节
KV 缓存：batch_size × seq_len × num_layers × 2 × hidden_dim × precision_bytes

FP8 下的 70B 参数模型大约需要： - 权重：70GB - KV 缓存（批次 256，序列 8192）：~120GB - 激活 + 开销：~30GB - 总计：~220GB（3 块 H100 80GB 或 2 块 H200 141GB）

性能调优工作流程

系统化优化可从 TensorRT-LLM 部署中提取最大性能：

第一阶段：基准测量

使用 trtllm-bench 进行快速性能评估：

python -m tensorrt_llm.bench \
    --model_dir $ENGINE_PATH \
    --input_len 512 \
    --output_len 256 \
    --batch_size 32 \
    --num_requests 1000

基准测试工具自动设置最优引擎参数，无需完整的 Triton 部署复杂性即可提供基准性能。¹²

第二阶段：量化选择

首先针对精度要求测试 FP8。如果精度下降超出可接受阈值，评估 INT8 SQ 或 INT4 AWQ。在代表性任务上运行评估基准，而不仅仅是困惑度测量。

第三阶段：批次大小优化

在从 1 到 max_batch_size 的批次大小范围内分析吞吐量。识别吞吐量曲线的拐点，即额外批处理提供递减回报的位置。将 max_batch_size 设置为该点以上 20-30%，以应对流量峰值。

第四阶段：KV 缓存调优

在生产工作负载期间监控 KV 缓存利用率。如果利用率持续超过 80%，增加 max_num_tokens 或减少 max_batch_size。如果利用率保持在 50% 以下，减少分配以释放内存用于更大批次。

第五阶段：持续监控

在生产中跟踪关键指标： - 每秒 token 数（吞吐量） - 首 token 延迟（延迟） - 队列深度（容量） - KV 缓存利用率（内存） - GPU 利用率（效率）

高级优化

推测解码

TensorRT-LLM 支持使用较小的草稿模型进行推测解码，预测多个 token 由主模型验证。该技术为兼容的工作负载提供 1.5-2 倍加速：

# 在引擎构建中启用推测解码
trtllm-build \
    --speculative_decoding_mode draft_tokens_external \
    --max_draft_len 5 \
    ...

推测解码有利于延迟敏感型应用，这类应用中完成时间比吞吐量更重要。该优化需要在内存中同时维护草稿模型和目标模型。

多 GPU 配置

TensorRT-LLM 支持张量并行（TP）、流水线并行（PP）和专家并行（EP）进行分布式推理：

# 4 路张量并行
trtllm-build \
    --tp_size 4 \
    --pp_size 1 \
    ...

TP 将每一层分割到多个 GPU 上，需要在每层边界进行 all-reduce 操作。PP 将层以流水线阶段分割到多个 GPU 上。对于推理，TP 通常提供更好的延迟，而 PP 则能够实现

[内容因翻译需要被截断]