Technisches Resümee: FMplex – Modell-Virtualisierung für das Serving erweiterbarer Foundation Models

Problemstellung

Foundation Models (FMs) sind zum Rückgrat für vielfältige Downstream-Anwendungen in den Bereichen Sprache, Vision, Zeitreihen und Multimodalität geworden. Bestehende Serving-Systeme (z. B. NVIDIA Triton) sind jedoch auf ein „Instance-pro-Aufgabe“-Paradigma ausgelegt, bei dem jede spezialisierte Aufgabe eine separate, unabhängige Kopie des Modells lädt. Dieser Ansatz ist für FMs ineffizient, weil:

1. Ressourcenverschwendung: FMs bestehen aus einem massiven, gemeinsamen Backbone (oft Gigabytes groß) und leichtgewichtigen, aufgabenspezifischen Erweiterungen (Heads, Adapter). Das Laden eines vollständigen Backbones für jede Aufgabe repliziert die schwerste Komponente und verschwendet so Beschleunigermemory.
2. Verlorene Effizienz: Unabhängige Instanzen verhindern die Amortisierung von Batching- und Ladekosten über verschiedene Aufgaben hinweg.
3. Interferenz und Isolation: Die bloße Ko-Lokalisierung von Aufgaben auf einem gemeinsamen GPU ohne logische Trennung führt zu Cross-Task-Interferenzen, bei denen Lastspitzen einer Aufgabe die Performance anderer Aufgaben verschlechtern.
4. Starre Lebenszyklen: Aktuelle Systeme koppeln den Lebenszyklus einer Aufgabe an die physische Modellinstanz, was es schwierig macht, Aufgaben hinzuzufügen, zu entfernen oder zu modifizieren, ohne den gesamten Backbone neu bereitzustellen.

Das Paper argumentt, dass der FM-Backbone als ein gemeinsames System-Substrat (analog zu einer CPU oder einem Speicher in der OS-Virtualisierung) behandelt werden sollte, anstatt als ein pro-Aufgabe-Bereitstellungsartefakt.

Methodik: FMplex

Die Autoren präsentieren FMplex, ein Serving-System, das Foundation Model Virtualization einführt. Das Kernkonzept ist das Virtual Foundation Model (vFM), eine logisch private FM-Instanz, die jeder Aufgabe präsentiert wird und die durch einen gemeinsamen physischen FM-Backbone gestützt wird.

Zentrale Architekturkomponenten

1. Virtual Foundation Model (vFM) Abstraktion:

   • Entkopplung: Das vFM entkoppelt die logische Sicht der Aufgabe (Anpassung, Zustand, Lebenszyklus) vom physischen Backbone.
   • Struktur: Jedes vFM umfasst eine Virtual Queue (für das Request-Routing), Task Extensions (Encoder, Decoder und PEFT-Adapter wie LoRA) sowie State/Accounting (SLOs, Prioritäten, Gewichte).
   • Mechanismus: Wenn eine Aufgabe ihr vFM aufruft, fängt FMplex den Aufruf ab, leitet ihn durch die virtuelle Warteschlange und führt ihn auf dem gemeinsamen physischen Backbone aus, wobei die aufgabenspezifischen Adapter nach Bedarf angewendet werden.

2. Batch-Aware Fair Queueing (BFQ) Scheduler:

   • Herausforderung: Standardmäßige Fair-Share-Scheduler (z. B. Start-Time Fair Queueing) operieren auf Basis einzelner Requests und berücksichtigen nicht die Effizienzgewinne durch Request-Batching, was für den Durchsatz von FMs entscheidend ist.
   • Lösung: BFQ ist ein work-conserving Scheduler, der eine gewichtete faire Teilung approximiert und gleichzeitig auf das Batching optimiert.
   • Funktionsweise: Er weist Requests basierend auf Task-Gewichten Start- und End-Tags zu. Er bildet iterativ Batches bis zu einer maximalen Größe ($B_{max}$) oder bis eine SLO-Deadline verletzt würde.
   • Adapter-Handhabung: BFQ bewältigt Inkompatibilitäten zwischen Adaptern, indem er Requests zuerst über den gemeinsamen Backbone batcht und dann inkompatible Adapter-Differenzen sequenziell verarbeitet, um Fairness ohne Einbußen bei der Batching-Effizienz zu gewährleisten.
   • Token-basierte Unterstützung: Für Token-basierte FMs (z. B. LLMs) berechnet BFQ die Token-basierte Arbeit in Service-Zeiteinheiten, um die Konsistenz mit den Request-Laufzeiten zu wahren.

3. Task-API und Serving Stack:

   • Task-API: Eine Programmierschnittstelle, die es Benutzern ermöglicht, Task-Pipelines zu konstruieren, indem sie Encoder, Decoder und Adapter an ein vFM binden. Sie unterstützt sowohl Inferenz als auch Fine-Tuning unter Verwendung desselben Pipeline-Objekts.
   • FMplex-Controller: Ein Cluster-Level-Controller, der den Bereitstellungsplan verwaltet. Er nutzt eine „Max-Share“-Heuristik, um Tasks bevorzugt an bestehende physische Backbones zu binden, wodurch die Instanziierung neuer Backbones minimiert wird.
   • Elastische Anpassung: Bei Laständerungen kann das System ein vFM eines Tasks an einen anderen existierenden physischen Backbone umbinden, wobei nur der leichtgewichtige Task-Zustand (Queues, Adapter) verschoben wird, anstatt den schweren Backbone neu zu laden.

Zentrale Beiträge

1. FM-Virtualisierung für Deployment-Sharing: Die Einführung der vFM-Abstraktion, die es ermöglicht, dass mehrere unabhängig angepasste Tasks eine einzige physische FM-Instanz teilen, während logische Isolation und unabhängige Lebenszyklen gewahrt bleiben.
2. Sharing-basierter Serving Stack: Ein End-to-End-System, das die Task-API zur erweiterbaren Task-Konstruktion und den FMplex-Controller zur Sharing-bewussten Cluster-Bereitstellung integriert.
3. Prototyp-Implementierung: Ein funktionaler Prototyp, der mehrere Modalitäten (Zeitreihen, Vision, LLMs, VLMs) und Runtimes (PyTorch, vLLM) unterstützt und Flexibilität über heterogene FMs hinweg demonstriert.
4. Umfassende Evaluierung: Eine rigorose Evaluierung über 7 Backbone-FMs (16 Varianten) und 92 Downstream-Tasks.

Experimentelle Ergebnisse

Die Evaluierung wurde auf einem 16-Knoten-AWS-Cluster (NVIDIA T4 GPUs) unter Verwendung synthetischer und realer Traces (Azure Functions) durchgeführt.

• Reduktion der Latenz:

  • Im Vergleich zu Spatial Partitioning (Isolierung von Tasks auf GPU-Partitionen) reduzierte FMplex die Latenz um bis zu 80 %.
  • Im Vergleich zu Best-Effort Co-location (mehrere volle Instanzen auf einer GPU ohne Isolation) reduzierte FMplex die Latenz um bis zu 33,3 %.
  • Auf Cluster-Ebene reduzierte FMplex die mittlere Latenz um 15 % und die P99-Latenz um 26 % im Vergleich zu Best-Effort Co-location.

• Ressourceneffizienz und Skalierbarkeit:

  • Speicher: FMplex reduziert den GPU-Speicherverbrauch signifikant. Beispielsweise erforderte die Ko-Lokalisierung von 10 Zeitreihen-Tasks auf einem gemeinsamen Backbone nur das 1,17-fache des Speichers eines einzelnen Tasks, verglichen mit dem 10-fachen bei einer unabhängigen Bereitstellung.
  • Durchsatz: FMplex konnte bei geringer Last (wo der Speicher der Flaschenhals ist) bis zu 6-mal mehr Tasks und bei moderater bis hoher Last (wo die Rechenleistung der Flaschenhals ist) 8–12 % mehr Tasks aufrechterhalten als Best-Effort Co-location.
  • Fairness: Unter asymmetrischen Service-Gewichten (z. B. 3:1) hielt FMplex Fairness-Scores von 0,97–0,98 bei gleichzeitig 84 RPS aufrecht. Im Gegensatz dazu erreichte ein nicht-gebatchter Fair-Sharing eine ähnliche Fairness bei nur 37 RPS, während unmanaged Sharing die Fairness auf 0,66 absinken ließ.

• Anpassungs-Overhead:

  • FMplex zeigte eine schnelle Anpassung an Workload-Spitzen. Das Umbinden eines Tasks an einen existierenden Backbone dauerte 0,5 Sekunden, während das Laden einer neuen Backbone-Instanz (wie bei Nicht-Sharing-Systemen erforderlich) etwa 58 Sekunden dauerte, was einen zwei Größenordnungen höheren Latenzsprung verursachte.

• Overhead: Der durch FMplex eingeführte Scheduling-Overhead (Queue-Handling und Tag-Berechnung) war minimal und betrug durchschnittlich 0,35 ms pro Request, was im Vergleich zu den Backbone-Ausführungszeiten vernachlässigbar ist.

Bedeutung und Ansprüche

Das Paper behauptet, dass FMplex den grundlegenden Mismatch zwischen der Architektur von Foundation Models (schwere, gemeinsame Backbones, leichte Erweiterungen) und aktuellen Serving-Systemen (pro-Instanz-Bereitstellung) adressiert. Durch die Behandlung des FM-Backbones als Virtualisierungs-Substrat ermöglicht FMplex:

• Deployment Sharing: Die Amortisierung der hohen Speicher- und Rechenkosten des Backbones über mehrere Tasks hinweg.
• Task-Isolation: Bereitstellung von Performance-Garantien und Isolation pro Task ohne den Ressourcenaufwand einer vollständigen Modellreplikation.
• Operationale Flexibilität: Das Hinzufügen, Entfernen oder Modifizieren von Tasks dynamisch, ohne die zugrunde liegende Infrastruktur neu bereitstellen zu müssen.

Die Autoren positionieren FMplex nicht nur als Optimierung für spezifische Modelle, sondern als generalisierbare Systemschicht, die klassische Virtualisierungsprinzipien auf den Bereich des Foundation Model Servings erweitert und somit ein effizienteres und skalierbareres KI-Infrastruktur-Management ermöglicht.