Развертывание 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 и бюджету.