如何用TensorRT实现请求合并以提高吞吐？
在如今的AI服务部署中，一个常见但棘手的问题是：明明GPU算力强大，推理模型也已优化，可系统整体吞吐却始终上不去。尤其是在高并发场景下，成千上万的小批量请求接连抵达，GPU频繁启动内核、搬运数据，计算单元却常常“吃不饱”——这种资源浪费直接拉低了单位时间内的处理能力。
这背后的核心矛盾在于：深度学习模型擅长并行处理大批量数据，而现实中的用户请求往往是离散且稀疏的。解决这一矛盾的关键，就是“请求合并”（Request Merging），也称动态批处理（Dynamic Batching）。它不是简单地让模型跑得更快，而是通过智能聚合，让每一次GPU执行都尽可能满载运行。
NVIDIA TensorRT 正是为此类生产级推理场景而生的利器。它不仅能将训练好的模型压缩、加速，更重要的是，结合其对动态形状和多精度的支持，为请求合并提供了坚实的技术基础。真正把“提升吞吐”从理论构想变成可落地的工程实践。
要理解请求合并为何有效，先得看清传统推理模式的瓶颈所在。以PyTorch或TensorFlow原生推理为例，每个请求到来时都会触发一次独立的前向传播流程：CPU准备输入 → 数据拷贝到GPU → 启动CUDA kernel → 等待执行完成 → 结果传回 → 返回响应。这其中，内存拷贝和kernel launch的开销几乎是固定的，与batch size关系不大。
这意味着，当batch=1时，这些固定成本被单个请求独自承担；而当batch=32时，同样的开销由32个请求共同分摊。GPU的SM（流式多处理器）也能持续处于活跃状态，避免空转。这就是吞吐量能成倍增长的根本原因——不是单次计算变快了，而是单位时间内完成了更多有效工作。
TensorRT 在这个过程中扮演的角色远不止是一个“更快的执行引擎”。它的设计哲学是从头到尾为确定性、高性能、低延迟服务。从模型导入开始，TensorRT 就会进行一系列深度优化：
- 图层融合：把连续的小操作如 Conv + Bias + ReLU 合并成一个复合节点，显著减少kernel调用次数。
- 精度校准：支持FP16甚至INT8量化，在保证精度损失可控的前提下，大幅提升计算密度。
- 内核自动调优：针对目标GPU架构（如Ampere、Hopper）搜索最优的CUDA实现方案。
- 序列化引擎：生成的
.engine文件包含所有优化策略，加载即用，无需重复编译。
这些优化单独看都很重要，但它们共同作用的结果，才使得大batch推理真正高效。比如，没有层融合，即便batch变大，kernel launch的开销仍可能成为瓶颈；没有INT8支持，显存带宽可能限制最大batch size。可以说，TensorRT 把整个推理链路打磨到了极致，只为让GPU“专心算数”。
当然，光有引擎还不够。真正的动态批处理需要一套运行时调度机制来协调请求的收集与合并。虽然TensorRT本身不直接管理请求队列，但它通过动态形状支持为上层调度器打开了大门。自TensorRT 7.x起，开发者可以在构建引擎时定义输入张量的维度范围，例如batch size可以从1到32动态变化。这就意味着同一个引擎可以灵活应对不同负载，无需为每个batch size单独生成模型。
下面这段Python代码展示了如何创建一个支持动态batch的TensorRT引擎：
import tensorrt as trt import numpy as np TRT_LOGGER = trt.Logger(trt.Logger.WARNING) builder = trt.Builder(TRT_LOGGER) network = builder.create_network(flags=1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) config = builder.create_builder_config() config.max_workspace_size = 1 << 30 # 1GB临时空间 profile = builder.create_optimization_profile() input_tensor = network.add_input(name="input", dtype=trt.float32, shape=(-1, 3, 224, 224)) profile.set_shape("input", min=(1, 3, 224, 224), opt=(8, 3, 224, 224), max=(32, 3, 224, 224)) config.add_optimization_profile(profile) if builder.platform_has_fast_fp16: config.set_flag(trt.BuilderFlag.FP16) # 假设已通过ONNX解析器导入模型 # parser.parse_from_file("resnet50.onnx") engine_bytes = builder.build_serialized_network(network, config) with open("resnet50_dynamic.engine", "wb") as f: f.write(engine_bytes)这里的关键点有三个：一是启用EXPLICIT_BATCH标志，明确声明批处理维度可变；二是通过OptimizationProfile定义最小、最优和最大输入尺寸，其中opt值代表性能预期最佳的配置；三是开启FP16标志以进一步提升效率。最终生成的引擎文件可在运行时接受任意符合范围的输入shape。
有了这样的引擎，接下来就需要一个批处理器来实现请求聚合。最简单的做法是在服务端维护一个请求队列，并设置一个微小的时间窗口（如5ms），在此期间不断收集新到达的请求。一旦达到预设的最大batch size或超时，就将这些输入沿batch维度堆叠，送入TensorRT引擎统一执行，最后再将输出拆解并回调返回给各自客户端。
以下是一个简化的批处理逻辑示例：
import time from queue import Queue import threading class BatchProcessor: def __init__(self, engine, max_batch_size=32, timeout_ms=5): self.engine = engine self.max_batch_size = max_batch_size self.timeout = timeout_ms / 1000.0 self.request_queue = Queue() self.running = True def add_request(self, input_data, callback): self.request_queue.put((input_data, callback)) def process_loop(self): while self.running: requests = [] start_time = time.time() while len(requests) < self.max_batch_size and (time.time() - start_time) < self.timeout: try: req = self.request_queue.get(timeout=0.001) requests.append(req) except: break if not requests: continue inputs, callbacks = zip(*requests) stacked_input = np.stack(inputs, axis=0) output = self.engine.infer(stacked_input) for i, cb in enumerate(callbacks): cb(output[i]) def start(self): thread = threading.Thread(target=self.process_loop) thread.start()这个类在一个后台线程中持续监听请求队列，采用“贪心+超时”的策略平衡吞吐与延迟。虽然简单，但它揭示了动态批处理的本质：在可接受的延迟范围内，尽可能多地聚合请求，使每次GPU执行都能最大化利用率。
不过，在真实生产环境中，手动实现这类逻辑往往不够稳健。更推荐的做法是使用NVIDIA Triton Inference Server。Triton 是专为大规模推理部署设计的服务框架，内置了成熟的动态批处理调度器，支持静态批、动态批、序列批等多种模式，还能根据优先级和服务等级协议（SLO）进行精细化控制。配合TensorRT后端，几乎无需额外开发即可获得极高的吞吐表现。
典型的系统架构如下：
[Client] → [Load Balancer] → [Triton Inference Server] ↓ [TensorRT Engine (on GPU)]在这种架构下，Triton 负责接收请求、执行批处理决策，并调用底层的TensorRT引擎完成推理。整个过程对客户端透明，开发者只需关注模型本身的性能调优。
实际测试数据显示，这种组合威力惊人。以ResNet-50模型在A100 GPU上的运行为例：当batch=1时，吞吐约为4,000 req/s；而启用动态批处理并将batch提升至32后，吞吐可突破20,000 req/s，提升超过5倍。更重要的是，每瓦特能耗下的推理数量也大幅提升，这对数据中心级别的部署具有显著的经济价值。
当然，任何优化都不是无代价的。请求合并的主要权衡在于延迟。由于需要等待其他请求到来才能触发推理，端到端延迟不可避免地上升。因此，在设置批处理超时时间时，必须结合业务需求谨慎选择。对于实时性要求极高的场景（如自动驾驶感知），可能更适合采用静态批处理或专用通道隔离处理。
此外，显存容量也是硬约束。大batch意味着更大的中间激活缓存，若超出GPU显存，会导致推理失败或OOM错误。因此，max_batch_size的设定不仅要考虑性能拐点，还需留出足够的安全余量。
尽管如此，对于大多数在线服务而言，适度增加几毫秒的延迟换取数倍吞吐提升，依然是极具吸引力的选择。尤其在云计费模式下，单卡支撑更高的QPS意味着更少的实例数量和更低的总体拥有成本（TCO）。
归根结底，TensorRT + 请求合并的价值不仅体现在性能数字上，更在于它推动了一种新的AI服务设计范式：从“被动响应”转向“主动调度”。系统不再只是机械地处理每一个请求，而是具备了一定的“思考”能力——知道何时该等、何时该走，从而在延迟与吞吐之间找到最优平衡。
对于开发者而言，掌握这套技术栈，意味着能够用更少的硬件资源承载更大的业务流量。无论是在推荐系统、语音识别还是视觉分析领域，这种能力都已成为构建高可用、低成本AI基础设施的核心竞争力。未来随着模型规模持续增长，这种“以批促效”的思路只会更加关键。
