Multi-LoRA: Dutzende KI-Modelle auf einer GPU betreiben

Die Rechtsabteilung will ein Modell, das Verträge in ihrem Ton zusammenfasst. Der Support wünscht sich eines, das Tickets nach hauseigenen Kategorien sortiert. Und das Marketing hätte gern eine KI, die Produktnamen und Claims korrekt trifft. Drei Abteilungen, drei feinabgestimmte Modelle – und schnell die Frage: Brauchen wir jetzt drei GPUs? Oder gleich zwölf?

Genau hier setzt Multi-LoRA-Serving an. Statt für jede Variante ein komplettes Modell in den Grafikspeicher zu laden, teilen sich alle Varianten ein einziges Basismodell. Die Unterschiede stecken in winzigen Zusatzdateien, die sich pro Anfrage austauschen lassen. Das klingt nach einem Detail für Infrastruktur-Teams. In Wahrheit entscheidet es darüber, ob selbst-gehostete KI in Ihrem Haus bezahlbar bleibt oder an der Hardwarerechnung scheitert.

Was LoRA technisch tut – kurz und ohne Nebel

LoRA steht für Low-Rank Adaptation. Beim klassischen Fine-Tuning ändern Sie die Gewichte des gesamten Modells – bei einem 7-Milliarden-Parameter-Modell sind das viele Gigabyte, die Sie speichern, laden und pflegen müssen. LoRA geht anders vor: Das Basismodell bleibt eingefroren, unverändert. Trainiert werden nur zwei kleine Matrizen, die sich an das Modell anlagern und sein Verhalten in die gewünschte Richtung schieben.

Der Größenunterschied ist drastisch. Ein LoRA-Adapter für Mistral-7B wiegt rund 13,6 Megabyte. Das Basismodell selbst bringt 14,48 Gigabyte auf die Waage. Der Adapter ist also kleiner als ein Tausendstel des Modells. In der Praxis rechnet man mit etwa einem Prozent zusätzlichem Speicherbedarf pro Adapter. Dieser Hebel macht den ganzen Ansatz erst interessant.

Wichtig für das Verständnis: Ein Adapter ist kein eigenständiges Modell. Ohne das Basismodell ist er wertlos. Er ist eher eine Linse, die Sie vor dieselbe Kamera schrauben – der Sensor bleibt gleich, das Bild ändert sich.

Ein Basismodell, viele Adapter – so läuft es

Der Kern von Multi-LoRA-Serving: Sie laden das schwere Basismodell genau einmal in den Grafikspeicher. Darauf legen Sie dutzende leichte Adapter. Kommt eine Anfrage herein, wählt der Server anhand einer Kennung – oft schlicht eine adapter_id – den passenden Adapter aus und beantwortet die Anfrage in dessen Charakter. Die nächste Anfrage kann bereits einen anderen Adapter nutzen.

Der Speicherbedarf bleibt dabei erstaunlich niedrig. In einem dokumentierten Aufbau führten 30 gleichzeitig geladene Adapter zu lediglich drei Prozent mehr Grafikspeicher. Sie bekommen also 30 Modellpersönlichkeiten zum Preis von etwas mehr als einer. Frameworks wie vLLM, Text Generation Inference und LoRAX beherrschen dieses Muster inzwischen produktiv; die optimierten Kernel dahinter stammen aus Projekten wie Punica.

Auch der Durchsatz leidet nicht zwangsläufig. Auf einer vergleichsweise günstigen Nvidia-L4-Karte erreichte ein solcher Aufbau 75 Anfragen pro Sekunde bei durchschnittlich 450 Eingabe- und 234 Ausgabe-Token. Das reicht für viele interne Anwendungen locker aus – und läuft auf Hardware, die kein Vermögen kostet.

Was das im Rechenzentrum wirklich spart

Rechnen wir es durch, an einem realen Beispiel aus der Community. Ein Anbieter hatte pro Geschäftskunden einen eigenen LoRA-Adapter auf einem gemeinsamen Llama-3.1-8B trainiert – am Ende 40 Stück. Hätte er jeden als separates Deployment betrieben, wären dafür rund 24.000 US-Dollar pro Monat an überwiegend leerlaufender GPU-Zeit angefallen. Mit Multi-LoRA passten alle 40 Adapter auf zwei A100-Karten.

Der eigentliche Gewinn liegt nicht nur im Einkauf der Hardware. Er liegt in der Auslastung. Einzelne feinabgestimmte Modelle warten die meiste Zeit auf Anfragen und verbrennen dabei teuren Speicher. Bündeln Sie sie auf einem Basismodell, teilen sie sich die Grundlast. Die Karte arbeitet, statt zu warten.

Dazu kommt ein Effekt, der sich schwerer beziffern lässt, aber im Betrieb schnell zählt: weniger bewegliche Teile. Ein Basismodell aktualisieren Sie einmal. Ein neuer Anwendungsfall bedeutet einen neuen Adapter von wenigen Megabyte, nicht ein neues Deployment mit eigener Überwachung, eigenem Speicher und eigener Update-Kette.

Wo Multi-LoRA im Alltag glänzt

Der klarste Fall ist der Mandanten-Betrieb. Wenn Sie Software als Dienst anbieten und jeder Kunde eine auf seine Daten zugeschnittene KI erwartet, wäre ein Modell pro Kunde ruinös. Ein Adapter pro Kunde auf gemeinsamer Basis dagegen skaliert sauber – vom zehnten bis zum hundertsten Mandanten ändert sich an der Grundinfrastruktur wenig.

Genauso überzeugend ist der Abteilungs-Fall im eigenen Haus. Recht, Support, Einkauf, Personal – jede Fachabteilung spricht ihre eigene Sprache und arbeitet mit eigenen Vorlagen. Statt einem generischen Modell, das allen halb passt, geben Sie jeder Abteilung einen eigenen Adapter, der genau ihre Begriffe, Formate und Tonlagen trifft. Alles auf einer Karte, alles zentral gepflegt.

Und schließlich die Entwicklung selbst. Neue Adapter sind billig zu trainieren und billig zu testen. Sie können eine überarbeitete Version neben der alten laufen lassen, den Datenverkehr aufteilen und vergleichen, ohne eine zweite Maschine hochzufahren. Das senkt die Hürde für Experimente spürbar – und gute KI entsteht selten im ersten Anlauf.

Grenzen und Stolperfallen

Multi-LoRA ist kein Allheilmittel. Alle Adapter hängen am selben Basismodell. Brauchen zwei Anwendungsfälle unterschiedliche Basismodelle – etwa ein Sprachmodell für Deutsch und eines mit besonderem Code-Verständnis –, dann teilen sie sich keine GPU auf diese Weise. Sie planen dann pro Basismodell.

Auch die Qualität hat Grenzen. LoRA verschiebt Verhalten, aber es zaubert kein Wissen herbei, das im Basismodell schlicht fehlt. Wenn Ihre Aufgabe tiefes Fachwissen verlangt, kommen Sie um sauber aufbereitete Daten und oft auch um Retrieval nicht herum. Der Adapter formt die Antwort – die Fakten müssen von woanders kommen.

Und ein Betriebsdetail: Viele Adapter auf einer Karte heißt auch, dass ein Ausfall dieser Karte viele Dienste zugleich trifft. Was Sie an Hardware sparen, sollten Sie zum Teil in Redundanz und Überwachung zurückstecken. Ein zweiter Knoten, der einspringt, gehört zu einem ernsthaften Aufbau dazu.

So steigen Sie pragmatisch ein

Fangen Sie klein an. Wählen Sie ein solides offenes Basismodell, das zu Ihren Aufgaben passt, und trainieren Sie zwei, drei Adapter für konkrete, gut abgegrenzte Anwendungsfälle. Setzen Sie auf ein Serving-Framework, das Multi-LoRA nativ kann, damit Sie das Umschalten pro Anfrage geschenkt bekommen.

Messen Sie früh und ehrlich: Durchsatz, Antwortzeit, Speicher pro zusätzlichem Adapter. Diese Zahlen sagen Ihnen, wie weit eine Karte trägt, bevor Sie die nächste brauchen. Und dokumentieren Sie, welcher Adapter zu welcher Aufgabe gehört – bei 30 Varianten verliert man den Überblick sonst schneller, als einem lieb ist.

Wenn Sie herausfinden möchten, wie sich mehrere feinabgestimmte KI-Modelle in Ihrem Haus auf bezahlbarer Hardware bündeln lassen, sprechen Sie mit uns. Bei AI-Designers begleiten wir Unternehmen von der Modellauswahl über das Fine-Tuning bis zum stabilen Betrieb selbst-gehosteter KI – praxisnah, messbar und mit Blick auf Ihre Datenhoheit.

Bilder: AI-Designed