Почему мы все используем карты Nvidia для ИИ?
1. Они в большинстве кейсов №1 по производительности
2. Существует множество форм-факторов карт, код под которые пишется на одном и том же CUDA Toolkit
3. Nvidia выкладывает высокопроизводительный софт (часто лучший для своей ниши) с поддержкой CUDA

Все это она делает более 15 лет (если считать точкой отсчета релиз CUDA в 2008)
Больше - здесь

Как устроен антифрод в Stripe? И что мы можем подметить?

Увидел статью по Radar - антифрод системе Stripe
Заменили ансамбль бустинга и линейной модели на ResNeXt like нейросеть, состоящую из блоков с разными ветвями
И вот какую дельту получили:
+ Проще модель и система в целом
+ Быстрее обучение
+ Быстрее инференс
+ Лучше качество модели (если много качественных данных)
- Меньше интерпретируемость

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

Подметил несколько тенденций:
1. Бустинг меняют на нейросети для табличных данных. С оговоркой, что во всех таких кейсах размеченных данных терабайты. В случае Stripe транзакции размечает поддержка. Вот вам и задел на онлайн обучение или хотябы частое переобучение
2. ResNext like модели хороши на данных больших размерностей (фичей что численных, что категориальных там куча). Я вообще больше модели компьютерного зрения учил, и для меня было забавно слышать от коллег на работе, что resnext - это про задачи оптимизации, и в них идеи бранчинга блоков тоже прижились
3. Интерпретируемость. Ее хотят и пытаются достичь. В случае с нейронками это тяжелая и последовательная работа по анализу работы алгоритма и значимости фичей. А потом обдумывание, как бы их понятно показывать и доводить до поддержки и клиентов
4. Все больше закапываемся в оптимизации обучения и инференса. Нейросети хочется глубже, размеченных данных все больше, а ускорители растут по производительности медленнее аппетитов. В оптимизационных задачах с большим объемом разметки задача все чаще пропихнуть в обучение как можно больше данных. В связи с этим начинают появляться кастомные обучалки и инференсы

Meta вчера представила базовую модель Emu для генерации видео и редактирования изображений

На мой взгляд она одна из самых качественных, что я видел. Выглядит так, что возможности движения на генерациях ограничены, но такого достаточно для большого количества приложений

Meta на самом деле ориентируется на использование в своей экосистеме и видит модель как генератор GIF, скетчей и набросков (мне кажется это пока вообще основное применение таким моделям), а также как редактор изображений для социальных сетей

Статья

А вот и релиз видеогенерации, которую можно потрогать и использовать
Stable Video Diffusion: Scaling Latent Video Diffusion Models to Large Datasets

Модель
Статья

Позвали на хакатон техэкспертом
У меня CV/ML кейс от сколтеха
На самом деле хороший способ вырваться и чуть сменить картинку перед глазами

В основном тут школьники и студенты 1-2х курсов, но я поймал себя на мысли, что было бы круто и мне поучаствовать
Хакатон очень хорошее место, чтобы получить себе проект в портфолио - нужно всего два-три дня, а условия создаются около идеальные: все данные собраны, почищены и размечены, а заказчик уже зафиксировал конечную цель и не нужно итерироваться

Про оптимизации кода

За последние 3 месяца пришлось поускорять код под x86 и arm
Принято считать, что современные компиляторы и так хорошо оптимизируют. И это правда, когда дело касается простых вещей в духе копирования массива

Но компилятор не может оптимизировать неизвестное на момент компиляции:

1. Если в цикле есть if, он может разломать векторизацию или добавить миспредикт бранча

2. Что в GPU, что в CPU недоутилизация вычислителя часто упирается в пропускную способность памяти и ее размеры (для GPU - память девайса. Для CPU - L1-L3 кэши). Так вот компилятор не может заранее понять, какие данные переиспользуются и от того будет постоянно перевытеснять их в кэшах.

3. Выравнивание по кэш линии
Если у вас есть межядерное взаимодействие, то, если два значения будут расположены в одной кэш линии, протокол синхронизации будет замедлять работу на обращении к каждой ячейке в кэш линии
Самый простой способ и самый стреляющий - объявить в классе
atomic<int> first;
atomic<int> second;
И вот уже два кажется независимых атомика сидят в одной кэшлинии и живут как один. А вы не понимаете, где этот ваш lock-free и почему такой маленький (в 2-4 раза меньше) bandwidth

4. Если вычислитель имеет несколько физических вычислительных блоков, то компилятор может недоутилизировать данный параллелизм. Например, автоматический unroll циклов затруднен при зависимостях между итерациями

5. Функции стандартной библиотеки должны быть универсальны, надежны и поддерживаемы. От сюда даже такие вещи как сортировка и бинарный поиск могут быть ускоренны в разы, не меняя алгоритм. Даже в с++. Хотя для этого вам нужно будет использовать simd инструкции под определенный тип данных

6. Numa ноды.
Если память выделится на одной ноде, поток вытеснится и перешедулится на ядро другой ноды - получите задержку на копирования между нумами (шаг протокола синхронизации)
Хотя, честно, Numa ноды сильно чаще упоминают, чем они реально улучшают производительность - в большинстве приложений микросекундные задержки не видны

Материалов на эту тему много. Мне очень понравилась книга от Сергея Слотина. Многое из того, что приходилось выискивать, там есть в хорошем качестве
Но опять же, пока сами не уткнетесь, в важность не поверите)

*на картинке схема нескольких Numa нод с собственными кэшами в рамках одного процессора

Кстати по хакатонам - в итоге решили поучаствовать и забрали приз

Не все успели, но нам понравилось
Хакатон - это хороший способ понять, насколько быстро и качественно мы можем делать задачи - в критической обстановке лучше чувствуешь свои сильные и слабые стороны

С началом нового года вас!

Опубликовал перевод статьи с dev блога
В таких статьях иногда много воды, но они полезны для расширения кругозора

Selective Column Reduction for DataLake Storage Cost Efficiency

Хотим научиться удалять столбцы в таблицах не делая дорогостоящие чтения и записи
Для этого залезем внутрь формата данных Apache Parquet, руками скопируем чанки данных с нужными нам колонками, а чанки с ненужными - просто пропустим
После запишем новые смещения начала чанков в метаданные
Если необходимо - в конце операции можно потереть исходный файл с чанками (в партиционированных таблицах копирование не страшно, т.к. чанки не сильно большие)

И, конечно, заметим, что это по сути Map операция, поэтому можно эффективно делать ее распределенно: запускаем несколько задач - по одной для каждого физического файла под абстракцией таблицы

Что мне нравится в этой статье
- Базово про Parquet и вообще затрагивается тема layout таблицы на диске
- Не боимся лезть внутрь движков и на масштабе получать экономию (кластера обычно общие, поэтому сэкономленное железо пойдет под утилизацию другими задачами)
- Натягиваем алгоритм на использующийся движок (у Uber это Spark, но это не принципиально)

оригинал

R&D в Google

Как правило, компании по-разному понимают функционал отделов и команд в структуре компании. Глобально можно сказать, что в разработке есть R = “Research” и D = “Development”.

С Development понятно - это команды, обычно ориентированные на выполнение плана и выгоду на горизонте до 6-12 месяцев
С R&D, если смотреть по рынку в целом, в основном компании чуть сваливаются в одну из сторон:
1. В Research:
задача улучшить алгоритм и оформить результат в виде презентаций и статей. О таком формате я часто слышу от ребят из Huawei/Samsung (справедливости ради, часто они себя явно Research называют, а не R&D)
2. В Development:
Задача - зарабатывать деньги, метрики вовлеченности и тд
У меня в отделе так - нет заработанных денег => нет больших премий
Наши команды явно позиционируются как продуктовые
И очень сложно сказать, что вот этот человек исследователь, а этот - копатель. Исследователь может под себя полезть переписывать часть движка инференса, потому что никто другой это делать не пойдет

Наткнулся на статью 2012 года от Гугла. Еще есть хороший обзор с инфографикой на медиуме
Они про второй тип - командам необходимо дать конкретную пользу на горизонте максимум нескольких лет.
Нет явного разделения. Людей переводят между ролями для разнообразия задач и опыта. Это позволяет нанимать реально крутых ребят и закрывать дыру непонимания между исследованиями и продуктом
И это в целом соответствует желаниям большей части хороших разработчиков - хочется держать баланс между исследованием и практикой внедрения

Обзор баз данных за 2023

В Carnegie Mellon University (CMU) есть очень сильная группа по базам данных. Во многом благодаря Andy Pavlo - очень крутому профессору с отличной подачей материала на лекциях
Еще у него есть стартап Ottertune, который с помощью ML настраивает параметры для баз данных для лучшей производительности

Он делает ежегодные обзоры индустрии. Поверьте, там есть что разбирать. Потому что стартапы по базам данных открываются и закрываются огромными объемами 😁
Что произошло в прошлом году?

1. Подъем популярности векторных баз данных. Во многом благодаря LLM и возможности по эмбедингам искать приближенно документы в “базе знаний”. И вот компании, типа Qdrant, Pinecone и Weaviate подняли существенные раунды
Но вот основная проблема в том, что функционал поиска по вектору - это по сути просто KNN индекс, которую может реализовать почти дюбая СУБД. Например просто интегрировав к себе faiss. Потому конкуренция и давление будут усиливаться
И, по большому счету, у векторных баз есть два пути
а. Превращаться в подобие MongoDB и служить базой записей. И заниматься реализацией SQL, распределенности и тд
б. Становиться вторичным специализированным движком (как Elasticsearch для логов)

2. Улучшения SQL стандарта
а. Поддержка графовых запросов. Пока в стандарте и реализовано только у Oracle. Должно стать меньше извращений с обходом графа
б. Поддержка многомерных массивов. С одной стороны это то же извращение, что и хранить json вместо создания нормальной таблицы и SQL база не очень про такую логику. С другой стороны, такое нововведение точно улучшит жизнь аналитикам, которые не будут вынуждены все сначала выгружать в python, а потом руками обрабатывать

*Наличие стандарта не означает наличие стабильной реализации (применимо вообще ко всему в ИТ)

3. Драмма MariaDB
Если коротко, то пахнет жареным. Перед IPO в тихую вывели 99% фандинга с профитной части компании. Акции упали на 90% от стоимости на IPO. Непрофитная часть, которая занимается поддержкой opensourse, говорит, что люди из профитной части не очень компетентны
Основатель обругал CEO при всех и ушел с командой
В общем то грусть и печаль. Пострадают те, кто поверили в проект и могут остаться без поддержки

Тут же Andy подмечает, что смерть профитной части компании почти всегда приводит к смерти проекта, каким бы опенсурсным он не был (за очень редкими исключениями). Мало кто готов заниматься благотворительностью. Доработка и поддержка любой софтины - тяжелая работа

4. Как в январе 2023 крашнулась система NOTAM, предупреждающая пилотов об опасности.
Было нарушено расписание примерно 11000 рейсов (задержка/экстренная посадка)
Судя по всему, система не менялась с момента закупки в 80х годах. И скорее всего, держала не больше 50 RPS (что забавно в сравнении с текущими производительностями систем)
Причина ошибки - покоррапченные файлы. И на последок: бекап, из которого попытались восстановить систему, оказался тоже нарушенным. Вообще восстановление из бекапа - это очень важный сценарий, который стоит регулярно прогонять на своих бекапах, иначе защита от ваших бекапов на уровне иконок в машине, приклеенных на место разрыва подушки безопасности

И в целом - стоит меньше доверять надежности систем. Кто бы что не говорил - они падают. Даже у гигантов индустрии.
А гарантии отказоустойчивости - не всегда выполнимы (маркетологи баз данных Вам поклянутся об обратном 😊)

5. Венчур в стартапах по базам данных
Много денег поднято. Но учитывая ситуацию в мире, вполне возможны дальнейшие сокращения персонала
TileDB - 34m$ series B
SQreamDB - 45m$ Series C
Neon - 46m$ series B
MotherDuck - 52.5m$ series B
DBeaver - 5m$ seed round (вот этой штукой я пользуюсь, но пока не понятно, почему я должен захотеть заплатить)

Выглядит это все конечно немного сюрреалистично. Как и венчур в целом. Большинство этих компаний просто не имеют ничего кроме софтины за спиной и около нуля платящих клиентов. Потому большинство из них просто живет, пока есть фандинг.
А потом напишут:
“Мы не смогли поднять раунд, извините, мы закрываемся. И да, ваши инстансы с данными будут удалены через 2 недели. Хорошего вам дня! С любовью, команда ХХХ“

Про обучение больших трансформеров

В основном в проде все используют LLM размера не больше 35B. А на деле даже чаще 7B или 15B
Связано это в первую очередь с эффективностью и расходимостью юнит экономики (ее бы с маленькими моделями свести для начала. GPU дороги)

Но параллельно есть товарищи, которые учат максимально большие сети. Прямого коммерческого смысла в этом сейчас нет - слишком дорогие косты инференса - сложно придумать маржинальное использование. А капекс на обучение самой сети очень велик
Зачем же тогда учат? Чтобы:
- Дистилировать в маленькую модель
- Новые идеи
- Перестраховаться на случай прорыва в вычислительных технологиях

Увидел статью Nvidia, как учить большие сети, когда под один эксперимент используется 1000+ GPU
Я выше писал, что мне очень нравится концепция Ray, однако самая большая его проблема - невозможность хорошо делить память девайса. И таким образом в любой момент времени только 1 операция может занимать GPU. Так вот для LLM это не большая проблема - нейронки большие, можно пофьюзить слои, да и воообще только Вы на кластере
Частичное решение данной проблемы - виртуальный сплит GPU, например MIG

При параллелизме вычисления нейросети (forward pass) есть 3 техники - параллелизм данных, тензоров и графа модели
В статье немного другая терминология - intra (== data + tensor. Параллелизм данных это по сути параллелизм тензора по внешней батч размерности) и inter (граф модели)
В такой терминологии удобнее мыслить блоками и связями между ними

Теперь к тому, как собственно устроено обучение:
1. Есть код в Jax
2. Далее alpa (сейчас функционал auto_sharding в рамках XLA) оптимальную модель intra вычислений (например матричных умножений)
3. alpa рассчитывает inter план вычислений
4. Компилируем каждый блок графа в IR представление (ака JIT)
5. Шедулим исполнение “бинарей” поверх акторной модели Ray

При всех доделках получаем утилизацию 57.5%, так что еще есть куда копать

2 рупора относительно того, как надо деплоить нейросети

1. Построим большие датацентры за ооочень много денег. Будем инференсить централизованно все там. На масштабе точно окупится. Ну сейчас не окупается, да. Но мы что-нибудь придумаем
Это приходит в голову в перую очередь и на самом деле почти все стартапы и рнд отделы именно так деплоят (отсюда и заказы на тысячи видеокарт)

2. А почему мы? У пользователей смартфоны, планшеты, умные колонки, часы и вообще много всего умного
Пусть их устройства и считают все эти нейронки. Железо существенно спрогрессировало на мобильных устройствах
И это более разумный рупор. Так делают примерно все производители мобильных (как минимум в камерах +- каждая уважающая себя компания использует или пыталется использовать не одну нейронку)

Получается две крайности, хотя определяющее - за что пользователь не готов или готов платить. Врятли многие готовы платить за обработку каждой фотографии в датацентре или покупать новомодное AI-only устройство за сотни долларов ради чатбота

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

На идею предыдущего поста навела статья от meta
MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases
LLM оптимизируют под мобильные девайсы. Пишут, что исследовали текущие подходы и сделали новую sota модель 125 и 350 Мб
Основные идеи:

1. Глубина сети сильно важнее ширины для компактных нейросетей

2. Давайте матрица преобразования эмбединга в предсказанный токен будет одновременно являться матрицей для получения ебмединга по токену (весом в nn.Embeding). На маленьких архитектурах можно секономить 10% модели почти не потеряв в качестве

3. Будем использовать Grouped Query Attention для экономии параметров. В нем каждая Key-Value голова используется для нескольких Query голов (в multihead соотношение 1-1). Оптимальное количество уникальных KV-голов - 16, но можно без существенной просадки снизить до 4х и уменьшить вес модели еще на 10%

4. Переиспользование параметров в рамках модели. Это версия модели LS (Layer Sharing). Попробовали разные схемы. Лучше работает, если блоки переиспользовать в обратном порядке, но эффективнее, если загрузите один раз блок и сразу два раза примените на нем forward и позже backward. Если посмотреть на неагрегированные замеры качества, там не однозначно: идея либо чуть хуже, либо на пункт лучше, хотя и выглядит интересно

5. Используют линейные слои с активацией swiGLU
SwiGLU(x, W, V, b, c, β) = Swishβ(xW + b) ⊗ (xV + c)