Implementarea modelelor ML

(Secțiunea: Tehnologie și infrastructură)

Scurt rezumat

Implementarea fiabilă a producției ML este o colecție de: artefacte repetabile (model/tokenizer/config), surfing standardizat (Triton/KServe/vLLM), proces securizat de eliberare (canar/albastru verde/umbră), observabilitate (latență, calitate, derivă) și runbook-uri privind incidentele. Latența scăzută (antifraudă/personalizare), SLO strict, PII/conformitatea și controlul costurilor sunt esențiale pentru iGaming.

1) Moduri de implementare

Lot (offline): sarcini de noapte/oră (scoring retrospectiv, actualizarea segmentelor). Ieftin, previzibil.
Online (API sincron): anti-fraudă, personalizare, recomandări, sfaturi LLM. Necesită p95 SLA (de exemplu, ≤ 100-300 ms).
Stream (aproape în timp real): 1-60 ferestre sec (Flink/Spark/Kafka Streams) pentru semnale CRM și declanșatoare.
Hibrid: online scor dur rapid + recalculare offline/calibrare.

2) Artefacte și ambalaje

artefacte model: greutăți, tokenizer, preprocesare/postprocesare configurații, set de date/versiune de cod.
Formate: PyTorch/TF SavedModel, ONNX pentru compatibilitate, TensorRT-motor pentru accelerare, GGUF/awq/gptq pentru cantitate LLM.
Containere: Imagini OCI Docker cu dependențe fixate; etichete multi-platformă (CPU/GPU).
Lansări imuabile: etichetarea "model: fraudă-v3. 2. 1 ', "imagine: fraudă: 3. 2. 1`.

3) Platforma de servire

Triton Inference Server: multi-model, butching dinamic, ansamblu-conducte.
KServe (nativ K8s): scară automată (HPA/KPA), canar/umbră, rulare proprie.
vLLM/TGI (LLM): batare continuă, cache KV, decodare speculativă.
Fichestor: online (ms-SLA) + offline pentru paritatea caracteristicilor.

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) Strategii de lansare

Blue-Green: două stive identice, comutare instantanee a traficului, rollback simplu.
Canare: creșterea treptată a traficului (1% → 5% → 25% → 100%) pe porți SLO/de calitate.
Shadow: Noul model primește o copie a traficului, răspunsurile nu afectează nimic - o estimare sigură.
Teste A/B: măsurăm valorile de afaceri (conversie, păstrare), semnificație statistică.

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

5) SLO-uri și bugete de funcționare

Antifraudă/personalizare online: p95 ≤ 100-150 ms, p99 ≤ 250-400 ms.
Sugestii LLM (128-512 jetoane): p95 ≤ 300-800 ms generarea primelor jetoane, jetoane/s ≥ țintă.
Disponibilitate: ≥ 99. 9% pentru căi critice.
Calitate: ASC/PR-ASC/Top-K @ N ≥ prag;% răspunsuri toxice/incorecte ≤ X.
Cost: $/1k cereri sau $/1k jetoane - în cadrul bugetului.

6) CI/CD pentru modele

1. Tren/finetune → model în registru (metadate: date/cod/metrici/licențe).

2. Pack & Validate: teste unitare pre/post, compatibilitate API, teste de încărcare (latență/jetoane/s).

3. Canare Implementare: 1-5% trafic; observabilitate (SLO/calitate/cost).

4. Promovarea/Rollback pe criterii porți.

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) Întârzierea și optimizarea debitului

Triton/vLLM, solicita concurenta, pre-/post-procesare pe CPU.
Cantitate (INT8/FP8/INT4) cu etalonare; TensorRT/ONNX Runtime compilare.
Caching: caracteristică (caracteristică online/Redis), rezultate și memorie cache KV pentru LLM.
Încălzire: încălzirea cântarelor/cachurilor în timpul dumpingului; vatră autoscară „caldă”.
Bugetul de timp: oprire timpurie, limita token/fascicul, adaptarea temperaturii.

8) Observabilitate: telemetrie, derivă, calitate

Metrici SRE: RPS, p50/p95/p99, erori (5xx/4xx), util GPU/CPU, memorie, coadă, umplere lot.
Măsurători ML: ASC/PR-ASC, eroare de calibrare, acoperire, jetoane/s, lungime răspuns, cache hit.
Drift: divergență PSI/JS prin intrări/caracteristici, monitorizarea schimbului de distribuție; alerte.
Calitate online: Cazuri de testare a aurului, eșantionare de răspuns, scor automat RAG/toxicitate LLM.
Logare: prompt/răspuns (anonimizat), trace_id, versiunea modelului.

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) Managementul caracteristicilor și consecvența

Caracteristică-paritate: aceleași transformări offline/online; caracteristici de versiune ca cod.
Fichestor online: ms-SLA, TTL, upsert, idempotency; cache mai aproape de navigare.
Backfill/refresh: Un plan de a păstra online de notare de la divergențe de la metrici offline.

10) Securitate, PII și licențe

PII: tokenizare/mascare, segmentare pe regiuni (EU/TR/LATAM), criptare în repaus/în tranzit.
Secrete/chei: KMS/Secrets Manager, fără secrete în imagini.
Politici LLM: filtre de conținut, dopuri sigure, echipa roșie.
Licențe: verificați condițiile pentru seturi de date/greutăți, interdicțiile de redistribuire/comerț.
Izolare: namespace-RBAC, cote, cauciucuri/toleranțe pentru piscine GPU.

11) Autoscale și QoS

Autoscaling: prin RPS/coadă/latență/GPU-util; min-gata-păstăi pentru linii telefonice.
Clasele QoS: critice online (anti-fraudă)> LLM chat> experimente. Preempţiune în favoarea criticilor.
Multi-regiune: rutare bazată pe latență, cache-uri de greutate încălzite, replicare caracteristică.

12) Runbooks și incidente

creștere p99: verificare umplere lot, coadă, GPU-util, pierdere cache; activați butching agresiv/fascicul inferior/jetoane.
Calitatea a scăzut: rollback la versiunea anterioară, porniți umbra, fixați sursele de derivă.
Costul este în creștere: activați cuantificarea/TensorRT, creșteți lotul, optimizați caracteristica/memoria cache, reduceți frecvența generațiilor LLM prin RAG/cache rezultat.
Incident PII: stop-the-line imediat, rechemare artefact, audit de acces, raport de procedură la autoritatea de reglementare.

13) Șabloane de probă

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 de verificare a implementării

1. Definiți SLO/SLA (latență/disponibilitate/calitate/cost).
2. Standardizați artefactele și registrul modelului (versiuni, metadate).
3. Alegeți o stivă de servire (Triton/KServe/vLLM) și un fichester.
4. Configurați canarii/verde albastru/umbră și porți automate.
5. Construiți CI/CD: teste de compatibilitate, regresie perf, promovare sigură.
6. Includeți observabilitatea (metrici SRE + ML), monitorizarea derivei și alerte.
7. Furnizarea de PII/securitate/licențe și audit.
8. Configurați politicile autoscale/QoS și multi-regiune.
9. Pregătiți runbook și au o zi de joc.
10. Introduceți managementul costurilor: butching, cuantificare, cache, RAG.

15) Antipattern

Desfășurați „așa cum este” fără canar/observabilitate → incidente neașteptate.
Caracteristici offline/online inconsecvente → discrepanță metrică.
Absența testelor perf și a limitelor → p99 „plutește”.
Înregistrarea solicită/răspunsuri fără anonimizare → risc PII.
Un bazin comun GPU pentru tot, fără QoS → critice on-line suferă.
Nu există nici un rollback și instantanee de artefacte → timp de nefuncționare lung.

Rezumat

Implementarea cu succes a modelelor ML sunt artefacte containerizate, servire standardizată, un proces de eliberare securizat (canar/albastru-verde/umbră), SLO-uri dure și observabilitate de calitate/derivă/cost. Adăugați fichestore, CI/CD cu porți perf, igienă PII, autoscale și QoS - iar serviciile dvs. antifraudă/personalizare/LLM vor menține în mod constant încărcăturile iGaming de vârf, rămânând previzibile în p99 și buget.