选择的分界线是状态关联：每个请求能否独立推理、任意重排且不依赖前序结果。能独立处理的请求，普通 Dynamic Batcher 通常更合适；同一会话中的请求必须保持顺序、共享实例内状态或依赖开始与结束标记时，应使用 Triton Sequence Batcher。不要把“请求形状相同”误判为“可安全合批”：有状态请求进入普通 batching，最危险的结果不是单纯延迟波动，而是上下文错配。
两类调度解决的不是同一个问题
Dynamic Batcher 面向可并行的独立推理请求。它会在允许的等待窗口和批大小约束内，从队列中组织批次，以提高设备利用率；因此请求是否进入同一批次、等待多久以及批次组成，均不应被业务当作会话顺序保证。它适合图像分类、独立文本编码、无服务端会话状态的排序等场景。
Sequence Batcher 则面向一串具有关联标识的请求。客户端以 correlation ID 区分序列，并通过序列开始、结束等控制信息表达生命周期；调度器需要让同一序列的请求以正确顺序落到可承接该序列的模型实例上。Triton 的能力范围、调度概念及版本差异应以Triton Inference Server User Guide为准，不能只凭其他项目的配置样例迁移判断。
状态关联为何改变实例绑定要求
有状态模型的“状态”可能是循环网络的隐藏状态、流式语音的解码上下文、跨片段的缓存，或由后端在实例内维护的会话对象。此时同一 correlation ID 的后续请求不仅要排在前序请求之后，还要到仍保存该上下文的执行位置。Sequence Batcher 的价值正在于把序列身份和生命周期纳入调度，而不是仅按张量维度凑批。
普通 Dynamic Batcher 不理解这类会话语义。即使两个请求输入尺寸一致，它也可能与其他会话共同等待、合并或在不同实例上执行。若模型依赖实例内状态，A 会话的后续片段被送往没有 A 上下文的实例，或控制边界缺失，就可能出现结果串话、状态重置、尾段错误等问题。仅在每次请求都完整携带状态、模型按请求显式读写状态且应用能够正确隔离时，才可重新评估普通合批；这仍需实测证明，而非假设。
决策对照：先确认语义，再看吞吐
| 判断维度 | Sequence Batcher | 普通 Dynamic Batcher |
|---|---|---|
| 请求关系 | 同一 ID 的请求存在前后依赖 | 每个请求可独立完成 |
| 顺序与实例 | 需要维护序列顺序，并关注实例内上下文延续 | 不应依赖队列顺序或固定实例 |
| 合批目标 | 在序列语义成立前提下调度可运行请求 | 尽量组织兼容的独立请求批次 |
| 队列等待 | 除批处理等待外，还受序列占用与可用实例影响 | 主要受到达节奏、批大小与等待策略影响 |
| 典型风险 | 遗漏开始/结束、错误复用 ID、序列长期不结束 | 把有状态流量合批，造成上下文错配 |
| 优先选择 | 流式、多轮、分片且状态留在服务端实例内 | 无状态、高并发、请求彼此可交换 |
配置前先画出请求状态机
实施时先定义一个业务序列从何时开始、哪些请求属于同一 ID、何时正常结束、异常和超时如何终止。随后确认模型配置中的输入输出、批处理维度、实例组和调度段是否与后端实现一致。模型配置字段、调度器配置方式及约束应逐项对照Triton Model Configuration，尤其要复核所用 Triton 版本是否支持目标后端和相应调度能力。
- 将流量按“独立请求”与“同一会话后续片段”拆分，不能分类的请求先按有状态处理。
- 为有状态路径设计稳定且唯一的 correlation ID，明确开始、结束和取消语义。
- 配置少量实例起步，观察长序列是否长期占住实例；不要先把实例数或等待时间调到极端值。
- 让无状态流量走单独模型版本或端点上的 Dynamic Batcher，避免与序列流量混用同一调度假设。
队列等待不能只看平均延迟
Dynamic Batcher 的等待策略是用一部分排队时间交换更大的批次机会；Sequence Batcher 还要面对序列黏性带来的可用实例限制。短序列和长序列混在一起时，整体平均延迟可能稳定，但短序列的尾延迟会因实例被长序列占用而恶化。因而调参不能只比较吞吐或平均值，也不能把一次压测中较大的批次视为永久收益。
至少按请求类型和序列长度分组记录排队时间、端到端延迟分位数、执行时间、批大小分布、活跃序列数、实例忙碌情况以及超时和取消比例。对 sequence 路径，还应记录开始到结束是否闭合、同一 ID 是否发生乱序、结束后是否仍收到后续片段。这些指标能区分“模型慢”“合批等待过长”和“实例被序列占用”三类问题。
用可重复实验验证，而不是凭输出看起来正常
建立包含至少两个交错会话的测试：为每个会话构造可识别的状态演进，并插入不同长度的间隔、并发与取消情形。验证同一 ID 的输出仅依赖自身历史，结束后新序列不继承旧状态，异常终止不会污染后续会话。再分别在单实例、多实例、不同并发和不同序列长度下执行，以暴露实例绑定与队列等待问题。
无状态路径则应验证不同到达顺序和不同批次拆分下的结果等价性。若结果会因批次成员、执行实例或到达顺序而改变，便不满足普通 batching 的前提，应回到状态建模或 Sequence Batcher 方案。硬件、后端实现、模型支持的批处理形式和运行时版本都会影响可用配置，部署前必须在目标环境复核官方文档和实际日志。
出现风险时保留明确回退路径
首个上线阶段可将有状态流量保留在 sequence 调度路径，并为异常序列设置业务侧超时、显式终止和可观测告警；无状态流量独立发布。若发现乱序、状态泄漏、尾延迟不可接受或配置兼容性问题，先停止扩大并发，切回已验证的较少实例或更保守的 sequence 配置，并隔离受影响的 correlation ID。只有在无状态等价性、队列指标和故障恢复都通过验证后，才逐步扩大 Dynamic Batcher 的覆盖范围。
WeChat
Profile