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

// installation

Installation prüfen

Gilt für

Produkt: Server · Zielgruppe: Platform Operator

Abnahmeprüfungen vor der Freigabe für Nutzer: Pods bereit, GPU-Ressourcen gebunden, Chat, RAG, OCR und STT je einmal geprüft, Neustart-Test bestanden, Manifest festgehalten. Führen Sie die Prüfungen mit synthetischen Testdaten durch – keine Kunden-, Patienten- oder Produktionsdaten – und halten Sie Betriebsmetadaten fest, nicht Prompts, Dokumente oder Antworten.

1. Plattform

kubectl -n basebox get pods -o wide                 # alle Running, Neustartzähler 0
kubectl -n basebox get job                          # idp-keycloak-bootstrap Complete
kubectl -n basebox get cluster                      # CNPG-Cluster healthy
kubectl -n basebox get pvc                          # alle Bound
kubectl -n basebox get ingress                      # Host = global.domain
kubectl -n basebox get certificate 2>/dev/null      # bei cert-manager: Ready
kubectl -n basebox get events --sort-by='.lastTimestamp' | tail -20
  • Alle Pods Running, keine Neustarts
  • Bootstrap-Job abgeschlossen
  • Datenbank-Cluster gesund, PVCs gebunden
  • Ingress und TLS korrekt; Browser zeigt ein vertrauenswürdiges Zertifikat (bei local die erwartete Warnung)

2. GPU-Zuteilung

kubectl describe node <node> | grep -A8 -E "Capacity|Allocatable|Allocated resources"
kubectl -n basebox describe pod -l app.kubernetes.io/name=inference | grep -A3 "nvidia.com/"
kubectl -n basebox exec -it <inference-pod> -- nvidia-smi
  • Der Knoten bietet die erwarteten Ressourcen an (z. B. nvidia.com/gpu: 1 und nvidia.com/mig-1g.35gb: 4 bei 2 × H200)
  • Die Inferenz ist an die komplette(n) GPU(s) gebunden
  • Jeder Service-Workload hält seine eigene GPU bzw. MIG-Instanz
  • Kein Workload teilt den Speicher der Inferenz-GPU

3. Funktionsprüfung über die Anwendung

Mit dem Administratorkonto anmelden (basebox-admin-secret) und je einmal:

Prüfung Vorgehen Erwartet
Login Browser → https://<domain> → Anmeldung Oberfläche lädt; „Über" zeigt Version, Modell, Kontextgröße, Realm
Chat Kurze Frage stellen Antwort streamt; kein Fehler
Langer Kontext Einen längeren synthetischen Text einfügen und zusammenfassen lassen Antwort ohne Kontextfehler bis zur konfigurierten Größe
Reasoning (falls Modell) Reasoning-Stufe Hoch wählen Gedankengang erscheint und lässt sich einklappen
RAG App mit Wissensbasis anlegen, synthetisches PDF hochladen, Frage stellen Verarbeitungsstatus abgeschlossen; Antwort mit Quellen-Chips; Download des Originals funktioniert
OCR Gescanntes PDF oder Bild mit Text hochladen Text wird erkannt und beantwortet
STT Kurze synthetische Audiodatei hochladen, „Transkribiere" Transkript erscheint; Mikrofon-Diktat funktioniert
Dokumente erzeugen „Erstelle ein Word-Dokument mit …" Datei steht zum Download
Konnektoren (falls aktiviert) Administration → Konnektoren → Verbindung testen Test erfolgreich
API curl $URL/v1/models mit einem API-Schlüssel Modellliste; Chat-Completion erfolgreich
Audit-Log Administration → Audit Log Login und Aktionen erscheinen; CSV-Export funktioniert
  • Alle Zeilen bestanden

4. Fehlerverhalten

  • Inferenz in einem Wartungsfenster stoppen (kubectl -n basebox scale deploy/inference --replicas=0 bzw. externen Endpunkt blockieren): Chat zeigt einen Fehler, kein stiller Rückfall
  • Inferenz wieder starten: Chat funktioniert nach dem Warm-up ohne Eingriff

5. Mischlast (empfohlen)

Ein begrenzter Lauf mit gleichzeitigem Chat, Dokumentaufnahme, OCR und STT zeigt, ob Service-Modelle und Inferenz sich in die Quere kommen. Referenz der 2 × H200: 60 Minuten Mischlast, 720 kurze und 12 lange LLM-Anfragen, 12 Service-Lastspitzen, 0 Neustarts der Inferenz.

  • Keine Workload-Neustarts während der Mischlast
  • Antwortzeiten im Chat bleiben stabil, während Dokumente verarbeitet werden

6. Neustart-Test

sudo reboot
# danach:
kubectl get nodes
kubectl describe node <node> | grep -A8 Allocatable
kubectl -n basebox get pods
  • GPU-Ressourcen und MIG-Layout kehren zurück
  • Alle Workloads werden wieder Ready; Inferenz nach dem Warm-up (Kaltstart etwa 6 Minuten bei 2 × H200)
  • Persistente Daten intakt: Wissensbasis der Test-App antwortet weiterhin

7. Monitoring und Backup

  • Health-Endpunkte erreichbar (/health von AISRV und Inferenz; /health/ready von Keycloak)
  • Metriken fließen, falls konfiguriert (AISRV_METRICS_PORT, enablePodMonitor, DCGM) – siehe Monitoring
  • Ein erstes Backup der Datenbanken erstellt und eine Wiederherstellung geübt – siehe Backup & Wiederherstellung

8. Manifest festhalten

Halten Sie fest – ohne Zugangsdaten:

helm list -n basebox
kubectl -n basebox get deployments -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'
nvidia-smi --query-gpu=name,uuid,driver_version --format=csv
nvcc --version | tail -1
kubectl version --short 2>/dev/null || kubectl version
helm version --short
kubectl get pods -n gpu-operator -o jsonpath='{.items[0].spec.containers[0].image}'
  • Chart- und App-Version, Image-Digests, Modell und Quantisierung, Treiber, CUDA, Kubernetes, Helm, GPU-Operator, Firmware, GPU-UUIDs mit Rolle, MIG-Layout, verwendete Values-Dateien (ohne Secrets)

9. Übergabe

  • Zugangsdaten des ersten Administrators sicher übergeben; Keycloak-Admin beim Betrieb
  • Administratoren kennen ihren Einstieg: Administration; sie legen sofort einen zweiten Administrator an
  • Betriebsverantwortung geklärt: Betrieb
  • Bei Custom-Hardware: ausgefülltes Eigene-Hardware-Dokument an basebox

Alles abgehakt? Dann ist die Installation abgenommen. Ab hier gilt Betrieb.