Какие метрики нужно отслеживать в системе сервинга LLM?
Автоматический перевод
Эта статья была автоматически переведена с оригинальной английской версии.
Отслеживайте TTFT, TPOT, общую латентность, ошибки и goodput на стороне клиента, а также очереди сервера, длины в токенах, использование KV cache и вытеснения. Одна только загрузка GPU не позволяет отличить полезную работу от перегрузки. Оценивайте качество ответов отдельно: быстрый сервис тоже может возвращать неверные ответы.
Начните с результата, который видит пользователь
TTFT измеряет время от отправки запроса до первого выходного токена. TPOT измеряет средний интервал между последующими выходными токенами. Для как минимум двух выходных токенов:
Фиксируйте эти моменты при доставке первого и последнего выходного токена. Отдельно записывайте латентность до завершения запроса: финальные метаданные или очистка соединения могут происходить после последнего токена. Также фиксируйте отдельные задержки в доставке. Средний TPOT для запроса может скрыть паузу. Чанки SSE могут содержать несколько токенов, поэтому интервалы между чанками и между токенами — разные измерения.
Показывайте перцентили латентности по значимым группам нагрузки, например по длине промпта и модели. Используйте одинаковые границы измерения времени: серверные метрики не включают часть времени передачи по сети и обработки на клиенте.
Goodput считает запросы в секунду, которые выполняют все заданные SLO сервинга. Если сервис завершает 100 запросов в секунду, а 40 не соответствуют хотя бы одному обязательному порогу, goodput составляет 60 запросов в секунду. Это показатель производительности сервинга, а не фактической правильности ответов. DistServe использует goodput с ограничениями по латентности при оценке архитектур сервинга.
Добавьте метрики, которые объясняют сбои
Документация метрик vLLM описывает выполняемые и ожидающие запросы, гистограммы латентности, количество токенов, использование KV и вытеснения. Настройте дашборды под развёрнутую версию.
| Измерение | Что проверить при росте значения |
|---|---|
| Ожидающие запросы и время в очереди | Скорость поступления запросов относительно допустимой мощности обработки |
| Использование KV cache и вытеснения | Длинные последовательности, активные батчи и выделение памяти |
| TTFT при стабильном TPOT | Очереди, токенизацию, префилл или сетевую задержку |
| TPOT и задержки в доставке | Планирование декодирования, обращения к памяти или буферизацию на клиенте |
| Токены и повторные попытки на завершённый запрос | Более длинный вывод или повторную работу |
Метрика vLLM типа gauge vllm:kv_cache_usage_perc, несмотря на название, использует долю от 0 до 1. Определяйте пороги оповещений по результатам load tests и требуемому времени восстановления. Свяжите небольшой набор оценок качества и трейсов сбоев с метриками сервинга.
Об общей архитектуре читайте в разделе мониторинг LLM-систем руководства.