Как понять, что «тормозит» DataLoader?
Недавно был задан классный вопрос:
"Может ли малая утилизация CPU означать проблемы с DataLoader?"
Утверждать нельзя, потому что в DataLoader:
1. Утилизируют CPU только аугментации и декодинг файла.
Это, пожалуй, единственная вычислительная нагрузка в нем, и ее может не хватать для создания существенной утилизации.
Декодинг файла - актуально для медиа-данных, хранящихся в сжатом виде.
2. Загрузка файлов - I/O-bound, т.к. представляет из себя ожидание получения очередного блока с сети/диска.
Поэтому и около нулевая утилизация CPU.
Смотреть надо на метрики диска (если чтение локально) или сети (если чтение с общего хранилища).
А для того, чтобы проверить, тормозит ли DataLoader, cравните скорость обучения в трёх вариантах:
1. Бейзлайн: ваш исходный код.
2. Минус аугментации: отключите/упростите тяжёлые трансформации.
3. Синтетика чтения: как в п.2, но данные не читаются с диска/сети — генерируйте случайные тензоры той же формы
4. Синтетика декодирования для image/video/voice: как в п.3, только генерируйте содержимое файла до декодирования.
Интерпретация:
1. Ускорение 1→2 — «тяжёлые» аугментации, оптимизируем их.
2. Ускорение 2→3 — бутылочное горлышко в доступе к данным.
3. Ускорение 4→3 — тормозит декодирование файлов.
4. Ускорения нигде нет — DataLoader вас не тормозит; ищите проблемы в самом тренировочном цикле.
Накидайте реакций/конфигов и сделаю замеры по разным сетапам даталоадеров.
@deploy_ml
Недавно был задан классный вопрос:
"Может ли малая утилизация CPU означать проблемы с DataLoader?"
Утверждать нельзя, потому что в DataLoader:
1. Утилизируют CPU только аугментации и декодинг файла.
Это, пожалуй, единственная вычислительная нагрузка в нем, и ее может не хватать для создания существенной утилизации.
Декодинг файла - актуально для медиа-данных, хранящихся в сжатом виде.
2. Загрузка файлов - I/O-bound, т.к. представляет из себя ожидание получения очередного блока с сети/диска.
Поэтому и около нулевая утилизация CPU.
Смотреть надо на метрики диска (если чтение локально) или сети (если чтение с общего хранилища).
А для того, чтобы проверить, тормозит ли DataLoader, cравните скорость обучения в трёх вариантах:
1. Бейзлайн: ваш исходный код.
2. Минус аугментации: отключите/упростите тяжёлые трансформации.
3. Синтетика чтения: как в п.2, но данные не читаются с диска/сети — генерируйте случайные тензоры той же формы
4. Синтетика декодирования для image/video/voice: как в п.3, только генерируйте содержимое файла до декодирования.
Интерпретация:
1. Ускорение 1→2 — «тяжёлые» аугментации, оптимизируем их.
2. Ускорение 2→3 — бутылочное горлышко в доступе к данным.
3. Ускорение 4→3 — тормозит декодирование файлов.
4. Ускорения нигде нет — DataLoader вас не тормозит; ищите проблемы в самом тренировочном цикле.
Накидайте реакций/конфигов и сделаю замеры по разным сетапам даталоадеров.
@deploy_ml
🔥7❤🔥1
У меня в последнее время подгорает на cursor, потому что
1. На запрос генерируется несколько файлов (код, тесты, readme, скрипты запуска).
2. Проект превращается в свалку файлов от разных запросов.
3. Лимиты на cursor улетают очень быстро. А ведь они недавно еще их и порезали.
Проблема в том, что в одном продукте смешан функционал для разных целевых аудиторий:
1. Вайбкодеры
Надо быстро и под ключ. Чтобы сразу весь проект сделало, скрипты сетапа и запуска. Те самые MVP, которые нужны, чтобы поглядеть как выглядит реализация идеи, выкинуть и сделать хорошо.
2. Профессиональные разработчики
Нужно добавить конкретный узкий функционал. Или даже один конкретный класс или функцию. Возможно несколько запросов подряд для реализации разного функционала.
В итоге интерфейсы и первые скетчи кода я сейчас вынуждено генерирую в chatgpt. И потом довожу их до ума в cursor, вечно добавляя "do not over engineer, make it simple, ...".
И все чаще ловлю себя на мысли "лучше бы сам руками сделал".
А где-то радуется один вайбкодер. И Сэм, пытающийся продать gpt как замену разработчика 😀
@deploy_ml
1. На запрос генерируется несколько файлов (код, тесты, readme, скрипты запуска).
2. Проект превращается в свалку файлов от разных запросов.
3. Лимиты на cursor улетают очень быстро. А ведь они недавно еще их и порезали.
Проблема в том, что в одном продукте смешан функционал для разных целевых аудиторий:
1. Вайбкодеры
Надо быстро и под ключ. Чтобы сразу весь проект сделало, скрипты сетапа и запуска. Те самые MVP, которые нужны, чтобы поглядеть как выглядит реализация идеи, выкинуть и сделать хорошо.
2. Профессиональные разработчики
Нужно добавить конкретный узкий функционал. Или даже один конкретный класс или функцию. Возможно несколько запросов подряд для реализации разного функционала.
В итоге интерфейсы и первые скетчи кода я сейчас вынуждено генерирую в chatgpt. И потом довожу их до ума в cursor, вечно добавляя "do not over engineer, make it simple, ...".
И все чаще ловлю себя на мысли "лучше бы сам руками сделал".
А где-то радуется один вайбкодер. И Сэм, пытающийся продать gpt как замену разработчика 😀
@deploy_ml
😁7💯5🔥4
Стоимость инференса LLM снижается до 10x каждый год
Cравниваются модели с похожим качеством на бенчмарках
Год назад была статья от a16z.
В этом году тренд продолжается.
Почему стоимость инференса падает?
1. Не столько инференс дешевеет, сколько модели становятся мощнее и quality-per-parameter растет.
2. Квантизации становятся продвинутее.
3. MoE/Model Router позволяют получать модели с производительностью огромных, но с фактически небольшим футпринтом (новые KIMI K2 с 1T параметров и с 32B активируемых; GPT5 который использует еще и model router).
4. GPU становятся мощнее. Но это всего условные ~х2 FLOPs per dollar за 2 года.
Процесс обучения таких моделей сложнее, от того их создание становится дороже с каждым годом.
Есть два позитивных последствия:
1. LLM будут шире использоваться, потому что будут лучше себя окупать. В Сбере говорят, что для массового распространения нужно еще сокращение в 7-10 раз. То есть, хотябы еще годик текущего тренда на снижение цен.
2. Модели, влезающие в одну игровую карту, становятся лучше и доступнее.
@deploy_ml
Cравниваются модели с похожим качеством на бенчмарках
Год назад была статья от a16z.
В этом году тренд продолжается.
Почему стоимость инференса падает?
1. Не столько инференс дешевеет, сколько модели становятся мощнее и quality-per-parameter растет.
2. Квантизации становятся продвинутее.
3. MoE/Model Router позволяют получать модели с производительностью огромных, но с фактически небольшим футпринтом (новые KIMI K2 с 1T параметров и с 32B активируемых; GPT5 который использует еще и model router).
4. GPU становятся мощнее. Но это всего условные ~х2 FLOPs per dollar за 2 года.
Процесс обучения таких моделей сложнее, от того их создание становится дороже с каждым годом.
Есть два позитивных последствия:
1. LLM будут шире использоваться, потому что будут лучше себя окупать. В Сбере говорят, что для массового распространения нужно еще сокращение в 7-10 раз. То есть, хотябы еще годик текущего тренда на снижение цен.
2. Модели, влезающие в одну игровую карту, становятся лучше и доступнее.
@deploy_ml
🔥8⚡1
Ещё немного о линейных трансформерах
На прошлой неделе участвовал в воркшопе китайских коллег и выступал на тему edge-cloud collaboration. Рассказывал, как мы ускоряли ARMT.
Проблема edge-cloud:
Смартфон есть почти у каждого, и их вычислительная мощность растёт. Сервер же один — и дорогой. Часто это приводит к подписке $10+ на любого LLM-ассистента.
Цель — максимально задействовать сам телефон (хотя бы для спекулятивного декодинга), чтобы снизить нагрузку и цену.
Преимущества линейных трансформеров (и ARMT):
1. Фиксированный оверхед памяти.
KVCache растёт линейно и уникален для каждого запроса. В линейных трансформерах состояние мало и на фоне общей модели почти не заметно. Особенно важно для edge-устройств с малым объёмом памяти (почти все до 8–16 ГБ), где все приложения конкурируют за ресурсы.
2. Линейная сложность.
Если положить в контекст два документа вместо одного, latency уменьшится в ~2 раза — не в 4, как у классического трансформера. Проще управлять нагрузкой.
Для мобильных — экономия батареи, меньше нагрева.
3. Гибкость в выборе базовой модели (только ARMT).
Можно взять любую модель как основу (ARMT работает на сегментной рекуррентности), без необходимости писать и тащить в прод дополнительные CUDA-ядра (тоже было в статье).
Для мобильных — не надо дописывать и оптимизировать библиотеку линейной алгебры.
4. Упрощение балансировки запросов (только ARMT).
Один запрос полностью утилизирует GPU (мы показали в статье), и нам не нужны сложные балансировки — можно вернуть stateless балансировщик.
Для мобильных — пользователь делает запрос, и модель может утилизировать ресурсы как телефона, так и сервера “из коробки”.
Когда не стоит думать о линейных трансформерах:
1. Контекст < ~32000 токенов.
Ниже этого порога квадратичная сложность обычного трансформера ещё не сильно влияет, и, не хуже линейной. В ARMT текущий порог — около 16–20k токенов. И при ~32к он начинает проявлять свою вычислительную выгоду.
2. Необходимость дообучения (fine-tune).
Внедрение линейного трансформера добавляет стадию дообучения (обучение рекуррентной памяти). Это на порядки дешевле претрейна, но требует ресурсов и сбора данных.
Вывод:
Если вы собрались пилить RAG по большим книжкам/картам, или по видео/музыке (там seq_len - это секунды и даже сжатие VAE не то чтобы решает проблему) - подумайте об линейных трасформерах.
Ps: преза в комментах
@deploy_ml
На прошлой неделе участвовал в воркшопе китайских коллег и выступал на тему edge-cloud collaboration. Рассказывал, как мы ускоряли ARMT.
Проблема edge-cloud:
Смартфон есть почти у каждого, и их вычислительная мощность растёт. Сервер же один — и дорогой. Часто это приводит к подписке $10+ на любого LLM-ассистента.
Цель — максимально задействовать сам телефон (хотя бы для спекулятивного декодинга), чтобы снизить нагрузку и цену.
Преимущества линейных трансформеров (и ARMT):
1. Фиксированный оверхед памяти.
KVCache растёт линейно и уникален для каждого запроса. В линейных трансформерах состояние мало и на фоне общей модели почти не заметно. Особенно важно для edge-устройств с малым объёмом памяти (почти все до 8–16 ГБ), где все приложения конкурируют за ресурсы.
2. Линейная сложность.
Если положить в контекст два документа вместо одного, latency уменьшится в ~2 раза — не в 4, как у классического трансформера. Проще управлять нагрузкой.
Для мобильных — экономия батареи, меньше нагрева.
3. Гибкость в выборе базовой модели (только ARMT).
Можно взять любую модель как основу (ARMT работает на сегментной рекуррентности), без необходимости писать и тащить в прод дополнительные CUDA-ядра (тоже было в статье).
Для мобильных — не надо дописывать и оптимизировать библиотеку линейной алгебры.
4. Упрощение балансировки запросов (только ARMT).
Один запрос полностью утилизирует GPU (мы показали в статье), и нам не нужны сложные балансировки — можно вернуть stateless балансировщик.
Для мобильных — пользователь делает запрос, и модель может утилизировать ресурсы как телефона, так и сервера “из коробки”.
Когда не стоит думать о линейных трансформерах:
1. Контекст < ~32000 токенов.
Ниже этого порога квадратичная сложность обычного трансформера ещё не сильно влияет, и, не хуже линейной. В ARMT текущий порог — около 16–20k токенов. И при ~32к он начинает проявлять свою вычислительную выгоду.
2. Необходимость дообучения (fine-tune).
Внедрение линейного трансформера добавляет стадию дообучения (обучение рекуррентной памяти). Это на порядки дешевле претрейна, но требует ресурсов и сбора данных.
Вывод:
Если вы собрались пилить RAG по большим книжкам/картам, или по видео/музыке (там seq_len - это секунды и даже сжатие VAE не то чтобы решает проблему) - подумайте об линейных трасформерах.
Ps: преза в комментах
@deploy_ml
🔥11❤🔥1
Как LLM становятся «самостоятельными исследователями»
Наткнулся на статью Barbarians at the Gate: How AI is Upending Systems Research [link] из UC Berkeley.
Тема на слуху, если не в курсе - рекомендую изучить,
чтобы понимать применимость в ваших задачах.
AI-Driven Research for Systems (ADRS):
Многократный generate → verify → select → mutate → repeat.
По сути то же самое, что делает человек при создании решения. Только тут LLM полностью генерирует варианты, вручную написанный верификатор/бенчмарк измеряет качество решения, и цикл эволюционирует, создавая более эффективный с точки зрения верификатора алгоритм.
Попробовать такое можно в OpenEvolve.
Отлично подходит для задач, где можно придумать однозначные критерии качества - написание оптимизированных функций, CUDA ядер, SQL запросов и решения оптимизационных задач.
Мы уже используем, как еще один инструмент генерации идей. Выходит неплохо, хотя результат и приходится допиливать.
@deploy_ml
Наткнулся на статью Barbarians at the Gate: How AI is Upending Systems Research [link] из UC Berkeley.
Тема на слуху, если не в курсе - рекомендую изучить,
чтобы понимать применимость в ваших задачах.
AI-Driven Research for Systems (ADRS):
Многократный generate → verify → select → mutate → repeat.
По сути то же самое, что делает человек при создании решения. Только тут LLM полностью генерирует варианты, вручную написанный верификатор/бенчмарк измеряет качество решения, и цикл эволюционирует, создавая более эффективный с точки зрения верификатора алгоритм.
Попробовать такое можно в OpenEvolve.
Отлично подходит для задач, где можно придумать однозначные критерии качества - написание оптимизированных функций, CUDA ядер, SQL запросов и решения оптимизационных задач.
Мы уже используем, как еще один инструмент генерации идей. Выходит неплохо, хотя результат и приходится допиливать.
@deploy_ml
🔥3
Как именно Alibaba ускорили на 84% мультимодельный инференс?
TLDR: Alibaba Cloud представила Aegaeon (без кода 🙃) [paper] — по-токенный авто-скейлер для мультимодельного инференса.
В проде (Alibaba Model Studio, >3 месяцев) он позволил снизить потребление GPU на 82%: с 1 192 до 213 H200,
а «goodput» (RPS в рамках SLO) вырос в 1.5-9х.
Продовый кластер состоит из 28 моделей размера 1.8–7B models (TP=1) и 19 моделей размера 32–72B models (TP=4)
В реальности - сделали несколько инженерных оптимизаций:
1. Написали ручную аллокацию и менеджмент памяти (уже это дает ускорение, см. YaFSDP)
2. Ушли от кластерного автоскейлинга. Нет явного масштабирования машинами, они запущены один раз на одном образе (пуллинг одного образа - до 10-20 минут) и дальше разделяются между моделями. Поэтому они и взяли vLLM, чтобы у них зависимости не поехали
3. Залезли в внутрянку vLLM, инициализация делается один раз на старте (vllm/tensorrt - инициализируются около 30 секунд), загрузка-выгрузка модели и кешей делается руками (Figure 7)
4. Token-level шедулинг - это скорее вишенка на торте и не особо верю, что именно такая гранулярность дает много ускорения.
SLA на TPOT измеряется в десятках миллисекунд, просто загрузка весов из CPU в GPU - от сотен миллисекунд для больших моделей.
Потому шедулить разумно в лучшем случае чанками.
Обратите внимание на картинку утилизации до/после
С уровней ~30% они подскочили до ~60% (Figure 18)
Так что над движками мультмодельного инференса еще работать и работать
Я сейчас как раз исследую подобные системы — планирование в кластере и enterprise кейсы с переподпиской серверов на модели. Если у вас нагруженный инференс и готовы обсудить архитектуру/SLA/кэш-стратегии — пишите в лс (@svt_danny) или чат.
@deploy_ml
TLDR: Alibaba Cloud представила Aegaeon (без кода 🙃) [paper] — по-токенный авто-скейлер для мультимодельного инференса.
В проде (Alibaba Model Studio, >3 месяцев) он позволил снизить потребление GPU на 82%: с 1 192 до 213 H200,
а «goodput» (RPS в рамках SLO) вырос в 1.5-9х.
Продовый кластер состоит из 28 моделей размера 1.8–7B models (TP=1) и 19 моделей размера 32–72B models (TP=4)
В реальности - сделали несколько инженерных оптимизаций:
1. Написали ручную аллокацию и менеджмент памяти (уже это дает ускорение, см. YaFSDP)
2. Ушли от кластерного автоскейлинга. Нет явного масштабирования машинами, они запущены один раз на одном образе (пуллинг одного образа - до 10-20 минут) и дальше разделяются между моделями. Поэтому они и взяли vLLM, чтобы у них зависимости не поехали
3. Залезли в внутрянку vLLM, инициализация делается один раз на старте (vllm/tensorrt - инициализируются около 30 секунд), загрузка-выгрузка модели и кешей делается руками (Figure 7)
4. Token-level шедулинг - это скорее вишенка на торте и не особо верю, что именно такая гранулярность дает много ускорения.
SLA на TPOT измеряется в десятках миллисекунд, просто загрузка весов из CPU в GPU - от сотен миллисекунд для больших моделей.
Потому шедулить разумно в лучшем случае чанками.
Обратите внимание на картинку утилизации до/после
С уровней ~30% они подскочили до ~60% (Figure 18)
Так что над движками мультмодельного инференса еще работать и работать
Я сейчас как раз исследую подобные системы — планирование в кластере и enterprise кейсы с переподпиской серверов на модели. Если у вас нагруженный инференс и готовы обсудить архитектуру/SLA/кэш-стратегии — пишите в лс (@svt_danny) или чат.
@deploy_ml
🔥15
В чем устройство LakeHouse и отличие от баз данных?
В этом году чаще слышу о LakeHouse и мыслях его внедрить.
В чем основная суть:
1. Слой хранения выносим отдельно от слоя вычисления -> в s3
2. Формат хранения - универсальный (parquet например)
3. Поверх одного хранилища запускаем разные табличные движки
Похожее произошло с вычислениями пару лет назад с приходом связки kubernetes/s3. Компании смогли динамически аллоцировать ресурсы и за счет этого снизить требования к индивидуальным серверам (правда потом LLM все опять перевернули с ног на голову из-за требований к nvlink и infiniband)
Решил написать пост, наткнувшись на видео от сооснователя DuckLake (для нас интересно до 24 минуты, дальше про DuckLake).
Об естественных особенностях такого решения:
➕ Удобно и гибко
1. Много движков, да и свой обработчик легко написать
2. Если движок поддерживает s3/parquet - не нужно писать коннекторы
3. Вычислительные ресурсы можно переиспользовать в рамках кластера (serverless для вычислений)
4. Наверное, будет устаревать плавнее, за счет модульности. То есть заменили движок/инструмент и вроде снова в тренде, не выкидывая всю систему целиком.
➕ Дешевле
1. Не нужно закупать вычислительные сервера под хранение
2. Ниже цена ошибки. Можно заранее думать только о серверах хранения, а для вычислений переиспользовать общие пулы ресурсов
3. Если движок поддерживает s3/parquet - не нужно перекладывать и дублировать данные между инструментами команд
➖ Сильно медленнее чем классические базы данных
Да, именно так, а что вы хотели?
1. Ходите всегда по сети за данными*, у вас буквально абстракция s3 и нет возможностей выполнить условный map локально на сервере хранения. А значит всегда ограничены 10-20Gbit/s сети.
2. Вынуждены каждый раз парсить файл заново. А обычная база может хранить на диске layout как в памяти и просто делать memmap.
➖ Тяжело
Раньше вы поднимали один продукт и настраивали. Тут продукт растащили на несколько независимых инструментов. На масштабе выгодно, для старта - тяжело (тут ситуация на kubernetes похожа)
*Да, вы можете оптимизировать формат хранения (parquet -> Vortex, F3, FastLanes, Nimble) и минимизировать s3 чтения.
Да, вы можете придумать кэши, но тогда появится база под метаданные. Туда в итоге и движемся. Но, повторю, это не то же самое, что прочитать с локального диска и пройтись по файлу. Джордан в видео заявляет х2-10 замедление от баз.
@deploy_ml
В этом году чаще слышу о LakeHouse и мыслях его внедрить.
В чем основная суть:
1. Слой хранения выносим отдельно от слоя вычисления -> в s3
2. Формат хранения - универсальный (parquet например)
3. Поверх одного хранилища запускаем разные табличные движки
Похожее произошло с вычислениями пару лет назад с приходом связки kubernetes/s3. Компании смогли динамически аллоцировать ресурсы и за счет этого снизить требования к индивидуальным серверам (правда потом LLM все опять перевернули с ног на голову из-за требований к nvlink и infiniband)
Решил написать пост, наткнувшись на видео от сооснователя DuckLake (для нас интересно до 24 минуты, дальше про DuckLake).
Об естественных особенностях такого решения:
1. Много движков, да и свой обработчик легко написать
2. Если движок поддерживает s3/parquet - не нужно писать коннекторы
3. Вычислительные ресурсы можно переиспользовать в рамках кластера (serverless для вычислений)
4. Наверное, будет устаревать плавнее, за счет модульности. То есть заменили движок/инструмент и вроде снова в тренде, не выкидывая всю систему целиком.
1. Не нужно закупать вычислительные сервера под хранение
2. Ниже цена ошибки. Можно заранее думать только о серверах хранения, а для вычислений переиспользовать общие пулы ресурсов
3. Если движок поддерживает s3/parquet - не нужно перекладывать и дублировать данные между инструментами команд
Да, именно так, а что вы хотели?
1. Ходите всегда по сети за данными*, у вас буквально абстракция s3 и нет возможностей выполнить условный map локально на сервере хранения. А значит всегда ограничены 10-20Gbit/s сети.
2. Вынуждены каждый раз парсить файл заново. А обычная база может хранить на диске layout как в памяти и просто делать memmap.
Раньше вы поднимали один продукт и настраивали. Тут продукт растащили на несколько независимых инструментов. На масштабе выгодно, для старта - тяжело (тут ситуация на kubernetes похожа)
*Да, вы можете оптимизировать формат хранения (parquet -> Vortex, F3, FastLanes, Nimble) и минимизировать s3 чтения.
Да, вы можете придумать кэши, но тогда появится база под метаданные. Туда в итоге и движемся. Но, повторю, это не то же самое, что прочитать с локального диска и пройтись по файлу. Джордан в видео заявляет х2-10 замедление от баз.
@deploy_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
DuckLake: Learning from Cloud Data Warehouses to Build a Robust “Lakehouse” (Jordan Tigani)
CMU Database Group - Future Data Systems Seminar Series (Fall 2025)
Speaker: Jordan Tigani (https://www.linkedin.com/in/jordantigani)
October 6, 2025
https://db.cs.cmu.edu/seminars/fall2025/#db3
Sponsors: Google DAPA Team (https://google.com)
Speaker: Jordan Tigani (https://www.linkedin.com/in/jordantigani)
October 6, 2025
https://db.cs.cmu.edu/seminars/fall2025/#db3
Sponsors: Google DAPA Team (https://google.com)
🔥5❤1
С наступающим Новым годом! 🎄✨
2025 выдался насыщенным, вот что запомнилось:
Из житейского:
1. LLM стали альтернативой поиску. RAG все чаще дает ответ сразу, а не списком сайтов, которые нужно переварить (галлюцинации, конечно, не нужно забывать).
2. Генеративный контент стал почти неотличим от реального. По ощущениям, каждый третий шортс - из нейросетки. А уж что там в рекламных материалах - баннера, заголовки, описания, картинки для макретплейсов.
3. Паранойя и "нейро-гигиена". Если что-то «чуть не так» - первая мысль: «это сгенерировано».
А еще, кстати, зрелость в команде легко проверить по работе с ChatGPT🔔 : кто-то перепроверяет и правит, кто-то молча пересылает как истину.
4. Инференс дешевеет - растет применение нейросетей.
В компаниях РФ особенно заметен спрос на RAG: поиск по внутренней документации, материалам сейлов, клиентский сервис - часто самая понятная польза от внедрения.
Из технического:
1. Распределённый инференс доехал до прода. Раньше распределенные вычисления были в основном в обучении и у энтузиастов с игровыми GPU, а теперь - в реальном инференсе больших моделей и длинных контекстов.
2. Масштабирование размеров LLM. Продовые модели - уже не только 3-7b, а и MoE 30-70b+
При этом моделями 671B (DeepSeekR1) и 1T (Kimi K2) уже никого не удивить.
3. Алгоритмические ускорения для инференса LLM. Спекулятивный декодинг, раздельные prefill/decode, multi-lora, оффлоадинг/автомасштабирование моделей - база для эффективного инференса.
Многое из этого нормально «из коробки» работает в vLLM/sglang в data/tensor-parallel сценариях.
4. MCP и мультиагенты: хайпа много, полезных применений пока мало.
В основном о них говорят ранние последователи, либо люди, слабо понимающие в ML разработке. А у технарей подгорает, потому что их просят сделать какой-то ужас. Но по мере снижения стоимости LLM, кажется, в массах свое применение они найдут.
Ещё раз - с наступающим! Пусть 2026 принесёт больше ясных задач, меньше горящих дедлайнов и побольше систем, которые работают быстрее, дешевле и предсказуемее 🚀
@deploy_ml
2025 выдался насыщенным, вот что запомнилось:
Из житейского:
1. LLM стали альтернативой поиску. RAG все чаще дает ответ сразу, а не списком сайтов, которые нужно переварить (галлюцинации, конечно, не нужно забывать).
2. Генеративный контент стал почти неотличим от реального. По ощущениям, каждый третий шортс - из нейросетки. А уж что там в рекламных материалах - баннера, заголовки, описания, картинки для макретплейсов.
3. Паранойя и "нейро-гигиена". Если что-то «чуть не так» - первая мысль: «это сгенерировано».
А еще, кстати, зрелость в команде легко проверить по работе с ChatGPT
4. Инференс дешевеет - растет применение нейросетей.
В компаниях РФ особенно заметен спрос на RAG: поиск по внутренней документации, материалам сейлов, клиентский сервис - часто самая понятная польза от внедрения.
Из технического:
1. Распределённый инференс доехал до прода. Раньше распределенные вычисления были в основном в обучении и у энтузиастов с игровыми GPU, а теперь - в реальном инференсе больших моделей и длинных контекстов.
2. Масштабирование размеров LLM. Продовые модели - уже не только 3-7b, а и MoE 30-70b+
При этом моделями 671B (DeepSeekR1) и 1T (Kimi K2) уже никого не удивить.
3. Алгоритмические ускорения для инференса LLM. Спекулятивный декодинг, раздельные prefill/decode, multi-lora, оффлоадинг/автомасштабирование моделей - база для эффективного инференса.
Многое из этого нормально «из коробки» работает в vLLM/sglang в data/tensor-parallel сценариях.
4. MCP и мультиагенты: хайпа много, полезных применений пока мало.
В основном о них говорят ранние последователи, либо люди, слабо понимающие в ML разработке. А у технарей подгорает, потому что их просят сделать какой-то ужас. Но по мере снижения стоимости LLM, кажется, в массах свое применение они найдут.
Ещё раз - с наступающим! Пусть 2026 принесёт больше ясных задач, меньше горящих дедлайнов и побольше систем, которые работают быстрее, дешевле и предсказуемее 🚀
@deploy_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
🍾14❤5🔥1