gonzo-обзоры ML статей
15.02.202500:28
06.02.202500:55
06.02.202500:52
06.02.202500:49
06.02.202500:48
06.02.202500:47
DeepSeek-V3 Technical Report
Статья: https://arxiv.org/abs/2412.19437
Репа: https://github.com/deepseek-ai/DeepSeek-V3
Предыдущий пост про DeepSeek был попсовый (https://t.me/gonzo_ML/3239), сегодня хочется пройтись по некоторым техническим решениям в DeepSeek, которые мы тут раньше не обсуждали.
В-нулевых, что важно знать про DeepSeek-V3 — это всё ещё относительно классический трансформер декодер (но с MoE, https://t.me/gonzo_ML/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 должен теперь доминировать везде. Не знаю, есть ли что-то лучше из опубликованного?
Статья: https://arxiv.org/abs/2412.19437
Репа: https://github.com/deepseek-ai/DeepSeek-V3
Предыдущий пост про DeepSeek был попсовый (https://t.me/gonzo_ML/3239), сегодня хочется пройтись по некоторым техническим решениям в DeepSeek, которые мы тут раньше не обсуждали.
В-нулевых, что важно знать про DeepSeek-V3 — это всё ещё относительно классический трансформер декодер (но с MoE, https://t.me/gonzo_ML/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 должен теперь доминировать везде. Не знаю, есть ли что-то лучше из опубликованного?
07.02.202515:47
06.02.202500:53
06.02.202500:51
06.02.202500:49
06.02.202500:48
06.02.202507:43
06.02.202500:53
06.02.202500:50
06.02.202500:48
06.02.202500:47
Также вложились в оптимизацию хранения и коммуникации, что помогло сэкономить и в потреблении памяти, и в оверхеде на коммуникацию.
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-операций.
На этом пока закончу технический разбор, может быть ещё пройдёмся по обучению и последующим моделям.
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-операций.
На этом пока закончу технический разбор, может быть ещё пройдёмся по обучению и последующим моделям.
28.01.202508:41
Шутка юмора
06.02.202507:37
HuggingFace тем временем выкатил свой AI App Store:
https://huggingface.co/spaces
https://huggingface.co/spaces
06.02.202500:53
06.02.202500:50
06.02.202500:48
06.02.202500:47
Предсказание токенов сделано последовательным. Для предсказания 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.
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.
27.01.202521:21
В продолжение темы, Jay Alammar, у которого были прекрасные визуальные объяснения про работу трансформера, в сто раз лучшие оригинальной статьи, выпустил только что иллюстрированный DeepSeek-R1
https://newsletter.languagemodels.co/p/the-illustrated-deepseek-r1
https://newsletter.languagemodels.co/p/the-illustrated-deepseek-r1
Көрсетілген 1 - 24 арасынан 76
Көбірек мүмкіндіктерді ашу үшін кіріңіз.