Пятничного прекрасного вам в ленту.

История ИИ от Демокрита Крита до наших дней.

https://www.aiprm.com/timeline-of-ai-technology/

И до Шмидхубера была жизнь!

И чтобы два раза не вставать:

Сколько времени прошло от сайнс-фикшна до воплощения, на примере 50 технологий.

https://www.aiprm.com/science-fiction-technologies/

Спасибо DeepSeek, иначе бы ещё ждали :)

https://openai.com/index/openai-o3-mini/

Пожалуй, это достойно не только чата, но и всего канала

https://youtu.be/vxkBE23zDmQ?si=DK5E-ox1wUjqhwIB

Я тут упоминал, что в рамках курса по AI Alignment решил копнуть немного в сторону mech interp (https://www.group-telegram.com/gonzo_ML.com/3200) и сделать нанорисёч на базе Gemma 2B. Вычленить какую-то цепь (circuit) времени не было, но немного успел поиграться с выкидыванием слоёв и обнаружил неожиданный для себя результат.

Если вкратце, то наверное пара вещей:

1. Все 26 слоёв декодера чем-то занимаются, от первого до последнего, эмбеддинги даже визуально меняются. Эту картинку приводил в прошлый раз. При этом опять же на глаз видно несколько групп слоёв с похожими паттернами активаций. Что именно они там делают, пока хз.

2. Если выкидывать слои, то определённо есть более критичные, и что неожиданно, кроме понятного критичного в начале, есть неожиданные критичные в середине, возможно, на границе тех самых визуально выделяемых групп. Интересно, что в них такого.

Может, конечно, это просто артефакт конкретного эксперимента, датасета и модели, но может и нет.

Написал про это здесь:
https://gonzoml.substack.com/p/not-all-layers-are-equal

Colab ноутбук для тех, кто захочет продолжить изыскания и покопаться сам, здесь:
https://colab.research.google.com/drive/1Dita8PWjxc_nPjOKCGKyuv7tVamZIc-h?usp=sharing

Картинка с "важностью" слоёв ниже.

Это уже было, но чтоб не искать.

Уже даже перестало быть смешно.

https://x.com/SchmidhuberAI/status/1885357355938046382?t=s0IbbVihpRgYYY5tVzb8WA&s=19

Про ограниченность ресурсов и инновации.

Это соавтор QLoRA, LLM.int8(), k-bit inference scaling laws, Petals, SWARM если что.

Worth watching. Много интересных рассуждений, не в режиме для теленовостей.

https://youtu.be/b_DUft-BdIE?si=HIECi3BXXj9TvbmG

Пример со стержнями и дисками прикольный.

Найс

Про магию Deepseek, RL и GRPO

Когда-то, давным давно, никто не занимался глупостями, и не использовал RL в обучении языковых моделей. Был unsupervised претрейнинг, был SFT для обучения моделей следования инструкциям, были какие-то энкодер специфичные лоссы, которые никак не были связаны с генерацией текста, ну и, в общем то, всё.

Потом наступили времена GPT-3.5 и соответствующей статьи опенаи. Авторы добавили третий шаг после претрейна и сфт — RLHF в виде PPO. Работало это так: африканцы, работающие за копейки (по меркам западного мира, по меркам их родных стран получали они вполне неплохо), размечали диалоговые данные на предмет соответствия заданным в ТЗ требованиям, на этих разметках обучался текстовый классификатор, который использовался в лоссе при обучении. Чтобы модель не ломалась и не начинала генерить, например, пустые предсказания (потому что если промолчать, то сойдёшь за умного), дополнительно накладывался KLD-штраф на слишком большой отход от генераций референс моделью. В итоге, постепенно, модель начинала генерить текст, который лучше рейтился классификатором -- и при условии соответствия классификатора human reference'ам, модель переставала быть токсичной, рассказывать про изготовление бомб и крэка и так далее.

Одним из больших плюсов такого подхода было то, что при наличии ревард-модели (классификатора), обучать модель генерациям можно на неразмеченных данных. По сути, ревард модель на лету их размечает, а нам надо только следить за падающим лоссом. С другой стороны, PPO — это штука сложная, нестабильная и требовательная к качеству ревард модели. Если её слишком сложно обмануть, то начнётся reward hacking и модель испортится. Плюс мб это skill issue, но сколько бы я не пробовал применять PPO, у меня всегда взрывался KLD и итоговая модель ломалась. Судя по моим консультациям с коллегами, у них было то же самое — и единственным способом с этим бороться было делать чекпоинты почаще и откатываться на последний рабочий чекпоинт в случае взрыва.

Было ясно, что надо как-то всё упростить, и следующим шагом стал DPO. В нём полностью избавились от отдельной ревард модели, используя саму обучаемую модель для оценки генераций. Если на пальцах — мы берём датасет, где ответы на промпты размечены на chosen и rejected, потом считаем логпробы обучаемой и референсной модели при генерации обоих вариантов ответа, нормируем ответы референсной и обучаемой модели друг на друга и потом оптимизируем сигмоиду от взвешенной разности между этими логпробами.

Это, по сути, стало стандартом для преференс-тюнинга моделей. При наличии даже небольшого размеченного датасета можно было быстро и дёшево обучить инстракт модель тому или иному стилю или добавить в её ответы какие-то свойства. К примеру, авторы моделей через DPO делали их цензурирование, а потом деятели коммьюнити через тот же DPO пытались модели расцензурить. Вариаций на тему этого лосса был миллион, все они отличаются какими-то небольшими изменениями оригинальной формулы и время от времени с ноги влетают на нипс.

А потом, в феврале 2024 года — почти год назад — появилась статья про модель DeepSeek Math, где авторы предложили тот самый GRPO, который используется в так хайпующем сейчас R1. Там они тоже решили отталкиваться от PPO как от базового лосса, но решили пойти чуть в другую сторону. Вместо per-prompt оптимизации, в GRPO сначала семплится батч из промптов, потом для каждого ответа считается ревард, потом из каждого реварда вычитается среднее по всем ревардам в батче и нормируется на std, так получаем advantage. Дальше мы считаем частное между предсказаниями новой и старой моделей и вычитаем KLD, чтобы модель не сильно уходила от изначальных ответов.

В итоге, DeepSeek Math с небольшим сфт колдстартом и GRPO била гораздо большие по размеру модели на основных бенчмарках по матеше. Потом тот же подход повторили Qwen Team — в Qwen 2 Math они тоже использовали GRPO для обучения, а в Qwen-2.5-Math доразметили датасет через Qwen-2-Math и получили ещё более качественную модель.

Финальный шаг был сделан в нашумевшем техрепорте о r1. Во-первых, в одном из экспериментов они вообще отказались от сфт колдстарта и сразу начинали учить модель через GRPO — и всё завелось. Во-вторых, если я правильно понял, они вообще не использовали ревард модель на промптах про математику — потому что её использование приводило к reward hacking. Вместо этого они проверяли формат вывода регэкспом и проверяли, правильный ли ответ был сгенерирован, то есть использовали ревард не нейронный, а rule based. И ничего, даже с такими простыми эвристиками модель сама обучалась CoT, метрики росли и итоговая модель, R1-Zero, показывала очень хорошие скоры на бенчмарках. В R1 сфт всё таки добавили, но это сделали исключительно чтобы повысить читаемость цепочек размышлений — скоры на бенчах выросли не так сильно и, по сути, это было не обязательно.

Не всё так однозначно хорошо, конечно, потому что такой rl-only подход, по всей видимости, не работает на моделях меньшего размера. Авторы попробовали обучить Qwen-32B только через RL, всё заработало, модель стала по качеству примерно как QwQ — но простой сфт на цепочках от R1 дал гораздо более высокий результат.

Рискну предположить, но возможно, что что-то подобное было сделано и в o1 — и это вполне укладывается в описание процесса файнтюна о1-mini, про который рассказывали во время рождественских видео опенаи. Если это так, то признаю, в том самом сентябрьском посте с критикой OpenAI я был неправ :)

Это что, получается, рл, наконец-то заработал?

Ссылки:

Deepseek Math: https://arxiv.org/abs/2402.03300
Qwen 2 Math: https://qwen2.org/math/
Qwen 2.5 Math: https://qwenlm.github.io/blog/qwen2.5-math/
Deepseek R1: https://arxiv.org/abs/2501.12948

Любопытное интервью с Дэвидом Дойчем. У него в частности свой особый взгляд на соотношение между AI и AGI

https://youtu.be/jQnoxhoWhXE?si=y_wtBbmyiP1XJnC9

DeepSeek-V3 Technical Report
Статья: https://arxiv.org/abs/2412.19437
Репа: https://github.com/deepseek-ai/DeepSeek-V3

Предыдущий пост про DeepSeek был попсовый (https://www.group-telegram.com/gonzo_ML.com/3239), сегодня хочется пройтись по некоторым техническим решениям в DeepSeek, которые мы тут раньше не обсуждали.

В-нулевых, что важно знать про DeepSeek-V3 — это всё ещё относительно классический трансформер декодер (но с MoE, https://www.group-telegram.com/gonzo_ML.com/472). DeepSeek-V3 содержит 671B параметров, из которых активны 37B для каждого токена. 61 трансформерный слой, d_h = 7168.

В работе есть несколько интересных решений, которые хочется отметить для истории. Для начала пара вещей, проверенных в DeepSeek-V2 (https://arxiv.org/abs/2405.04434).


❇️ Во-первых, Multi-head Latent Attention (MLA). Что это такое?

В классическом Multi-Head Attention (MHA) эмбеддинги входных токенов h_t проецируются в векторы query, key, value q_t, k_t, v_t через незавимимые матрицы проекций W^q, W^k, W^v и затем нарезаются на векторы для отдельных голов внимания. После работы self-attention (тот самый softmax(QK/sqrt(d))*V ), получаем o_t для отдельных голов, конкатенируем и далее через матрицу W^o генерим выход слоя.

MLA делает низкоранговую компрессию для key и values, где h_t сначала проецируется в низкоранговый латентный вектор c_t, а потом из этого вектора через отдельные матрицы W^uk, W^uv, разворачивается в k_t, v_t. Размер латентного вектора, d_c, сильно меньше, чем итоговая размерность с учётом всех голов (d_h*n_h). На инференсе это сокращает размер необходимого KV-кеша, потому что надо кешировать только низкоразмерные c_t, а не полноразмерные k_t, v_t как раньше. Более того, матрицы проекций из c_t в ключи и значения можно вообще убрать, матрицу для k_t (W^uk) можно инкорпорировать внутрь матрицы для получения q_t (W^q), а матрицу для v_t (W^uv) внутрь выходной матрицы W^o.

На самом деле и для q_t тоже делается низкоранговая компрессия в свой вектор c_t, это не влияет на KV-кеш, но помогает уменьшить объём памяти для активаций при обучении.

Была проблема с тем, что позиционные эмбеддинги RoPE несовместимы с низкоранговой компрессией KV, для решения этой проблемы предложили decoupled RoPE strategy с дополнительными многоголовыми q^R и шареным k^R со своей размерностью d^R_h на голову. Итоговые вектора для Q и K являются конкатенацией векторов полученных из соответствующего низкорангового вектора c_t и вектора для RoPE (q^R, k^R).

Посмотрите на формулы (раздел 2.1.2), там понятнее, чем текстом.

В DeepSeek-V2, размерность латентного вектора d_c была установлена в 4d_h (суммарная размерность четырёх голов), а размерность для RoPE d^R_h в d_h/2 (полголовы). В MLA DeepSeek-V3 128 голов внимания, каждая размерности 128. Размерность d_c равна 512.

Помните, что это не единственный способ оптимизации внимания при ускорении генерации и от классического MHA уже много где ушли в Multi-Query Attention (MQA) имени Ноама Шазира (https://arxiv.org/abs/1911.02150), где K и V шарятся между всеми головами внимания (что сильно ускоряет инференс и слегка ухудшает качество), и Grouped-Query Attention (GQA) тоже от Гугла (https://arxiv.org/abs/2305.13245), которое было срединным путём между MHA и MQA, и где количество key-value голов было больше одной, но меньше полного набора как у query — здесь по одной key-value голове на группу query голов — и качество можно приближать к оригинальному MHA.

MLA хорошо экономит кеш, сравним с GQA с 2.25 групп, при этом перформанс даже выше MHA. В общем выглядит так, что MLA должен теперь доминировать везде. Не знаю, есть ли что-то лучше из опубликованного?

❇️ Во-вторых, DeepSeekMoE (https://arxiv.org/abs/2401.06066)

“Эксперты” сидят в FFN слоях, не в MLA, и слой заменяется на выбор и вызов какого-то числа “экспертов” из всех доступных. По сути каждый эксперт — это отдельный слой FFN, который выбирается каким-то алгоритмом роутинга. Классический GShard (https://www.group-telegram.com/gonzo_ML.com/473) активировал двух экспертов на слой, Switch Transformer (https://www.group-telegram.com/gonzo_ML.com/473) одного. Соответственно каждый токен отправляется на обработку выбранным экспертам, и если их больше одного, их ответы каким-то образом смешиваются (например, с весами).

DeepSeekMoE пытается добиться от экспертов большей специализации. Для этого экспертов разбивают на более мелких. То есть каждого эксперта разбили на m штук, но при этом и активируем больше, тоже в m раз, так что суммарные вычисления остаются примерно такими же. Это называется Fine-Grained Expert Segmentation. Вместо K активных экспертов из N получаем mK из mN. Выходит более интересная комбинаторика в виде сильно большего количества вариантов, кто может быть задействован, соответственно может получиться более интересная специализация экспертов.

С другой стороны может требоваться какое-то общее знание и для этого осмысленно выделить сколько-то шаренных экспертов, которым токены отправляются всегда. Тогда есть надежда, что общее знание будет выучиваться там, а не в куче остальных экспертов независимо. Можно сказать, что в итоге есть N_s shared экспертов и N_r routed экспертов. В DeepSeek-V3 используется 1 shared, 256 routed, из них выбирается 8 активных.

Routed эксперты выбираются как top-k, по affinity скору, рассчитываемому как скалярное произведение входного эмбеддинга токена и центроида конкретного эксперта. Я не заметил описания, как вычисляется этот центроид, но допускаю, что это какое-то среднее значение активаций (или входов) всех токенов, на которые реагирует данный эксперт. В DeepSeek-V2 брали softmax от этого произведения, в DeepSeek-V3 перешли к sigmoid, а также добавили нормализацию всех скоров перед их применением.

Чтобы избежать коллапса при роутинге (например, когда всё отправляется одним и тем же экспертам) в DeepSeek-V2 был специальный балансирующий лосс, даже два: один на уровне экспертов, другой на уровне вычислительных девайсов, что логично, баланса хочется и там, и там. Слишком большой лосс может ухудшить перформанс модели и в DeepSeek-V3 отказались от дополнительного лосса, использовав специальную стратегию балансировки auxiliary-loss-free load balancing strategy, опубликованную командой чуть ранее (https://arxiv.org/abs/2408.15664). В ней при роутинге к affinity score добавляется bias и по результату берётся top-k. Для вычисления коэффициента при смешивании экспертов (gating value) этот bias не используется. За изменение bias отвечает специальная процедура, которая следит, какие эксперты вызывались внутри батча и если кто-то перегружен, понижает ему этот bias (и повышает, если эксперт сидит без дела). Работает лучше, чем с лоссом. Прикольно, назад от бэкпропа. Хотя может просто не нашли правильный подход для обучения бэкпропом…

Чтобы избежать дисбаланса в рамках обрабатываемой последовательности также добавили Complementary Sequence-Wise Auxiliary Loss с очень маленьким весом. Есть алгоритмический Node-Limited Routing, ограничивающий девайсы, идейно близкий к балансирующему лоссу в DeepSeek-V2. Каждый токен отправляется максимум на 4 узла.


❇️ Далее новые вещи. Используется Multi-Token Prediction (MTP). Идея MTP в том, что в каждой позиции предсказывается больше одного токена. В текущей модели это два токена, текущий и следующий. По идее это усиливает обучающий сигнал и может повысить data efficiency. Также это может помочь модели лучше готовиться к предсказанию будущих токенов.

Предсказание токенов сделано последовательным. Для предсказания D дополнительных токенов используется D MTP модулей (MTP Modules), у них шареные эмбеддинги и выходная голова. На вход им прилетает выход слоя основной модели или предыдущего MTP модуля, а также эмбеддинги следующего токена, всё нормализуется RMSNorm и конкатенируется. Каждый модуль считает кроссэнтропийный лосс, по всем модулям вычисляется средний лосс и он с коэффициентом 𝜆 выступает как дополнительный лосс модели (0.3 для первых 10T токенов, 0.1 для последующих 4.8T). При инференсе MTP модули отбрасываются, но можно и использовать для speculative decoding.

MTP стабильно улучшает перформанс на большинстве бенчмарков. В экспериментах acceptance rate для следующего токена находился в диапазоне от 85% до 90%. В комбинации со speculative decoding TPS возрастает в 1.8 раза.


❇️ Другая интересная часть — инфраструктура.

DeepSeek-V3 обучался на кластере из 2048 NVIDIA H800 GPU. Напомню, что H800 — это урезанная H100 для Китайского рынка. У H800 ослаблен interconnect (bandwidth ниже более чем в два раза и количество линков NVLink тоже уменьшено), а также в десятки раз понижены флопсы для FP64 — для нейросетей неважно, а атомные бомбы считать хуже. Чтобы нумерация была “особенно логичной”, H200 — это улучшенная версия H100 с большим объёмом более быстрой памяти.

Для обучения внутри компании написали свой закрытый фреймворк HAI-LLM.

DeepSeek-V3 использует 16-way Pipeline Parallelism (PP), 64-way Expert Parallelism (EP) с 8 нодами, и ZeRO-1 Data Parallelism (DP). Для эффективного PP разработали алгоритм DualPipe, перекрывающий фазы коммуникации и вычисления в forward и backward фазах. Приводит к уменьшению pipeline bubbles. Благодаря суровым оптимизациям памяти обошлись без Tensor Parallelism (TP). Кроме этого разработали эффективные cross-node all-to-all communication kernels.


❇️ Но самая интересная для меня часть здесь — это FP8 Training.

Кто не знает, что такое FP32, FP16, BF16, вэлкам в мой старый пост: https://moocaholic.medium.com/fp64-fp32-fp16-bfloat16-tf32-and-other-members-of-the-zoo-a1ca7897d407. FP8 там нет, но по аналогии поймёте, что это такое.

Кажется, это первая открытая реально большая продакшн модель, обученная в FP8. Llama3, например, вроде как в BF16 обучалась, и я так понимаю это примерно стандарт, ну либо микс FP32/16. Да, была более ранняя работа (https://arxiv.org/abs/2409.12517) от израильтян из Habana (теперь Интел). Там в FP8 обучали 7B модель на 2T токенов на интеловско-хабановских же Gaudi2 и получали качество сравнимое с BF16 при улучшении throughput на 34%. Была и ещё более ранняя FP8-LM (https://arxiv.org/abs/2310.18313) от Microsoft, где обучали GPT-175B. Они даже библиотечку опубликовали (https://github.com/Azure/MS-AMP). В принципе не удивлюсь, если OpenAI в итоге тоже внутри на FP8 перешли, но от них молчок. Что там у Гугла тоже не поймёшь. Но ставлю на BF16 🙂

В реальности у DeepSeek, конечно, тоже mixed precision — какие-то вещи по-прежнему считаются в более полных форматах, BF16 или даже FP32. В таких форматах остались: embedding module, the output head, MoE gating modules, normalization operators, and attention operators (вот тут я не совсем понял, какие именно). Также в большей разрядности пишут master weights, weight gradients, и optimizer states. Это всё повышает стабильность обучения, кажется, основную проблему низкоразрядных форматов (ну за пределами отсутствия поддержки в кернелах и железе). Но большинство тяжёлых вычислений в FP8. Отчасти поэтому, я думаю, они сумели сильно сэкономить в деньгах на компьют. В идеальной теории это повышает доступный компьют в два раза, одновременно уменьшая во столько же требования к памяти.

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

Также вложились в оптимизацию хранения и коммуникации, что помогло сэкономить и в потреблении памяти, и в оверхеде на коммуникацию.

FP8 обучение провалидировали на DeepSeek-V2 с 16B и 230B параметров, там разница между FP8 и BF16 оказалась в пределах случайности.

Ждём теперь, когда Америка обяжет Нвидию ограничить FP4 и FP8 🙂


❇️ Для инференса тоже сделали оптимизации.

Деплоймент фаз prefilling и decoding разделён. Напомню, что во время prefill обрабатываются все токены промпта и вычисляются все промежуточные KV, в во время decode происходит авторегрессионная генерация токена за токеном. Подробнее тут (https://developer.nvidia.com/blog/mastering-llm-techniques-inference-optimization/).

Для prefill минимальный деплой юнит содержит 4 ноды с 32 GPU и конкретные настройки параллелизма. При декодировании, где нужно суммарно 9 экспертов, минимальный юнит содержит 40 нод с 320 GPU и имеет свои настройки.


❇️ Отдельная интересная секция — это “3.5. Suggestions on Hardware Design”.

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

Среди рекомендаций есть группа про коммуникацию и про компьют.

На коммуникацию приходилось выделять 20 из 132 SM, которые могли бы заниматься вычислениями. Авторы хотели бы использовать GPU со-процессор или специальный сетевой со-процессор, в который можно было бы выгружать подобные задачи. Кто помнит 386/387 и далее, когда были процессоры и арифметические со-процессоры? Вот теперь зреют графические процессоры и со-процессоры! Хотя, кажется, они давно уже есть, те же DPU? С точки зрения программирования интересно было бы унифицировать сети Infiniband (scale-out) and NVLink (scale-up).

С точки зрения компьюта есть запрос на повышение точности аккумуляции внутри тензорных ядер, поддержку tile- и block-wise квантований, онлайн квантования, и поддержку транспонированных GEMM-операций.


На этом пока закончу технический разбор, может быть ещё пройдёмся по обучению и последующим моделям.