新闻详情

新闻详情

首页 / 资讯中心 / 详情

首词延时 Latency 揭秘 AI 推理中的“攒批”艺术

发布时间:2026/11/7 6:52:02来源:尧图网络
首词延时 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 仅需几分钱。
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

【外设】之大彩串口显示屏 2026/11/7 13:27:02

【外设】之大彩串口显示屏

大彩串口屏初步使用 1 .官网下载 STM32 屏幕 GUI 设计资料 http://www.gz-dc.com/category/typeid/4112 找到 STM32 Keil 工程,移植相关代码因项目而异进行移植,由于项目简单,本人只对用到的指令接口进行修改。 比如:注意事项&…

阅读更多 →
无法下载Windows系统iso文件 2026/11/7 0:39:20

无法下载Windows系统iso文件

当我遇到这个问题的时候,我打开了一个网站: 登录 然后我打算下载的时候: 突然那个官方的连接就可以下载了:

阅读更多 →
【清华代码熊】DeepSeek V4.1 Flash 后训练详解 2026/11/7 6:36:21

【清华代码熊】DeepSeek V4.1 Flash 后训练详解

📌 上期解析了 DeepSeek V4.1 Flash 模型架构改进,本期解析 DeepSeek V4.1 Flash 预训练/后训练技术: 🌟 预训练:45T 文本 多模态混合语料、直接训练 sparse attention(取消 DeepSeek V4 的 dense 冷启动&…

阅读更多 →
Shuffle-R1: Efficient RL framework for Multimodal Large Language Models via Data-centric Dynamic ... 2026/11/7 22:37:56

Shuffle-R1: Efficient RL framework for Multimodal Large Language Models via Data-centric Dynamic ...

文章主要内容和创新点 主要内容 本文聚焦于多模态大语言模型(MLLM)强化学习(RL)训练中的效率问题,提出了一个名为Shuffle-R1的框架。研究发现,当前RL训练存在两个关键缺陷: 优势值坍缩(Advantage Collapsing):批次中大多数优势值集中在零附近,导致有效梯度信号被淹…

阅读更多 →
PRvL: Quantifying the Capabilities and Risks of Large Language Models for PII Redaction 2026/11/6 14:29:05

PRvL: Quantifying the Capabilities and Risks of Large Language Models for PII Redaction

一、文章主要内容总结 本文聚焦于利用大型语言模型(LLMs)实现个人身份信息(PII)脱敏的研究,旨在解决传统脱敏方法(如基于规则的系统、领域特定命名实体识别(NER)模型)泛化能力差、跨格式/跨语境适应性弱的问题。 研究通过全面评估多种LLM架构(包括密集型LLM(D-LLM…

阅读更多 →
LLaVA-RE: Binary Image-Text Relevancy Evaluation with Multimodal Large Language Model 2026/11/6 14:29:07

LLaVA-RE: Binary Image-Text Relevancy Evaluation with Multimodal Large Language Model

文章主要内容和创新点 主要内容 本文聚焦于二进制图像-文本相关性评估任务(判断图像与文本“相关”或“不相关”),针对该任务中文本格式多样、相关性定义随场景变化等挑战,提出了基于多模态大语言模型(MLLM)的解决方案LLaVA-RE。 模型设计:LLaVA-RE基于LLaVA 1.5架构,…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉