Системный дизайн от 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

У меня в последнее время подгорает на cursor, потому что

1. На запрос генерируется несколько файлов (код, тесты, readme, скрипты запуска).
2. Проект превращается в свалку файлов от разных запросов.
3. Лимиты на cursor улетают очень быстро. А ведь они недавно еще их и порезали.

Проблема в том, что в одном продукте смешан функционал для разных целевых аудиторий:
1. Вайбкодеры
Надо быстро и под ключ. Чтобы сразу весь проект сделало, скрипты сетапа и запуска. Те самые MVP, которые нужны, чтобы поглядеть как выглядит реализация идеи, выкинуть и сделать хорошо.
2. Профессиональные разработчики
Нужно добавить конкретный узкий функционал. Или даже один конкретный класс или функцию. Возможно несколько запросов подряд для реализации разного функционала.

В итоге интерфейсы и первые скетчи кода я сейчас вынуждено генерирую в chatgpt. И потом довожу их до ума в cursor, вечно добавляя "do not over engineer, make it simple, ...".
И все чаще ловлю себя на мысли "лучше бы сам руками сделал".

А где-то радуется один вайбкодер. И Сэм, пытающийся продать gpt как замену разработчика 😀

@deploy_ml