Развертывание ML-моделей в собственной инфраструктуре: архитектура, эксплуатация и требования к среде

Машинное обучение постепенно становится частью корпоративных информационных систем. ML-модели используются для классификации документов, прогнозирования спроса, поиска аномалий, анализа изображений, обработки естественного языка, рекомендаций и автоматизации внутренних процессов. Однако обучение модели - только один этап жизненного цикла. Чтобы результат работы Data Science-команды превратился в прикладной сервис, модель необходимо развернуть в инфраструктуре и организовать её стабильную эксплуатацию.

Развертывание ML-моделей в собственной инфраструктуре означает, что вычислительные ресурсы, данные и основные программные компоненты располагаются в контролируемом организацией контуре - в локальном центре обработки данных, частном облаке или другой внутренней среде. Такой подход отличается от использования полностью внешнего облачного API, где запросы передаются сервису стороннего поставщика.

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

Что означает развертывание ML-модели

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

Сам по себе такой набор ещё не является рабочим корпоративным сервисом.

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

Процесс получения ответа от уже обученной модели называется инференсом. Именно для выполнения инференса в промышленной среде обычно создаётся отдельный сервис.

В простом варианте модель запускается внутри обычного приложения. Более масштабируемая архитектура предполагает выделение отдельного inference-сервера, к которому другие системы обращаются через API.

Такое разделение позволяет независимо обновлять модель, увеличивать количество её экземпляров и контролировать используемые вычислительные ресурсы.

Чем эксплуатация отличается от обучения

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

Во время обучения выполняется большое количество вычислений над значительными объёмами данных. Особенно ресурсоёмким может быть обучение нейронных сетей. Для него применяются мощные графические ускорители, большие объёмы оперативной или видеопамяти и высокопроизводительные системы хранения.

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

Однако нагрузка зависит от типа модели.

Небольшая модель машинного обучения может выполнять тысячи прогнозов на обычном центральном процессоре. Крупная языковая модель способна потребовать нескольких GPU даже только для инференса.

Кроме того, для промышленного использования важна не только максимальная производительность. Необходимо учитывать время ответа, количество одновременных запросов и требования к доступности.

Поэтому инфраструктуру обучения и инфраструктуру эксплуатации часто разделяют. Модель может обучаться на одном вычислительном кластере, а после проверки передаваться в отдельный промышленный контур.

Основные компоненты ML-инфраструктуры

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

Первый - вычислительные узлы. Это физические или виртуальные серверы с CPU и, при необходимости, GPU.

Второй - программная среда выполнения. Она включает операционную систему, драйверы ускорителей, библиотеки машинного обучения и другие зависимости.

Третий уровень - непосредственно inference-сервис. Он загружает модель в память, принимает запросы и возвращает результаты.

Следующий компонент - хранилище моделей. В нём находятся различные версии моделей, их параметры и связанные артефакты.

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

В промышленной среде также требуются мониторинг, журналирование, аутентификация и сетевые механизмы.

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

CPU или GPU для инференса

Одним из первых вопросов при проектировании является выбор вычислительных ресурсов.

Использование GPU требуется далеко не каждой ML-модели.

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

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

При этом GPU является ограниченным и сравнительно дорогостоящим ресурсом. Если модель загружает ускоритель только на несколько процентов, выделять ей отдельное устройство может быть неэффективно.

Поэтому при проектировании желательно проводить нагрузочное тестирование.

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

После этого можно определить, требуется ли GPU и сколько моделей или экземпляров сервиса допустимо размещать на одном узле.

Значение видеопамяти

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

Перед выполнением инференса веса нейронной сети обычно загружаются в память GPU. Дополнительно пространство требуется для промежуточных вычислений и обрабатываемых запросов.

Крупные модели могут занимать десятки гигабайт.

Если модель не помещается в память одного ускорителя, возможны различные варианты: уменьшение точности представления весов, квантование, распределение между несколькими GPU или частичное использование оперативной памяти.

Каждый из таких методов имеет свои компромиссы.

Квантование уменьшает объём памяти и может повысить скорость инференса, но способно несколько изменить качество результатов. Распределение модели между устройствами увеличивает требования к обмену данными между ускорителями.

Поэтому размер модели является одним из ключевых параметров при планировании оборудования.

Контейнеризация ML-моделей

Одна из распространённых проблем ML-проектов - зависимость модели от конкретной программной среды.

Модель может работать только с определённой версией Python, ML-фреймворка или библиотеки обработки данных.

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

Контейнеризация уменьшает эту проблему.

Модель вместе с необходимым runtime, библиотеками и кодом упаковывается в контейнерный образ. Такой образ можно запускать на разных серверах с совместимой контейнерной платформой.

Контейнер также позволяет фиксировать программную среду конкретной версии модели.

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

При этом контейнер не решает все вопросы совместимости. При использовании GPU остаётся зависимость от драйверов и программных компонентов хоста, поэтому версии среды необходимо согласовывать.

Использование Kubernetes

Когда количество моделей и серверов увеличивается, ручное управление контейнерами становится сложным.

Для таких сред часто применяется Kubernetes.

Оркестратор позволяет описать требуемое состояние системы: например, должны постоянно работать три экземпляра inference-сервиса определённой версии.

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

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

Но внедрять контейнерный оркестратор только ради одной небольшой модели не всегда рационально. Kubernetes сам является достаточно сложной инфраструктурной системой и требует сопровождения.

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

Для нескольких простых моделей иногда достаточно виртуальных машин или обычных контейнеров.

API как интерфейс к модели

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

Удобнее предоставить единый API.

Например, клиент отправляет JSON-запрос с необходимыми данными, а сервер возвращает прогноз.

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

API создаёт стабильную границу между прикладной системой и внутренним устройством модели.

Разработчику основного приложения не требуется знать, используется ли PyTorch, TensorFlow, ONNX Runtime или другой движок инференса. Для него важен контракт API.

Это также упрощает обновление модели.

Если структура запроса и ответа остаётся прежней, новая версия может быть установлена без изменения клиентских приложений.

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

Синхронный и асинхронный инференс

Не все запросы к модели должны обрабатываться одинаковым способом.

Синхронный инференс используется, когда клиент ожидает ответ непосредственно во время запроса. Такой режим характерен для онлайн-сервисов: пользователь отправляет данные и почти сразу получает результат.

В этом случае основным показателем становится задержка.

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

Тогда клиент передаёт задание в очередь, а обработчик выполняет его позже.

Такой подход позволяет лучше управлять пиковыми нагрузками.

Для массовых операций применяется также пакетный инференс. Модель получает сразу набор объектов, что в некоторых вычислительных средах повышает эффективность использования GPU.

Выбор режима зависит от требований бизнеса к времени ответа.

Балансировка нагрузки

Если inference-сервис используется многими приложениями, единственного его экземпляра может быть недостаточно.

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

Балансировка решает не только задачу производительности, но и частично повышает доступность.

Если один сервер модели перестаёт отвечать, его можно исключить из пула.

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

Поэтому масштабирование только после появления очереди запросов может оказаться слишком медленным.

Для критичных сервисов часть вычислительной мощности иногда резервируется заранее.

Хранилище и реестр моделей

В процессе разработки обычно появляется множество моделей.

Они отличаются архитектурой, параметрами обучения, данными и метриками качества.

Если хранить их как произвольно названные файлы в каталогах, быстро становится сложно определить, какая версия работает в промышленной системе.

Поэтому применяется model registry - реестр моделей.

В реестре фиксируются версия, дата создания, автор, показатели тестирования и состояние модели. Например, одна версия может считаться экспериментальной, другая - подтверждённой для промышленного использования.

Артефакты модели хранятся в соответствующем репозитории или объектном хранилище.

При развертывании инфраструктура получает именно указанную версию.

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

CI/CD для машинного обучения

Развертывание модели вручную допустимо на этапе эксперимента, но плохо масштабируется.

Поэтому процессы ML постепенно включаются в CI/CD.

После появления новой версии могут автоматически выполняться тесты кода, проверка формата артефактов и создание контейнерного образа.

Затем модель разворачивается сначала в тестовой среде.

Только после прохождения функциональных и нагрузочных проверок она может попасть в production.

При этом ML добавляет к обычному CI/CD дополнительный элемент - проверку качества самой модели.

Программный сервис способен технически работать без ошибок, но выдавать прогнозы хуже предыдущей версии.

Следовательно, решение о выпуске должно учитывать и программные тесты, и ML-метрики.

Такой подход часто относят к MLOps - совокупности практик, связывающих разработку моделей с их промышленной эксплуатацией.

Версионирование данных

Результат ML-модели зависит не только от программного кода.

Большую роль имеют данные, на которых она обучалась.

Две модели с одинаковой архитектурой и настройками могут демонстрировать разные результаты, если набор обучения изменился.

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

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

Это важно при расследовании ошибок и повторном обучении.

Особенно актуально версионирование для организаций, где модели могут влиять на значимые бизнес-решения.

Мониторинг ML-сервисов

После развертывания модель становится промышленным сервисом и нуждается в обычном техническом мониторинге.

Необходимо отслеживать использование CPU и GPU, память, количество запросов, время ответа и частоту ошибок.

Для GPU дополнительно полезно контролировать объём занятой видеопамяти и загрузку ускорителя.

Однако для ML технического мониторинга недостаточно.

Сервис может работать без единой ошибки, но качество прогнозов постепенно ухудшается.

Такое явление может быть связано с изменением входных данных. Например, структура поведения клиентов изменилась, появились новые категории документов или изменились характеристики оборудования.

Поэтому MLOps включает мониторинг статистики входов и результатов модели.

Data drift и concept drift

Одна из особенностей эксплуатации ML заключается в том, что окружающая среда меняется.

Data drift означает изменение распределения входных данных.

Предположим, модель обучалась на информации о покупках, где определённая категория товаров составляла 10% операций. Через год её доля выросла до 40%. Формат данных остаётся корректным, но статистическая среда стала другой.

Concept drift связан с изменением самой зависимости между признаками и результатом.

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

Система мониторинга может обнаруживать статистические изменения, но решение о необходимости переобучения обычно требует анализа со стороны специалистов.

Поэтому эксплуатация ML - это непрерывный процесс, а не одноразовое развертывание.

Безопасность локального ML-контура

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

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

Однако локальный контур также необходимо защищать.

Доступ к API модели следует аутентифицировать и ограничивать в соответствии с ролями.

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

Необходимо контролировать доступ к весам моделей и конфигурациям.

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

Поэтому следует заранее определить, какие сведения действительно нужны для диагностики.

Большие языковые модели в собственной инфраструктуре

Развертывание LLM стало отдельным направлением корпоративной ML-инфраструктуры.

В отличие от большинства классических моделей, крупные языковые модели предъявляют особенно высокие требования к памяти и вычислительным ресурсам.

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

Квантованные варианты позволяют уменьшить требования к видеопамяти, но требуют проверки качества на реальных корпоративных задачах.

Значительное влияние оказывает количество одновременных пользователей.

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

При работе с внутренними документами LLM часто применяется не изолированно, а вместе с RAG - механизмом поиска информации в корпоративных источниках и передачи найденного контекста модели.

В этом случае инфраструктура дополнительно включает систему подготовки документов, индекс и поисковый компонент.

Требования к системе хранения

Модели могут занимать от нескольких мегабайт до сотен гигабайт, поэтому способ хранения также влияет на архитектуру.

Для небольших моделей обычного файлового хранилища достаточно.

В крупных системах применяется централизованное объектное хранилище или репозиторий артефактов.

Важно учитывать скорость загрузки.

После перезапуска inference-сервера крупную модель необходимо считать с диска и разместить в памяти. Медленное хранилище увеличит время восстановления сервиса.

Если одновременно запускаются десятки экземпляров, нагрузка на систему хранения может резко возрастать.

Поэтому время старта модели необходимо измерять отдельно и учитывать при построении схем высокой доступности.

Отказоустойчивость

Для критичного ML-сервиса следует заранее определить, что произойдёт при отказе оборудования.

Если единственный GPU-сервер перестаёт работать, доступ к модели прекращается.

Для повышения доступности используются несколько узлов и балансировка запросов.

Однако резервирование GPU обходится дорого, поэтому архитектура зависит от требований сервиса.

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

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

Следует также резервировать не только вычисления. Недоступность хранилища моделей или сервиса авторизации может остановить систему даже при исправных inference-узлах.

Высокая доступность должна охватывать всю цепочку компонентов.

Планирование ресурсов

Расчёт мощности лучше проводить на основе реальной модели, а не общих характеристик оборудования.

Сначала измеряется потребление памяти при загрузке модели.

Затем определяется среднее и максимальное время инференса.

После этого проводится тест с несколькими параллельными запросами.

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

Также следует учитывать прогноз роста нагрузки.

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

Обновление модели без остановки сервиса

Новая версия модели не должна обязательно приводить к полной остановке приложения.

Для этого применяются стратегии постепенного развертывания.

При rolling update экземпляры старой версии поочерёдно заменяются новыми.

Blue-green deployment предполагает наличие двух сред: текущей и новой. После проверки трафик переключается на новую.

При canary-подходе небольшая часть запросов сначала отправляется новой модели. Если показатели остаются допустимыми, её доля постепенно увеличивается.

Для ML особенно полезно сравнение результатов двух версий на одинаковых входных данных.

Иногда новая модель сначала работает в shadow-режиме: получает копии реальных запросов, но её ответы не используются пользователями. Это позволяет оценить поведение на производственных данных без риска изменить основной сервис.

Как начинать проект развертывания

Первым этапом должен быть не выбор GPU или Kubernetes, а описание требований.

Необходимо определить, кто будет использовать модель, сколько запросов ожидается, какое время ответа допустимо и насколько критична её доступность.

Затем оцениваются размер модели и требования к памяти.

После этого создаётся минимальный тестовый inference-сервис и выполняется нагрузочное тестирование.

Только на основании измерений выбираются CPU или GPU, количество экземпляров и способ масштабирования.

Следующий этап - контейнеризация и автоматизация доставки версии.

Параллельно следует настроить журналирование, метрики и контроль доступа.

После этого модель можно запустить для ограниченной группы пользователей, собрать статистику и только затем переводить в полноценную промышленную эксплуатацию.

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

Ограничения локального развертывания

Собственная инфраструктура даёт организации высокий уровень контроля, но требует ресурсов на эксплуатацию.

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

Для GPU-инфраструктуры добавляются драйверы, специализированные библиотеки и вопросы совместимости.

При быстром росте нагрузки масштабирование локального ЦОД может занимать больше времени, чем получение дополнительных ресурсов в публичном облаке.

Кроме того, оборудование может использоваться неравномерно. Мощный GPU-сервер, приобретённый для одной модели, способен значительную часть времени простаивать.

Поэтому перед выбором локального варианта следует оценивать не только требования информационной безопасности, но и экономику владения.

В некоторых организациях рациональной становится гибридная модель: чувствительные и постоянно используемые модели размещаются внутри корпоративного контура, а отдельные экспериментальные задачи выполняются на внешних вычислительных ресурсах, если это допускается политиками работы с данными.

Заключение

Развертывание ml-моделей в вашей инфраструктуре представляет собой полноценную инженерную задачу, находящуюся на пересечении машинного обучения, разработки программного обеспечения и эксплуатации ИТ-систем. Промышленный сервис включает значительно больше компонентов, чем файл с обученными весами: необходимы вычислительные ресурсы, runtime, API, хранилище моделей, система доставки версий, мониторинг и механизмы защиты.

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

Контейнеризация помогает фиксировать программную среду, а оркестраторы позволяют масштабировать и восстанавливать сервисы. Реестр моделей и CI/CD обеспечивают управляемое версионирование, а MLOps-процессы связывают разработку модели с промышленной эксплуатацией.

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

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

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