Model Serving
Сервис модели предоставляет доступ к обученной модели через сетевой API: приложения отправляют входные данные и получают предсказания. Разбираем пакетную обработку, масштабирование и проверки работоспособности.
Обслуживание моделей — это размещение обученной модели машинного обучения за сетевым эндпоинтом, обычно HTTP или gRPC, чтобы приложения могли отправлять входные данные и получать предсказания. Система обслуживания загружает веса один раз, хранит их в памяти на CPU или GPU, принимает множество параллельных запросов, объединяет их в пакеты, добавляет или удаляет реплики при изменении трафика, переключает версии модели и сообщает о своём состоянии. В феврале 2016 года Google открыла исходный код TensorFlow Serving для запуска моделей TensorFlow в производственной среде. Сейчас обслуживание моделей — это исполнительная часть эксплуатации машинного обучения (MLOps), которая находится между упаковкой модели и мониторингом её предсказаний.
Как система обслуживания обрабатывает запросы#
Каждый запрос проходит проверку, предварительную обработку — например, декодирование и изменение размера изображения, — очередь, саму модель и постобработку с преобразованием результата в формат ответа, например JSON. Большинство решений при обслуживании принимается в очереди. Динамическое пакетирование задерживает запросы на несколько миллисекунд, чтобы ускоритель обрабатывал несколько входных данных за один прямой проход. Это повышает пропускную способность с небольшим увеличением задержки инференса. Когда очередь заполнена, сервер отклоняет новые запросы с кодом HTTP 429, чтобы клиенты снизили частоту запросов.
Команды обслуживания отслеживают перцентили задержки, например p95 и p99, пропускную способность в запросах в секунду, утилизацию ускорителя, частоту ошибок и время холодного запуска — задержку до момента, когда масштабированная с нуля реплика сможет ответить. Новые версии выпускаются постепенно: при канареечном развёртывании небольшая доля трафика направляется новой модели, а при теневом развёртывании копии реальных запросов отправляются ей без возврата её ответов.
Это приложение FastAPI загружает YOLO26 один раз при запуске и возвращает обнаруженные объекты в формате JSON. TestClient FastAPI отправляет один запрос через полный HTTP-стек в том же процессе, поэтому пример можно запустить без запуска сервера:
from fastapi import FastAPI
from fastapi.testclient import TestClient
from ultralytics import YOLO
app = FastAPI()
model = YOLO("yolo26n.pt") # загружаем веса один раз при запуске сервера
@app.get("/predict")
async def predict(url: str):
"""Detect objects in the image at `url` and return them as JSON."""
results = model(url)
return results[0].summary()
client = TestClient(app)
response = client.get("/predict", params={"url": "https://ultralytics.com/images/bus.jpg"})
print(response.status_code, response.json()[0])В выводе показан статус 200 и первое обнаружение в виде словаря с названием класса, оценкой уверенности и координатами рамки — такую структуру summary() создаёт для каждого обнаруженного объекта. Поскольку обработчик — async def, FastAPI запускает его в одном цикле событий, поэтому общая модель никогда не обрабатывает два запроса одновременно. Серверы, которым нужна параллельная обработка, запускают несколько рабочих процессов, каждый со своей копией модели.
Шаблоны обслуживания и программное обеспечение#
Способ обслуживания модели зависит от того, когда нужны её ответы: от инференса в реальном времени для видеопотока с камеры до ночных заданий:
- Обслуживание в реальном времени: Каждый запрос получает ответ, пока отправитель ждёт, через REST или gRPC; так работают приложения для пользователей и видеопотоки с камер.
- Пакетное обслуживание: Запланированное задание автономно оценивает большой набор данных, например обрабатывает за ночь изображения за день, и оптимизирует пропускную способность в ущерб задержке.
- Потоковая обработка: Результаты непрерывно отправляются по мере поступления видеокадров или показаний датчиков.
- Периферийный ИИ: Модель выполняется непосредственно на устройстве, часто после экспорта в оптимизированный формат, без обращения к сети.
К универсальному программному обеспечению для обслуживания моделей относятся NVIDIA Dynamo-Triton, ранее называвшийся Triton Inference Server, а также TensorFlow Serving, Ray Serve, BentoML и KServe на Kubernetes. Поддержка TorchServe от PyTorch ограничена, дальнейшие обновления не планируются. Серверы LLM, такие как vLLM, SGLang и TensorRT-LLM, добавляют непрерывное пакетирование и постраничное управление KV-кэшем для генерации токен за токеном. Большинство этих систем запускается в контейнерах, объединяющих модель, среду выполнения и зависимости в один образ.
Обслуживание моделей, развёртывание и движки инференса#
Обслуживание моделей тесно связано с несколькими смежными понятиями. Развёртывание модели — более широкий процесс запуска модели в производственной среде, включающий упаковку, инфраструктуру и поэтапный выпуск; обслуживание — та часть, которая отвечает на запросы после запуска. Движок инференса, например TensorRT, ONNX Runtime или OpenVINO, выполняет вычисления модели, а система обслуживания объединяет один или несколько движков с сетевым взаимодействием, очередями и масштабированием.
Платформа Ultralytics обслуживает модели YOLO через выделенные эндпоинты: каждый представляет собой однопользовательский сервис в одном из 42 регионов с маршрутами /predict, /health и сгенерированными маршрутами /docs. Конфигурация по умолчанию масштабируется до нуля при отсутствии запросов, а запуск может занять около минуты. При замене модели URL эндпоинта сохраняется, а прежняя модель продолжает обслуживать запросы, пока новая не будет готова.










