Serving и мониторинг модели

Batch и online

Serving — то, как модель отдаёт ответы в проде. Есть два режима.

Batch (пакетный режим): задача по расписанию берёт всех клиентов, считает ответ модели для каждого и пишет результат в таблицу. Модель churn так и работает: маркетинг утром открывает готовый список. Для batch хватает CronJob в Kubernetes или задачи в Airflow.

Online: модель стоит за HTTP API и отвечает на каждый запрос, например в момент, когда клиент открыл корзину. Здесь важны latency и масштабирование, как у любого API.

Сервис в контейнере

Простой вариант online serving: небольшой сервис на FastAPI, который при старте загружает модель из model registry и отвечает на /predict.

from fastapi import FastAPI
import mlflow
import pandas as pd

app = FastAPI()
model = mlflow.pyfunc.load_model("models:/churn@champion")  # загрузка при старте

@app.post("/predict")
def predict(rows: list[dict]):
    scores = model.predict(pd.DataFrame(rows))
    return {"scores": scores.tolist()}

Дальше всё как с обычным сервисом: Dockerfile, Deployment, Service, HPA, readiness probe.

KServe

KServe — open source платформа для serving моделей в Kubernetes. В 2025 году CNCF приняла его как инкубационный проект.

Модель описывают одним ресурсом InferenceService. KServe сам выбирает контейнер, который умеет запускать модели нужного формата:

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: churn
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn                  # формат модели
      storageUri: s3://models/churn/v15  # где лежит файл модели

KServe скачает модель, поднимет Pod и даст адрес для запросов.

Triton и vLLM

Для моделей на GPU есть отдельные серверы inference.

NVIDIA Triton Inference Server запускает модели из PyTorch, ONNX, TensorRT и других фреймворков. Он умеет dynamic batching: собирает несколько пришедших запросов в одну пачку, чтобы обработать их на GPU за один проход.

vLLM обслуживает большие языковые модели (LLM). Его основа PagedAttention, способ хранить промежуточные данные генерации в памяти GPU небольшими блоками, чтобы они не занимали лишнего. vLLM отдаёт API, совместимый с API OpenAI.

Pod получает GPU через resources.limits с ресурсом nvidia.com/gpu. Для этого на ноде должен работать NVIDIA device plugin.

Постепенная выкатка

Новая модель прошла проверку на test set, но в проде может вести себя иначе. Поэтому её выкатывают постепенно.

• Shadow. Запросы идут в обе модели, пользователю отвечает старая. Ответы новой только записываются и сравниваются, на пользователей она не влияет.
• Canary. Новая модель отвечает на часть запросов, например на 10%. Если метрики в порядке, долю повышают. В KServe это поле canaryTrafficPercent: 10 в predictor, оно работает в serverless-режиме KServe.
• A/B-тест. Две модели работают на разных группах пользователей. Сравнивают бизнес-метрику, например сколько клиентов со скидкой вернулись. Статья Google упоминает A/B-тест как проверку перед тем, как модель становится основной.

Что мониторить

Метрики сервиса те же, что у любого API: latency, число запросов в секунду, ошибки, память, загрузка GPU. Их собирает Prometheus, как в треке про наблюдаемость.

Модель ломается без ошибок в логах, поэтому к ним добавляют:

• распределение входных данных: сравнение с данными обучения ловит data drift;
• распределение ответов: например, модель вдруг стала ставить вероятность ухода 0.9 почти всем;
• качество модели: accuracy по реальным исходам.

У последней метрики есть задержка. Ушёл клиент или нет, видно только через несколько недель после прогноза. Распределения входов и ответов можно проверять каждый день, а accuracy получается позже.

Для поиска drift есть open source библиотека Evidently. Она сравнивает текущие данные с эталонным датасетом, например с данными обучения, и показывает, у каких feature распределение изменилось. Сильное изменение распределения входит в список триггеров переобучения из статьи Google.

Что важно запомнить

Batch считает ответы модели по расписанию, online отвечает на каждый запрос. Online serving делают сервисом в контейнере или через KServe. Triton и vLLM нужны для моделей на GPU.

Новую модель выкатывают через shadow, canary или A/B-тест.

Кроме метрик сервиса мониторят распределения входов и ответов и accuracy по реальным исходам. Drift ищут по распределениям, сильный drift запускает переобучение.