Гайд · TNWS AI

Как собрать метрики llama.cpp server через /metrics без ложных выводов

4 мин—

Включаем --metrics, читаем счётчики токенов и занятые запросы, отделяем throughput от задержки пользователя.

Задача и применимость

Поисковый вопрос: «как мониторить скорость токены в секунду llama.cpp metrics prometheus». Получить наблюдаемые метрики генерации и очереди, чтобы находить деградацию под нагрузкой. llama.cpp server c флагом --metrics; endpoint GET /metrics и имена метрик взяты из официального README проекта, проверенного 20 сентября 2026 года. В router mode нужен параметр ?model={model_id}.

Пример рассчитан на уже имеющийся файл модели, полученный законным способом по условиям его лицензии. Здесь не утверждается, что любая GGUF-модель одинаково понимает русский язык или имеет один и тот же чат-шаблон. Фактический номер сборки узнавайте локально через llama-server --version и повторяйте контрольный опыт после обновления бинарника.

Что подтверждено документацией

README перечисляет Prometheus-совместимый endpoint /metrics, доступный только с --metrics. Среди метрик: llamacpp:prompt_tokens_total, llamacpp:tokens_predicted_total, llamacpp:predicted_tokens_seconds, llamacpp:requests_processing и llamacpp:requests_deferred. В router mode отсутствие model в запросе к /metrics возвращает HTTP 400.

Порядок действий

  1. Запустите тестовый сервер с --metrics и проверьте /health.
  2. Получите текст GET /metrics и убедитесь, что есть ожидаемые имена метрик.
  3. Отправьте короткий контрольный запрос на генерацию без секретных данных.
  4. Повторите сбор, сравните изменения счётчиков и наблюдайте processing/deferred под нагрузкой.
  5. Параллельно измерьте клиентскую задержку p95: скорость токенов не заменяет времени ожидания.

Локальный запуск для описанного сценария (замените путь к файлу на ваш):

./build/bin/llama-server -m /models/your-chat-model.gguf --metrics --host 127.0.0.1 --port 8080

Готовый шаблон запроса и проверки

import urllib.request
url = "http://127.0.0.1:8080/metrics"
with urllib.request.urlopen(url, timeout=10) as response:
    metrics = response.read().decode("utf-8")
required = ["llamacpp:prompt_tokens_total",
            "llamacpp:tokens_predicted_total",
            "llamacpp:requests_processing",
            "llamacpp:requests_deferred"]
missing = [name for name in required if name not in metrics]
if missing:
    raise RuntimeError("Нет метрик: " + ", ".join(missing))
for line in metrics.splitlines():
    if line.startswith("llamacpp:requests_deferred"):
        print(line)

Входные данные и ожидаемый результат

Вход: локальный сервер с --metrics и два последовательных замера, между которыми выполнен искусственный вопрос. Ожидаемое наблюдение — текстовый формат с именами перечисленных метрик; после работы модели суммарные счётчики токенов меняются. Конкретную скорость заранее не обещаем.

Почему важна именно эта проверка

Счётчик накопленного числа токенов нужно интерпретировать как величину за время жизни процесса; после перезапуска он может обнулиться. Разницу между двумя снимками делите на прошедшее время, если нужна оценка пропускной способности за окно наблюдения. Gauge текущих requests_processing и requests_deferred характеризует момент проверки, а не историю всех запросов. Если у пользователя высокий p95, но predicted_tokens_seconds выглядит прилично, возможна очередь, длинная обработка prompt или большая загрузка модели; проверяйте этапы отдельно.

Работа с реальными данными

Режим router меняет способ адресации метрик: README требует параметр model, иначе HTTP 400. Не превращайте 400 в «метрик у сервера нет». Запишите идентификатор модели и отдавайте его вместе с запросом, затем убедитесь, что измеряете нужную нагрузку. Другой типичный сценарий — endpoint вообще недоступен, потому что флаг --metrics не был передан при старте. Не открывайте этот маршрут в публичный интернет только ради внешней панели: используйте отдельную закрытую сеть мониторинга, авторизацию на прокси и минимальную видимость.

Проверка после изменения модели или нагрузки

Мониторинг должен отвечать на действие: при росте requests_deferred уменьшите одновременную нагрузку, ограничьте длину ответа или проверьте ресурсы, а не автоматически увеличивайте количество слотов без измерения памяти. После обновления сборки сравните имена метрик и настройте тест-проверку, чтобы график не стал пустым незаметно. Пример кода проверяет присутствие метрики, но полноценный сборщик Prometheus должен парсить labels и временные ряды. Не выводите в метрики пользовательский промпт или персональные данные; это агрегированные числовые показатели.

Отдельно следите за парой llamacpp:prompt_tokens_total и llamacpp:prompt_seconds_total: их изменение помогает оценивать нагрузку обработки входа, независимо от генерации выходных токенов. Если после изменения промпта выросло число входных токенов, а модель стала отвечать медленнее, ускорение декодирования не устранит эту причину. Создайте контрольный сценарий с коротким и длинным контекстом, сравнивайте одинаковые окна времени после прогрева и фиксируйте изменения модели или контекста рядом с метриками, чтобы не получить ложное сравнение.

Критерии приёмки

  1. GET /metrics возвращает Prometheus-подобный текст с указанными именами.
  2. Счётчики и gauges не перепутаны при интерпретации.
  3. p95 времени ответа измеряется отдельно от скорости генерации.

Частые ошибки и чего не делать

  • Не ожидать /metrics без флага --metrics.
  • Не путать совокупное число токенов с tokens/s.
  • Не приписывать router-ошибку 400 поломке модели.

Краткие ответы на вопросы

Как включить /metrics?

При запуске добавить --metrics.

Что измеряет requests_deferred?

Текущие отложенные запросы согласно README.

Достаточно ли predicted_tokens_seconds для оценки UX?

Нет, измеряйте и клиентскую задержку.

Официальные источники

Частые вопросы

Как включить /metrics?

При запуске добавить --metrics.

Что измеряет requests_deferred?

Текущие отложенные запросы согласно README.

Достаточно ли predicted_tokens_seconds для оценки UX?

Нет, измеряйте и клиентскую задержку.

Читайте также

Комментарии

Пока тихо. Скажите первое слово