ML доставляет

Скорость

uv написан на Rust и использует продвинутые алгоритмы разрешения зависимостей (на основе pubgrub — тот же, что в poetry, но сильно оптимизированный). Это даёт значительный прирост производительности в разрешении зависимостей, парсинге, проверке хэшей и т.д. В наших проектах разница особенно заметна на CI и при работе с большим количеством зависимостей.

Простая работа с окружениями

uv может заменить сразу несколько инструментов:

uv venv — быстрое создание виртуального окружения
uv pip install — ускоренная установка пакетов
uv sync — работа с pyproject.toml / requirements

Параллельная загрузка и установка

Скачивает и устанавливает пакеты параллельно (много потоков).
Использует эффективный HTTP-клиент с HTTP/2 и хорошим кэшированием.
При повторной установке часто вообще ничего не скачивает — просто берёт из кэша.
Кэш shared между проектами (экономия места и времени).

Отличная интеграция с Ruff и другими современными инструментами

Поскольку uv от тех же авторов, что и Ruff, они очень хорошо дружат между собой. Это позволяет держать весь Python-стек современным и быстрым.

Мы много этим вопросом задавались и задаемся до сих пор, особенно когда выбираем задачи, которые делать стоит, а какие нет. В нашей команде мы в первую очередь смотрим на обратную связь пользователей платформы: ML-инженеров и разработчиков.
Долгое время нашей основной целью было снижение Time to Market ML-проектов. Сейчас с помощью платформы мы также стараемся оптимизировать затраты на инфраструктуру. Кроме того, ML-платформа влияет на количество инцидентов и время их устранения, но этот элемент мы пока не оценивали в формате «до/после».

Основное, что перестало работать, является даже не техническим решением, а форматом работы. У нас была модель поддержки, в которой инженеры MLOps-команды при возникновении каких-то проблем у ML-инженеров приходили разбираться в их технических решениях, не всегда даже связанных со взаимодействием с платформой. В таком формате небольшая MLOps-команда перестала справляться, поэтому мы постепенно перестроили поддержку: начали делать инструкции, проводить встречи, делиться опытом и интересными кейсами из поддержки. Теперь на основе этих материалов более опытные ML-инженеры могут помогать своим коллегам.

Стоимость ML-инфраструктуры для нас очень важна. Даже если фича даёт бизнес-эффект, важно понимать, не обходится ли она дороже, чем приносит пользы. В таком случае разрабатывать и внедрять её просто не имеет смысла. Поэтому мы стараемся не только ускорять работу ML-команд, но и помогать им оптимально использовать инфраструктурные ресурсы.

Чтобы одна модель не могла забрать на себя весь кластер, мы разделяем ноды по критичности нагрузки, используем requests и limits в Kubernetes и контролируем, сколько ресурсов запрашивается под разные задачи. Для GPU-нагрузок используем MIG. Он помогает эффективнее делить GPU между задачами и снижает риск, что они будут мешать друг другу.

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