ML მოდელების განლაგება

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

ML- ის საიმედო წარმოების განლაგება არის ერთობლიობა: განმეორებითი არტეფაქტები (მოდელი/ტოკენაზერი/კონფისკაცია), სტანდარტიზებული სერვინგი (Triton/KServe/vLLM), უსაფრთხო გამოშვება (კანარი/შავი მწვანე/shadow), დაკვირვება (ლატენტობა, ხარისხი, დრიფტი) და runbook ინციდენტებისთვის. IGaming- ისთვის კრიტიკულია დაბალი შეფერხება (ანტიფროდიული/პერსონალიზაცია), მკაცრი SLO, PII/შესაბამისობა და ღირებულების კონტროლი.

1) განლაგების რეჟიმები

Batch (ოფლაინი): ღამის/საათების დავალებები (რეტროსპექტივების მორიელი, სეგმენტების განახლება). იაფი, პროგნოზირებადი.
ონლაინ (სინქრონული API): ანტიფროდი, პერსონალიზაცია, რეკომენდაციები, LLM რჩევები. მოითხოვს p95 SLA (მაგალითად, 100-300 ms).
Stream (ნამდვილი დრო): ფანჯრები 1-60 წამი (Flink/Spark/Kafka Streams) CRM სიგნალებისა და გამომწვევებისთვის.
ჰიბრიდი: სწრაფი უხეში მონაკვეთი + ოფლაინ გადაანგარიშება/კალიბრაცია.

2) არტეფაქტები და შეფუთვა

სამოდელო ნიმუშები: წონა, ტოკენიზატორი, წინასწარი დამუშავების/დამუშავების კონფიგურაცია, Dataset/coda ვერსია.
ფორმატები: PyTorch/TF SavedModel, ONNX თავსებადობისთვის, TensorRT ძრავა აჩქარებისთვის, GGUF/awq/gptq LLM რაოდენობისთვის.
კონტეინერები: Docker OCI გამოსახულებები pinned დამოკიდებულებით; მრავალ პლატფორმის ტეგები (CPU/GPU).
Immutable გამოშვებები: tegirling 'model: fraud-v3. 2. 1`, `image: fraud:3. 2. 1`.

3) Serving პლატფორმა

Triton Inference Server: მულტიმედიური, დინამიური batching, ensemble-pipelines.
KServe (K8s-national): მანქანის სკეიტი (HPA/KPA), კანარი/shadow, საკუთარი runtime.
vLLM/TGI (LLM): continuous batching, KV ქეში, სპეკულაციური დეკოდირება.
Fichestor: online (ms-SLA) + ოფლაინ 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) გამოშვების სტრატეგიები

Blue-Green: ორი იდენტური დასტის, მყისიერი ტრაფიკის გადართვა, მარტივი გამოტოვება.
Canary: SLO/ხარისხის games ტრაფიკის თანდათანობითი ზრდა (1% - 5% - 25% - 100%).
Shadow: ახალი მოდელი იღებს ტრაფიკის ასლს, პასუხები გავლენას არ ახდენს - უსაფრთხო შეფასება.
A/B ტესტები: გაზომეთ ბიზნეს მეტრიკა (კონვერტაცია, შენარჩუნება), სტატისტიკური მნიშვნელობა.

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

5) SLO და სამუშაო ბიუჯეტები

ონლაინ ანტიფროდიული/პერსონალიზაცია: p95-100-150 ms, p99-250-400 ms.
LLM მინიშნებები (128-512 ნიშანი): პირველი ნიშნების წარმოქმნის p95-300-800 ms, tokens/s სამიზნე.
წვდომა: 99 ევრო. 9% კრიტიკული გზებისთვის.
ხარისხი: AUC/PR-AUC/Top-K @ N ბარიერი;% ტოქსიკური/არასწორი პასუხები X.
ღირებულება: $1k მოთხოვნა ან/1k აშშ დოლარი - ბიუჯეტის ფარგლებში.

6) CI/CD მოდელებისთვის

1. Train/finetune - მოდელი რეესტრში (მეტამონაცემები: მონაცემები/კოდი/მეტრიკა/ლიცენზია).

2. Pack & Validate: unit ტესტები preproc ./postprots., API- ს თავსებადობა, დატვირთვის ტესტები (latency/tokens/s).

3. Canary Deploy: 1-5% ტრაფიკი; დაკვირვება (SLO/ხარისხი/ღირებულება).

4. Promote/Rollback კრიტერიუმების კარიბჭეზე.

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) შეფერხებისა და გამტარუნარიანობის ოპტიმიზაცია

Batching/mikrobatching (Triton/vLLM), მოთხოვნის პარალელიზმი, pre-/post-processing CPU- ზე.
კვანტური (INT8/FP8/INT4) კალიბრაციით; TensorRT/ONX Runtime კომპოზიცია.
კეშირება: fich (ონლაინ ბიულეტენი/Redis), შედეგები და KV ქეში LLM- სთვის.
Warmup: წონაში/ქეში დათბობა; „თბილი“ საყრდენები სკეიტბორდისთვის.
დროის ბიუჯეტი: ადრეული გაჩერება, ტოქსინების/ბემის შეზღუდვა, ტემპერატურის ადაპტაცია.

8) დაკვირვება: ტელემეტრია, დრიფტი, ხარისხი

SRE მეტრიკა: RPS, p50/p95/p99, შეცდომები (5xx/4xx), GPU/CPU util, მეხსიერება, ჯერი, სატანკო ფილმი.
ML მეტრიკა: AUC/PR-AUC, calibration error, coverage, tokens/s, პასუხის სიგრძე, ქეში-ჰიტი.
დრიფტი: PSI/JS-Divergention შესასვლელი/fiich- ში, განაწილების ცვლის მონიტორინგი; ალერტა.
ონლაინ ხარისხი: საკონტროლო ოქროს მაგალითები, პასუხების ნიმუში, ავტომატური RAG სკორეტი/ტოქსიკურობა LLM- სთვის.
ჟურნალები: prompt/პასუხი (ანონიმიზაციით), trace _ id, მოდელის ვერსია.

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) ფიჩების მართვა და თანმიმდევრულობა

Feature-parity: იგივე ტრანსფორმაციები ოფლაინ/ონლაინ; გააფორმეთ ფიჩები, როგორც კოდი.
ონლაინ მიმღები: ms-SLA, TTL, upsert, idempotence; ქეში უფრო ახლოს არის სერვინგთან.
Backfill/refresh: გეგმა, რომ ონლაინ ესკორტი არ განსხვავდებოდეს ოფლაინ მეტრებთან.

10) უსაფრთხოება, PII და ლიცენზია

PII: ტოკენიზაცია/შენიღბვა, რეგიონების სეგმენტი (EU/TR/LATAM), დაშიფვრა დასვენების/ტრანზიტის დროს.
საიდუმლოებები/გასაღებები: KMS/Secrets მენეჯერი, სურათებში საიდუმლო არ არის.
LLM პოლიტიკა: შინაარსის ფილტრები, უსაფრთხო თავსახური, წითელი თამაში.
ლიცენზიები: შეამოწმეთ პირობები datasets/წონისთვის, აკრძალვები redistribution/კომერციის შესახებ.
იზოლაცია: namespace-RBAC, კვოტები, taints/tolerations GPU ტყვიებისთვის.

11) Autoskale და QoS

Autoscaling: RPS/რიგის/ლატენტობის/GPU-util- ის მიხედვით; min-ready-pods ცხელი ხაზებისთვის.
QoS კლასები: კრიტიკული ონლაინ (anti-fraud)> LLM ჩატი> ექსპერიმენტები. Preemption კრიტიკის სასარგებლოდ.
Multiregion: latency-based routing, გაცხელებული წონის ქეში, fick- ის რეპლიკაცია.

12) Runbooks და ინციდენტები

ზრდა p99: შეამოწმეთ batch fill, ჯერი, GPU-util, ქეში-miss; ჩართეთ აგრესიული ბატჩინგი/შეამცირეთ beam/ნიშნები.
ხარისხი დაეცა: წინა ვერსიაზე დაბრუნება, shadow ჩართვა, დრიფტის წყაროების დაფიქსირება.
ღირებულება იზრდება: ჩართეთ ქვითარი/TensorRT, გაზარდეთ ბატები, ოპტიმიზაცია მოახდინეთ ფიჩები/ქეში, შეამციროთ LLM თაობის სიხშირე RAG/ქეში.
PII ინციდენტი: დაუყოვნებლივი stop-the-line, არტეფაქტების მიმოხილვა, წვდომის აუდიტი, რეგულატორის ანგარიში პროცედურის შესაბამისად.

13) შაბლონების მაგალითები

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) განხორციელების სია

1. განსაზღვრეთ SLO/SLA (latence/availability/quality/cost).
2. სტანდარტიზდება მოდელების არტეფაქტები და რეესტრი (ვერსიები, მეტამონაცემები).
3. შეარჩიეთ Serving Steak (Triton/KServe/vLLM) და fichestor.
4. ამ კანარის/ცისფერი მწვანე/shadow და ავტომატური კარიბჭეების პარამეტრები.
5. აშენეთ CI/CD: თავსებადობის ტესტები, perf რეგრესია, უსაფრთხო პოპულარიზაცია.
6. ჩართეთ დაკვირვება (SRE + ML მეტრიკა), დრიფტის მონიტორინგი და ალერტები.
7. უზრუნველყეთ PII/უსაფრთხოება/ლიცენზია და აუდიტი.
8. კონფიგურაცია autoskale/QoS და მრავალ რეგიონალური პოლიტიკოსები.
9. მოამზადეთ runbook და გაატარეთ თამაშის დღე.
10. შეიყვანეთ ღირებულების კონტროლი: batching, quantization, ქეში, RAG.

15) ანტიპატერები

გაუფერულება „როგორ არის“ კანარის/დაკვირვების გარეშე - მოულოდნელი ინციდენტები.
offline/online არაკოორდინირებული ფიჩები არის მეტრიკის შეუსაბამობა.
პერფის ტესტებისა და შეზღუდვების არარსებობა p99 „ბანაობს“.
პრომტების/პასუხების ანონიმიზაციის გარეშე ლოდინი PII- ს რისკს წარმოადგენს.
ერთი საერთო GPU აუზი მხოლოდ QoS- ის გარეშე არის კრიტიკული ინტერნეტით.
არ არის გამოტოვებული არტეფაქტების სნაიპშოტები, გრძელი სისუსტეები.

შედეგები

ML- მოდელების წარმატებული განლაგება არის კონტეინერიზებული არტეფაქტები, სტანდარტიზებული სერვინგი, უსაფრთხო/ცისფერი-მწვანე/shadow, მკაცრი SLO და ხარისხის/დრიფტის/ღირებულების დაკვირვება. დაამატეთ fichestor, CI/CD პერფორირებული კარიბჭეებით, PII ჰიგიენა, ავტო სკეიტი და QoS - და თქვენი ანტიფროდიული/პერსონალიზაცია/LLM სერვისები სტაბილურად შეინარჩუნებენ iGaming- ის პიკის დატვირთვებს, რომლებიც პროგნოზირებენ p99 და ბიუჯეტში.