4、动态批处理概念：静态批处理与动态批处理的区别、动态批处理的优势与挑战
4.1 核心原理：从“固定形状”到“请求驱动”的批处理范式转变
在CUDA与TensorRT的推理优化中，批处理（Batching）是提升GPU利用率最核心的手段。其本质是将多个独立请求合并为一次张量运算，从而摊薄内核启动开销、提升显存带宽与计算单元占用率。然而，传统静态批处理与动态批处理在请求聚合时机和张量形状约束上存在根本差异。
静态批处理（Static Batching）要求所有请求在进入推理引擎前必须具有完全相同的形状（如固定尺寸的224×224×3图像），且批大小在模型编译期即被锁定。TensorRT在构建引擎时，会针对该固定形状做内核自动调优（Kernel Auto-tuning），选择最优的卷积/矩阵乘法算法。这种方式的优点是延迟可预测、显存分配固定，但缺点同样明显：一旦请求形状变化或批大小不匹配，要么填充（Padding）到固定尺寸造成算力浪费，要么重新构建引擎，无法适应生产环境的流量波动。
动态批处理（Dynamic Batching）则允许推理引擎在运行时根据实际到达的请求数量与形状，动态调整批大小和输入张量维度。TensorRT通过优化配置文件（Optimization Profile）实现这一点，为每个动态维度指定最小、最优和最大三个值。引擎在运行时根据当前请求队列长度，在预设范围内选择最优批大小，并将不同形状的输入通过隐式填充（Implicit Padding）或显式形状张量（Shape Tensor）统一到同一批次中。
4.2 方法流程：TensorRT动态批处理的实现路径
在TensorRT中实现动态批处理，核心是定义优化配置文件（Optimization Profile）。每个动态维度（包括批大小N、通道数C、高度H、宽度W）都需要声明最小、最优、最大三个值。引擎在运行时根据实际输入形状，在预设范围内选择最优内核。
// 定义动态批处理配置
IExecutionContext* context = engine->createExecutionContext();
// 设置优化配置文件索引（支持多个profile）
context->setOptimizationProfileAsync(0, stream);
// 动态形状输入绑定
const char* inputName = engine->getIOTensorName(0);
context->setInputShape(inputName, Dims4(1, 3, 224, 224)); // 实际batch=1
// 动态形状输出绑定
context->setTensorAddress(inputName, inputBuffer);
context->setTensorAddress(outputName, outputBuffer);
// 异步推理
context->enqueueV3(stream);动态批处理的完整流程包含四个关键阶段：
- 请求收集（Request Collection）：推理服务器（如Triton）在时间窗口内（通常1~10ms）收集到达的推理请求，放入队列。
- 形状对齐（Shape Alignment）：将不同形状的输入通过填充（Padding）或裁剪（Cropping）统一到同一尺寸。TensorRT支持隐式填充（自动在张量末尾补零）和显式形状张量（通过Shape Tensor传递实际形状信息）。
- 批大小决策（Batch Size Decision）：调度器根据当前队列长度、GPU利用率、延迟约束（SLA）决定本次推理的批大小。常见策略包括固定窗口（等待固定时间）和动态窗口（根据到达速率调整等待时间）。
- 引擎执行（Engine Execution）：将聚合后的批次提交给TensorRT引擎，引擎根据优化配置选择最优内核执行推理。
4.3 案例/场景：动态批处理在真实业务中的收益
以智能视频分析平台为例，该平台需要同时处理来自多个摄像头的视频流，每帧图像分辨率不同（1080P、720P、480P），且请求到达时间高度随机。使用静态批处理时，系统被迫将所有帧填充到1080P，导致720P和480P帧的算力浪费高达60%。同时，当请求不足时，系统必须等待固定批大小凑齐，增加了延迟。
切换到动态批处理后，系统配置了min=1, opt=8, max=16的优化配置文件，并采用动态时间窗口策略：当队列中请求数≥8时立即推理；当请求数不足时，等待最多5ms。实际运行数据显示：
| 指标 | 静态批处理 | 动态批处理 | 提升幅度 |
|---|---|---|---|
| 平均吞吐量（FPS） | 320 | 580 | +81% |
| P99延迟（ms） | 45 | 38 | -15% |
| GPU利用率 | 62% | 91% | +29% |
| 无效计算占比 | 38% | 7% | -31% |
另一个典型场景是自然语言处理（NLP）推理服务。Transformer模型的输入序列长度变化剧烈（从几十到上千token），静态批处理要求所有序列填充到最大长度，导致大量计算浪费。动态批处理结合序列长度分桶（Length Bucketing），将相似长度的请求聚合到同一批次，配合TensorRT的动态形状支持，在BERT推理中实现了约2.3倍的吞吐提升。
4.4 误区与复盘：动态批处理的“隐形陷阱”
动态批处理只是提供了可能性，实际收益取决于调度策略。如果时间窗口设置过长，请求等待时间增加，延迟SLA可能被打破；如果窗口过短，批大小不足，GPU利用率反而下降。需要根据业务流量模型精细调优。
将min设为1、max设为64看似灵活，但TensorRT会为每个优化配置生成多套内核。配置范围过大会导致引擎体积膨胀（可能增加数GB）和构建时间剧增（从分钟级到小时级）。更严重的是，运行时内核切换（Context Switching）开销增加，可能抵消动态批处理的收益。
动态形状意味着每次推理的显存分配大小不同。频繁的显存分配/释放会导致显存碎片化，最终触发OOM。必须使用显存池（Memory Pool）或缓存分配器（Caching Allocator）来复用显存块。
复盘建议：在生产环境部署动态批处理前，应先在离线环境使用真实流量回放进行压测。重点关注三个指标：批大小分布（是否经常处于min或max边界）、形状变化频率（是否频繁触发内核切换）、显存峰值（是否接近显存上限）。根据压测结果调整优化配置范围和时间窗口参数，才能充分发挥动态批处理的优势。