Edge of Context
Suche

· Aktualisiert

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

LoRAX Serving Leitfaden: Betrieb mehrerer LoRA Adapter auf Kubernetes

Ein einziger Basis-Model sowie zahlreiche LoRA-Adapter führen zu einem ungewöhnlichen Serving-Problem. Die Basis-Weights werden zwar gemeinsam genutzt, doch jeder Anfrage kann ein anderes Satz von Adapter-Weights-Komponenten benötigen. Ein herkömmliches Design, bei dem pro Variante ein einzelner Deployment verwendet wird, verschwendet GPU-Speicher, da die meisten Varianten in diesem Fall untätig bleiben.

LoRAX Es adressiert diesen sogenannten „Long Tail“. Der Mechanismus lädt Adapter nach Bedarf hoch, gruppiert Anfragen für verschiedene Adapter zusammen und bewegt die Adapter Weights zwischen der GPU- und der CPU-Arbeitsspeicherebene hin und her. Der ansprechende Slogan lautet: „Tausende fein abgestimmter Models auf einer einzigen GPU.“ Die technische Frage ist jedoch enger gefasst: Nutzen das aktuelle Set an aktivierten Adaptern, das Eintreffmuster sowie das Latency-Ziel ausreichend von einer geplanten Umschichtung, um einen weiteren Aufwand bei der Entwicklung eines Serving Runtime zu rechtfertigen?

Dieser Leitfaden beantwortet diese Frage, überprüft den API lokal und wandelt anschließend das Starter-Helm-Chart des Repositoriums in einen ausformulierten Produktionsplan um.

Zusammenfassung. Wählen Sie LoRAX, wenn viele kompatible LoRA-Adapter denselben Basis-Model teilen und der Datenverkehr spärlich oder langschwänzig ist. Die Kapazität hängt vom aktiven Arbeitsumfang ab und nicht von der Größe des Katalogs. Fixieren Sie den Runtime, authentifizieren sowie listen Sie die Adapter-IDs auf, fügen Sie eine zuverlässige Caching-Lösung für Artefakte sowie Prüfsignale hinzu, leiten Sie den Datenfluss unter Berücksichtigung der Cache-Localität um und Benchmark behandeln Sie kalte sowie warme Datenpfade getrennt voneinander.

Das Serving-Problem ist das Arbeitsmenge.

LoRA friert einen Basis-Model ein und lernt niedrig-rangige Aktualisierungen für ausgewählte Weight-Matrizen. Der resultierende Adapter ist in der Regel deutlich kleiner als ein vollständiger Checkpoint, doch seine Größe hängt weiterhin vom Rang, den Zielmodulen, der Anzahl der Schichten sowie vom Datentyp ab. Feststehende Angaben wie „jeder Adapter ist 100 MB groß“ liefern ungenaue Informationen zur Speicherkapazität.

Für Serving sind drei Größen zu unterscheiden:

Ein Katalog kann Tausende von Adaptern enthalten, ohne dass dadurch automatisch Tausende in VRAM untergebracht werden. Entscheidend sind vielmehr die Häufigkeit, mit der sich die aktive Menge ändert, die Größe dieser Adapter sowie die Möglichkeit, ob Anfragen nach verschiedenen Adaptern nützliche Datensätze teilen können.

LoRAX kombiniert vier Mechanismen:

  1. Die Basis Model bleibt für alle kompatiblen Adapter vor Ort vorhanden.
  2. Eine Anfrage gibt einen Adapter an, der aus Hugging Face, Predibase oder einem Dateisystem ermittelt werden kann.
  3. Der Scheduling-Prozess zum Austausch von Adaptern lädt Vorabdaten vor und überträgt Weights zwischen der GPU- und der CPU-Speicherebene.
  4. Heterogene Continuous Batching-Gruppen leiten Anfragen an unterschiedliche Adapter weiter.

Der LoRAX-Anfragenpfad von der Adapterauflösung bis zur Generierung

Der Projektbericht zeigt, dass heterogenes Batching Throughput sowie Latency im Laufe der Zunahme der Anzahl an parallelen Adaptern innerhalb des Benchmarks nahezu konstant halten. Behandeln Sie dies als Hypothese für Ihre Arbeitslast. Faktoren wie die Länge von Prompt, die Ausgabellänge, die Rangfolge, die Zielmodule, die Auslastung der Batch-Einheiten, der Cache-Churn sowie die Erstellung von GPU können das Ergebnis verändern.

Wenn LoRAX eine sinnvolle Wahl ist

LoRAX verdient einen Benchmark, wenn alle folgenden Bedingungen erfüllt sind:

Zu den typischen Anwendungsfällen gehören tenant-spezifische Assistenten, zahlreiche Domänenvarianten sowie Online-Experimente, die eine gemeinsame Basis Checkpoint teilen.

Die Anwendung ist weniger geeignet, wenn nur wenige Adapter den Datenverkehr dominieren, Models keine gemeinsame Basis aufweisen, starre Latency Ziele kalte Lasten nicht vertragen, oder die Plattform nicht sicher steuern kann, welche Artefakte der Server lädt. In solchen Fällen kann ein herkömmlicher vLLM oder TGI Deployment mit einer festgelegten Adapterliste einfacher zu handhaben sein.

Verwenden Sie Kubernetes nicht einfach deshalb, weil der Katalog sehr umfangreich ist. Überprüfen Sie zunächst die Kompatibilität von Runtime sowie des Adapters auf einem einzelnen GPU.

Überprüfen Sie einen Basis-Agenten sowie zwei Adapter lokal.

Die LoRAX README empfiehlt den vorkompilierten Container. In einer produktiven Umgebung sollte ein immutabler Image-Digest verwendet werden; main Es wird hier lediglich angezeigt, weil es sich um den im Repository dokumentierten Quick‑Start‑Tag handelt.

mkdir -p data

docker run --rm --gpus all --shm-size 1g \
    -p 8080:80 \
    -v "$PWD/data:/data" \
    ghcr.io/predibase/lorax:main \
    --model-id mistralai/Mistral-7B-Instruct-v0.1

Die dokumentierte Mindestanforderung umfasst Linux, Docker, eine Ampere- oder neuere NVIDIA GPU-Karte sowie Treiber, die mit CUDA 11.8 kompatibel sind. Lizenzen von Model sowie gesicherte Repositorys können zudem einen Hugging Face Token erfordern.

Beginnen Sie mit dem Basis-Model:

curl http://127.0.0.1:8080/generate \
    -H 'Content-Type: application/json' \
    -d '{
      "inputs": "[INST] Give one reason to measure cold-adapter latency. [/INST]",
      "parameters": {"max_new_tokens": 64}
    }'

Senden Sie anschließend einen kompatiblen Adapter:

curl http://127.0.0.1:8080/generate \
    -H 'Content-Type: application/json' \
    -d '{
      "inputs": "[INST] Solve: Natalia sold 48 clips in April and half as many in May. What is the total? [/INST]",
      "parameters": {
        "max_new_tokens": 64,
        "adapter_id": "vineetsharma/qlora-adapter-Mistral-7B-Instruct-v0.1-gsm8k"
      }
    }'

Die erste Anfrage kann den Adapter herunterladen und laden; spätere Anfragen können auf in Cache gespeicherte Artefakte sowie auf den residenten Weights zurückgreifen. Es sollten beide Pfade aufgezeichnet werden. Eine einzelne „warme“ Anfrage liefert nur begrenzte Informationen über das Verhalten bei selten auftretenden Anfragen.

Verwenden Sie den aktuellen OpenAI-Client

LoRAX stellt einen mit OpenAI kompatiblen Chat-Endpunkt bereit. Der model Das Feld gibt den Adapter an:

from openai import OpenAI


client = OpenAI(
    api_key="EMPTY",
    base_url="http://127.0.0.1:8080/v1",
)

response = client.chat.completions.create(
    model="alignment-handbook/zephyr-7b-dpo-lora",
    messages=[
        {"role": "user", "content": "Explain cache locality in two sentences."},
    ],
    max_tokens=100,
)

print(response.choices[0].message.content)

Standardmäßig benötigt der Server keinen API-Schlüssel. Dies ist für den lokalen Betrieb praktisch, stellt jedoch bei einer Konfiguration für den Internetzugang ein Sicherheitsrisiko dar. Authentifizierung, Berechtigungsverwaltung für verschiedene Nutzergruppen, Quotenregelungen sowie die Erlaubnisliste für Adapter sollten daher vor der Verwendung dieses Schlüssels implementiert werden.

Definieren eines Kompatibilitätschecks

Bevor ein Adapter in den Katalog aufgenommen wird, müssen mindestens folgende Punkte überprüft werden:

Lehnen Sie inkompatible Artefakte bereits während der Registrierung ab, anstatt dies erst bei der ersten Anfrage des Benutzers zu tun.

Verstehen Sie die Residenzregeln vor dem Bereitstellen

Speicherung von Adapter-Artefakten sowie die Residenz von Runtime in LoRAX

Der Basis-Model verbraucht den größten festen Anteil an GPU-Speicher. Adapter wie Weights und KV cache, der Batch-Arbeitsbereich sowie Runtime Kernels konkurrieren um den verbleibenden Speicher. CPU RAM kann ausgehängte Adapter speichern, während /data speichert die heruntergeladenen Artefakte.

Es handelt sich hierbei nicht um austauschbare Ebenen. Ein Datenträger- oder Hub-Objekt muss zunächst ausgelesen und materialisiert werden, bevor es zu einem CPU- oder GPU-residenten Adapter wird. Messen Sie die Übergänge getrennt voneinander:

PfadWas enthalten istMetrik zur Erfassung
GPU Anzahl der AufrufeAdapter bereits vorhandenWartezeit und Zeit bis zum ersten Aufruf von Token
CPU Anzahl der AufrufeÜbertragung oder Rematerialisierung in GPUVerzögerung durch Adapterlast und End-zu-Ende-Verarbeitung Latency
Artifakt-KollisionLiest von lokal /data CacheVerzögerung beim Lesen/Laden sowie Cache-Bytes
FernfehlschlagDownload sowie Validierung und LadenLadezeit, Fehler sowie vollständige Abkühlphase Latency

Capacity Planning muss die tatsächliche Verteilung der Popularität der Adapter wiedergeben. Einheitlich zufällig generierte Adapter-IDs führen zu einem anderen Cache-Problem im Vergleich zu einer workload-Struktur, die zipf’schem Verhalten ähnelt.

Implementieren Sie den Repository-Diagramm-Entwurf sorgfältig

Der Repositorium enthält charts/lorax,Daher bildet ein fixierter Repository-Revisionssstand zusammen mit einer lokalen Darstellung den wiederholbaren Ausgangspunkt:

git clone https://github.com/predibase/lorax.git
cd lorax
git checkout <reviewed-commit-or-release>

helm dependency update charts/lorax
helm template lorax charts/lorax -f values.production.yaml
helm upgrade --install lorax charts/lorax \
    --namespace inference \
    --create-namespace \
    -f values.production.yaml

Wie am 15. Juli 2026 geprüft, verdienen die Standardcharts Attention:

Dadurch dient der Diagramm als nützliches Hilfsmittel – nicht als Produktionsrichtlinie.

Beginnen Sie mit der tatsächlichen Wertstruktur des Diagramms.

Der Diagramm zeigt die Runtime-Konfiguration als Unterstruktur an deploymentDie Launcher-Argumente sind eine Liste von Namen/Wert-Paaren. Ein minimales Overlay sieht wie folgt aus:

deployment:
    replicas: 1

    image:
        repository: ghcr.io/predibase/lorax
        tag: "<tested-tag>" # Prefer an immutable digest in rendered manifests.

    args:
        - name: "--model-id"
          value: "mistralai/Mistral-7B-Instruct-v0.1"
        - name: "--max-input-length"
          value: "2048"
        - name: "--max-total-tokens"
          value: "3072"
        - name: "--max-batch-total-tokens"
          value: "8192"
        - name: "--max-batch-prefill-tokens"
          value: "4096"

    resources:
        requests:
            nvidia.com/gpu: "1"
        limits:
            nvidia.com/gpu: "1"

    readinessProbe:
        httpGet:
            path: /health
            port: http
        periodSeconds: 5
        failureThreshold: 600

service:
    serviceType: ClusterIP
    port: 80

Die oben genannten Grenzwerte für Token sind Beispielschwellenwerte und keine Empfehlungen zur Festlegung der Größe. Sie sollten anhand repräsentativer Prompts-Werte, der erwarteten Konkurrenzlast, des benötigten GPU-Speichers sowie von Load Tests abgeleitet werden.

Die Lücken explizit schließen

Das aktuelle Diagramm-Template enthält feste Werte. emptyDir Volumina sowie einfache Umgebungsvariablen. Ein gesicherter Deployment erfordert daher eine überprüfte Konfigurationsdatei Fork, einen Patch nach der Generierung oder eine höherwertige Manifestschicht, um Folgendes hinzuzufügen:

Platzieren Sie einen Hub Token nicht direkt in einer bereits kommitionierten Werte-Datei. Gehen Sie nicht davon aus, dass zwei Replikate eine nützliche Hochverfügbarkeit bieten, solange beide nicht in der Lage sind, die Basis Model zu laden, und solange das Router verhindern kann, dass alle „cold adapters“ an beide Pods gesendet werden.

Route zur Cache-Lokalität

Durch Round-Robin-Balancierung kann jede Replik zu einem „kalten“ Cache werden. Ein nützliches Router verknüpft mithilfe von Hashing oder ähnlichen Methoden eine bestimmte Adapter-ID mit einer Replik und stellt gleichzeitig einen Failover-Pfad bereit, falls diese Replik nicht verfügbar ist.

Der Schlüssel Routing muss aus dem authentifizierten Anwendungsstate stammen und nicht von einem willkürlichen Parameter einer öffentlichen URL. Andernfalls kann ein Aufrufer erzwungene Remote-Downloads veranlassen, Caches leeren oder versuchen, Namen privater Adapter herauszufinden.

LoRAX oder vLLM?

Der aktuelle vLLM kann LoRA-Module bereitstellen, die bei der Initialisierung deklariert werden, und sie außerdem über Endpunkte oder Resolver-Plugins dynamisch laden. In seiner eigenen Dokumentation wird darauf hingewiesen, dass das Aktualisieren des Runtime-Adapters Sicherheitsrisiken mit sich bringt und daher nicht in produktiven Umgebungen außerhalb eines isolierten, vertrauenswürdigen Kontexts eingesetzt werden sollte.

Der nützliche Vergleich ist eher operativ als numerisch:

FrageLoRAXvLLM
Wie werden Long-Tail-Adapter entdeckt?Der Adapter-ID kann auf Anfrage Hugging Face, Predibase oder Dateisystem- Artefakte auflösen.statische Module, dynamische Verwaltungsendpunkte oder Resolver-Plugins
Wie wird die Residenzverwaltung gesteuert?Explizite Planung des Austauschs von Adaptern zwischen GPU und CPUKonfigurierte Aktivitäts- und CPU LoRA-Limitierungen sowie Verhalten des Resolvers
Was ist die Anfrageschnittstelle?TGI-Stil /generate, Python‑Client sowie OpenAI-kompatibler ChatOpenAI-kompatible Serving sowie natives Python APIs
Was sollte entscheiden?Kalt/warm Latency, Cache-Churn, heterogene Batch-Prozesse Throughput sowie operative Anpassungsfähigkeitdieselben Kriterien für die Wiederholung der Arbeitslast und den Betrieb

Vermeiden Sie Formulierungen wie „LoRAX für 1.000 Adapter, vLLM für zehn“. Allein die Größe des Katalogs bestimmt die Leistung nicht. Benchmark – unabhängig vom gleichen Basismodul, den Adaptern, Prompts, den Rängen, der Ankunftszeit Trace sowie der Hardware.

Ein Produktions-Akzeptanztest

Bevor Sie den Katalog erweitern, führen Sie eine Wiedergabe durch, die Folgendes umfasst:

  1. Eine feste Hot-Set-Konfiguration zur Erstellung von Throughput und Latency.
  2. Eine Long-Tail-Verteilung zur Messung von CPU sowie der Anzahl der Cache-Zugriffe auf Artefakte.
  3. Ein Anstieg an zuvor nicht gesehenen, aber in der Allowlist enthaltenen Adaptern.
  4. Der Austausch von Pods zur Überprüfung der Wiederherstellung von Basiskomponenten und Adaptern.
  5. Ein nicht verfügbarer oder beschädigter Adapter zur Überprüfung der Isolierungsfunktionen sowie der Fallback-Mechanismen.
  6. Mehrere gleichzeitige Nutzer, um Authentifizierungsmechanismen, Quoten sowie Metrik-Labels zu überprüfen.

Überwachen Sie die Anfragenrate, die Wartezeit im Queue, die Zeit bis zum ersten Token, die Zeit zwischen den Token Latency, die Gesamtzeit Latency, die Ladezeit des Adapters, die Kategorie der Cache-Erfolge, den GPU sowie den CPU Speicherverbrauch, die heruntergeladenen Bytes sowie die Fehler nach Ursache. Vermeiden Sie es, Adapter-IDs in unbeschränkten Metrik-Bezeichnungen zu verwenden; führen Sie sie stattdessen in kontrollierte Dimensionen oder in gemessene Traces ein.

Definieren Sie vor dem Test die Akzeptanzschwellenwerte. Beispiele hierfür sind ein maximal zulässiger Fehleranteil im Kaltstart-Prozess, ein Zielwert für P99 im Warmstart-Zustand, ein Zielwert für Cache-Erfolge entsprechend der beobachteten Popularitätsverteilung sowie ein Zeitziel für die Wiederherstellung nach Verlust eines Pods.

Fazit

LoRAX wandelt viele kompatible Feinabstimmungen einer Flotte von Basis-Model-Kopien in ein Problem der Adapterplatzierung um. Dies kann für Workloads mit seltenen Anfragen eine vorteilhafte Architektur darstellen, führt aber per Definition nicht zu konstanten Kosten oder Latency-Werten. Der aktive Arbeitsbereich, der Austauschweg, die Mischung der Batch-Daten sowie die Speicherschicht bestimmen weiterhin das Endergebnis.

Überprüfen Sie zunächst diese Mechanismen anhand eines GPU. Anschließend sollten Sie Kubernetes ernst nehmen: Fixieren Sie die Artefakte, sichern Sie den Cache, schützen Sie die Zugangsdaten, autorisieren Sie die Adapter, leiten Sie die Anfragen lokal weiter und messen Sie jeden möglichen Verlauf der Datenverarbeitung. Sollte LoRAX unter denselben Bedingungen eine bessere Leistung als die aktuelle vLLM-Konfiguration erbringen, dann steht der Deployment-Entscheidung ein fundiertes Beweismittel zur Verfügung.

Referenzen