Обзор баз данных за 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

Что запустить на 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