Автотюнинг llama.cpp: скрипт, который не даст тебе сойти с ума от OOM на нескольких видеокартах

Всё начинается с OOM

Знакомо? Загружаешь Llama 3.2 70B на две RTX 4090, с гордостью пишешь в терминале -ngl 99, жмешь Enter. Через пять секунд – краш. Out of memory. Пробуешь -ngl 80. Снова OOM. -ts 0.5? Работает, но со скоростью улитки – 2 токена в секунду. Добро пожаловать в ад ручного подбора флагов для llama.cpp на нестандартных конфигурациях. Особенно когда у тебя не одна, а две, три или даже четыре разные видеокарты.

Что за скрипт и зачем он вообще нужен?

В конце 2025 года на GitHub вылез репозиторий с говорящим названием «llama.cpp-auto-tuner». Его идея проста до гениальности: зачем человеку вручную перебирать десятки комбинаций флагов -ngl, -ts, -mg и -c, если можно написать скрипт, который сделает это сам? Причем не наугад, а по алгоритму, который учитывает объем VRAM каждой карты, пропускную способность PCIe и даже тепловые характеристики.

1 Что он делает на самом деле?

• Диагностика железа. Первым делом скрипт сканирует систему. Сколько у тебя GPU? Какие у них архитектуры (sm_89 для Ada, sm_86 для Ampere)? Сколько видеопамяти на каждой? Есть ли NVLink?
• Анализ модели. Загружает GGUF-файл, смотрит на его размер, квантование (Q4_K_M, Q8_0), архитектуру. Вычисляет, сколько примерно слоев можно закинуть на каждую карту.
• Итеративный поиск. Это не случайный подбор. Скрипт начинает с безопасных значений, затем постепенно «нагружает» видеокарты, отслеживая не только OOM, но и деградацию скорости из-за swapping в RAM.
• Стресс-тест и бенчмарк. Найденная конфигурация проверяется на стабильность и производительность (tokens per second). Скрипт может запустить несколько прогонов, чтобы отсеять случайные всплески.
• Генерация готовой команды. В конце ты получаешь не просто набор цифр, а целую строку для запуска llama.cpp, которую можно скопировать и использовать.

С кем (и с чем) его сравнивать?

Альтернативы? Их две с половиной.

Получается, скрипт не уникален, но он первый, кто довел идею автоматизации до конца – до реальной работы с несколькими разнородными видеокартами. Не та связка «две одинаковые 4090», которая встречается в каждом втором гайде, а вот это: «RTX 3090 Ti (24 GB) + RTX 4060 (8 GB) + Intel Arc A770 (16 GB)». Для таких случаев он и создавался.

Как это выглядит на практике? Разберем два кейса.

Кейс 1: Две разные карты NVIDIA

Конфигурация: основная карта – RTX 4090 (24 GB), вторая – старая RTX 3060 Ti (8 GB). Модель – свежая Command R+ 35B в квантовании Q4_K_M (~22 GB).

Человек без скрипта сделал бы так: попытался загрузить все слои на 4090 (-ngl 99) – OOM. Начал уменьшать. Потом, через десяток попыток, догадался бы использовать флаг -mg i для распределения между картами. Но как распределить? Наугад: -mg 24,8? Снова OOM, потому что не весь объем VRAM доступен под слои, часть нужна под кэш.

Скрипт за 15 минут работы выдал команду:

./main -m command-r-plus-35b-q4_k_m.gguf \
  -ngl 83 -c 16384 \
  -mg 21.2,6.1 -ts 0.85 \
  -b 512 --flash-attn

Результат: стабильные 18 токенов/с при длинном контексте. Ключевое здесь – дробные значения в -mg. Скрипт понял, что для эффективной работы с кэшом нужно оставить немного «воздуха» в VRAM.

Кейс 2: Гибридная система (NVIDIA + Intel Arc)

Конфигурация: RTX 4070 Super (12 GB) + Intel Arc A770 (16 GB). Модель – Llama 3.2 11B Vision (немного «тяжелее» обычной 11B).

Скрипт, обнаружив драйверы SYCL, автоматически включил поддержку гибридного режима. Он не просто раскидал слои, но и подобрал оптимальный размер пакета (-b), чтобы PCIe 4.0 x8 не стало узким местом при обмене данными между картами разных производителей.

./main -m llama-3.2-11b-vision-q5_k_m.gguf \
  -ngl 100 -c 4096 \
  -mg 11.5,14.0 -b 256 \
  --split-mode layer

Итог: 42 токена/с. Без скрипта я бы даже не знал, с чего начать настройку такой экзотической связки.

Так кому этот инструмент реально нужен?

Если у тебя одна видеокарта и ты запускаешь модели, которые в нее четко вписываются (например, 7B на 8 GB VRAM), можешь смело пролистать. Твои мучения с флагами ограничатся парой попыток.

А вот этот скрипт создан для тех, кто живет в хаосе нестандартных конфигураций:

• Энтузиасты с «зоопарком» GPU. Тот самый случай, когда в системе стоит и новая карта для игр, и прошлое поколение для потокового кодирования, и еще одна «на пробу».
• Лаборатории с разнородным железом. Не у всех есть бюджет на кластер из одинаковых A100. Часто в ход идет то, что есть: несколько разных серверных карт или рабочих станций.
• Те, кто постоянно меняет модели. Сегодня тестируешь 8B, завтра – 70B, послезавтра – какую-нибудь свежую 120B от новой opensource-лаборатории. Каждый раз заново подбирать флаги – убийственно.
• Оптимизаторы, гонящиеся за каждым токеном. Когда нужно выжать из имеющегося железа максимум, а не «примерно рабочую» конфигурацию. Например, для проектов на слабых видеокартах каждый процент скорости на счету.

Главный подвох (потому что он есть всегда)

Скрипт – не волшебная палочка. Он не исправит проблемы самой llama.cpp или драйверов. Если у тебя в системе криво стоят драйверы CUDA 12.6 или сломанный Vulkan 1.3.285, он просто вылетит с ошибкой на этапе диагностики.

И еще: он требует времени. Полный цикл оптимизации для большой модели на нескольких картах может занять 40-50 минут. Скрипт будет запускать и останавливать процесс, меняя параметры. Это не мгновенно. Но это все равно в десятки раз быстрее, чем делать то же самое руками.

Мой вердикт? Если твоя работа или хобби связаны с постоянными экспериментами над разными LLM на неидеальном железе – этот скрипт сэкономит тебе кучу нервов и времени. Он не заменит глубокого понимания того, как работают аргументы llama.cpp, но станет отличным автоматическим помощником, который избавит от рутины. А освободившееся время можно потратить на что-то более интересное, чем наблюдение за OOM-крашами.

Подписаться на канал