Licensed to be used in conjunction with basebox, only.
// installation
Erweiterte Architekturen
Gilt für
Produkt: Server · Zielgruppe: Platform Operator
Layouts jenseits eines Einzelknotens mit einer Inferenz-GPU. Diese Seiten existieren, damit sich die Informationsarchitektur nicht ändert, wenn solche Setups dokumentiert werden – und damit klar ist, welches Muster heute validiert, welches unterstützt und welches Zukunft ist. Der Maßstab ist derselbe wie bei den Referenzkonfigurationen: Validated · Supported · Experimental · Custom.
Die vier Muster
| Muster | Was es löst | Status heute | Seite |
|---|---|---|---|
| Multi-GPU – Tensor-Parallelismus über mehrere GPUs für ein Modell | Modelle oder Kontexte, die nicht auf eine GPU passen | Validated in der Konfiguration 4 × H100 SXM (TP=2) | Multi-GPU |
| Dedizierte Service-GPU – eine GPU oder MIG-Slices ausschließlich für Service-Modelle | Uploads und Transkriptionen konkurrieren nie mit der Inferenz | Validated als MIG-Variante (2 × H200, 4 × H100); Supported als eigene GPU (2 × H200 + RTX PRO 6000) | Dedizierte Service-GPU |
| Mehrere Inferenz-Instanzen – mehrere Modelle oder Instanzen nebeneinander | Standard- plus Reasoning-Modell; mehr Parallelität bei gleichem Kontext | Möglich über Endpunkte, die mehrere Modelle anbieten; Routing-Details unter DevOps-Vorbehalt | Mehrere Inferenz-Instanzen |
| Multi-Node – Plattform, Service-Modelle und Inferenz über Knoten verteilen | Kapazität jenseits eines Servers, Sicherheitszonen, Hochverfügbarkeit | Getrennte Anwendungs- und Inferenzhosts dokumentiert und erprobt (Deployment-Topologien); Hochverfügbarkeit ist eine separate Architektur | Multi-Node |
Wann Sie hier weiterlesen sollten
- Das gewünschte Modell passt nicht auf eine GPU → Multi-GPU.
- Nutzer melden Latenzspitzen im Chat, während Dokumente verarbeitet werden → Dedizierte Service-GPU.
- Zwei Modelle sollen parallel angeboten werden, oder eine Instanz ist ausgelastet → Mehrere Inferenz-Instanzen.
- Ein Server reicht nicht (GPU-Slots, Strom), die Inferenz gehört in eine andere Zone, oder Ausfallsicherheit ist gefordert → Multi-Node.
Alles davor – ein Knoten, eine Inferenz-GPU, Service-Modelle auf MIG oder CPU – ist mit den Referenzkonfigurationen und dem Bare-Metal-Pfad abgedeckt.
Was für alle Muster gilt
- GPUs anhand stabiler Identität zuordnen (UUID, PCI-Adresse), nie anhand von Indexnummern.
- GPU-Speicher ist lokal je Karte. Zwei 80-GB-GPUs sind kein 160-GB-Gerät; Tensor-Parallelismus verteilt Schichten, er poolt keinen Speicher.
- Nutzer sprechen nie direkt mit der Inferenz – auch nicht bei mehreren Instanzen oder Knoten. Nur AISRV.
- Ein Modell-Cache je Knoten. Modellartefakte liegen dort, wo die Inferenz läuft.
- Kein stiller Rückfall. Fällt eine Instanz oder ein Knoten aus, zeigt basebox den Fehler.
- Erst messen, dann bauen. Jedes Muster beginnt mit einer Kapazitäts- oder Latenzmessung – Monitoring, Skalierung.
Status ehrlich lesen
Ein Muster als Supported oder Experimental zu führen heißt: basebox kennt und unterstützt den Ansatz, hat aber nicht jede Kombination gemessen. Wenn Sie ein solches Layout produktiv betreiben, dokumentieren Sie es nach der Vorlage Eigene Hardware und melden Sie Ihre Erfahrung an support@basebox.ai – so werden aus Mustern Referenzkonfigurationen.
Nächster Schritt: Multi-GPU