Diagonal Batching Unlocks Parallelism in Recurrent Memory Transformers for Long Contexts
[huggingface][arxiv][code]
Выложили статью по оптимизации рекуррентного линейного трансформера (ARMT).
Мы оптимизировали вычисление графа линейного трансформера ARMT. С нашим методом он масштабируется практически как простое увеличение батча на практичных размерах сегментов.
В сочетании с малым использованием памяти (25МБ против 4ГБ для 128к контекста) можно утилизировать современные GPU без сложных техник типа пайплайнинга и одновременно обрабатывать больше запросов.
Будем рады поддержке в виде апвоутов на HF🙈
Нам чуть-чуть до верха рейтинга, проголосовать можно на странице
@deploy_ml
[huggingface][arxiv][code]
Выложили статью по оптимизации рекуррентного линейного трансформера (ARMT).
Мы оптимизировали вычисление графа линейного трансформера ARMT. С нашим методом он масштабируется практически как простое увеличение батча на практичных размерах сегментов.
В сочетании с малым использованием памяти (25МБ против 4ГБ для 128к контекста) можно утилизировать современные GPU без сложных техник типа пайплайнинга и одновременно обрабатывать больше запросов.
Будем рады поддержке в виде апвоутов на HF
Нам чуть-чуть до верха рейтинга, проголосовать можно на странице
@deploy_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8🏆2❤🔥1👍1
Зачем нужен бизнес-сценарий при нагрузочном тестировании?
Когда 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
🔥4⚡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
🔥10🦄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
😁6🔥4💯3