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

balabala

DistServe

手抓饼熊：DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving


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

手抓饼熊：Splitwise: Efficient Generative LLM Inference Using Phase Splitting


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

• 洞察一：不同的推理服务可能具有广泛不同的提示和标记分布。
  
• 洞察二：混合连续批处理中的大部分时间都花在令牌阶段，很少有活动令牌进行批处理。
  
• 洞察三：对于大多数请求，大部分E2E时间都花在令牌生成阶段。
  
• 洞察四：提示阶段的批处理大小应限制在保证良好性能的范围内。相反，令牌生成阶段的批处理可以获得高吞吐量而没有任何不利影响。
  
• 洞察五：在提示阶段进行批处理受计算限制，而令牌阶段受内存容量限制。
  
• 洞察六：尽管提示阶段有效地利用了GPU的功耗预算，但令牌生成阶段没有。
  
• 洞察七：生成阶段可以在更便宜、性能较低的硬件上运行，以获得更好的性能/功耗和性能/价格效益。
  

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

手抓饼熊：Inference without Interference:Disaggregate LLM Inference for Mixed Downstream Workloads


相对于前两篇分离式架构，这篇文章的系统架构更为全面复杂一点，控制平面包含监控和全局调度器，这是工业分不少系统必不可少的部分。这篇文章有如下几个特点：
1，prefill阶段引入了类似ChunkAttention的方法，手抓饼熊：ChunkAttention: Efficient Self-Attention with Prefix-Aware KV Cache and Two-Phase Partition 。
2，调度这一块更详细了，整体看起来更像是一个大的工业化的分布式系统了，分为4个模块，分别是控制平面、prefill实例、decode实例、长度预测模块。
3，全局调度器：全局调度器属于控制平面的一部分，请求到来时，会选择一个负载最小的prefill实例，将请求发送给prefill实例。
4，引入了长度预测模块，prefill实例会根据长度预测的结果，以及decode实例的负载，使用本地调度器，选择一个decode，将请求发送给decode 实例。
5，实例翻转：prefill实例和decode实例可以相互转换。
MemServe

手抓饼熊：MemServe: Context Caching for Disaggregated LLM Serving with Elastic Memory Pool


TetriInfer和MemServe的作者高度重叠，怀疑是一个工作的不同时期演进。但是由于区别看起来还是有不少，所以也单独拿出来分享。
文章分析之前的工作都是请求内有优势，但是优化无法用于请求间（请求间有prompt共享、或者多轮对话），这一篇文章主要是在原来的分离式架构基础上，支持了Context Caching（请求间有prompt共享）。该文章的特点是以分离式架构和请求间prompt共享设计了一个Elastic Memory Pool，文章写的比较详细，建议对这方面感兴趣的可以全文阅读，了解细节。
Mooncake

这篇文章知乎大佬分析的多，整体如下：
许欣然：关于 Mooncake 的碎碎念
ZHANG Mingxing：Mooncake (1): 在月之暗面做月饼，Kimi 以 KVCache 为中心的分离式推理架构
方佳瑞：Mooncake阅读笔记：深入学习以Cache为中心的调度思想，谱写LLM服务降本增效新篇章
手抓饼熊：Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving
相对于前面的几篇文章，这篇文章涉及的技术更全面一些，所以要看懂的话，需要更多的背景知识，如序列并行。该文章加入了ChunkAttenion、请求间prompt共享、结合pipeline技术的序列并行等技术。
后记

关于分离式架构目前找到了这5篇文章。暂时命名大模型推理分离架构五虎将，后续有新的论文再实时更新名字。

原文地址：https://zhuanlan.zhihu.com/p/706218732