Лучший способ сжечь бюджет компании на инфраструктуру — запуск LLM в продакшене. Но только если вы не знаете, какой бэкенд использовать и как его настраивать.

Проблема в том, что параметры современных нейросетей растут по экспоненте, а обрабатываемый контекст становится все длиннее. Из-за этого операционные расходы на генерацию текста превращаются в главный барьер для масштабирования сервисов. Обслуживать запросы к LLM в десятки раз сложнее и дороже, чем крутить классический поиск по ключевым словам. Чтобы не разориться на счетах и выжать максимум из дорогостоящих GPU, нужен специализированный софт.

В этой статье мы подробно сравним три ведущих бэкенда для инференса: vLLM, LMDeploy и экосистему NVIDIA Triton Inference Server в связке с TensorRT-LLM. Мы разберем, как они управляют памятью, какие методы квантования используют и как распределяют запросы, а также оценим результаты их бенчмарков на актуальных архитектурах NVIDIA Hopper и Blackwell.

Последние годы развитие LLM шло по пути экстенсивного масштабирования: считалось, что чем больше весов и данных, тем умнее модель. В индустрии даже сложилась жесткая классификация по количеству параметров: 7B, 8B, 32B. Она же создает иллюзию, что модели одной весовой категории обладают сопоставимыми аналитическими, генеративными и логическими характеристиками, что в корне противоречит современным эмпирическим наблюдениям.

Но действительно ли «вес» модели все еще определяет ее качество в 2026 году? Или компактная архитектура способна конкурировать с гигантами, требующими H100 и сотни гигабайт VRAM? В этой статье мы не будем рассуждать об этом абстрактно: возьмем реальные модели из каталога FMC и посмотрим на практике, как размер влияет на качество reasoning, генерации и прикладную эффективность — и влияет ли вообще.

Привет! Меня зовут Александр Егоров, я MLOps-инженер в Альфа-Банке, куда попал через проект компании KTS.

За свою карьеру я построил четыре ML-платформы (одна из которых сейчас в Росреестре) и развиваю с командой пятую. Параллельно учусь в ИТМО по направлению «Безопасность искусственного интеллекта».

В этой статье я немного покритикую Airflow и поделюсь нашей историей миграции на связку Argo Workflows и Argo CD. Spoiler alert: технические подробности и результаты в наличии.

Привет! Меня зовут Александр, я MLOps-инженер.

JupyterHub — централизованный инструмент для создания Jupyter-ноутбуков для разных пользователей по заранее заданным параметрам, который используется более чем 200 специалистами у нас на проекте с коллегами из Альфа-Банка.

Сейчас множество сервисов Альфа-Банка могут запускаться в Kubernetes, который уже стал стандартом. И JupyterHub не исключение. Есть много статей по его запуску, и в большинстве из них описано, как просто поднять данный сервис и запустить рабочий ноутбук на базе профилей. Каждый профиль представляет собой заранее настроенные параметры для Pod ноутбука.

Однако с ростом числа пользователей возникают различные проблемы, о которых мы поговорим в этой статье.

Модели машинного обучения становятся критически важными для бизнеса, помогая оптимизировать процессы и принимать более обоснованные решения. Однако их актуальность и точность могут быстро снижаться из-за изменения данных. Автоматическое переобучение моделей в продакшене решает эту проблему, обеспечивая обновление и улучшение моделей без значительных временных затрат.

В этой статье мы рассмотрим процесс автоматического переобучения моделей ML в продакшене, используя инструменты MLOps. Обсудим интеграцию таких инструментов, как AirFlow и Spark, с CI/CD пайплайнами, а также создание конфигурационного модуля, позволяющего разработчикам сосредоточиться на моделях, не углубляясь в инфраструктурные детали.

Привет, меня зовут Александр Егоров, я MLOps инженер. В статье расскажу о том, как мы в банке выкатываем огромное количество моделей. Разберём не только пайплайн по выкладке отдельных моделей, но и целые каскады.