Запустить 30B модель на ноутбуке? Это не шутка
Вы смотрите на Granite 4 Small — 30-миллиардную MoE-модель от IBM — и думаете: "На моём ноутбуке с 8 ГБ VRAM она никогда не запустится". Обычно вы были бы правы. 30B параметров в формате FP16 — это 60 ГБ памяти. Даже с 4-битным квантованием нужно 15 ГБ. А у вас всего 8 ГБ видеопамяти.
Но есть секрет. Granite 4 Small — это Mixture of Experts. Из 30 миллиардов параметров одновременно активны всего 8-12 миллиардов. Остальные спят в оперативной памяти, ожидая своей очереди.
MoE-архитектура делит модель на экспертов — небольшие нейросети по 3-4 миллиарда параметров каждый. На каждом токене активируется только 2-3 эксперта. Остальные 20+ миллиардов параметров просто лежат в RAM и не занимают VRAM.
Вот почему вы можете запустить 30B модель на железе, которое должно справляться максимум с 13B. Это не магия — это грамотное распределение ресурсов.
1 Скачиваем и подготавливаем модель
Первая ошибка — брать первую попавшуюся версию Granite 4 Small. Некоторые квантования "сломаны" для MoE-архитектуры. Особенно Q4_K_M — он часто приводит к артефактам в генерации.
Не используйте автоматические конвертеры для MoE-моделей. Они могут неправильно обработать экспертов — получите модель, которая генерирует бессмыслицу.
Проверенный вариант — Q4_0 от TheBloke. Консервативное квантование, но стабильное:
# Скачиваем модель
wget https://huggingface.co/TheBloke/granite-4-small-GGUF/resolve/main/granite-4-small.Q4_0.gguf
# Проверяем размер файла
ls -lh granite-4-small.Q4_0.gguf
# Должно быть около 8-9 ГБ
Размер в 8 ГБ — это не случайность. Q4_0 квантует до 4 бит с нулевым смещением. Качество падает на 2-3% по сравнению с Q5, но модель помещается в вашу VRAM с запасом для кэша.
2 Собираем llama.cpp с поддержкой MoE
Стандартная сборка llama.cpp из репозитория может не поддерживать MoE. Особенно если вы взяли версию недельной давности.
Вот как собирать правильно:
# Клонируем репозиторий
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
# Переключаемся на стабильную ветку
# НЕ используйте main — там могут быть экспериментальные изменения
# которые сломают MoE-поддержку
# Лучше взять конкретный коммит с известной работоспособностью
git checkout b3238
# Собираем с поддержкой CUDA и Metal (для macOS)
make clean
LLAMA_CUDA=1 make -j$(nproc)
# Проверяем, что MoE поддерживается
./main --help | grep -i "moe\|expert"
# Должны увидеть флаги вроде --tensor-split и --n-gpu-layers
Если вы видите --tensor-split в выводе — всё хорошо. Этот флаг критически важен для нашего случая.
3 Настройка распределения слоёв — сердце метода
Вот где большинство людей ошибаются. Они пытаются запихнуть всю модель в VRAM или, наоборот, всё в CPU. И то, и другое убивает производительность.
Granite 4 Small имеет 32 слоя. Но не все слои равны — эксперты распределены по ним неравномерно.
Правильная стратегия:
# НЕПРАВИЛЬНО — всё в VRAM (не поместится)
./main -m granite-4-small.Q4_0.gguf -n 256 --n-gpu-layers 32
# НЕПРАВИЛЬНО — всё в CPU (медленно)
./main -m granite-4-small.Q4_0.gguf -n 256 --n-gpu-layers 0
# ПРАВИЛЬНО — гибридный подход
./main -m granite-4-small.Q4_0.gguf -n 256 \
--n-gpu-layers 24 \
--tensor-split 7,1 \
-c 8192 \
-b 512 \
--mlock \
--no-mmap
Давайте разберём каждый флаг:
--n-gpu-layers 24— 24 слоя в VRAM, 8 слоёв в RAM. Первые слои — самые "тяжёлые", их держим в видеопамяти--tensor-split 7,1— распределение памяти между GPU и CPU. 7 частей в GPU, 1 в CPU (примерно 7 ГБ VRAM, 1 ГБ RAM под модель)-c 8192— контекст 8192 токенов. Granite 4 Small поддерживает до 32K, но на 8 ГБ VRAM больше 8K не вытянуть-b 512— batch size 512. Уменьшаем, если видим out-of-memory--mlock --no-mmap— закрепляем модель в памяти. Замедляет загрузку, но ускоряет inference на 10-15%
| Распределение слоёв | VRAM использование | Скорость (tkps) | Качество |
|---|---|---|---|
| Все слои в GPU (32) | Out of memory | — | — |
| 20 слоёв GPU, 12 CPU | 6.5 ГБ | 8-10 tkps | Нормальное |
| 24 слоя GPU, 8 CPU (наш вариант) | 7.2 ГБ | 12-14 tkps | Хорошее |
| Все слои в CPU (0) | 0.5 ГБ VRAM | 1-2 tkps | Отличное, но медленно |
4 Оптимизация для длинного контекста
Granite 4 Small поддерживает 32K контекст. Но на 8 ГБ VRAM вы не сможете использовать больше 8-12K. KV-кэш съедает слишком много памяти.
Решение — квантование KV-кэша:
# Без квантования KV-кэша (память взрывается)
./main -m granite-4-small.Q4_0.gguf -c 16000 \
--n-gpu-layers 24 \
--tensor-split 7,1
# С квантованием KV-кэша (работает)
./main -m granite-4-small.Q4_0.gguf -c 16000 \
--n-gpu-layers 24 \
--tensor-split 7,1 \
--rope-freq-base 1000000 \
--rope-freq-scale 0.5 \
--flash-attn \
--no-kv-offload
Что здесь происходит:
--rope-freq-base 1000000и--rope-freq-scale 0.5— настройки RoPE для длинного контекста. Без них модель "забывает" начало длинного промпта--flash-attn— используем Flash Attention. Экономит до 30% памяти на KV-кэше--no-kv-offload— не выгружаем KV-кэш в CPU. Для длинного контекста offload убивает производительность
С этими настройками 12K контекст использует примерно 7.8 ГБ VRAM. На грани, но работает.
Не пытайтесь использовать --kv-offload с контекстом больше 8K. Пересылка KV-кэша между GPU и CPU каждые несколько токенов снижает скорость до 2-3 tkps. Лучше уменьшить контекст до 8K, но оставить всё в VRAM.
Результаты: что можно ожидать
После всех настроек вы получите:
- Скорость генерации: 12-14 токенов в секунду на первых 100 токенах, 8-10 tkps на длинной генерации
- Загрузка модели: 45-60 секунд (из-за --mlock)
- Пиковое использование VRAM: 7.2-7.8 ГБ из 8 ГБ
- Использование RAM: 18-22 ГБ из 32 ГБ (остальное для системы и кэшей)
Для сравнения — та же модель на чистом CPU (без GPU) даёт 1-2 tkps. На полном GPU (если бы поместилась) — 25-30 tkps. Наш гибридный подход даёт 8-14 tkps — золотая середина.
Ошибки, которые всё испортят
Я видел, как люди неделями пытаются запустить Granite 4 Small на слабом железе. Вот их основные ошибки:
# ОШИБКА 1: Слишком много слоёв в GPU
./main -m granite-4-small.Q4_0.gguf --n-gpu-layers 28
# Результат: CUDA out of memory после 10-15 токенов
# ОШИБКА 2: Неправильный tensor-split
./main -m granite-4-small.Q4_0.gguf --tensor-split 1,1
# Результат: 4 ГБ в GPU, 4 ГБ в CPU — неэффективно
# ОШИБКА 3: Забыли --mlock на Windows
# Windows агрессивно свопирует память модели
# Без mlock скорость падает в 2-3 раза после часа работы
# ОШИБКА 4: Пытаются использовать --mmap с маленькой RAM
# mmap экономит RAM, но увеличивает latency
# На 32 ГБ RAM лучше использовать --mlock
А если хочется ещё быстрее?
Есть три способа выжать дополнительные 2-3 tkps:
- Использовать Q3_K_S вместо Q4_0 — модель станет 6 ГБ вместо 8 ГБ. Качество упадёт на 5-7%, но в VRAM поместится больше слоёв
- Уменьшить контекст до 4096 — освободит 1-1.5 ГБ VRAM. Можно добавить ещё 2-3 слоя в GPU
- Использовать --no-mmap-prefetch — рискованно, но ускоряет загрузку экспертов из RAM
Мой совет — не гонитесь за скоростью. 8-10 tkps достаточно для чата. Для кодогенерации можно снизить до Q3, но будьте готовы к глупым ошибкам в синтаксисе.
Granite 4 Small против других MoE-моделей
Вы можете спросить — зачем именно Granite 4 Small? Есть же Mixtral, DeepSeek MoE, Qwen MoE.
| Модель | Общие параметры | Активные параметры | Минимальная VRAM (Q4) | Качество кода |
|---|---|---|---|---|
| Granite 4 Small | 30B | 8-12B | 7-8 ГБ | Отличное |
| Mixtral 8x7B | 47B | 13B | 9-10 ГБ | Хорошее |
| DeepSeek MoE 16B | 16B | 2.4B | 4-5 ГБ | Среднее |
Granite 4 Small — оптимальный выбор для 8 ГБ VRAM. Достаточно большой, чтобы генерировать качественный код, но достаточно эффективный, чтобы поместиться в ограниченную память.
Если у вас есть доступ к нескольким старым GPU, как в статье про тройной GTX 1070, можно запустить и более крупные модели. Но для ноутбука с одной видеокартой Granite 4 Small — предел.
Что делать, когда всё равно не хватает памяти
Бывает — система резервирует 500 МБ VRAM для дисплея, и ваши 7.8 ГБ не помещаются в 8 ГБ. Вот экстренные меры:
# 1. Убиваем все лишние процессы, использующие GPU
nvidia-smi # смотрим PID
kill -9 [PID]
# 2. Уменьшаем batch size до минимума
./main -m granite-4-small.Q4_0.gguf -b 128 ...
# 3. Используем --memory-f32 вместо --no-mmap
# Медленнее, но экономит 10-15% памяти
# 4. Последний вариант — уходим в чистый CPU
./main -m granite-4-small.Q4_0.gguf --n-gpu-layers 0 -t 16
# Используем все 16 потоков CPU, получаем 2-3 tkps
# Медленно, но работает
Если и это не помогает — смотрите в сторону меньших моделей типа Nanbeige 3B. Или экспериментируйте с сверхнизкобитным квантованием.
Итог: стоит ли игра свеч?
Запуск 30B модели на ноутбуке с 8 ГБ VRAM — это не про комфорт. Это про принцип. Вы жертвуете скоростью ради возможности запуска большой модели.
12-14 tkps — это 1 слово в секунду. Для неторопливого чата сгодится. Для кодогенерации — уже напряжно. Но сам факт, что 30-миллиардная модель вообще работает на таком железе, впечатляет.
Через год, когда MoE-архитектуры станут стандартом, а инструменты вроде llama.cpp научатся лучше распределять экспертов между GPU и CPU, мы будем запускать 100B модели на 8 ГБ VRAM. А пока Granite 4 Small — лучший способ почувствовать будущее на своём ноутбуке.
Попробуйте. Даже если получится всего 5 tkps — вы всё равно запустите модель, которая по параметрам в 4 раза больше, чем должно помещаться в вашу видеопамять. И в этом есть своя магия.