В мире больших языковых моделей (LLM) существует устойчивое заблуждение: чем больше параметров у модели, тем она умнее. Однако инженеры, занимающиеся развертыванием ИИ, знают, что это не совсем так. Ключевым фактором становится не просто количество параметров, а то, как модель их организует. Сегодня на сцене доминируют два подхода: Dense (плотные) модели и Mixture-of-Experts (MoE, смешанные эксперты). Выбор между ними — это не вопрос «что лучше», а вопрос «что подходит для ваших ограничений».
Представьте себе два двигателя с одинаковым рабочим объемом. Один сжигает топливо во всех цилиндрах при каждом такте, обеспечивая стабильную, но ресурсоемкую мощность. Другой активирует только те цилиндры, которые нужны в данный момент, экономя топливо, но требуя сложной системы управления. Именно так работают современные архитектуры LLM. В этой статье мы глубоко разберем, как устроены Dense и MoE модели, почему Nemotron 3.5 Lightning может активировать лишь 3 миллиарда из 30 миллиардов параметров, и как это влияет на стоимость и скорость вашего сервиса.
01Архитектурные основы: Плотность против Экспертов
Чтобы понять разницу, нужно заглянуть внутрь нейронной сети. В классической Dense-модели каждый токен, который вы вводите, проходит через все параметры сети. Если у вас есть модель на 27 миллиардов параметров, то для обработки каждого отдельного токена (слова или части слова) вычислительные мощности задействуют все эти 27 миллиардов весов. Это происходит в блоке Feed-Forward Network (FFN) каждого декодирующего слоя. Проще говоря, Dense-модель — это «все или ничего»: она всегда использует полную вычислительную мощность, независимо от сложности задачи.
MoE-модели предлагают иной подход. Вместо одного общего блока FFN, они содержат множество таких блоков, называемых «экспертами». Внутри каждого слоя может быть от 8 до 128 таких экспертов. Когда токен поступает в модель, специальная сеть-маршрутизатор (router) решает, к каким именно экспертам его направить. Обычно выбирается топ-k экспертов (например, 2 или 4), которые наиболее релевантны для данного токена. Остальные эксперты в этом слое остаются «спящими» и не участвуют в вычислениях для этого конкретного токена.
Важно отметить, что маршрутизация происходит на каждом слое отдельно. Токен не «прикрепляется» к одному эксперту навсегда; он перенаправляется заново на каждом этапе обработки. При этом механизм внимания (attention) работает для всех токенов полностью, как и в Dense-моделях. Когда в спецификации модели говорится «3B активных параметров», это включает в себя веса внимания и эмбеддинги для всех токенов, плюс веса только тех FFN-экспертов, которые были выбраны маршрутизатором.
02Как работает маршрутизация в MoE
Механизм маршрутизации в MoE-моделях — это не магия, а математическая оптимизация. Маршрутизатор (gate network) оценивает входной токен и присваивает баллы каждому доступному эксперту. Токен отправляется тем экспертам, которые набрали наибольший балл. Это позволяет модели эффективно масштабировать свою емкость без пропорционального увеличения вычислительных затрат на каждый шаг.
Интересно, что «экспертиза» в MoE-моделях часто не связана с семантическим пониманием темы (как, например, «эксперт по медицине»). Чаще всего специализация экспертов лежит в области синтаксиса и паттернов токенов: пунктуация, числа, специфические языковые конструкции. Однако это зависит от архитектуры и методов обучения. Некоторые современные модели, такие как Mistral Small 4, также используют «общего» эксперта, к которому маршрутизируются все токены, чтобы обеспечить базовую стабильность.
Существуют и гибридные варианты. Например, в модели Nemotron 3.5 Lightning используется архитектура Mamba-2 + MoE + Attention. Слои Mamba-2 заменяют механизм внимания в большинстве слоев, используя состояние с постоянным размером (recurrent state), а не растущий KV-cache. Это кардинально меняет профиль памяти при работе с длинными контекстами, добавляя еще один уровень эффективности, который не учитывается простой разреженностью (sparsity) MoE.
03Производительность: Пропускная способность против Задержки
Главный вопрос, который волнует разработчиков: что быстрее? Ответ зависит от контекста. MoE-модели часто обеспечивают более высокую пропускную способность (throughput) — то есть количество токенов, сгенерированных в секунду, — потому что они активируют только подмножество параметров. Dense-модели, напротив, могут предлагать более простую службу и предсказуемую задержку (latency) при низких нагрузках.
Ключевое различие заключается в том, как модели масштабируют память и вычисления. В Dense-модели стоимость хостинга (память) и инференса (вычисления) масштабируются вместе. В MoE-модели эти затраты разделены. Вы платите за память заранее: все эксперты должны быть загружены в VRAM видеокарты. Но вычисления происходят только для активных экспертов. «Спящие» эксперты не требуют вычислительных ресурсов, хотя и занимают место в памяти. Это превращает переменные затраты на токено-вычисления в фиксированные затраты на память.
При размере батча (batch size) 1, декодирование ограничено доступной памятью, а не вычислительной мощностью. Здесь MoE выигрывает, так как считывает меньше байтов весов на токен. Однако по мере роста размера батча токены коллективно начинают использовать большинство экспертов в сети. В этом случае преимущество MoE сужается, хотя снижение работы на токен сохраняется. Таким образом, MoE сохраняет преимущество по пропускной способности при любых размерах батча, но разрыв в задержке по сравнению с хорошо оптимизированной Dense-моделью уменьшается при высокой конкурентности.
04Практическое сравнение: Nemotron 3.5 Lightning против Gemma 4
Давайте посмотрим на цифры. Сравним модели с примерно одинаковым общим количеством параметров (~30B). С одной стороны, у нас есть Gemma 4 31B (Dense, мультимодальная), а с другой — Nemotron 3.5 Lightning (MoE + Mamba-2, 30B общих, 3B активных).
Несмотря на то, что Gemma 4 имеет больше параметров (31B против 30B), Nemotron 3.5 Lightning демонстрирует значительно более высокую скорость вывода. Данные от Artificial Analysis показывают, что Nemotron 3.5 Lightning генерирует от 235.7 до 494.2 токенов в секунду, в то время как Gemma 4 выдает от 36.9 до 222.4 токенов в секунду. Это колоссальная разница. Кроме того, стоимость вывода одного миллиона токенов у Nemotron составляет около $0.22, тогда как у Gemma 4 — $0.40. А если сравнить с Qwen3.8-27B (Dense), то Nemotron работает в 4-5 раз быстрее и стоит в 14 раз дешевле.
Однако важно понимать цену этого преимущества. Nemotron 3.5 Lightning набирает меньше баллов в тестах на общую способность (Intelligence Index: 24 против 30 у Gemma 4). Это означает, что для сложных задач логического вывода (reasoning), где требуется глубокий анализ, Dense-модель может быть предпочтительнее. Но для агентных задач, где нужно быстро выполнять множество хорошо определенных шагов, MoE-архитектура идеальна.
05Когда выбирать Dense, а когда MoE?
Выбор архитектуры должен основываться на ваших конкретных ограничениях развертывания. Вот четыре ключевых фактора, которые нужно учесть.
1. Бюджет памяти
Память MoE-модели определяется общим количеством параметров, а не активными. Это значит, что для размещения 30B MoE-модели и 30B Dense-модели потребуется примерно одинаковый объем VRAM (около 60 ГБ для BF16 на одной H100). Вопрос в том, что вы получаете за эти гигабайты. Dense-модель конвертирует память в «интеллект» и емкость. MoE-модель конвертирует память в пропускную способность. Если у вас ограничена память, но нужна высокая скорость обработки множества запросов, MoE выигрывает.
2. Конкурентность (Concurrency)
MoE явно выигрывает при обработке одиночных запросов (batch size 1). При масштабировании конкурентности преимущество MoE сохраняется, но разрыв в задержке сужается. Если ваше приложение чувствительно к задержкам при высокой нагрузке (например, чат-бот с тысячами одновременных пользователей), обязательно проведите бенчмаркинг обеих архитектур. Dense-модели могут предложить более стабильную задержку в пиковых нагрузках.
3. Планы по дообучению (Fine-Tuning)
Dense-модели проще дообучать. Все параметры активны, градиенты распространяются равномерно. Полное дообучение MoE-модели может привести к дисбалансу маршрутизатора: некоторые эксперты могут стать слишком популярными, а другие — полностью выйти из употребления. Для MoE рекомендуется использовать методы LoRA/PEFT или замораживать маршрутизатор. Например, рецепт контролируемого дообучения (SFT) от NVIDIA для Nemotron 3.5 Lightning специально разработан для предотвращения этого дисбаланса.
4. Квантование
Квантование (сжатие модели) по-разному влияет на Dense и MoE архитектуры. Во-первых, проверьте исходную точность чекпоинта. Mistral Small 4 изначально выпущен в формате FP8, поэтому квантование до 4-бит дает прирост лишь ~1.7x (121 ГБ → 71 ГБ), а не ожидаемые 4x. Во-вторых, разные архитектуры по-разному реагируют на сжатие. В MoE-моделях критически важно сохранять маршрутизатор (router), эмбеддинги и выходной заголовок в высокой точности, так как малые возмущения могут изменить дискретные решения маршрутизации. В гибридных моделях с вниманием, таких как Qwen3.8-27B, блок линейного внимания часто оставляют в BF16, чтобы избежать деградации качества.
06Гибридные архитектуры и будущее
Мы наблюдаем переход от чистых Transformer-архитектур к гибридным. Использование Mamba-2 в Nemotron 3.5 Lightning — яркий пример того, как можно комбинировать сильные стороны разных подходов. Mamba-2 обеспечивает эффективную обработку длинных контекстов с постоянной памятью, а MoE обеспечивает высокую пропускную способность. Такие гибриды открывают новые возможности для развертывания LLM в условиях жестких ограничений по ресурсам.
Кроме того, развитие агентного ИИ (Agentic AI) требует моделей, которые могут быстро выполнять множество действий. Здесь MoE-модели, такие как Nemotron 3.5 Lightning, становятся стандартом де-факто благодаря своей скорости и эффективности. Для физических ИИ-задач (Physical AI), таких как управление роботами, также популярны решения, оптимизированные под низкую задержку и высокую надежность.
07Что это значит на практике
Итак, как применить эти знания? Если вы строите сервис для агентов, которые должны быстро выполнять шаги (например, поиск в интернете, вызов API, генерация кода), выбирайте MoE-модель с высокой пропускной способностью, такую как Nemotron 3.5 Lightning. Вы получите скорость, которая позволит вашему агенту работать в реальном времени, и сэкономите на стоимости инференса.
Если же вы создаете систему для сложного логического вывода, анализа документов или мультимодального понимания, где важна максимальная точность, а не скорость, Dense-модель, такая как Gemma 4, может быть лучшим выбором, несмотря на более высокую стоимость. Помните, что архитектура — это инструмент. Правильный выбор зависит от того, что для вас важнее: емкость (capacity) или скорость (throughput).
Для начала работы с Nemotron 3.5 Lightning вы можете попробовать модель на build.nvidia.com, загрузить веса с Hugging Face или использовать API через OpenRouter. Исходный код и данные открыты, что позволяет адаптировать модель под ваши нужды. Исследуйте, экспериментируйте и выбирайте архитектуру, которая лучше всего служит вашей задаче.
Источник: NVIDIA Developer ↗