技术摘要：FMplex – 用于服务可扩展基础模型的模型虚拟化

问题陈述

基础模型（FMs）已成为语言、视觉、时间序列和多模态等多种下游应用的核心支柱。然而，现有的模型服务系统（如 NVIDIA Triton）是围绕“每任务一实例”（instance-per-task）范式设计的，即每个定制化任务都会加载一个独立的、单独的模型副本。这种方法对于基础模型而言是低效的，原因如下：

1. 资源浪费： 基础模型由庞大的共享骨干网络（通常达数 GB）和轻量级的任务特定扩展（头部、适配器）组成。为每个任务加载完整的骨干网络会重复加载最沉重的组件，从而浪费加速器显存。
2. 效率损失： 独立的实例无法在不同任务之间实现批处理（batching）和加载成本的分摊。
3. 干扰与隔离： 仅仅将任务共同置于共享 GPU 上而不进行逻辑隔离，会导致跨任务干扰，即一个任务的负载激增会降低其他任务的性能。
4. 生命周期僵化： 当前系统将任务的生命周期与物理模型实例耦合在一起，使得在不重新部署整个骨干网络的情况下添加、删除或修改任务变得困难。

本文认为，基础模型的骨干网络应当被视为一种共享的系统底层（类似于操作系统虚拟化中的 CPU 或内存），而不是一个针对每个任务的部署产物。

方法论：FMplex

作者提出了 FMplex，这是一个引入了 基础模型虚拟化（Foundation Model Virtualization） 的服务系统。其核心概念是 虚拟基础模型（Virtual Foundation Model, vFM）——它是一个呈现给每个任务的逻辑上私有的基础模型实例，而该实例由一个共享的物理基础模型提供支持。

核心架构组件

1. 虚拟基础模型（vFM）抽象：

   • 解耦： vFM 将任务的逻辑视图（定制化、状态、生命周期）与物理骨干网络解耦。
   • 结构： 每个 vFM 包括一个 虚拟队列（用于请求路由）、任务扩展（编码器、解码器以及像 LoRA 这样的 PEFT 适配器）以及 状态/统计（SLO、优先级、权重）。
   • 机制： 当任务调用其 vFM 时，FMplex 会拦截该调用，将其路由至虚拟队列，并在共享的物理骨干网络上执行，同时应用任务特定的适配器。

2. 批处理感知公平队列（Batch-Aware Fair Queueing, BFQ）调度器：

   • 挑战： 标准的公平份额调度器（如起始时间公平队列，STFQ）是基于单个请求进行操作的，并未考虑到请求批处理带来的效率提升，而这对于基础模型的吞能至关重要。
   • 解决方案： BFQ 是一种工作守恒（work-conserving）的调度器，它在优化批处理的同时，近似实现了加权公平共享。
   • 运行机制： 它根据任务权重为请求分配开始/结束标签。它迭代地构建批次，直到达到最大规模（$B_{max}$）或触发 SLO 截止日期违规为止。
   • 适配器处理： BFQ 通过首先在公共骨干网络上进行批处理，然后顺序处理不兼容的适配器差异来处理适配器不兼容问题，从而在确保公平性的同时不牺牲批处理效率。
   • 基于 Token 的支持： 对于基于 Token 的基础模型（如 LLM），BFQ 在服务时间单位中对 Token 级别的计算量进行计费，以保持与请求级运行时间的连贯性。

3. Task-API 与服务栈：

   • Task-API： 一个允许用户通过将编码器、解码器和适配器附加到 vFM 来构建任务流水线的编程接口。它同时支持使用相同的流水线对象进行推理和微调。
   • FMplex-Controller： 一个管理部署计划的集群级控制器。它使用 “Max-Share” 启发式算法，尽可能将任务绑定到现有的物理骨干网络上，以最小化新的骨干网络实例化。
   • 弹性适配： 当负载变化时，系统可以将任务的 vFM 重新绑定到另一个现有的物理骨干网络，仅移动轻量级的任务状态（队列、适配器），而非重新加载沉重的骨干网络。

核心贡献

1. 用于部署共享的基础模型虚拟化： 引入了 vFM 抽象，允许多个独立定制的任务共享单个物理基础模型实例，同时保持逻辑隔离和独立的生命周期。
2. 基于共享的服务栈： 一个集成了用于可扩展任务构建的 Task-API 和用于共享感知集群部署的 FMplex-Controller 的端到端系统。
3. 原型实现： 一个功能完备的原型，支持多种模态（时间序列、视觉、LLM、VLM）和运行时（PyTorch, vLLM），展示了其跨异构基础模型的灵活性。
4. 全面评估： 在 7 个骨干网络（包含 16 个变体）和 92 个下游任务上进行了严格的评估。

实验结果

评估是在一个 16 节点的 AWS 集群（NVIDIA T4 GPU）上进行的，使用了合成数据和真实世界追踪数据（Azure Functions）。

• 延迟降低：

  • 与 空间分区（将任务隔离在 GPU 分区上）相比，FMplex 将延迟降低了高达 80%。
  • 与 尽力而为的共置（在单个 GPU 上部署多个完整实例但不进行隔离）相比，FMplex 将延迟降低了高达 33.3%。
  • 在集群规模下，与尽力而为的共置相比，FMplex 将平均延迟降低了 15%，并将 P99 延迟降低了 26%。

• 资源效率与可扩展性：

  • 显存： FMplex 显著降低了 GPU 显存占用。例如，将 10 个时间序列任务共置在共享骨干网络上仅需 1.17倍 于单个任务的显存，而独立部署则需要 10倍。
  • 吞吐量： 与尽力而为的共置相比，FMplex 在低负载（显存是瓶颈）下可维持高达 6倍 的任务量，在中小高负载（计算是瓶颈）下可维持 8–12% 更多的任务量。
  • 公平性： 在非对称服务权重（如 3:1）下，FMplex 在维持 84 RPS 的同时，保持了 0.97–0.98 的公平性得分。相比之下，非批处理公平共享在仅 37 RPS 时达到了类似的公平性，而无管理的共享则使公平性降至 0.66。

• 适配开销：

  • FMplex 展示了对工作量激增的快速响应。将任务重新绑定到现有骨干网络仅需 0.5 秒，而加载一个新的骨干网络实例（如非共享系统所要求的）则需要 ~58 秒，这会导致两个数量级的延迟峰值。

• 开销：

  • FMplex 引入的调度开销（队列处理和标签计算）极小，平均每个请求仅为 0.35 ms，相对于骨干网络的执行时间而言可以忽略不计。

意义与主张

本文主张 FMplex 解决了基础模型架构（沉重的共享骨干网络、轻量级的扩展）与当前服务系统（每实例部署）之间的根本性错配。通过将基础模型骨干网络视为虚拟化底层，FMplex 实现了：

• 部署共享： 将沉重的骨干网络显存和计算成本分摊到多个任务中。
• 任务隔离： 在不承担全量模型复制资源惩罚的前提下，提供单任务性能保证和隔离。
• 运维灵活性： 允许动态添加、删除或修改任务，而无需重新部署底层基础设施。

作者将 FMplex 定位为不仅是针对特定模型的优化，而是一个通用的系统层，它将经典的虚拟化原则扩展到了基础模型服务的领域，从而实现了更高效、更具扩展性的 AI 基础设施。