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

// installation

Ressourcen & Skalierung

Gilt für

Produkt: Server · Zielgruppe: Platform Operator

Wie sich der Ressourcenbedarf auf die drei Schichten verteilt, was mit Nutzern, Dokumenten bzw. Modellgröße wächst, und welche Stellschrauben es gibt, um jede Schicht unabhängig zu skalieren. Die Zahlen auf dieser Seite sind Richtwerte aus dem Chart und den Referenzkonfigurationen – exakte unterstützte Minimal- und Empfehlungswerte je Schicht stehen unter DevOps-Vorbehalt und werden auf den Seiten der Referenzkonfigurationen genannt, sobald bestätigt.

Was womit wächst

Schicht	Wächst mit	Ressourcen	Stellschrauben
basebox-Plattform	Anzahl Nutzer und gleichzeitiger Sitzungen, API-Verkehr, Anzahl Organisationen	CPU, RAM, Datenbank-IOPS, Speicher für Medien	Replikate und Autoscaling für AISRV/frontend/storesrv, CNPG-Instanzen, Storage Class, Datenbankgröße
Service-Modelle	Dokumentvolumen (Uploads, Wissensbasen), OCR-Anteil, Audiominuten	GPU-Speicher und -Rechenleistung; im CPU-Modus CPU und RAM	Dedizierte GPU oder MIG-Slices, `COMPUTE: gpu`/`cpu`, Replikate von ragsrv, Größe der Modell-Cache-Volumes
Inferenz	Modellgröße, Kontextlänge, gleichzeitige Anfragen, Latenzziel	GPU-Speicher (Gewichte + KV-Cache), GPU-Rechenleistung, Interconnect	Modell und Quantisierung, Anzahl GPUs / Tensor-Parallelismus, `AISRV_LLM_CONTEXT_SIZE`, KV-Cache-Quantisierung

Die drei Schichten skalieren unabhängig: Mehr Nutzer heißt nicht mehr GPU für die Inferenz, solange die Parallelität nicht steigt; mehr Dokumente heißt Speicher und Service-GPU, nicht Inferenz.

Plattform

Richtwerte des Charts für ein Produktiv-Deployment: minimal 5+ Kerne und 12 GB+ RAM, empfohlen 10+ Kerne und 32 GB+ RAM – für den gesamten Stack ohne GPU-Workloads. Beispiel-Requests aus den Service-Seiten:

# AISRV / STORESRV
resources:
  requests: {cpu: 1000m, memory: 2Gi}
  limits:   {cpu: 2000m, memory: 4Gi}

Skalieren:

AISRV horizontal (replicaCount, autoscaling.enabled mit Ziel-CPU) – zustandslos, Datenbank per CloudNativePG.
Keycloak ebenfalls horizontal; Infinispan-Cache bei mehreren Replikaten beachten.
Datenbanken: *-db.cluster.instances: 3 für Lesereplikate und Ausfallsicherheit; schnelle Storage Class (SSD/NVMe); storage.size von den 5–10 Gi Standardwerten auf 20–50 Gi je Dienst in Produktion.
Ingress ist auf lange Verbindungen (24 h) und 20 MB Body ausgelegt; Datei-Uploads in Wissensbasen können größere Limits verlangen.

Service-Modelle

Sie brauchen einen stabilen, vorhersehbaren Fußabdruck. Typisch nützlich: rund 48 GB GPU-Speicher, besser etwa 96 GB für größere Nutzungsszenarien – als Architektur-Orientierung, nicht als Mindestanforderung. Die Referenzkonfigurationen zeigen zwei Wege: eine dedizierte GPU (RTX PRO 6000) oder MIG-Slices (4 × 1g.35gb auf einer H200; 2 × 3g.40gb auf je einer H100).

# ragsrv / ragsrv-support im GPU-Modus (Beispiel)
resources:
  requests: {cpu: 2000m, memory: 8Gi,  nvidia.com/gpu: 1}
  limits:   {cpu: 4000m, memory: 16Gi, nvidia.com/gpu: 1}
# CPU-Modus
resources:
  requests: {cpu: 4000m, memory: 16Gi}
  limits:   {cpu: 8000m, memory: 32Gi}

Skalieren: bei hohem Dokumentvolumen mehr ragsrv-Replikate und größere ragsrv-db; bei viel OCR oder Audio mehr GPU-Speicher für die Service-GPU; im CPU-Modus mehr Kerne und RAM – funktionsfähig, aber deutlich langsamer. Ein gemessener Anhaltspunkt aus der Referenzkonfiguration 2 × H200: 120-seitiges PDF in 28,47 s extrahiert; 60 Minuten Audio in 31,31 s transkribiert.

Inferenz

Hier steckt der große GPU-Bedarf. Faustformel:

Verfügbarer VRAM = Modellgewichte + (Kontextgröße × gleichzeitige Nutzer × KV-Cache je Token)

Beispiel Llama 3.3 70B FP8 auf 4 × H100 (320 GB): 65k Kontext → 10–12 gleichzeitige Nutzer; 32k → 20–25; 16k → 40–50. Kontext und Parallelität sind ein Zielkonflikt; KV-Cache-Quantisierung kann die Kapazität etwa verdoppeln. Tabellen je Hardware-Klasse und Modell: LLM-Empfehlungen.

Skalieren:

Größeres Modell oder längerer Kontext → mehr VRAM: stärkere Quantisierung, zweite GPU mit Tensor-Parallelismus (TP muss die Attention-Heads teilen: GPT-OSS 120B erlaubt TP=1, 2, 4, 8, nicht 3), oder größere GPUs.
Mehr gleichzeitige Nutzer → mehr KV-Cache: Kontext senken, KV-Cache quantisieren, zusätzliche Instanz – siehe Mehrere Inferenz-Instanzen.
Latenz → weniger Batching-Spielraum, mehr Hardware je Nutzer.
Die Inferenz kann auf einen separaten GPU-Host wandern, ohne dass die Plattform sich ändert – siehe Deployment-Topologien.

AISRV_LLM_CONTEXT_SIZE muss zum tatsächlich in der Runtime konfigurierten Kontext passen; es begrenzt, was Nutzer in einen Chat laden können.

Speicher und Netzwerk

Speicher wächst mit Dokumenten (Medien-Volume, ragsrv-db), Modellartefakten (200 GB+ für den Inferenz-Cache üblich) und Datenbanken. Chart-Richtwert: 200 GB+ minimal, 500 GB+ SSD/NVMe empfohlen, 1 TB+ für Modellspeicher.
Netzwerk ist selten der Engpass; relevant bei getrennten Anwendungs- und Inferenzhosts (Prompts und Kontext wandern zwischen ihnen) und bei Tensor-Parallelismus (NVLink/NVSwitch zwischen den Inferenz-GPUs).
Shared Memory (/dev/shm, 64 GB in der geprüften Konfiguration) für das Laden großer Modelle.

Wann ein zweiter Knoten

Ein Einzelknoten deckt die Referenzkonfigurationen ab. Ein zweiter Knoten wird sinnvoll, wenn die Inferenz mehr GPUs braucht, als ein Server aufnimmt, wenn Plattform und Inferenz in verschiedene Sicherheitszonen gehören, oder wenn Hochverfügbarkeit gefordert ist. Was dann möglich wird und was schwieriger: Multi-Node.

Beobachten, dann skalieren

Skalieren Sie auf Messwerten, nicht auf Vermutungen: GPU-Auslastung und -Speicher (DCGM), Inferenz-Latenz und Tokens/s, Warteschlangen der Dokumentverarbeitung, Pod-CPU/-RAM (kubectl top), Datenbankgröße. Was zu beobachten ist: Monitoring; die Betriebssicht des Skalierens: Skalierung.

Nächster Schritt: Referenzkonfigurationen