Что запустить на AMD GPU?

Обзавелся карточкой amd 6800xt 16Gb
rdna2, gfx1030 - актуальный rocm [compatibility matrix]

Планирую позапускать продовые фреймворки и разные модели. Что было бы интересно больше? ⬇️
Если есть какие-то еще идеи - пишите в комменты или лс

Подборка статей 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

Использование llm для кода и их деплой

С недавнего времени начал использовать llm кодера для работы*.
Супер крутая тема, если правильно применять. В моем случае у каждого эксперимента кодовая база как правило своя, а код надо писать как можно быстрее.

Свои наблюдения сформировал в статью на habr. Там же есть ссылки на reddit и LessWrong, где можно почитать мнения других людей.

*на самом деле мне уже 3 месяца руководитель вдалбливал, что это тема. Так что я совсем не ранний адоптер.

Стек вычислений DeepSeek

👋 Помните неделю opensource от DeepSeek?
Нарисовал схему, как связаны между собой компоненты системы. По всем core и thrid-party компонентам добавил кликабельные ссылки на код или доку.

📌 Прилагаю:
- PDF-схема во вложении
- Интерактивная версия по ссылке

Еще полезно прочитать обзор DeepSeek на систему с 6-го дня релизов.

@deploy_ml

Оптимизация матриц под AMD

Считается, что карты amd имеют нестабильный софт. Но конкретики я не видел. Разве что мне совсем не понравились замеры coder llm, которые я делал в статье.

Большую часть вычислений в нейросети занимают матричные умножения. Все остальное в сумме дает <10%, если не брать большие контексты.

Недавно вышла интересная статья бывшего сотрудника AMD, где он ускорил GEMM в 1.6 раз относительно rocBLAS.
По сути, все сводится к тому, что rocBLAS не умеет в v_dual_fmac_f32, хотя эта инструкция доступна с RDNA3 (2022 год релиза!) и использует только v_fmac_f32.

Аналогичная статья есть и для CUDA. За исключением, что там было достигнуто только 93% производительности cuBLAS.

Достаточно большой камень в огород AMD, учитывая, что от GEMM напрямую зависит утилизация GPU.

@deploy_ml

Системный дизайн от ClickHouse

Как rust в c++ внедряли от Алексея Миловидова - СТО СlickHouse.
В статье в формате "проблема-решение" последовательно задеты все основные компоненты системы:
кодовая база, CLI, сборка и кросс-компиляция, дистрибуция и линковка зависимостей, CICD, профилировка, санитайзеры, фаззеры - все со ссылками на PR с кодом.

Хорошая статья для понимания дизайна инфры. И так как многие инфраструктурные ML-инструменты (помимо ClickHouse) — такие же бинари на C/C++/Rust/Go, то понимание устройства ClickHouse хорошо перекладывается на другие системы.

Отдельно круто, что СТО открыто говорит, почему захотели внедрить rust, в каких местах неожиданно сломалось, и в какой последовательности разгребали.

@deploy_ml

Судя по моим статьям и постам - MLOps особо интересен, а за последний год стал особо популярным. И в основном вопросы “как правильно?“ и “что внедрить?“
А я откуда знаю?
Давайте попробуем разобраться

Написал статью на хабр по следам карты MLOps

Оптимизации генерации токенов нейросетей

Пересмотрел статьи с ICLR 2025 и собрал статьи по эффективным нейросетям.
Начнём с авторегрессионного декодирования — спекулятивный декодинг и другие методы всё ещё активно развиваются.

Если не понимаете, зачем это нужно — у меня есть разбор на Habr.

1. DeFT: Decoding with Flash Tree-attention for Efficient Tree-structured LLM Inference
[oral presentation][paper]
При ризонинге (tree-of-thought) и спекулятивном декодинге с генерацией нескольких токенов сразу (как у Medusa) возникает древообразная структура новых токенов. Из-за этого наивная схема вычисления будет загружать общий префикс KV кэшей много раз.

В статье попилили KV кэш на блоки, выпрямили дерево и блочно эффективно генерируют токены, убирая повторные загрузки кеша из VRAM.

2. Faster Cascades via Speculative Decoding
[poster][paper]
Помимо спекулятивного декодинга, есть еще спекулятивные каскады - драфт модель целиком используется для генерации. У них нет верификации, а токены принимаются на основе эвристик (например, уверенности draft модели в следующем токене).

В статье совместили два подхода. Получился спекулятивный декодинг с критериями принятия токенов из каскадов.

3. Judge Decoding: Faster Speculative Sampling Requires Going Beyond Model Alignment
[paper]
Спекулятивный декодинг сравнивает схожесть распределений выхода draft и base моделей, а не правильность токенов в определенном контексте. Из-за этого много токенов отклоняется, даже если они вполне корректны.

В статье авторы дообучили небольшую Judge head на классификацию правильности токена. И заменили критерий принятия: base_model_accept(spec_tokens) OR judge_accept(spec_tokens).
Метрики качества в том же домене не проседают, количество принятых токенов (а значит и ускорение) становится больше.

4. Multi-Draft Speculative Sampling: Canonical Decomposition and Theoretical Limits
[paper]
В спекулятивном декодинге в основном используют одну draft модель. Для нескольких моделей были теоретические выкладки, но без конкретных правил.

В статье выводится формула оптимального критерия принятия для нескольких моделей. Нужно решить LP задачу, где сложность - квадрат размера словаря.
Для упрощения они предлагают Truncated LP схему, где большая часть параметров выставляется в 1 и сводит задачу к настраиваемой сложности s^2.
Количество принятых токенов растет, но замеров ускорения не увидел.

@deploy_ml

Куда развиваются серверные GPU?

Серверные GPU превращаются в супер-вычислители.
Вот как меняются характеристики от поколения к поколению у NVIDIA:
1. Шина CPU<->GPU: PCIe → SXM → NVLink C2C
2. Память: 32 GB (V100) → 80 GB (H100) → 192 GB (B200)
3. NVLink: 600 (A100) → 900 (H100) → 1800 (GB300) Gb/s [link]
4. NVLink full-mesh стойки: NVL72
5. Датацентровая сеть: 200Gb/s infiniband -> 400Gb/s BlueField

Все эти улучшения идут в том числе за счет увеличения тепла:
1. 450Watt A100 SXM -> 700Watt on B200 SXM
2. 6500Watt A100 DGX -> 10200Watt B200 DGX

Как это влияет на сервера и датацентры?

1. Air -> Liquid.
DGX H-серии были последними, что использовали воздушное охлаждение.
GPU B-серии требуют жидкостного охлаждения — иначе невозможно обеспечить плотность и мощность.
Хотя данная проблема появилась раньше, когда начали пытаться уместить 4-8х 4090 в 4U короб.

2. Direct-to-Chip (D2C) охлаждение с водоблоками + контур вывода тепла наружу.
Контур отвода тепла от стоек и контур вывода тепла наружу. Уже сейчас есть выбор серверов с D2C и стартапы, строящие системы охлаждения под ключ.

3. Возможное развитие иммерсивного охлаждения.
Это когда все ваши сервера круглосуточно погружены в ванну с диэлектриком.
Потенциал есть, заявляют лучшую PUE (Power Usage Effectiveness) до 1.02 (где 1.0 - идеально), но массовое внедрение сдерживается практическими ограничениями.

4. Проприетарные стойки (DGX, NVL72).
Экономически оправданы только при полной загрузке. Требуют специфичной инфраструктуры и часто не совместимы с обычными датацентрами.

5. Архитектура ЦоД меняется
Серверов в помещении становится меньше, появляются острова GPU и больше вспомогательной инфраструктуры вокруг. Больше веса, давления, новые требования к зданию и инженерным системам.

На изучить:
1. EdgeConneX - Impacts of Introducing Liquid Cooling into Data Center Infrastructure
2. Schneider Electric - Navigating Liquid Cooling Architectures for Data Centers with AI Workloads
3. Schneider Electric - The Different Technologies for Cooling Data Centers
4. CoolIT Systems - The Impact of Liquid Cooling Technology in AI-Era Data Centers

@deploy_ml

Зачем нужен бизнес-сценарий при нагрузочном тестировании?

Когда MVP нового функционала разработан, часто инженеры теряются при постановке задачи нагрузочного тестирования: не ясно, как и что тестировать, как добиться репрезентативности.
Причина в том, что производительность сильно зависит от конкретных сценариев использования и взаимодействия компонент. Общей картины обычно у большинства нет, а сложные коммуникации технари не любят.

Например, для инференса LLM реальны такие сценарии:
1. Короткие запросы,
2. RAG с файлами разного размера,
3. Длинное во времени интерактивное взаимодействие (с офлоадингом KV кешей),
4. Редкие запросы к разным моделям (с офлоадингом весов моделей),
5. Мульти-модельный деплой и деплой модели с большим количеством LoRA-адаптеров.

Каждый сценарий требует отдельных профилей нагрузки (размер контекста, паттерн обращения) и выявляет свои узкие места. End2End-тесты помогают обнаружить эти проблемы заранее, прежде чем о них сообщат пользователи.

Это касается не только инференса, но и любых компонентов: кешей, баз данных, cicd. Узкое место не всегда очевидно — это может быть медленная авторизация, сброс долгих запросов или ошибки взаимодействия микросервисов команд.

Без понимания бизнес-задачи сетапы выбираются как-нибудь.
В итоге команда рискует исправлять не то, что действительно важно.

@deploy_ml

Обогнали, но "кого?" и "как?". Новые сетевые карточки 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

Замеры MultiLoRA для оффлайн/асинхронного инференса

Опубликовал статью на habr по сравнению функционала MultiLoRA в vllm и TensorRT-LLM.
Интересно, что в релизных докерах результат не в ту сторону, которую вы могли бы подумать - vllm на всех сетапах круче*.
Думал, что дело в настройках TensorRT-LLM, ускорил в 1.2-1.5 раз, но vllm оно так и не догнало (на графиках и табличках замеры уже с оптимизацией)

*сравниваются python3 обертки в сетапе оффлайн/асинхронного инференса. Без интерактивности (потому без time-to-first-token) и сетевой обвязки.

@deploy_ml

А вот и слайды.
Небольшой обзор по эффективному обучению и релевантным тематикам для студентов с летней школы.

В начале прикладные материалы + материалы для начинающих.
Для тех кто много знает - в конце начинается более инфровая часть и технические репорты.

На многих слайдах внизу есть ссылки на статьи/технические блоги.

Как понять, что «тормозит» 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