Энтузиасты обучили модель NanoColibri-Instruct за $200 и доказали эффективность архитектуры MoE

Команда энтузиастов успешно обучила модель NanoColibri-Instruct с нуля, потратив всего $180–260 на аренду одного видеокарты. Проект доказал, что архитектура Mixture-of-Experts (MoE) с 2,7 млрд параметров в сумме и 340 млн активных параметров на токен может превзойти плотные модели по пяти из семи задач без предварительной настройки. Обучение велось по принципу эстафеты: участники по очереди запускали вычисления на своих ресурсах, передавая состояние модели через репозиторий.

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

Механика обучения и архитектура

Главная цель проекта — не создание самой модели, а проверка гипотезы о запуске больших моделей на устройствах с ограниченной оперативной памятью. Идея заключается в том, чтобы хранить часть модели на диске (NVMe) и подгружать только необходимые блоки («эксперты») в память по мере необходимости. Ноутбук с 16 ГБ ОЗУ не может удержать модель в 24–28 млрд параметров целиком, но в архитектуре MoE каждый токен обрабатывается плотным ядром, одним общим экспертом и парой небольших модулей размером 3–4 МБ.

Для реализации обучения без кластера был внедрен протокол «эстафеты» на базе платформы Hugging Face Hub. Процесс выглядит так:

• Участник заявляет о начале работы («берет эстафету») через механизм атомарной операции сравнения и замены.
• Система блокирует доступ к текущему этапу для других, предотвращая дублирование работы.
• После завершения этапа данные загружаются обратно, и «эстафета» передается следующему участнику.
• Если аренда облачного сервера прерывается, система автоматически освобождает доступ для других.

Всего было выполнено 20 000 обновлений весов на наборе данных FineWeb-Edu (около 5,2 млрд токенов), а затем проведено 1 500 обновлений для настройки диалогового режима на наборе smol-smoltalk. Общее время работы видеокарты H100 составило около 90 часов.

Архитектура модели Nano оптимизирована под конкретный движок вывода (HYV3):

• 24 слоя: один плотный слой и 23 слоя MoE.
• 64 эксперта шириной 512 с выбором топ-2 лучших.
• Один общий эксперт шириной 2048, который всегда resides в памяти.
• Механизм нормализации QK-norm и балансировка нагрузки без вспомогательных потерь (aux-loss-free).

Результаты тестирования и сравнение

Для честного сравнения все модели прогонялись через единый тестовый набор с одинаковыми промптами. NanoColibri (активные параметры 341 млн, 5,4 млрд токенов) сравнивался с двумя плотными моделями, обученными на сопоставимом объеме данных: Pythia-410M и Cerebras-GPT-256M.

NanoColibri показал лучшие результаты в 5 из 7 задач. Показатели в тестах LAMBADA (понимание контекста в художественной литературе) оказались ниже, что объясняется отсутствием художественных текстов в обучающей выборке FineWeb-Edu. Тест WinoGrande показал результаты в пределах статистической погрешности.

Примечательно: Обучение модели с выбором топ-2 экспертов на этапе тренировки, даже если при выводе используется только топ-1, критически важно для корректной работы механизма маршрутизации и предотвращения «замораживания» весов.

Ошибки и планы развития

В ходе эксперимента команда столкнулась с двумя серьезными проблемами, которые стоит учитывать при повторении подобных экспериментов.

Первая проблема связана с измерением скорости работы с диском. При тестировании на арендованном сервере скорость загрузки данных из памяти оставалась стабильной даже при искусственном ограничении объема ОЗУ. Оказалось, что операционная система использовала кэш страниц (page cache), маскируя реальную нагрузку на диск. Для получения достоверных данных о работе с медленной памятью необходимо использовать жесткое ограничение памяти на уровне ядра (cgroups) на оборудовании, где это ограничение действительно работает.

Вторая ошибка касается планирования обучения. Использование фиксированного расписания изменения скорости обучения (косинусное) привело к тому, что процесс обучения «закончился» раньше времени, не оставив запаса для продолжения. В будущих итерациях будет использовано расписание WSD (warmup–stable–decay), которое предусматривает длительную стабильную фазу, удобную для передачи эстафеты между участниками.

Дальнейшие планы включают создание модели Colibri-Micro (7 млрд параметров, 1 млрд активных) на 100 млрд токенов с упором на код, а затем Colibri-Grande (24–28 млрд параметров). Последняя модель будет специально спроектирована так, чтобы ее контейнер превышал объем памяти стандартного ноутбука, что позволит протестировать реальную работу системы подгрузки с диска.

Операционные последствия, тренды и практические аспекты

• Снижение барьера входа: Возможность обучать сложные архитектуры MoE на бюджет в $200 открывает доступ к экспериментам для небольших команд и исследователей, не имеющих доступа к мощным кластерам.
• Зависимость от инфраструктуры: Реализация концепции потоковой передачи данных с диска требует жесткого контроля за памятью на уровне операционной системы; стандартные методы ограничения ресурсов могут давать ложные результаты из-за кэширования.
• Риск фрагментации данных: Использование эстафетного обучения требует строгой дисциплины и надежного механизма блокировок; ошибка в передаче состояния может привести к потере целого дня вычислений.
• Технологический тренд: Переход к моделям, где общее количество параметров превышает объем оперативной памяти устройства, становится актуальным направлением для локального развертывания ИИ, но требует пересмотра подходов к архитектуре и движкам вывода.