Инструменты мониторинга CPU и памяти не переносятся на графические процессоры GPU в Kubernetes с такой же лёгкостью. Хотя платформа обычно предоставляет показатели использования на уровне контейнера или Pod, при совместном использовании GPU платформенным командам приходится самостоятельно создавать большую часть уровней видимости, распределения и биллинга — от сбора данных до определения доли каждой команды в затратах.
Важность проблемы связана с тем, что GPU обычно представляет собой самую дорогую статью в счёте за инфраструктуру. Анализ указывает, что эксплуатационные расходы не ограничиваются стоимостью узла: они также включают инженерное время, необходимое для компенсации пробелов в измерениях, проверки точности показателей и предотвращения превышения нагрузками объёма, выделенного им Kubernetes.
Почему обычных показателей недостаточно?
Инструмент NVIDIA DCGM exporter, с которого начинают многие операторы, по умолчанию предоставляет данные на уровне физического устройства. Когда Pod владеет целым GPU, этого может быть достаточно, однако при использовании time-slicing или MPS для совместного использования устройства ситуация меняется. В этом случае одно и то же значение может отображаться для каждого Pod, использующего один GPU, и будет казаться, будто три нагрузки потребили 300% фактически несуществующего устройства.
Проблема заключается в том, что графики могут выглядеть корректно, несмотря на непригодность исходных данных для распределения. Поэтому команды могут построить полноценные отчёты и панели мониторинга на показателях, которые фактически не различают потребителей.
Что практически меняется для платформенных команд?
GPU также отличается от CPU моделью распределения ресурсов. В Kubernetes GPU обычно отображается как целочисленный ресурс, например nvidia.com/gpu: 1, и планировщик не позволяет работать с дробными частями так, как это обычно делается с процессорами. Фактическое совместное использование происходит ниже уровня планировщика посредством time-slicing, MPS или MIG, что усложняет сравнение запрошенного нагрузкой ресурса с использованным.
Командам также необходимы независимые средства контроля, чтобы убедиться, что ресурс, который Kubernetes зарегистрировал как выделенный, соответствует тому, к чему приложение действительно может получить доступ. Переменная окружения NVIDIA_VISIBLE_DEVICES при отсутствии подходящей настройки может привести к тому, что контейнер увидит все GPU на узле, даже если планировщик выделил ему только один.
Кроме того, выражение «использование GPU на 80%» не обязательно имеет единственное значение. Оно может измерять лишь наличие работающего ядра в течение части окна выборки, не объясняя потребление вычислительной мощности или пропускную способность памяти. В некоторых фреймворках, например vLLM, большая часть памяти GPU может резервироваться при запуске, поэтому память или пропускная способность могут быть более важным показателем, чем общий показатель использования.
Биллинг: память проще распределять, чем вычисления
Библиотека NVIDIA NVML может показать объём памяти, удерживаемый каждым процессом, а затем связать процесс с Pod и ответственной за него командой; при этом сумма значений не будет равна полной памяти карты, поскольку часть памяти удерживается самим драйвером.
Точность распределения вычислительного времени между параллельно работающими нагрузками ограничена. Две нагрузки могут выглядеть так, будто каждая из них активна на 90%, но показатели не объяснят, какая из них потребила 70% мощности, а какая — 30%. Поэтому анализ предлагает использовать память GPU как практическую основу для внутреннего биллинга, рассматривая измерение вычислений как операционный показатель, а не как точный ориентир для выставления счетов.
Выбор модели совместного использования меняет расчёты
Совместное использование GPU не означает одну-единственную модель. time-slicing поочерёдно использует устройство без изоляции, MPS позволяет одновременно запускать ядра разных процессов, а MIG делит оборудование на фиксированные части. При этом облачные сервисы могут взимать плату за весь физический GPU даже при использовании его части; кроме того, согласно материалу, карты классов A100 и H100 можно разделить максимум на семь экземпляров.
Dynamic Resource Allocation (DRA) становится будущим направлением управления ресурсами, однако всё ещё находится на этапе развития, а окружающие его инструменты, включая инструменты масштабирования вроде Karpenter, следуют за этим развитием.
Почему эта новость важна?
На AWS стоимость самого дешёвого GPU, совместимого с MIG, класса A100 составляет около 22 долларов в час, или примерно 14 долларов при использовании спотового ценообразования, против около 5 долларов в час за сопоставимый экземпляр только на CPU, согласно материалу. Поэтому ошибка в распределении использования — не небольшая бухгалтерская проблема: она может напрямую повлиять на решения по ёмкости и затратам, а также на справедливость распределения нагрузки между командами.
Редакционный вывод заключается в том, что эксплуатация GPU в Kubernetes по-прежнему требует иной операционной модели, чем модель для CPU и памяти. Платформенным командам необходимо определить, что можно измерить точно, установить ясные правила распределения затрат и не принимать бухгалтерские решения на основе общего показателя GPU, который не описывает реальное потребление. В то же время источник указывает, что развитие DRA и разделение оборудования могут постепенно сократить этот разрыв, однако сроки этого процесса и ограничения существующих инструментов остаются открытыми вопросами.