ServerlessLLM：大型语言模型的低延迟无服务器推理
背景
当使用Serverless部署LLM时，由于用户需要的LLM模型（gpt-4o,openai-1o,Longchat-lite)，各式各样，将模型全部保存在本地存在巨量GPU开销。因此，Serverless平台需要将各种LLM的checkpoint缓存在远端存储中。在request到来时，Serverless平台为该请求分配GPU资源、拉取对应的LLM checkpoint以初始化该LLM实例。这显然会带来时延开销，尤其是LLM通常达GB/TB大小。
解决的问题/问题特点
高模型下载时间：从云存储中下载检查点（大小130G）需要26秒；
长时间模型加载：使用 PyTorch 将 OPT-30B 加载到 4 个 GPU 中需要 34 秒， 而将 LLaMA-2-70b 加载到 8 个 GPU 中需要 84 秒。 远远大于在推理过程中自己生成令牌的0.1秒。
被不认可的解决方案：
订阅过量GPU，配合冷启动和热启动；但是LLM需求太大了。
LLM通常很容易超过几百GB，使用主机内存是hold不住的；
部署额外的存储服务器，但是带宽金额，传输时间，也很不划算
创新点/解决方案
1.检查点：
什么是检查点？快照，模型的架构，每个张量的大小和形状，模型并行计划等。
在这边的优化：基于大块的顺序读取-分区，张量寻址-索引文件映射；
支持有序的张量块读取。简而言之就是原来checkpoint里包含了元数据和数据参数本身，数据参数本身就是连续的，把他们和非结构化的元数据剥离开，然后就可以对他们使用连续的数据读取了。然后这些元数据呢（层数、每层大小等）写入到索引表里，就可以快速的从连续空间中提取和复原张量了。
多层检查点检查：
并行的PCIe链路，将模型加载到GPU更快了；
对内存池进行一些缓存过期的操作，保持一些高频的模型参数；
内存碎片访问太慢了，用固定大小的内存块；
使用直接文件读取和锁存（pinned memory）。前者加速SSD到DRAM，后者加速从CPU内存到GPU显存。
实现多级存储读取。并在同一级存储内使用多线程优化，不同级别存储间使用流水线优化。
2.实时迁移：
对钩是表现优异的意思。
现在在Server2 中正在运行modelA
(a)可用性驱动的策略；在S1中将B从SSD加载到GPU， B的延迟太高了。
(b) 位置驱动的策略；B的延迟超级长，要等A执行完。
(c)抢占驱动的策略；减少了B的延迟，但是A模型执行重新加载和计算，需要大量时间
(d)实时迁移驱动的本地驱动策略；S2继续推理A，同时把一些中间状态转移给S1，这样S1不用重新计算。其他与（c)一致。
快照太慢了，提出基于令牌的迁移。（令牌是什么？我的理解是一些可以快速传输的东西，然后传过去再计算，因为计算时间小于传输大东西的时间）
通过两阶段迁移的方式，避免对正在进行的应用造成影响。
把模型A加载到目标服务器；如果目标服务器有，则不用加载了。
调度器告诉源服务器：目标服务器的地址
源服务器把输入令牌和已经产生的输出令牌，发送给目标服务器
目标服务器根据这些令牌，重新计算KV缓存
等第四步执行完，源服务器暂停推理，把这期间产生的输出令牌给目标服务器
调度器完成迁移，在源服务器上卸载A，加载B
路由表中标记一下，模型A现在在目标服务器上。两个服务器继续推理。
优化启动时间 模型调度
要不要迁移，迁移到哪一台server。
我要不要将模型C迁移到另一台服务器，然后把模型B从DRAM加载上来。
要先估计模型的加载时间（排队时间+模型大小/带宽）和模型的迁移时间（令牌+模型恢复时间）。
利用我们的时间估计技术，ServerlessLLM 评估所有服务器以加载即将到来的模型，选择提供最短估计启动时间的服务器。选择包括要分配的服务器 ID 和 GPU 插槽。 如果在考虑了迁移之后也没有GPU服务器能满足，那任务就等着。
实验
实验设置
采用真实的GPU集群，GPU集群有4台服务器；
每个服务器有4个GPU，还有一些存储的512GB内存和2TB的SSD。还有两块CPU。
工作负载，Gamma 分布到来时间。任务到来的请求频率。
主流的深度学习大模型参数，真实的LLM输入。
实验结果贴图
直接 I/O 并实现基于块的并行加载 ； 同层并行；不同层流水线；
在检查点方面做了很多优化，所以在加载速度和带宽利用率方面，深蓝色最优秀。
通过添加各种手段，批量处理，直接IO，多线程，固定内存块，流水线；让吞吐量越来越高。
ServerlessLLM支持实时迁移功能，本地性感知调度，多层检查点加载。
Shepherd* 抢占机制，也考虑本地性。
Serverless 随机选择，无迁移和抢占。
RPS（每秒钟能处理的请求数量）
在低中高三种RPS下，因为serverlessllm会迁移，所以绿色的线表现最优秀。
在不同的数据集和模型大小，serverlessllm绿色仍然优秀。主要是考虑本地性缓存的影响。
横坐标是模型的大小。
最先进的分布式模型服务系统 Ray Serve
Ray Serve的局限性：Ray Serve依赖于从远程存储下载模型，导致较高的启动延迟。
Ray Serve with Cache的改善：加了一点cache
serverlessllm，做了超级多优化。平均延时碾压前俩。
肯定是每个节点GPU越多，延时越小。模型数量（集群中同时管理的LLM总数）越多，肯定延时越多。
读后感
检查点那边太涉及CUDA，多级缓存了。PCLE
两个要解决的问题，第一个其实就是从云上下载东西太慢，所以我们从旁边的边缘节点下载；第二个就是（远程传输+本地计算）时间 < 模型从本地（SSD磁盘）加载时间。
和LLM关系(参数量很大）并不是很大，主要还是缩短冷启动时间。
工程上量很大，确实真实的考虑了将LLM装载和部署到GPU上，且考虑了LLM是一个很大的文件。
参考链接：
https://www.usenix.org/conference/osdi24/presentation/fu
https://github.com/ServerlessLLM/ServerlessLLM
