Перейти к основному содержимому

Стратегия сбора метрик производительности (Performance Metrics Strategy)

1. Проблема​

API инференс-движков (vLLM, SGLang) в ответе на запрос (/v1/chat/completions) обычно возвращает только сгенерированный текст и количество токенов (usage). Они не предоставляют информацию о потреблении памяти GPU или точном времени обработки конкретного запроса на стороне сервера.

2. Источники метрик​

2.1. Client-Side Metrics (Измеряются Оркестратором или Wrapper'ом)​

Стандартные метрики для оценки производительности инференса LLM/VLM:

  • Latency (E2E): Полное время от отправки запроса до получения последнего токена.
  • TTFT (Time to First Token): Время до появления первого токена. Критично для интерактивных приложений.
  • TPOT (Time Per Output Token): Среднее время генерации одного токена (исключая префилл).
  • Throughput (TPS): Tokens Per Second — общая пропускная способность системы.
  • ITL (Inter-Token Latency): Задержка между генерацией последовательных токенов (важно для плавности стриминга).

2.2. Server-Side Metrics (Prometheus / /metrics)​

vLLM и SGLang экспортируют метрики в формате Prometheus по эндпоинту /metrics.

  • vLLM:
    • vllm:gpu_cache_usage_perc: Процент использования KV-кэша.
    • vllm:num_requests_running: Количество активных запросов.
  • SGLang:
    • Аналогичные метрики использования памяти и очереди.

Проблема: Эти метрики агрегированные (общие для сервера), их сложно сопоставить с конкретным запросом/картинкой в многопоточной среде.

2.3. System-Level Metrics (NVIDIA SMI / PyNVML)​

Мониторинг ресурсов "снаружи" или внутри Wrapper'а.

  • GPU Memory:
    • Idle Memory: Память, занятая весами модели до начала генерации.
    • Peak Memory: Максимальное потребление памяти во время генерации (активации + KV-кэш).
  • GPU Util: % утилизации GPU (Volatile GPU Utilization).

3. Решение для VLMHyperBench​

Для точного профилирования предлагается гибридный подход:

3.1. Benchmarking Mode (Single Concurrency)​

Для получения "чистых" метрик потребления ресурсов моделью:

  1. Запускать инференс в один поток (concurrency=1).
  2. Параллельно с запросом запускать сборщик метрик (nvidia-smi poll).
  3. Сопоставлять пиковое потребление памяти с запросом.

3.2. Production Mode (High Concurrency)​

Для оценки пропускной способности:

  1. Измерять Client-Side Latency и TTFT.
  2. Считать Total Throughput (RPM, TPS) для всего батча.
  3. Мониторить /metrics сервера для оценки утилизации GPU в целом, а не на запрос.

4. Реализация в Архитектуре​

4.1. API Wrapper (Proxy)​

Внедрение Inference API Wrapper (FastAPI), который оборачивает вызовы к vLLM/SGLang/HF.

  • Роль: Проксирование запросов + измерение метрик "на месте".
  • Функции:
    1. Замер start_time и mem_usage_before.
    2. Вызов реального бэкенда.
    3. Замер ttft (при стриминге) и end_time.
    4. Замер mem_usage_peak (через фоновый тред или pynvml poll).
    5. Возврат ответа с добавленным полем metrics.

4.2. Performance Monitor (Sidecar - опционально)​

Для глубокой отладки (nsys, torch profiler) можно использовать sidecar-контейнер, но для основных метрик достаточно Wrapper'а.

Итог:

  • Wrapper обеспечивает унифицированный сбор TTFT, TPOT, Latency и Memory Peak для любого бэкенда.
  • Оркестратор получает готовые метрики в ответе API, что упрощает агрегацию.