Bereitstellung von ML-Modellen

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Eine zuverlässige ML-Produktions-Bereitstellung ist eine Kombination aus: wiederholbaren Artefakten (Modell/Token-Izer/Config), standardisiertem Serving (Triton/KServe/vLLM), einem sicheren Release-Prozess (Canary/Blue Green/Shadow), Beobachtbarkeit (Latenz, Qualität, Drift) und Runbooks auf Vorfälle. Für iGaming sind niedrige Latenz (Anti-Fraud/Personalisierung), strenge SLOs, PII/Compliance und Kostenkontrolle entscheidend.

1) Bereitstellungsmodi

Batch (offline): Nacht-/Stundenjobs (Scoring der Retrospektive, Aktualisierung der Segmente). Billig, vorhersehbar.
Online (synchrone API): Fraud, Personalisierung, Empfehlungen, LLM-Hinweise. Erfordert p95 SLA (z. B. ≤ 100-300 ms).
Stream (near-real-time): Fenster 1-60 sec (Flink/Spark/Kafka Streams) für CRM Signale und Trigger.
Hybrid: Online schnell grob vorbestellen + offline nachrechnen/kalibrieren.

2) Artefakte und Verpackung

Modellartefakte: Gewichte, Tokenisierer, Prä-/Postprozessing-Configs, Dataset/Code-Version.
Formate: PyTorch/TF SavedModel, ONNX für Kompatibilität, TensorRT-Engine für Beschleunigung, GGUF/awq/gptq für LLM-Quantisierung.
Container: Docker OCI-Images mit pinned Abhängigkeiten; Multi-Plattform-Tags (CPU/GPU).
Immutable releases: tagging 'model: fraud-v3. 2. 1`, `image: fraud:3. 2. 1`.

3) Serving-Plattform

Triton Inference Server: Multimodelles, dynamisches Batching, Ensemble-Pipelines.
KServe (K8s-nativ): Auto-Skale (HPA/KPA), Kanaren/Schadow, eigene Laufzeiten.
vLLM/TGI (LLM): continuous batching, KV-Cache, spekulative Decodierung.
Fichester: Online (ms-SLA) + Offline für Konsistenz (Feature Parity).

yaml apiVersion: serving. kserve. io/v1beta1 kind: InferenceService metadata: { name: fraud }
spec:
predictor:
canaryTrafficPercent: 15 model:
modelFormat: { name: triton }
storageUri: s3://models/fraud/v3. 2. 1/
resources: { limits: { nvidia. com/gpu: "1" } }

4) Veröffentlichungsstrategien

Blau-Grün: zwei identische Stacks, sofortige Verkehrsumschaltung, einfacher Rollback.
Canary: Schrittweise Steigerung des Traffics (1% → 5% → 25% → 100%) durch SLO/Quality Gates.
Schatten: Das neue Modell erhält eine Kopie des Verkehrs, die Antworten beeinflussen nichts - eine sichere Schätzung.
A/B-Tests: Wir messen Geschäftsmetriken (Conversion, Retention), statistische Signifikanz.

map $request_id $route {
default old;
"~ canary" new; # 5-15% by flag/cook/feature-toggle
}

5) SLO und Arbeitsbudgets

Online die antifrod/Personalisierung: p95 ≤ 100-150 ms, p99 ≤ 250-400 ms.
LLM-Hinweise (128-512 Token): p95 ≤ 300-800 ms Generierung der ersten Token, Token/s ≥ Ziel.
Verfügbarkeit: ≥ 99. 9% für kritische Pfade.
Qualität: AUC/PR-AUC/Top-K @ N ≥ Schwelle;% toxische/inkorrekte Reaktionen ≤ X.
Kosten: $/1k Anfragen oder $/1k Token - innerhalb des Budgets.

6) CI/CD für Modelle

1. Train/finetune → das Modell im Register (Metadaten: Daten/Code/Metriken/Lizenzen).

2. Pack & Validate: Einheitentests preproz ./postproz., API-Kompatibilität, Lasttests (latency/tokens/s).

3. Canary Deploy: 1-5% des Datenverkehrs; Beobachtbarkeit (SLO/Qualität/Kosten).

4. Promote/Rollback nach Kriterien-Gates.

yaml jobs:
build-serve:
steps:
- run: make export_onnx && make docker_build
- run: pytest tests/serve --maxfail=1
- run: python perf_check. py --p95 120 --fail-on-regress
- run: kubectl apply -f kserve-canary. yaml

7) Optimierung von Latenz und Bandbreite

Batching/Microbatching (Triton/vLLM), Parallelisierung von Anfragen, Pre-/Post-Processing auf der CPU.
Quantisierung (INT8/FP8/INT4) mit Kalibrierung; TensorRT/ONNX Laufzeitkompilierung.
Caching: Fich (Online-Fichester/Redis), Ergebnisse und KV-Cache für LLM.
Warmup: Aufwärmen der Waage/Caches bei Deployment; „warme“ Pods für das Autoscale.
Zeitbudget: früher Stopp, Token/Beam-Limit, Temperaturanpassung.

8) Beobachtbarkeit: Telemetrie, Drift, Qualität

SRE-Metriken: RPS, p50/p95/p99, Fehler (5xx/4xx), GPU/CPU util, Speicher, Warteschlange, Batch-Fill.
ML-Metriken: AUC/PR-AUC, Calibration Error, Coverage, Tokens/s, Response Length, Cache Hit.
Drift: PSI/JS-Divergenz nach Input/Fich, Überwachung der Verteilungsverschiebung; Alertas.
Qualität online: Testgold Beispiele, Antworten Sampling, automatische RAG-Score/Toxizität für LLM.
Protokollierung: Prompt/Antwort (mit Anonymisierung), trace_id, Modellversion.

inference_latency_ms_bucket{model="fraud-v3. 2. 1",le="100"} 12345 inference_qps{model="fraud-v3. 2. 1"} 450 tokens_per_second{model="llm-help-v1"} 210

9) Fich-Management und Konsistenz

Feature-parity: die gleichen Transformationen offline/online; versionieren Sie die fici als Code.
Online-Fichester: ms-SLA, TTL, upsert, idempotency; Cache näher am Serving.
Backfill/refresh: Ein Plan, um zu verhindern, dass das Online-Scoring von Offline-Metriken abweicht.

10) Sicherheit, PII und Lizenzen

PII: Tokenisierung/Maskierung, Segmentierung nach Regionen (EU/TR/LATAM), Verschlüsselung in Ruhe/im Transit.
Geheimnisse/Schlüssel: KMS/Secrets Manager, keine Geheimnisse in Bildern.
LLM-Richtlinien: Inhaltsfilter, sicherer Stopper, Red-Teaming.
Lizenzen: Überprüfen Sie die Bedingungen für Datasets/Gewichte, Redistributions-/Handelsverbote.
Isolation: Namespace-RBAC, Quoten, Taints/Tolerations für GPU-Pools.

11) Autoscale und QoS

Autoscaling: durch RPS/Warteschlange/latency/GPU-util; min-ready-pods für Hotlines.
QoS-Klassen: kritisch online (Anti-Fraud)> LLM-Chat> Experimente. Präemption zugunsten der Kritischen.
Multi-Region: latenzbasiertes Routing, erwärmte Gewichtscaches, Replikation von Fich.

12) Runbooks und Vorfälle

P99-Wachstum: Batch-Fill, Warteschlange, GPU-Util, Cache-Miss überprüfen; Aktivieren Sie aggressives Batching/Downbeam/Token.
Die Qualität ist gesunken: Rollback auf die Vorgängerversion, Schatten einschalten, Driftquellen erfassen.
Die Kosten steigen: Quantisierung/TensorRT aktivieren, Batch erhöhen, Fichi/Cache optimieren, LLM-Generierungsrate über RAG/Ergebnis-Cache reduzieren.
PII-Vorfall: sofortiger Stop-the-line, Rückruf von Artefakten, Zugriffsprüfung, Bericht an die Regulierungsbehörde über das Verfahren.

13) Musterbeispiele

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

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

python resp = client. score({"features": f}) # v3. 2. 1 assert set(resp. keys()) >= {"score","version","latency_ms"}

14) Checkliste Umsetzung

1. Definieren Sie SLO/SLA (Latenz/Verfügbarkeit/Qualität/Kosten).
2. Standardisieren Sie Artefakte und Modellregister (Versionen, Metadaten).
3. Wählen Sie einen Serving Stack (Triton/KServe/vLLM) und einen Fichester.
4. Richten Sie Kanari/Blue Green/Shadow und automatische Gates ein.
5. CI/CD erstellen: Kompatibilitätstests, Perf-Regression, sichere Promotion.
6. Ermöglichen Sie Beobachtbarkeit (SRE + ML-Metriken), Driftüberwachung und Alerts.
7. Stellen Sie PII/Sicherheit/Lizenzen und Audit sicher.
8. Konfigurieren Sie AutoScale/QoS und multiregionale Richtlinien.
9. Bereiten Sie das Runbook-i vor und haben Sie einen Spieltag.
10. Geben Sie das Kostenmanagement ein: Batching, Quantisierung, Cache, RAG.

15) Antipatterns

Deploy „wie es ist“ ohne canari/Beobachtbarkeit → unerwartete Vorfälle.
Inkonsistente Daten offline/online → metrische Diskrepanz.
Das Fehlen von Perf-Tests und Grenzen → p99 „schwimmt“.
Die Protokollierung von Prompts/Antworten ohne Anonymisierung → das PII-Risiko.
Ein gemeinsamer GPU-Pool für alles ohne QoS → kritisch online leidet.
Kein Rollback und Snap-Shots von Artefakten → lange Ausfallzeiten.

Ergebnisse

Der erfolgreiche Rollout von ML-Modellen umfasst containerisierte Artefakte, standardisiertes Serving, einen sicheren Release-Prozess (Canary/Blue-Green/Shadow), rigide SLOs und Quality/Drift/Cost Observability. Fügen Sie Fichester, CI/CD mit Perf-Gates, PII-Hygiene, Auto-Scale und QoS hinzu - und Ihre Anti-Fraud/Personalisierung/LLM-Dienste halten die Spitzenlasten von iGaming stabil und bleiben für p99 und das Budget vorhersehbar.