大模型推理分离架构五虎上将

文摘   2024-11-18 07:00   美国  

原文:https://zhuanlan.zhihu.com/p/706218732

DistServe

https://zhuanlan.zhihu.com/p/696864514


DistServe这篇文章比较容易读(prefill和generate分离,论文里并未考虑异构、容错、抢占,也没有涉及一些序列并行、prompt cache之类的)。下面介绍个人认为这篇文章的几个重要关注点:

1,详细从LLM推理角度详细的解释为什么要做prefill和genrate阶段分离,主要原因如下:

  • a,将单个预填充作业添加到解码请求的批处理中会显著减慢两个过程,导致TTFT和TPOT显著增加。

  • b,由于解码作业需要等待GPU上正在进行的预填充作业,解码作业可能会经历更长的排队延迟。

  • c,将预填充和解码阶段放置在同一GPU上不可避免地共享它们的资源和并行性设置。然而,每个阶段都具有其独特的计算特性和延迟要求,需要更多的异构资源分配。

  • d,预填充和解码阶段共同部署,增加解码批处理大小很困难因为这会与满足延迟目标相冲突,特别是在请求率高的情况下;

  • e,分离的架构,可以将多个预填充实例分配给单个解码实例,这种方法允许在专用GPU上积累更大的解码阶段批处理大小,而不会牺牲TPOT;可以进一步扩展解码批处理大小接近计算限制。随着解码批处理大小的增加接近计算限制,解码计算开始类似于预填充阶段。

2,prefill和generate分离之后,必然涉及到调度,这篇文章由于建模场景的限制,调度逻辑并不是很复杂,非常值得一读;

3,DistServe目前是开源的,值得对照源码一起查看。

 欢迎加入自动驾驶实战群


Splitwise

https://zhuanlan.zhihu.com/p/698537680

如上图所示,Splitwise也是一个prefill和generate分离的架构,下面介绍个人认为这篇文章的几个重要关注点,Splitwise论文个人觉得比较特色的是第三章,通过实验给了很多结论:

  • 洞察一:不同的推理服务可能具有广泛不同的提示和标记分布。

  • 洞察二:混合连续批处理中的大部分时间都花在令牌阶段,很少有活动令牌进行批处理。

  • 洞察三:对于大多数请求,大部分E2E时间都花在令牌生成阶段。

  • 洞察四:提示阶段的批处理大小应限制在保证良好性能的范围内。相反,令牌生成阶段的批处理可以获得高吞吐量而没有任何不利影响。

  • 洞察五:在提示阶段进行批处理受计算限制,而令牌阶段受内存容量限制。

  • 洞察六:尽管提示阶段有效地利用了GPU的功耗预算,但令牌生成阶段没有。

  • 洞察七:生成阶段可以在更便宜、性能较低的硬件上运行,以获得更好的性能/功耗和性能/价格效益。

这部分文章第四章同样讲的是调度以及kv cache传输,个人理解第一层机器间调度是分离架构所更关注的,第二层的机器内调度,和我们传统大模型推理调度类似(类似vllm的调度器概念,分离之后,不同的角色调度考虑不同),kv cache传输主要采用了按层传输,从而达到计算通信重叠;

TetriInfer

https://zhuanlan.zhihu.com/p/698629560

相对于前两篇分离式架构,这篇文章的系统架构更为全面复杂一点,控制平面包含监控和全局调度器,这是工业分不少系统必不可少的部分。这篇文章有如下几个特点:

1,prefill阶段引入了类似ChunkAttention的方法,https://zhuanlan.zhihu.com/p/699796352

2,调度这一块更详细了,整体看起来更像是一个大的工业化的分布式系统了,分为4个模块,分别是控制平面、prefill实例、decode实例、长度预测模块。

3,全局调度器:全局调度器属于控制平面的一部分,请求到来时,会选择一个负载最小的prefill实例,将请求发送给prefill实例。

4,引入了长度预测模块,prefill实例会根据长度预测的结果,以及decode实例的负载,使用本地调度器,选择一个decode,将请求发送给decode 实例。

5,实例翻转:prefill实例和decode实例可以相互转换。

MemServe

https://zhuanlan.zhihu.com/p/706165095

TetriInfer和MemServe的作者高度重叠,怀疑是一个工作的不同时期演进。但是由于区别看起来还是有不少,所以也单独拿出来分享。

文章分析之前的工作都是请求内有优势,但是优化无法用于请求间(请求间有prompt共享、或者多轮对话),这一篇文章主要是在原来的分离式架构基础上,支持了Context Caching(请求间有prompt共享)。该文章的特点是以分离式架构和请求间prompt共享设计了一个Elastic Memory Pool,文章写的比较详细,建议对这方面感兴趣的可以全文阅读,了解细节。

Mooncake

这篇文章知乎大佬分析的多,整体如下:

许欣然:关于 Mooncake 的碎碎念(https://zhuanlan.zhihu.com/p/705910725)

ZHANG Mingxing:Mooncake (1): 在月之暗面做月饼,Kimi 以 KVCache 为中心的分离式推理架构(https://zhuanlan.zhihu.com/p/705754254)

方佳瑞:Mooncake阅读笔记:深入学习以Cache为中心的调度思想,谱写LLM服务降本增效新篇章(https://zhuanlan.zhihu.com/p/706097807)

手抓饼熊:Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving(https://zhuanlan.zhihu.com/p/706109023)

相对于前面的几篇文章,这篇文章涉及的技术更全面一些,所以要看懂的话,需要更多的背景知识,如序列并行。该文章加入了ChunkAttenion、请求间prompt共享、结合pipeline技术的序列并行等技术。


最后别忘了,帮忙点“在看”。  

您的点赞,在看,是我创作的动力。


AiFighing是全网第一且唯一以代码、项目的形式讲解自动驾驶感知方向的关键技术。


长按扫描下面二维码,加入知识星球。




Ai fighting
全网第一且唯一分享自动驾驶实战,以代码、项目的形式讲解自动驾驶感知方向的关键技术,从算法训练到模型部署。主要致力于3D目标检测,3D目标追踪,多传感器融合,Transform,BEV,OCC,模型量化,模型部署等方向的实战。
 最新文章