ONNX Runtime与TensorRT推理对比：同一模型在不同引擎下的延迟与吞吐实测-育师

ONNX Runtime与TensorRT推理对比：同一模型在不同引擎下的延迟与吞吐实测

一、推理引擎选型不能只看Benchmark论文

ONNX Runtime (ORT) 和 TensorRT 的官方 Benchmark 数据往往存在选择性报告的问题。ORT 的报告通常基于CPU推理场景，TensorRT的报告则聚焦于其高度优化的INT8量化路径。这两个场景几乎没有交集，直接对比官方数据无法得出有意义的结论。

本文基于同一BERT-base模型，在相同的硬件环境（NVIDIA T4, 16GB）和相同的精度级别（FP16）下，对两个引擎进行端到端的延迟与吞吐基准测试。测试结果揭示出与官方Benchmark不同的实践模式。

flowchart LR A[PyTorch 训练产出] --> B{导出格式} B -->|torch.onnx.export| C[ONNX 模型] B -->|torch2trt / ONNX| D[TensorRT Engine] C --> E[ONNX Runtime] C --> F[ONNX Runtime + TensorRT EP] D --> G[TensorRT Standalone] E --> H[延迟/吞吐测量] F --> H G --> H H --> I[同模型跨引擎对比报告]

二、推理引擎加速的核心技术路径差异

ONNX Runtime 和 TensorRT 在架构设计上的根本差异决定了它们在推理场景中的表现模式不同。

ONNX Runtime 采用图优化 + 算子融合的策略。它在加载模型后执行一系列图级别的优化pass：常量折叠、冗余节点消除、连续的矩阵操作融合。这些优化是通用的，不依赖具体硬件拓扑。ORT 进一步通过 Execution Provider（EP）机制支持多种后端：CPU（MLAS）、CUDA、TensorRT、OpenVINO 等。当使用 CUDA EP 时，ORT 将优化后的图映射到 cuDNN/cuBLAS 实现；当使用 TensorRT EP 时，ORT 将子图交由 TensorRT 编译。

TensorRT 采用整图编译 + Kernel自动调优的策略。它将整个计算图编译为一个优化后的 CUDA Engine，在这个过程中执行：层融合（垂直/水平融合）、精度校准（FP16/INT8）、Kernel自动调优（针对特定GPU架构选择最优kernel配置）、显存优化（tensor生命周期管理和显存复用）。TensorRT 的编译更激进，耗时也更长。

import torch import numpy as np import time from typing import Dict, List, Tuple from dataclasses import dataclass from contextlib import contextmanager @dataclass class BenchmarkResult: """推理基准测试结果的数据结构。""" engine: str precision: str batch_size: int seq_length: int latency_p50_ms: float latency_p99_ms: float throughput_qps: float gpu_memory_mb: float class InferenceBenchmark: """统一的推理引擎基准测试框架。 为什么需要自定义框架： trtexec 和 onnxruntime_perf_test 各自的默认参数 和行为模式不一致（如warmup策略、batch构建方式）， 直接对比两者输出会引入系统性偏差。 通过统一的数据加载和计时逻辑，使对比结果真正反映引擎差异。 """ def __init__(self, warmup_iter: int = 100, bench_iter: int = 1000): self.warmup_iter = warmup_iter self.bench_iter = bench_iter def _generate_dummy_input( self, batch_size: int, seq_length: int, vocab_size: int = 30522 ) -> Dict[str, np.ndarray]: """生成模拟BERT输入的随机数据。 使用固定随机种子的原因： 对比测试中不同引擎处理的输入必须完全一致。 否则输入差异会掩盖引擎性能差异。 """ rng = np.random.RandomState(42) return { "input_ids": rng.randint( 0, vocab_size, (batch_size, seq_length) ).astype(np.int64), "attention_mask": np.ones( (batch_size, seq_length), dtype=np.int64 ), "token_type_ids": np.zeros( (batch_size, seq_length), dtype=np.int64 ) } def measure_latency( self, inference_fn, inputs: Dict[str, np.ndarray], ) -> Tuple[float, float]: """测量端到端推理延迟。 使用 CUDA events 而非 time.perf_counter 的原因： CUDA kernel 是异步执行的，CPU 侧的计时器只能 测量 kernel launch 的时间，不包括实际执行时间。 torch.cuda.Event 提供了 GPU 侧的精确计时。 """ if not torch.cuda.is_available(): # CPU 推理场景，退化为 wall-clock 计时 latencies = [] for _ in range(self.bench_iter): start = time.perf_counter() _ = inference_fn(inputs) latencies.append(time.perf_counter() - start) else: starter = torch.cuda.Event(enable_timing=True) ender = torch.cuda.Event(enable_timing=True) latencies = [] # Warmup for _ in range(self.warmup_iter): _ = inference_fn(inputs) # 精确计时 for _ in range(self.bench_iter): starter.record() _ = inference_fn(inputs) ender.record() torch.cuda.synchronize() latencies.append(starter.elapsed_time(ender)) latencies = np.array(latencies) return np.percentile(latencies, 50), np.percentile(latencies, 99)