В этом материале
Каждый показатель должен помогать принять решение. Согласуйте состояние оборудования, готовность сервиса, полезную работу и ответственного за действие, а не собирайте графики ради количества.
Владелец предоставляет GPU и хочет понимать, что происходит с машиной. Оператору нужны признаки неисправностей и перегрузки. Партнёру, оплачивающему эксплуатацию, нужны объяснимые расходы. Один показатель загрузки не отвечает на все эти вопросы, поэтому для пилота полезно заранее определить несколько уровней наблюдения.
Уровень оборудования
Начните со состояния устройства и ограничений площадки. Температура, питание, аппаратные события и доступность GPU помогают понять, может ли машина продолжать согласованную работу. Поддержка конкретных показателей зависит от модели оборудования и инструментов.
NVIDIA DCGM различает наблюдение за состоянием и активную диагностику. Это полезная основа для процедуры: обычный сбор телеметрии и специальный тест не следует считать одинаковым вмешательством в работу сервера.
До пилота согласуйте, кто реагирует на отклонение и кто вправе остановить нагрузку. Автоматический график не заменяет такого решения.
Уровень ресурсов
Память, занятость вычислений, CPU, диск и сеть помогают объяснять ограничения. Смотрите на временной ряд, а не только на одиночное значение. Свяжите его с составом запросов и изменениями окружения.
Например, рост занятой памяти может совпасть с переходом к длинным входам. Это другой диагностический сценарий, чем внезапное исчезновение устройства. В отчёте полезно оставить контекст события, чтобы следующая смена специалиста не начинала расследование заново.
Не включайте в телеметрию содержимое чужих документов только ради удобства анализа. Технические показатели и данные пользователей требуют отдельного определения состава и доступа.
Уровень сервиса
Проверьте, загружена ли нужная модель и доступен ли endpoint снаружи согласованного контура. Включённый сервер может ещё не быть готовым принимать запросы. Для каждой стадии полезна собственная проверка.
Метрики vLLM позволяют наблюдать очередь и время обработки. Конкретный набор выбирают под версию движка и продукт. Не обещайте владельцу показатели, которые выбранный стек фактически не собирает.
Добавьте событие обновления или обслуживания. Иначе плановое снижение готовности будет выглядеть как неизвестный сбой, а сравнение периодов окажется несправедливым.
В карточке инцидента сохраняйте время обнаружения, затронутый узел, наблюдаемые признаки и принятое действие. Даже короткая последовательная запись помогает отличить повторяющуюся проблему от единичного события и проверить, сработало ли обслуживание.
Уровень полезного результата
Нужно различать принятые запросы, успешные завершения, ошибки и отмены. Для некоторых задач добавляется проверка структуры или качества. Сотня технически выданных ответов не обязательно означает сотню пригодных результатов.
В пробном отчёте соедините эти сведения с интервалом и идентификатором ресурса. Тогда владелец сможет увидеть, к какой машине относится работа, не получая доступа к клиентским данным.
Финансовые начисления показывайте отдельно по согласованным правилам. Технический счётчик не должен незаметно превращаться в обещание оплаты.
Уровень действия
Для значимых сигналов запишите дальнейший шаг: наблюдать, ограничить поток, вывести узел на обслуживание или вызвать специалиста площадки. Проверьте процедуру на пилоте с безопасным тестовым событием.
Для продолжения пригодятся безопасность доступа, сеть и доступность и отчётность владельцу.