«Измерено, а не обещано»: автор блога Hugging Face уместил претрейн 1,11B-модели в 6 ГБ памяти ноутбучной видеокарты

«Везде был один и тот же ответ: нужна A100»

Автор начинает с того, что искал способ претрейна на слабой видеокарте и не нашёл ни одного разбора: везде повторялся один и тот же вывод — нужна A100, а на таком железе поместится разве что игрушечная модель на 20 млн параметров. Стек он собрал сам и, по собственному признанию, вышел на 100,6% измеренного пика GEMM для своей карты — результат, который его самого озадачил, поскольку «я не учёный, просто человек без денег».

Заголовочные числа выглядят так: 1,11 млрд параметров в режиме претрейна, а не инференса; пиковая видеопамять 4,51 ГБ, то есть 1,5 ГБ в запасе; пропускная способность 1 579 токенов в секунду при контексте 4 096; около 375 дней до Chinchilla-оптимальных 36 млрд токенов. Всё измерено на RTX 4050 с 6 ГБ — это ноутбучная карта, а не серверный ускоритель.

Пять приёмов, каждый из которых уже опубликован

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

Блочно-координатный спуск (BAdam) тренирует один блок за раз и очищает его состояние оптимизатора — экономия примерно в 8 раз на состоянии оптимизатора. Выгрузка весов на CPU убирает неактивные блоки с видеокарты, и экономия растёт вместе с глубиной модели. Тернарные веса из BitNet b1.58 превращают 32-битные веса в −1/0/+1, сжимая их в 2,33 раза. Связанные эмбеддинги оставляют одну таблицу словаря вместо двух, что на масштабе 1B экономит 103 млн параметров. Gradient checkpointing пересчитывает активации вместо их хранения и сводит их примерно к 50 МБ, а чанковый cross-entropy материализует логиты по срезам и пересчитывает их на обратном проходе — это дало около 1,5 ГБ экономии при контексте 4 096 и словаре на 50 тысяч токенов.

Два приёма, которые раньше не работали вместе

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

Исправление (issue #157) — закреплять связанную таблицу: параметр, достижимый из двух модулей, никогда не вытесняется, потому что прямой проход использует его на обоих концах, а окно резидентности ни одного блока не покрывает оба использования. Цена — одна таблица словаря, постоянно находящаяся в памяти: 250 МБ на масштабе 1B. В сочетании с чанковым cross-entropy (--chunked-loss 512) ранее падавшая по памяти комбинация заработала: пятишаговый тест в fp32 при 1,11B параметров прошёл на 79% от 6 ГБ, то есть на 4,85 ГБ, без OOM.

Гибридная архитектура и точное вспоминание

Модель — гибрид на гейтированных блоках DeltaNet: десять блоков DeltaNet и два слоя скользящего окна внимания на слоях 3 и 10. Автор прямо оговаривает, что архитектура является реимплементацией опубликованных работ, включая канонический апдейт gated DeltaNet в стиле GLA / Mamba-2, нормализатор RMSNorm по головам и выходной гейт с короткой причинной свёрткой в стиле Mamba / RWKV-7.

Зачем внимание рекуррентной модели: чистая рекуррентность сжимает всю историю в фиксированное состояние и не может вспомнить точные токены из контекста. На синтетической пробе из 200 испытаний чистая DeltaNet дала 4–5% попаданий внутри окна и 0,5% за окном, а гибрид — 35,5% внутри окна (в 9 раз выше базовой линии) и 8,5% за окном (в 17 раз). Слои внимания добавляют около 13% видеопамяти и примерно 7% времени шага при претрейне. По формулировке автора, для кодинг-агентов и задач с опорой на контекст это разница между «модель выдумывает сигнатуру функции» и «модель копирует точную сигнатуру из контекста».

Что стек даёт на одной и той же карте

На стандартном скрипте эта карта упирается примерно в 243 млн параметров, а со стеком доходит до 1,58 млрд — примерно в 6,5 раза больше. Автор отдельно поясняет, что множитель приходит именно от стека претрейна, а не от архитектуры: обычный трансформер на 1,07B под этим стеком идёт в 4,04 ГБ, а на 243M трансформер и рекуррентный гибрид требуют почти одинаковой памяти — 4,80 против 5,09 ГБ.

Для остальных карт приведена линейная экстраполяция от измеренного потолка: 8 ГБ — около 2,2B и примерно 160 дней на 1,5B, 12 ГБ — около 3,5B и 75 дней на 2,5B, 16 ГБ — около 4,8B и 40 дней на 3,5B, 24 ГБ — около 7,5B и 18 дней на 5B. Эти строки помечены как экстраполированные, а не измеренные: измерена только строка на 6 ГБ, остальное — оценка сверху, зависящая от архитектуры карты, поведения WDDM и размера батча.

Системная память и куда уходит видеопамять

Системную память автор называет недооценённой частью задачи: при 6 ГБ на карте минимум — 16 ГБ, рекомендуется 32 ГБ, потому что при выгрузке около 3–4 ГБ весов лежат в системной памяти, а на Windows превышение видеопамяти не даёт ошибки, а тихо выливается в системную память со скоростью в 4–15 раз ниже. Он измерял 82 секунды на микробатч, когда вылилась модель на 2,45B, и напоминает правило: системной памяти нужно не меньше двух объёмов видеопамяти при выгрузке и не меньше полутора — без неё.

Разбор расхода при 48M и контексте 4 096 показывает, что крупнейший потребитель — не модель: на вычисление лосса по словарю уходит около 1 500 МБ, на контекст CUDA и рабочие буферы — около 400 МБ, на тернарные веса — около 960 МБ, на состояние оптимизатора BCD — около 200 МБ, на активации — около 50 МБ и на закреплённую связанную таблицу — около 250 МБ.

Год на один прогон

Главное ограничение автор формулирует без смягчений: уместиться — не значит обучить. Шаг обучения разложен на части: умножение матриц занимает 33% и идёт на 100,6% от потолка карты, мелкие операции между ними — 36% и ограничены скоростью памяти, проход по последовательности — 15%, пересылка данных — ещё 15% как цена того, что всё уместилось в 6 ГБ. Даже оптимистичная оценка оставшихся улучшений даёт 20–25%, то есть примерно 300 дней вместо 375: остальное — это 36 млрд токенов.

Отдельно объясняется, почему ориентир — 30 токенов на параметр вместо 20 из статьи Chinchilla: измерения на трёх размерах модели показали, что переход с 20 на 30 даёт улучшение held-out лосса на 1,9–3,3% за 50% дополнительных вычислений, а с 30 на 40 — лишь около 1,1% за 33%. Для 1,11B это около 33 млрд токенов, а остановка на 20 токенах на параметр оставила бы 2–3% качества на столе. Как ведёт себя эта зависимость с ростом модели, автор считает нерешённым: трёх размеров не хватает, чтобы разделить слагаемые.

Что реально по силам 6 ГБ

По оценке автора, на такой карте осмысленны две задачи: корректно сформатированные вызовы инструментов при размере модели примерно от 100 до 270 млн параметров — это дни обучения, и связный диалог при примерно 270 млн — около 24 дней. Хорошо писать код — вне досягаемости: модели, в разы большие и обученные на триллионах токенов, всё ещё слабы в этом. Первые две задачи автор называет реальными проектами, третью — нет. В конфигурации прогона на 1,11B он приводит полный список флагов — от --arch hvn и --d-model 2048 до --optimizer muon и --chunked-loss 512, объясняя каждый: связанные эмбеддинги экономят 103 млн параметров, выгрузка требует gradient checkpointing, а Muon даёт в 1,6 раза меньше шагов до того же лосса, но примерно на 12% медленнее на шаг.

Ловушки, которые стоили часов

В отдельном разделе собраны ошибки, стоившие реального времени: torch.compile на этой архитектуре работает в 2,4 раза медленнее по четырём независимым измерениям, поэтому используется флаг --fast, который его намеренно пропускает, а голый --no-fast без флагов точности молча роняет расчёт в fp32 — 74,6 секунды на шаг вместо 8,66.

Отдельная ловушка — стандартная смесь данных: она ограничивает претрейн 0,13 млрд токенов, потому что OpenAssistant объёмом 15,7 млн токенов забирает 35% бюджета, и прогон на 1B получает в 270 раз меньше данных, чем ему нужно, при внешне здоровой кривой лосса, которая просто перечитывает одни и те же токены. Лечится это флагом --pretrain-mix 0.0,0.0,0.0,1.0 с FineWeb-Edu. Кроме того, ничего не печатается до шага 50, поэтому короткий прогон выглядит зависшим — следить нужно за training_log.csv, а tokenizer.vocab_size не включает добавленные токены, и для размера таблицы эмбеддингов надо брать len(tokenizer), иначе получается выход за границы.

Тупики, отозванные выводы и молчаливые баги

Автор сознательно публикует и то, что не сработало: 11 идей проверены и отклонены, среди них оригинальная архитектура HVN, проигравшая гейтированной DeltaNet 13% при равных данных, mixture-of-experts, уступающий простому увеличению плотной модели, тензор-трейн-факторизация с вдвое меньшим числом параметров и на 22% худшим результатом, chunk-parallel scan, оказавшийся в 4 раза медленнее, и curriculum по длине последовательности, замедливший обучение на 2,9%.

Отдельно перечислены пять отозванных выводов и четыре оптимизации, которые оказались медленнее бездействия, включая torch.compile и удаление слоя внимания — на 6,4% медленнее. Восемь молчаливых багов были пойманы проверяемыми тестами: кэш, отдававший необученные веса; проверка на пять элементов, пройденная по случайности, а не по сигналу; CUDA graph, где сравнивались один шаг против одного шага из одного состояния, поэтому нулевая разница ничего не доказывала.

Границы применимости

Раздел ограничений автор пишет сам: архитектура — реимплементация опубликованных работ, а свойство постоянной памяти на инференсе принадлежит всему этому семейству моделей, а не проекту. Ничего выше 48 млн параметров здесь не обучено до сходимости, поэтому все утверждения о масштабировании измерены ниже этой границы и не должны переноситься выше.

Отдельной строкой оговорено, что цифра в 100 тысяч токенов памяти на инференсе рассчитана, а не измерена, и потому на странице не приводится. Сравнения сделаны на одном seed: он устраняет удачу между вариантами, но не удачу, общую для обоих — переобучение той же модели трижды со сменой только начальных случайных чисел сдвинуло результат на 0,089, и некоторые различия в проекте меньше этой величины.

Что доступно

Код проекта лежит в открытом репозитории kramba-ai под лицензией Apache 2.0. Лицензия покрывает код, но не обученные веса: контрольные точки — отдельная работа со всеми правами, а веса, которые пользователь обучит сам, принадлежат ему. Публикация относится к авторским материалам сообщества Hugging Face, а не к официальным заявлениям компании, и это личный опыт одного разработчика, а не результат лаборатории.