Документальный материал и расчётная методика. Результаты собственного тестирования оборудования не заявляются.
График загрузки GPU не отвечает на главный вопрос: получает ли пользователь полезный ответ в обещанное время. Ускоритель может быть занят обслуживанием одного длинного запроса, пока остальные ждут. И наоборот, низкая загрузка бывает нормальной для резервной мощности. Мониторинг инференса должен соединять пользовательский результат, поведение очереди и состояние оборудования.
Начать с обещания сервиса
Опишите два или три класса запросов. Например, короткий интерактивный ответ, поиск по документам и пакетная обработка. Для каждого задайте допустимое время первого ответа, полное время завершения, долю ошибок и условия измерения. Числовые пороги определяет бизнес-задача после пилота; универсальной хорошей задержки для всех LLM не существует.
Не смешивайте быстрые и тяжёлые операции в единственном среднем. Смотрите распределение, включая высокие перцентили, размер входа и ответа. Сравнивайте одинаковые окна времени при похожей нагрузке. Если вчера запросы содержали две страницы, а сегодня целый отчёт, изменение задержки может объясняться составом работы.
Измерить путь от клиента до токена
| Уровень | Что измерять | Какое решение поддерживает |
|---|---|---|
| Клиент | Полное время, обрывы, первый видимый токен | Соответствует ли сервис ожиданиям |
| Приложение | Аутентификация, поиск, подготовка контекста | Где возникает задержка до модели |
| Планировщик | Ожидание, активные и отклонённые запросы | Нужны ли квоты или дополнительная мощность |
| Генерация | TTFT, интервалы токенов, объём вывода | Как работают prefill и decode |
| Оборудование | Память, мощность, ошибки, температура | Есть ли ресурсное ограничение или неисправность |
Определения метрик различаются между инструментами. В документации vLLM per-request metrics момент начала отдельных измерений связан с планированием запроса 1. Клиентская задержка дополнительно включает сеть и прикладные этапы. Перед сравнением двух отчётов запишите точки начала и окончания таймеров. NVIDIA NIM также разделяет время первого токена и показатели дальнейшей генерации 2.
Полезный дашборд помещается на одном экране
Верхняя строка показывает долю успешных запросов, пользовательскую задержку и объём завершённой работы. Следом идут очередь и число активных запросов. Ниже — память, вычислительная загрузка, мощность и ошибки устройства. По такому порядку оператор сначала замечает воздействие на пользователя, затем ищет причину.
DCGM Exporter предоставляет метрики NVIDIA GPU для систем мониторинга 3. Доступность конкретного показателя зависит от оборудования, драйвера и настроек. Отсутствующее значение нельзя автоматически заменять нулём. Отдельно показывайте давность последнего измерения: остановившийся сборщик способен выглядеть как спокойный сервер.
Предупреждение должно вести к действию
Сигнал «GPU загружен на 95%» сам по себе может не требовать вмешательства. Более полезна комбинация: очередь растёт, задержка нарушает цель, число завершений не увеличивается. Для неё задайте действие — ограничить пакетные задания, проверить длинные запросы или направить поток на подготовленный резерв.
Для нехватки памяти предусмотрите проверку длин контекста, параллелизма и повторных попыток. Не уменьшайте параметры вслепую: можно улучшить доступность и одновременно испортить качество ответа. Для ошибок устройства должен существовать порядок диагностики и обращения по сервисному договору. Для каждого сигнала назначьте ответственного и время актуальности инструкции.
Журналы без лишних данных
Для расследования обычно полезны идентификатор запроса, версия модели, длительности, объёмы токенов и код ошибки. Полный текст диалога собирают только при определённой цели, основании и ограничении доступа. Секреты и документы не должны попадать в метки метрик: кроме риска раскрытия это создаёт чрезмерное число рядов и усложняет мониторинг.
Добавьте синтетическую проверку с заранее известным безопасным вопросом. Она должна проходить через тот же внешний API, что использует клиент, и проверять не только HTTP-статус, но и структуру ответа. После обновления сравнивайте результат с предыдущей версией при одинаковом наборе заданий.
В отчёте владельцу показывайте стоимость успешной полезной операции и долю выполнения SLO. Это связывает мониторинг с FinOps AI-инфраструктуры. Перед закупкой дополнительного сервера соберите такие данные на пилоте: они помогают отличить дефицит мощности от ошибки конфигурации или поиска.
Источники и проверка
- vLLM: Per-request metrics ↗Проверено: 2026-10-23
- NVIDIA NIM: LLM benchmarking metrics ↗Проверено: 2026-10-23
- NVIDIA DCGM Exporter metrics ↗Проверено: 2026-10-23

