Copyright © 2022-2026 basebox GmbH, all rights reserved.
Licensed to be used in conjunction with basebox, only.

// installation

Mehrere Inferenz-Instanzen

Gilt für

Produkt: Server · Zielgruppe: Platform Operator

Mehrere Modelle oder mehrere Instanzen eines Modells nebeneinander betreiben – etwa ein schnelles Standardmodell plus ein Reasoning-Modell, oder zwei Instanzen desselben Modells für mehr Parallelität. Diese Seite beschreibt, was aus Sicht der Plattform gilt, welche Muster technisch tragfähig sind und wo die Grenze zwischen dokumentiert und noch offen liegt.

Was AISRV sieht

Für die basebox-Plattform ist die Inferenz ein OpenAI-kompatibler Endpunkt: AISRV_LLM_URL, ein API-Schlüssel aus einem Secret, und die Modellbezeichner, die der Endpunkt unter /v1/models meldet. Welche Modelle Administratoren unter Modelle aktivieren freigeben können, ergibt sich aus dieser Liste; das Standardmodell gilt überall, wo eine App nichts anderes festlegt.

Daraus folgt das Grundprinzip dieser Seite: Mehrere Modelle heißt ein Endpunkt, der mehrere Modelle meldet. Wie dieser Endpunkt intern aufgebaut ist – eine Runtime, mehrere Runtimes hinter einem Router, mehrere Replikate – ist Sache der Inferenz-Schicht, nicht der Plattform.

Drei Muster

Muster	Was es löst	Aufbau	Status
A · Zwei Modelle, zwei Runtimes, ein Router	Standardmodell + Reasoning-Modell; kleines Modell für Massenaufgaben, großes für schwierige	Je Modell eine vLLM-Instanz auf eigener GPU/eigenen GPUs; davor ein OpenAI-kompatibler Router, der nach model verteilt und alle Modelle unter /v1/models meldet	Supported – Routing-Details stehen unter DevOps-Vorbehalt
B · Ein Modell, mehrere Replikate	Mehr gleichzeitige Nutzer bei gleichem Kontext	Mehrere identische Instanzen hinter einem Kubernetes-Service oder Load Balancer; jede Instanz eigene GPU(s)	Supported
C · Ein Modell, größer geschnitten	Mehr Kontext oder Durchsatz aus einer Instanz	Tensor-Parallelismus über mehrere GPUs – siehe Multi-GPU	Validated (4 × H100, TP=2)

Muster C ist oft die bessere Antwort auf „zu langsam" als Muster B: vLLM batcht Anfragen kontinuierlich, und eine große Instanz nutzt GPU-Speicher besser als zwei kleine mit doppelt geladenen Gewichten.

Muster A: zwei Modelle

Voraussetzungen

• Je Modell genügend GPU-Speicher für Gewichte und KV-Cache – zwei Modelle auf einer GPU konkurrieren um denselben Speicher; besser je Modell eigene GPU(s). Die LLM-Empfehlungen nennen den Bedarf je Modell und Quantisierung.
• Ein Router, der die OpenAI-API spricht, Anfragen nach dem Feld model weiterleitet und die vereinigte Modellliste liefert. Er muss eine API-Zugangsberechtigung verlangen und nur von AISRV erreichbar sein – dieselben Anforderungen wie an jeden externen Endpunkt (Inferenz anbinden).
• Die Bezeichner unter /v1/models müssen exakt mit dem übereinstimmen, was Administratoren in basebox aktivieren.

Aufbau

1. Zweite Runtime als eigenes Deployment mit eigener GPU-Anforderung (nvidia.com/gpu oder ein MIG-Profil), eigenem Modell-Cache und eigenem MODEL_ID. Die gebündelte Inferenz des Charts trägt ein Modell; eine zweite Instanz legen Sie daneben an.
2. Router davor; AISRV auf den Router zeigen lassen (AISRV_LLM_URL), Schlüssel aus Secret.
3. Aus dem AISRV-Pod prüfen:

   curl -s -H "Authorization: Bearer $KEY" $AISRV_LLM_URL/v1/models | jq '.data[].id'
   

   Beide Bezeichner müssen erscheinen.
4. In der Administration beide Modelle aktivieren, Standard setzen, Reasoning-Modell einzelnen Apps zuweisen (Standardmodelle).

Kontextgröße und Ausgabelimit gelten in AISRV je Endpunkt (AISRV_LLM_CONTEXT_SIZE, AISRV_LLM_WORD_LIMIT). Bei zwei Modellen mit unterschiedlichem Kontext setzen Sie den Wert auf das kleinere – oder klären mit basebox, ob je Modell konfiguriert werden kann.

Muster B: Replikate

• Jede Instanz braucht ihre eigene(n) GPU(s) und lädt die Gewichte selbst – Speicher wird nicht geteilt.
• Ein Kubernetes-Service vor identischen Pods verteilt Anfragen; Streaming-Antworten laufen über eine Verbindung, deshalb genügt einfache Verteilung ohne Session-Affinität.
• Der Modell-Cache je Knoten muss vorhanden sein (Speicher); Kaltstarts dauern je Instanz mehrere Minuten – Probes und Warm-up entsprechend.
• Erst messen: Wenn eine Instanz bei Ihrer Last weder GPU-Auslastung noch Warteschlange zeigt, bringt ein Replikat nichts – siehe Skalierung.

Was für alle Muster gilt

• Kein stiller Rückfall. Fällt eine Instanz aus, zeigt basebox den Fehler für Anfragen an dieses Modell; es wechselt nicht unbemerkt auf ein anderes.
• Nutzer sprechen nie direkt mit einer Instanz – nur mit AISRV.
• Datenverarbeitungsgrenze. Alle Instanzen und der Router liegen in derselben freigegebenen Grenze wie der Anwendungsserver; Pfade über Hosts hinweg per TLS (Inferenz-Architektur).
• Service-Modelle sind keine Inferenz. RAG, OCR und Sprache-zu-Text laufen getrennt auf der dedizierten Service-GPU und bleiben von diesen Mustern unberührt.
• Manifest führen: welche Instanz welche GPU(s), welches Modell, welche Version.

Prüfen

• /v1/models liefert alle erwarteten Bezeichner.
• Eine Anfrage je Modell aus dem AISRV-Pod antwortet; die Last erscheint auf der richtigen GPU (nvidia-smi dmon).
• In basebox lassen sich beide Modelle aktivieren und je App wählen; der Wechsel ist im Chat sichtbar.
• Ausfalltest: eine Instanz stoppen → Anfragen an dieses Modell melden einen Fehler, das andere Modell arbeitet weiter.

Häufige Fehlerbilder

Symptom	Ursache	Lösung
Modell fehlt in der Administration	Bezeichner nicht unter /v1/models oder anders geschrieben	Router-Liste prüfen; Bezeichner exakt
Zweite Instanz startet nicht (OOM)	Beide Modelle auf einer GPU	Eigene GPU(s) oder MIG je Instanz
Antworten kommen vom falschen Modell	Router ignoriert das Feld model	Router-Konfiguration; Test mit curl je Modell
Langsam trotz zweiter Instanz	Last war nicht GPU-gebunden	Erst messen, dann skalieren

Nächster Schritt: Multi-Node