llama.cpp GPU layers: как проверить частичный перенос модели

В llama.cpp настройка --n-gpu-layers управляет переносом слоёв модели на GPU в поддерживаемой сборке. Она не обозначает процент мощности и не гарантирует полное размещение при произвольном числе. Рабочий результат зависит от архитектуры, backend, видеопамяти, контекста и остальных буферов. Проверяйте фактическое размещение в журнале после каждого изменения.

Убедитесь, что GPU-backend существует

Сначала проверьте версию бинарника и способ сборки. CPU-сборка не получает CUDA или Vulkan только от появления аргумента переноса. Доступность GPU на уровне ОС тоже не доказывает, что конкретный исполняемый файл содержит нужный backend и совместимые зависимости.

Аппаратные маршруты описаны в официальной инструкции сборки llama.cpp. Параметры размещения перечислены в документации llama-server. Начните с подтверждённого обнаружения устройства, затем исследуйте число переносимых слоёв.

Не делите модель на равные доли вслепую

Условная половина слоёв не обязана занимать половину всей памяти. В архитектуре есть разные тензоры и служебные данные, а контекст расходует ресурс независимо от размера основного файла. Поэтому оценка по числу слоёв годится для планирования опыта, но не заменяет измерение.

Например, перенос десяти и двадцати слоёв — два учебных режима одной модели. Сравнивать их следует при одинаковом GGUF, контексте и настройках генерации. Полученные цифры нельзя переносить на другой checkpoint только потому, что у него такое же число слоёв или параметров.

Изменяйте размещение последовательно

Пример аргумента для совместимого локального сервера:

llama-server -m /path/to/model.gguf \
  --ctx-size 4096 --n-gpu-layers 20 \
  --host 127.0.0.1 --port 8080

Путь и число 20 требуют выбора под вашу модель; это демонстрация синтаксиса. Сохраните журнал загрузки и фактический перенос. Затем увеличьте или уменьшите только этот параметр, не меняя одновременно квантование и контекст.

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

Сравните задержку, а не только загрузку

Большее размещение на GPU часто рассматривают ради производительности, но результат зависит от всей системы. CPU, оперативная память и обмен остаются частью цепочки. Сохраните время обработки входа, начала ответа и завершения, а также фактические токены.

Смешанный режим может подходить для редких локальных задач, но не отвечать требованиям интерактивного сервиса. Разница ресурсов объясняется в материале RAM и VRAM, а исходный запуск — в руководстве llama-server. Сначала проверьте качество, затем сопоставляйте задержку.

После успешного размещения повторите запрос с рабочим входом. Загрузка слоёв проверяет только часть бюджета памяти и не подтверждает запас для растущего контекста во время генерации.

Покажите полезную границу машины

Для владельца оборудования результатом должна стать таблица из нескольких проверенных размещений с памятью и временем. Она объясняет, что можно получить от существующего GPU и где начинается ограничение. Укажите также, сколько системных ресурсов остаётся другим приложениям.

Финансовому партнёру такая таблица помогает оценить пользу более ёмкой карты относительно уже работающего смешанного варианта.