KI-Infrastruktur und GPU-Pools

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Produktion-AI ist nicht „ein Modell auf einem Server“, sondern ein Cluster aus GPU-Knoten, Shared Accelerator Pools, Unified Serving, Daten/Daten, Beobachtbarkeit und Value Management. Für iGaming ist es in Echtzeit kritisch: Fraud, Personalisierung, Chatbots, LLM-Assistenten, Spiel-/Aktionsempfehlungen. Grundsteine: Kubernetes/Slurm für die Planung, Isolierung von Arbeitslasten, Hochgeschwindigkeitsnetz (100/200/400G mit RDMA), schnelle Speicher, ausgereifte MLOps und „Stahlbeton“ SLO.

1) Architektonische Karte

1. Rechencluster: GPU-Knoten (A/H-Klassen, AMD/ROCm, Intel Gaudi, etc.), CPU-Knoten für Preprocessing/Fics.

2. Netzwerk: 100G + Ethernet/IB, RDMA (RoCEv2), NCCL-Topologien, QoS.

3. Der Aufbewahrungsort: objekt- (S3-sowmest.) , verteilte POSIX (Ceph/grid), lokale NVMe-Scratch.

4. Daten/Daten: Fichester (online/offline), Vektor-DBs (ANN), Cache (Redis), Warteschlangen.

5. ML-Plattform: Register der Artefakte und Modelle, Pipelines (CI/CD), Versionskontrolle, Fichi als Code.

6. Service Layer: Triton/KServe/vLLM/text-generation-inference (TGI), A/V/canary-deploy, Autoresis.

7. Governance und Sicherheit: PII, Geheimnisse, Audit, Exportrichtlinien, Waagen-/Dataset-Lizenzen.

• Online-Scoring (p95 ≤ 50-150 ms) - Betrugsbekämpfung, Empfehlungen, Ranking.
• LLM-Surfen (p95 ≤ 200-800 ms für 128-512 Token) - Chat/Agenten/Hinweise.
• Batch Analytics/Nachschulung - Nachtfenster, Offline-Metriken.
• Feinthuning/Anpassung - periodisch, mit Priorität unter online.

2) GPU-Pools und Planung

Modell der Pools

Pool „Serving“: kurze Anfragen, hohes Batching, strenge SLOs.
Pool „Training/Feinthüning“: lange Jobs, verteiltes Training (DDP).
Pool „F & E/Experimente“: Quoten/Limits, Präemption erlaubt.
Pool „CPU/Pre-/Post-processing“: Normalisierung, Tokenisierung, Rerank auf der CPU.

Planer

Kubernetes (+ device-plugin, NodeFeatureDiscovery, taints/tolerations, PriorityClass, PodPriority/Preemption).
Slurm (oft für HPC-Training) - kann mit K8s durch einzelne Worker gemischt werden.
Fairshare und Quoten: Namespace-Quoten für GPU, CPU, Speicher; „Banken“ GPU-Uhren; Nijmspace-/Projektlimits.

GPU-Partitionierung

MIG (Multi-Instance GPU): Schneiden des Beschleunigers in isolierte Slices (für Serving/Multi-Tenant).
MPS: SM-Sharing für kleine Aufgaben (Interferenz überwachen).
NVLink/PCIe: Berücksichtigen Sie die Topologie beim Pinning von Pods (Topology Aware Scheduling).

yaml apiVersion: v1 kind: Pod metadata:
annotations:
scheduling. k8s. io/group-name: "ai-serving"
spec:
nodeSelector: { gpu-pool: serving }
tolerations: [{ key: "gpu", operator: "Exists", effect: "NoSchedule" }]
priorityClassName: ai-serving-critical

3) Netzwerk- und standortübergreifende Leistung

RDMA (RoCEv2) für NCCL-All-Revises ECN/PFC-Einstellungen, Isolierung von Verkehrsklassen.
Lokalisierung: Training innerhalb einer „Fabrik“ (Pod/Host/Optik), Serving - näher am Benutzer (Edge/Region).
Congest-Steuerung: Tuned Profile, Jumbo Frames, Pin-Ning-Schnittstellen.

4) Speicher und Daten

Waage/Artefakt-Speicher: Objekt (Versionierung, Immutability).
Dataset/Fichi: Lakehouse (Delta/Iceberg/Hudi) + Offline-Fiechor; Online-Fichester (Millisekunden-SLAs).
Vektor-DBs (ANNs): Faiss/ScaNN/Accelerators oder Vektorvektor-Engines; Sharding, HNSW/IVF, Replikation.
Lokaler NVMe-Cache: Aufwärmen der Waage/Embedding für einen Kaltstart.

5) Serving-Modelle

Frameworks

Triton Inference Server (Multimodel, Multi-Runtime, Dynamic Batching).
KServe (K8s-nativ, autoscaling HPA/KPA, Kanari).
vLLM/TGI für LLM-Tokenisierung und Hochleistungs-Decodierung (Paged-Attention, KV-Cache Offload).
ONNX Runtime/TensorRT-LLM - für Kompilierung und Beschleunigung.

Optimierungen

Quantisierung: INT8/FP8/INT4 (Perzentil/Kalibrierung, AWQ/GPTQ) - online vorsichtig, Qualität messen.
Zusammenstellung des Graphen: TensorRT, TorchInductor/XLA, fused-kernels.
Batching/Microbatching: dynamisch und statisch; для LLM — continuous batching.
KV-Cache: Sharing zwischen Anfragen, Offload auf CPU/NVMe in langen Kontexten.
Spekulatives Decodieren: Entwurfsmodell + Verifikator zur Beschleunigung des Token-Proofs.
Token/Kontext-Limits, früher Stopp, Stopp-Wörter, Zeit-Budget auf Anfrage.

Deploy-Richtlinien

A/B, Kanari, Schatten - Vergleich von Latenz/Qualität/Geschäftsmetriken.
Blue Green - kein Downtime.
Rollback durch SLO/Fehler.

6) Training/Feinarbeit

DDP/FSDP/ZeRO: verteilter Speicher/Gradienten, Berücksichtigung von NVLink/Topologie.
Checkpoints: inkrementell/vollständig, Frequenz vs I/O.
Mixed Precision: bf16/fp16 + loss scaling; Stabilität zu profilieren.
Dataset-Sharding: einheitlicher Iterator, Replikation nach Knoten.
Prioritäten: Unterbrechbare Jobs (preemptible) zugunsten von Serving.
Autonome Pipelines: Data → Train → Eval → Register → Promotion in PROD nach Gate-Kriterien.

7) MLOps und Plattform

Modellregister: Versionen, Signaturen, Abhängigkeiten, Lizenzen/Nutzungsrecht der Waage.
CI/CD-Modelle: Kompatibilitätstests, Performance-Regressionen, Quality-Gates, Safe Deploy.
Fichester: Offline/Online-Konsistenz (Feature Parity), TTL und Backfill.
Data/Model Lineage: Trace vom Dataset zum Report/Experiment.
Verzeichnis der Prompts/Templates für LLM (Versionierung).

8) Beobachtbarkeit und SLO

• Latenz p50/p95/p99, tokens/s, batch occupancy, queue wait, GPU-util/SM occupancy, memory, bugs.
• LLM-Spezifität: I/O-Token, durchschnittliche Antwortlänge, Bounce-by-Limit-Anteil, KV-Cache-Hit.
• Qualität: automatische Regressionstests (offline), Online-Telemetrie (Inhaltsflags, Toxizität, Genauigkeit der Ausgabe auf Goldproben).
• Business SLO: Personalisierungskonvertierung, Anti-Fraud-Genauigkeit, Retention.

Alertas: p99/Warteschlangen-Wachstum, Token/s-Rückgang, Batch-Fill-Degradation, VRAM/PCIe-Throttle-Erschöpfung, Ausfallrate-Limit-Wachstum.

9) Sicherheit, Compliance und Datenschutz

PII/Daten: Segmentierung von Berechnungen und Daten nach Regionen, Verschlüsselung in Ruhe/im Transit, Tokenisierung.
Geheimnisse/Schlüssel: KMS/Secrets Manager; Ausschließen der Speicherung in Images/Code.
LLM-Ausgaberichtlinien: Sicherheitsfilter, Red-Teaming, Protokollierung von Prompts/Antworten (mit Anonymisierung).
Lizenzen: Übereinstimmung mit Dataset/Gewichtslizenzen; „no-redistribute „/kommerzielle Beschränkungen.
Isolierung von Tenanten: Namespace-RBAC, Netzwerke, MIG-Slices, Limits und Quoten.

10) Kosten und Phinops

Capacity-Planung: Lastprofile (RPS, Token/sec), „Tails“ von Turnieren und Kampagnen.
Reserve/Spot: gemischte Pools (reserved + spot/preemptible) mit Neuaufstellung von Aufgaben und Checkpoints.
Autoscale: HPA/KPA durch RPS/queue Tiefe/GPU-util; „Warmstart“ mit aufgewärmten Gewichten.
Modell Zoo: Reduzieren Sie die Anzahl der Optionen; Verwenden Sie eine Anpassung (LoRA/PEFT) anstelle einer vollständigen Duplizierung.
Cache: Embeddings/teure Abfrageergebnisse, KV-Cache-Sharing für LLM.
Token-Optimierung: Komprimierung von Prompts, retrieval-augmented generation (RAG), rerank vor der Generierung.

11) Multiregion, HA und DR

Active/Active-Serving näher am Benutzer, globales Routing (latenzbasiert).
Replikation von Gewichten und Fics mit Integritätsprüfung; Aufwärmen von Caches bei Releases.
DR-Plan: Verlust von AZ/Region, Evakuierung auf Reservepool, Steuerung der Abhängigkeit vom zentralen Katalog.
Chaos-Tage: Fehlertests für GPU-Knoten/Netzwerkdomänen/Speicher.

12) Konfigurationsmuster (Konzepte)

text dynamic_batching {
preferred_batch_size: [4, 8, 16, 32]
max_queue_delay_microseconds: 2000
}
instance_group { count: 2 kind: KIND_GPU }

yaml spec:
predictor:
canaryTrafficPercent: 20 model:
modelFormat: { name: triton }
resources:
limits: { nvidia. com/gpu: "1" }

--tensor-parallel-size 2
--max-num-seqs 512
--gpu-memory-utilization 0. 9
--enforce-eager

13) LLM-Spezifität: RAG und Suchkontur

Indizierung: Chanking, Embedding, ANN-Sharding durch 'tenant/locale'.
Rerank: leichtes Modell auf CPU/GPU-Slice für erhöhte Genauigkeit.
Prompt/Kontext-Cache: Dedup, canonicalization.
Zitier-/Haftungsrichtlinien für sensible Bereiche (KUS/Regeln).

14) Checkliste Umsetzung

1. SLO (p95 latency/tokens/s, availability) und Lastprofile fixieren.
2. Unterteilen Sie den Cluster in Pools (serving/train/R & D), geben Sie die Quoten/Prioritäten ein.
3. Aktivieren Sie RDMA/NCCL und topologisch bewusste Planung.
4. Konfigurieren Sie die Speicher: Waagen, Datasets, Fichester (online/offline), Vektor-DBs.
5. Wählen Sie einen Serving-Stack (Triton/KServe/vLLM) und fügen Sie Batching/KV-Cache/Quantisierung hinzu.
6. Führen Sie die Modellregistrierung, CI/CD, Kanari/Shadow-Deploy aus.
7. Liefern Sie Beobachtbarkeit: System + Geschäftsmetriken, Qualitäten, Verfolgung.
8. Geben Sie Sicherheitsrichtlinien/PII, Lizenzen, Audit ein.
9. TCO optimieren: reserved + spot, Auto-Scale, Cache, PEFT statt kompletter Klone.
10. Bereiten Sie HA/DR vor und verbringen Sie einen Spieltag.

15) Antipatterns

„Eine große GPU für alles“ ohne Pools und Prioritäten.
Das Fehlen von dynamischem Batching und KV-Cache für LLM → eine Explosion von p99 und Kosten.
Training und Serving auf einem Pool ohne Präemption → SLO-Vorfälle.
Null Qualität/Sicherheit Telemetrie → unmerkliche Degradation und Risiken.
Zentralisierter Monolith ohne Fichester/Modellregister → keine Reproduzierbarkeit.
Skalen-/Datenlizenzen ignorieren.

Ergebnisse

Eine erfolgreiche KI-Infrastruktur besteht aus GPU-Pools mit intelligenter Planung, hohem Netzwerk und korrektem Speicher, effizientem Serving (Batching, Cache, Quantisierung, Kompilierung), ausgereiften MLOps und strengen SLOs. In Kombination mit Sicherheit/PII, multiregionalem HA/DR und durchdachtem Finop liefert die Plattform ein stabiles p99, kontrolliertes $/Request und eine schnelle Einführung neuer Modelle - von der Fraud-Bekämpfung über die Personalisierung bis hin zu LLM-Assistenten.