# Отчёт о простое GPU: как различать ожидание, недоступность и резерв

Как составить отчёт о простое GPU без двойного счёта: интервалы ожидания, резерва, работ и недоступности, источники наблюдений и ограничения финансовых выводов.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/gpu-idle-report-state-taxonomy/
Language: ru

Отчёт о простое GPU нужно строить по определённым состояниям и временным интервалам. Разделяйте ожидание задачи, собственный резерв, техническую недоступность и обслуживание. Один показатель загрузки не объясняет, почему машина не выполняла внешнюю работу и как это учитывается в расчётах.

Такой отчёт полезен владельцу и оператору для поиска ограничений. Он не должен автоматически превращать каждый свободный час в упущенный доход. Коммерческий смысл интервалов зависит от отдельно согласованной модели и подтверждённых событий, а не только от графика utilization.

## Определите взаимно исключающие состояния

Для одного ресурса в конкретный момент выберите одно основное состояние, а причины сохраняйте отдельными признаками. Например, GPU может быть доступен без запросов или занят собственным резервом. Эти ситуации не стоит одновременно записывать в несколько итоговых сумм.

Условный день для одного GPU:

| Состояние | Длительность | Что запись означает |
| --- | --- | --- |
| Внешняя работа | 8 часов | Выполнялась определённая нагрузка |
| Готов без задачи | 10 часов | Ресурс был доступен |
| Собственный резерв | 2 часа | Внешняя работа не предполагалась |
| Обслуживание | 2 часа | Выполнялись согласованные действия |
| Недоступность | 2 часа | Нужный ресурс не был готов |

Сумма равна 24 часам только потому, что интервалы примера не пересекаются. В реальном отчёте сначала проверяют временную шкалу, а затем считают длительность.

## Сопоставьте несколько источников

[NVIDIA DCGM Health Monitoring](https://docs.nvidia.com/datacenter/dcgm/latest/learn/modules/health-monitoring.html) описывает пассивные проверки по телеметрии. Такой источник помогает увидеть состояние оборудования, но не объясняет автоматически наличие запросов приложения. Отсутствие аппаратного предупреждения не подтверждает готовность полного сервиса.

[Метрики vLLM](https://docs.vllm.ai/en/latest/usage/metrics/) дают сведения о стороне обслуживания модели. Для выбранной системы нужно определить доступные показатели и их смысл. Если аппаратная и прикладная картины расходятся, сохраните оба наблюдения вместо подмены одного другим.

## Храните причины отдельно от выводов

Для недоступности укажите наблюдаемое событие и установленную причину, если она известна. Потеря связи, остановка процесса и отсутствие подтверждения — разные записи. Неизвестная причина должна оставаться неизвестной до проверки.

Укажите дату, часовой пояс и источник каждого существенного события. Если данные собирались с разной частотой, длительность может быть оценкой. Не создавайте точность до секунды, когда исходное наблюдение выполнялось только раз в несколько минут.

## Проверьте итог периода

Сумма основных состояний должна соответствовать выбранному периоду с явно показанными пробелами данных. Время без наблюдений не следует автоматически считать исправной работой или простоем. Для него можно использовать отдельную отметку неопределённости.

Финансовую часть отчёта связывают с согласованными правилами. Даже внешняя нагрузка может быть тестовой, а готовность без задач — не иметь начисления. Поэтому технические интервалы сохраняют отдельно от подтверждённой оплаченной работы и корректировок.

## Используйте отчёт для улучшения

Посмотрите, какая причина повторяется и какое действие может её изменить. Например, обслуживание и потеря сети требуют разных решений. Новый GPU не устраняет автоматически ограничение площадки или неясность расписания.

Для подготовки полезны [показатели работы GPU](/ru/journal/capacity-reporting/) и [мониторинг по уровням](/ru/journal/gpu-monitoring-scorecard/).