动态批处理是什么？

动态批处理（Dynamic Batching）是一种推理服务端机制：它会在运行时把多个独立的推理请求合并成一个批次执行。它的优化重点在请求调度、批次形成和资源使用，而不是直接改变模型能力。

在在线推理服务中，请求通常不会整齐地同时到达：有的请求先进入队列，有的请求稍后到达；有的很快生成结束，有的仍在继续。动态批处理要解决的，就是在可接受的等待时间和服务目标内，把这些请求组织成更适合执行的批次。

在部分 LLM 推理语境中，Continuous Batching（连续批处理）也会被称为动态批处理或迭代级批处理。两者都强调运行时调度，但 Continuous Batching 更突出在生成迭代过程中持续补入新请求。

要点： 动态批处理的核心不是简单把 batch size 固定调大，而是让服务端根据请求到达情况、资源状态和 SLO（服务级目标）动态组织推理批次。

为什么 LLM 推理需要动态批处理？

LLM 在线推理通常同时面对两个目标：既要尽快响应单个用户请求，又要让 GPU 等计算资源保持较高利用率。逐条处理请求虽然调度简单，但在并发请求持续到达时，往往难以充分利用硬件资源。

单请求处理容易造成资源空转

如果每个请求都单独执行，服务端可能频繁处理小规模计算任务。对于高并发问答、聊天机器人或文本生成 API，这种方式容易让资源在请求间隙中等待，整体吞吐量受限。

批处理的基本思想，是把多个请求合并执行，让一次推理计算承载更多有效工作。动态批处理进一步把“何时合并、合并多少、如何继续调度”放到运行时决定，因此更适合请求到达不均匀的在线服务。

推理吞吐不只取决于模型本身

LLM 推理常受到内存 IO 等因素影响，吞吐瓶颈不一定只来自模型参数规模或算力本身。即使模型权重不变，服务端调度方式、内存使用方式和批次组织策略，也会影响整体吞吐表现。

因此，动态批处理常被用于 LLM 推理吞吐优化：通过运行时合并请求、调整批次或块大小，在资源约束和 SLO 目标之间取得平衡。

常见目标包括吞吐、资源利用和延迟指标

动态批处理通常关注以下目标：

• 提高有效吞吐量，让单位时间内完成更多推理请求；
• 改善 GPU 利用率，减少请求零散带来的资源空转；
• 在特定实现和负载条件下，改善 TBT 等与生成过程相关的延迟指标；
• 在通常不修改模型权重的前提下，优化推理服务部署效率。

这里的 TBT 可理解为特定推理框架文档中使用的生成过程延迟指标，具体定义和计算方式应以对应框架文档为准。需要注意的是，动态批处理并不天然保证所有延迟指标都下降。它通常需要在“多等待一点以组成更合适的批次”和“尽快执行以降低单请求等待”之间做取舍。

动态批处理的基本工作流程

动态批处理可以理解为服务端围绕请求队列持续做调度。一个典型流程如下。

1. 请求进入服务端队列

用户请求先进入推理服务。每个请求可能包含不同长度的输入，也可能对应不同的生成长度需求。服务端会记录请求到达时间、资源状态和当前调度窗口。

2. 服务端聚合可合并的请求

调度器在运行时观察队列中的请求，并尝试把多个独立请求合并成当前批次。这里的关键不是预先写死所有批次，而是在请求实际到达后动态形成批次。

3. 形成当前批次并执行推理

当调度器认为条件满足时，会把选中的请求组成一个批次提交执行。这个条件可能与当前资源、等待时间、批次大小上限、业务 SLO 目标等因素有关。

在 vllm-ascend 文档的描述中，动态批处理会根据资源和 SLO 目标，在分块预填充策略的每次推理迭代中动态调整块大小，用于提高有效吞吐量并降低 TBT。其他框架是否采用相同机制，需要结合具体文档和版本确认。

4. 根据完成情况继续调度

批次执行过程中，不同请求的完成时间可能不同。对于 LLM 生成任务，某些序列可能较早结束，另一些序列仍需继续生成。

连续批处理的一种典型思路是：当批次中的某个序列完成后，调度器可以利用空出的执行位置插入新序列，让推理过程持续承载有效请求，而不是等待整个批次全部结束后再开始下一批。

5. 持续平衡吞吐和延迟

动态批处理不是一次性动作，而是持续调度过程。服务端会不断接收新请求、形成批次、执行推理、释放资源、补入请求，并围绕吞吐、等待时间和资源占用进行平衡。

动态批处理、静态批处理和连续批处理有什么区别？

静态批处理、动态批处理和连续批处理都与“批次”有关，但调度粒度和适用场景不同。

静态批处理更偏固定批次

静态批处理通常按照较固定的批次大小或调度规则执行。它实现简单，适合任务规模比较稳定、等待时间要求不高或离线处理的场景。

但在在线推理中，请求到达往往不均匀。如果为了凑满固定批次而等待太久，可能影响单个请求响应；如果不等待，又可能形成过小批次，降低资源利用率。

动态批处理强调运行时合并和调整

动态批处理的重点是运行时决策。它会根据当前队列、资源状态和服务目标，把多个独立请求合并为批次执行。相比固定批次，它更适合请求持续到达、负载波动明显的推理服务。

连续批处理强调迭代级调度

Continuous Batching 更常出现在 LLM 生成任务中。由于生成过程通常按 token 或迭代推进，不同请求可能在不同时间结束。连续批处理通过迭代级调度，让新请求在合适时机进入正在运行的批处理流程，从而提升部署吞吐量。

动态批处理能带来哪些收益？

动态批处理的收益主要来自服务端调度和资源利用优化，而不是模型能力本身发生变化。

提高有效吞吐量

动态批处理会把多个单独请求合并成批次执行，使一次推理过程承载更多请求。对于高并发 LLM 推理服务，这有助于提高单位时间内完成的请求数量。

Continuous Batching 也常被定位为提升 LLM 部署吞吐量的方法，尤其适合生成长度不一致、请求持续进入的场景。

改善 GPU 利用率

当请求零散到达时，逐条执行容易造成 GPU 利用不足。动态批处理通过运行时合并请求，并在连续批处理场景中利用空出的序列位置补入新请求，有助于减少资源空转。

需要谨慎理解的是，GPU 利用率提升并不等于每个请求都更快返回。如果等待凑批时间过长，单请求感知延迟可能上升。因此部署时要结合业务目标设置调度策略。

通常不需要修改模型权重

从 Continuous Batching 的相关资料看，这类优化更接近推理服务调度和内存使用层面的优化，不需要修改模型权重；通常也不应被理解为模型能力本身的改造。

对于已经完成模型训练或微调的业务，动态批处理可以作为部署优化方向之一，在不重新训练模型的情况下改善服务效率。

在特定实现中可能改善生成延迟指标

在 vllm-ascend 文档的描述中，动态批处理会根据资源和 SLO 目标动态调整块大小，用于提高有效吞吐量并降低 TBT。这里应理解为：在特定实现和负载条件下，调度策略可以改善与生成过程相关的时间指标。

但不同框架、模型、硬件和请求分布会产生不同效果，不能脱离实际压测直接假设所有延迟都会下降。

使用动态批处理时需要关注哪些边界？

动态批处理适合做推理服务优化，但它不是万能方案。引入前应明确：它解决的是调度与资源利用问题，而不是模型语义能力、推理正确性或权重问题。

它不是模型能力改造

动态批处理不会让模型“更聪明”，也不会改变模型权重。它主要改变多个请求在服务端被组织和执行的方式。

如果业务问题来自模型效果不足、上下文设计不合理或提示词质量较差，动态批处理通常不能直接解决这些问题。

SLO 目标会影响调度策略

动态批处理需要围绕 SLO 目标做取舍。例如：

• 等待时间过短，批次可能太小，吞吐提升有限；
• 等待时间过长，批次更容易变大，但用户感知延迟可能增加；
• 批次或块大小过大，可能增加资源占用；
• 资源紧张时，调度策略需要避免局部吞吐优化影响整体稳定性。

要点： 动态批处理的关键不是追求最大批次，而是在业务可接受延迟内，获得更好的整体吞吐和资源利用。

不应直接套用固定配置

不同框架的参数、默认值、版本行为和硬件适配可能不同，生产环境不宜直接套用固定配置。更稳妥的做法，是围绕业务负载、延迟目标和资源占用进行压测评估：

• 请求是否持续到达；
• 输入和输出长度分布是否差异较大；
• 业务更看重吞吐还是响应延迟；
• GPU 利用率是否长期偏低；
• 是否有明确的 SLO 目标；
• 是否能通过压测观察批次大小、等待时间和资源占用变化。

动态批处理适合哪些应用场景？

动态批处理更适合在线推理服务，尤其是请求持续到达、单请求执行成本较高，并且希望在可接受延迟内提升整体吞吐的场景。

可以用下面的清单判断是否值得评估动态批处理：

• 是否存在稳定或突发的并发推理请求；
• 是否希望提升 LLM 推理吞吐量；
• 是否观察到 GPU 利用率不足或资源空转；
• 是否需要在明确 SLO 目标内做服务端调度；
• 是否希望不修改模型权重就优化部署效率；
• 是否能通过压测验证等待时间、批次大小和吞吐变化。

如果以上问题多数答案为“是”，动态批处理通常值得纳入 LLM 推理服务优化方案；如果请求量很低、延迟极其敏感且几乎没有并发，动态批处理带来的收益可能有限，甚至需要谨慎控制等待策略。