连续批处理Continuous Batching是这样一种技术LLM 服务器不再等待整个批次全部跑完而是只要任何一个请求一完成就立刻把队列中等待的新请求放进空出来的位置让 GPU 时时刻刻都有活干。在这篇博客里我们将学习连续批处理——一种让 LLM 服务器在生成的每一步都保持 GPU 满负荷、从而同时服务远多于以往用户数的技术。我们将覆盖以下内容全局图景快速回顾LLM 如何生成 token为什么批处理对 LLM 很重要老办法静态批处理Static Batching静态批处理的问题什么是连续批处理拼车类比连续批处理逐步工作流程一个数值例子真实数字与加速效果连续批处理的收益几个重要说明快速总结全局图景在深入细节之前先看清全局。当许多用户同时向 LLM 发送请求时服务器必须处理所有这些请求。服务器跑在 GPU 上而 GPU 非常擅长并行地做许多小任务。为了充分利用 GPU服务器会把请求分组凑成一个批次batch同时处理。老式的批处理方式叫静态批处理Static Batching它让 GPU 干等新方式叫连续批处理Continuous Batching它让 GPU 每一步都在干活。一句话概括连续批处理 任何一个旧请求一完成立刻把新请求补进批次而不是等整个批次全部结束。仅这一个想法就让 LLM 服务器用同样的硬件服务多得多的用户。快速回顾LLM 如何生成 token要理解连续批处理必须先理解 LLM 是如何生成回复的。token 是一小块文本。它可以是一个单词、单词的一部分或者单个字符。LLM 一次生成一个 token。为了生成下一个 token它会查看到目前为止的所有 token预测最可能的下一个然后把它追加到文本里再继续预测下一个。如此往复直到模型决定停止。推理inference分两个阶段预填充阶段prefill phase模型一次性读入整个提示词prompt在单次前向传播中处理全部输入 token。在这趟传播中它为每个提示词 token 计算键Key和值Value并存进 KV 缓存KV Cache。预填充结束时模型产出第一个输出 token。这个阶段每个请求只发生一次在开始时。解码阶段decode phase模型一次生成一个 token。每个新 token 就是一步。一个 200 token 的回复意味着 200 个解码步。对我们来说关键点是这个生成回复不是一整块大任务而是数百个小步骤每步一个 token。正因为响应是每步产出 token服务器可以在每个 token 就绪的瞬间就发给用户而不必等整段回复完成即 token 流式输出Token Streaming。为了让解码更快服务器为每个请求保存一份 KV 缓存。KV 缓存保存着到目前为止所有 token 的键和值模型就不用在每一步重新计算它们。批次里的每个请求都有自己的 KV 缓存。为什么批处理对 LLM 很重要LLM 跑在 GPU 上。GPU 非常擅长同时对许多数据做同一类运算。如果只给 GPU 一个请求它的大部分算力都在闲置。为了让 GPU 忙起来服务器把许多请求放在一起处理这一组就叫批次batch。假设 8 个用户同时发来请求。服务器不再一个一个跑而是把 8 个合成一个批次一起跑。GPU 处理这 8 个请求的耗时和处理 1 个大致相同。这就是批处理重要的原因它让单块 GPU 同时服务许多用户而每个用户的等待时间并不比独占时长多少。但有个麻烦批次怎么组什么时候开始什么时候结束这正是静态批处理与连续批处理的分野。老办法静态批处理Static Batching在静态批处理中服务器收集一组固定数量的请求一起运行等全部完成之后才开始下一个批次。看看它是怎么运转的服务器收集比如说4 个请求组成一个批次。对这 4 个请求一起跑预填充阶段。然后跑解码阶段。每个解码步为这 4 个请求各产出 1 个新 token。持续解码直到批次中每个请求都完成。只有 4 个请求全部完成后服务器才开启下一个批次。这个方式简单、容易实现。但它有个严重的问题。静态批处理的问题问题在于不同请求的完成时间相差极大。一个用户可能问2 加 2 等于几“回复只有几个 token另一个用户可能要求写一篇关于气候变化的详细文章”回复有 1000 个 token。如果两者在同一个批次里短请求 5 个解码步就完成了。但批次还要再跑几百步因为长请求还没结束。那么短请求原先占的位置怎么样了它就那么空着。GPU 依然为这个空位置做计算但计算产出毫无用处纯属浪费。看出问题了吗在批次生命周期的绝大部分时间里只有少数几个位置在干有用的事其余的都空着等最慢的请求跑完。GPU 很忙但它做的大部分是无用功。而中途到达的新用户必须等当前整个批次结束才能轮到开始。于是连续批处理应运而生。什么是连续批处理连续批处理是这样一种跑批次的方式服务器不等待整个批次跑完。批次里任何一个请求一完成服务器立刻用队列中等待的新请求顶替它的位置。批次永远不闲着。每个位置始终在为某个请求做有用的事。我们不再把批次理解为一组同生共死的请求而是一组始终有人坐着的座位。关键想法很朴素静态批处理工作在请求粒度上连续批处理工作在token粒度上。在静态批处理里工作单位是一整个请求。所有请求同时开始全部结束批次才结束。在连续批处理里工作单位是此刻批次里所有人的一步解码。每走完一步解码服务器就检查有人完成了吗有就换出去。有新请求进来吗有就塞进来。拼车类比用一个现实世界的类比来理解。想象一辆 4 座拼车沿一条长线路行驶乘客到站一个个下车。静态批处理是这样4 名乘客起点上车。车每到一站都停着直到 4 名乘客全部到达目的地。哪怕一位乘客 5 分钟就到站了他的座位在剩余行程里一直空着。路边等车的新乘客上不来除非整趟行程结束、车返回再接下一批 4 人。连续批处理是这样4 名乘客起点上车。任何一位乘客一到站下车路边等待的新乘客立刻坐进空出来的座位。车永远坐着 4 个人座位不会空太久。哪辆车一天能服务更多乘客显然是后者。座位是昂贵的资源就要让它每一刻都满员。座位就是 GPU 的槽位slot乘客就是请求乘客在车上待的时长就是该请求生成的 token 数。连续批处理让每个 GPU 槽位在每一步都满着。连续批处理逐步工作流程我们走一遍采用连续批处理的服务器是怎么处理请求的。第 1 步服务器的批次有固定数量的槽位。设为 4 个。第 2 步请求到达队列。只要批次里有空位服务器就从队首取下一个请求放进槽位并为新请求跑预填充阶段准备好它的状态。第 3 步服务器为当前批次中的所有请求跑一步解码。每个请求得到 1 个新 token。第 4 步解码步之后服务器逐个检查请求。当模型产出停止 tokenstop token或达到最大长度时该请求即完成。完成的请求被移出槽位结果发回给用户。第 5 步服务器查看队列。若有等待中的请求就把它放入刚空出来的槽位并为它跑预填充。第 6 步服务器跑下一步解码。然后从第 4 步循环往复。整个流程长这样----------- | 队列 | - 新请求到达这里 ----------- | | 有空位就取队首 v ------------------------------- | 批次4 个槽位 | | [槽位 1] [槽位 2] | | [槽位 3] [槽位 4] | ------------------------------- | v ------------------------------- | 解码步 | | 每个槽位产出 1 个新 token | ------------------------------- | v ------------------------------- | 检查每个槽位 | | - 完成了移除并发送结果 | | - 空出来了从队列补入 | ------------------------------- | --- 回到解码步这个循环不停运转。每一步解码服务器都检查完成情况和新到请求。批次永远是满的。GPU 永远在做有用的事。一个数值例子用真实数字来说话。假设服务器有 4 个槽位。到达 4 个请求请求 A需要 100 个解码步请求 B需要 20 个解码步请求 C需要 50 个解码步请求 D需要 200 个解码步批次开跑后紧接着到达一个新请求 E。E 需要 30 个解码步。静态批处理下批次以 A、B、C、D 开始。E 在队列里等。各步的槽位状态如下[.]表示空槽位在做无用功槽位 1 槽位 2 槽位 3 槽位 4 队列 第 0 步: [A] [B] [C] [D] [E] 第 20 步: [A] [.] [C] [D] [E] - B 完成槽位空转 第 50 步: [A] [.] [.] [D] [E] - C 完成两个槽位空置 第 100 步:[.] [.] [.] [D] [E] - A 完成三个槽位浪费 第 200 步:[.] [.] [.] [.] [E] - D 完成批次结束从第 20 步起GPU 大部分时间都在为空槽位做无用功。E 在队列里干等了这么久直到第 200 步之后才终于得到一个槽位开始。连续批处理下批次同样以 A、B、C、D 开始。E 在队列里等。槽位 1 槽位 2 槽位 3 槽位 4 队列 第 0 步: [A] [B] [C] [D] [E] 第 20 步: [A] [E] [C] [D] [ ] - B 完成E 立刻补位 第 50 步: [A] [.] [.] [D] [ ] - E 和 C 同时完成 第 100 步:[.] [.] [.] [D] [ ] - A 完成 第 200 步:[.] [.] [.] [.] [ ] - D 完成E 在第 50 步就完成了而不是等到第 200 步才有机会开始。图里出现空槽位只是因为队列断了粮。在真实服务器持续有流量的情况下每个槽位每一步都满着GPU 一直在做有用的事。真实数字与加速效果再用真实数字感受一下能省多少。假设每个解码步在 GPU 上耗时 50 毫秒批次大小为 4 个槽位沿用上面那 5 个请求A100、B20、C50、D200、E30 个 token不用连续批处理静态时第 1 轮A、B、C、D 在批次中。批次跑到全部完成 200 步。 耗时200 x 50 ms 10,000 ms 10.0 s 第 2 轮E独自在下一个批次。跑 30 步。 耗时30 x 50 ms 1,500 ms 1.5 s 跑完全部 5 个请求总耗时11.5 s 生成 token 总数100 20 50 200 30 400 个 token连续批处理时5 个请求在同一条连续流水线上全部完成。 E 在第 20 步补位第 50 步完成。 最长的 D 在第 200 步完成。 跑完全部 5 个请求总耗时200 x 50 ms 10,000 ms 10.0 s 生成 token 总数400 个 token再看用户实际感受到的东西——每个请求的响应时间请求静态批处理连续批处理请求 A100 token5.0 s5.0 s请求 B20 token1.0 s1.0 s请求 C50 token2.5 s2.5 s请求 D200 token10.0 s10.0 s请求 E30 token11.5 s2.5 s快 4.6 倍平均6.0 s4.2 s用户 E 在静态批处理下先干等了 10 秒等上一批结束才能开始连续批处理下 E 立刻补位快了 4.6 倍。现在看看对真实负载的影响。假设 100 个请求到达服务器50 个短请求各 20 token50 个长请求各 200 token需要生成的 token 总数50 x 20 50 x 200 11,000 个。这里的关键指标是吞吐量throughput——服务器每秒产出的 token 数。吞吐量越高同样硬件能服务的用户越多。算术如下不用连续批处理 每个批次 4 个请求平均含 2 短 2 长。 批次跑到最长的完成 200 步。 批次数100 / 4 25 批 每批耗时200 x 50 ms 10 s 总耗时25 x 10 250 s 吞吐量11,000 tokens / 250 s 44 tokens/s 用连续批处理 队列持续补给槽位始终满员。 每步每槽产出 1 token 每步 4 个 token。 所需步数11,000 / 4 2,750 步 总耗时2,750 x 50 ms 137,500 ms 137.5 s 吞吐量11,000 tokens / 137.5 s 80 tokens/s 加速比80 / 44 1.8 倍 节省时间250 - 137.5 112.5 s同样的工作量少花 45% 时间把同样的对比放到时间轴上看时间秒: 0 50 100 150 200 250 不用: || 250 s 25 批、每批 200 步 用: || 137.5 s 连续流水线4 个槽位始终满员 -------- 节省 112.5 s --------同样的活儿服务器 137.5 秒干完而不是 250 秒。同样的硬件接近两倍的工作量。这就是连续批处理的漂亮之处。实践中对多数真实负载加速比在 2 到 4 倍之间。具体数字取决于请求长度的差异有多大差异越大收益越大流入流量有多平稳越平稳收益越大模型与硬件vLLM 等系统公开的基准测试表明连续批处理与 Paged Attention分页注意力结合相比朴素部署可获得超过 20 倍的吞吐量提升在同一块 GPU 上相比静态批处理也有 2 到 4 倍的提升。连续批处理的收益连续批处理带来三大收益更高吞吐量吞吐量是服务器每秒产出的 token 数。因为 GPU 始终在做有用的事每秒产出的 token 更多。在真实系统里吞吐量相比静态批处理常常能翻上数倍。更短等待时间新请求不必等整个批次结束一有空位就立刻补进去。用户会感觉服务器很快。更好的硬件利用率GPU 是 LLM 服务器里最贵的部件。连续批处理让它始终忙于有用的工作同样的 GPU 榨出更多价值。正因如此几乎所有现代 LLM 服务系统——如 vLLM、SGLang、TensorRT-LLM 等——都使用连续批处理。几个重要说明连续批处理与 Paged Attention 是天作之合。Paged Attention 解决 KV 缓存的内存浪费问题连续批处理解决静态批处理的算力浪费问题。两者合力才让单块 GPU 能同时服务众多用户vLLM 这样的服务系统就是把这两者组合起来的典范。连续批处理不改变模型本身。它不改变注意力的运作方式、token 的生成方式、模型的输出内容只改变服务器在 GPU 上调度请求的方式。每个用户得到的输出与其请求被单独运行时完全一致。批次大小不是无限的。GPU 内存有限批次里每个请求的 KV 缓存都要占内存。服务器选择的批次大小必须装得进内存批次满了新请求就在队列里等空位。用 KV 缓存压缩KV Cache Compression缩小每个请求的缓存是往同样内存里塞更多请求的一种办法。在连续批处理中新请求的预填充与其他所有人的解码步跑在同一块 GPU 上。当一个超长提示词到达时它的预填充可能让其他所有用户的解码暂停片刻。在超大规模场景下预填充-解码分离Prefill-Decode Disaggregation通过把预填充和解码放到不同 GPU 上运行来消除这个影响。本文示例中的数字为清晰起见做了一些简化新请求加入连续批次时的少量预填充开销被我们按零计静态批次的构成2 短 2 长是真实批次会围绕其波动的平均值。「请求长度差异越大、连续批处理赢数倍」这个定性结论在所有真实负载中均成立。快速总结回顾一下我们学到的LLM 一次生成一个 token。一个回复是数百个小解码步不是一整块大任务。批处理重要因为 GPU 最擅长同时对许多数据做同样的运算。静态批处理把一组固定请求一起跑等最慢的那个结束。提前完成的位置空转浪费 GPU 的功。连续批处理在任何旧请求完成的瞬间换入新请求批次永远满员。拼车类比静态批处理是等所有乘客到站的车连续批处理是一座位空出来就立刻接新客的车。token 级调度连续批处理工作在 token 粒度而非请求粒度。每一步解码服务器都检查完成情况与新到请求。收益更高吞吐量、更短等待时间、更好的 GPU 利用率。与 Paged Attention 是绝配两者合力解决了 LLM 服务的内存浪费与算力浪费两大问题。这就是连续批处理让 GPU 保持满负荷、让单台服务器同时服务更多用户的原理。常见问题连续批处理会改变模型的输出吗不会。连续批处理不改变模型、不改变注意力的运作方式、也不改变 token 的生成方式它只改变服务器在 GPU 上调度请求的方式。每个用户得到的输出与其请求被单独运行时完全一致。连续批处理比静态批处理快多少实践中对多数真实负载加速比在 2 到 4 倍之间。具体数字取决于请求长度的差异程度、流入流量的平稳程度以及模型和硬件。请求长度差异越大、流量越平稳收益越大。连续批处理和 Paged Attention 有什么区别Paged Attention 解决 KV 缓存的内存浪费问题连续批处理解决静态批处理的算力浪费问题。两者配合得非常好合力让单块 GPU 能同时服务众多用户。可以往连续批次里无限制地加请求吗不行。GPU 内存有限批次里每个请求的 KV 缓存都要占内存。服务器选择的批次大小必须装得进内存批次满了新请求就在队列里等空位。KV 缓存压缩是往同样内存里装更多请求的一种办法。连续批处理中一个超长提示词会拖慢其他用户吗会。新请求的预填充与其他所有人的解码步跑在同一块 GPU 上。当超长提示词到达时它的预填充可能让其他所有用户的解码暂停片刻。在超大规模场景下预填充-解码分离通过把预填充和解码放到不同 GPU 上运行来消除这个影响。
连续批处理Continuous Batching是这样一种技术LLM 服务器不再等待整个批次全部跑完而是只要任何一个请求一完成就立刻把队列中等待的新请求放进空出来的位置让 GPU 时时刻刻都有活干。在这篇博客里我们将学习连续批处理——一种让 LLM 服务器在生成的每一步都保持 GPU 满负荷、从而同时服务远多于以往用户数的技术。我们将覆盖以下内容全局图景快速回顾LLM 如何生成 token为什么批处理对 LLM 很重要老办法静态批处理Static Batching静态批处理的问题什么是连续批处理拼车类比连续批处理逐步工作流程一个数值例子真实数字与加速效果连续批处理的收益几个重要说明快速总结全局图景在深入细节之前先看清全局。当许多用户同时向 LLM 发送请求时服务器必须处理所有这些请求。服务器跑在 GPU 上而 GPU 非常擅长并行地做许多小任务。为了充分利用 GPU服务器会把请求分组凑成一个批次batch同时处理。老式的批处理方式叫静态批处理Static Batching它让 GPU 干等新方式叫连续批处理Continuous Batching它让 GPU 每一步都在干活。一句话概括连续批处理 任何一个旧请求一完成立刻把新请求补进批次而不是等整个批次全部结束。仅这一个想法就让 LLM 服务器用同样的硬件服务多得多的用户。快速回顾LLM 如何生成 token要理解连续批处理必须先理解 LLM 是如何生成回复的。token 是一小块文本。它可以是一个单词、单词的一部分或者单个字符。LLM 一次生成一个 token。为了生成下一个 token它会查看到目前为止的所有 token预测最可能的下一个然后把它追加到文本里再继续预测下一个。如此往复直到模型决定停止。推理inference分两个阶段预填充阶段prefill phase模型一次性读入整个提示词prompt在单次前向传播中处理全部输入 token。在这趟传播中它为每个提示词 token 计算键Key和值Value并存进 KV 缓存KV Cache。预填充结束时模型产出第一个输出 token。这个阶段每个请求只发生一次在开始时。解码阶段decode phase模型一次生成一个 token。每个新 token 就是一步。一个 200 token 的回复意味着 200 个解码步。对我们来说关键点是这个生成回复不是一整块大任务而是数百个小步骤每步一个 token。正因为响应是每步产出 token服务器可以在每个 token 就绪的瞬间就发给用户而不必等整段回复完成即 token 流式输出Token Streaming。为了让解码更快服务器为每个请求保存一份 KV 缓存。KV 缓存保存着到目前为止所有 token 的键和值模型就不用在每一步重新计算它们。批次里的每个请求都有自己的 KV 缓存。为什么批处理对 LLM 很重要LLM 跑在 GPU 上。GPU 非常擅长同时对许多数据做同一类运算。如果只给 GPU 一个请求它的大部分算力都在闲置。为了让 GPU 忙起来服务器把许多请求放在一起处理这一组就叫批次batch。假设 8 个用户同时发来请求。服务器不再一个一个跑而是把 8 个合成一个批次一起跑。GPU 处理这 8 个请求的耗时和处理 1 个大致相同。这就是批处理重要的原因它让单块 GPU 同时服务许多用户而每个用户的等待时间并不比独占时长多少。但有个麻烦批次怎么组什么时候开始什么时候结束这正是静态批处理与连续批处理的分野。老办法静态批处理Static Batching在静态批处理中服务器收集一组固定数量的请求一起运行等全部完成之后才开始下一个批次。看看它是怎么运转的服务器收集比如说4 个请求组成一个批次。对这 4 个请求一起跑预填充阶段。然后跑解码阶段。每个解码步为这 4 个请求各产出 1 个新 token。持续解码直到批次中每个请求都完成。只有 4 个请求全部完成后服务器才开启下一个批次。这个方式简单、容易实现。但它有个严重的问题。静态批处理的问题问题在于不同请求的完成时间相差极大。一个用户可能问2 加 2 等于几“回复只有几个 token另一个用户可能要求写一篇关于气候变化的详细文章”回复有 1000 个 token。如果两者在同一个批次里短请求 5 个解码步就完成了。但批次还要再跑几百步因为长请求还没结束。那么短请求原先占的位置怎么样了它就那么空着。GPU 依然为这个空位置做计算但计算产出毫无用处纯属浪费。看出问题了吗在批次生命周期的绝大部分时间里只有少数几个位置在干有用的事其余的都空着等最慢的请求跑完。GPU 很忙但它做的大部分是无用功。而中途到达的新用户必须等当前整个批次结束才能轮到开始。于是连续批处理应运而生。什么是连续批处理连续批处理是这样一种跑批次的方式服务器不等待整个批次跑完。批次里任何一个请求一完成服务器立刻用队列中等待的新请求顶替它的位置。批次永远不闲着。每个位置始终在为某个请求做有用的事。我们不再把批次理解为一组同生共死的请求而是一组始终有人坐着的座位。关键想法很朴素静态批处理工作在请求粒度上连续批处理工作在token粒度上。在静态批处理里工作单位是一整个请求。所有请求同时开始全部结束批次才结束。在连续批处理里工作单位是此刻批次里所有人的一步解码。每走完一步解码服务器就检查有人完成了吗有就换出去。有新请求进来吗有就塞进来。拼车类比用一个现实世界的类比来理解。想象一辆 4 座拼车沿一条长线路行驶乘客到站一个个下车。静态批处理是这样4 名乘客起点上车。车每到一站都停着直到 4 名乘客全部到达目的地。哪怕一位乘客 5 分钟就到站了他的座位在剩余行程里一直空着。路边等车的新乘客上不来除非整趟行程结束、车返回再接下一批 4 人。连续批处理是这样4 名乘客起点上车。任何一位乘客一到站下车路边等待的新乘客立刻坐进空出来的座位。车永远坐着 4 个人座位不会空太久。哪辆车一天能服务更多乘客显然是后者。座位是昂贵的资源就要让它每一刻都满员。座位就是 GPU 的槽位slot乘客就是请求乘客在车上待的时长就是该请求生成的 token 数。连续批处理让每个 GPU 槽位在每一步都满着。连续批处理逐步工作流程我们走一遍采用连续批处理的服务器是怎么处理请求的。第 1 步服务器的批次有固定数量的槽位。设为 4 个。第 2 步请求到达队列。只要批次里有空位服务器就从队首取下一个请求放进槽位并为新请求跑预填充阶段准备好它的状态。第 3 步服务器为当前批次中的所有请求跑一步解码。每个请求得到 1 个新 token。第 4 步解码步之后服务器逐个检查请求。当模型产出停止 tokenstop token或达到最大长度时该请求即完成。完成的请求被移出槽位结果发回给用户。第 5 步服务器查看队列。若有等待中的请求就把它放入刚空出来的槽位并为它跑预填充。第 6 步服务器跑下一步解码。然后从第 4 步循环往复。整个流程长这样----------- | 队列 | - 新请求到达这里 ----------- | | 有空位就取队首 v ------------------------------- | 批次4 个槽位 | | [槽位 1] [槽位 2] | | [槽位 3] [槽位 4] | ------------------------------- | v ------------------------------- | 解码步 | | 每个槽位产出 1 个新 token | ------------------------------- | v ------------------------------- | 检查每个槽位 | | - 完成了移除并发送结果 | | - 空出来了从队列补入 | ------------------------------- | --- 回到解码步这个循环不停运转。每一步解码服务器都检查完成情况和新到请求。批次永远是满的。GPU 永远在做有用的事。一个数值例子用真实数字来说话。假设服务器有 4 个槽位。到达 4 个请求请求 A需要 100 个解码步请求 B需要 20 个解码步请求 C需要 50 个解码步请求 D需要 200 个解码步批次开跑后紧接着到达一个新请求 E。E 需要 30 个解码步。静态批处理下批次以 A、B、C、D 开始。E 在队列里等。各步的槽位状态如下[.]表示空槽位在做无用功槽位 1 槽位 2 槽位 3 槽位 4 队列 第 0 步: [A] [B] [C] [D] [E] 第 20 步: [A] [.] [C] [D] [E] - B 完成槽位空转 第 50 步: [A] [.] [.] [D] [E] - C 完成两个槽位空置 第 100 步:[.] [.] [.] [D] [E] - A 完成三个槽位浪费 第 200 步:[.] [.] [.] [.] [E] - D 完成批次结束从第 20 步起GPU 大部分时间都在为空槽位做无用功。E 在队列里干等了这么久直到第 200 步之后才终于得到一个槽位开始。连续批处理下批次同样以 A、B、C、D 开始。E 在队列里等。槽位 1 槽位 2 槽位 3 槽位 4 队列 第 0 步: [A] [B] [C] [D] [E] 第 20 步: [A] [E] [C] [D] [ ] - B 完成E 立刻补位 第 50 步: [A] [.] [.] [D] [ ] - E 和 C 同时完成 第 100 步:[.] [.] [.] [D] [ ] - A 完成 第 200 步:[.] [.] [.] [.] [ ] - D 完成E 在第 50 步就完成了而不是等到第 200 步才有机会开始。图里出现空槽位只是因为队列断了粮。在真实服务器持续有流量的情况下每个槽位每一步都满着GPU 一直在做有用的事。真实数字与加速效果再用真实数字感受一下能省多少。假设每个解码步在 GPU 上耗时 50 毫秒批次大小为 4 个槽位沿用上面那 5 个请求A100、B20、C50、D200、E30 个 token不用连续批处理静态时第 1 轮A、B、C、D 在批次中。批次跑到全部完成 200 步。 耗时200 x 50 ms 10,000 ms 10.0 s 第 2 轮E独自在下一个批次。跑 30 步。 耗时30 x 50 ms 1,500 ms 1.5 s 跑完全部 5 个请求总耗时11.5 s 生成 token 总数100 20 50 200 30 400 个 token连续批处理时5 个请求在同一条连续流水线上全部完成。 E 在第 20 步补位第 50 步完成。 最长的 D 在第 200 步完成。 跑完全部 5 个请求总耗时200 x 50 ms 10,000 ms 10.0 s 生成 token 总数400 个 token再看用户实际感受到的东西——每个请求的响应时间请求静态批处理连续批处理请求 A100 token5.0 s5.0 s请求 B20 token1.0 s1.0 s请求 C50 token2.5 s2.5 s请求 D200 token10.0 s10.0 s请求 E30 token11.5 s2.5 s快 4.6 倍平均6.0 s4.2 s用户 E 在静态批处理下先干等了 10 秒等上一批结束才能开始连续批处理下 E 立刻补位快了 4.6 倍。现在看看对真实负载的影响。假设 100 个请求到达服务器50 个短请求各 20 token50 个长请求各 200 token需要生成的 token 总数50 x 20 50 x 200 11,000 个。这里的关键指标是吞吐量throughput——服务器每秒产出的 token 数。吞吐量越高同样硬件能服务的用户越多。算术如下不用连续批处理 每个批次 4 个请求平均含 2 短 2 长。 批次跑到最长的完成 200 步。 批次数100 / 4 25 批 每批耗时200 x 50 ms 10 s 总耗时25 x 10 250 s 吞吐量11,000 tokens / 250 s 44 tokens/s 用连续批处理 队列持续补给槽位始终满员。 每步每槽产出 1 token 每步 4 个 token。 所需步数11,000 / 4 2,750 步 总耗时2,750 x 50 ms 137,500 ms 137.5 s 吞吐量11,000 tokens / 137.5 s 80 tokens/s 加速比80 / 44 1.8 倍 节省时间250 - 137.5 112.5 s同样的工作量少花 45% 时间把同样的对比放到时间轴上看时间秒: 0 50 100 150 200 250 不用: || 250 s 25 批、每批 200 步 用: || 137.5 s 连续流水线4 个槽位始终满员 -------- 节省 112.5 s --------同样的活儿服务器 137.5 秒干完而不是 250 秒。同样的硬件接近两倍的工作量。这就是连续批处理的漂亮之处。实践中对多数真实负载加速比在 2 到 4 倍之间。具体数字取决于请求长度的差异有多大差异越大收益越大流入流量有多平稳越平稳收益越大模型与硬件vLLM 等系统公开的基准测试表明连续批处理与 Paged Attention分页注意力结合相比朴素部署可获得超过 20 倍的吞吐量提升在同一块 GPU 上相比静态批处理也有 2 到 4 倍的提升。连续批处理的收益连续批处理带来三大收益更高吞吐量吞吐量是服务器每秒产出的 token 数。因为 GPU 始终在做有用的事每秒产出的 token 更多。在真实系统里吞吐量相比静态批处理常常能翻上数倍。更短等待时间新请求不必等整个批次结束一有空位就立刻补进去。用户会感觉服务器很快。更好的硬件利用率GPU 是 LLM 服务器里最贵的部件。连续批处理让它始终忙于有用的工作同样的 GPU 榨出更多价值。正因如此几乎所有现代 LLM 服务系统——如 vLLM、SGLang、TensorRT-LLM 等——都使用连续批处理。几个重要说明连续批处理与 Paged Attention 是天作之合。Paged Attention 解决 KV 缓存的内存浪费问题连续批处理解决静态批处理的算力浪费问题。两者合力才让单块 GPU 能同时服务众多用户vLLM 这样的服务系统就是把这两者组合起来的典范。连续批处理不改变模型本身。它不改变注意力的运作方式、token 的生成方式、模型的输出内容只改变服务器在 GPU 上调度请求的方式。每个用户得到的输出与其请求被单独运行时完全一致。批次大小不是无限的。GPU 内存有限批次里每个请求的 KV 缓存都要占内存。服务器选择的批次大小必须装得进内存批次满了新请求就在队列里等空位。用 KV 缓存压缩KV Cache Compression缩小每个请求的缓存是往同样内存里塞更多请求的一种办法。在连续批处理中新请求的预填充与其他所有人的解码步跑在同一块 GPU 上。当一个超长提示词到达时它的预填充可能让其他所有用户的解码暂停片刻。在超大规模场景下预填充-解码分离Prefill-Decode Disaggregation通过把预填充和解码放到不同 GPU 上运行来消除这个影响。本文示例中的数字为清晰起见做了一些简化新请求加入连续批次时的少量预填充开销被我们按零计静态批次的构成2 短 2 长是真实批次会围绕其波动的平均值。「请求长度差异越大、连续批处理赢数倍」这个定性结论在所有真实负载中均成立。快速总结回顾一下我们学到的LLM 一次生成一个 token。一个回复是数百个小解码步不是一整块大任务。批处理重要因为 GPU 最擅长同时对许多数据做同样的运算。静态批处理把一组固定请求一起跑等最慢的那个结束。提前完成的位置空转浪费 GPU 的功。连续批处理在任何旧请求完成的瞬间换入新请求批次永远满员。拼车类比静态批处理是等所有乘客到站的车连续批处理是一座位空出来就立刻接新客的车。token 级调度连续批处理工作在 token 粒度而非请求粒度。每一步解码服务器都检查完成情况与新到请求。收益更高吞吐量、更短等待时间、更好的 GPU 利用率。与 Paged Attention 是绝配两者合力解决了 LLM 服务的内存浪费与算力浪费两大问题。这就是连续批处理让 GPU 保持满负荷、让单台服务器同时服务更多用户的原理。常见问题连续批处理会改变模型的输出吗不会。连续批处理不改变模型、不改变注意力的运作方式、也不改变 token 的生成方式它只改变服务器在 GPU 上调度请求的方式。每个用户得到的输出与其请求被单独运行时完全一致。连续批处理比静态批处理快多少实践中对多数真实负载加速比在 2 到 4 倍之间。具体数字取决于请求长度的差异程度、流入流量的平稳程度以及模型和硬件。请求长度差异越大、流量越平稳收益越大。连续批处理和 Paged Attention 有什么区别Paged Attention 解决 KV 缓存的内存浪费问题连续批处理解决静态批处理的算力浪费问题。两者配合得非常好合力让单块 GPU 能同时服务众多用户。可以往连续批次里无限制地加请求吗不行。GPU 内存有限批次里每个请求的 KV 缓存都要占内存。服务器选择的批次大小必须装得进内存批次满了新请求就在队列里等空位。KV 缓存压缩是往同样内存里装更多请求的一种办法。连续批处理中一个超长提示词会拖慢其他用户吗会。新请求的预填充与其他所有人的解码步跑在同一块 GPU 上。当超长提示词到达时它的预填充可能让其他所有用户的解码暂停片刻。在超大规模场景下预填充-解码分离通过把预填充和解码放到不同 GPU 上运行来消除这个影响。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
