动态批处理：累积请求形成批次以提升吞吐

什么是动态批处理

动态批处理是一种在实时推理服务中自动累积独立请求，并按批次一起处理的优化技术。它允许系统在延迟可接受的前提下等待一小段时间，将到达的多个请求合并成批次，再交给模型或计算引擎执行，从而显著提高吞吐量。

与静态批处理（需要客户端或上游系统预先打包好固定大小的批次）不同，动态批处理由服务端透明完成，客户端无须改动，有效解决了线上流量不规则、请求到达不均匀带来的资源浪费问题。

为什么需要动态批处理

深度学习模型在批处理输入时通常能更好利用硬件并行能力。一个批次处理 8 条数据的时间往往远小于单独处理 8 条数据的时间之和。但在在线服务中，请求是逐个到达的，如果来一个处理一个，GPU 利用率会很低。

动态批处理正是为了解决这个矛盾而生的：既不需要客户端攒够一批再发送，又能让服务器自动拼合请求，在吞吐和延迟之间找到平衡。

主要收益

• 显著提升吞吐：更少的推理调用次数，更好的硬件利用率，提升 QPS。
• 降低平均延迟：减少单个请求在队列中等待调度的时间（对比逐个处理）。
• 透明实施：客户端代码零改动。
• 资源成本优化：同样的硬件能承载更大流量，降低单次推理成本。

动态批处理的工作原理

动态批处理通常在推理框架或服务层实现，核心流程如下：

1. 请求入队
   每个到达的推理请求被放入一个共享队列，同时记录到达时间。

2. 批次构建策略
   系统根据配置的策略决定何时取出请求并组成批次。常见策略包括：

   • 超时触发：等待最长不超过 max_batch_delay 毫秒，期间收集新请求。
   • 大小触发：当队列中请求数达到 max_batch_size 时立即组成批次。
   • 混合策略：满足任一条件就触发批处理。

3. 动态整形与填充
   不同请求的输入形状可能不同（例如文本长短不一），需要进行填充或截断，使批次内各样本对齐。框架通常自动处理这一步骤。

4. 批次执行
   将批次一次性送入模型推理，获得结果。

5. 结果分发
   按照请求的原始顺序或标识，将批次结果拆解并返回给对应的客户端连接。

下方是简化流程示意图（文字描述）：

请求流入 → 批处理队列 → 等待超时/攒够批次 → 组合批次 → 模型推理 → 拆分结果 → 返回

如何实现动态批处理（以 TensorFlow Serving 为例）

许多推理服务框架已经内置了动态批处理能力。下面以 TensorFlow Serving 和 Triton Inference Server 为例，展示配置方法。

TensorFlow Serving 中的动态批处理

TensorFlow Serving 通过 --enable_batching 标志和批次配置文件启用动态批处理。

步骤 1：编写批处理配置文件 batching_config.txt

max_batch_size { value: 32 }
batch_timeout_micros { value: 5000 }
max_enqueued_batches { value: 100 }
num_batch_threads { value: 4 }

参数含义：

• max_batch_size：批次包含的最大请求数。
• batch_timeout_micros：等待新请求的最长时间（微秒），此处为 5 毫秒。
• max_enqueued_batches：队列中允许暂存的最大批次数，用于背压控制。
• num_batch_threads：构建批次的线程数。

步骤 2：启动 TensorFlow Serving 时指定配置文件

tensorflow_model_server \
  --model_name=my_model \
  --model_base_path=/models/my_model \
  --enable_batching=true \
  --batching_parameters_file=/path/to/batching_config.txt \
  --port=8500

Triton Inference Server 的动态批处理

Triton 同样提供了简洁的配置方式，在模型配置文件中添加 dynamic_batching 段落。

dynamic_batching {
  max_queue_delay_microseconds: 100
  preferred_batch_size: [ 8, 16 ]
  preserve_ordering: false
}

• max_queue_delay_microseconds：最大排队延迟（μs）。
• preferred_batch_size：倾向构建的批次大小，系统会根据实际流量选择接近的值。
• preserve_ordering：是否保持请求顺序，设为 false 可略微提升吞吐。

关键参数调优建议

为了让动态批处理在吞吐和延迟之间取得最佳平衡，需要根据业务模型和流量特征调优。

批处理大小

• 过小：不能充分利用 GPU 并行性，吞吐改善有限。
• 过大：增加等待时间，延长尾延迟；也可能超出显存限制。
• 建议从模型能处理的最大批大小（受显存约束）开始，逐步下调，观察延迟和吞吐曲线。

超时时间

• 过长：响应延迟上升，用户体验变差。
• 过短：通常只能凑到小批次，吞吐优化减弱。
• 实践中常设 5 ~ 50 毫秒，对实时性要求高的 API 可以设为 1 ~ 10 毫秒。

队列深度

• 队列可以平滑突发流量，但过大可能消耗过多内存并增加平均等待时间。一般设置为 max_batch_size 的几倍即可。

动态批处理的局限与注意事项

1. 延迟敏感性
   动态批处理本质是“用时间换取吞吐”。超时设置会导致请求在队列中等待，因此需要评估 P99 延迟是否会超出业务 SLA。

2. 异构请求性能损失
   如果请求间的输入长度差异很大（如短文本和长篇文章混在一起），填充会导致大量无效计算，反而降低有效吞吐。此时可以考虑按长度分桶批处理或使用 Ragged Tensor。

3. 状态管理
   对于有状态模型（如带有会话历史），需要确保批处理不会打乱请求间的状态顺序，有些框架支持 preserve_ordering 选项。

4. 不适合极低延迟场景
   比如要求端到端延迟在 2 毫秒以内的服务，等待组成批次本身就可能超出时限，此时应直接使用单个推理。

与其他批处理方式的对比

动手实验：观察动态批处理效果

可以基于 TensorFlow Serving 快速体验动态批处理带来的性能差异。

1. 准备一个简单的文本分类模型（TensorFlow SavedModel 格式）。
2. 分别启动两个服务实例：一个开启动态批处理，一个关闭。
3. 使用压测工具发送请求，例如通过 locust 或 wrk 发送不同并发量的请求。
4. 对比结果：你会发现在中等并发时，开启动态批处理的实例吞吐量明显更高，且平均延迟并不至于翻倍。

典型结果示例（仅供参考）：

• 无批处理：100 QPS，平均延迟 20ms，P99 45ms
• 动态批处理（超时 10ms，最大批次 8）：280 QPS，平均延迟 22ms，P99 50ms

可以看到吞吐接近 3 倍提升，仅付出极小的延迟代价。

总结

动态批处理是实时推理服务中一项性价比极高的优化技术。通过在服务端自动合并请求构建批次，它在几乎没有系统复杂度增加的情况下，大幅提升了 GPU 利用率和系统吞吐。对于大多数在线推理场景，开启动态批处理并合理配置超时与批次大小，是投入产出最高的优化手段之一。

掌握动态批处理的原理和调优方法，能够帮助你在实际项目中轻松应对流量波动，降低硬件成本，同时保持服务质量。