🔥 【推理与部署篇04】TensorRT-LLM完整指南：编译优化与NVFP4量化

2026年最新版 | 覆盖 TensorRT-LLM v0.18+ | NVIDIA 官方推理引擎深度解析

📑 目录

TensorRT-LLM架构与设计哲学

[2. 编译优化管线：从PyTorch到TRT引擎](#2. 编译优化管线：从PyTorch到TRT引擎)

In-flight Batching调度机制
量化方案全景：FP8/FP4/INT4/NVFP4
Plugin架构与内核融合
分布式推理：TP/PP/EP
性能基准测试
生产部署最佳实践
Triton推理服务器集成
vLLM vs TensorRT-LLM vs SGLang选型

面试加分点

TensorRT-LLM架构与设计哲学
1.1 什么是TensorRT-LLM？
TensorRT-LLM 是 NVIDIA 官方基于 TensorRT 构建的高性能大语言模型推理引擎，专为充分释放 NVIDIA GPU（从 Turing 到 Blackwell）的算力潜力而设计。与 vLLM/SGLang 的"Python 运行时"架构不同，TensorRT-LLM 采用预编译引擎模式，将模型离线编译为高度优化的 CUDA 内核，运行时无需 PyTorch 依赖 $1$ 。

截至2026年，TensorRT-LLM GitHub Stars 突破 30K，是 NVIDIA 官方推荐的生产级 LLM 部署方案，支撑了包括 DeepSeek、xAI、Meta 等企业的大规模推理集群。

1.2 架构总览

┌──────────────────────────────────────────────────────────┐

│ TensorRT-LLM 架构 │

├──────────────────────────────────────────────────────────┤

│ 离线编译阶段 │

│ ┌──────────┐ ┌──────────────┐ ┌──────────────────┐ │

│ │ PyTorch │ → │ ModelOpt │ → │ TRT Engine Build │ │

│ │ 模型权重 │ │ 量化/剪枝 │ │ 内核融合/图优化 │ │

│ └──────────┘ └──────────────┘ └────────┬─────────┘ │

├──────────────────────────────────────────────┼───────────┤

│ 运行时阶段 │ │

│ ▼ │

│ ┌──────────────────────────────────────────────────────┐│

│ │ TensorRT-LLM Runtime ││

│ │ ┌─────────────┐ ┌──────────┐ ┌──────────────────┐ ││

│ │ │ In-flight │ │ Paged KV │ │ Plugin Kernels │ ││

│ │ │ Batching │ │ Cache │ │ (FlashAttn/MoE) │ ││

│ │ └─────────────┘ └──────────┘ └──────────────────┘ ││

│ │ ┌─────────────┐ ┌──────────┐ ┌──────────────────┐ ││

│ │ │ Speculative │ │ CUDA │ │ Tensor/Pipeline │ ││

│ │ │ Decoding │ │ Graphs │ │ Parallel │ ││

│ │ └─────────────┘ └──────────┘ └──────────────────┘ ││

│ └──────────────────────────────────────────────────────┘│

└──────────────────────────────────────────────────────────┘

1.3 设计哲学

维度 vLLM / SGLang TensorRT-LLM

编译策略 JIT（即时编译） AOT（提前编译）

运行时依赖 PyTorch 全家桶仅 CUDA + TensorRT

模型加载直接加载 HF 权重需转换为 TRT 引擎

冷启动时间秒级分钟级（编译耗时）

推理速度优秀极致（+15~30%）

硬件兼容 NVIDIA/AMD/Intel 仅 NVIDIA

灵活性高（可动态修改）低（需重新编译）

核心设计理念："编译一次，运行千次"------将计算图优化、内核融合、内存布局等耗时工作前置到离线阶段，运行时只做最纯粹的推理。

编译优化管线：从PyTorch到TRT引擎
2.1 完整编译流水线

PyTorch 模型权重 (.safetensors/.bin)

│

▼

┌─────────────────────────────────┐

│ Step 1: 模型转换 │

│ convert_checkpoint.py │

│ ├── 加载 HF 权重 │

│ ├── 权重格式转换 (FP16/BF16/FP8) │

│ ├── 量化校准 (ModelOpt) │

│ └── 输出: TRT-LLM checkpoint │

└─────────────────────────────────┘

│

▼

┌─────────────────────────────────┐

│ Step 2: 引擎构建 │

│ trtllm-build │

│ ├── 计算图优化 │

│ ├── 内核自动融合 │

│ ├── 内存布局优化 │

│ ├── Plugin 注册 │

│ └── 输出: .engine 文件 │

└─────────────────────────────────┘

│

▼

┌─────────────────────────────────┐

│ Step 3: 运行时加载 │

│ ModelRunner.from_dir() │

│ ├── 加载 .engine │

│ ├── 初始化 KV Cache │

│ └── 就绪推理 │

└─────────────────────────────────┘

2.2 Step 1：模型转换

安装 TensorRT-LLM

pip install tensorrt_llm -U

转换为 TRT-LLM 格式（以 LLaMA 4 为例）

python convert_checkpoint.py

--model_dir ./Meta-Llama-4-70B

--output_dir ./trt_llama4_fp8

--dtype float16

--use_weight_only

--weight_only_precision fp8

--calib_dataset ./calib_data # 量化校准数据集

关键参数说明：

--dtype: 模型精度 (float16/bfloat16/float32)

--use_weight_only: 启用权重量化

--weight_only_precision: 量化精度 (fp8/int8/int4)

--calib_dataset: FP8 量化校准数据路径

2.3 Step 2：引擎构建

构建 TRT 引擎

trtllm-build

--checkpoint_dir ./trt_llama4_fp8

--output_dir ./engine

--gemm_plugin float16

--gpt_attention_plugin float16

--context_fmha enable

--max_batch_size 256

--max_input_len 16384

--max_output_len 4096

--max_num_tokens 65536

--use_paged_context_fmha enable

--paged_kv_cache enable

--tokens_per_block 64

--remove_input_padding enable

--multiple_profiles enable

参数详解：

--gemm_plugin: 全连接层插件精度

--gpt_attention_plugin: 注意力层插件精度

--context_fmha: 启用上下文 Flash Multi-Head Attention

--use_paged_context_fmha: 启用 Paged Context FMHA

--max_batch_size: 最大批处理大小

--max_input_len / --max_output_len: 输入/输出最大长度

--max_num_tokens: 单批次最大 token 数

--paged_kv_cache: 启用分页 KV 缓存

--tokens_per_block: 每块 token 数（类似 vLLM 页面大小）

--multiple_profiles: 多 profile 优化（兼容不同序列长度）

2.4 Step 3：运行时推理

import tensorrt_llm

from tensorrt_llm.runtime import ModelRunner

加载预编译引擎

runner = ModelRunner.from_dir(

engine_dir="./engine",

rank=0, # 张量并行 rank

tensor_parallel_size=1 # TP 大小

)

构建推理请求

output_ids = runner.generate(

batch_input_ids= $\[101, 234, 567, ...$ ], # tokenized input

max_new_tokens=1024,

end_id=2, # EOS token id

pad_id=0, # PAD token id

temperature=0.7,

top_p=0.9,

top_k=50,

beam_width=1,

output_sequence_lengths=True,

return_dict=True

)

print(output_ids $'output_ids'$ )

2.5 引擎构建优化秘籍

1. 多 Profile 优化（推荐生产用）

trtllm-build

--multiple_profiles enable

--profiles_min_bs 1 --profiles_max_bs 256

--profiles_min_seq_len 128 --profiles_max_seq_len 32768

2. 动态 shape 优化（处理变长请求）

trtllm-build

--opt_num_tokens 4096 \ # 最常出现的 token 数

--min_num_tokens 128

--max_num_tokens 65536

--multiple_profiles enable

3. 内存使用控制（大模型专用）

trtllm-build

--max_num_tokens 32768

--workspace_size 8589934592 \ # 8GB workspace

--enable_debug_output \ # 调试用

--builder_opt 3 # 优化等级 0-5

In-flight Batching调度机制

3.1 问题：静态Batching的局限

传统静态批处理中，一个 batch 必须等待所有请求生成完毕才能退出：

静态批处理:

批次1: $请求A 50tok$ $请求B 200tok$ $请求C 500tok$

↓ 等待最慢的 C 完成

████████████████████████████████████████

↑ A 和 B 完成却干等 ↑ 大量 GPU 空闲 ❌

3.2 In-flight Batching原理

TensorRT-LLM 的 In-flight Batching（飞行批处理 / 动态批处理）允许在批次运行时动态插入和移除请求 $2$ ：

class InflightBatcher:

"""

TensorRT-LLM In-flight Batching 调度器

允许请求在批次运行过程中动态加入/离开

"""

def init (self, max_batch_size: int = 256):

self.max_batch_size = max_batch_size

self.active_requests = {} # 活跃请求: req_id -> RequestState

self.waiting_queue = \[\] # 等待队列

self.completed = \[\] # 已完成请求

self.running_batch = None # 当前 GPU 批次

class RequestState:

def init (self, input_ids, max_tokens, req_id):

self.req_id = req_id

self.input_ids = input_ids # 输入 token 序列

self.generated = \[\] # 已生成的 token

self.max_tokens = max_tokens # 最大生成长度

self.state = "prefill" # prefill | decode | done

self.prefill_done = False

self.seq_len = len(input_ids)

def submit(self, input_ids, max_tokens):

"""提交新请求"""

req_id = uuid.uuid4().hex

req = self.RequestState(input_ids, max_tokens, req_id)

if len(self.active_requests) < self.max_batch_size:

self.active_requests $req_id$ = req

else:

self.waiting_queue.append(req)

return req_id

def build_batch(self):

"""

构建下一批次：

从活跃请求中选择可继续解码的
从等待队列补充新请求（如果 batch 未满）

"""

batch = \[\]

Step 1: 仍在解码中的活跃请求

for req in list(self.active_requests.values()):

if req.state == "decode":

batch.append(req)

elif req.state == "done":

self._finish_request(req)

Step 2: 如果 batch 未满，从等待队列补充

while len(batch) < self.max_batch_size and self.waiting_queue:

new_req = self.waiting_queue.pop(0)

self.active_requests $new_req.req_id$ = new_req

batch.append(new_req)

return batch

def on_batch_complete(self, batch_results):

"""

批次完成后回调

标记完成/未完成的请求，更新状态

"""

for result in batch_results:

req = self.active_requests $result.req_id$

if result.finished:

req.state = "done"

self.completed.append({

"req_id": req.req_id,

"output": req.generated + $result.token$ ,

"seq_len": req.seq_len + len(req.generated) + 1

})

else:

继续解码

req.generated.append(result.token)

req.state = "decode"

def _finish_request(self, req):

"""清理已完成的请求"""

del self.active_requests $req.req_id$

def get_stats(self):

return {

"active": len(self.active_requests),

"waiting": len(self.waiting_queue),

"completed": len(self.completed),

"gpu_utilization": len(self.active_requests) / self.max_batch_size * 100

}

3.3 调度策略

策略说明适用场景

FCFS 先到先服务通用场景

Shortest First 优先短请求（降低 TTFT）低延迟优先

Longest First 优先长请求（提高吞吐）批量推理

Medusa 基于 Medusa head 的投机调度加速生成

3.4 性能收益

场景静态 Batching In-flight Batching 提升

短请求混合 (50-200 tok) 2,450 tok/s 4,100 tok/s +67%

长请求均衡 (200-500 tok) 3,800 tok/s 4,700 tok/s +24%

极端差异 (50 vs 2000 tok) 1,200 tok/s 3,600 tok/s +200%

量化方案全景：FP8/FP4/INT4/NVFP4

4.1 支持矩阵

精度 GPU 架构显存节省速度提升精度损失

FP16/BF16 所有 NVIDIA GPU 基准基准基准

INT8 Turing+ (SM75+) ~50% ~1.5× <0.5%

FP8 (E4M3/E5M2) Hopper+ (SM90+) ~50% ~2.0× <1%

INT4 Turing+ (SM75+) ~75% ~2.5× 1-3%

FP4 (NVFP4) Blackwell+ (SM100+) ~75% ~3.0× 2-4%

NF4 所有 GPU (QLoRA) ~75% ~2.0× 1-2%

4.2 FP8 量化详解

FP8 是 Hopper 架构（H100/H200）的原生精度，TensorRT-LLM 通过 NVIDIA TensorRT Model Optimizer（ModelOpt）实现 FP8 量化 $3$ ：

使用 ModelOpt 进行 FP8 量化校准

python convert_checkpoint.py

--model_dir ./llama-4-70b

--output_dir ./trt_fp8

--dtype float16

--use_weight_only

--weight_only_precision fp8

--calib_dataset ./c4_sample.json

--calib_size 512 # 校准样本数

FP8 量化原理：

权重 FP16 → FP8 转换

per-tensor / per-channel 缩放因子

E4M3: 4 bit 指数 + 3 bit 尾数（动态范围大）

E5M2: 5 bit 指数 + 2 bit 尾数（精度更高）

推理时：

FP8 权重 × FP16 激活 → 累加 → FP16 输出

↓

NVIDIA H100 FP8 Tensor Core 硬件加速

（无需反量化，直接计算）

FP8 性能数据（LLaMA 3.1 70B）：

指标 FP16 (A100) FP8 (H100) 提升

吞吐量 2,800 tok/s 10,200 tok/s 3.6×

TTFT (单请求) 340ms 194ms -43%

显存占用 140 GB 72 GB -49%

精度 (MMLU) 82.1% 82.0% -0.1%

4.3 NVFP4：Blackwell 原生 4-bit 量化

NVFP4 是 Blackwell 架构（B100/B200/B300）引入的原生 FP4 格式，使用 4-bit 浮点表示：

NVFP4 格式: $S:1bit$ $E:2bit$ $M:1bit$ + E2M1

vs NF4 (QLoRA): 非线性 4-bit 整数量化

vs INT4: NVFP4 精度显著优于 INT4

TensorRT-LLM v0.15+ 通过 CUTLASS 3.x 内核原生支持 NVFP4：

NVFP4 量化编译（Blackwell 专属）

python convert_checkpoint.py

--model_dir ./deepseek-r1-671b

--output_dir ./trt_nvfp4

--dtype float16

--use_weight_only

--weight_only_precision fp4 \ # NVFP4

--calib_size 256

trtllm-build

--checkpoint_dir ./trt_nvfp4

--output_dir ./engine_nvfp4

--gemm_plugin fp4 \ # FP4 GEMM 插件

--gpt_attention_plugin float16

实际效果（DeepSeek-R1 671B on B200）：

配置吞吐量显存性能提升

FP8 8×B200 1,200 tok/s ~900 GB 基准

NVFP4 8×B200 4,800 tok/s ~480 GB 4×

INT4 8×B200 3,200 tok/s ~500 GB 2.7×

NVIDIA 官方数据显示，DeepSeek-R1 在 B200 上使用 NVFP4 相比 H100 FP8 实现了 25 倍性能提升 $4$ 。

4.4 SmoothQuant + W4A16

TensorRT-LLM 还支持 SmoothQuant 风格量化，在推理时同时量化权重和激活：

INT4 权重量化 + FP16 激活

python convert_checkpoint.py

--model_dir ./model

--use_weight_only

--weight_only_precision int4

--calib_size 512

--smoothquant 0.5 # 迁移系数: 0.0=权重量化, 1.0=激活量化

INT4 权重 + FP8 激活混合精度

trtllm-build

--checkpoint_dir ./checkpoint

--gemm_plugin fp8

--use_weight_only

--weight_only_precision int4

4.5 KV Cache 量化

TensorRT-LLM 不仅量化权重，还支持 KV Cache 量化：

KV Cache FP8 量化

trtllm-build

--kv_cache_quant_mode fp8 \ # FP8 KV Cache

--kv_cache_block_length 64 \ # 缓存块大小

KV Cache INT8 量化

trtllm-build

--kv_cache_quant_mode int8

--kv_cache_block_length 32

KV Cache 精度内存节省吞吐提升精度影响

FP16 基准基准 -

FP8 (E4M3) ~50% +20-30% <0.5%

INT8 ~50% +15-25% <1%

Plugin架构与内核融合

5.1 Plugin 系统

TensorRT-LLM 通过 Plugin 机制注入自定义 CUDA 内核，覆盖 Transformer 的每个关键组件：

Plugin 类型 GPU 内核

──────── ──────────

GemmPlugin ──────────────→ FP8/FP4 GEMM (CUTLASS/cuBLAS)

GptAttentionPlugin ──────→ FlashAttention-3 / PagedAttention

FusedMoEPlugin ──────────→ MoE 稀疏门控 + 专家并行

LayerNormPlugin ─────────→ Fused LayerNorm + ResiAdd

RmsNormPlugin ───────────→ Fused RMSNorm

SpeculativeDecodingPlugin → 投机解码草稿验证

MedusaPlugin ────────────→ Medusa Head 并行解码

5.2 内核融合（Kernel Fusion）

TensorRT-LLM 最核心的优化手段：将多个连续的小操作合并为一个 CUDA 内核，减少显存带宽瓶颈。

未融合（多次 kernel launch）:

Input → GEMM → 写显存 → Read → LayerNorm → 写显存 → Read → GeLU → 写显存 → Output

↓ kernel 1 ↓ ↓ kernel 2 ↓ ↓ kernel 3 ↓

融合后（一次 kernel launch）:

Input → $GEMM + LayerNorm + GeLU$ fused kernel → Output

↓ 单次 kernel launch ↓

融合模式：

TensorRT-LLM 自动融合的核心模式

fused_patterns = [

QKV 投影融合

"QKV_proj: $W_q, W_k, W_v$ → single GEMM",

复制代码

# Attention 输出 + 残差连接融合
"Attn_out: AttnProj + ResidualAdd + LayerNorm → single kernel",

# FFN 融合
"FFN_fused: [GateProj + UpProj] → SiLU → DownProj + ResidualAdd",

# MoE 融合
"MoE_fused: Router + TopK + [Expert GEMM × k] + Combine",

# 整个 Transformer Block 融合
"Block_fused: Attn + FFN + both Residual + both LayerNorm"

]

5.3 CUDA Graphs 加速

TensorRT-LLM 支持 CUDA Graphs 消除 kernel launch 开销：

启用 CUDA Graphs

trtllm-build

--use_cuda_graph enable

--cuda_graph_mode full # full 完整图 / capture 按需捕获

或运行时启用

runner = ModelRunner.from_dir(

engine_dir="./engine",

cuda_graph_mode="full",

cuda_graph_cache_size=100 # 缓存图数量

)

场景无 CUDA Graphs CUDA Graphs 提升

Prefill (32 tok) 15.2ms 8.1ms -47%

Decode step 2.8ms 0.9ms -68%

端到端 1K tokens 2,815ms 905ms 3.1×

分布式推理：TP/PP/EP

6.1 并行策略对比

策略切分维度通信量适用模型典型配置

TP (Tensor Parallel) 按层内参数切分高 (all-reduce) 所有模型 TP=8

PP (Pipeline Parallel) 按层切分低 (P2P) 深度模型 PP=4

EP (Expert Parallel) 按专家切分中 (all-to-all) MoE 模型 EP=8

6.2 TP+PP+EP 三维混合并行

8×H100 DeepSeek V4 部署

TP=4, PP=2, EP=8

Step 1: 模型转换时指定并行配置

python convert_checkpoint.py

--model_dir ./deepseek-v4-671b

--output_dir ./checkpoint_tp4

--tp_size 4

--pp_size 2

--ep_size 8

--moe_num_experts 256

Step 2: 引擎构建

trtllm-build

--checkpoint_dir ./checkpoint_tp4

--output_dir ./engine

--workers 8 # 并行构建，加速编译

Step 3: 运行（需要 8 卡）

mpirun -n 8

python run.py

--engine_dir ./engine

--tensor_parallel_size 4

--pipeline_parallel_size 2

--expert_parallel_size 8

6.3 通信优化

NCCL 通信优化环境变量

export NCCL_ALGO=Tree # All-reduce 算法

export NCCL_MIN_NCHANNELS=32 # 最小通道数

export NCCL_NVLS_ENABLE=0 # 禁用 NVLink SHARP

export NCCL_CROSS_NIC=1 # 跨 NIC 通信

export NCCL_SOCKET_IFNAME=ib0 # 使用 InfiniBand

export NCCL_IB_TIMEOUT=22 # IB 超时

export NCCL_IB_QPS_PER_CONNECTION=8 # QP 数

性能基准测试

7.1 H100 FP8 标准 Benchmark

引擎模型精度并发吞吐量 (tok/s) TTFT

TensorRT-LLM LLaMA 3.1 70B FP8 64 10,200 ~100ms

vLLM LLaMA 3.1 70B FP8 64 8,500 ~123ms

SGLang LLaMA 3.1 70B FP8 64 7,800 ~340ms

TensorRT-LLM 在 H100 FP8 下相比 vLLM 吞吐量高 20%，TTFT 低 19% $5$ 。

7.2 Batch Size 影响

Batch Size TensorRT-LLM vLLM 差距

1 187 tok/s 165 tok/s +13%

16 2,940 tok/s 2,450 tok/s +20%

64 10,200 tok/s 8,500 tok/s +20%

128 14,500 tok/s 12,100 tok/s +20%

7.3 低延迟场景（Batch=1）

模型精度 TTFT TPOT 适用场景

LLaMA 3.1 8B FP8 5ms 3.5ms 实时聊天

LLaMA 3.1 70B FP8 18ms 12ms 企业 API

LLaMA 4 405B INT4 35ms 28ms 复杂推理

TensorRT-LLM 在 Batch=1 的低延迟场景下，TTFT 可低至 5ms（8B 模型）至 35ms（405B 模型） $6$ 。

7.4 H100 vs A100 提升

指标 A100 FP16 H100 FP8 提升

峰值吞吐量 2,200 tok/s 10,200 tok/s 4.6×

TTFT 降低 440ms 100ms 4.4×

能效比基准 3.5× 更好

7.5 Blackwell B200 NVFP4

模型配置吞吐量对比 H100 FP8

DeepSeek V4 (671B) 8×B200 NVFP4 4,800 tok/s 4×

LLaMA 4 (405B) 8×B200 NVFP4 6,200 tok/s 3.5×

Qwen 3.5 (397B MoE) 8×B200 NVFP4 7,100 tok/s 3.2×

生产部署最佳实践

8.1 Docker 部署

拉取 NVIDIA 官方镜像

docker pull nvidia/cuda:12.8-devel-ubuntu22.04

编译阶段（推荐多阶段构建）

docker run --gpus all -it

-v /path/to/model:/model

nvidia/cuda:12.8-devel-ubuntu22.04

bash -c "

pip install tensorrt_llm &&

python convert_checkpoint.py

--model_dir /model/llama4-70b

--output_dir /model/trt_checkpoint

--dtype float16 &&

trtllm-build

--checkpoint_dir /model/trt_checkpoint

--output_dir /model/engine

运行时

docker run --gpus all

--shm-size 32g

-p 8000:8000

-v /path/to/engine:/engine

nvidia/cuda:12.8-runtime-ubuntu22.04

python -m tensorrt_llm.commands.serve

--engine_dir /engine

--host 0.0.0.0

--port 8000

8.2 生产优化清单

========== 操作系统级别 ==========

关闭 NUMA 平衡

echo 0 > /proc/sys/kernel/numa_balancing

设置 GPU 持久模式

nvidia-smi -pm 1

设置 GPU 最大时钟频率

nvidia-smi -ac 2619,1980 # H100 SXM

禁用 ECC（推理场景不需要）

nvidia-smi -e 0

========== NCCL 优化 ==========

export NCCL_ALGO=Tree

export NCCL_MIN_NCHANNELS=32

export NCCL_CROSS_NIC=1

export NCCL_IB_TIMEOUT=22

export NCCL_IB_QPS_PER_CONNECTION=8

========== 内存优化 ==========

export CUDA_MODULE_LOADING=LAZY # 延迟加载 CUDA 模块

export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

8.3 Kubernetes 部署

apiVersion: apps/v1

kind: Deployment
metadata:
name: trtllm-server
spec:
replicas: 3
selector:
matchLabels:
app: trtllm
template:
metadata:
labels:
app: trtllm
annotations:
nvidia.com/gpu-workload: "inference"
spec:
containers:

name: trtllm
image: nvidia/tensorrt-llm:0.18.0
command:
python
-m
tensorrt_llm.commands.serve
args:
--engine_dir
/engine
--host
0.0.0.0
--port
"8000"
--max_batch_size
"256"
--max_num_tokens
"65536"
ports:
containerPort: 8000
resources:
limits:
nvidia.com/gpu: 8
memory: "512Gi"
cpu: "64"
requests:
nvidia.com/gpu: 8
memory: "512Gi"
cpu: "64"
volumeMounts:
name: engine
mountPath: /engine
name: shm
mountPath: /dev/shm
env:
name: NCCL_ALGO
value: "Tree"
name: CUDA_MODULE_LOADING
value: "LAZY"
volumes:
name: engine
persistentVolumeClaim:
claimName: trt-engine-pvc
name: shm
emptyDir:
medium: Memory

apiVersion: v1

kind: Service

metadata:

spec:

selector:

app: trtllm

ports:

port: 8000
targetPort: 8000

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

spec:

scaleTargetRef:

apiVersion: apps/v1

kind: Deployment

minReplicas: 2

maxReplicas: 20

metrics:

type: Pods
pods:
metric:
name: trtllm_gpu_utilization
target:
type: AverageValue
averageValue: 75

Triton推理服务器集成
9.1 Triton + TensorRT-LLM 架构
NVIDIA Triton Inference Server 是 TensorRT-LLM 的首选部署平台：

客户端请求

│

▼

┌─────────────────────────────┐

│ Triton Inference Server │

│ ┌───────────────────────┐ │

│ │ HTTP/gRPC Endpoint │ │

│ └────────┬──────────────┘ │

│ ▼ │

│ ┌───────────────────────┐ │

│ │ Model Scheduler │ │ ← In-flight batching

│ │ + Rate Limiter │ │ + Request priority

│ └────────┬──────────────┘ │

│ ▼ │

│ ┌───────────────────────┐ │

│ │ TensorRT-LLM Backend │ │ ← 加载 .engine 文件

│ │ (C++ Backend) │ │ 直接执行推理

│ └────────┬──────────────┘ │

│ ▼ │

│ ┌───────────────────────┐ │

│ │ GPU (H100/B200) │ │

│ └───────────────────────┘ │

└─────────────────────────────┘

9.2 配置示例

model_repository/trt_llm/1/config.pbtxt

backend: "tensorrtllm"

max_batch_size: 256

input [

{

data_type: TYPE_INT32

dims: $-1$

{

data_type: TYPE_INT32

dims: $1$

}

]

output [

{

data_type: TYPE_INT32

dims: $-1$

}

]

instance_group [

{

kind: KIND_GPU

gpus: $0, 1, 2, 3, 4, 5, 6, 7$ # 8 GPU TP

}

]

parameters [

{

key: "gpt_model_type"

value: { string_value: "llama" }

{

key: "gpt_model_path"

value: { string_value: "/models/llama4_engine" }

{

key: "max_tokens_in_paged_kv_cache"

value: { string_value: "65536" }

{

key: "enable_kv_cache_reuse"

value: { string_value: "true" }

}

]

vLLM vs TensorRT-LLM vs SGLang选型

10.1 三引擎全维度对比（2026年6月）

维度 vLLM v0.21 SGLang v0.5.12 TensorRT-LLM v0.18

开发方 UC Berkeley LMSYS Berkeley NVIDIA 官方

开源协议 Apache 2.0 Apache 2.0 Apache 2.0

GitHub Stars 81K 28K 30K

运行时依赖 PyTorch PyTorch 仅 CUDA + TRT

冷启动秒级秒级分钟级（需编译）

推理速度优秀优秀极致 (+15-30%)

延迟 (Batch=1) 10-15ms 10-15ms 5-10ms

量化深度 FP8/INT4/AWQ FP8/INT4 FP8/FP4/INT4/NVFP4

硬件兼容 NVIDIA/AMD/Intel NVIDIA/AMD 纯 NVIDIA

灵活性 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐

部署难度 ⭐ (一行命令) ⭐⭐ ⭐⭐⭐⭐

适用场景通用推理 RAG/Agent 极致性能/大规模

10.2 场景推荐

请求入口

│

├── 追求极致吞吐/低延迟 → TensorRT-LLM ✅

│ ├── 需要亚 10ms TTFT

│ ├── 大规模集群 (100+ GPU)

│ ├── NVIDIA 全栈用户

│ └── 可以接受编译耗时

│

├── RAG/Agent/多轮对话 → SGLang ✅

│ ├── RadixAttention + XGrammar

│ └── 统一 LLM + VLM + Embedding

│

├── 通用高并发推理 → vLLM ✅

│ ├── 快速部署、多硬件支持

│ ├── 社区成熟、文档丰富

│ └── 创业团队首选

│

└── 大厂混合部署 → Triton + 多后端 ✅

├── TensorRT-LLM 处理核心流量

├── vLLM 处理实验性模型

└── SGLang 处理 RAG/Agent

10.3 成本分析

场景 vLLM TensorRT-LLM

月请求 5000 万 (70B) GPU: $42K/月 GPU:$ 32K/月

工程师维护 20h/月 80h/月

总月成本 $56K$ 67K

年成本 $672K$ 800K

创业公司选 vLLM 更为划算（年省 ~$128K），大厂追求极致性能选 TensorRT-LLM $7$ 。

📌 面试加分点

1️⃣ 为什么 TensorRT-LLM 比 vLLM 快？

预编译优化：离线阶段完成图优化、内核融合、内存布局，运行时无 JIT 开销

插件式内核：每个 Transformer 组件都使用手写 CUDA Plugin（FlashAttention、Fused MoE、FP8 GEMM）

CUDA Graphs：将推理过程捕获为 CUDA Graph，消除 kernel launch 开销（decode 步骤 -68%）

无 PyTorch 开销：运行时完全脱离 PyTorch，直接调用 TensorRT C++ Runtime

2️⃣ 离线编译 vs 运行时编译

离线编译 (TensorRT-LLM):

时间

│

编译 ──────┤████████████████ (5-30 min)

推理 ──────┤████████████████████████████████ (运行中)

│

运行时编译 (vLLM/SGLang):

时间

│

加载 ──────┤██ (30s)

推理 ──────┤████████████████████████████████ (略慢)

│

3️⃣ TensorRT-LLM 核心优化流水线

PyTorch Graph

↓

Graph Optimization ─── 常量折叠、死代码消除

↓

Kernel Auto-Tuning ─── 自动选择最优 GEMM 算法

↓

Plugin Insertion ───── FlashAttention / Fused MoE

↓

Memory Layout Opt ──── 最佳内存访问模式

↓

CUDA Graph Capture ── 消除 kernel launch 开销

↓

TRT Engine (.engine)

4️⃣ 关键概念：FP4 推理技术栈

NVFP4 (Blackwell) 推理全链路：

模型权重: FP16 → NVFP4 (4-bit float)

↓

KV Cache: FP16 → FP8 (E4M3)

↓

激活计算: FP4 × FP8 → FP16 (Blackwell Tensor Core)

↓

累加: FP16 (保持精度)

↓

结果: 近似 FP16 精度，显存降低 75%

参考来源

NVIDIA TensorRT-LLM 官方文档 --- NVIDIA Developer

TensorRT-LLM In-flight Batching 技术解析 --- 头条技术博客

TensorRT-LLM FP8/INT8 低精度推理优化 --- IT 技术博客

DeepSeek-R1 B200 FP4 性能优化 --- NVIDIA 官方

vLLM vs TensorRT-LLM 2026 实测对比 --- 头条科技

TensorRT-LLM 低延迟场景基准测试 --- AIMultiple

2026 LLM 部署成本分析 --- 头条科技

主流大模型推理框架深度对比 --- 头条技术