Bereitstellung von ML-Modellen

1) Rolle und Ziele

Bereitstellung = zuverlässige Lieferung von Inference an das Produkt und den Betrieb unter Einhaltung von RG/AML/Legal und Budgets.
Ziele: geringe Latenz, hohe Verfügbarkeit, Reproduzierbarkeit, Sicherheit und schnelle Reversibilität (Rollback).

2) Serving-Architekturen

2. 1 Muster

Online (real-time): REST/gRPC, p95 50-150 ms für Personalisierung; ≤2 -5 s für RG/AML-Alert.
Near-real-time: Mikrobatches 1-5 min (OLAP-Vitrinen).
Batch/offline: Nachtvitrinen Gold, WORM-Exporte für die Regulierungsbehörde.
In-Process Scoring: Einbettung des Light-Modells in den Service (geringe Latenz).
Serverless: Kaltstartfunktionen für seltene Aufgaben.

2. 2 Topologien

Single Model Service → einfach und schnell.
Ensemble/Graph (router → preprocess → model → postprocess) → komplexe Pipelines.
Sidecar Feature Fetcher → zieht Online-Dateien aus Caches (Redis/Scylla).

3) Modellregister und Versionen

Registry: 'model _ id', 'version', 'stage = {Staging, Production, Archived}', Artefakte (Gewichte, Preprozessor, Kalibrierung), Anforderungen (CPU/GPU/Speicher), Modellkarte (Daten, Metriken, Risiken, Fairness).
Immutable Artefakte: content-hash; WORM-Kopien von Releases.
Rücknahmepolitik: nur über Register und deklarative Manifeste.

4) Containerisierung und Verpackung

dockerfile
FROM python:3. 11-slim
ENV PYTHONUNBUFFERED=1
WORKDIR /app
COPY requirements. txt.
RUN pip install -r requirements. txt --no-cache-dir
COPY artifacts/./artifacts/
COPY src/./src/
CMD ["python", "src/serve. py"]

python serve. py from fastapi import FastAPI import joblib, time app = FastAPI()
model = joblib. load("artifacts/model. joblib")
scaler = joblib. load("artifacts/scaler. joblib")

@app. post("/score")
def score(payload: dict):
t0 = time. time()
x = preprocess(payload, scaler)
y = float(model. predict_proba([x])[0,1])
return {"score": y, "latency_ms": int((time. time()-t0)1000), "model_version": "1. 8. 3"}

5) Kubernetes/Helm und Auto-Scaling

yaml apiVersion: apps/v1 kind: Deployment metadata: {name: ml-score, labels: {app: ml-score}}
spec:
replicas: 3 selector: {matchLabels: {app: ml-score}}
template:
metadata: {labels: {app: ml-score}}
spec:
containers:
- name: api image: registry/ml-score:1. 8. 3@sha256:...
ports: [{containerPort: 8080}]
resources:
requests: {cpu: "500m", memory: "512Mi"}
limits:  {cpu: "2",  memory: "2Gi"}
envFrom: [{secretRef: {name: ml-secrets}}]
readinessProbe: {httpGet: {path: /healthz, port: 8080}, periodSeconds: 5}
livenessProbe: {httpGet: {path: /livez,  port: 8080}, periodSeconds: 10}

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: {name: ml-score-hpa}
spec:
scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: ml-score}
minReplicas: 3 maxReplicas: 50 metrics:
- type: Pods pods:
metric: {name: requests_per_second}
target: {type: AverageValue, averageValue: "15"}
- type: Resource resource: {name: cpu, target: {type: Utilization, averageUtilization: 70}}

6) Roll-out-Strategien

Schatten (dunkler Start): Das neue Modell verarbeitet Abfragekopien, Antworten werden ignoriert; Vergleich der Metriken/Latenz/Kosten.
Canary: 1-10% Traffic → 25% → 50% → 100% mit grünem SLO; automatisches Zurückrollen bei Degradation.
Blau-Grün: parallele Stapel; Instant-Routing-Switch.
Gradual Feature Flag: Routing über Märkte/Tenanten/Geräte.
A/B/n: Online-Experimente mit sequentiellen Tests.

yaml routes:
- match: {tenant: "EEA"} # feature-flags/rules to: {model: "1. 8. 3", weight: 20}
- match: {tenant: "EEA"}
to: {model: "1. 7. 9", weight: 80}

7) Fichy online/offline: Äquivalenz

Einheitliche Transformationsbibliothek und Feature Store (online + offline).
Äquivalenztest: MAE/MAPE zwischen Online-Fichs und Offline-Referenz auf einer Referenzprobe.
Cache-Fich: Redis/Scylla, TTL für Fenstermerkmale; Timeouts und Fallbacks.

8) Beobachtbarkeit, SLO und Warnung

8. 1 SLI/SLO-Benchmarks

Latenz: p95 ≤ 150 ms (Personalisierung), p99 ≤ 300 ms; RG/AML Alert ≤ 5 mit Ende-zu-Ende.
Verfügbarkeit: ≥ 99. 9%.
Inference-Fehler: ≤ 0 5% 5xx; coverage ≥ 99%.
Drift: PSI fich/scora <Schwelle, ECE (Kalibrierung) stabil.
Бизнес: uplift Net Revenue, fraud saved, time-to-intervene.

8. 2 Metriken (Prometheus)

yaml
- http_request_duration_seconds{quantile="0. 95"}
- http_requests_total{code=~"5.."}
- model_inference_latency_ms_bucket
- feature_fetch_latency_ms_bucket
- model_score_distribution_bucket
- psi_feature_{name}
- expected_cost_live

yaml
- alert: HighP95Latency expr: histogram_quantile(0. 95, sum(rate(model_inference_latency_ms_bucket[5m])) by (le)) > 0. 15 for: 10m
- alert: DriftDetected expr: psi_feature_amount_base > 0. 25 for: 15m

Трейсинг: OpenTelemetry — span’ы `feature_fetch`, `score`, `postprocess`, `guardrail`.

9) RG/AML guardrails und Sicherheitspolitik

Pre-/Post-Filter: Masken für verbotene Aktionen (Häufigkeit von Impressionen, Cooldown, Verbot von aggressiven Offern).
Policy Shielding: Steigung über der RG-Schwelle → sanfte Intervention/Pause.
Audit: Protokollierung von 'policy _ id', 'propensity', 'mask', 'decision', 'reason'.
PII und Wohnsitz: Token statt ID, separate Verschlüsselungsschlüssel und Cluster im EWR/UK/BR; Verbot regionenübergreifender Join's ohne Grundlage.
Geheimnisse: KMS/CMK, Secret Manager; keine PII in Logs/Traces.

10) Kalibrierung, Schwellenwerte und Entscheidungspolitik

Kalibrierung (Platt/Isotonic) als Artefakt.
Schwelle für erwartete Kosten; konfigurierbar in Registry/Ficha-Flag.
Sicherheitskappen: obere/untere Aktionsgrenzen, manuelle Override für Compliance.

11) Pullbacks, Degradationen und DR

Ein-Klick-Rollback: Umschalten der Route auf die vorherige' model _ version'.
Runbook: Skripte „latentnost↑“, „Fehler 5xx↑“, „Drift/Kalibrierung gebrochen“, „Externer Fitch-Provider nicht verfügbar“.
Fehlerisolierung: Circuit Breaker, Retry/Backoff, Cache der letzten gültigen Lösung.
DR: Artefakt/Registry-Backups, Replikation in die „warme“ Region, Übungen.

python try:
features = fetch_features(timeout=30)
except TimeoutError:
features = last_known_good(user_id) # fallback

12) Kosten-Engineering und Produktivität

Pfadprofilierung: fichy (30-60%), Modell (20-40%), Netzwerk/IO (10-30%).
Kostenreduzierung: Caching von Hot Fich, Replay-Quoten, Lightweight-Modelle, INT8/FP16 (falls zutreffend), Lazy-Postprocess.
HPA auf RPS/CPU/Latenz, Beschränkung auf State-Size bei Stream-Fit.
Chargeback: cost/request, cost/feature; Budgets für Märkte/Teams.

13) Sichere Freigaben und Compliance

Prod Readiness Kriterien: SLO grün auf Schatten, keine Drift/Leckage, Modellkarte voll, Fairness-Slices normal.
Regulator: WORM-Archiv der Veröffentlichung (Gewichte, Kalibrierung, Schwellenwerte, Metriken, Testprotokolle), unveränderliche Exportberichte.
DSAR/RTBF: Verfahren zum Entfernen von Spuren eines bestimmten Benutzers aus Caches/Logs/Fich.

14) QS vor dem Ausrollen

Integrationstests: API-Vertrag, Schemata, „leere/extreme“ Fälle.
Last: p99, Verteilungsschwänze, Burst-Verkehr.
Äquivalenztest online/offline.
Chaos-Tests: Ausschalten des Fich-Cache/Base, Timeouts externer Dienste.

15) Beispiele für Konfigurationen

yaml
- match: [headers: {x-exp: "canary"}]
route:
- destination: {host: ml-score-v1-8-3, weight: 20}
- destination: {host: ml-score-v1-7-9, weight: 80}

python
@app. get("/healthz")
def health():
return {"ok": True, "model_version": "1. 8. 3", "registry_sig_ok": verify_signature()}

16) Prozesse und RACI

R (Responsible): MLOps (Serving/Orchestration/Observability), Data Eng (Fici/Caches/Contracts), Data Science (Modellkarten/Kalibrierung/Schwellenwerte).
A (Accountable): Head of Data / CDO.
C (konsultiert): Compliance/DPO (PII/RG/AML/DSAR), Security (KMS/Secrets/Audit), SRE (SLO/Incidents), Finance (ROI/Budgets).
I (Informed): Produkt/Marketing/Betrieb/Support.

17) Umsetzungsfahrplan

1. Modellregister und immutable Artefakte; FastAPI/gRPC-Service + K8s/Helm.

2. Shadow-Start mit p95/5xx/Drift-Überwachung, Fich-Äquivalenztest.

3. Canary 10% → 50% → 100% mit Rollback-Auto-Script und Alert.

4. Modellkarte, Kalibrierung, Expected-Cost Schwelle und Guardrails v1.

• Ficha Cash, Circuit Breakers, Runbooks/DR-Übungen.
• Auto-Scaling auf RPS/Latenz, Kosten-Dashboards und Chargeback.
• Slice-Monitoring fairness, WORM-Archiv der Veröffentlichungen.

• Serving-Graph (Kandidaten → Re-Rank), Slate-Logging-Propency.
• Multi-Region, Wohnsitz (EWR/UK/BR) mit separaten Schlüsseln.
• Auto-Roll/Überfärbung durch Drift, Autogen von Qualitäts-/Kalibrierungsberichten.

18) Prod Readiness Checkliste

• Die Musterkarte ist ausgefüllt; Daten/Daten/Kalibrierung/Schwellenwerte sind versioniert.
• Verträge fich und Äquivalenztest online/offline - grün.
• SLO: p95, 5xx, Abdeckung - grün auf Schatten und 10% canary ≥ 24 Stunden.
• Alerts und Dashboards (Latenz/Fehler/Drift/expected-cost) sind enthalten.
• Guardrails RG/AML und Entscheidungsaudits sind aktiv; PII/Wohnsitz eingehalten.
• One-Click Rollback und Runbook Incidents getestet.
• Die Kosten sind im Haushaltsplan enthalten. HPA und Cache sind konfiguriert.

19) Anti-Muster und Risiken

Manuelle Ausrollen ohne Register und immutable Artefakte.
Inkonsistente Online-/Offline-Daten → Unstimmigkeiten in der Produktion.
Das Fehlen von Schatten/Kanaren → versteckte Regressionen.
Schwelle nicht durch erwartete Kosten, keine Kalibrierung.
Synchrone externe Lookups ohne Timeouts/Cache.
Kein DR/Rollback, kein WORM-Archiv der Veröffentlichung.

20) Das Ergebnis

Die ML-Produktion ist keine „Model Challenge“, sondern eine Engineering-Plattform: Registry und Versionen, sichere Rollouts (Shadow/Canary/Blue-Green), Fachdisziplin und Kalibrierung, Beobachtbarkeit und SLO, Guardrails für RG/AML und ein klarer Rollback-Plan. Wenn Sie diesem Playbook folgen, erhalten Sie eine schnelle, zuverlässige und konforme Inferenz, die durchweg Geschäftswert zu kontrollierten Kosten bringt.