Licensed to be used in conjunction with basebox, only.
// installation
Skalierung
Gilt für
Produkt: Server · Zielgruppe: Platform Operator
Jede Schicht unabhängig skalieren: mehr Nutzer, mehr Dokumente, größere Modelle. Wann GPUs, wann Knoten hinzukommen – und wann nichts davon nötig ist, sondern eine Einstellung. Diese Seite ist die Betriebssicht; die Architektur dahinter steht unter Ressourcen & Skalierung.
Zuerst: Was ist eigentlich knapp?
Skalieren Sie auf Messwerten. Die häufigsten Symptome und ihre Ursache:
| Symptom | Wahrscheinlich knapp | Sehen Sie an |
|---|---|---|
| Chat-Antworten werden langsam, wenn viele gleichzeitig arbeiten | Inferenz: KV-Cache / Rechenleistung | Inferenz-Warteschlange, Latenz p95, GPU-Auslastung nahe 100 % |
| Lange Anfragen scheitern, OOM in Inferenz-Logs | Inferenz: VRAM | GPU-Speicher > 90 % |
| Uploads bleiben lange „in Verarbeitung", Chat bleibt schnell | Service-Modelle | ragsrv/ragsrv-support-Auslastung, Verarbeitungsdauer je Dokument |
| Chat wird langsam, während Dokumente verarbeitet werden | Service-Modelle teilen die Inferenz-GPU | GPU-Speicher der Inferenz-GPU schwankt mit Uploads |
| Oberfläche träge, Login langsam, viele Nutzer | Plattform: AISRV, Keycloak, Datenbank | CPU/RAM der Pods, DB-Connections |
| Uploads scheitern, Modell-Downloads brechen ab | Speicher | PVC-Füllstand |
Was zu messen ist und womit: Monitoring.
Inferenz skalieren
| Ziel | Stellschraube | Hinweis |
|---|---|---|
| Mehr gleichzeitige Nutzer, gleiches Modell | Kontext senken (AISRV_LLM_CONTEXT_SIZE und Runtime-Kontext); KV-Cache-Quantisierung aktivieren |
KV-Cache = Kontext × Nutzer × Cache/Token; Quantisierung verdoppelt etwa die Kapazität |
| Mehr gleichzeitige Nutzer, Kontext beibehalten | Zweite Inferenz-Instanz auf weiterer GPU | Mehrere Inferenz-Instanzen |
| Größeres Modell oder längerer Kontext | Stärkere Quantisierung (FP8/AWQ/MXFP4); Tensor-Parallelismus über zwei GPUs (NUM_GPUS: "2", nvidia.com/gpu: 2) |
TP muss die Attention-Heads teilen; Paar mit schnellstem Peer-Pfad – Multi-GPU |
| Bessere Latenz | Weniger Batching-Spielraum, mehr Hardware je Nutzer; schnelleres Modell (MoE wie GPT-OSS) | Empfohlene Modelle |
| Inferenz vom Anwendungsserver trennen | Separater GPU-Host, AISRV per TLS/API-Key | Deployment-Topologien |
Richtwerte: Llama 3.3 70B FP8 auf 4 × H100 – 65k Kontext ≈ 10–12 Nutzer, 32k ≈ 20–25, 16k ≈ 40–50 (LLM-Empfehlungen).
Service-Modelle skalieren
| Ziel | Stellschraube |
|---|---|
| Schnellere Dokumentverarbeitung | Vom CPU- in den GPU-Modus (COMPUTE: gpu); dedizierte GPU oder MIG-Slices statt geteilter GPU |
| Mehr paralleles Dokumentvolumen | ragsrv.replicaCount erhöhen; ragsrv-support-Replikate; RWX-Volume für /tmp/ragsrv, wenn Pods auf verschiedenen Knoten |
| Mehr OCR/Audio | Größere MIG-Instanz oder eigene GPU für ragsrv-support / Whisper |
| Größere Wissensbasen | ragsrv-db.cluster.storage.size erhöhen; schnelle Storage Class; pgvector-Indizes beobachten |
Service-Modelle nie auf die Inferenz-GPU legen, um „Platz zu sparen" – das erzeugt genau die Latenzspitzen, die Nutzer melden. Muster: Dedizierte Service-GPU.
Plattform skalieren
| Ziel | Stellschraube |
|---|---|
| Mehr gleichzeitige Nutzer in der Oberfläche/API | aisrv.replicaCount oder autoscaling.enabled: true (Ziel-CPU 70 %); frontend.replicaCount; storesrv bei Bedarf |
| Login-Last | idp.replicaCount / Autoscaling; Infinispan-Cache bei mehreren Replikaten beachten |
| Datenbank-Last und Ausfallsicherheit | *-db.cluster.instances: 3 (Lesereplikate); schnelle Storage Class; storage.size erhöhen; regelmäßig VACUUM/ANALYZE |
| Mehr Organisationen | Limits je Organisation in der Administration; Plattform wie oben |
Beispiel:
aisrv:
replicaCount: 3
autoscaling:
enabled: true
minReplicas: 3
maxReplicas: 10
targetCPUUtilizationPercentage: 70
aisrv-db:
cluster:
instances: 3
storage:
size: 50Gi
storageClass: fast-ssd
Speicher skalieren
PVCs vergrößern (Storage Class muss Erweiterung erlauben), Medien-Volume und Modell-Caches getrennt betrachten, Backups mitwachsen lassen – Speicher.
Wann GPUs, wann Knoten
| Situation | Maßnahme |
|---|---|
| Inferenz braucht mehr VRAM, Server hat freie GPU-Slots | GPU hinzufügen; TP oder zweite Instanz |
| Service-Modelle konkurrieren mit Inferenz | Dedizierte Service-GPU oder MIG auf einer großen GPU |
| Server ist voll (GPU-Slots, Strom, Kühlung) | Zweiter Knoten: Inferenz auf eigenen GPU-Host, Plattform bleibt – Deployment-Topologien |
| Hochverfügbarkeit gefordert | Mehrere Knoten, replizierte Datenbanken, Anti-Affinität – separate Architektur, Multi-Node |
| Nur die Oberfläche ist träge | Kein neuer Knoten – Replikate und Datenbank-Instanzen |
Ein Einzelknoten deckt die Referenzkonfigurationen ab; Multi-Node ist der Schritt, wenn Kapazität oder Verfügbarkeit es verlangen – nicht der erste Reflex.
Vorgehen
- Messen (eine Woche, mit Spitzen).
- Eine Schicht ändern, nicht drei.
- Rendern, im Wartungsfenster anwenden, Mischlast prüfen.
- Manifest aktualisieren.
Nächster Schritt: Troubleshooting