Google Gemma 4 31B a été réduit à 18,3 Go et exécuté sur Kaggle gratuit

31-миллиардную Google Gemma 4 удалось ужать с 62 ГБ до 18,3 ГБ и прогнать через бесплатный Kaggle, хотя лимит диска там меньше исходного веса модели. Для этого автор собрал довольно жесткий, но рабочий пайплайн: квантование на лету, удаление кэша во время выполнения и прямая выгрузка результата в Hugging Face Hub.

Где уперлись в лимиты

Исходная Gemma 4 31B в формате float16 занимает около 62 ГБ, а доступный на бесплатном Kaggle диск ограничен 57,6 ГБ. Проблема не только в том, чтобы скачать модель. Ее нужно еще переквантовать в 4 бита, получить новый набор весов примерно на 18 ГБ и затем выгрузить его наружу.

Если считать по-простому, на одном этапе нужно держать и оригинал, и результат, а это уже около 80 ГБ. То есть стандартный сценарий тут ломается еще до первой успешной выгрузки. В этом и смысл кейса: не про красивый MLOps на дорогом железе, а про попытку запустить тяжелую открытую модель в условиях, где каждый гигабайт приходится буквально отбивать.

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

Как собрали пайплайн

Первый ключевой прием — квантование не после полной подготовки, а прямо в процессе загрузки. Для этого использовались bitsandbytes и формат NF4, а параметр device_map="auto" позволил автоматически разложить модель по двум T4 с 15 ГБ памяти каждая. Идея в том, чтобы не ждать, пока все веса спокойно лягут на диск и только потом начинать обработку. Чем раньше начинается сжатие, тем меньше шанс, что временные файлы и промежуточные состояния окончательно съедят доступное место.

• Модель грузится и квантуется почти одновременно, без длинной паузы между этапами Параметр device_map="auto" распределяет шардированные веса между двумя T4 После загрузки в VRAM кэш Hugging Face удаляется, чтобы освободить место под новый артефакт * Вместо сохранения на диск используется прямая отправка модели в Hugging Face Hub Самый радикальный шаг — удалить папку кэша Hugging Face уже после того, как модель загружена в видеопамять. Технически трюк опирается на поведение Linux: даже если файл уже удален из файловой системы, процесс может продолжать держать его открытым, а место становится доступным для новых записей. За счет этого исходные 62 ГБ перестают мешать созданию квантованных шардов. Финальный этап тоже обошли без лишних копий: вместо обычного сохранения и отдельной загрузки результат сразу отправлялся в Hugging Face Hub через push_to_hub.

«Мы не ждали конца загрузки, мы начали жать веса сразу».

Что вышло в итоге

На выходе получился артефакт размером 18,3 ГБ — уже не монстр, привязанный к серверному железу, а модель, с которой можно работать на куда более обычных конфигурациях. Автор отдельно подчеркивает, что речь идет о 31-миллиардной Gemma 4, ориентированной в том числе на задачи, связанные со сложным кодом. Сам результат был выложен в Hugging Face, то есть это не просто теоретический рецепт, а воспроизводимый эксперимент с конкретным итогом и готовой сборкой.

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

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

Что это значит

Крупные открытые модели вроде Google Gemma 4 можно адаптировать даже под очень скромную инфраструктуру, если пересобрать весь процесс вокруг ограничений, а не вокруг удобного пайплайна. Для разработчиков это хороший сигнал: барьер входа в эксперименты с большими LLM снижается, но цена этой доступности — более хрупкие и ручные MLOps-сценарии.