RedLLM, энкодер-декодер, применяет RoPE повсеместно: в модулях self-attention энкодера, self-attention декодера и cross-attention. Однако есть и проблемы: RedLLM была значительно более склонна к нестабильности во время обучения. Решение авторов работы — добавить дополнительный слой LN на выход механизма внимания:

Attn_RedLLM = LN(Attn_DecLLM)

Модели обучались в пяти масштабах, от 150M до 8B параметров, причём RedLLM сохраняла сбалансированную архитектуру с равным числом слоёв в энкодере и декодере.

Важно помнить, чем отличаются блоки внимания в чистом декодере и в декодере внутри энкодер-декодера. В классическом декодере, который был в энкодер-декодер архитектуре, каждый блок декодера содержал три слоя: causal self-attention + encoder-decoder self-attention (или cross-attention) + ffn. В чистом декодере типа GPT блоков меньше: causal self-attention + ffn. Подробно и с картинками разобрано у Jay Alammar здесь (https://jalammar.github.io/illustrated-gpt2/).

Размеры RedLLM и DecLLM делали одинаковыми, сохраняя при этом hidden dimension, из-за этого количество слоёв разнится -- у 8B моделей этой 32 слоя в чистом декодере и 14/14 слоёв для энкодера-декодера. Думаю, такая разница из-за отсутствия слоя cross-attention в чистом декодере, так как блоки энкодер-декодера получаются “жирнее” на один слой, что при фиксированной размерности модели приводит к увеличению общего веса, и надо сокращать количество блоков для паритета.

Модели предобучали на 1.6T токенов (RedPajama V1), а затем делали instruction-файнтюнинг на датасете FLAN. DecLLM предобучалась со стандартной задачей каузального языкового моделирования (Causal Language Modeling), а RedLLM на задаче префиксного языкового моделирования (Prefix Language Modeling), где первая половина последовательности служит входом для энкодера (префикс, и внимание там двунаправленное, в смысле токены могут заглядывать в будущее), а вторая половина — целью для декодера (с обычным каузальным вниманием с маской, не дающей токенам смотреть в будущее).

Такая постановка означает, что при одинаковых данных для предобучения (1.6 трлн токенов из RedPajama V1), эффективное количество целевых токенов для RedLLM (0.8 трлн) было вдвое меньше, чем для DecLLM.

Результаты интересны и состоят из двух частей, соответствующих разным этапам жизненного цикла LLM.

?? Этап 1: Преимущество DecLLM на предобучении

Изначально результаты, казалось бы, подтверждают предпочтения индустрии в пользу decoder-only моделей.

У DecLLM вычислительно-оптимальный скейлинг. На этапе предобучения она достигает меньшей перплексии при заданном объёме вычислений. Хотя обе архитектуры показывают схожие экспоненты скейлинга, RedLLM требует примерно вдвое больше FLOPs, чтобы достичь той же перплексии, что и DecLLM.

Лучшая производительность в zero/few-shot. После предобучения DecLLM демонстрирует значительно более сильные способности в zero-shot и few-shot режимах. В масштабе 8B её средний результат в few-shot на 8 пунктов выше, чем у RedLLM (43.37 против 35.13). Вероятно, это связано с тем, что задача Causal LM ближе к стандартным форматам оценки.

На этом этапе аргументы в пользу decoder-only моделей кажутся весомыми.

?? Этап 2: Реабилитация RedLLM через файнтюнинг

Картина кардинально меняется после instruction-файнтюнинга на датасете FLAN. RedLLM, несмотря на своё отставание на этапе предобучения, демонстрирует удивительную адаптивность. Это довольно сильно перекликается с их же работой про T5Gemma (https://arxiv.org/abs/2504.06225).

Сближение по качеству. После файнтюнинга RedLLM не только сокращает разрыв в производительности, но и достигает сравнимых и, в среднем, даже немного лучших результатов в zero-shot и few-shot режимах во всех масштабах. При 8B параметров few-shot результат RedLLM составляет 61.32, превосходя 59.02 у DecLLM. Получается, что производительность на предобучении не является окончательным предиктором возможностей итоговой, файнтюненной модели.