Apex-2 - это языковая модель, которую один энтузиаст обучил с нуля: без внешних базовых весов, без стартового чекпоинта от другой команды. Отчёт об эксперименте опубликован в r/LocalLLaMA. Конфигурация такая: 3,87 млрд общих параметров при 1,45 млрд активных на каждый токен. Перед нами не продукт и не релиз под API, а исследовательский артефакт, который показывает, что сегодня реально сделать на ограниченном железе.
Главная особенность в том, что автор не взял готовую модель и не дообучил её под свои задачи. Он собрал данные, настроил архитектуру, провёл претрейн на 86,5 млрд токенов и затем SFT. Аппаратная база скромная по меркам фронта: сначала один ускоритель GH200, позже два, связанные методом DiLoCo.
Интерес к таким кейсам растёт из-за разрыва в цене и доступе. Крупные лаборатории считают претрейн в триллионах токенов, поэтому сравнение «86,5 млрд против 18 трлн» полезно: оно показывает, где заканчивается эффект масштаба данных и начинает работать архитектура. Про сам класс небольших MoE-моделей мы уже писали отдельно: MoE-модели с ~2B активных параметров.
Что такое Apex-2 и почему это интересный кейс
Apex-2 относится к семейству MoE-моделей (Mixture of Experts), где вычисления на каждый токен проходят не через всю сеть, а через выбранную часть экспертов. При 3,87B общих параметров и 1,45B активных модель тратит на генерацию примерно в 2,7 раза меньше вычислений, чем потратила бы плотная модель того же размера. Именно это делает кейс интересным для тех, кто считает бюджет GPU.
Второй повод присмотреться - полный цикл обучения с нуля. Автор прошёл претрейн и инструкционное дообучение, а затем ещё и попробовал выравнивание через DPO. Большинство публичных отчётов энтузиастов заканчиваются на этапе загрузки чужого чекпоинта, здесь же виден весь путь целиком, включая провалы.
Честные цифры и признание слабых мест делают отчёт полезнее рекламного анонса. Модель не подаётся как конкурент крупным LLM. Она показывает, какой результат достижим при 86,5 млрд токенов данных и одном, затем двух ускорителях GH200, и где именно заканчиваются возможности такого масштаба.
Архитектура Apex-2: MoE, GQA и другие детали
Основа - decoder-only трансформер на 32 слоя с d_model 2048. Каждый слой построен как MoE, плотных слоёв в сети нет. Это отличает Apex-2 от гибридных схем, где часть блоков оставлена обычной.
- общие параметры: 3,87B;
- активные параметры на токен: 1,45B;
- слоёв: 32;
- d_model: 2048;
- внимание: GQA, 16 query-голов и 4 KV-головы;
- эксперты: 16 штук, активируются 4 (top-4);
- контекст: 4096 токенов;
- токенизатор: Qwen3 на 151k токенов.
Загрузка идёт через transformers или vLLM с маппингом Qwen3MoeForCausalLM. Архитектуру совместили с уже существующим способом загрузки MoE-моделей Qwen, и это избавило автора от написания собственного загрузчика. Для практики это плюс: локальный запуск не требует отдельного форка инференс-движка.
Почему MoE с 16 экспертами и top-4
Механика простая. На каждом слое есть 16 экспертных подсетей и маршрутизатор. Он выбирает 4 эксперта под каждый токен, остальные 12 в вычислениях не участвуют. Отсюда расхождение между 3,87B общих параметров и 1,45B активных: сеть хранит много, а тратит меньше.
Смысл в том, что при фиксированном бюджете вычислений MoE позволяет держать больше параметров, чем плотная модель. Разные эксперты подстраиваются под разные паттерны данных, а маршрутизатор направляет токен туда, где он обрабатывается лучше. Обратная сторона - память: грузить надо все 3,87B, даже если на конкретный токен работает 1,45B. Компромиссы MoE-архитектуры мы разбирали подробнее на примере Qwen 3.x-35B-A3B.
Важная оговорка: 16 экспертов и top-4 - это решение автора конкретного эксперимента. Такой выбор не доказывает, что конфигурация оптимальна, и не означает, что другие комбинации дали бы худший результат.
GQA 16Q/4KV и контекст 4096
GQA (Grouped Query Attention) означает, что несколько query-голов делят одну пару ключ-значение. Здесь 16 query-голов приходятся на 4 KV-головы. Такой шаг сокращает размер KV-кеша и снижает расход памяти при генерации, хотя и слегка ограничивает гибкость внимания по сравнению с полным MHA. Для модели, которую обучали на одном ускорителе, экономия памяти имеет прямой смысл, потому что позволяет поднять размер батча.
Контекст в 4096 токенов - прямое ограничение по возможностям. Этого хватает на короткие диалоги и отдельные функции кода, но мало для длинных документов, многофайлового рефакторинга или разбора больших логов. Автор сам отмечает 4k как слабое место, а не как особенность дизайна.
Как проходило обучение: претрейн на 86,5 млрд токенов и DiLoCo
Претрейн занял 86,5 млрд токенов. В пересчёте на триллионы это около 0,087T, то есть примерно в 200 раз меньше, чем у моделей, с которыми Apex-2 сравнивают. Стартовало обучение на одном GH200, после чего автор перешёл на два ускорителя, связав их через DiLoCo.
GH200 - ускоритель с общей памятью CPU и GPU, что позволяет держать крупные состояния без выгрузки в отдельную оперативную память. Для одиночного эксперимента это удобно, хотя получить такую машину в личное пользование сложно и дорого.
Отдельно стоит зафиксировать, что точное время обучения, число шагов и частоту синхронизаций автор в отчёте не приводит. Восстанавливать эти цифры догадками не стоит: их в исходных данных нет.
Роль DiLoCo при переходе на два GH200
DiLoCo работает иначе, чем обычный data parallel, где градиенты синхронизируются на каждом шаге. Здесь каждый узел какое-то время обучается автономно на своей порции данных, а затем результаты периодически объединяются. Синхронизаций становится меньше, и обмен данными между устройствами перестаёт быть узким местом.
Для Apex-2 это дало возможность увеличить суммарный поток токенов при переходе с одного GH200 на два. Практический вывод для аналогичных проектов: DiLoCo разумен там, где нет быстрого интерконнекта между ускорителями, но есть два отдельных устройства, которые могут работать почти независимо и обмениваться обновлениями реже.
SFT: дообучение на 2,5 млрд токенов с упором на код и математику
После претрейна последовал SFT (Supervised Fine-Tuning) примерно на 2,5 млрд токенов. Датасеты сместили в сторону кода, математики и инструкций. Задача этапа - научить базовую модель следовать командам и выдавать связные ответы в нужном формате, а не просто продолжать текст.
Финальным автор оставил именно SFT-чекпоинт. Базовую модель после претрейна он тоже измерял, и именно к базовой версии относится сравнение с Qwen2.5-1.5B по HumanEval+. Разделение существенно: цифры SFT-версии и базовой модели не взаимозаменяемы, и путать их нельзя.
Ещё один вывод из отчёта: SFT хватило для нужного качества, и добавлять поверх него выравнивание не потребовалось. Это результат конкретного набора данных и метрик, а не общий закон, применимый к любой модели.
Результаты на бенчмарках: где Apex-2 сильна, а где нет
Все числа ниже относятся к SFT-чекпоинту и получены в режиме greedy с chat template.
| Бенчмарк | Режим | Результат |
|---|---|---|
| HumanEval | SFT, greedy | 43,9 |
| HumanEval+ | SFT, greedy | 41,5 |
| MBPP | SFT, greedy | 56,3 |
| MBPP+ | SFT, greedy | 48,9 |
| GSM8K | 0-shot CoT | 32,4 |
| MATH-500 | - | 21,0 |
| IFEval | prompt strict | 44,7 |
| MMLU | 5-shot | 28,6 |
Как читать эти цифры. Код - сильная сторона. HumanEval 43,9 и MBPP 56,3, а их строгие варианты с дополнительными тестами дают 41,5 и 48,9. Это рабочий уровень для генерации коротких функций, где не нужны длинные рассуждения.
Знания и математика провисают заметно. MMLU 28,6 при 5-shot и MATH-500 21,0 говорят о том, что модель не набрала фактических знаний и не решает сложные многошаговые задачи. GSM8K 32,4 в режиме 0-shot CoT подтверждает: даже школьная арифметика даётся с трудом. IFEval 44,7 в строгом режиме показывает, что следование инструкциям есть, но нестабильное.
Сравнение с Qwen2.5-1.5B: что стоит за цифрами
Qwen2.5-1.5B обучали на 18 триллионах токенов. Apex-2 получила 86,5 млрд, то есть примерно в 200 раз меньше. По HumanEval+ базовая версия Apex-2 сравнялась с Qwen2.5-1.5B. Если смотреть только на эту строчку, выглядит как убедительная победа экономии данных.
Подвох в том, что сравнение узкое. Оно касается одного бенчмарка по коду и только базовой модели, а не SFT-версии. По MMLU и математике Apex-2 отстаёт сильно, и это прямо признаёт автор. Архитектура MoE помогает эффективнее расходовать параметры, но не заменяет объём данных, нужный для фактических знаний. Сводные числа из разных отчётов вообще плохо сопоставимы, о чём мы разбирали на примере MiniCPM5-2B.
Итог по бенчмаркам простой: Apex-2 сильна в генерации короткого кода и слаба в знаниях и математике. Переносить её результат на другие задачи нет оснований.
Ограничения Apex-2: англоцентричность, галлюцинации и 4k контекста
Автор перечисляет слабые места без прикрас:
- англоцентричность: мультиязычных способностей почти нет, обучение шло на английских данных;
- слабые знания и, как следствие, частые галлюцинации;
- почти нулевые результаты на LiveCodeBench в категориях medium и hard;
- контекст всего 4096 токенов.
Пункт про LiveCodeBench стоит выделить. HumanEval проверяет короткие изолированные функции, а LiveCodeBench берёт задачи, приближенные к реальной разработке. Разрыв между 41,5 на HumanEval+ и почти нулём на сложных задачах LiveCodeBench означает одно: Apex-2 пишет отдельные функции, но не решает задачи, где нужны рассуждения на несколько шагов и понимание более широкого контекста.
Мультиязычность для русскоязычного пользователя - критичное ограничение. Модель обучалась на английском, и ожидать от неё рабочего русского не приходится. Для продакшена без дополнительного дообучения она не подходит, а использовать её как универсального ассистента смысла нет.
Провал DPO: почему автор откатился к SFT-чекпоинту
После SFT автор попробовал DPO (Direct Preference Optimization) на 220 тысячах пар предпочтений с length-normalization. Результат оказался отрицательным: ответы стали заметно длиннее, а метрики по коду, математике и IFEval просели. Автор остановил обучение и сохранил SFT-чекпоинт.
Что здесь поучительного. DPO учит модель предпочитать один ответ другому, и при неудачной нормализации длины она может выучить не полезность, а объём. В части схем выигрывает более длинный ответ, и модель начинает накручивать текст. Сами длинные ответы при этом не делают код корректнее, а на IFEval вредят, потому что инструкции часто требуют краткости и формата.
Второй момент - данные. 220 тысяч пар предпочтений немного для модели с 3,87B параметров, а качество разметки и распределение пар напрямую влияют на итог. Неудачный прогон не доказывает, что DPO бесполезен как метод. Он доказывает, что выравнивание нужно проверять по метрикам, а не принимать на веру, и что откат к предыдущему чекпоинту - нормальная инженерная практика, а не признание провала проекта.
Практические выводы: что можно взять из опыта Apex-2
Пять выводов, которые переносятся на собственные проекты обучения и дообучения.
- MoE работает даже в малом масштабе. При 1,45B активных параметров модель держит 3,87B общих и показывает на коде результат уровня плотной модели, обученной на порядки большем объёме данных.
- Обучение с нуля доступно, но требует компромиссов. 86,5 млрд токенов дают навык в узкой области и почти не дают знаний. Если нужна эрудиция, без большого корпуса не обойтись.
- DiLoCo снижает требования к обмену между узлами. Это разумный выбор, когда быстрого интерконнекта нет, а два отдельных ускорителя есть.
- SFT может закрыть задачу без DPO. В этом кейсе SFT дал лучший результат, а попытка выравнивания его ухудшила.
- Честная оценка ограничений экономит время. Автор прямо пишет про 4k контекста, англоцентричность и провал на LiveCodeBench, и это позволяет не тратить силы на неподходящие сценарии.
Для локального запуска Apex-2 совместима с transformers и vLLM через маппинг Qwen3MoeForCausalLM, что упрощает развёртывание. Применять её стоит как инструмент для короткого кода на английском или как основу для собственного дообучения под конкретную задачу. Ждать от неё универсального ассистента причин нет: знаний мало, контекст короткий, галлюцинации частые.