Как прошел MLечный путь 2025? Один митап — четыре доклада и пять стартапов
Делимся конспектом по мотивам прошедшего мероприятия.
23 апреля мы провели в Петербурге митап для ML-специалистов. Спикеры обсудили запуск LLM в продакшен, оптимизацию GPU-инференса, а также Edge-решения для медицины и агросектора. Минимум теории — больше кейсов от Selectel, Cloud.ru, Celsus и Русагро.
Как подобрать инфраструктуру под LLM? Как контейнеризировать GPU в многоарендных средах? Как запускать ML на комбайне или медицинском поезде без интернета? На эти вопросы ответили в четырех докладах на MLечном пути.
А еще мы организовали питч-сессию для стартапов. Пять проектов на стадии pre-MVP боролись за призовой фонд в 100 000 бонусов. Победителей выбирали сами зрители. В тексте рассказываем, как все было.
Приручая LLM: как подобрать седло под своего дракона
Антон Алексеев, DevOps-инженер в Selectel.
Большие языковые модели (LLM) все чаще становятся ядром цифровых решений в компаниях. Но их запуск в продакшен требует не только понимание моделей, но и грамотной инженерии инфраструктуры. Неверный выбор ресурсов приводит не просто к падению производительности, а к прямым финансовым потерям.
В своем докладе Антон поделился опытом, как они с командой подходят к подбору железа для LLM: от проектирования до оптимизации и автоматизации.
5 принципов подбора железа
Проектирование под бизнес-задачу, а не под модель
Первая ошибка многих — выбирать модель по числу параметров или известности. Вместо этого лучше учитывать нефункциональные требования:
- количество запросов в секунду (RPS),
- допустимая задержка (latency),
- число одновременных пользователей.
Эти метрики позволяют заранее просчитать нагрузку и не переплачивать за избыточные ресурсы.
Выбор GPU с учетом стоимости ошибки
В CPU-инфраструктуре добавление ресурсов — часто вопрос пары кликов. С GPU все иначе: ошибка в расчете видеопамяти означает переход на новое поколение карт, что ведет к кратному росту затрат. Поэтому точный расчет необходим уже на этапе архитектуры.
Подбор инференс-фреймворков
Мы протестировали несколько вариантов — VLLM, SGLang, Ollama. VLLM показал самый заметный прогресс: производительность выросла втрое за семь месяцев. Это отражает зрелость open-source решений для реальных нагрузок.
Нагрузочные тесты
Без тестов — любые расчеты теоретические. Чтобы подобрать оптимальную конфигурацию инференс-фреймворка, мы используем GenAI Perf Analyzer. С его помощью нам удалось снизить задержку с 15 секунд до менее одной при 60 RPS в одном из наших проектов.
Квантизация
Чтобы запускать модели с миллиардами параметров на доступных GPU, используют степень квантизации Q4 (AWQ, GPTQ). Качество остается приемлемым для большинства задач, а расходы — контролируемыми.
Нам нужно «приручить больших драконов» — LLM. И для этого важно правильно выбрать седла — видеокарты. Неправильный выбор GPU — это не просто ошибка, это дорогостоящая ошибка.
Выбор бэкенда для Triton: TensorRT vs VLLM
Когда приходит время запускать LLM-дракона в инференс через Triton, важно подобрать правильное седло — бэкенд. В докладе мы сравнили TensorRT-LLM и vLLM на модели LLaMA3.1 8B при нагрузке 10, 50 и 100 одновременных пользователей. За отправную точку взяли статью BentoML Cloud и дополнили ее своими замерами спустя семь месяцев.
Что показали тесты
| Метрика | BentoML (июнь 2024) | Наши тесты (через семь месяцев) |
| Throughput | TensorRT выше | vLLM выше при 10 и 50 пользователей |
| Time-to-First Token (TTFT) | vLLM быстрее | vLLM быстрее |
| Latency при 100 пользователей | Сравнимо | TensorRT стабильнее |
| Удобство запуска и настройки | vLLM проще | vLLM проще |
| Гибкость под OpenAI API и агенты | Ограничена | Высокая (из коробки) |
Выводы
Подходы к запуску принципиально разные. TensorRT-LLM требует предварительной сборки движка, ручной настройки и глубокого понимания документации Triton и TensorRT. vLLM запускается быстрее: достаточно описать параметры инференса в конфиге и стартовать сервер.
Если важна скорость внедрения и стабильность под реальной нагрузкой, vLLM сейчас — оптимальный выбор. TensorRT остается актуальным, когда в приоритете кастомная оптимизация под конкретное топовое «железо» и максимальная выжимка производительности.
Ключевые тезисы
- Нефункциональные требования определяют инфраструктуру — проектирование начинается с RPS, latency и числа пользователей, а не с выбора модели.
- Точная оценка видеопамяти критична — ошибка в расчетах по GPU приводит к многократному росту затрат.
- Open-source фреймворки стали зрелым выбором для продакшена — по производительности и удобству интеграции они часто превосходят проприетарные решения.
Ознакомиться с полным докладом можно в записи.
Эффективная утилизация GPU для инференса в облаке: когда MIG и MPS не помогают
Артемий Мазаев, лидер продукта в Cloud.ru.
Большинство ML-команд знают MIG, CUDA Streams, MPS, Time Slicing и vGPU как стандартные инструменты повышения утилизации GPU. Но с ростом масштабов и сложности сценариев инференс-нагрузок, а также требований к изоляции пользователей стало ясно, что стандартные подходы не позволяют эффективно использовать GPU в рамках единой вычислительной инфраструктуры.
Чтобы решить эти проблемы, коллеги из Cloud.ru разработали собственную технологию управления GPU-ресурсами — vGPU. Подробнее о решении Артемий рассказал в своем докладе.
Как распределять GPU для инференса: эволюция подходов
Команда классифицировала сценарии использования GPU клиентами на три уровня зрелости.
- MVP — быстрый запуск модели без требований к тонкой настройке.
- Собственная разработка — частичная оптимизация.
- Продвинутые пользователи — собственные пайплайны и кастомные оптимизации.
Анализ показал, что даже продвинутые пользователи используют менее 50% ресурсов GPU.
Для повышения эффективности утилизации обычно применяются два подхода — SMS (Single Model Serving) и MMS (Multi Model Serving).
- SMS — одна модель равняется одной GPU. Предлагает простое масштабирование, но низкую эффективность.
- MMS — динамическая загрузка нескольких моделей на GPU. Выше эффективность памяти, но сложнее масштабирование и больше накладных расходов.
Почему стандартные решения не подходят
Многие индустриальные технологии виртуализации GPU показали ограниченность в реальных задачах. При этом у CUDA, Time Slicing и MPS есть проблема с контролем памяти.
| Технология | Проблемы |
| CUDA Streams | Нет защиты памяти между задачами. |
| Time Slicing | Трудно управлять в продакшене. |
| MPS | Ограничения по изоляции и числу партиций. |
| MIG | Максимум 7 разделов на карту, сложно для массового шардинга. |
Хоть NVIDIA vGPU и решает многие проблемы, использовать его в России не получится из-за лицензионных ограничений.
vGPU: собственная альтернатива виртуализации GPU
Команда Cloud.ru создала vGPU — прослойку между CUDA Library и приложениями. Решение перехватывает обращения к GPU и управляет выделением памяти и ядер на уровне контейнеров.
Техническое решение
- Использование LD_PRELOAD для подмены вызовов библиотек CUDA.
- Контроль памяти и ядер на уровне Docker-контейнеров.
- Полная изоляция между задачами.
Результаты
- На одной карте H100 запускалось до восьми реплик модели без потерь производительности.
- Утилизация ресурсов выросла почти вдвое.
- Стоимость инференса для клиентов снизилась до уровня западных облаков.
Тесты и выводы
На примере модели BGE-m3 (embedding) команда показала следующие результаты.
- Без vGPU из 80 ГБ видеопамяти использовалось лишь 10 ГБ, остальное простаивало.
- С vGPU удалось эффективно задействовать до восьми реплик на одной карте.
- Масштабирование стало линейным — увеличение числа реплик пропорционально увеличивало пропускную способность.
Проблема масштабирования GPU в инференсе — это не только память или CUDA-ядер, а управление CPU-ресурсами при сильной нарезке. При ультратонком шардинге узким местом становится процессор.
Основные выводы
- MIG, MPS и Time Slicing подходят для малых задач или single-tenant решений. В облачных продакшен-средах с высокой плотностью клиентов они быстро достигают ограничений.
- Горизонтальное масштабирование через контейнеризацию с WGPU предоставляет лучшую гибкость и изоляцию.
- Контроль CPU становится критическим при многократной виртуализации одной видеокарты.
Ознакомиться с полным докладом можно в записи.
Адский инференс: ML в тайге, на поездах и без интернета
Евгений Никитин, технический директор и кофаундер CELSUS.
Большинство историй о продакшене LLM- и ML-моделей начинаются с облаков. Масштабируемость, автоскейлинг, CI/CD — все преимущества современной инфраструктуры доступны «по клику».
Но реальный мир далеко не всегда таков. В медицинских сценариях, особенно в российских регионах, часто приходится проектировать решения на пределе возможностей: фиксированное железо, нестабильные сети или полное отсутствие интернета.
В докладе Евгений рассказал о построении инференс-инфраструктуры на трех уровнях сложности — от привычных облаков до передвижных медицинских комплексов там, где нет ничего цифрового.
Уровень 1: облако — максимальная гибкость
В облаке хочется жить всем. Это почти как Sims: все работает по клику, масштабируется и обновляется автоматически.
Часть клиентов компании использует облачные решения с автоскейлингом и CI/CD. Здесь доступны гибридный мультиклауд, автоматическое масштабирование CPU и GPU, обновления моделей без даунтайма.
Технические особенности
- Оркестрация: Azure DevOps, мультиклауд, автоскейлинг.
- Мониторинг: Grafana, Streamlit-интерфейс, алерты в Mattermost.
- Железо: T4, 4090, A100, H100.
- Observability: полные логи, drift detection по DICOM-тегам.
- Обновления: через CI/CD пайплайны, latency развертывания новых моделей минимален.
Уровень 2: on-premises — фиксированное железо и бюрократия
В облаке кликаешь — и новая модель выкатилась. В on-prem пишешь ТЗ, а потом месяц ждешь, пока админ вставит видеокарту.
Сценарии — региональные, в том числе коммерческие клиники. Здесь гибкость резко снижается. Серверы фиксируются при закупке, изменение конфигурации — долгий бюрократический процесс.
Технические особенности
- Масштабирование: отсутствует, фиксированные сервера.
- Железо: часто устаревшие GPU (вплоть до 2015–2016 годов).
- Совместимость: российские ОС (Astra, RedOS), нестабильные драйверы.
- Мониторинг: PostgreSQL foreign tables → Grafana.
- Обновления: вручную или через заранее собранные образы.
Первый кейс
Для одной клиники с несколькими системами — ММГ, рентген, КТ — заказали один большой сервер. В итоге разные модули начали конфликтовать по памяти. Команда внедрила отдельные ограничения для моделей внутри общего железа, чтобы исключить взаимные сбои.
Технические решения
- Оптимизация: квантизация, TensorRT, Torch Compile.
- Health-check: контроль NaN, нулевых тензоров, деградации.
- Фильтрация данных: ML-модель для отсечения «мусорных» входных данных.
Второй кейс
В одном из регионов использовали сервер с GPU объемом 6 ГБ вместо 8 ГБ, заявленных по ТЗ. Модель была оптимизирована и дополнена fallback-логикой: если нейросеть не помещается в память, используется урезанная версия.
Уровень 3: офлайн-инференс — поезда, грузовики и ноутбуки
В облаках важно latency. В тайге важно, чтобы провод не выпал из розетки и модель вообще запускалась.
Сценарий — инференс на мобильных медицинских установках без стабильного интернета.
Технические особенности
- Оборудование: ноутбуки, старые GPU, экспериментальные российские процессоры.
- Масштабирование: невозможно.
- Обновления: редкие или отсутствуют (только при физическом доступе).
- Мониторинг: минимальный, часто ручной или по логам.
Эксперимент
На одной из машин стояла реальная российская GPU. Команда адаптировала классификатор под нестандартный API и ограничения памяти.
Технические решения
- Self-healing и fallback.
- Watchdog-сервисы: контроль корректности запуска и предсказаний.
- «Красная кнопка»: автоматический redeploy при ошибках.
- Логирование: автоматическая выгрузка для offline-анализа.
Кейс
Передвижной маммограф: инференс запущен на ноутбуке в вагоне с маммографом. Основная проблема — износ кабелей и нестабильное питание из-за движения маммографа. Решение — физическая фиксация соединений промышленным скотчем.
Ключевые тезисы
- Автоматизация и fallback обязательны даже в офлайне: health-check, self-healing и гибридные схемы инференса повышают надежность системы.
- Гибридный инференс (локальный бэкенд и облачные модели) — оптимальный компромисс между приватностью и гибкостью.
- Главное ограничение — не технологии, а инфраструктура и бюрократия. Инженерам приходится балансировать между техническими решениями и реальностью локальных условий.
Ознакомиться с полным докладом можно в записи.
Edge AI для агросектора: видеоаналитика на комбайнах
Адель Самигулин, Senior-разработчик в Русагро.
Как развернуть видеоаналитику в поле, где максимум — 2G, а железо должно стоить дешевле смартфона? Команда Русагро знает ответ: коллеги спроектировали и внедрили систему компьютерного зрения для мониторинга сбора и отгрузки урожая прямо на зерноуборочных комбайнах. В докладе — инженерная история о компромиссах, поиске решений и адаптации ML под реальные ограничения.
Зачем компьютерное зрение агросектору
Датчики давления лгут, бортовые системы недоступны, арендные комбайны нельзя вскрывать. Камеры — единственное универсальное решение.
Задача бизнеса — автоматический мониторинг процессов сбора и выгрузки урожая. С его помощью можно оптимизировать логистику и минимизировать простои техники.
Ключевое требование: обработка данных должна происходить локально, на борту комбайна. Причина проста — в полях интернет нестабилен (в лучшем случае 2G), а события, например сбой выгрузки, требуют немедленного реагирования.
Проблема с альтернативами
- Датчики давления показали высокий уровень ложных срабатываний.
- Доступ к бортовым системам комбайнов невозможен — техника часто арендуется, в электронику вмешиваться запрещено.
Вывод: необходимо создать Edge AI-решение на основе компьютерного зрения, которое работает в реальном времени.
Сбор и фильтрация данных: борьба с «лишними» кадрами
Первичный датасет: 1 500 часов видео с камер комбайнов.
Проблема: 90% кадров неинформативные: статичные или без события.
Решения
- Исключение кадров, где комбайн стоит. Использован алгоритм Template Matching — если два последовательных кадра совпадают, техника не движется.
- Поиск видео с выгрузкой зерна. Для этого применили DINO V2 (self-supervised encoder) и Metric Learning: выявляли кадры с выдвинутым шнеком как индикатором отгрузки.
Результаты
- Объем данных на разметку сокращен в девять раз.
- Существенная экономия ресурсов на аннотацию и обучение.
Железо: как выбрать Edge-платформу, которая не разорит
Сначала коллеги остановились на NVIDIA® Jetson Xavier™. У него отличная производительность, но высокая цена и сложная логистика. В качестве альтернативы выбрали Intel NPU: он немного дешевле, но все равно слишком дорого. Идеальным вариантом стал Orange Pi 5B с NPU Rockchip — его и взяли в работу.
Почему Rockchip
- Простая закупка, нет экспортных ограничений.
- Активная поддержка SDK и документации.
- Низкая стоимость по сравнению с решениями NVIDIA и Intel.
Orange Pi стал рабочей лошадкой проекта. Выиграл по цене, доступности и скорости внедрения.
Модель и адаптация под Edge
Изначально команда использовала 3D CNN для классификации видеофрагментов (учет временного контекста). Однако у них не было конвертации в формат RKNN. Появились ограничения поддержки 3D слоев на Rockchip.
Чтобы решить эту проблему, они перешли на ResNet для покадровой классификации. Временной контекст был реализован постобработкой — усреднение предсказаний по нескольким кадрам. Это помогло организовать простотой перенос модели на Edge. А также обеспечить высокую устойчивость к ракурсам и условиям съемки.
Когда железо ограничено, простая архитектура дает больше, чем сложные эксперименты.
Деплой, обновления и борьба с дата-дрифтом
Развертывание
Инференс работал локально на Orange Pi. Результаты предсказаний записывались в onboard-базу данных, а при появлении связи данные автоматически выгружались в облако.
Система обрабатывала видео с двух камер— жатка и шнек. Из-за ограничений железа реализовали поочередный инференс по кадрам. Предсказания записывались в локальную БД и выгружались в центральную систему при появлении сети.
Обновления модели
Команда определила механизм отправки deb-файлов и организовала автоматическое обновление моделей на всех устройствах при следующем подключении к сети. Это позволило дообучать модели без физического доступа к комбайнам.
Дата-дрифт
Проблемы с точностью возникли из-за ракурса камер на разных комбайнах.
Для решения использовали данные с параллельно тестируемых датчиков, чтобы автоматически размечать новые данные. Это расширило датасет с 18 до 57 тысяч изображений и позволило переобучить модель.
Однако авторазметку удалось применить только для задачи отгрузки зерна. Для сбора подходящих дополнительных данных не было.
Автоматическая разметка по сигналам с датчиков — спасение. Без этого собрать нужный датасет было бы нереально.
Результаты и полевые испытания
Точность. При обучении и валидации показатели Precision и Recall были близки к единице. В реальных условиях выявлено небольшое количество ложных срабатываний. В основном — в нестандартных сценариях, например при параллельной выгрузке зерна другим комбайном.
Внешняя среда. Система успешно функционировала при разном освещении, включая ночные смены, и неблагоприятных погодных условиях. В сложных случаях модель корректно оценивала уровень неуверенности, избегая критических ошибок.
Мониторинг. Валидация результатов проводилась с использованием альтернативных источников данных — бортовых датчиков. Для сложных кейсов применялась explainability (Grad-CAM): визуализация внимания модели помогала выявлять и корректировать проблемные сценарии.
Confidence в сложных кейсах не зашкаливал — модель правильно оценивала неуверенность.
Ключевые тезисы
- Self-supervised подходы (DINO V2) позволяют быстро сократить объем данных для обучения.
- Edge-first мышление: лучше заранее проектировать под ограничения железа.
- Fallback и мониторинг критичны — в агросекторе нет второго шанса на сбор данных.
В полях главная метрика — чтобы все работало, даже если трактор с камерой уедет за горизонт.
Ознакомиться с полным докладом можно в записи.
Питч-сессия стартапов: ML-решения на стадии pre-MVP
В конце мероприятия прошла питч-сессия стартапов на стадии pre-MVP. Участники представили проекты в области AI и аналитики данных, после чего аудитория выбрала фаворитов онлайн-голосованием.
Проекты
- Ева («Ударник») — AI-помощник для сбора контактов потенциальных клиентов и автоматического установления связи.
- вИИзуал — мультимодальный ИИ для анализа изображений и видео в Data Lake.
- HiveTrace — система защиты генеративного ИИ, которая состоит из мониторинга и инструментов предотвращения атак.
- Lissa Health — анализ данных для выявления отклонений от нормы: от диагностики до контроля качества и экологических рисков.
- Volga — движок для расчета ML-фичей в реальном времени.
Победителями голосования стали HiveTrace, Volga и вИИзуал. Несмотря на раннюю стадию, решения демонстрируют зрелый технический подход и ориентацию на масштабируемость. Узнать подробнее о проектах участников можно Startup Pitch.
Общий вывод
MLечный путь 2025 показал, что продакшен ML сегодня — это не абстрактные алгоритмы, а инженерия, инфраструктура и компромиссы. Спикеры доказали, что сложные задачи решаются не за счет гигантских бюджетов, а за счет точных расчетов, зрелых инструментов и гибкости мышления.
Хотите быть частью сообщества, что развивает ML? Следите за комьюнити MLечного пути в Telegram.
