Чего хотеть от фреймворка инференса?
Первое что приходит в голову - производительности😎
Но сосредоточиться только на ней будет ошибкой
Вот несколько других параметров:
1. Язык реализации. Если у вас малые нейронки или размеры входов, то издержки взаимодействия с питоном будут существенны под нагрузкой и стоит смотреть c++ фреймворки. Если матрицы большие, то, на самом деле, можно вполне пользоваться питоном пока нагрузки не велики (те же llm могут тратить десятки секунд на обработку контекста). Да и сами операции в питон фреймворках реализованы через биндинги С/С++
2. Среда использования. Если вы экспериментируете с составом кластера, и у вас наряду с nvidia картами есть еще и amd/intel/huawei - хорошей идеей будет подумать об одном общем фреймворке с реализацией нужных бекендов
3. Сборка. Просто ли собрать код, загрузить его на сервер и запустить? Контейнер может весить 10-20Гб и загрузка его с диска на рестартах может занимать десятки минут. Если уходить еще ниже на уровень бинарей, то возить с собой все .so библиотеки может быть проблематично. И, кстати, никто не обещал что залинкованная динамически библиотека на сборке не крашнет вам бинарь в неподходящий момент
4. Память. Если ваша нагрузка memory-bound (GPU VRAM переполнена), то имеет смысл смотреть реальную занимаемую память на нагрузке для одного запроса
5. Наличие хаков для нишевых сценариев. Инференсить llm без спекулятивного декодинга, kv cache, квантизаций, батчевания prefill/decode - равно тратить в разы больше ресурсов. В некоторых движках этих фичей может не быть
6. Качество кода. Разные фреймворки написаны с разным отношением. Кто-то пишет интуитивно понятный код, который легко раздебажить, а кто-то пишет все в одном файле на 3к строк и потом с пеной у рта говорит про эффективность (удачи дебажить ошибки в коде nvidia🚬 , но их не поймут, если они напишут не самый оптимальный код). В любом коде будут ошибки, любой будет падать - это просто факт, посмотрите в Release notes на исправленные в патчах ошибки, и вам покажется, что фреймворк вообще своей жизнью живет, иногда новые релизы просто не собираются
Так вот вы либо имеете контроль над кодом и можете на своей стороне сделать патч, либо с синими глазами даунгрейдите версию фреймворка в надежде поймать фикс и ждете исправлений в апстриме
📝 В общем, тут все не так однозначно. И кстати интересная тенденция - чем сложнее система и больше продакшен, тем большей простоты от кода и сборки стараются достичь. Потому что, когда все упадет, спросят с тебя, а не с разработчиков TensorRT
Первое что приходит в голову - производительности
Но сосредоточиться только на ней будет ошибкой
Вот несколько других параметров:
1. Язык реализации. Если у вас малые нейронки или размеры входов, то издержки взаимодействия с питоном будут существенны под нагрузкой и стоит смотреть c++ фреймворки. Если матрицы большие, то, на самом деле, можно вполне пользоваться питоном пока нагрузки не велики (те же llm могут тратить десятки секунд на обработку контекста). Да и сами операции в питон фреймворках реализованы через биндинги С/С++
2. Среда использования. Если вы экспериментируете с составом кластера, и у вас наряду с nvidia картами есть еще и amd/intel/huawei - хорошей идеей будет подумать об одном общем фреймворке с реализацией нужных бекендов
3. Сборка. Просто ли собрать код, загрузить его на сервер и запустить? Контейнер может весить 10-20Гб и загрузка его с диска на рестартах может занимать десятки минут. Если уходить еще ниже на уровень бинарей, то возить с собой все .so библиотеки может быть проблематично. И, кстати, никто не обещал что залинкованная динамически библиотека на сборке не крашнет вам бинарь в неподходящий момент
4. Память. Если ваша нагрузка memory-bound (GPU VRAM переполнена), то имеет смысл смотреть реальную занимаемую память на нагрузке для одного запроса
5. Наличие хаков для нишевых сценариев. Инференсить llm без спекулятивного декодинга, kv cache, квантизаций, батчевания prefill/decode - равно тратить в разы больше ресурсов. В некоторых движках этих фичей может не быть
6. Качество кода. Разные фреймворки написаны с разным отношением. Кто-то пишет интуитивно понятный код, который легко раздебажить, а кто-то пишет все в одном файле на 3к строк и потом с пеной у рта говорит про эффективность (удачи дебажить ошибки в коде nvidia
Так вот вы либо имеете контроль над кодом и можете на своей стороне сделать патч, либо с синими глазами даунгрейдите версию фреймворка в надежде поймать фикс и ждете исправлений в апстриме
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤1
AMD Instinct™ MI325X Accelerators
Новая игрушка от AMD🧸
256Gb видеопамяти на плате - это мощно🌠 И компьют хороший
У nvidia есть свой аналог H200 - там 141Gb (у A100/H100 - 80Gb)
Для кого это и почему это круто?
99% - для ML инженеров на время разработки. Дело в том, что релизы новых моделей, если их не тюнить, часто не влезают в 80Gb (да-да дожились). Либо работают долго
Из моих последних использований:
1. Open-Sora для генерации видео лезет только в 4GPU, если генерить в 720p. У меня получилось уместить с приседаниями, но все же
2. Flux для генерации изображений - генерит одну картинку 30 сек на А100, что не быстро для model-surgery
🏆 Так вот если у тебя есть такая плата - ты на коне. Просто берешь почти любую модель и разворачиваешь за пару минут. Да и компьют быстрый. А не мучаешься с model/sequence/tensor параллелизмом
Для инференса эта штука может быть полезна в контексте LLM с очень большими последовательностями - размеры KV-Cache могут быть оч большими при нагрузке. Но, думаю, врятли кто-то будет особо использовать
Ps:
Мне кажется, что amd уже очень даже конкурентноспособны для AI. У меня чешутся руки прикупить такую карточку и поделать на ней замеры
Ps2:
Мы такие платы пока не получим, H100 и так с скрипом завозят, а эти лимитированы и продаются избранным, не слышал, чтобы у кого-то были
Новая игрушка от AMD
256Gb видеопамяти на плате - это мощно
У nvidia есть свой аналог H200 - там 141Gb (у A100/H100 - 80Gb)
Для кого это и почему это круто?
99% - для ML инженеров на время разработки. Дело в том, что релизы новых моделей, если их не тюнить, часто не влезают в 80Gb (да-да дожились). Либо работают долго
Из моих последних использований:
1. Open-Sora для генерации видео лезет только в 4GPU, если генерить в 720p. У меня получилось уместить с приседаниями, но все же
2. Flux для генерации изображений - генерит одну картинку 30 сек на А100, что не быстро для model-surgery
Для инференса эта штука может быть полезна в контексте LLM с очень большими последовательностями - размеры KV-Cache могут быть оч большими при нагрузке. Но, думаю, врятли кто-то будет особо использовать
Ps:
Мне кажется, что amd уже очень даже конкурентноспособны для AI. У меня чешутся руки прикупить такую карточку и поделать на ней замеры
Ps2:
Мы такие платы пока не получим, H100 и так с скрипом завозят, а эти лимитированы и продаются избранным, не слышал, чтобы у кого-то были
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2
vLLM или алгоритмические ускорения инференса LLM
Тот случай, когда фреймворк инференса выбирается из-за алгоритмических фичей и простоты использования
В чем тут проблема?
При генерации токенов llm имеет две стадии:
1. Prefill - обработка контекста и заполнение KVCache
Compute-bound задача (умножение больших матриц)
2. Decode - генерация новых токенов авторегрессионно (сгенерировали токен, добавили к текущему накопленному промпту, повторили, пока не сгенерируете достаточно)
Memory-bound задача (больше таскаем KVCache и собираем матрицы, чем умножаем)
Получается, GPU недоутилизируется на Decode, а также наивная реализация KV-Cache приводит к переаллокациям (внутренняя фрагментация) или невозможности эффективного исполнения батча запросов
Одно из первых решений - vllm. Его же многие сейчас берут как бейзлайн, благодаря простоте использования.
Python фреймворк с биндингами на кернелы, кстати
От них выступление с картиночками на английском
Статья про PagedAttention
Они не придумали все, есть много похожих статей. Часть фичей по мотивам они сделали и у себя (например, разбиение контекста на чанки)
Основной вклад:
1. Paged attention - делаем страничную виртуальную память для кешей как в OS и провязываем его напрямую в блок внимания. Тот случай, когда аккуратно написанный кернел делает разницу
2. Эффективная реализация батчинга - если KVCache блочен, то ничего не мешает нам батчевать запросы (не нужно физически собирать матрицу батча в последовательную память)
*восстановлен после случайного удаления
Тот случай, когда фреймворк инференса выбирается из-за алгоритмических фичей и простоты использования
В чем тут проблема?
При генерации токенов llm имеет две стадии:
1. Prefill - обработка контекста и заполнение KVCache
Compute-bound задача (умножение больших матриц)
2. Decode - генерация новых токенов авторегрессионно (сгенерировали токен, добавили к текущему накопленному промпту, повторили, пока не сгенерируете достаточно)
Memory-bound задача (больше таскаем KVCache и собираем матрицы, чем умножаем)
Получается, GPU недоутилизируется на Decode, а также наивная реализация KV-Cache приводит к переаллокациям (внутренняя фрагментация) или невозможности эффективного исполнения батча запросов
Одно из первых решений - vllm. Его же многие сейчас берут как бейзлайн, благодаря простоте использования.
Python фреймворк с биндингами на кернелы, кстати
От них выступление с картиночками на английском
Статья про PagedAttention
Они не придумали все, есть много похожих статей. Часть фичей по мотивам они сделали и у себя (например, разбиение контекста на чанки)
Основной вклад:
1. Paged attention - делаем страничную виртуальную память для кешей как в OS и провязываем его напрямую в блок внимания. Тот случай, когда аккуратно написанный кернел делает разницу
2. Эффективная реализация батчинга - если KVCache блочен, то ничего не мешает нам батчевать запросы (не нужно физически собирать матрицу батча в последовательную память)
🔥3
ggml - с++ библиотека тензорных операций
🤩 Написана на базовых и интуитивно понятных абстракциях. Все под чистым cmake (попробуйте пособирать executorch с их buck системой над cmake, например. Мне надоело). И при этом есть широкий выбор бэкендов: cuda, amd hip, huawei ascend, x86, arm
Мне рекомендовали фреймворк в контексте мобильных девайсов. Но, знаете, эта штука просто супер как базовый compute слой для серверного инференса🙂
🚀 Берете любой нативный для вас сетевой фреймворк (хоть внутренний кастом) и в путь - гибкости вы не потеряете
✨ И да, оно очень эффективно работает с памятью, на десятки процентов лучше, чем у условного executorch. Соседняя конкурентная нагрузка скажет спасибо (думаю, в торче память излишне кешируется, либо я что-то не оптимизировал. Но круто, что такая разница из коробки)
Тот самый фреймворк инференса, из-за которого написан пост
Появился как библиотека движка для llama.cpp и whisper.cpp
Если интересно, почитайте пост с hf, скрин с фичами прикрепил
ggml - это некий баланс между "возьмем triton от Nvidia для производительности" (но про кастомизацию забудем) и "нам надо кастом, поэтому пишем сами ядра на cublas и Intrinsics/asm"
И вот на мой взгляд для производительной разработки это сейчас одно из лучших решений
😐 Из минусов - часть операций может быть не реализована эффективно, в любом случае нужны сравнительные замеры, на сколько это критично для ваших моделей. Ну и формат хранения GGUF. Но на hf под популярные модели есть уже сконверченные веса
Мне рекомендовали фреймворк в контексте мобильных девайсов. Но, знаете, эта штука просто супер как базовый compute слой для серверного инференса
Тот самый фреймворк инференса, из-за которого написан пост
Появился как библиотека движка для llama.cpp и whisper.cpp
Если интересно, почитайте пост с hf, скрин с фичами прикрепил
ggml - это некий баланс между "возьмем triton от Nvidia для производительности" (но про кастомизацию забудем) и "нам надо кастом, поэтому пишем сами ядра на cublas и Intrinsics/asm"
И вот на мой взгляд для производительной разработки это сейчас одно из лучших решений
Please open Telegram to view this post
VIEW IN TELEGRAM
🎄4☃3❤3
Поздравляю вас с наступающим Новым годом!
Надеюсь, что 2024 был для вас продуктивным. Пусть 2025 будет еще лучше и принесет больше новых возможностей!
Спасибо, за то, что читаете и комментируете. За год посты стали глубже и качественней благодаря вам
Скоро появится новый контент с замерами, будет круче и полезнее (и, может, даже веселее). Начнем с жизненных мемов, пока не собран сетап
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8☃2🎄2
За последние два года опубликовано много крутых статей по спекулятивному инференсу для llm - собрал из них небольшой обзор
Для поста слишком много информации, поэтому разместил на Хабре:
Обзор алгоритмов спекулятивного инференса для llm
Внутри много полезных ссылок на статьи и код
Кстати, схемы в статье сам рисовал. Как вам формат?
🔥 - Круто, мне помогает быстрее понять идею
🗿 - Мне важен первоисточник, перехожу по всем ссылкам
Для поста слишком много информации, поэтому разместил на Хабре:
Обзор алгоритмов спекулятивного инференса для llm
Внутри много полезных ссылок на статьи и код
Кстати, схемы в статье сам рисовал. Как вам формат?
🔥 - Круто, мне помогает быстрее понять идею
🗿 - Мне важен первоисточник, перехожу по всем ссылкам
Хабр
Алгоритмы спекулятивного инференса LLM
Введение За последние годы качество LLM моделей сильно выросло, методы квантизации стали лучше, а видеокарты мощнее. Тем не менее качество генерации все еще напрямую зависит от размера весов и, как...
🔥9👍3
Добро пожаловать в матрицу?
Сейчас набирает обороты рисерч моделей мира, где вместо отрисовки графики картинку полностью генерирует модель по промптам (архитектуры те же, что у моделей генерации видео)
Рисерчеры постили на старых игрушках
Doom - https://gamengen.github.io/
Minecraft - https://oasis-model.github.io/
Что скорее для забавы
Но Nvidia сегодня выкатила свой фреймворк физичных world моделей. Качество генерации ооч крутое
Code - https://github.com/NVIDIA/Cosmos
Article - https://research.nvidia.com/publication/2025-01_cosmos-world-foundation-model-platform-physical-ai
Кажется, будет появляться больше хороших синтетических датасетов, хоть и за счет тонны компьюта.
Ну и удачи тому чудаку, который будет делать инфренс этих моделей at scale🚬
@deploy_ml
Сейчас набирает обороты рисерч моделей мира, где вместо отрисовки графики картинку полностью генерирует модель по промптам (архитектуры те же, что у моделей генерации видео)
Рисерчеры постили на старых игрушках
Doom - https://gamengen.github.io/
Minecraft - https://oasis-model.github.io/
Что скорее для забавы
Но Nvidia сегодня выкатила свой фреймворк физичных world моделей. Качество генерации ооч крутое
Code - https://github.com/NVIDIA/Cosmos
Article - https://research.nvidia.com/publication/2025-01_cosmos-world-foundation-model-platform-physical-ai
Кажется, будет появляться больше хороших синтетических датасетов, хоть и за счет тонны компьюта.
Ну и удачи тому чудаку, который будет делать инфренс этих моделей at scale
@deploy_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡4
Новые игровые пользовательские GPU, какие они?
Прошел этап анонсов видеокарт - Nvidia, amd и intel зарелизили свои карты нового поколения.
Мы не геймеры, но игровые карты стали best-value-to-money решениями, по крайней мере для инференса. Но сейчас не об этом - сейчас хочу поделиться своим мнением по каждому релизу.
🏆 intel
Классные бюджетные карты за 250$. Они так зашли на старте, что ниже 350-400$ их теперь не купить, а стоки раскупаются быстрее поставок. Думаю, это дело времени, через пару месяцев должно отпрыгнуть к изначальным ценам.
16gb GDDR6 - это круто за свою цену. По слухам, будет еще версия 24Gb. Для компьютерного зрения, даунстрим тасок и прочего, что должно держать нагрузку, кажется, будет хорошим решением.
Для компании intel, находящейся в не очень хорошем состоянии (процессоры серьезно проигрывают борьбу AMD на всех рынках), GPU - непрофильный эксперимент с большим бюджетом. Если бы battlemage не зашли, подразделение могли закрыть полностью в рамках снижения затрат.
🤐 Amd
Тут полный байт, посмотрите комменты под видео с презентации на CES.
Спойлер - гпу там не показали, но есть пару слайдов без бенчмарков.
Кажется, это не капитуляция, и у этого есть объяснение - идет процесс унификации серверных и игровых карт. Будет новая архитектура UDNA в 2026, анонсированная еще в сентябре.
И потому текущее поколение "пропущено" - будут какие-то проходные варианты и amd просто пытается понять, какой выставить цену, чтобы не словить хейта. И если бы они сейчас показали бенчмарки, мог быть антипиар.
И, кстати, тезис "мы за бюджетный сегмент, не будем соревноваться с Nvidia 5090" видимо был пылью в глаза.
Судя по всему еще как будут, просто не успели сделать нормально)
🤑 Nvidia
Из крутого - 32Gb памяти у 5090. Не то чтобы это сделает супер разницу с 24, но сможете втиснуть чуть больше батч на вход.
Дальше классический маркетинг. Видишь слайд "5070 is better than 4090, but cost 549$" и такой ваааааау. Смотришь спеки, а там куда ядер сильно меньше. И вообще у 5090 куда ядер всего на 33% больше чем у 4090. Тут ты напрягаешься, откуда заявленная почти x3 AI производительность? Может из-за почти в 2 раза возросшей пропускной способности GDDR7? Нееее.
Следите за руками. Производительность указана в AITops. Не fp, не bf, не int операций, а вот этого маркетингово чуда. Теперь смотрим в описание и понимаем "fp8 == 4090 AITops == 5090 AITops == fp4". А, как вам финт ушами?
На деле скорость возрастет примерно на 30% в среднем, судя по первым бенчам на играх. Так что расходимся, нас заскамили.
Итог
Intel - молодцы, будем смотреть бенчи на моделях
AMD - терпят до объединения игровых и серверных карт
Nvidia - скамеры, но за 32Gb респект
@deploy_ml
Прошел этап анонсов видеокарт - Nvidia, amd и intel зарелизили свои карты нового поколения.
Мы не геймеры, но игровые карты стали best-value-to-money решениями, по крайней мере для инференса. Но сейчас не об этом - сейчас хочу поделиться своим мнением по каждому релизу.
Классные бюджетные карты за 250$. Они так зашли на старте, что ниже 350-400$ их теперь не купить, а стоки раскупаются быстрее поставок. Думаю, это дело времени, через пару месяцев должно отпрыгнуть к изначальным ценам.
16gb GDDR6 - это круто за свою цену. По слухам, будет еще версия 24Gb. Для компьютерного зрения, даунстрим тасок и прочего, что должно держать нагрузку, кажется, будет хорошим решением.
Для компании intel, находящейся в не очень хорошем состоянии (процессоры серьезно проигрывают борьбу AMD на всех рынках), GPU - непрофильный эксперимент с большим бюджетом. Если бы battlemage не зашли, подразделение могли закрыть полностью в рамках снижения затрат.
Тут полный байт, посмотрите комменты под видео с презентации на CES.
Спойлер - гпу там не показали, но есть пару слайдов без бенчмарков.
Кажется, это не капитуляция, и у этого есть объяснение - идет процесс унификации серверных и игровых карт. Будет новая архитектура UDNA в 2026, анонсированная еще в сентябре.
И потому текущее поколение "пропущено" - будут какие-то проходные варианты и amd просто пытается понять, какой выставить цену, чтобы не словить хейта. И если бы они сейчас показали бенчмарки, мог быть антипиар.
И, кстати, тезис "мы за бюджетный сегмент, не будем соревноваться с Nvidia 5090" видимо был пылью в глаза.
Судя по всему еще как будут, просто не успели сделать нормально)
Из крутого - 32Gb памяти у 5090. Не то чтобы это сделает супер разницу с 24, но сможете втиснуть чуть больше батч на вход.
Дальше классический маркетинг. Видишь слайд "5070 is better than 4090, but cost 549$" и такой ваааааау. Смотришь спеки, а там куда ядер сильно меньше. И вообще у 5090 куда ядер всего на 33% больше чем у 4090. Тут ты напрягаешься, откуда заявленная почти x3 AI производительность? Может из-за почти в 2 раза возросшей пропускной способности GDDR7? Нееее.
Следите за руками. Производительность указана в AITops. Не fp, не bf, не int операций, а вот этого маркетингово чуда. Теперь смотрим в описание и понимаем "fp8 == 4090 AITops == 5090 AITops == fp4". А, как вам финт ушами?
На деле скорость возрастет примерно на 30% в среднем, судя по первым бенчам на играх. Так что расходимся, нас заскамили.
Итог
Intel - молодцы, будем смотреть бенчи на моделях
AMD - терпят до объединения игровых и серверных карт
Nvidia - скамеры, но за 32Gb респект
@deploy_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
😁5👍2🔥2
Стандартизация - это тяжело. Или в чем проблема mlops
Вчера пришел друг с интересной проблемой
— Как экспортировать из pytorch в onnxruntime трансформерную модель?
— Ну как, берешь, экспортируешь
— Так оно без кастомного трансформерного слоя будет, а нам надо. Я бы готов был согласиться на flash_attention, но трейс будет без него
Дальше я просто попытался эффективно перенести torch.nn.functional.scaled_dot_product_attention в onnx и onnxruntime
Пару запросов и мы находим кернел в onnxrt для атеншена
Но если просто сделать torch.onnx.export, то вы получите честный граф со всеми matmul из формулы, что не приближает к результату
Дальше в похожих issue [еще одно] в onnx тебя отправляют в graph optimizer или в написание кастомного слоя
В graph optimizer есть таки AttentionFusing. Я его попробовал, получил разлет версий и спустя 30 минут смог таки скомпилить слой и не уронить оптимизатор графа
Но на выходе я получил просто fused matmul. Ну не превратиться он волшебным образом во что-то внятное в рантайме. Да и руками это не выпарсить в код обратно
Таким образом мы не можем без написания кастомного слоя перенести красиво в инференс обычную операцию внимания. А еще, пока я подгонял версии torch и onnxscript чтобы оно не разваливалось - результирующий граф жил своей жизнью (что будет и при ваших обновлениях библиотек)
Получается train, mlops, inference - выбери два, которые будут у тебя нормально сделаны
train - забить нельзя, команда потеряет скорость в экспериментах и нервы
inference - нельзя, потому что это эффективность, надежность и операционные затраты бизнеса
mlops при таком подходе остается быть мостиком из костылей
Ps:друг написал свою конвертацию атеншена через autograd. Не красиво, но задача решена
@deploy_ml
Вчера пришел друг с интересной проблемой
— Как экспортировать из pytorch в onnxruntime трансформерную модель?
— Ну как, берешь, экспортируешь
— Так оно без кастомного трансформерного слоя будет, а нам надо. Я бы готов был согласиться на flash_attention, но трейс будет без него
Дальше я просто попытался эффективно перенести torch.nn.functional.scaled_dot_product_attention в onnx и onnxruntime
Пару запросов и мы находим кернел в onnxrt для атеншена
Но если просто сделать torch.onnx.export, то вы получите честный граф со всеми matmul из формулы, что не приближает к результату
Дальше в похожих issue [еще одно] в onnx тебя отправляют в graph optimizer или в написание кастомного слоя
В graph optimizer есть таки AttentionFusing. Я его попробовал, получил разлет версий и спустя 30 минут смог таки скомпилить слой и не уронить оптимизатор графа
Но на выходе я получил просто fused matmul. Ну не превратиться он волшебным образом во что-то внятное в рантайме. Да и руками это не выпарсить в код обратно
Таким образом мы не можем без написания кастомного слоя перенести красиво в инференс обычную операцию внимания. А еще, пока я подгонял версии torch и onnxscript чтобы оно не разваливалось - результирующий граф жил своей жизнью (что будет и при ваших обновлениях библиотек)
Получается train, mlops, inference - выбери два, которые будут у тебя нормально сделаны
train - забить нельзя, команда потеряет скорость в экспериментах и нервы
inference - нельзя, потому что это эффективность, надежность и операционные затраты бизнеса
mlops при таком подходе остается быть мостиком из костылей
Ps:
@deploy_ml
😁7🌚2👍1🥴1
Пришло время обновить интро 👋
Меня зовут Данил, я автор этого канала. Работаю в rnd, занимаюсь исследованиями в ML инфре. Пишу на с++ и python, еще умею в go/rust. Работал в rnd командах облака и нейросетевой инфраструктуре контекстной рекламы
Чем занимаюсь:
1. Архитектурю ml продукты и системы
2. Поднимаю инференс
3. Продираюсь через библиотеки с эффективнымиджунглями реализациями
4. Подбираю фреймворки, библиотеки и базы под конкретные задачи
Что почитать на канале:
🚀 Инференс
- ggml - лучшая библиотека для реализации серверного инференса
- inference, train, mlops - выбери два, сломай лицо об третье
- Как выбирать движок инференса
🖥 Алгоритмы
- Ускорение LLM через PagedAttention и батчинг
- Спекулятивный декодинг - как маленькой llm ускорить громадную
⚙️ Железки
- AMD Instinct™ MI325X - мега gpu на 256Gb памяти
- Будущее серверных железяк
- Какие карты использовать для инференса
Если есть идеи по темам постов, вопросы или обратная связь, пишите в комменты или в личку @svt_danny
Спасибо что подписываетесь и читаете ❤️
Меня зовут Данил, я автор этого канала. Работаю в rnd, занимаюсь исследованиями в ML инфре. Пишу на с++ и python, еще умею в go/rust. Работал в rnd командах облака и нейросетевой инфраструктуре контекстной рекламы
Чем занимаюсь:
1. Архитектурю ml продукты и системы
2. Поднимаю инференс
3. Продираюсь через библиотеки с эффективными
4. Подбираю фреймворки, библиотеки и базы под конкретные задачи
Что почитать на канале:
- ggml - лучшая библиотека для реализации серверного инференса
- inference, train, mlops - выбери два, сломай лицо об третье
- Как выбирать движок инференса
🖥 Алгоритмы
- Ускорение LLM через PagedAttention и батчинг
- Спекулятивный декодинг - как маленькой llm ускорить громадную
- AMD Instinct™ MI325X - мега gpu на 256Gb памяти
- Будущее серверных железяк
- Какие карты использовать для инференса
Если есть идеи по темам постов, вопросы или обратная связь, пишите в комменты или в личку @svt_danny
Спасибо что подписываетесь и читаете ❤️
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8🔥6💯1
Обзор баз данных за 2024
Каждый год обновляется профессором CMU Andy Pavlo. Оригинальная статья
Почему-то особо про векторные базы не написал. На них сейчас особый хайп. Но мы это отдельно рассмотрим
Кратко события за год:
1. Redis поменял лицензию на смесь Redis Source Available License and MongoDB SSPL
Хотят больше зарабатывать и боятся облаков, которые очень много зарабатывают и не делятся прибылью
Сообщество обозлилось и начало делать форки. Самые известные - Valkey и Redict. На сколько я слышу, у нас больше пересели на Valkey
Еще есть dragonfly - по многочисленным отзывам написан очень круто и намного лучше держит нагрузку
Elasticsearch вернул опенсурс лицензию, после нескольких лет попыток противостоять AWS. Кажется, редис ждет та же участь
2. Баталии Databricks и Snowflake
Обе компании выросли до лидеров на огромном конкурентном рынке хранения и обработки данных. Оба, кстати, стартовали из исследователей (phd thesis M.Zukowski - snowflake. M.Zaharia - Databricks)
Теперь цапаются друг на друга, игнорируя все вокруг и тратя огромные ресурсы. Сравниваются стоимостями и производительностями сервисов, а также качеством своих llm.
Тем временем Databricks поднял раунд на 10млрд $, чтобы выкупить акции у сотрудников, которыедемотивированны ждут обещанного IPO
3. Интеграция DuckDB повсюду
Анализ Snowflake и Redshift показывает, что средний аналитический запрос затрагивает 100Mb данных, для чего достаточно простого движка. DuckDB как раз имеет хорошую встраиваимость, потому полюбился для реализации аналитических плагинов для postgres
Еще один игрок, решающий хорошо схожую задачу - clickhouse. Энди пишет, что раньше его было сложно поднимать и настраивать, а также не хватало гибкости, потому duckdb популярнее в контексте расширения баз (на малых среднестатистических нагрузках удобство важнее, тем более в контексте встраиваемости)
4. Новая коммерческая база - CedarDB
Основана на коде Umbra, разрабатываемой Томасом Ньюманом. Но он хочет продолжать работать над ней как над исследовательским проектом, а не строить очередной стартап. При этом не стал мешать одному из своих phd студентов форкнуть код и открыть стартап под названием CedarDB
@deploy_ml
Каждый год обновляется профессором CMU Andy Pavlo. Оригинальная статья
Почему-то особо про векторные базы не написал. На них сейчас особый хайп. Но мы это отдельно рассмотрим
Кратко события за год:
1. Redis поменял лицензию на смесь Redis Source Available License and MongoDB SSPL
Хотят больше зарабатывать и боятся облаков, которые очень много зарабатывают и не делятся прибылью
Сообщество обозлилось и начало делать форки. Самые известные - Valkey и Redict. На сколько я слышу, у нас больше пересели на Valkey
Еще есть dragonfly - по многочисленным отзывам написан очень круто и намного лучше держит нагрузку
Elasticsearch вернул опенсурс лицензию, после нескольких лет попыток противостоять AWS. Кажется, редис ждет та же участь
2. Баталии Databricks и Snowflake
Обе компании выросли до лидеров на огромном конкурентном рынке хранения и обработки данных. Оба, кстати, стартовали из исследователей (phd thesis M.Zukowski - snowflake. M.Zaharia - Databricks)
Теперь цапаются друг на друга, игнорируя все вокруг и тратя огромные ресурсы. Сравниваются стоимостями и производительностями сервисов, а также качеством своих llm.
Тем временем Databricks поднял раунд на 10млрд $, чтобы выкупить акции у сотрудников, которые
3. Интеграция DuckDB повсюду
Анализ Snowflake и Redshift показывает, что средний аналитический запрос затрагивает 100Mb данных, для чего достаточно простого движка. DuckDB как раз имеет хорошую встраиваимость, потому полюбился для реализации аналитических плагинов для postgres
Еще один игрок, решающий хорошо схожую задачу - clickhouse. Энди пишет, что раньше его было сложно поднимать и настраивать, а также не хватало гибкости, потому duckdb популярнее в контексте расширения баз (на малых среднестатистических нагрузках удобство важнее, тем более в контексте встраиваемости)
4. Новая коммерческая база - CedarDB
Основана на коде Umbra, разрабатываемой Томасом Ньюманом. Но он хочет продолжать работать над ней как над исследовательским проектом, а не строить очередной стартап. При этом не стал мешать одному из своих phd студентов форкнуть код и открыть стартап под названием CedarDB
@deploy_ml
❤3🔥2
Подборка статей MLSys 2024 (part 1)
Давний подписчик предложил добавить подборки по статьям и фреймворкам.
У меня большая кубышка такого контента😏 . Давайте начнем с более практичных вариантов
MLSys - хорошая конференция, с очень качественными принятыми статьями. Если что, в 2024 приняли только 37 статей
Полный список
Что запомнилось мне:
1. AWQ: Activation-aware Weight Quantization for On-Device LLM Compression and Acceleration [poster][paper] - best paper award
Одна из самых хайповых квантизаций. Поддержана во всех крутых фреймворках
2. Q-Hitter: A Better Token Oracle for Efficient LLM Inference via Sparse-Quantized KV Cache [poster][paper]
На больших контекстах decode становится memory-bound. В статье - как эффективно совместить разрежение и квантизацию KVCache
3. Punica: Multi-Tenant LoRA Serving [poster][paper]
Развили идею батчевания lora адаптеров на планирование по всему кластеру
4. DiffusionPipe: Training Large Diffusion Models with Efficient Pipelines [poster][paper]
Минимизируют простои ресурсов через аккуратное планирование обучаемых и замороженных частей пайплайна
5. SiDA: Sparsity-Inspired Data-Aware Serving for Efficient and Scalable Large Mixture-of-Experts Models [poster][paper]
MoE модели активируют небольшую часть весов для инференса каждого запроса. Это же преимущество приводит к проблемам с эффективным инференсом в проде, которые решают в статье - нужно уметь эффективно управлять доступной RAM и GPU памятью
6. Disaggregated Multi-Tower: Topology-aware Modeling Technique for Efficient Large Scale Recommendation [poster][paper]
Кластера обучения не однородны по топологии транспорта. В статье адаптируют большую и плоскую нейросетевую рекомендательную модель к обучению на масштабах датацентра
@deploy_ml
Давний подписчик предложил добавить подборки по статьям и фреймворкам.
У меня большая кубышка такого контента
MLSys - хорошая конференция, с очень качественными принятыми статьями. Если что, в 2024 приняли только 37 статей
Полный список
Что запомнилось мне:
1. AWQ: Activation-aware Weight Quantization for On-Device LLM Compression and Acceleration [poster][paper] - best paper award
Одна из самых хайповых квантизаций. Поддержана во всех крутых фреймворках
2. Q-Hitter: A Better Token Oracle for Efficient LLM Inference via Sparse-Quantized KV Cache [poster][paper]
На больших контекстах decode становится memory-bound. В статье - как эффективно совместить разрежение и квантизацию KVCache
3. Punica: Multi-Tenant LoRA Serving [poster][paper]
Развили идею батчевания lora адаптеров на планирование по всему кластеру
4. DiffusionPipe: Training Large Diffusion Models with Efficient Pipelines [poster][paper]
Минимизируют простои ресурсов через аккуратное планирование обучаемых и замороженных частей пайплайна
5. SiDA: Sparsity-Inspired Data-Aware Serving for Efficient and Scalable Large Mixture-of-Experts Models [poster][paper]
MoE модели активируют небольшую часть весов для инференса каждого запроса. Это же преимущество приводит к проблемам с эффективным инференсом в проде, которые решают в статье - нужно уметь эффективно управлять доступной RAM и GPU памятью
6. Disaggregated Multi-Tower: Topology-aware Modeling Technique for Efficient Large Scale Recommendation [poster][paper]
Кластера обучения не однородны по топологии транспорта. В статье адаптируют большую и плоскую нейросетевую рекомендательную модель к обучению на масштабах датацентра
@deploy_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤2
Дистилляты deepseek r1 и жизненные проблемы
Я задал одни и те же вопросы разным дистиллятам deepseek r1:
qwen 1.5b, qwen 7b, llama 8b, qwen 32b - именно эти модели, скорее всего, будут интересны большинству на практике.
Спросил бытовое: как приготовить окрошку, поменять пробитую шину и выжить в лесу. В картинках можете сравнить, как они справились⬇️ (на картинках - qwen32b, в комментах - другие модели)
Вспомнился давний мем с Зоей Вексельштейн:
Какая у вашей модели reasoning? Как она performing?
А как быстро запустить инференс таких моделей - смотрите в моем мини туториале на habr
@deploy_ml
Я задал одни и те же вопросы разным дистиллятам deepseek r1:
qwen 1.5b, qwen 7b, llama 8b, qwen 32b - именно эти модели, скорее всего, будут интересны большинству на практике.
Спросил бытовое: как приготовить окрошку, поменять пробитую шину и выжить в лесу. В картинках можете сравнить, как они справились
Вспомнился давний мем с Зоей Вексельштейн:
Какая у вашей модели reasoning? Как она performing?
@deploy_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4😁3👍2❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Что запустить на AMD GPU?
Обзавелся карточкой amd 6800xt 16Gb
rdna2, gfx1030 - актуальный rocm [compatibility matrix]
Планирую позапускать продовые фреймворки и разные модели. Что было бы интересно больше? ⬇️
Если есть какие-то еще идеи - пишите в комменты или лс
Обзавелся карточкой amd 6800xt 16Gb
rdna2, gfx1030 - актуальный rocm [compatibility matrix]
Планирую позапускать продовые фреймворки и разные модели. Что было бы интересно больше? ⬇️
Если есть какие-то еще идеи - пишите в комменты или лс
🔥7👌2❤1🤩1👾1
Что было бы интереснее позапускать?
Anonymous Poll
41%
Дообучение моделей на torch/jax
43%
Инференс llm моделей
35%
Распознавание голоса
30%
Детекция, сегментация, трекинг и тд
24%
Генерация картинок/видео
19%
Bert модели для прода
3%
Напишу в комменты/лс
Подборка статей MLSys 2024 (part 2)
Вторая часть классных статей c mlsys
[Часть 1] [Сайт конференции]
1. Keyformer: KV Cache reduction through key tokens selection for Efficient Generative Inference [poster][paper]
Генерация новых токенов в llm становится memory-bound при больших контекстах (грузим большие KV-кеши, Q - размерности (1,hidden_dim)). В статье предлагают алгоритм, выкидывающий некоторые токены из кешей. Это портит распределение выхода внимания, потому вместо softmax для выбора токенов используют вероятностный softmax с температурой.
2. Atom: Low-Bit Quantization for Efficient and Accurate LLM Serving [poster][paper]
Квантизуют веса и активации. Выделяют выбросы в активациях и квантизуют их отдельно в большей точности. Издержки прячут объединяя сжатие с предыдущим оператором, а расжатие - в fused gemm.
3. FlashDecoding++: Faster Large Language Model Inference with Asynchronization, Flat GEMM Optimization, and Heuristics [poster][paper]
Низкоуровневые оптимизации. Меняют способ вычисления софтмакса, чтобы делать меньше синхронизаций. Вместо батчевания prefill/decode пишут ядро матричного умножения с наслоением загрузки и вычисления тайлов в разделяемую память.
4. Lancet: Accelerating Mixture-of-Experts Training by Overlapping Weight Gradient Computation and All-to-All Communication [poster][paper]
Батчевание вычислений приводит к повышению производительности. В случае инференса MoE моделей часто используют expert-параллелизм (эксперты одного слоя хранятся на разных видеокартах). Соответственно, токены нужно распределить по экспертам, а потом собрать обратно. В статье переделывают реализацию MoE слоя так, чтобы вычисления и коммуникации между видеокартами наслаивались.
5. Prompt Cache: Modular Attention Reuse for Low-Latency Inference [poster][paper]
Часто промпт к LLM состоит из контекста (документы, код, картинки) и наших вопросов. Например, в rag и ассистентах написания кода. Каждый раз вычислять кеши не эффективно. Переиспользовать кеши между запросами не эквивалентно их перевычислению, хотя может сойти с рук, если документы независимы. В статье предлагают решение через структуризацию запроса. Качество сохраняется на уровне исходной модели в 90% случаев. Сайд эффект - для большого числа документов матрица внимания становится блочной, а память под кеши ассимптотически линейной.
6. SLoRA: Scalable Serving of Thousands of LoRA Adapters [poster][paper]
Low rank adapter - популярный способ дешево дообучить модель. Однако если попытаться делать инференс большого числа адаптеров для одной модели - получится неэффективная реализация. Все адаптеры в память видеокарты не влезут, а при неаккуратной подгрузке можно улететь в OOM. В статье предлагают аккуратно батчевать запросы: ветка с основной моделью может батчеваться как обычно, адаптеры - через group gemm, а подгружать слои можно наперед только для активных адаптеров.
@deploy_ml
Вторая часть классных статей c mlsys
[Часть 1] [Сайт конференции]
1. Keyformer: KV Cache reduction through key tokens selection for Efficient Generative Inference [poster][paper]
Генерация новых токенов в llm становится memory-bound при больших контекстах (грузим большие KV-кеши, Q - размерности (1,hidden_dim)). В статье предлагают алгоритм, выкидывающий некоторые токены из кешей. Это портит распределение выхода внимания, потому вместо softmax для выбора токенов используют вероятностный softmax с температурой.
2. Atom: Low-Bit Quantization for Efficient and Accurate LLM Serving [poster][paper]
Квантизуют веса и активации. Выделяют выбросы в активациях и квантизуют их отдельно в большей точности. Издержки прячут объединяя сжатие с предыдущим оператором, а расжатие - в fused gemm.
3. FlashDecoding++: Faster Large Language Model Inference with Asynchronization, Flat GEMM Optimization, and Heuristics [poster][paper]
Низкоуровневые оптимизации. Меняют способ вычисления софтмакса, чтобы делать меньше синхронизаций. Вместо батчевания prefill/decode пишут ядро матричного умножения с наслоением загрузки и вычисления тайлов в разделяемую память.
4. Lancet: Accelerating Mixture-of-Experts Training by Overlapping Weight Gradient Computation and All-to-All Communication [poster][paper]
Батчевание вычислений приводит к повышению производительности. В случае инференса MoE моделей часто используют expert-параллелизм (эксперты одного слоя хранятся на разных видеокартах). Соответственно, токены нужно распределить по экспертам, а потом собрать обратно. В статье переделывают реализацию MoE слоя так, чтобы вычисления и коммуникации между видеокартами наслаивались.
5. Prompt Cache: Modular Attention Reuse for Low-Latency Inference [poster][paper]
Часто промпт к LLM состоит из контекста (документы, код, картинки) и наших вопросов. Например, в rag и ассистентах написания кода. Каждый раз вычислять кеши не эффективно. Переиспользовать кеши между запросами не эквивалентно их перевычислению, хотя может сойти с рук, если документы независимы. В статье предлагают решение через структуризацию запроса. Качество сохраняется на уровне исходной модели в 90% случаев. Сайд эффект - для большого числа документов матрица внимания становится блочной, а память под кеши ассимптотически линейной.
6. SLoRA: Scalable Serving of Thousands of LoRA Adapters [poster][paper]
Low rank adapter - популярный способ дешево дообучить модель. Однако если попытаться делать инференс большого числа адаптеров для одной модели - получится неэффективная реализация. Все адаптеры в память видеокарты не влезут, а при неаккуратной подгрузке можно улететь в OOM. В статье предлагают аккуратно батчевать запросы: ветка с основной моделью может батчеваться как обычно, адаптеры - через group gemm, а подгружать слои можно наперед только для активных адаптеров.
@deploy_ml
🔥8❤1
Релизы ускорений llm от DeepSeek
Когда был хайп вокруг v3/r1, все удивлялись малой стоимости обучения модели (даже при учете того, что это была стоимость финальных запусков).
Тогда в техническом репорте были заявлены две крутые вещи:
1. MLA слой внимания (kv головы в пониженной размерности. Снижается размер kv-cache).
2. Эффективная реализация MoE с эксперт параллелизмом.
И вот они вышли в мир:
1. FlashMLA [github]
2. DeepEP для MoE [github]
Уже присматриваюсь✏️ .
Думал, что пересылку в DeepEP реализуют через openucx. Но нет, на nvshmem
@deploy_ml
Когда был хайп вокруг v3/r1, все удивлялись малой стоимости обучения модели (даже при учете того, что это была стоимость финальных запусков).
Тогда в техническом репорте были заявлены две крутые вещи:
1. MLA слой внимания (kv головы в пониженной размерности. Снижается размер kv-cache).
2. Эффективная реализация MoE с эксперт параллелизмом.
И вот они вышли в мир:
1. FlashMLA [github]
2. DeepEP для MoE [github]
Уже присматриваюсь
Думал, что пересылку в DeepEP реализуют через openucx. Но нет, на nvshmem
@deploy_ml
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6