llama.cpp benchmark: измерить скорость своей модели через llama-bench

Что покажет этот тест?

Представьте, что локальная нейросеть долго «думает» над вашим вопросом. llama-bench поможет разделить задержку на два этапа: pp — обработку входного текста и tg — выдачу новых частей ответа. Единица измерения — токены в секунду; токен здесь означает небольшой фрагмент текста, а не целое слово. Инструмент считает среднее по повторам и разброс значений, но не оценивает, насколько полезен ответ. s1

Результат этой инструкции — две строки замера для одной модели на вашем компьютере, которые можно сохранить и повторить после изменения настройки. llama-bench создаёт синтетическую нагрузку: реального письма или вопроса в тест вводить не нужно. Время разбиения текста на токены и выбора следующего токена в цифры инструмента не входит; не называйте эти цифры общей скоростью приложения. s1

Что понадобится до запуска?

Основной путь ниже — для Linux с обычным процессором, без обязательной видеокарты. Нужны Git, CMake, компилятор C/C++, curl, доступ к сети для загрузки исходников и файла модели, а также место на диске. На Ubuntu эти инструменты можно установить командой sudo apt update && sudo apt install -y git cmake build-essential curl. Сборка CPU документирована разработчиками llama.cpp; конкретный минимум оперативной памяти для предложенной пары «компьютер + файл GGUF» мы не подтверждали, поэтому не обещаем, что модель запустится на любом устройстве. Проверьте свободное место и память до загрузки; размер GGUF не равен требованию к RAM. s2

Модель примера — Qwen2.5-1.5B-Instruct, файл Q4_K_M в формате GGUF из официального репозитория Qwen. GGUF — формат файла, который читает llama.cpp; Q4_K_M — конкретный вариант сжатия весов. В закреплённой ревизии файл присутствует; карточка репозитория помечена Apache-2.0. Если у вас уже есть совместимый локальный GGUF, можно использовать его путь вместо скачивания, сохранив точное название и ревизию в заметках. s3 s5

После подготовки исходников и файла модели сам CPU-тест выполняется на этом компьютере без обращения к облачному API. Загрузка и установка требуют сети; не считайте наличие одного локального файла доказательством отсутствия сетевых запросов у других запущенных программ. Если приватность критична, после подготовки отключите сеть и повторите тест; редакция такой сетевой проверки не проводила. s1 s2

Как получить два сравнимых показателя?

1. В терминале выполните git clone https://github.com/ggml-org/llama.cpp.git, затем cd llama.cpp и git checkout 06cad0b9e77315bd2930bd4f70a6d7b37b2a01c1. Команда git rev-parse HEAD должна вывести этот же полный идентификатор. Так фиксируется версия инструмента, а не случайная будущая сборка. s1 s2
2. Выполните cmake -B build -DCMAKE_BUILD_TYPE=Release, затем cmake --build build --config Release -j 2. Проверьте наличие программы через ./build/bin/llama-bench --help: должен появиться список параметров -m, -p, -n, -r. На закреплённой ревизии каталог инструментов включает llama-bench; если сборка завершилась с ошибкой, к замеру не переходите. s1 s2 s4
3. Внутри каталога проекта выполните mkdir -p models, затем curl -fL 'https://huggingface.co/Qwen/Qwen2.5-1.5B-Instruct-GGUF/resolve/91cad51170dc346986eccefdc2dd33a9da36ead9/qwen2.5-1.5b-instruct-q4_k_m.gguf' -o models/qwen2.5-1.5b-instruct-q4_k_m.gguf. Убедитесь, что загрузка завершилась без ошибки и файл существует. Здесь указан точный файл и зафиксированная ревизия, а не плавающее main. s3 s5
4. Проверьте скорость обработки входа и выдачи: ./build/bin/llama-bench -m models/qwen2.5-1.5b-instruct-q4_k_m.gguf -ngl 0 -p 512 -n 128 -r 5 -o json > bench.json. -ngl 0 оставляет слои модели на CPU; -p 512 и -n 128 задают длины синтетических этапов; -r 5 повторяет каждый тест пять раз. В bench.json ожидаются записи с n_prompt: 512 и n_gen: 128, полями avg_ts, stddev_ts и отдельными samples_ts. Это форма ожидаемого результата, а не измеренные Modelium числа. s1
5. Откройте bench.json и запишите две строки avg_ts с единицей «токенов/с» вместе с stddev_ts. Сохраните рядом вывод git rev-parse HEAD, название/ревизию GGUF, модель процессора и ОС, backends, n_gpu_layers, n_threads, n_prompt, n_gen и число повторов из JSON. При повторном прогоне меняйте только одну настройку и сравнивайте одинаковый этап с таким же этапом; чужие цифры с другим железом не используйте как обещание скорости. s1

Как понять результат и избежать ошибки?

Сверьте, что файл содержит два разных теста, а не один ответ модели: запись для обработки входа (n_prompt=512, n_gen=0) и запись для выдачи (n_prompt=0, n_gen=128). Не складывайте скорости pp и tg и не обещайте по ним длительность произвольного диалога. Если программа не видит файл, проверьте точное имя и завершение скачивания; если завершается с ошибкой памяти, не выводите минимальную RAM из размера файла — возьмите меньшую совместимую модель и укажите, что это уже другой тест. s1

Скорость на CPU не равна скорости на видеокарте: для её проверки нужен отдельно собранный backend и новая серия измерений с зафиксированной настройкой, а не просто смена числа в таблице. Для проверки качества реального ответа после замера откройте общий гайд llama.cpp; если нужна нагрузка на работающий сервер, у vLLM bench serve другая методика и метрики. s1 s2