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

// installation

Server-Architektur

Gilt für

Produkt: Server · Zielgruppe: Platform Operator

Die Gestalt eines basebox Servers: eine dedizierte Maschine (oder ein kleiner Cluster) mit basebox-Plattform, Service-Modellen und – auf demselben Knoten oder einem separaten GPU-Host – der Inferenz. Diese Seite zeigt die drei üblichen Layouts und das Muster, nach dem GPUs verteilt werden.

Die drei Schichten auf einem Server

flowchart TB
  subgraph SRV["Dedizierter Kundenserver · Kubernetes"]
    P["<b>basebox-Plattform</b><br/>frontend · AISRV · storesrv · Keycloak · PostgreSQL · Ingress<br/><i>CPU, RAM, Speicher – keine GPU</i>"]
    S["<b>Service-Modelle</b><br/>ragsrv · ragsrv-support: RAG, Extraktion, OCR, STT<br/><i>dedizierte GPU oder MIG-Slices, sonst CPU-Modus</i>"]
    I["<b>Inferenz</b><br/>vLLM mit dem Sprachmodell<br/><i>komplette GPU(s), optional tensor-parallel</i>"]
    P --> S
    P -->|OpenAI-kompatible API| I
  end
  U["Nutzer · API-Clients"] -->|HTTPS| P
  style P fill:#f4f2ee,stroke:#524e47,color:#1d1e1c
  style S fill:#dcefe2,stroke:#3a7a49,color:#1d1e1c
  style I fill:#dbeafe,stroke:#1e40af,color:#1d1e1c

Die Plattform braucht keine GPU. Die GPUs eines Servers gehören den Service-Modellen und der Inferenz – und sie sollten sich nicht dieselbe GPU teilen, damit ein Upload oder eine Transkription nie mit dem Chat um VRAM konkurriert. Warum: Architektur verstehen.

Die drei Layouts

Layout	Beschreibung	Wann sinnvoll	GPU-Vorbereitung
Ein Server, ein Cluster	Alle drei Schichten auf einem Kubernetes-Knoten	Evaluierung, kompakte Appliance, die Referenzkonfigurationen	Diesen Server für GPU-Workloads vorbereiten
Ein Cluster mit CPU- und GPU-Knoten	Plattform auf CPU-Knoten, Service-Modelle und Inferenz auf GPU-Knoten	Bestehendes Kubernetes mit Knotentrennung	Nur die GPU-Knoten vorbereiten
Getrennte Anwendungs- und Inferenzserver	Plattform (+ Service-Modelle im CPU- oder GPU-Modus) auf einem Anwendungsserver; Inferenz auf separatem GPU-Host, angesprochen über die OpenAI-kompatible API	GPU-System wird separat verwaltet oder liegt in anderer Sicherheitszone	Der Anwendungsserver kann rein CPU-basiert sein

Das dritte Layout mit ausgearbeitetem vLLM-Beispiel, Secrets, Netzwerkanforderungen und Prüfschritten: Deployment-Topologien. Nutzer und Browser sprechen in jedem Layout nur mit der Plattform, nie direkt mit der Inferenz.

Das GPU-Zuteilungsmuster

Die meisten Referenzkonfigurationen folgen einem Muster:

• Inferenz-GPU(s): komplette, nicht partitionierte GPUs für das Sprachmodell; bei großen Modellen zwei GPUs als tensor-paralleles Paar (TP=2).
• Service-GPU: eine dedizierte GPU (etwa RTX PRO 6000) oder eine große GPU in MIG-Instanzen aufgeteilt – eine je Dienst: GPU-RAG, Dokumentextraktion, OCR, Sprache-zu-Text.
• Plattform: CPU.

Konfiguration	Inferenz	Service-Modelle	Status
2 × H200 141 GB	1 komplette H200	1 H200 als 4 × MIG 1g.35gb	Validated
4 × H100 SXM 80 GB	2 H100 tensor-parallel	2 H100 als je 2 × MIG 3g.40gb	Validated
2 × H200 + RTX PRO 6000	2 H200	RTX PRO 6000 dediziert	Supported
3 × RTX PRO 6000	typischerweise 2	1 dediziert	Supported

Kubernetes sieht diese Aufteilung als Ressourcen (nvidia.com/gpu, nvidia.com/mig-1g.35gb, …), die die Helm-Values je Dienst anfordern. Details je Konfiguration: Referenzkonfigurationen.

Die Komponenten

Was auf dem Server läuft – Frontend, AISRV, storesrv, Keycloak, PostgreSQL-Cluster (CloudNativePG), ragsrv, ragsrv-support, inference, optionale MCP-Konnektoren – und wie sie kommunizieren, steht unter basebox-Komponenten. Bereitgestellt wird alles über das Umbrella-Chart basebox.ai.

Software-Stack von unten nach oben

1. Betriebssystem – Ubuntu 24.04 LTS empfohlen
2. NVIDIA-Treiber, CUDA, Container Toolkit – auf Hosts mit GPU-Workloads
3. Kubernetes (1.33+ empfohlen, 1.23+ vom Chart verlangt) mit GPU Operator, Ingress-Controller, Storage Class, CloudNativePG
4. basebox per Helm – Plattform, Service-Modelle, gebündelte oder externe Inferenz

Der Weg dorthin: Bare-Metal-Installation.

Was ein Server nicht ist

• Kein Hochverfügbarkeitscluster von Haus aus. Die Referenzkonfigurationen sind Einzelknoten; HA über mehrere Knoten ist eine separate Architektur – siehe Multi-Node.
• Nicht durch Hardware definiert. Eine Referenzkonfiguration dokumentiert ein bekanntes Setup; sie ist keine Mindestanforderung von basebox.
• Nicht Cloud, auch wenn er bei basebox steht. Siehe Hosting-Optionen.

Nächster Schritt: Hardware-Optionen