Привет, Хабр! 23 апреля мы провели в Петербурге митап для ML-специалистов. Спикеры обсудили запуск LLM в продакшен, оптимизацию GPU-инференса, а также Edge-решения для медицины и агросектора. Минимум теории — больше кейсов от Selectel, Cloud.ru, Celsus и Русагро.

Как подобрать инфраструктуру под LLM? Как контейнеризировать GPU в многоарендных средах? Как запускать ML на комбайне или медицинском поезде без интернета? На эти вопросы ответили в четырех докладах на MLлечном пути.

А еще мы организовали питч-сессию для стартапов. Пять проектов на стадии pre-MVP боролись за призовой фонд в 100 000 бонусов. Победителей выбирали сами зрители. В тексте рассказываем, как все было.


Используйте навигацию, если не хотите читать текст полностью:
→ Приручая LLM: как подобрать седло под своего дракона
→ Эффективная утилизация GPU для инференса в облаке: когда MIG и MPS не помогают
→ Адский инференс: ML в тайге, на поездах и без интернета
→ Edge AI для агросектора: видеоаналитика на комбайнах
→ Питч-сессия стартапов: ML-решения на стадии pre-MVP

Приручая LLM: как подобрать седло под своего дракона

Антон Алексеев, DevOps-инженер в Selectel.


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

В своем докладе Антон поделился опытом, как они с командой подходят к подбору железа для LLM: от проектирования до оптимизации и автоматизации.

Пять принципов подбора железа

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

• количество запросов в секунду (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 и дополнили ее своими замерами спустя семь месяцев.

Что показали тесты

Выводы

Подходы к запуску принципиально разные. 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 есть проблема с контролем памяти.Хоть 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.