# llama-bench: как отделить регрессию prompt processing от token generation

Чтобы локализовать регрессию llama.cpp, сначала отделите prompt processing от token generation через llama-bench.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/llama-bench-phase-regression/
Language: ru

Чтобы локализовать регрессию llama.cpp, сначала отделите prompt processing от token generation через llama-bench. Общая длительность API ответа смешивает вычисления, очередь и клиентскую обработку. Сравнивайте pp, tg и pg на одинаковых параметрах, глубине контекста и сборках. Числа из несопоставимых запусков не позволяют понять, изменилась ли конкретная фаза модели или просто объем выполненной работы и внешние условия эксперимента.

## Разберите типы измерений

[README llama-bench](https://raw.githubusercontent.com/ggml-org/llama.cpp/master/tools/llama-bench/README.md) описывает pp, tg и совместные pg режимы. Они отвечают на разные вопросы и не должны сливаться в одно число tokens per second. Сохраните точные параметры prompt processing и generation, а также depth контекста. Изолированный tg на малой глубине не характеризует любой длинный разговор. Перед сравнением укажите, какую фазу предполагается исследовать, и проверьте, что выбранная команда действительно выполняет именно ее, а не другой режим, случайно использованный в прежнем отчете.

## Зафиксируйте сборку и placement

[Руководство build](https://raw.githubusercontent.com/ggml-org/llama.cpp/master/docs/build.md) показывает зависимость executable от backend и compiler settings. Два коммита, собранные с разными оптимизациями, не изолируют изменение исходного кода. Запишите compiler, Toolkit, architecture targets, offload и threads. Если сравнивается именно новый backend, обозначьте это отдельной переменной. Не приписывайте весь эффект одному commit, когда одновременно поменялись CUDA targets, CPU native optimization или количество размещенных на GPU слоев: такая таблица отвечает уже на другой вопрос.

## Пример записи регрессии

Для старой и новой сборки создайте строки pp, tg и pg на двух выбранных глубинах контекста. Числа глубины выбираются по задаче и сохраняются в manifest; здесь они не задают универсального benchmark. В каждой строке отметьте параметры, повторения, наблюдаемую вариативность и functional smoke result. Если ухудшается только pp, исследуйте входную фазу. Если только tg на большой глубине, проверьте соответствующий путь чтения состояния и исполнения, не объясняя результат исключительно скоростью диска при загрузке checkpoint.

## Повторите условия, а не впечатление

Используйте сохраненные inputs и достаточные повторения, указывая разброс вместо одного удачного значения. Учитывайте прогрев, фоновые процессы и ограничения питания, если они меняются. Не смешивайте холодный startup с фазовым замером уже загруженной модели. При подозрении на дрейф повторите исходную сборку после новой. Если результат не воспроизводится, сохраните неопределенность вместо публикации точного процента регрессии, который опирается на случайный одиночный запуск. Сначала докажите устойчивость наблюдения, затем ищите его механизм.

## Вернитесь к serving отдельно

Фазовый benchmark локализует вычислительное изменение, но не заменяет HTTP нагрузку с batching и очередью. После локальной проверки повторите representative serving сценарий и покажите обе границы вывода. В пакет включите binary checksums, model revision, команды, raw results и параметры контекста. Не обещайте, что улучшенный pp автоматически уменьшит TTFT при перегруженном API. Полезный отчет объясняет, какая фаза изменилась, на каком depth и насколько стабильно это наблюдение. Он помогает разработчику повторить проблему и оператору оценить ее значимость для своего workload, не превращая один общий throughput в универсальную характеристику модели, GPU или всего сервера и не скрывая цену более быстрого prefill для decode на другой глубине.

## Связанные материалы

[Бенчмарк GPU для инференса, которому можно доверять](/ru/journal/inference-benchmark-method/); [vLLM bench serve: как прочитать результат командного теста](/ru/journal/vllm-bench-serve-command/).