Welche Komponenten ermöglichen es mehreren lokalen Modellen, sich einen Beschleuniger zu teilen?

Mehrere lokale Modelle können sich einen Beschleuniger teilen, wenn die Serving-Schicht die Gewichtsspeicherung im Speicher, die dynamische Speichernutzung, die Ausführungszeit und die Anfrageisolierung über verschiedene Workloads hinweg koordiniert.

Eine Heim-GPU kann zwischen einem Chatmodell, einem Embedding-Modell, einem Vision-Encoder und einer Spracherkennung wechseln. Das dauerhafte Laden aller Gewichtssätze kann den VRAM übersteigen, während das Entladen bei jeder Anfrage die Latenz bis zum ersten Token unberechenbar macht. Ein Multi-Modell-Controller benötigt daher eine Speicherresidenz-Strategie, modellübergreifende Speicherabrechnung, Scheduling, Cache-Isolierung, Preemption und Fairness, statt sich darauf zu verlassen, dass separate Prozesse blind um Ressourcen konkurrieren.

Die Speicherresidenz-Strategie entscheidet, welche Gewichte verfügbar bleiben

Der Controller erfasst die Modellgröße, die Ankunftsrate, die Ladezeit, das Latenzziel und die jüngste Nutzung. Beliebte Modelle bleiben resident, selten genutzte Modelle werden im CPU-Speicher oder auf dem Speicher abgelegt, und eine prognostizierte Nachfrage kann das Vorwärmen auslösen, bevor die nächste Anfrage den Beschleuniger erreicht.

Multi-Modell-Vorwärmen bereitet universelle GPU-Worker für mehrere Modelle vor und koordiniert das Vorwärmen mit einer platzierungsbewussten Verdrängung. Die Ergebnisse zeigen, warum das Vermeiden eines kalten Ladevorgangs die Zeit bis zum ersten Token bei vorhersehbarer Nachfrage deutlich verbessern kann. Dieser Unterschied bleibt auch bei späteren Tests im Haushalt sichtbar.

Bei Entscheidungen zur Speicherresidenz sollten Quantisierungs- und Adaptervarianten berücksichtigt werden, da zwei scheinbar ähnliche Endpunkte unterschiedliche Basismodellgewichte enthalten können. Ein striktes Speicherlimit verhindert, dass proaktives Laden den KV-Cache aktiver Anfragen verdrängt. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung darauf aufbaut.

Modellübergreifende Speicherkoordination verhindert fragmentierte Kapazität

Gewichte bleiben größtenteils stabil, während Aktivierungen und KV-Caches mit Batch- und Sequenzlänge wachsen. Ein gemeinsamer Allocator kann Speicherseiten bei Bedarf zuordnen, ungenutzte Bereiche zurückfordern und Reservierungen offenlegen, damit ein Modell nicht den Speicher verbraucht, der einem anderen zugesagt wurde.

Modellübergreifende Speicherkoordination führt eine modellübergreifende Speicherkoordination mit dynamischer Zuordnung virtueller zu physischen Speicherseiten und Richtlinien für die gemeinsame Nutzung zur Laufzeit ein. Das Design erklärt, warum die gewöhnliche GPU-Nutzung auf Prozessebene nicht gut auf schnell wechselnde Modellanforderungen reagieren kann. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.

Speicherfreigabe ist keine Datenfreigabe. KV-Cache-Blöcke, Präfix-Caches, temporäre Puffer und Adapterzustände benötigen Mandanten- und Modellkennungen; andernfalls kann eine wiederverwendete Seite oder ein Cache-Schlüssel Kontext offenlegen oder Ergebnisse zwischen Endpunkten verfälschen.

Scheduling und Adapter-Multiplexing steuern die Ausführungszeit

Ein Scheduler entscheidet zwischen räumlicher Aufteilung, bei der Modelle gemeinsam Speicher belegen, und zeitlicher Aufteilung, bei der Kernel abwechselnd ausgeführt werden. Kontinuierliches Batching verbessert den Durchsatz, während Preemption und gewichtete Warteschlangen interaktive Anfragen vor langen Hintergrundaufgaben schützen.

Adapter-Multiplexing stellt Tausende von Low-Rank-Adaptern über gemeinsame Basismodelle bereit, indem es Adaptergewichte seitenweise lädt und heterogene Batches koordiniert. Dies zeigt, wie Spezialisierungen mehr Zustand gemeinsam nutzen können als vollständig getrennte Modellreplikate. Die praktischen Auswirkungen werden sichtbar, wenn mehrere Quellen um begrenzten Kontext konkurrieren.

Die Fehlergrenze liegt in Kernel- und Speicherinterferenzen. Zwei Modelle, die gleichzeitig in den Speicher passen, können ihre Latenzziele dennoch verfehlen, wenn sie um Rechenleistung, Bandbreite oder Kopier-Engines konkurrieren. Gemeinsame Nutzung ist nur dann sinnvoll, wenn die p95-Latenz und Fairness pro Modell innerhalb der Richtlinien bleiben, nicht wenn lediglich die Gesamtauslastung hoch aussieht.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Erstellen Sie eine Interferenzmatrix für die gemeinsame Modellnutzung

Messen Sie jedes Modell allein und führen Sie anschließend Tests für jedes wichtige Paar sowie für die erwartete Mischung aus vier Modellen mit kurzen, langen, stoßartigen und Hintergrundanfragen durch. Erfassen Sie die Kaltstart-Ladezeit, den belegten Speicher, das KV-Wachstum, die Kernel-Auslastung, den Durchsatz, die p50- und p95-Latenz sowie Verdrängungen.

Nutzen Sie das Prinzip des gerouteten Stacks aus gerouteter Modellresidenz, um jedem Endpunkt eine Priorität und eine Residenzklasse zuzuweisen. Wiederholen Sie die Tests mit Adaptern, quantisierten Varianten, kontinuierlichem Batching und Preemption und prüfen Sie dabei, dass Caches und Anfrageidentitäten isoliert bleiben.

Behalten Sie eine gemeinsame Nutzungsrichtlinie nur dann bei, wenn wichtige interaktive Modelle auch bei der ungünstigsten erwarteten Mischung ihr Latenzziel erreichen. Wenn ein Paar wiederholt Thrashing verursacht, serialisieren Sie dieses Paar oder reservieren Sie ein Zeitfenster, statt die Nebenläufigkeit für eine bessere Auslastungsgrafik zu erhöhen.