Новички часто не понимают, что именно считается деплоем ML-модели и насколько глубоко в этом нужно разбираться. Ниже я покажу, как деплой выглядит на практике, насколько он важен для начинающего ML-инженера и с какими технологиями имеет смысл познакомиться в первую очередь.

Деплой ML-модели — это момент, когда обученная модель становится частью продукта. Модель перестаёт жить в ноутбуке и начинает работать в бизнес-логике: её можно вызывать из других сервисов и систем.

В вакансиях ML-инженеров часто упоминают десятки технологий, связанных с деплоем: Docker, Kubernetes, CI/CD и другие. 
Новичку сложно понять, какие из них действительно важны, а какие встречаются «для галочки», потому что без опыта продакшена сам процесс деплоя остаётся абстрактным.

Какие требования к деплою бывают в компаниях?

Чтобы разобраться в вопросе, я глубоко изучил, как деплой устроен на практике. Я опросил ML-инженеров из более чем 10 разных компаний, проанализировал 600+ вакансий и выделил четыре варианта требований к навыкам деплоя:

1. Навыки деплоя не требуются.  
   Деплоем занимается отдельная команда или платформа, а ML-инженер передаёт модель дальше.

2. Навыки деплоя указаны как «будет плюсом».  
   В компании есть готовый процесс выкатки в прод, и от ML-инженера требуется лишь следовать инструкции: собрать Docker-образ, поправить конфигурацию или параметры запуска.

3. Деплой — часть обязанностей ML-инженера.
   В этом случае ML-инженер сам отвечает за развёртывание модели и её обновление.

4. Ожидается полноценный MLOps-функционал.
   Такое чаще встречается в стартапах, где один человек закрывает сразу несколько ролей.

По моему опыту, в большинстве компаний от ML-инженера не ждут глубоких навыков деплоя. Обычно деплоем занимается отдельная команда, а ML-инженеру нужно лишь изредка внести правки — например, в Docker-образ.

Анализ вакансий показывает похожую картину: навыки деплоя упоминаются примерно в 15–25% позиций. При этом лишь для 5–10% вакансий деплой действительно критичен — его отсутствие может стать причиной отказа ещё до технического этапа.

Деплой — не самый важный навык на старте карьеры ML-инженера. Гораздо важнее понимать, какие навыки действительно нужны для входа в профессию и в каком порядке их изучать. Этот вопрос я подробно разобрал в отдельной статье с Roadmap по NLP.

Если интересно, как именно я анализировал вакансии и откуда взялись цифры, ниже я оставил подробную методику.

ВАЖНО!
На собеседованиях по теме деплоя редко уходят в детали — чаще всего спрашивают, приходилось ли вообще участвовать в деплое и на каком уровне.

Дальше я коротко пройду по базовым инструментам деплоя, с которыми имеет смысл познакомиться на старте, и поясню, зачем они нужны ML-инженеру.

FastAPI

FastAPI — это лёгкий Python-фреймворк, который позволяет «подключить» ML-модель к другим частям системы.

Проще говоря, с помощью FastAPI модель можно превратить в сервис, который принимает запросы, обрабатывает их с помощью модели и возвращает результат. Например, другой сервис может отправить текст на классификацию и получить ответ модели в виде JSON.

Docker

Docker — это способ упаковать ML-модель, код и все зависимости в единый контейнер, чтобы сервис одинаково работал в любом окружении.

На практике это решает простую, но важную проблему: модель может без ошибок запускаться у вас на ноутбуке, на тестовом сервере и в продакшене. Не нужно заново настраивать окружение или гадать, почему «у меня работает, а в проде нет». Именно поэтому почти все ML-сервисы деплоят через Docker.

CI/CD

CI/CD — это автоматический процесс, который обновляет сервис без ручных действий. 

Проще говоря, вы вносите изменения в код и отправляете их в репозиторий, а дальше всё происходит автоматически: код проверяется, собирается Docker-образ и выкатывается новая версия сервиса.

Для ML-инженера CI/CD важен не как отдельная технология, а как часть общего процесса деплоя. Обычно не требуется настраивать пайплайны с нуля — достаточно понимать, как они работают, где смотреть логи и как происходит обновление модели в продакшене.

Kubernetes

Kubernetes — это система, которая управляет запуском и работой сервисов в продакшене.

Если упростить, представим, что мы обучили ML-модель и завернули инференс в FastAPI и Docker. Kubernetes запускает несколько копий этого сервиса, следит, чтобы они не падали, и автоматически масштабирует их, когда растёт нагрузка.

Когда мы обновляем модель или код инференса, Kubernetes постепенно заменяет старую версию сервиса на новую — без остановки системы. Для пользователя этот процесс обычно проходит незаметно.

Как обычно выглядит деплой ML-модели в работе

На практике деплой ML-модели редко выглядит как сложный инфраструктурный проект. По моему опыту и по опыту коллег из других компаний, зона ответственности ML-инженера обычно ограничивается подготовкой сервиса и участием в выкладке, а дальше процесс живёт сам.

Если упростить, типичный процесс деплоя ML-модели в компании выглядит примерно так:

1. ML-инженер обучает модель и проверяет её качество.

2. Модель оборачивается в сервис на FastAPI.

3. Сервис упаковывается в Docker-контейнер. В этом процессе обычно не используются продвинутые возможности Docker - только база.

4. Код отправляется в репозиторий, где автоматически запускается CI/CD и выкатывается новая версия сервиса. CI/CD за все время работы я правил буквально пару раз.

5. Дальнейшей поддержкой и стабильной работой сервиса обычно занимается платформа или MLOps-команда.

Отдельно важно понимать, где заканчивается зона ответственности ML-инженера.

ML Engineer vs MLOps

В крупных компаниях деплоем и ML-инфраструктурой обычно занимаются отдельные команды. MLOps — это скорее DevOps с ML-контекстом, а не «прокачанная» версия ML-инженера.

Хотя в вакансиях требования часто выглядят похоже — Docker, Kubernetes, CI/CD — на практике роли разные. ML-инженер отвечает за то, чтобы модель стала рабочим сервисом: API, Docker и участие в процессе выката. MLOps отвечает за платформу, на которой эти сервисы запускаются, масштабируются и стабильно работают.

Проще говоря, ML-инженер делает модель пригодной для продакшена, а MLOps — следит за тем, чтобы продакшен не ломался.

Продвинутые инструменты

Иногда в вакансиях ML-инженеров можно встретить ONNX, Triton или TensorRT. Эти инструменты относятся к более продвинутому уровню деплоя и инференса.

ONNX — это формат представления модели. Сам по себе он не является сложной технологией, но чаще используется как часть более сложного пайплайна инференса.

Triton и TensorRT применяются для сервинга и оптимизации тяжёлых нейросетевых моделей, как правило в высоконагруженных системах. В большинстве случаев работа с этими инструментами относится к зоне ответственности MLOps или platform-команд.

Знать о существовании ONNX, Triton и TensorRT полезно, но изучать их в глубину на старте карьеры ML-инженера не требуется.

Итог

Деплой ML-моделей — это не отдельная дисциплина, а часть процесса превращения модели в продукт. Для начинающего ML-инженера важно не становиться MLOps-специалистом, а понимать, как модель попадает в продакшен и что с ней происходит дальше.

На старте достаточно базового стека: FastAPI, Docker и общего понимания CI/CD и Kubernetes. Этого обычно хватает, чтобы ориентироваться в вакансиях и уверенно чувствовать себя на собеседованиях.

Я пишу такие тексты, потому что сам когда-то искал нормальные объяснения. Если такой формат откликается, в своем Telegram я публикую похожие разборы и мысли про ML-карьеру.