Розгортання ML-моделей

(Розділ: Технології та Інфраструктура)

Коротке резюме

Надійне продакшн-розгортання ML - це сукупність: повторюваних артефактів (модель/токенайзер/конфіг), стандартизованого сервінгу (Triton/KServe/vLLM), безпечного реліз-процесу (канарі/блю-грін/shadow), спостережуваності (латентність, якість, дрейф) і runbook-ів на інциденти. Для iGaming критичні низька затримка (антифрод/персоналізація), строгі SLO, PII/комплаєнс і контроль вартості.

1) Режими розгортання

Batch (офлайн): нічні/годинні завдання (скоринг ретроспективи, оновлення сегментів). Дешево, передбачувано.
Online (синхронний API): антифрод, персоналізація, рекомендації, LLM-підказки. Вимагає p95 SLA (наприклад, ≤ 100-300 мс).
Stream (near-real-time): вікна 1-60 сек (Flink/Spark/Kafka Streams) для сигналів і тригерів CRM.
Гібрид: онлайн швидкий грубий скорер + офлайн перерахунок/калібрування.

2) Артефакти та упаковка

Модельні артефакти: ваги, токенізатор, конфіги препроцесингу/постпроцесингу, версія датасету/коду.
Формати: PyTorch/TF SavedModel, ONNX для сумісності, TensorRT-engine для прискорення, GGUF/awq/gptq для LLM-квантизації.
Контейнери: Docker OCI-образи з pinned залежностями; багатоплатформові теги (CPU/GPU).
Immutable-релізи: тегування'model: fraud-v3. 2. 1`, `image: fraud:3. 2. 1`.

3) Платформа сервінгу

Triton Inference Server: мультимодельний, динамічний батчинг, ensemble-pipelines.
KServe (K8s-нативно): авто-скейл (HPA/KPA), канарі/шадоу, власні runtime.
vLLM / TGI (LLM): continuous batching, KV-кеш, спекулятивний декодинг.
Фічестор: online (мс-SLA) + offline для узгодженості фіч (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: поступове нарощування трафіку (1% → 5% → 25% → 100%) за гейтами SLO/якості.
Shadow: нова модель отримує копію трафіку, відповіді ні на що не впливають - безпечна оцінка.
A/B-тести: вимірюємо бізнес-метрики (конверсія, утримання), статистична значимість.

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

5) SLO та робочі бюджети

Онлайн антифрод/персоналізація: p95 ≤ 100-150 мс, p99 ≤ 250-400 мс.
LLM підказки (128-512 токенів): p95 ≤ 300-800 мс генерації перших токенів, tokens/s ≥ цільового.
Доступність: ≥ 99. 9% для критичних шляхів.
Якість: AUC/PR-AUC/Top-K @N ≥ порогу,% токсичних/некоректних відповідей ≤ X. і т.д.
Вартість: $/1k запитів або $/1k токенів - в межах бюджету.

6) CI/CD для моделей

1. Train/finetune → модель в реєстрі (метадані: дані/код/метрики/ліцензії).

2. Pack & Validate: unit-тести препроц ./постпроц., сумісність 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) Оптимізації затримки і пропускної

Батчинг/мікробатчинг (Triton/vLLM), паралелізм запитів, pre-/post-processing на CPU.
Квантування (INT8/FP8/INT4) з калібруванням; TensorRT/ONNX Runtime компіляція.
Кешування: фіч (online-фічестор/Redis), результатів і KV-кеш для LLM.
Warmup: прогрів ваг/кешів при деплої; «теплі» поди для автоскейлу.
Тайм-бюджет: рання зупинка, обмеження токенів/beam, адаптація температури.

8) Спостережуваність: телеметрія, дрейф, якість

SRE-метрики: RPS, p50/p95/p99, помилки (5xx/4xx), GPU/CPU util, пам'ять, черга, batch-fill.
ML-метрики: AUC/PR-AUC, calibration error, coverage, tokens/s, довжина відповіді, кеш-hit.
Дрейф: PSI/JS-дивергенція по входах/фічах, моніторинг зсуву розподілів; алерти.
Якість онлайн: контрольні золоті приклади, семплінг відповідей, автоматичний RAG-score/токсичність для LLM.
Журналювання: промпт/відповідь (з анонімізацією), 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: ті ж трансформації в offline/online; версіонуйте фічі як код.
Онлайн фічестор: мс-SLA, TTL, upsert, idempotency; кеш ближче до сервінгу.
Backfill/refresh: план, щоб онлайн-скоринг не розходився з офлайн-метриками.

10) Безпека, PII та ліцензії

PII: токенізація/маскування, сегментація по регіонах (EU/TR/LATAM), шифрування в спокої/в транзиті.
Секрети/ключі: KMS/Secrets Manager, ніяких секретів в образах.
LLM-політики: фільтри контенту, безпечні стопера, red-teaming.
Ліцензії: перевіряйте умови на датасети/ваги, заборони на редистрибуцію/комерцію.
Ізоляція: namespace-RBAC, квоти, taints/tolerations для GPU-пулів.

11) Автоскейл і QoS

Autoscaling: по RPS/черзі/latency/GPU-util; min-ready-pods для гарячих ліній.
QoS-класи: критичний онлайн (anti-fraud)> LLM-чат> експерименти. Preemption на користь критичних.
Мультирегіон: latency-based routing, прогріті вагові кеші, реплікація фіч.

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 (latency/availability/quality/cost).
2. Стандартизуйте артефакти та реєстр моделей (версії, метадані).
3. Виберіть сервінг-стек (Triton/KServe/vLLM) і фічестор.
4. Налаштуйте канарі/блю-грін/shadow і автоматичні гейти.
5. Побудуйте CI/CD: тести сумісності, перф-регресії, безпечний промоушен.
6. Увімкніть спостережуваність (SRE + ML-метрики), дрейф-моніторинг та алерти.
7. Забезпечте PII/безпеку/ліцензії та аудит.
8. Налаштуйте автоскейл/QoS і мультирегіональні політики.
9. Підготуйте runbook-і і проведіть game-day.
10. Введіть управління вартістю: батчінг, квантизація, кеш, RAG.

15) Антипатерни

Деплою «як є» без канарі/спостережуваності → несподівані інциденти.
Неузгоджені фічі offline/online → розбіжність метрик.
Відсутність перф-тестів і лімітів → p99 «плаває».
Логування промптів/відповідей без анонімізації → ризик PII.
Один загальний GPU-пул для всього без QoS → критичний онлайн страждає.
Немає відкату і снапшотів артефактів → довгі простої.

Підсумки

Успішне розгортання ML-моделей - це контейнеризовані артефакти, стандартизований сервінг, безпечний реліз-процес (canary/blue-green/shadow), жорсткі SLO і спостережуваність якості/дрейфу/вартості. Додайте фічестор, CI/CD з перф-гейтами, PII-гігієну, автоскейл і QoS - і ваші антифрод/персоналізація/LLM-сервіси будуть стабільно тримати пікові навантаження iGaming, залишаючись передбачуваними по p99 і бюджету.