Solar-Open-100B на домашнем железе: как запустить корейского гиганта через llama.cpp

Корейский прорыв, который не помещается в память

Solar-Open-100B - это не просто очередная большая языковая модель. Это корейский вызов всему миру open-source AI. 102 миллиарда параметров, архитектура Mixture of Experts (MoE), обучение на 19.7 триллионах токенов. Звучит впечатляюще, пока не попробуешь запустить это на своем компьютере.

Проблема в том, что 100 миллиардов параметров - это примерно 200 ГБ памяти в формате FP16. Даже если у вас есть 4 видеокарты A100 по 80 ГБ каждая, это не гарантирует успеха. Но есть llama.cpp - наш спаситель, который умеет сжимать этих гигантов до разумных размеров.

Что вам понадобится (спойлер: много)

Давайте сразу к делу. Если вы думаете, что запустите Solar-Open-100B на ноутбуке с 16 ГБ оперативки, забудьте. Вот реальные требования:

Если у вас нет такого железа, не расстраивайтесь. Есть варианты: арендовать облачные инстансы (дорого), использовать llama.cpp RPC-server для распределенных вычислений или собрать мощную станцию за $15 000.

Подготовка: собираем все, что нужно

Перед тем как что-то запускать, нужно подготовить поле боя. Вот что должно быть установлено:

1 Собираем llama.cpp с поддержкой CUDA

Без CUDA вы будете ждать ответа модели несколько часов. Не делайте так.

# Клонируем репозиторий
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

# Собираем с поддержкой CUDA
make clean
make LLAMA_CUBLAS=1 -j$(nproc)

# Проверяем, что собралось
./main --help | grep cuda

Если в выводе видите флаги, связанные с CUDA - все хорошо. Если нет, проверьте, что у вас установлены CUDA Toolkit и cuBLAS. На сборке llama.cpp можно споткнуться, особенно на нестандартных системах.

2 Качаем и конвертируем модель

Тут начинается самое интересное. Официальная модель лежит на Hugging Face, но в формате, который llama.cpp не понимает. Нужно конвертировать в GGUF.

# Устанавливаем Python зависимости
pip install torch transformers accelerate

# Клонируем скрипт конвертации
cd llama.cpp
python convert_hf_to_gguf.py \
  --model-name-upstage/SOLAR-10.7B-v1.0 \
  --outfile solar-100b.q4_0.gguf \
  --outtype q4_0

Параметр --outtype определяет уровень квантования. Варианты:

• q4_0 - самое сильное сжатие, качество страдает
• q4_K_M - баланс между размером и качеством (рекомендую)
• q5_K_M - почти оригинальное качество, но большой размер
• q8_0 - почти без потерь, но зачем тогда квантовать?

Для Solar-Open-100B я рекомендую начать с q4_K_M. Модель будет весить около 50 ГБ вместо 200, а качество останется приемлемым.

Запуск: момент истины

Модель сконвертирована, llama.cpp собран. Пора запускать. И вот тут многие совершают ошибку - пытаются засунуть всю модель в VRAM.

# КАК НЕ НАДО ДЕЛАТЬ
./main -m solar-100b.q4_K_M.gguf -p "Расскажи о квантовой физике" -n 256

Скорее всего, вы получите ошибку out of memory. Потому что даже квантованная модель не помещается в память одной видеокарты (если только у вас не H100 80GB).

Правильный подход - использовать оффлоадинг:

# Загружаем столько слоев в VRAM, сколько помещается
./main -m solar-100b.q4_K_M.gguf \
  -p "Объясни MoE-архитектуру простыми словами" \
  -n 512 \
  -c 2048 \
  -ngl 40 \
  --temp 0.7 \
  --repeat-penalty 1.1

Ключевой параметр здесь -ngl 40. Он говорит llama.cpp загрузить 40 слоев в VRAM. Остальные будут в оперативной памяти. Как определить это число? Методом проб и ошибок.

Оптимизация: заставляем летать

Даже с оффлоадингом Solar-Open-100B может работать медленно. Вот несколько трюков для ускорения:

Используем несколько GPU

Если у вас несколько видеокарт, распределите слои между ними:

./main -m solar-100b.q4_K_M.gguf \
  -p "Напиши код на Python для парсинга HTML" \
  -ngl 80 \
  -sm "0,1" \
  -ts 0.8,0.8

Параметр -sm "0,1" распределяет вычисления между GPU 0 и 1. -ts 0.8,0.8 резервирует по 80% памяти каждой карты.

Настраиваем размер контекста

Solar-Open-100B поддерживает контекст 4096 токенов. Но чем больше контекст, тем больше памяти нужно. Для большинства задач хватит 2048:

-c 2048  # Вместо 4096

Используем кэширование K/V

Для интерактивных сессий это обязательно:

--prompt-cache solar.cache \
--prompt-cache-all

Первый запрос будет медленным, но последующие - значительно быстрее.

С чем сравнить? Альтернативы Solar-Open-100B

Если Solar-Open-100B кажется слишком тяжелой, есть варианты:

Если нужна простая инструкция по загрузке моделей, посмотрите как скачать Llama 3.3 8B в GGUF - принцип тот же.

Кому это вообще нужно?

Запускать Solar-Open-100B на своем железе - это как держать тигра в квартире. Интересно, но непрактично. Вот кому это может быть полезно:

• Исследователи, которые хотят экспериментировать с MoE-архитектурами локально
• Компании с серьезными вычислительными ресурсами, которым нужна приватность
• Энтузиасты, у которых есть домашняя LLM-инфраструктура на 192 ГБ RAM
• Разработчики, создающие специализированные решения на основе больших моделей

Если вы из тех, кто любит запускать все локально, возможно, вам пригодится One-Click установщик для локальных LLM.

Что делать, если ничего не работает

Такое бывает. Особенно с такими большими моделями. Вот checklist:

1. Проверьте, что llama.cpp собран с LLAMA_CUBLAS=1
2. Убедитесь, что CUDA драйверы обновлены
3. Попробуйте уменьшить -ngl (возможно, вы переоценили объем свободной VRAM)
4. Проверьте, что модель действительно сконвертирована в GGUF (не в оригинальном формате)
5. Попробуйте более агрессивное квантование (q4_0 вместо q4_K_M)
6. Если все еще не работает - спросите в Issues llama.cpp на GitHub. Вы не первый.

И последнее: не ожидайте чудес скорости. Даже на 4x A100 80GB Solar-Open-100B будет генерировать текст со скоростью 2-5 токенов в секунду. Это нормально для модели такого размера.

Корейцы сделали интересную модель. Но запускать ее локально - это спорт для подготовленных. Если у вас нет подходящего железа, может, лучше начать с чего-то попроще? Или подождать, пока оптимизации в llama.cpp станут лучше. Или пока кто-то не сделает облачный API с нормальными тарифами.

А пока - удачи с вашим 100-миллиардным корейским другом. Он того стоит. Наверное.