В этом материале
Сборку Windows проверяют по фактическому backend и результату запуска; успешная компиляция не подтверждает GPU-исполнение.
На Windows llama.cpp можно запускать из подходящего готового выпуска или собирать самостоятельно. Для собственного варианта заранее выберите backend и следуйте соответствующему разделу официальной инструкции. Успешная компиляция базового проекта ещё не доказывает использование GPU: подтвердите устройство и размещение модели в журнале запуска.
Решите, зачем нужна собственная сборка
Готовый официальный выпуск удобен для первичной проверки, если он соответствует нужной платформе. Собственная сборка полезна при конкретной причине: нужный backend, исправление определённого commit или воспроизводимая конфигурация. Не добавляйте сложность только потому, что старый обзор начинает с компиляции.
Официальное руководство build описывает инструменты и разные аппаратные пути. Запишите ОС, компилятор, CMake, используемый SDK и исходную версию проекта. Такой паспорт позволит отличить ошибку подготовки среды от ограничения модели.
Выберите backend до конфигурации CMake
CUDA относится к поддерживаемой NVIDIA-среде, другие ускорители используют свои маршруты. Не устанавливайте CUDA для карты другого производителя ради одноимённого аргумента. Набор опций и зависимостей нужно выбирать по конкретному разделу документации и версии исходников.
Для подготовленной CUDA-среды учебный пример конфигурации:
cmake -B build -DGGML_CUDA=ON
cmake --build build --config ReleaseКоманды не устанавливают компилятор, SDK и драйвер. Если CMake сообщает об их отсутствии, сначала исправьте именно эту ступень. Повторное скачивание весов модели не поможет конфигурации проекта, которая ещё не смогла собрать нужный backend.
Проверьте, какой бинарник запускается
После сборки сохраните полный путь к исполняемому файлу. Несколько установок в PATH могут приводить к запуску старого CPU-варианта вместо нового. В многоконфигурационной сборке также различаются каталоги Debug и Release; ориентируйтесь на фактический вывод инструмента.
Выполните предусмотренную команду показа версии и справки. Затем запустите небольшой совместимый GGUF и изучите журнал устройств. Сравните дату, commit и backend с паспортом сборки. Репозиторий llama.cpp содержит актуальные ссылки на инструменты и выпуски, а не только на исходный код.
Отделите сборку от размещения модели
Если бинарник обнаружил GPU, следующий этап — выбранное число переносимых слоёв, память и контекст. Эти параметры не подтверждаются одним успешным сообщением компилятора. Для базового API используйте инструкцию llama-server, для размещения — руководство GPU layers.
Практический контроль: одна модель, короткий запрос, перезапуск из нового окна и повторный запрос. Такой опыт обнаруживает скрытую зависимость от временных переменных и текущего каталога. Затем переходите к более длинному документу, сохраняя отдельно результаты базовой совместимости и нагрузки.
Не удаляйте рабочий бинарник до проверки нового. Два подписанных каталога с паспортами сборок позволяют сравнить результат и быстро восстановить известный маршрут, не повторяя всю подготовку инструментов.
Практические выводы
Владелец рабочей станции может приложить версию сборки, backend, файл модели и команду. Добавьте условия доступности: использование компьютера другими приложениями, перезагрузки и режим сна. Эти ограничения относятся к эксплуатации ресурса, даже когда сама генерация работает корректно.
Для финансового партнёра полезно понимать, требуется ли дооснащение или только воспроизводимая программная среда. Это позволяет оценивать следующий пилот по уже проверенной цепочке, а не по факту наличия видеокарты в Windows.