TensorRT 和 ONNX Runtime 推理优化实战：10 个降低延迟的工程技巧

2025-11-29
广东
本文字数：19754 字
阅读完需：约 65 分钟

模型速度的瓶颈往往不在算法本身。几毫秒的优化累积起来就能让用户感受到明显的性能提升。下面这些技术都是在生产环境跑出来的经验，不需要重构代码实施起来也相对简单并且效果显著。

固定输入形状，越早告诉运行时越好动态形状用起来方便但对性能不友好。TensorRT 和 ONNX Runtime 在处理固定形状时能做更激进的优化。

TensorRT 这边，构建引擎时最好围绕实际使用的 min/opt/max 设置 optimization profile，生产环境尽量让所有请求都落在 opt 范围。ONNX Runtime 可以直接导出固定维度的模型，比如 1×3×224×224。确实需要动态性的话，也要把范围控制得足够紧。

TensorRT: build with a tight optimization profile

profile = builder.create_optimization_profile()

profile.set_shape("input", (1,3,224,224), (1,3,224,224), (1,3,224,224))

config.add_optimization_profile(profile)这样 kernel 选择、内存规划、算子融合在形状确定的情况下都能做得更彻底。

启动前把该热的都热一遍冷启动的开销藏在各个角落：驱动初始化、page fault、lazy allocation。服务启动和重启后跑几轮 warmup，把这些一次性成本提前消化掉。

ONNX Runtime warmup + pinned buffers

import onnxruntime as ort, numpy as np

so = ort.SessionOptions()

so.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL

sess = ort.InferenceSession("model.onnx", sess_options=so, providers=["CUDAExecutionProvider"])

x = np.random.randn(1,3,224,224).astype(np.float32)

for _ in range(8): # small loop to populate caches/contexts

sess.run(None, {"input": x})warmup 的形状一定要和线上一模一样。如果服务多种 batch size，每个都得过一遍。

I/O binding 配合 pinned memory 减少拷贝 Host 和 device 之间来回搬数据是 tail latency 的大敌。buffer 绑定一次，后面反复用就行了。

ONNX Runtime I/O binding example

io = sess.io_binding()

x = np.random.randn(1,3,224,224).astype(np.float32)

Upload once & bind

io.bind_cpu_input("input", x) # or bind to CUDA device via OrtValue

io.bind_output("logits", device_type="cuda")

sess.run_with_iobinding(io)

out = io.copy_outputs_to_cpu()[0] # pull back only when you mustGPU 流量大的场景，host 端内存用 page-locked（pinned）能让 H2D/D2H 传输快不少。本质上是把多次小开销合并成一次前置成本，allocator 也不用频繁介入。

精度降低不一定掉点现在的 GPU 对 FP16 支持很好，服务器 CPU 和 NPU 上 INT8 的收益也越来越明显。只要精度守得住，延迟的改善非常直接。

TensorRT 开 FP16 就是一个 flag 的设置：

config.set_flag(trt.BuilderFlag.FP16)。但是 INT8 需要校准，要拿代表性数据跑一遍生成 per-channel scale。ONNX Runtime 可以用 TensorRT EP 或者直接加载量化后的模型。

TensorRT FP16 (and INT8 if you have a calibrator)

config.set_flag(trt.BuilderFlag.FP16)

config.set_flag(trt.BuilderFlag.INT8)

config.int8_calibrator = calibrator

这里可以先量化最慢的几个子图，比如 embedding 层或者 attention block，不用一上来就全模型量化。

图优化可以开到最高档，但要验证数值让运行时自己去融合算子、选更优的 kernel，这个收益基本是白来的。

ONNX Runtime optimizations + EPs

so = ort.SessionOptions()

so.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL

providers = [

("TensorrtExecutionProvider", {"trt_fp16_enable": True}),

"CUDAExecutionProvider",

"CPUExecutionProvider"

]

sess = ort.InferenceSession("model.onnx", sess_options=so, providers=providers)但是需要注意的是融合会改变计算顺序，数值可能有细微漂移。开启前后要跑个 tolerance check，确保输出没问题。

micro-batch 在 GPU 上效果明显单条请求跑推理简单，但硬件利用率往往上不去。打包成 4-8 个请求一起跑，能在保持低延迟的同时提升吞吐。

关键是 batching window 要够小，比如 2-5ms，不然 p95 会飙。micro-batch 的大小最好和前面 optimization profile 设置的尺寸对齐。

不过如果 SLA 本身就很紧（p50 要求 5ms 以内），micro-batch 带来的收益可能不如下面要说的 CUDA Graph。

CUDA Graph 消除 kernel launch 开销小模型或者调用频繁的 graph，kernel launch 的开销会很明显。CUDA Graph 能把整个推理过程录制下来，replay 时几乎没有 CPU 开销。

TensorRT 在形状固定的情况下可以直接启用，只需要 warmup 一次，后面就一直跑 captured graph。

这里可以理解成在 GPU driver 层面把推理编译成一个可重放的宏。

ONNX Runtime 线程设置有讲究 ONNX Runtime 暴露了几个线程相关的参数，对 CPU 和混合负载的 tail latency 影响挺大。

so = ort.SessionOptions()

so.intra_op_num_threads = 1 # one thread per operator often stabilizes latency

so.inter_op_num_threads = 1 # avoid oversubscription; raise carefully if parallel graphsExecution Provider 的选择也很重要：

GPU 场景优先级是 TensorRT EP → CUDA EP → CPU EP fallback。纯 CPU 跑的话 OpenMP 或者 DNNL/MKL build 配合合理的线程池设置效果最好。边缘设备上 Intel 的盒子可以试试 OpenVINO EP。

把预处理后处理从 GIL 里挪出去 Python 的胶水代码经常成为隐藏的性能杀手。能用 NumPy 向量化就别写循环，能用 Numba 或者推到 CUDA/CuPy 上更好。热路径里的 transform 最好提前编译好。如果要并发处理请求，worker pool 的规模要和运行时的线程数配合好。

Example: pre-allocate and reuse buffers to dodge Python overheads

import numpy as np

class Preprocessor:

def init(self, shape=(1,3,224,224)):

self.buf = np.empty(shape, dtype=np.float32)

def __call__(self, img):      # write into self.buf in-place; no fresh allocations      np.copyto(self.buf, img)      self.buf /= 255.0       return self.buf

复制代码

这里的判断标准很简单，每个请求都会跑的代码，问问能不能预分配、向量化或者缓存起来。

Session、Engine、Buffer 都只建一次每个请求新建一个

trt.ICudaEngine 或

onnxruntime.InferenceSession 基本等于自杀。output array 每次重新分配也一样。

正确做法是进程启动时就加载好 singleton session/engine，每个 worker 维护一两个 CUDA stream，buffer pool 按 shape 和 dtype 索引。

Simple singleton-ish loader

class Model:

_sess = None

_io = None

@classmethod

def get(cls):

if cls._sess is None:

so = ort.SessionOptions()

so.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL

cls._sess = ort.InferenceSession("model.onnx", sess_options=so,

providers=["CUDAExecutionProvider"])

cls._io = cls._sess.io_binding()

return cls._sess, cls._io 这样做的好处是稳定，p95 不会因为 allocator 和 initializer 出现在热路径而突然炸掉。

一个完整的 GPU 推理骨架下面的代码是把前面几个关键技术串起来：

import onnxruntime as ort, numpy as np

def make_session(path):

so = ort.SessionOptions()

so.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL

providers = [("TensorrtExecutionProvider", {"trt_fp16_enable": True}),

"CUDAExecutionProvider", "CPUExecutionProvider"]

return ort.InferenceSession(path, sess_options=so, providers=providers)

class Runner:

def init(self, model_path, shape=(1,3,224,224)):

self.sess = make_session(model_path)

self.shape = shape

self.io = self.sess.io_binding()

self._warmup()

def _warmup(self, iters=8):      x = np.random.randn(*self.shape).astype(np.float32)      self.io.bind_cpu_input("input", x)      self.io.bind_output("logits", device_type="cuda")      for _ in range(iters):          self.sess.run_with_iobinding(self.io)      self.io.clear_binding_inputs()  # ready for real runs  
def run(self, x_np: np.ndarray):      # assumes x_np matches self.shape; in production, validate or clamp      self.io.bind_cpu_input("input", x_np)      self.io.bind_output("logits", device_type="cuda")      self.sess.run_with_iobinding(self.io)      return self.io.copy_outputs_to_cpu()[0]