Wprowadzanie modeli ML

(Sekcja: Technologia i infrastruktura)

Krótkie podsumowanie

Niezawodne wdrożenie produkcji ML to zbiór: powtarzalnych artefaktów (model/tokenizer/config), standaryzowanego surfingu (Triton/KServe/vLLM), bezpiecznego procesu uwalniania (kanaryjski/niebieski zielony/cień), obserwowalności (opóźnienie, jakość, dryfowanie) i książek startowych na wypadkach. Niskie opóźnienia (przeciwdziałanie oszustwom/personalizacja), ścisłe SLO, PII/zgodność i kontrola kosztów są kluczowe dla iGaming.

1) Tryby wdrażania

Partia (offline): zadania nocne/godzinne (retrospektywne punktowanie, segmenty aktualizacji). Tanie, przewidywalne.
Online (synchroniczny API): anty-oszustwa, personalizacja, zalecenia, porady LLM. Wymaga p95 SLA (na przykład ≤ 100-300 ms).
Strumień (w czasie zbliżonym do rzeczywistego): 1-60 sekund okien (Flink/Spark/Kafka Streams) dla sygnałów CRM i wyzwalaczy.
Hybrid: online szybki wynik szorstki + offline recalculation/calibration.

2) Artefakty i opakowania

Artefakty modelowe: wagi, tokenizer, konfiguracje preprocessing/postprocessing, zestaw danych/wersja kodowa.
Formaty: PyTorch/TF Sa.gModel, ONNX dla kompatybilności, silnik TensorRT do przyspieszania, GGUF/awq/gptq dla kwantyzacji LLM.
Kontenery: obrazy Docker OCI z pinned zależności; znaczniki wielopoziomowe (CPU/GPU).
Immutable releases: tagging 'model: fraud-v3. 2. 1 „,” obraz: oszustwo: 3. 2. 1`.

3) Platforma obsługi

Triton Inference Server: multi-model, dynamiczne butching, ensemble-pipelines.
KServe (K8s-native): automatyczna skala (HPA/KPA), kanaryjska/cień, własny czas trwania.
vLLM/TGI (LLM): ciągłe dozowanie, pamięć podręczna KV, dekodowanie spekulacyjne.
Fichestor: online (ms-SLA) + offline dla parytetu funkcji.

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) Strategie uwolnienia

Niebiesko-zielony: dwa identyczne stosy, natychmiastowe przełączanie ruchu, prosty zwrot.
Kanaryjski: stopniowo wzrasta ruch (1% → 5% → 25% → 100%) w obrębie bram SLO/jakości.
Cień: Nowy model dostaje kopię ruchu, odpowiedzi nie mają wpływu na nic - bezpieczny szacunek.
Testy A/B: mierzymy wskaźniki biznesowe (konwersja, retencja), znaczenie statystyczne.

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

5) SLO i budżety operacyjne

Online anti-fraud/personalization: p95 ≤ 100-150 ms, p99 ≤ 250-400 ms.
Wskazówki LLM (128-512 żetonów): p95 ≤ 300-800 ms generowanie pierwszych żetonów, żetony/s ≥ cel.
Dostępność: ≥ 99. 9% dla ścieżek krytycznych.
Jakość: AUC/PR-AUC/Top-K @ N ≥ próg,% toksyczne/nieprawidłowe odpowiedzi ≤ X.
Koszt: żądania $/1k lub żetony $/1k - w ramach budżetu.

6) CI/CD dla modeli

1. Pociąg/finetune → model w rejestrze (metadane: dane/kod/mierniki/licencje).

2. Pack & Validate: testy jednostkowe przed/po, kompatybilność API, badania obciążenia (opóźnienie/żetony/s).

3. Canary Deploy: 1-5% ruch; obserwowalność (SLO/jakość/koszt).

4. Promocja/Rollback według bram kryteriów.

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) Optymalizacja opóźnień i przepustowości

Tryton/vLLM, żądanie jednoczesności, przed/po przetworzeniu na procesorze.
kwantyzacja (INT8/FP8/INT4) z kalibracją; TensorRT/ONNX Kompilacja runtime.
Buforowanie: funkcja (funkcja online/Redis), wyniki i pamięć podręczna KV dla LLM.
Rozgrzewka: ocieplenie łusek/buforów podczas dumpingu; „ciepłe” autoskale.
Budżet czasu: wczesny przystanek, granica/wiązka żetonu, dostosowanie temperatury.

8) Obserwowalność: telemetria, dryf, jakość

Metryki SRE: RPS, p50/p95/p99, błędy (5xx/4xx), GPU/CPU util, pamięć, kolejka, batch-fill.
Wskaźniki ML: AUC/PR-AUC, błąd kalibracji, zasięg, żetony/s, długość odpowiedzi, trafienie w pamięci podręcznej.
Drift: dywergencja PSI/JS według wejść/funkcji, monitorowanie przesunięcia dystrybucji; wpisy.
Jakość online: Złote skrzynki testowe, Pobieranie próbek odpowiedzi, Automatyczny wynik RAG/Toksyczność LLM.
Logowanie: szybka/odpowiedź (anonimizowana), trace_id, wersja modelowa.

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) Zarządzanie cechami i spójność

Parytet funkcji: takie same transformacje offline/online; funkcje wersji jako kod.
Fichestor online: ms-SLA, TTL, upsert, idempotency; cache bliżej surfingu.
Backfill/refresh: Plan, aby utrzymać w Internecie punktacji od odchylenia od metryki offline.

10) Bezpieczeństwo, PII i licencje

PII: tokenizacja/maskowanie, segmentacja według regionu (EU/TR/LATAM), szyfrowanie w miejscu odpoczynku/tranzytu.
Sekrety/klucze: KMS/Secrets Manager, brak tajemnic w obrazach.
Zasady LLM: filtry treści, bezpieczne korki, red-teaming.
Licencje: warunki kontroli zbiorów danych/wag, zakazy redystrybucji/handlu.
Izolacja: przestrzeń nazw-RBAC, kwoty, plamy/tolerancje dla puli GPU.

11) Autoskale i QoS

Autoskalowanie: przez RPS/kolejka/opóźnienie/GPU-util; min-ready-strąki do infolinii.
Klasy QoS: online critical (anti-fraud)> LLM chat> eksperymenty. Wyprzedzanie na korzyść krytyków.
Multi-region: routing oparty na opóźnieniach, podgrzewane bufory wagowe, replikacja funkcji.

12) Książki startowe i incydenty

p99 wzrost: sprawdź wypełnienie partii, kolejka, GPU-util, cache miss; włączyć agresywne mycie/niższe wiązki/żetony.
Jakość spadła: odwrót do poprzedniej wersji, włącz cień, naprawić źródła dryfu.
Koszt rośnie: umożliwienie kwantyzacji/TensorRT, zwiększenie partii, optymalizacja funkcji/pamięci podręcznej, zmniejszenie częstotliwości generacji LLM za pomocą pamięci podręcznej RAG/result.
Incydent PII: natychmiastowe zatrzymanie linii, wycofanie artefaktu, audyt dostępu, sprawozdanie z procedury dla organu regulacyjnego.

13) Przykładowe szablony

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) Lista kontrolna wdrażania

1. Zdefiniuj SLO/SLA (opóźnienie/dostępność/jakość/koszt).
2. Standaryzacja artefaktów i rejestru modeli (wersje, metadane).
3. Wybierz stos serwujący (Triton/KServe/vLLM) i fichester.
4. Ustaw kanarki/niebieski zielony/cień i automatyczne bramy.
5. Budowa CI/CD: testy kompatybilności, regresja perfu, bezpieczna promocja.
6. Należy uwzględnić obserwowalność (metryki SRE + ML), monitorowanie dryfu i wpisy.
7. Zapewnić PII/bezpieczeństwo/licencje i audyt.
8. Konfiguruj zasady autoskali/QoS i wielu regionów.
9. Przygotuj książkę startową i mieć dzień gry.
10. Wprowadź zarządzanie kosztami: masowanie, kwantyzacja, pamięć podręczna, RAG.

15) Antypattery

Wdrożyć „jak jest” bez kanarka/obserwowalność → nieoczekiwane incydenty.
Niespójne funkcje offline/online → rozbieżność metryczna.
Brak testów perf i limitów → p99 „floats”.
Rejestrowanie wierszy/odpowiedzi bez anonimizacji → ryzyko PII.
Jeden wspólny basen GPU dla wszystkiego bez QoS → krytyczne cierpi online.
Nie ma rollback i migawki artefaktów → długie przestoje.

Podsumowanie

Udane wdrożenie modeli ML to pojemnikowe artefakty, standaryzowana porcja, bezpieczny proces uwalniania (kanaryjski/niebiesko-zielony/cień), twarde SLO oraz jakość/dryf/obserwowalność kosztów. Dodaj fichestore, CI/CD z bramami perf, higieną PII, autoskalą i QoS - a Twoje usługi przeciwdziałania oszustwom/personalizacji/LLM będą konsekwentnie utrzymywać najwyższe obciążenia iGaming, pozostając przewidywalne w p99 i budżecie.