А если хотите подготовиться не только к вопросам по тестированию, но и разобраться во всём цикле разработки DL-сервисов, то приходите на курс DLOps, который стартует 4 июня!

Есть два основных подхода:
а) FastAPI / Flask (и др.) обёртка. Файл модели загружается в HTTP / gRPC-сервис. Минимальные накладные расходы на старте, но проблемы с масштабированием / батчингом придётся решать самостоятельно.

б) Специализированные inference-серверы. Например,Triton Inference Server, TorchServe, vLLM. Поддерживают батчинг, управление памятью и обслуживание нескольких моделей одновременно. Оправданы при высоких требованиях к latency и throughput.

Если у вас большие требования к доступности — нужно несколько реплик на разных серверах (а лучше — ДЦ). Иначе сбой на одном сервере — и к вашей модели

«

не достучаться

»

. В случае с несколькими репликами важно, чтобы при падении одной из них трафик перераспределялся между остальными. Здесь тоже есть несколько вариантов, например:

а) Kubernetes. Автоматически поддерживает заданное число реплик, проверяет доступность / работоспособность и перераспределяет трафик.
б) Bare Metal. Прямой запуск на серверах. Максимальный контроль над ресурсами, логику перезапуска и балансировки нужно делать самостоятельно. Например, через systemd и nginx / HAProxy.

Есть несколько подходов:
а) Бизнес-логика и модель в одном сервисе. Минимальная сложность при запуске, но при росте нагрузки возникают проблемы. Бизнес-логика и инференс потребляют ресурсы совместно и разделить их невозможно: если модель перегружена, масштабируется весь сервис целиком, включая логику, которая в этом не нуждается. Обратная ситуация аналогична. Это приводит к избыточному расходу памяти и GPU, а также к сложностям при горизонтальном масштабировании.

б) Отдельно микросервис с моделью и отдельно сервис с бизнес-логикой. Например, Triton или vLLM обслуживают модель, а «основной» сервис обращается к ним по HTTP/gRPC. Компоненты обновляются и масштабируются независимо: можно добавить реплики только на сторону модели или логики.