Прошло семь лет с момента разработки оригинальной архитектуры GPT. На первый взгляд, если оглянуться на GPT-2 (2019) и взглянуть вперёд на DeepSeek-V3 и Llama 4 (2024–2025), можно удивиться, насколько эти модели по-прежнему структурно схожи.

Разумеется, позиционные эмбеддинги эволюционировали от абсолютных к роторационным (RoPE), Multi-Head Attention в значительной степени уступил место Grouped-Query Attention, а более эффективная SwiGLU заменила такие функции активации, как GELU. Но если отбросить эти незначительные усовершенствования, действительно ли мы наблюдаем принципиальные архитектурные сдвиги — или просто продолжаем полировать одни и те же фундаментальные конструкции?

Сравнение LLM между собой с целью выявления ключевых факторов, влияющих на их качество (или недостатки), по-прежнему остаётся крайне нетривиальной задачей: датасеты, методы обучения и гиперпараметры сильно различаются и зачастую плохо документированы.

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

Итак, в этой статье я не буду рассуждать о результатах бенчмарков или алгоритмах обучения — вместо этого сосредоточусь на архитектурных нововведениях, которые определяют современные флагманские open-source модели.

1. DeepSeek V3/R1

Как вы, вероятно, уже не раз слышали, модель DeepSeek R1 произвела серьёзный эффект при релизе в январе 2025 года. DeepSeek R1 — это reasoning-модель, построенная на архитектуре DeepSeek V3, представленной в декабре 2024 года.

Хотя основное внимание в этом материале уделено архитектурам, выпущенным в 2025 году, считаю уместным включить сюда и DeepSeek V3, поскольку широкое внимание и активное принятие она получила только после запуска DeepSeek R1.

В этом разделе я сосредоточусь на двух ключевых архитектурных техниках, представленных в DeepSeek V3, которые повысили вычислительную эффективность и отличают её от большинства других LLM:

• Multi-Head Latent Attention (MLA)

• Mixture-of-Experts (MoE)

1.1 Multi-Head Latent Attention (MLA)

Прежде чем перейти к Multi-Head Latent Attention (MLA), кратко напомню контекст, объясняющий, зачем вообще возникла эта техника. Начнём с Grouped-Query Attention (GQA) — это замена Multi-Head Attention (MHA), ставшая в последние годы новым стандартом благодаря большей вычислительной и параметрической эффективности.

Кратко о GQA: в отличие от классического MHA, где у каждой attention head свой набор ключей и значений, в GQA несколько head'ов делят одни и те же проекции ключей и значений для снижения потребления памяти.

Например, как показано на рисунке 2 ниже: при наличии двух KV-групп и четырёх attention head'ов, головы 1 и 2 могут использовать одну общую пару {K, V}, а головы 3 и 4 — другую. Это снижает общее число операций над ключами и значениями, уменьшает использование памяти и повышает эффективность (без заметного ущерба для качества моделирования, что подтверждается абляционными экспериментами).

Идея GQA сводится к уменьшению количества K/V-пар путём их шаринга между query head'ами. Это:

1. Снижает общее количество параметров модели;

2. Уменьшает нагрузку на память при инференсе, так как в KV-кэше нужно хранить и считывать меньшее число K и V тензоров.

Хотя GQA — это прежде всего оптимизация на уровне эффективности, абляционные исследования (например, в оригинальной статье про GQA и в статье Llama 2) показывают, что по качеству моделирования она сопоставима с классическим MHA.

Теперь — к Multi-Head Latent Attention (MLA). Это другая стратегия сокращения памяти, особенно эффективно работающая с KV-кешированием. В отличие от GQA, которая шарит K/V между head'ами, MLA сжимает тензоры ключей и значений в пространство меньшей размерности перед тем, как они будут сохранены в KV-кэш.

Во время инференса эти сжатые тензоры обратно проецируются в исходное пространство перед использованием — как показано на рисунке 3 ниже. Это добавляет одну дополнительную матричную операцию, но позволяет существенно снизить объём используемой памяти.

(К слову, query-компоненты также подвергаются сжатию, но только во время обучения, а не во время инференса.)

Кстати, MLA появилась не впервые в DeepSeek-V3 — эта архитектура использовалась (и даже была представлена) ещё в DeepSeek-V2. Кроме того, в статье по V2 приведены интересные результаты абляционных экспериментов, которые могут объяснить, почему команда DeepSeek отдала предпочтение MLA, а не GQA (см. рисунок 4 ниже).

Как показано на рисунке 4 выше, GQA демонстрирует более низкие результаты по сравнению с MHA, в то время как MLA обеспечивает лучшее качество моделирования, чем MHA — вероятно, именно поэтому команда DeepSeek выбрала MLA вместо GQA.

Резюмируя: MLA — это изящный приём, позволяющий сократить объём KV-кэша, при этом немного превосходя MHA по качеству моделирования.

1.2 Mixture-of-Experts (MoE)

Другим важным архитектурным компонентом в DeepSeek, заслуживающим внимания, является использование слоёв Mixture-of-Experts (MoE). Хотя MoE и не является изобретением DeepSeek, в этом году она вновь набрала популярность, и многие архитектуры, которые будут рассмотрены далее, также её используют.

Скорее всего, ты уже знаком с концепцией MoE, но короткое напоминание будет уместно.

Базовая идея MoE заключается в том, чтобы заменить каждый FeedForward-модуль в блоке трансформера на несколько expert-слоёв, каждый из которых по сути является таким же FeedForward-модулем. То есть вместо одного FeedForward-блока мы подставляем несколько, как показано на рисунке 5 ниже.

FeedForward-блок внутри трансформера (на рисунке выше он показан тёмно-серым цветом) содержит значительную часть всех параметров модели. (Стоит отметить, что блок трансформера, а вместе с ним и FeedForward-блок, повторяются многократно в LLM; в случае DeepSeek-V3 — 61 раз.)

Таким образом, замена одного FeedForward-блока на несколько (в MoE-конфигурации) существенно увеличивает общее число параметров модели. Однако ключевой трюк заключается в том, что не все эксперты используются ("активируются") для каждого токена. Вместо этого маршрутизатор выбирает лишь небольшое подмножество экспертов для каждого токена.

Поскольку активны только некоторые эксперты, MoE-модули часто называют разрежёнными (sparse), в отличие от плотных (dense) модулей, в которых участвуют все параметры. При этом большое общее количество параметров в MoE повышает ёмкость модели, то есть её способность усваивать больше знаний в процессе обучения. Разреженность же позволяет сохранить эффективность на этапе инференса, так как одновременно задействуется лишь небольшая часть параметров.

Например, в DeepSeek-V3 используется 256 экспертов на MoE-модуль, а общее количество параметров достигает 671 миллиарда. Но во время инференса одновременно активны только 9 экспертов (1 общий и 8, выбранных маршрутизатором). Это означает, что в расчёте на один шаг инференса задействуется лишь 37 миллиардов параметров — вместо всех 671.

Одной из примечательных особенностей MoE-дизайна в DeepSeek-V3 является использование shared expert — эксперта, который всегда активен для любого токена. Эта идея не нова: она была представлена в статьях DeepSeek 2024 MoE и ещё раньше — в DeepSpeedMoE (2022).

Преимущества наличия общего эксперта были впервые отмечены именно в DeepSpeedMoE, где показано, что это улучшает общее качество моделирования по сравнению с конфигурациями без shared expert. Вероятная причина — в том, что общие или повторяющиеся паттерны не нужно учить каждому индивидуальному эксперту отдельно, что оставляет больше места для обучения специализированных шаблонов.

1.3 Краткий итог по DeepSeek

Подводя итог: DeepSeek-V3 — это огромная модель с 671 миллиардом параметров, которая на момент запуска опережала все другие open-weight модели, включая Llama 3 на 405B. Несмотря на больший размер, модель гораздо эффективнее на этапе инференса за счёт архитектуры Mixture-of-Experts (MoE), где одновременно активируются только 37 миллиардов параметров на токен.

Другим ключевым отличием DeepSeek-V3 является использование Multi-Head Latent Attention (MLA) вместо Grouped-Query Attention (GQA). Обе схемы — это более эффективные альтернативы классической Multi-Head Attention (MHA) при использовании KV-кэша. Несмотря на большую сложность реализации MLA, исследования в статье по DeepSeek-V2 показывают, что она обеспечивает более высокое качество моделирования по сравнению с GQA.

2. OLMo 2

Серия моделей OLMo, разработанная некоммерческим Институтом искусственного интеллекта Аллена (Allen Institute for AI), заслуживает внимания благодаря своей прозрачности в отношении обучающих данных и кода, а также достаточно подробной технической документации.

Хотя вы вряд ли увидите OLMo в топах бенчмарков или лидербордов, модели из этой серии довольно «чистые» и, что более важно, служат отличным референсом для разработки LLM благодаря своей открытости.

Несмотря на то, что популярность OLMo 2 в первую очередь связана с прозрачностью, с точки зрения производительности они тоже вполне конкурентоспособны. На момент релиза в январе (до появления Llama 4, Gemma 3 и Qwen 3) модели OLMo 2 находились на границе Парето по соотношению вычислительных затрат и качества, как показано на рисунке 7 ниже.

Как уже упоминалось ранее, в рамках этой статьи я сосредотачиваюсь только на архитектурных особенностях LLM (без углубления в данные и обучение), чтобы сохранить объём в разумных пределах. Так что же интересного в архитектуре OLMo 2? В основном — это нормализации: размещение слоёв RMSNorm, а также добавление QK-norm, о чём будет сказано ниже.

Также стоит отметить, что OLMo 2 по-прежнему использует классический Multi-Head Attention (MHA), а не MLA или GQA.

2.1 Размещение слоёв нормализации

В целом, OLMo 2 в значительной степени наследует архитектуру оригинальной модели GPT, как и большинство современных LLM. Однако есть несколько важных отличий. Начнём со слоёв нормализации.

Подобно Llama, Gemma и большинству других LLM, OLMo 2 перешёл от LayerNorm к RMSNorm.

Но поскольку RMSNorm — это уже пройденный этап (по сути, упрощённая версия LayerNorm с меньшим числом обучаемых параметров), я не буду подробно разбирать различия между RMSNorm и LayerNorm.

Тем не менее, стоит обсудить именно размещение слоя RMSNorm. В оригинальном трансформере (в статье “Attention is all you need”) два слоя нормализации располагались внутри трансформерного блока — после модуля внимания и после FeedForward-модуля соответственно.

Такое размещение известно как Post-LN или Post-Norm.

GPT и большинство последующих LLM стали размещать слои нормализации до модулей внимания и FeedForward, что получило название Pre-LN или Pre-Norm. Сравнение Post- и Pre-Norm представлено на схеме ниже.

В 2020 году Xiong и соавт. показали, что Pre-LN даёт более устойчивые градиенты на инициализации. Также было отмечено, что Pre-LN хорошо работает даже без тщательной настройки learning rate warm-up, которая обычно критична для Post-LN.

OLMo 2 же применяет разновидность Post-LN (с RMSNorm вместо LayerNorm, поэтому я называю это просто Post-Norm).

В OLMo 2 нормализация располагается после attention и FeedForward, как показано на рисунке ниже. Но при этом, в отличие от оригинального трансформера, нормализация остаётся внутри резидуальных связей (skip connections).

Зачем понадобилось перемещать нормализацию? Ответ — для улучшения стабильности обучения, как показано на графике ниже.

К сожалению, на графике приведён эффект одновременно от перестановки нормализации и применения QK-Norm, так что невозможно точно оценить вклад каждой из техник по отдельности.

2.2 QK-Norm

Поскольку в предыдущем разделе уже упоминался QK-Norm, а в других моделях, о которых пойдёт речь позже (например, Gemma 2 и 3), он тоже используется, кратко объясню, что это.

QK-Norm — это ещё один слой RMSNorm. Он вставляется внутрь модуля Multi-Head Attention и применяется к векторам queries (q) и keys (k) до применения позиционного кодирования RoPE. Ниже приведён фрагмент реализации слоя Grouped-Query Attention (GQA), написанный для реализации Qwen 3 с нуля — применение QK-Norm в GQA аналогично его использованию в MHA у OLMo:

class GroupedQueryAttention(nn.Module):
    def __init__(
        self, d_in, num_heads, num_kv_groups,
        head_dim=None, qk_norm=False, dtype=None
    ):
        # ...

        if qk_norm:
            self.q_norm = RMSNorm(head_dim, eps=1e-6)
            self.k_norm = RMSNorm(head_dim, eps=1e-6)
        else:
            self.q_norm = self.k_norm = None

    def forward(self, x, mask, cos, sin):
        b, num_tokens, _ = x.shape

        # Apply projections
        queries = self.W_query(x) 
        keys = self.W_key(x)
        values = self.W_value(x) 

        # ...

        # Optional normalization
        if self.q_norm:
            queries = self.q_norm(queries)
        if self.k_norm:
            keys = self.k_norm(keys)

        # Apply RoPE
        queries = apply_rope(queries, cos, sin)
        keys = apply_rope(keys, cos, sin)

        # Expand K and V to match number of heads
        keys = keys.repeat_interleave(self.group_size, dim=1)
        values = values.repeat_interleave(self.group_size, dim=1)

        # Attention
        attn_scores = queries @ keys.transpose(2, 3)
        # ...

Как уже говорилось, вместе с Post-Norm, QK-Norm улучшает стабильность обучения. Отмечу, что QK-Norm был придуман не в OLMo 2 — он появился ещё в статье Scaling Vision Transformers в 2023 году.

2.3 Краткий итог по OLMo 2

Если кратко, ключевые архитектурные особенности OLMo 2 сводятся к следующему:

• использование RMSNorm вместо LayerNorm;

• размещение RMSNorm после, а не до attention и FeedForward (вариант Post-Norm);

• добавление RMSNorm к queries и keys внутри attention-механизма (QK-Norm).

Обе эти модификации в совокупности улучшают стабильность функции потерь на обучении.

Ниже приведена сравнительная схема OLMo 2 и Llama 3 — как видно, архитектуры во многом схожи, за исключением того, что OLMo 2 продолжает использовать традиционный MHA, а не GQA. (Хотя команда OLMo выпустила версию на 32B спустя 3 месяца, в которой уже используется GQA.)

3. Gemma 3

Модели Gemma от Google всегда были весьма сильными, но, на мой взгляд, традиционно недооценёнными по сравнению с более «громкими» моделями, такими как серия LLaMA.

Одной из отличительных черт Gemma является довольно крупный словарь — это сделано для лучшей поддержки мультиязычности. Кроме того, у моделей акцент именно на размер 27B (в отличие от 8B или 70B). При этом стоит отметить, что Gemma 2 также доступна в меньших конфигурациях: 1B, 4B и 12B.

27B — это действительно удачный компромисс: модель заметно мощнее 8B, но при этом не требует таких ресурсов, как 70B.

Что ещё интересного в Gemma 3? Как мы уже обсуждали ранее, модели вроде DeepSeek-V3/R1 используют архитектуру Mixture-of-Experts (MoE) для снижения требований к памяти при инференсе при фиксированном размере модели. (Подход MoE используется и в других моделях, о которых мы поговорим позже.)

Gemma 3 применяет иной «трюк» для сокращения вычислительных затрат — sliding window attention.

3.1 Sliding Window Attention

Благодаря механизму sliding window attention (впервые представленному в работе LongFormer в 2020 году и уже применявшемуся в Gemma 2), команде Gemma 3 удалось существенно сократить требования к памяти в KV-кэше — как показано на схеме ниже.

Так что же такое sliding window attention? Если стандартный self-attention можно рассматривать как глобальный механизм внимания (каждый токен может взаимодействовать со всеми остальными), то sliding window attention — это локальное внимание, поскольку здесь область контекста ограничена определённым окном вокруг текущей query-позиции. Это показано на иллюстрации ниже.

Важно: sliding window attention можно использовать как с Multi-Head Attention, так и с Grouped-Query Attention (GQA); в Gemma 3 используется GQA.

Как упомянуто выше, sliding window attention также называют локальным вниманием, потому что окно ограничено и «скользит» вместе с позицией query. В отличие от этого, обычное self-attention глобально — каждый токен может взаимодействовать со всеми другими токенами.

Следует также отметить, что архитектура Gemma 2 тоже использовала sliding window attention. Разница в Gemma 3 — в изменении соотношения между глобальным и локальным вниманием.

Например, в Gemma 2 применялась гибридная схема: sliding window (локальное) внимание и глобальное внимание использовались в соотношении 1:1. Каждый токен имел доступ к контексту в окне шириной 4k токенов.

В то время как Gemma 2 использовала локальное внимание через один слой, в Gemma 3 это соотношение стало 5:1 — то есть, на каждые 5 слоёв с sliding window attention приходится всего 1 слой с глобальным вниманием. Более того, размер окна был уменьшен с 4096 (в Gemma 2) до 1024 токенов (в Gemma 3). Это делает модель более эффективной и смещает акцент в сторону локализованных вычислений.

Согласно их ablation-исследованию, использование sliding window attention практически не влияет на качество моделирования, что видно из графика ниже.

Хотя sliding window attention — наиболее заметная архитектурная особенность Gemma 3, я также кратко затрону размещение слоёв нормализации, как продолжение секции про OLMo 2.

3.2 Размещение слоев нормализации в Gemma 3

Небольшой, но интересный момент, заслуживающий внимания: в Gemma 3 используется RMSNorm как в Pre-Norm, так и в Post-Norm конфигурации вокруг модуля grouped-query attention.

Это схоже с тем, что было реализовано в Gemma 2, но всё же стоит отметить, поскольку отличается от:

1. Post-Norm-схемы, применённой в оригинальном Transformer (“Attention is all you need”),

2. Pre-Norm, ставшего популярным с GPT-2 и используемого во многих последующих архитектурах,

3. Post-Norm-варианта в OLMo 2, который мы уже рассматривали ранее.

Считаю такой подход к размещению слоя нормализации достаточно интуитивным: он позволяет получить преимущества как Pre-Norm, так и Post-Norm. На мой взгляд, немного дополнительной нормализации — это не проблема. В худшем случае, если она окажется избыточной, мы просто получим небольшую неэффективность из-за дублирования. На практике же, учитывая относительную «дешевизну» RMSNorm с точки зрения вычислений, это не должно существенно повлиять на производительность.

3.3 Сводка по Gemma 3

Gemma 3 — это хорошо сбалансированная LLM, которая, как мне кажется, недооценена в open-source-среде. Самая интересная особенность — использование sliding window attention для повышения эффективности (будет любопытно посмотреть на её комбинацию с MoE в будущем).

Также у Gemma 3 уникальное размещение слоёв нормализации: RMSNorm применяется как до, так и после модулей attention и FeedForward.

3.4 Бонус: Gemma 3n

Через несколько месяцев после релиза Gemma 3 компания Google представила Gemma 3n — модификацию модели Gemma 3, оптимизированную под ограниченные вычислительные ресурсы с целью запуска на мобильных устройствах.

Одна из ключевых оптимизаций в Gemma 3n — использование слоя с параметрами Per-Layer Embedding (PLE). Основная идея здесь заключается в том, чтобы держать только подмножество параметров модели в памяти GPU. Эмбеддинги, специфичные для токенов и модальностей (текст, аудио, визуальные данные), подгружаются по мере необходимости из CPU или SSD.

На диаграмме ниже показана экономия памяти благодаря PLE: указывается 5.44 миллиарда параметров для стандартной версии Gemma 3. Вероятно, речь идёт о варианте Gemma 3 с 4 миллиардами параметров.

Несоответствие между 5.44 и 4 миллиардами объясняется тем, что Google использует нестандартный способ подсчёта параметров в LLM: эмбеддинги часто исключаются из общего числа параметров, чтобы модель казалась «меньше» — за исключением случаев, когда выгоднее указать большую цифру. Такая практика характерна не только для Google, но и стала общераспространённой в индустрии.

Ещё один интересный трюк — концепция MatFormer (сокращение от Matryoshka Transformer). Например, в Gemma 3n используется одна общая трансформер-архитектура, которую можно разрезать на более мелкие, автономно работающие части. Каждая такая «срезка» обучается выполнять задачи самостоятельно, так что на этапе инференса можно использовать только ту часть модели, которая реально нужна, без необходимости загружать всю архитектуру целиком.

4. Mistral Small 3.1

Модель Mistral Small 3.1 с 24 миллиардами параметров, выпущенная в марте вскоре после релиза Gemma 3, примечательна тем, что превзошла Gemma 3 27B по ряду бенчмарков (за исключением задач по математике), при этом обеспечивая более высокую скорость.

Низкая задержка инференса у Mistral Small 3.1 по сравнению с Gemma 3, вероятно, объясняется использованием кастомного токенизатора, а также сокращением объёма KV-кэша и количества слоёв. В остальном архитектура довольно стандартна, как показано на рисунке ниже.

Интересно, что более ранние версии моделей Mistral использовали sliding window attention, но от этой механики, похоже, отказались в Mistral Small 3.1. Таким образом, поскольку Mistral применяет обычный Grouped-Query Attention, а не Grouped-Query Attention с использованием скользящего окна, как в Gemma 3, возможно, появляются дополнительные преимущества в производительности за счёт возможности задействовать более оптимизированный код (например, FlashAttention). Я предполагаю, что хотя sliding window attention снижает потребление памяти, это не обязательно ведёт к снижению задержки инференса — а именно на этом сделан фокус в Mistral Small 3.1.

5. Llama 4

Развёрнутое обсуждение архитектуры Mixture-of-Experts (MoE), приведённое ранее в статье, вновь оказывается полезным — Llama 4 также реализует MoE-подход, при этом в остальном она использует довольно стандартную архитектуру, во многом схожую с DeepSeek-V3, как показано на схеме ниже. (Llama 4 изначально поддерживает мультимодальность — как и Gemma или Mistral. Однако в данной статье акцент сделан на языковом моделировании, поэтому рассматривается только текстовая часть модели.)

Хотя архитектура Llama 4 Maverick визуально очень похожа на DeepSeek-V3, между ними есть ряд примечательных различий.

Во-первых, Llama 4, как и её предшественники, использует Grouped-Query Attention, тогда как в DeepSeek-V3 реализован Multi-Head Latent Attention — мы подробно разбирали его в начале статьи. Обе модели относятся к крупным архитектурам, при этом DeepSeek-V3 примерно на 68% превосходит Llama 4 по общему количеству параметров. Однако по числу активных параметров перевес ещё более значителен: DeepSeek-V3 использует 37 миллиардов активных параметров против 17 миллиардов у Llama 4 Maverick.

В Llama 4 Maverick реализована более классическая конфигурация MoE — меньшее число, но более «тяжёлые» эксперты (2 активных эксперта с размерностью скрытого слоя 8192), в то время как в DeepSeek-V3 задействовано 9 активных экспертов с размерностью скрытого слоя по 2048. Кроме того, DeepSeek вставляет MoE-слои в каждый transformer-блок (за исключением первых трёх), тогда как Llama 4 чередует MoE и плотные (dense) модули в каждом втором блоке.

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

6. Qwen3

Qwen3 — очередная успешная серия, лидирующая в своей размерной категории. В линейке представлено 7 "плотных" (dense) моделей: 0.6B, 1.7B, 4B, 8B, 14B и 32B. И 2 модели с архитектурой Mixture-of-Experts: 30B-A3B и 235B-A22B.

(К слову, отсутствие пробела в “Qwen3” — не опечатка; я намеренно сохраняю оригинальное написание, выбранное разработчиками Qwen.)

6.1 Qwen3 (плотная архитектура)

Начнём с плотных моделей. На момент написания статьи модель 0.6B, возможно, является самой компактной среди современных open-weight LLM. И, по моему личному опыту, она показывает отличные результаты для своего размера. У неё высокая пропускная способность (tokens/sec) и небольшой объём используемой памяти — если вы планируете запускать её локально. Более того, благодаря малому числу параметров её удобно обучать локально (в образовательных целях).

Для большинства задач у меня Qwen3 0.6B уже вытеснила Llama 3 1B. Ниже приведено сравнение этих двух архитектур.

Представленные выше показатели вычислительной производительности получены с моей реализации на PyTorch при запуске на GPU A100. Как видно, Qwen3 имеет меньший объём памяти за счёт компактной архитектуры: используются более узкие скрытые слои и меньшее число attention-head'ов. Однако при этом в модели больше трансформер-блоков, чем в Llama 3, что приводит к более медленной генерации (ниже скорость в токенах в секунду).

6.2 Qwen3 (MoE)

Как уже упоминалось, Qwen3 также выпускается в двух MoE-вариантах: 30B-A3B и 235B-A22B. Почему одни архитектуры, вроде Qwen3, имеют как обычные (dense), так и MoE (sparse) версии?

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

Dense-модели, как правило, проще в fine-tuning’е, деплое и оптимизации под различное оборудование.

С другой стороны, MoE-модели оптимизированы под масштабируемый инференс. Например, при фиксированном бюджете на инференс они обеспечивают большую общую модельную ёмкость (то есть, способность поглощать знания на этапе обучения, за счёт увеличения размеров модели), при этом без пропорционального роста затрат на инференс.

Благодаря выпуску обеих версий, серия Qwen3 охватывает широкий спектр сценариев использования: dense-модели — для устойчивости, простоты и fine-tuning’а, а MoE-модели — для эффективного масштабируемого сервинга.

Чтобы завершить этот раздел, давайте сравним Qwen3 235B-A22B (обратите внимание, что A22B означает «22B активных параметров») с DeepSeek-V3, у которой почти вдвое больше активных параметров — 37B.

Как видно на графике выше, архитектуры DeepSeek-V3 и Qwen3 235B-A22B крайне схожи. Однако важно отметить, что Qwen3 отказались от использования shared expert — в то время как более ранние модели, такие как Qwen2.5-MoE, использовали общего эксперта.

К сожалению, команда Qwen3 не раскрыла причины, по которым они отказались от shared expert. Если предположить, возможно, это оказалось ненужным для обеспечения стабильности обучения при увеличении числа экспертов с 2 (в Qwen2.5-MoE) до 8 (в Qwen3). Таким образом, они смогли сэкономить ресурсы (вычисления/память), задействовав только 8, а не 8+1 экспертов. (Хотя это не объясняет, почему DeepSeek-V3 до сих пор использует shared expert.)

Обновление. Junyang Lin, один из разработчиков Qwen3, прокомментировал это следующим образом:

«В тот момент мы не увидели достаточно заметного прироста от использования shared expert и нас беспокоили возможные сложности с оптимизацией инференса, которые он может вызвать. Если честно, однозначного ответа на этот вопрос у нас нет».

7. SmolLM3

SmolLM3, возможно, не так популярен, как другие LLM, рассмотренные в этой статье, но он всё же заслуживает внимания: модель демонстрирует отличные показатели при относительно скромных и удобных 3 миллиардах параметров — промежуточном размере между 1.7B и 4B вариантами Qwen3, как показано на рисунке ниже.

Кроме того, как и в случае с OLMo, команда поделилась большим количеством информации о тренировочном процессе, что редкость и всегда высоко ценится.

Как видно из сравнительной схемы архитектур, SmolLM3 использует довольно стандартную архитектуру. Возможно, наиболее интересной особенностью модели является применение NoPE (No Positional Embeddings).

7.1 NoPE (No Positional Embeddings)

NoPE — это достаточно старая идея в контексте LLM, восходящая к статье 2023 года The Impact of Positional Encoding on Length Generalization in Transformers, где предлагалось отказаться от явной инъекции позиционной информации (например, через абсолютные позиционные эмбеддинги в ранних архитектурах GPT или современный RoPE).

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

RoPE же действует иначе — он модифицирует (ротирует) векторы запросов и ключей в зависимости от позиции токена.

В слоях NoPE позиционный сигнал не добавляется вообще: ни фиксированный, ни обучаемый, ни относительный — никакой.

Несмотря на отсутствие явного позиционного кодирования, модель всё равно понимает порядок токенов благодаря маске причинности (causal attention mask), которая запрещает каждому токену «заглядывать» в будущее. Таким образом, токен в позиции t может «видеть» только токены в позициях ≤ t, что сохраняет автоагрессивный порядок.

Иными словами, хотя позиционная информация и не добавляется явно, в архитектуре модели всё равно есть встроенное направление, и модель может научиться использовать это при обучении градиентным спуском, если это помогает минимизировать loss. (Подробности — в теоремах из оригинальной статьи про NoPE.)

В целом, авторы статьи про NoPE показали не только то, что явное позиционное кодирование не обязательно, но и то, что отказ от него улучшает length generalization — способность LLM сохранять качество ответов при увеличении длины входной последовательности (см. график ниже).

Важно понимать, что эксперименты проводились на относительно маленькой GPT-подобной модели (~100M параметров) и с ограниченной длиной контекста. Пока неясно, насколько эти выводы масштабируются на современные крупные LLM.

Возможно, именно поэтому команда SmolLM3 применяет NoPE (или точнее, опускает RoPE) только в каждом четвёртом слое.

8. Kimi 2

Kimi 2 недавно наделал немало шума в AI-сообществе как open-weight модель с выдающейся производительностью. Согласно бенчмаркам, она наравне с лучшими проприетарными системами — такими как Gemini от Google, Claude от Anthropic и модели ChatGPT от OpenAI.

Особого внимания заслуживает использование варианта относительно нового оптимизатора Muon вместо классического AdamW. Насколько мне известно, это первый случай применения Muon в продакшн-модели такого масштаба — ранее он демонстрировал масштабируемость только до 16B параметров. Это дало отличную динамику функции потерь во время обучения, что, вероятно, и помогло модели резко вырваться в лидеры среди аналогов.

Хотя многие отмечали, что loss получился необычайно гладким (без характерных скачков), я бы не сказал, что он исключительно гладкий (например, посмотрите на кривую loss у OLMo 2 на графике ниже; к тому же, L2-норма градиента, возможно, была бы лучшей метрикой стабильности обучения). Но что действительно впечатляет — это скорость и стабильность убывания loss.

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

Сама модель содержит 1 триллион параметров, что по-настоящему впечатляет.

На момент написания статьи это, вероятно, самая крупная LLM текущего поколения, если учитывать, что:

• LLaMA 4 Behemoth ещё не вышла,

• проприетарные LLM не учитываются,

• а 1.6-триллионный Switch Transformer от Google — это энкодер-декодер архитектура из другого поколения.

Таким образом, круг замыкается: Kimi 2 использует архитектуру DeepSeek-V3, с которой мы начали эту статью, только в более масштабном виде, как показано на схеме ниже.

Как видно, Kimi 2.5 — это по сути тот же DeepSeek V3, но с большим числом экспертов в MoE-модулях и меньшим числом голов в модуле Multi-head Latent Attention (MLA).

Стоит отметить, что Kimi 2 — не взявшийся из ниоткуда проект. Более ранняя модель — Kimi 1.5, подробно описанная в статье Kimi k1.5: Scaling Reinforcement Learning with LLMs, уже тогда выглядела многообещающей. Однако ей не повезло: статья про DeepSeek R1 вышла в тот же день — 22 января. Кроме того, насколько мне известно, веса Kimi 1.5 так и не были опубликованы.

Судя по всему, команда Kimi учла этот опыт и выложила Kimi K2 как open-weight модель до релиза DeepSeek R2.

На момент написания, Kimi K2 — самая впечатляющая open-weight модель, доступная сообществу.

Заключение

Эволюция архитектур LLM в последние годы шла по пути итеративных улучшений, а не революционных прорывов. Технологии, такие как GQA, SwiGLU и RoPE, стали стандартом. В 2025 году мы наблюдаем взрыв популярности архитектур Mixture-of-Experts (MoE), которые позволяют создавать огромные модели (Llama 4, DeepSeek-V3, Kimi K2) с эффективным инференсом. Эти тенденции определяют будущее больших языковых моделей, предлагая разработчикам все более мощные и эффективные инструменты.