为什么大模型“攒够一批请求才发车”反而能省大钱揭秘 AI 推理中的“攒批”艺术在使用 ChatGPT、DeepSeek 或 Claude 等大模型服务时你是否遇到过这样的现象按下回车后光标会微微“顿”那么零点几秒随后字迹就像开了快进一样啪啪啪吐出来这零点几秒的微小停顿其实是云服务商在后台默默做了一件“偷梁换柱”的事情——攒批Batching。服务器故意等了零点几秒把来自海量用户的几十个请求“攒”在一起打包送进 GPU。这种看似“牺牲少许首次响应时间”的操作正是各大 AI Infra人工智能基础设施厂商将 Token 价格打到极低水平的底牌。一、 根源大模型推理的“内存墙”要理解攒批为什么能省钱首先要看清大模型运行时的硬件困局。很多人的直觉是“GPU 算力越强大模型生成就越快。”但实际上大模型在 Decode逐字生成阶段的瓶颈根本不是“计算能力不足”而是“数据搬运太慢”。这就是计算机科学中著名的内存墙Memory Wall。我们把 GPU 拆成两个主要部分显存VRAM / HBM相当于“书桌”。大模型庞大的参数动辄几十到上百 GB在服务启动后就常驻在显存里。计算核心Tensor Cores / SRAM相当于“大脑”。这是真正做矩阵乘法的地方速度极快但容量极小根本放不下庞大的模型参数。当大模型每生成一个新词时GPU 内部都会经历如下循环搬运参数计算核心对显存喊话“把模型第 1 层到第 80 层的参数全部给我搬过来”数学计算计算核心拿到参数算出下一个 Token 的概率。覆盖清除计算核心容量太小算完必须清空准备迎接收下一个 Token。单用户调用的悲剧开重型卡车送一张明信片假设服务器来一个请求就立刻处理搬运参数耗时从显存搬运 100GB 参数到计算核心需要0.03 秒。计算耗时计算核心算这 1 个人的 1 个词仅需0.0001 秒。在这个过程中GPU 极强的计算能力有99% 的时间都在空转死等数据从显存慢吞吞地传输过来。这就好比开着一辆重型大卡车花费大量昂贵油钱跑了一趟只为了送一张明信片。二、 攒批Batching平摊数据搬运成本既然每次生成新词都逃掉要把几百 GB 的参数从显存拉到计算核心上跑一遍那能不能拉一次参数顺便把更多人的词一起算了这就是“攒批”的核心逻辑【单用户模式】 搬运 100GB 参数 ── 计算用户 A 的 1 个词 ── 产出1 Token 【32人攒批模式】 搬运 100GB 参数 ── 同时计算 A, B, C... 等 32 人的词 ── 产出32 Tokens因为 GPU 内部天生拥有成千上万个并行计算单元同时计算 1 个用户的向量和同时计算 32 个用户的向量所消耗的时间几乎没有差别都是 0.03 秒左右。成本核算的变化耗时依然是 0.03 秒左右显存数据搬运时间占据绝大部分。产出从原来的 1 个 Token 暴增到 32 个 Token。单价GPU 服务器是按每小时几十美元的固定成本租用的。在耗时几乎不变的情况下产出的 Token 总数翻了 32 倍分摊到每一个 Token 上的硬件成本直接降到了原来的 1/32。三、 演进从“静态攒批”到“动态连续批处理”在实际业务场景中“攒批”并不是简单的“等齐 32 个人就关门发车”因为大模型输出具有极高的随机性。用户 A问“11等于几”模型吐 2 个词结束符号 EOS就回答完毕了。用户 B让写“写一篇万字长文”模型需要持续吐 2000 个词。如果采用早期的静态攒批Static Batching就像一辆封闭的大巴车用户 A 早就回答完了但他不能下车必须在车上坐着等用户 B 吐完那 2000 个词整辆大巴才能解散。这会导致 GPU 显存 slot 严重浪费。为了解决这个问题现代推理引擎如 vLLM、TGI、SGLang 等引入了连续批处理Continuous Batching机制。“随时上下车”的环线公交连续批处理在极细粒度的“每生成一个词Iteration-level”维度上进行调度第 1 步GPU 搬运参数同时算 [A, B, C, D] 的下一个词。 第 2 步发现 A 吐出了结束符 EOSA 立即下车并把结果返回给用户。 第 3 步调度器不停车立刻把队列里等待的新用户 Z 塞进 A 腾出的空位。 第 4 步GPU 搬运参数同时算 [Z, B, C, D] 的下一个词……这样一来GPU 就像一辆永不停歇的环线公交车。有人回答完毕下车空位瞬间会被后台排队的乘客补满。GPU 的计算核心全程处于“满载”状态几乎没有任何一丝算力被浪费。四、 总结时间与成本的博弈AI Infra 的核心任务本质上是一场平衡的艺术极致的用户体验来一个请求算一个首字响应极快但 GPU 算力利用率极低运营成本昂贵。极致的商用成本稍微“攒”一下请求再计算连续批处理虽然牺牲了零点几秒的首字延迟TTFT却换来了吞吐量数十倍的提升和 Token 成本的断崖式下跌。正是由于这种“翻一次字典服务一群人”的硬件级优化云服务商才得以在保持高并发响应的同时将大模型 API 的价格降到每百万 Token 仅需几分钱。 首词延时 Latency 揭秘 AI 推理中的“攒批”艺术
为什么大模型“攒够一批请求才发车”反而能省大钱揭秘 AI 推理中的“攒批”艺术在使用 ChatGPT、DeepSeek 或 Claude 等大模型服务时你是否遇到过这样的现象按下回车后光标会微微“顿”那么零点几秒随后字迹就像开了快进一样啪啪啪吐出来这零点几秒的微小停顿其实是云服务商在后台默默做了一件“偷梁换柱”的事情——攒批Batching。服务器故意等了零点几秒把来自海量用户的几十个请求“攒”在一起打包送进 GPU。这种看似“牺牲少许首次响应时间”的操作正是各大 AI Infra人工智能基础设施厂商将 Token 价格打到极低水平的底牌。一、 根源大模型推理的“内存墙”要理解攒批为什么能省钱首先要看清大模型运行时的硬件困局。很多人的直觉是“GPU 算力越强大模型生成就越快。”但实际上大模型在 Decode逐字生成阶段的瓶颈根本不是“计算能力不足”而是“数据搬运太慢”。这就是计算机科学中著名的内存墙Memory Wall。我们把 GPU 拆成两个主要部分显存VRAM / HBM相当于“书桌”。大模型庞大的参数动辄几十到上百 GB在服务启动后就常驻在显存里。计算核心Tensor Cores / SRAM相当于“大脑”。这是真正做矩阵乘法的地方速度极快但容量极小根本放不下庞大的模型参数。当大模型每生成一个新词时GPU 内部都会经历如下循环搬运参数计算核心对显存喊话“把模型第 1 层到第 80 层的参数全部给我搬过来”数学计算计算核心拿到参数算出下一个 Token 的概率。覆盖清除计算核心容量太小算完必须清空准备迎接收下一个 Token。单用户调用的悲剧开重型卡车送一张明信片假设服务器来一个请求就立刻处理搬运参数耗时从显存搬运 100GB 参数到计算核心需要0.03 秒。计算耗时计算核心算这 1 个人的 1 个词仅需0.0001 秒。在这个过程中GPU 极强的计算能力有99% 的时间都在空转死等数据从显存慢吞吞地传输过来。这就好比开着一辆重型大卡车花费大量昂贵油钱跑了一趟只为了送一张明信片。二、 攒批Batching平摊数据搬运成本既然每次生成新词都逃掉要把几百 GB 的参数从显存拉到计算核心上跑一遍那能不能拉一次参数顺便把更多人的词一起算了这就是“攒批”的核心逻辑【单用户模式】 搬运 100GB 参数 ── 计算用户 A 的 1 个词 ── 产出1 Token 【32人攒批模式】 搬运 100GB 参数 ── 同时计算 A, B, C... 等 32 人的词 ── 产出32 Tokens因为 GPU 内部天生拥有成千上万个并行计算单元同时计算 1 个用户的向量和同时计算 32 个用户的向量所消耗的时间几乎没有差别都是 0.03 秒左右。成本核算的变化耗时依然是 0.03 秒左右显存数据搬运时间占据绝大部分。产出从原来的 1 个 Token 暴增到 32 个 Token。单价GPU 服务器是按每小时几十美元的固定成本租用的。在耗时几乎不变的情况下产出的 Token 总数翻了 32 倍分摊到每一个 Token 上的硬件成本直接降到了原来的 1/32。三、 演进从“静态攒批”到“动态连续批处理”在实际业务场景中“攒批”并不是简单的“等齐 32 个人就关门发车”因为大模型输出具有极高的随机性。用户 A问“11等于几”模型吐 2 个词结束符号 EOS就回答完毕了。用户 B让写“写一篇万字长文”模型需要持续吐 2000 个词。如果采用早期的静态攒批Static Batching就像一辆封闭的大巴车用户 A 早就回答完了但他不能下车必须在车上坐着等用户 B 吐完那 2000 个词整辆大巴才能解散。这会导致 GPU 显存 slot 严重浪费。为了解决这个问题现代推理引擎如 vLLM、TGI、SGLang 等引入了连续批处理Continuous Batching机制。“随时上下车”的环线公交连续批处理在极细粒度的“每生成一个词Iteration-level”维度上进行调度第 1 步GPU 搬运参数同时算 [A, B, C, D] 的下一个词。 第 2 步发现 A 吐出了结束符 EOSA 立即下车并把结果返回给用户。 第 3 步调度器不停车立刻把队列里等待的新用户 Z 塞进 A 腾出的空位。 第 4 步GPU 搬运参数同时算 [Z, B, C, D] 的下一个词……这样一来GPU 就像一辆永不停歇的环线公交车。有人回答完毕下车空位瞬间会被后台排队的乘客补满。GPU 的计算核心全程处于“满载”状态几乎没有任何一丝算力被浪费。四、 总结时间与成本的博弈AI Infra 的核心任务本质上是一场平衡的艺术极致的用户体验来一个请求算一个首字响应极快但 GPU 算力利用率极低运营成本昂贵。极致的商用成本稍微“攒”一下请求再计算连续批处理虽然牺牲了零点几秒的首字延迟TTFT却换来了吞吐量数十倍的提升和 Token 成本的断崖式下跌。正是由于这种“翻一次字典服务一群人”的硬件级优化云服务商才得以在保持高并发响应的同时将大模型 API 的价格降到每百万 Token 仅需几分钱。