MLOps-платформа растёт вместе с командами, моделями и инфраструктурой. А ещё регулярно подкидывает вопросы: что автоматизировать, что оставить командам, где поставить ограничения и как понять, куда её развивать.
В мини-интервью Юрий Классен, руководитель команды MLOps, рассказывает, как в Купер.тех развивают MLOps-платформу и что влияет на решения:
1️⃣ Как понять, что ML-платформа действительно помогает, а не просто добавляет ещё один слой абстракции?
Мы много этим вопросом задавались и задаемся до сих пор, особенно когда выбираем задачи, которые делать стоит, а какие нет. В нашей команде мы в первую очередь смотрим на обратную связь пользователей платформы: ML-инженеров и разработчиков.
Долгое время нашей основной целью было снижение Time to Market ML-проектов. Сейчас с помощью платформы мы также стараемся оптимизировать затраты на инфраструктуру. Кроме того, ML-платформа влияет на количество инцидентов и время их устранения, но этот элемент мы пока не оценивали в формате «до/после».
2️⃣ Что перестало работать по мере роста числа моделей и команд? Какие подходы пришлось пересмотреть?
Основное, что перестало работать, является даже не техническим решением, а форматом работы. У нас была модель поддержки, в которой инженеры MLOps-команды при возникновении каких-то проблем у ML-инженеров приходили разбираться в их технических решениях, не всегда даже связанных со взаимодействием с платформой. В таком формате небольшая MLOps-команда перестала справляться, поэтому мы постепенно перестроили поддержку: начали делать инструкции, проводить встречи, делиться опытом и интересными кейсами из поддержки. Теперь на основе этих материалов более опытные ML-инженеры могут помогать своим коллегам.
3️⃣ Есть ли у вас механизмы, которые помогают не сжечь весь кластер
одной моделью?
Стоимость ML-инфраструктуры для нас очень важна. Даже если фича даёт бизнес-эффект, важно понимать, не обходится ли она дороже, чем приносит пользы. В таком случае разрабатывать и внедрять её просто не имеет смысла. Поэтому мы стараемся не только ускорять работу ML-команд, но и помогать им оптимально использовать инфраструктурные ресурсы.
Чтобы одна модель не могла забрать на себя весь кластер, мы разделяем ноды по критичности нагрузки, используем requests и limits в Kubernetes и контролируем, сколько ресурсов запрашивается под разные задачи. Для GPU-нагрузок используем MIG. Он помогает эффективнее делить GPU между задачами и снижает риск, что они будут мешать друг другу.
4️⃣ Есть ли сценарии, где задержка в несколько сотен миллисекунд уже становится критичной?
Обычно это сценарии, напрямую связанные со взаимодействием с пользователем. Пользователь заметит, если результаты поиска или рекомендации загружаются слишком долго, и, конечно, это влияет на удовлетворённость клиентов. Поэтому, когда мы делаем решения для таких систем, на latency смотрим очень внимательно. Например, у меня даже был доклад о том, как мы оптимизировали этот показатель в нашем Feature Store. С ним можно ознакомиться по ссылке.