Зачем нужен бизнес-сценарий при нагрузочном тестировании?
Когда MVP нового функционала разработан, часто инженеры теряются при постановке задачи нагрузочного тестирования: не ясно, как и что тестировать, как добиться репрезентативности.
Причина в том, что производительность сильно зависит от конкретных сценариев использования и взаимодействия компонент. Общей картины обычно у большинства нет, а сложные коммуникации технари не любят.
Например, для инференса LLM реальны такие сценарии:
1. Короткие запросы,
2. RAG с файлами разного размера,
3. Длинное во времени интерактивное взаимодействие (с офлоадингом KV кешей),
4. Редкие запросы к разным моделям (с офлоадингом весов моделей),
5. Мульти-модельный деплой и деплой модели с большим количеством LoRA-адаптеров.
Каждый сценарий требует отдельных профилей нагрузки (размер контекста, паттерн обращения) и выявляет свои узкие места. End2End-тесты помогают обнаружить эти проблемы заранее, прежде чем о них сообщат пользователи.
Это касается не только инференса, но и любых компонентов: кешей, баз данных, cicd. Узкое место не всегда очевидно — это может быть медленная авторизация, сброс долгих запросов или ошибки взаимодействия микросервисов команд.
Без понимания бизнес-задачи сетапы выбираются как-нибудь.
В итоге команда рискует исправлять не то, что действительно важно.
@deploy_ml
Когда MVP нового функционала разработан, часто инженеры теряются при постановке задачи нагрузочного тестирования: не ясно, как и что тестировать, как добиться репрезентативности.
Причина в том, что производительность сильно зависит от конкретных сценариев использования и взаимодействия компонент. Общей картины обычно у большинства нет, а сложные коммуникации технари не любят.
Например, для инференса LLM реальны такие сценарии:
1. Короткие запросы,
2. RAG с файлами разного размера,
3. Длинное во времени интерактивное взаимодействие (с офлоадингом KV кешей),
4. Редкие запросы к разным моделям (с офлоадингом весов моделей),
5. Мульти-модельный деплой и деплой модели с большим количеством LoRA-адаптеров.
Каждый сценарий требует отдельных профилей нагрузки (размер контекста, паттерн обращения) и выявляет свои узкие места. End2End-тесты помогают обнаружить эти проблемы заранее, прежде чем о них сообщат пользователи.
Это касается не только инференса, но и любых компонентов: кешей, баз данных, cicd. Узкое место не всегда очевидно — это может быть медленная авторизация, сброс долгих запросов или ошибки взаимодействия микросервисов команд.
Без понимания бизнес-задачи сетапы выбираются как-нибудь.
В итоге команда рискует исправлять не то, что действительно важно.
@deploy_ml
❤3🔥3
Обогнали, но "кого?" и "как?". Новые сетевые карточки AMD.
Несколько дней назад вышла новость, что AMD в партнерстве с Oracle Cloud развернет свои UALink (Nvidia NVL72-like) стойки.
У нас эту новость подхватили в контексте новой сетевой карточки AMD Pensando™ Pollara 400 AI, аналога infiniband.
Кратко характеристики:
1. RoCE v2 + UEC 1.0 RDMA
2. До 4х портов. Можно подключить 1x400Gb/s, 2x200Gb/s, 4x100Gb/s
И вы могли слышать, что заявляется выше эффективность по сравнению с конкурентами (так на сайте нарисовано).
Там, как обычно, забавно:
1. Сравниваются они с Nvidia ConnectX-7, вышедшим в 2022 году. И обгоняют его на 10%.
А у Nvidia уже есть серия BlueField и новый ConnectX-8.
2. В релизе дают ссылки на статьи с обоснованиями, почему они круче. Так вот там две статьи:
- Enhancing Large-Scale AI Training Efficiency: The C4 Solution for Real-Time Anomaly Detection and Communication Optimization [arxiv]
- The Llama 3 Herd of Models [arxiv]
Но в обоих статьях AMD не использовали. Там Nvidia BlueField в сетапах, с которым они по производительности не сравниваются.
Вот что пишут на том же релизе в footnote: "Claim reflects technology used in AMD Pensando Pollara 400 NICs, however testing and data not specific to the Pollara 400. Results may vary."
Вот так вот. На самом деле, маркетинг догоняющих продуктов - это очень не просто.
Не сказать же в релизе "мы медленнее, но дешевле и готовы с вами персонально работать" (хотя мне кажется персональность работы в b2b поставках - это куда более конкурентное преимущество, чем 10% к производительности).
И я очень рад, что у AMD появляются конкурентные решения. Им очень не хватало наличия конкурентного аналога infiniband, чтобы иметь замкнутую поставку для обучения и инференса, учитывая крутость последних суперчипов mi300 с большим количеством памяти.
@deploy_ml
Несколько дней назад вышла новость, что AMD в партнерстве с Oracle Cloud развернет свои UALink (Nvidia NVL72-like) стойки.
У нас эту новость подхватили в контексте новой сетевой карточки AMD Pensando™ Pollara 400 AI, аналога infiniband.
Кратко характеристики:
1. RoCE v2 + UEC 1.0 RDMA
2. До 4х портов. Можно подключить 1x400Gb/s, 2x200Gb/s, 4x100Gb/s
И вы могли слышать, что заявляется выше эффективность по сравнению с конкурентами (так на сайте нарисовано).
Там, как обычно, забавно:
1. Сравниваются они с Nvidia ConnectX-7, вышедшим в 2022 году. И обгоняют его на 10%.
А у Nvidia уже есть серия BlueField и новый ConnectX-8.
2. В релизе дают ссылки на статьи с обоснованиями, почему они круче. Так вот там две статьи:
- Enhancing Large-Scale AI Training Efficiency: The C4 Solution for Real-Time Anomaly Detection and Communication Optimization [arxiv]
- The Llama 3 Herd of Models [arxiv]
Но в обоих статьях AMD не использовали. Там Nvidia BlueField в сетапах, с которым они по производительности не сравниваются.
Вот что пишут на том же релизе в footnote: "Claim reflects technology used in AMD Pensando Pollara 400 NICs, however testing and data not specific to the Pollara 400. Results may vary."
Вот так вот. На самом деле, маркетинг догоняющих продуктов - это очень не просто.
Не сказать же в релизе "мы медленнее, но дешевле и готовы с вами персонально работать" (хотя мне кажется персональность работы в b2b поставках - это куда более конкурентное преимущество, чем 10% к производительности).
И я очень рад, что у AMD появляются конкурентные решения. Им очень не хватало наличия конкурентного аналога infiniband, чтобы иметь замкнутую поставку для обучения и инференса, учитывая крутость последних суперчипов mi300 с большим количеством памяти.
@deploy_ml
🔥5⚡2
Замеры MultiLoRA для оффлайн/асинхронного инференса
Опубликовал статью на habr по сравнению функционала MultiLoRA в vllm и TensorRT-LLM.
Интересно, что в релизных докерах результат не в ту сторону, которую вы могли бы подумать - vllm на всех сетапах круче*.
Думал, что дело в настройках TensorRT-LLM, ускорил в 1.2-1.5 раз, но vllm оно так и не догнало (на графиках и табличках замеры уже с оптимизацией)
*сравниваются python3 обертки в сетапе оффлайн/асинхронного инференса. Без интерактивности (потому без time-to-first-token) и сетевой обвязки.
@deploy_ml
Опубликовал статью на habr по сравнению функционала MultiLoRA в vllm и TensorRT-LLM.
Интересно, что в релизных докерах результат не в ту сторону, которую вы могли бы подумать - vllm на всех сетапах круче*.
Думал, что дело в настройках TensorRT-LLM, ускорил в 1.2-1.5 раз, но vllm оно так и не догнало (на графиках и табличках замеры уже с оптимизацией)
*сравниваются python3 обертки в сетапе оффлайн/асинхронного инференса. Без интерактивности (потому без time-to-first-token) и сетевой обвязки.
@deploy_ml
Хабр
Эффективный инференс множества LoRA адаптеров
LoRA — популярный метод дообучения больших моделей на небольших датасетах, однако на этапе инференса низкоранговые адаптеры работают неэффективно, а их объединение с весами требует хранения отдельной...
❤🔥5🔥3🍌1
Летняя школа AIRI
Приехал в Томск чтобы провести пару лекций на летней школе по ИИ от AIRI и заменторить проекты.
Ну и поесть окрошку и варенье из шишек.
4 июля буду читать о практичных инженерных штуках в обучении моделей.
Слайдами тут обязательно поделюсь)
Приехал в Томск чтобы провести пару лекций на летней школе по ИИ от AIRI и заменторить проекты.
Ну и поесть окрошку и варенье из шишек.
4 июля буду читать о практичных инженерных штуках в обучении моделей.
Слайдами тут обязательно поделюсь)
🔥10⚡2❤1
А вот и слайды.
Небольшой обзор по эффективному обучению и релевантным тематикам для студентов с летней школы.
В начале прикладные материалы + материалы для начинающих.
Для тех кто много знает - в конце начинается более инфровая часть и технические репорты.
На многих слайдах внизу есть ссылки на статьи/технические блоги.
Небольшой обзор по эффективному обучению и релевантным тематикам для студентов с летней школы.
В начале прикладные материалы + материалы для начинающих.
Для тех кто много знает - в конце начинается более инфровая часть и технические репорты.
На многих слайдах внизу есть ссылки на статьи/технические блоги.
Google Docs
Final efficient training airi 2025
Практические инструменты эффективного обучения Сивцов Данил Инженер-исследователь, AIRI
🔥11🦄1
Как понять, что «тормозит» 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