❇️ Во-вторых, DeepSeekMoE (https://arxiv.org/abs/2401.06066) “Эксперты” сидят в FFN слоях, не в MLA, и слой заменяется на выбор и вызов какого-то числа “экспертов” из всех доступных. По сути каждый эксперт — это отдельный слой FFN, который выбирается каким-то алгоритмом роутинга. Классический GShard (https://t.me/gonzo_ML/473) активировал двух экспертов на слой, Switch Transformer (https://t.me/gonzo_ML/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. Также это может помочь модели лучше готовиться к предсказанию будущих токенов.