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

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

Метрика	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.

MLечный путь 2025 — знания, опыт, коммьюнити. Как это было?