TorchServe (устаревший)

TorchServe был официальным production-сервером PyTorch, который поддерживали AWS и Meta. Проект мёртв: с лета 2025 года репозиторий pytorch/serve архивирован (read-only), статус — Limited Maintenance: обновлений, багфиксов и патчей безопасности больше не будет. Мы сохраняем эту страницу, потому что TorchServe всё ещё встречается в проде и в тысячах туториалов 2022–2024 годов — но для новых проектов выбирать его нельзя. Ниже — что он делал и чем его заменяют.

Как это работало

TorchServe упаковывал модель через torch-model-archiver (веса, код хендлера и зависимости в .mar-архив) и обслуживал несколько моделей с динамическим батчингом, версионированием и метриками Prometheus. Хендлеры — Python-классы с методами initialize, preprocess, inference, postprocess — задавали пайплайн обработки запроса. Именно эта связка «архив + хендлер + REST/gRPC» и была причиной популярности: один инструмент закрывал упаковку, сервинг и мониторинг.

Чем заменять

Выбор замены зависит от нагрузки. Для LLM-инференса де-факто стандарт 2026 года — vLLM (continuous batching, PagedAttention) и SGLang. Для классических моделей (vision, табличные, эмбеддинги) — NVIDIA Triton Inference Server (мульти-фреймворк, GPU sharing, dynamic batching), KServe на Kubernetes (с 2025 года — CNCF incubating проект с фокусом на generative AI serving), BentoML или Ray Serve. Простейший путь остался прежним: FastAPI + одна модель на контейнер — этого хватает на удивительно большом объёме трафика. ONNX по-прежнему полезен как lingua franca между training-фреймворком и serving-runtime.

Если TorchServe уже стоит у вас в проде: он не перестанет работать завтра, но без патчей безопасности каждый месяц эксплуатации увеличивает риск — планируйте миграцию, начиная с самых нагруженных эндпоинтов, и бенчмаркьте p50/p95/p99 на реальном трафике до и после.

Типичные ошибки

Главная ошибка в 2026 году — начинать новый проект на TorchServe, потому что так советует старый туториал: вы получите сервер без обновлений и патчей безопасности. Вторая — «мигрировать» на форк или свой патчсет вместо перехода на живой сервер: поддержка инференс-сервера — не та работа, которую стоит брать на себя. Остальные ловушки сервинга никуда не делись: model.predict() в Python-цикле (GPU простаивает), отсутствие warm-up при старте контейнера (таймаут первого запроса), игнорирование p99 latency и REST там, где gRPC ополовинил бы overhead на высоком QPS.

Связанные понятия

• Серверное обслуживание модели
• REST API для обслуживания (FastAPI)
• Сервер инференса Triton
• Пакетная обработка против реального времени