当前位置:首页 > 每日看点

如何评价DeepSpeed-FastGen这项工作?

卡卷网12个月前 (04-29)每日看点239

首先,还是老套路,先来看看在FastGen之前已有的技术方案,以及这些技术方案面临的问题。

FastGen前的方案及问题

  1. vLLM以及其Blocked KV Caching,详见:牛大脑袋:VLLM-PagedAttention评述 。其主要含义为将KVCache在内存上整合,以避免内存脆片,提升并发能力。
  2. Orca及连续批处理。其主要技术推动点就是在每次前向推理时独立做调度策略,也就是token级独立处理。

基于这两点,一个模型推理系统的大致流程是这样的:在每一步推理中,首先判断有没有需要处理的Prompt,如果有,并且序列数量未达上限,那么就停下来处理Prompt,然后把处理后的KVCache交给Decoding阶段做批推理。否则直接做批推理。

但这种方法有一个问题,生成过程会中断。这带来的影响是,占用率和响应速度下降了。什么意思呢?当batch很大的时候,每次Prompt计算一次,会让全部的batch都停下来等待,这就会让所有的生成时间都变长,尤其是当Prompt也很长的时候,这个等待时间就很长。同时,在这个阶段当中,因为生成过程停下来再重启,GPU利用率也在下降,同时这部分时间内,带宽利用率也下降。(因为Prompt阶段是一个计算密集型,带宽未到极限)。

FastGen的出发点和解决方案

FastGen主要解决的就是Prompt延时问题,解决的核心思路:“通过对提示(prompt)和生成(generation)的动态分拆与融合,进一步改进了连续批处理和系统吞吐量。”

这篇文章基于三个观点:

Token latency的耗时和batchsize无关,和token长度基本线性,所以token数量是影响延迟的核心。这里,对token latency具体是什么没有明确说,有两种可能,一种是prefill阶段的耗时;一种是decode阶段的耗时,随着seq长度增加,decode延时也增加。我更倾向于认为是prefill阶段的耗时,因为这和后文拆分prefill强相关,反之如果是decode延时的话,就不太对了,因为图上显示推理时间的增加几乎和token长度正比例增加,在我的经验中,应该是有一个基础的耗时,然后token增加带来的单token推理长度增加比较缓慢。

如何评价DeepSpeed-FastGen这项工作?  第1张

prefill token长度带来延时的变化

当token比较长时,计算效率达到最大。对计算来说,无论token多少,都需要加载全部weight,这部分带宽占用是固定的。在token较少的阶段,这部分受限于weight带宽,无法完全发挥算力。当token数增加后,带宽占用基本不变下,算力线性上升,因此算力逐渐增加达到GPU算力上限。这个GPU效率随着token变化的关系是一个凹的。

如何评价DeepSpeed-FastGen这项工作?  第2张

推理长度增加带来计算效率提高,并且,变化关系是凹的

为了让效率最高,理想的做法是让大任务和小任务结合起来,这样才能让效率最大化。展开来说,就是在prefill阶段,计算效率比较高,因为相对来说token数要多一些,而在decode阶段,计算效率相对较低,因为token数是1。把prefill和decode结合起来,效率要比prefill和decode分时做要高。对prefill来说是个计算密集型,对decode来说是个访存密集型,结合起来的话,计算利用率就会高。

但是为了做这个结合,在prefill和decode当中就需要做同步。特别是对prefill来说,需要把比较长的那种prefill拆分为短的prefill,也就是说做多次短prefill后再开始decode。理论上来说,这相当于在decode中间把prefill藏到流水线中,确实降低了prefill延时,但实现起来要考虑到decode延时(prefill和decode放在一起拖慢decode速度),因此提升效果有限,特别是对于decode比较长的。

总结

文章中的仿真结果也印证了这点。仿真的做法是挺鸡贼的,鸡贼之处在于,测试数据用的是长Prompt,短decode的。本来,Prompt和decode的长度分布是有一个固定分布的,绝不是这样。

如何评价DeepSpeed-FastGen这项工作?  第3张

数据来源:ACCELGEN: Heterogeneous SLO-Guaranteed High-Throughput LLM Inference Serving for Diverse Applications 实际数据分布输入长度和输出长度关系

真实数据分布和文章中测试数据对比

如何评价DeepSpeed-FastGen这项工作?  第4张

测试数据用的都是这种长Prompt短Generation数据

FastGen给出的算法,核心是解决了Prompt的耗时问题,以及如何把Prompt放在decode阶段的问题。但是为了解决这个问题,将Prompt的过程插入到decode阶段,造成了decode效率的某种降低。在其文章的测试中,鸡贼地用长Prompt短decode这种case,就是希望避免长decode过程把整体效果降低。

这篇文章的核心创新是将Prompt拆分后,藏到decode阶段上,以此降低系统总延时。但问题也是不少,第一,文章很多点没说清楚,比如延迟究竟是推理延迟还是prefill延迟,一个时钟片段做多长的prefill、多长的decode,这些统统没有说,更别说展开讨论了,要是有这部分,文章效果会好很多。第二,在测试时全部用的是长Prompt,短decode这种组合,不能证明实际算法的有效性,只能看成在某些特定场景下的优化,这点不指出的话有点误导人。不过话说回来,站在未来的视角去苛责过去的进步,也是有些强人所难,希望AI Infra领域可以有更多突破成果吧!

扫描二维码推送至手机访问。

版权声明:本文由卡卷网发布,如需转载请注明出处。

本文链接:https://www.kajuan.net/ttnews/2025/04/12781.html

分享给朋友:

相关文章

逾期后支付宝微信被冻结,显示执保该怎么办?

这几天有朋友问我说,他的微信零钱突然的用不了,问我是不是被冻结了,问我该怎么办?是不是被起诉了?这个,那个,别慌,别慌,还是那句老话:有钱就去协商,没钱只能暂时不管!但是真不管,这个被冻结的微信怎么办呢?今天针对这个问题,我就给大家做一哥比…

有了Istio,开发还需要微服务架构吗?

有了Istio,开发还需要微服务架构吗?

Istio 是一个开源的服务网格(Service Mesh),通过它可以实现对服务间通信的管理和监控。对于那些本身没有设计为具备安全功能的传统应用程序,Istio 可以提供一个“透明”的安全保护层,而不需要对应用本身进行任何代码修改。…

我觉得华为Mate60Pro明明配置不高,为什么还是有那么多人买呢?

我也好奇啊,所以闲聊时,我问了我们公司的副总,我说Mate60pro配置这么拉胯你怎么还买啊? 他一脸疑惑的看着我,配置?什么配置?我这手机信号挺好的啊? 我们总经理用的是去年华为出的折叠手机,花了一万多,我也想问问他同样的问题,但奈何一直…

什么样的网站能快速捕获你的心?

什么样的网站能快速捕获你的心?

大家好,我是程序员鱼皮。 大家如果平时使用网站或产品时出现了问题,一般都会去寻找 “联系客服” 的位置,从而获得人工的帮助。我们团队的面试刷题产品 - 面试鸭最近就遇到了这样一个难题:明明我们网站右下角就有联系客服按钮、而且我们每道面试题目…

鸿蒙系统到底是不是安卓系统?

你好,是的。 接下来我给不懂技术的人简单的说一下哄蒙系统的来龙去脉。 首先你要知道什么是开源。 ‌‌开源 (Open Source)全称为开放源代码‌,意味着任何人都可以获取和使用软件的源代码,并在遵守版权协议的前提下进行修改和再发布。‌1…

发表评论

访客

看不清,换一张

◎欢迎参与讨论,请在这里发表您的看法和观点。