Licensed to be used in conjunction with basebox, only.
// installation
Inferenz
Gilt für
Produkt: Server · Zielgruppe: Platform Operator
Inferenz ist das Sprachmodell – LLM, VLM oder Reasoning-Modell –, das dem Nutzer antwortet. Es ist die Schicht, die den GPU-Bedarf eines Servers bestimmt, und sie ist von basebox selbst getrennt.
Wie basebox mit der Inferenz spricht
AISRV ruft das Modell über eine OpenAI-kompatible API auf (/v1/models, /v1/chat/completions). Diese Grenze macht die Schicht trennbar: basebox ist es gleich, ob der Endpunkt
- das gebündelte vLLM ist, das das Helm-Chart auf demselben Knoten bereitstellt,
- ein separater GPU-Server im Kundennetz,
- ein anderer Kubernetes-Cluster oder
- ein freigegebener externer Anbieter.
Nutzer und Browser sprechen nie direkt mit der Inferenz – nur AISRV. Der Endpunkt muss eine API-Zugangsberechtigung verlangen und TLS nutzen, wenn Verkehr Hosts überschreitet. Das ausgearbeitete Beispiel mit Secrets, Helm-Values und Prüfschritten steht unter Deployment-Topologien; der Schritt im Selbstinstallierer-Pfad ist Inferenz anbinden.
Was das Sizing bestimmt
| Faktor | Wirkung |
|---|---|
| Gewähltes Modell und Größe | VRAM für Gewichte; größere Modelle brauchen mehr GPUs oder stärkere Quantisierung |
| Quantisierung | Tauscht VRAM und Geschwindigkeit gegen Qualität |
| Kontextlänge | Der KV-Cache wächst mit dem Kontext; lange Kontexte sind speicherhungrig |
| Erwartete Parallelität | Mehr gleichzeitige Nutzer → mehr KV-Cache und Rechenleistung |
| Geforderte Latenz | Straffere Latenz → weniger Batching-Spielraum → mehr Hardware je Nutzer |
| Nutzungsmuster | Kurze Fragen vs. lange Dokumentanalyse vs. werkzeuglastige Agentenschleifen |
Das ist ein komplexes Thema ohne eine einzige Antwort. Diese Dokumentation beantwortet nicht primär „Welche Hardware soll ich kaufen?" – dafür gibt es separates Sizing-Material. Hier beantworten wir: Gegeben diese Infrastruktur – wie stelle ich Inferenz richtig bereit und betreibe sie?
Multi-GPU und darüber hinaus
Ein Modell kann mehrere GPUs umspannen (Tensor-Parallelismus – z. B. zwei H100 als Paar in der 4 × H100-Konfiguration); mehrere Modelle oder Instanzen können nebeneinander laufen; Inferenz kann auf separate Knoten wandern. Diese Layouts sind unter Erweiterte Architekturen gesammelt und werden dokumentiert, sobald DevOps sie bestätigt.
Verhalten im Fehlerfall
basebox fällt nicht stillschweigend auf ein anderes Modell zurück, wenn der konfigurierte Endpunkt offline ist. Es zeigt den Fehler an und erholt sich, sobald die Inferenz wieder bereit ist. Planen Sie Monitoring und Alarmierung für den Inferenz-Endpunkt entsprechend – siehe Betrieb → Monitoring.
Wo es weitergeht
- Welche Backends unterstützt sind, was jeder Endpunkt implementieren muss: Unterstützte Inferenz-Backends
- basebox an ein Modell binden (URL, Modell-ID, Kontext, Limits, Secrets): Modelle konfigurieren
- Was getestet, empfohlen oder lediglich kompatibel ist: Modelle & Inferenz
- Konkrete getestete Layouts: Referenzkonfigurationen
Nächster Schritt: Ressourcen & Skalierung