Запуск Granite 4 Small 30B MoE на ноутбуке с 8 ГБ VRAM - полное руководство | AiManual
AiManual Logo Ai / Manual.
04 Янв 2026 Гайд

Практический гайд: как запустить 30B MoE-модель (Granite 4 Small) на ноутбуке с 8 ГБ VRAM и 32 ГБ RAM

Подробная инструкция по запуску 30B MoE-модели Granite 4 Small на ноутбуке с 8 ГБ видеопамяти и 32 ГБ RAM. Настройка llama.cpp, размещение экспертов в CPU, рабо

Запустить 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 в выводе — всё хорошо. Этот флаг критически важен для нашего случая.

💡
Не пытайтесь использовать LM Studio или Ollama для Granite 4 Small на 8 ГБ VRAM. Их системы распределения слоёв не оптимизированы для MoE-архитектуры. Вы либо получите out-of-memory, либо скорость 0.5 токена в секунду.

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:

  1. Использовать Q3_K_S вместо Q4_0 — модель станет 6 ГБ вместо 8 ГБ. Качество упадёт на 5-7%, но в VRAM поместится больше слоёв
  2. Уменьшить контекст до 4096 — освободит 1-1.5 ГБ VRAM. Можно добавить ещё 2-3 слоя в GPU
  3. Использовать --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 раза больше, чем должно помещаться в вашу видеопамять. И в этом есть своя магия.