{\lambda}Scale: Enabling Fast Scaling for Serverless Large Language Model Inference

本文提出了名为$\lambda$Scale的高效无服务器大模型推理系统，其核心创新在于利用高速 RDMA 网络实现模型快速多播与“边加载边执行”的分布式推理机制，从而显著降低了模型启动开销并提升了应对突发负载的能力。

要点

这篇论文介绍了一个名为 𝜆Scale 的新系统，它的目标是让无服务器（Serverless）的大语言模型（LLM）推理变得更快、更省钱。

为了让你更容易理解，我们可以把整个系统想象成一个**“超级外卖配送网络”，而大语言模型就是“巨大的披萨”**。

1. 背景：现在的痛点是什么？

场景： 想象你开了一家卖巨型披萨（大模型）的店。平时生意冷清，但突然有一波订单洪峰（比如大家突然都想用 AI 聊天），你需要立刻在几十家分店同时烤出披萨。

现在的困难（冷启动问题）：

• 传统做法（慢）： 以前，分店接到订单后，得先去总仓库把整个巨大的披萨面团（模型文件）运过来，再开始烤。如果面团有 140GB 大，用普通快递（普通网络）运，可能需要十几分钟。等面团到了，客人早就饿晕了。
• 另一种做法（贵）： 为了不让客人等，有些店干脆24 小时备着面团（预加载模型）。但这就像为了偶尔的订单，让几十家分店都囤积着巨大的面团，既占地方（内存/显存），又浪费钱（GPU 资源闲置）。

核心矛盾： 要么等得久（冷启动慢），要么花钱多（资源浪费）。

2. 𝜆Scale 的解决方案：边运边烤（Execute-while-Load）

𝜆Scale 提出了一个天才的想法：“边运面团，边开始烤”。

它利用了两个关键优势：

1. 超级高速公路（RDMA 网络）： 现在的服务器之间连接着像 400Gbps 这样的超高速专线，比快递快得多。
2. 流水线作业： 不需要等整个面团运到，只要运到第一块，就可以开始切分、开始烤。

核心比喻：二项式流水线广播（Binomial Pipeline Multicast）

想象一下，你要把一张巨大的海报（模型）分发给 8 个朋友。

• 旧方法（树状分发）： 你先把海报给 A，A 再给 B 和 C，B 再给 D 和 E……像传声筒一样，一层层传，很慢。
• 𝜆Scale 的方法（二项式流水线）：
  • 你把海报撕成 4 块（分块）。
  • 你同时把第 1 块给 A，第 2 块给 B。
  • A 拿到第 1 块后，立刻把第 1 块传给 C，同时你给 A 第 3 块。
  • 关键点： 只要 A 拿到了第 1 块，他就可以立刻开始处理第 1 块的任务（比如开始推理），而不需要等第 2、3、4 块都到齐。
  • 这就是**“边运边烤”**。

3. 𝜆Scale 的三大绝招

为了让这个“边运边烤”完美运行，论文设计了三个核心机制：

① 智能分发策略（𝜆Pipe）

• 比喻： 就像是一个聪明的物流调度员。
• 作用： 它不只是简单地把模型传过去，而是根据网络情况，把模型切成最合适的“小块”，并安排谁先传哪一块。它让所有收到部分模型的分店（节点），立刻组成一个**“流水线团队”**。
• 效果： 哪怕模型还没传完，只要第一块到了，团队就能立刻开始干活（处理用户请求），大大减少了排队等待的时间。

② 动态切换模式（Mode Switching）

• 比喻： 从“接力赛”切换到“个人赛”。
• 作用： 在模型传输过程中，大家是“接力”干活（分布式推理）。一旦模型完全传到了某个分店，这个分店就立刻变成“独立门店”，自己全权处理后续请求，不再需要和其他店接力。
• 效果： 既利用了传输时的并行能力，又保证了传输完成后的本地高效运行，中间没有卡顿。

③ 灵活的记忆管理（Locality-driven Startup）

• 比喻： 智能冰箱和冷库。
• 作用： 模型可以存在不同的地方：
  • 热启动（GPU 显存）： 面团就在烤箱旁，秒级启动。
  • 温启动（内存）： 面团在冰箱里，拿过来很快。
  • 冷启动（硬盘/云端）： 面团在很远的冷库，需要时间。
• 效果： 𝜆Scale 能根据面团在哪里，自动选择最快的“搬运 + 烹饪”方案，不管面团在哪，都能快速响应。

4. 结果如何？

论文在真实的阿里云和 Azure 数据上测试了这套系统，效果惊人：

• 速度快： 相比现有的最先进方案，𝜆Scale 让90% 的用户等待时间（尾延迟）缩短了 5 倍。也就是说，以前要等 5 秒才能看到第一个字，现在只要 1 秒。
• 省钱： 因为不需要为了应对高峰而囤积大量闲置的 GPU 资源，成本降低了约 31%。
• 抗爆发： 面对突然的流量洪峰（比如大家突然都在用 AI），它能像变形金刚一样，瞬间“变”出更多分身来干活，而不会让系统崩溃。

总结

𝜆Scale 就像是一个**“零等待、零浪费”的超级外卖系统**。它不再死板地等待所有材料到齐再开工，而是利用超高速网络，让材料在运输途中就开始被加工。

• 以前： 等面团运到 -> 开始烤 -> 出餐（慢，且浪费资源）。
• 现在（𝜆Scale）： 面团运到第一块 -> 立刻开始烤第一块 -> 面团运到第二块 -> 立刻烤第二块（快，且省钱）。

这项技术让大模型在云端的使用体验更接近“即开即用”，让 AI 服务变得更便宜、更流畅。

技术摘要

这是一份关于论文 𝜆Scale: Enabling Fast Scaling for Serverless Large Language Model Inference 的详细技术总结。

1. 研究背景与问题 (Problem)

随着大语言模型（LLM）规模的不断增长，基于云端的无服务器（Serverless）推理服务面临着严峻的**冷启动（Cold Start）**挑战。现有的无服务器推理平台在处理动态、突发的工作负载时存在以下主要问题：

• 启动延迟高： 从远程存储（如 S3）加载大型模型到 GPU 需要数分钟，导致无法满足毫秒级或秒级的延迟要求。
• 资源浪费与成本高昂： 为了规避冷启动，现有方案通常采用“过度配置（Overprovisioning）”策略，即始终保持大量 GPU 实例处于活跃状态，这导致了极高的资源闲置成本和违背了无服务器“按量付费”的初衷。
• 缓存效率低： 尝试在主机内存（Host Memory）或 SSD 中缓存模型虽然能减少部分开销，但在多租户、大规模集群环境下，受限于内存容量和 SSD 传输带宽，缓存命中率低，且从 SSD 加载到 GPU 的速度仍然太慢（比内存慢一个数量级）。
• 缺乏动态扩展能力： 现有的分布式推理方案通常针对静态环境设计，缺乏在模型加载过程中动态构建执行流水线的能力，无法在负载激增时快速扩容。

2. 核心方法论 (Methodology)

论文提出了 𝜆Scale，一种高效的无服务器推理系统，旨在实现模型的快速扩展。其核心思想是利用 GPU 节点间的高速 RDMA 网络进行快速模型组播，并在模型传输过程中启用分布式推理执行，即 “边加载边执行”（Execute-while-Load）。

2.1 核心架构与组件

• 集群管理器 (Cluster Manager)： 负责调度用户查询、管理全局资源、协调模型扩展和流水线执行。
• 工作节点 (Worker Nodes)： 部署模型服务实例，包含节点控制器和模型管理器。模型管理器利用 GPUDirect RDMA (GDR) 技术，绕过主机内存直接在 GPU 间传输数据，并支持通过 RDMA 直接访问远程内存中的模型。
• 𝜆Pipe (核心方案)： 一种高效的模型扩展方案，支持自适应模型组播和动态执行流水线构建。

2.2 关键技术设计

1. 自适应模型组播 (Adaptive Model Multicast)：

   • 基于二项式流水线组播算法 (Binomial Pipeline Multicast)，将模型细分为块（Blocks）。
   • 采用 k 路传输策略 (k-way transmission)：将节点分为 $k$ 个子组，通过循环移位（Circular Shift）的方式优化块的传输顺序。这使得在传输过程中，不同的接收节点能尽早获得完整的模型分片，从而尽早开始构建执行流水线。
   • 相比传统的二叉树组播，二项式流水线能更好地利用集群带宽，显著降低传输延迟。

2. 流水线推理执行 (Pipelined Inference Execution)：

   • 在模型尚未完全加载到所有节点时，系统即可动态构建跨节点的执行流水线 (Execution Pipeline)。
   • 利用2D 流水线策略：在传输路径上分布的节点协同工作，每个节点处理模型的不同分片，并行处理多个请求批次。
   • 支持单 GPU 和多 GPU 场景，甚至利用节点内的 NVLink 进行快速本地复制，最大化资源利用率。

3. 模式切换 (Mode Switching)：

   • 当模型完全加载到所有节点后，系统无缝切换到本地执行模式，消除跨节点通信开销。
   • 通过重新计算 KV Cache（而非传输 KV Cache）来保证状态一致性，避免了昂贵的全对全通信。

4. 高效模型管理 (Efficient Model Management)：

   • ** locality-driven 启动：** 根据模型位置（GPU 热启动、主机内存温启动、冷启动）采用不同的启动策略。
   • 内存优化： 采用张量打包 (Tensor Packing) 将模型块映射到连续内存以提高传输效率，并进行GPU 内存预分配以减少运行时开销。

3. 主要贡献 (Key Contributions)

1. 提出了“边加载边执行”的新范式： 打破了传统“先加载完再执行”的限制，利用高速网络在模型传输过程中即可开始分布式推理，显著降低了冷启动延迟。
2. 设计了 𝜆Pipe 扩展方案： 结合了自适应二项式组播和动态流水线构建，实现了低延迟的模型分发和高效的分布式执行。
3. 实现了跨存储层的高效管理： 统一了 GPU 内存和主机内存的模型管理，支持从不同存储层级快速扩展模型实例。
4. 系统实现与开源： 基于 Derecho 和 Meta 的 Llama 推理框架进行了实现，代码将在论文接收后开源。

4. 实验结果 (Results)

作者在真实的 LLM 推理轨迹（包括 Alibaba Cloud 和 Azure OpenAI 的 BurstGPT 数据）和 H800 GPU 集群上进行了评估，对比了 ServerlessLLM、FaaSNet 和 NCCL 等基线系统。

• 传输延迟：
  • 在 12 个节点、70B 参数模型的场景下，𝜆Scale 的端到端组播延迟比 FaaSNet 快 1.82 倍，比 NCCL 快 1.53 倍。
  • 在 8 个节点上完成 Llama-13B 的扩展仅需 1 秒以内，比 NCCL 快 1.5 倍。
• 吞吐量 (Throughput)：
  • 在高负载下，𝜆Scale 达到峰值吞吐量的时间比基线系统快 2 到 4 倍（取决于 $k$ 值配置）。
  • 在冷启动场景下，𝜆Scale 的吞吐量提升幅度高达 3.75 倍至 11.4 倍。
• 延迟 (Latency)：
  • 在处理突发流量时，𝜆Scale 的 90% 尾延迟 (Tail Latency) 相比基线系统改善了 2.4 倍至 5 倍。
• 成本效益：
  • 在真实工作负载下，𝜆Scale 通过更弹性的资源调度，相比基线系统减少了 17.8% 至 31.3% 的 GPU 资源消耗（Cumulative GPU Time）。

5. 意义与影响 (Significance)

• 解决无服务器推理的痛点： 𝜆Scale 有效解决了大型模型在无服务器环境下的冷启动难题，使得在无需过度配置资源的情况下，也能应对突发的流量高峰。
• 提升资源利用率： 通过“边加载边执行”和动态流水线，大幅减少了 GPU 的闲置时间，真正实现了无服务器计算的经济效益。
• 推动 LLM 服务普及： 该方案降低了大规模 LLM 推理的门槛和成本，使得更多企业能够以低成本、低延迟的方式部署和扩展 AI 服务。
• 技术前瞻性： 将二项式组播算法与分布式推理流水线结合，为未来的大规模分布式 AI 系统提供了新的设计思路，特别是在利用 RDMA 网络进行细粒度协同计算方面。

总结来说，𝜆Scale 通过创新的系统架构和算法优化，成功实现了 Serverless LLM 推理的快速扩展和低成本运行，是云原生 AI 基础设施领域的一项重要进展。