LoRAX: Tausende LoRA-Adapter auf einer GPU, mit einem Preis bei der Speicherverwaltung

Das Problem: viele Fine-Tunes, eine knappe GPU

Wer pro Kunde oder pro Aufgabe ein eigenes fine-tuned Modell betreibt, zahlt für jedes Modell den vollen Speicherbedarf der Gewichte. Bei einem 7B-Modell in fp16 sind das grob 14 GB, und die passen nicht mehrfach auf eine Karte. LoRAX setzt stattdessen auf ein geteiltes Basisgewichtsmodell und lädt nur die LoRA-Gewichte pro Anfrage nach. Die Beschreibung nennt als Ziel, Tausende fine-tuned Modelle auf einer GPU zu servieren. Die Zielgruppe ergibt sich daraus: Plattformteams, die eine gemeinsame Basis wie Llama, Mistral oder Qwen betreiben und darauf viele kleine, aufgabenspezifische Adapter ausrollen. Ein einzelnes Modell ohne Adapter ist nicht der Anwendungsfall, für den die Architektur gebaut ist.

Adapter-Exchange-Scheduling und heterogenes Continuous Batching

Der Kern liegt im Zusammenspiel zweier Mechanismen. Heterogeneous Continuous Batching packt laut Feature-Liste Anfragen für verschiedene Adapter in denselben Batch und hält Latenz und Durchsatz nahezu konstant, wenn die Zahl gleichzeitiger Adapter steigt. Möglich wird das, weil das Basisgewichtsmodell für alle Anfragen identisch ist und nur die Adaptergewichte pro Sequenz variieren. Der zweite Mechanismus ist Adapter Exchange Scheduling: Adapter werden asynchron zwischen GPU- und CPU-Speicher vorausgeladen und ausgelagert, und die Batch-Bildung wird auf den Gesamtdurchsatz des Systems abgestimmt. Der entscheidende Punkt ist die Asynchronität. Ein neu angeforderter Adapter wird just-in-time geladen, ohne laufende Anfragen zu blockieren. Wer das selbst baut, landet fast zwangsläufig bei einem synchronen Ladevorgang, der die GPU währenddessen leer laufen lässt. Die Release Notes zu v0.12.0 nennen zusätzlich Multi-LoRA Prefix Caching und einen fp8 KV-Cache, beides Stellschrauben für den Speicherverbrauch bei langen Kontexten.

Was unter der Haube an Inferenz-Optimierungen steckt

LoRAX nennt drei kompilierte CUDA-Kernel: flash-attention, paged attention und SGMV. SGMV steht für Segmented Gather Matrix-Vector Multiplication und ist der rechenintensive Teil, wenn mehrere Adapter im selben Batch unterschiedliche Gewichte verwenden. Ohne einen solchen Kernel müsste die Matrixmultiplikation pro Adapter getrennt laufen, was den Vorteil des gemeinsamen Batches wieder auffrisst. Dazu kommen Tensor-Parallelismus für die Verteilung über mehrere GPUs, Quantisierung und Token-Streaming. Die Basisgewichte lassen sich in fp16 oder quantisiert mit bitsandbytes, GPT-Q oder AWQ laden. Angepasst werden können laut Dokumentation beliebige lineare Schichten des Modells. Das ist eine Einschränkung, die man kennen sollte: Wer Adapter mit anderen Zielmodulen trainiert hat, findet sie hier möglicherweise nicht wieder.

Inbetriebnahme über den vorgebauten Container

Die Dokumentation empfiehlt ausdrücklich den vorgebauten Docker-Container, um das Kompilieren eigener CUDA-Kernel zu vermeiden. Das ist ein ehrlicher Hinweis darauf, wie aufwendig ein Build aus dem Quellcode wäre. Die Mindestanforderungen sind eine Nvidia-GPU ab Ampere, CUDA-11.8-kompatible Treiber, ein Linux-System und Docker. Nach der Installation des nvidia-container-toolkit folgen die beiden bekannten Schritte: systemctl daemon-reload und systemctl restart docker. Der Start sieht dann so aus: model=mistralai/Mistral-7B-Instruct-v0.1, volume=$PWD/data, danach docker run --gpus all --shm-size 1g -p 8080:80 -v $volume:/data ghcr.io/predibase/lorax:main --model-id $model. Der Parameter --shm-size 1g ist relevant, weil der Container shared memory für die Kommunikation zwischen Prozessen benötigt. Ein Adapter wird nicht beim Start registriert, sondern pro Anfrage über das Feld adapter_id im JSON-Body des /generate-Endpunkts benannt, etwa vineetsharma/qlora-adapter-Mistral-7B-Instruct-v0.1-gsm8k. Für Python gibt es den Client lorax-client mit Client("http://127.0.0.1:8080"), der generate(prompt, max_new_tokens=64, adapter_id=adapter_id) aufruft. Ein OpenAI-kompatibler Chat-Endpunkt ist ebenfalls vorhanden.

Grenzen: Kaltstart, Speicherdruck und falsche Basisarchitektur

Das just-in-time-Laden ist kein kostenloser Vorgang. Ein Adapter, der noch nie im GPU-Speicher lag, muss erst übertragen werden. Die Dokumentation beschreibt das Vorausladen als asynchron, sodass gleichzeitige Anfragen nicht blockiert werden, aber sie macht keine Zusage über die Latenz der ersten Anfrage an einen kalten Adapter. Wer viele Adapter in kurzen Abständen erstmals anspricht, sollte diesen Fall selbst vermessen, statt sich auf die Formulierung zu verlassen. Der zweite Druckpunkt ist der CPU-seitige Adapter-Cache. Er ist die Voraussetzung dafür, dass Auslagern und Wiederladen günstiger sind als ein erneutes Holen vom HuggingFace Hub. Wie groß dieser Cache dimensioniert wird und was passiert, wenn er überläuft, geht aus dem vorliegenden Material nicht hervor. Drittens die Modellbindung: Die Liste der unterstützten Architekturen umfasst Llama, CodeLlama, Mistral, Zephyr und Qwen, und die Liste ist laut Dokumentation nicht abgeschlossen. Ein exotisches oder sehr neues Basisgerüst fällt heraus, und damit fällt der gesamte Ansatz weg. Und schließlich: LoRAX unterstützt nur LoRA-Adapter aus PEFT oder Ludwig. Wer mit anderen Verfahren trainiert oder die Gewichte vollständig feintuned, kann sie hier nicht einbinden.

Der Vergleich mit vLLM

vLLM ist der naheliegende Ausgangspunkt, weil LoRAX auf denselben Grundbausteinen aufsetzt: Paged Attention, Continuous Batching, hoher Durchsatz. Der Unterschied liegt in der Verwaltungsschicht darüber. vLLM lädt LoRA-Adapter, die beim Start des Servers registriert oder über die API aktiviert werden, und hält sie im Speicher. LoRAX ergänzt das um Adapter Exchange Scheduling, also das asynchrone Vorausladen und Auslagern zwischen GPU und CPU, und um das heterogene Batching über Adaptergrenzen hinweg. Das ist genau der Teil, der bei vielen hundert oder tausend Adaptern über den Durchsatz entscheidet, weil die Adapter nicht mehr dauerhaft im GPU-Speicher liegen müssen. Der Preis dafür ist mehr bewegliche Teile: ein Adapter-Cache, ein Scheduler, ein zusätzlicher Pfad für das Nachladen. Wer nur eine Handvoll Adapter dauerhaft aktiv hält, fährt mit vLLM einfacher, weil diese Schicht dann nichts einspart. Wer dagegen viele selten genutzte Adapter vorhält, profitiert von der Auslagerung.

Betrieb, Lizenz und Wartungskosten

LoRAX steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung, erfordert aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen an den Dateien kenntlich gemacht werden. Wer den Code modifiziert und als Dienst betreibt, sollte die eigenen Pflichten mit der Rechtsabteilung klären; das ist keine Rechtsberatung. Für den Betrieb nennt die Dokumentation vorgebaute Docker-Images, Helm-Charts für Kubernetes, Prometheus-Metriken und verteiltes Tracing über Open Telemetry. Das sind konkrete Anknüpfungspunkte für bestehende Monitoring-Stacks. Die Wartungslast liegt weniger im Anwendungscode als in der Umgebung: Der Container enthält kompilierte CUDA-Kernel, und die Anforderungen nennen CUDA 11.8 sowie Ampere oder neuer. Ein Sprung auf eine neuere CUDA- oder Treibergeneration bedeutet damit ein neues Image und einen erneuten Test der Kernel, nicht nur ein Paket-Update. Nach dem Start des Servers lohnt ein Blick auf den Endpunkt /generate mit einem basisnahen Prompt ohne adapter_id, um Basisgewichte und Tokenisierung zu prüfen, bevor Adapter ins Spiel kommen.

Redaktionelles Fazit

LoRAX passt zu Teams, die viele PEFT- oder Ludwig-LoRA-Adapter auf einer gemeinsamen Basis betreiben, Ampere-Hardware oder neuer stellen und den Betrieb über Kubernetes mit Helm-Charts abbilden. Wer nur ein einzelnes Modell ohne Adapter serviert, sollte bei einem schlankeren Server bleiben, weil Adapter-Exchange-Scheduling und der CPU-seitige Adapter-Cache dann nur Overhead erzeugen. Vor dem Rollout zu prüfen sind drei Dinge: ob die eigene Basisarchitektur in der Liste der unterstützten Architekturen steht, ob die Treiber- und CUDA-Version zum veröffentlichten Container passt, und ob die Adapter aus HuggingFace Hub, Predibase oder einem lokalen Dateisystem tatsächlich aus Ihrer Trainingspipeline stammen, denn nur PEFT- und Ludwig-Adapter sind laut Dokumentation vorgesehen.

Offizielle Quellen

1. License: Apache-2.0
2. predibase/lorax on GitHub
3. Project website
4. README
5. Releases