Перейти к содержанию

Типы экземпляров службы графического процессора

Типы экземпляров службы графического процессора описывают формы вычислений — только с использованием ЦП или с поддержкой ускорителя — из которых создаются Экземпляры службы графического процессора.

Оператор GPUStack поддерживает ускорители нескольких производителей — AMD, Ascend, Cambricon, Hygon, Iluvatar, MetaX, Moore Threads, NVIDIA и T-Head. Для каждого производителя ускоритель может быть выделен эксклюзивно (все устройство), общий или логически нарезанный (разделение программного обеспечения с независимыми бюджетами VRAM и вычислений). NVIDIA, T-Head и Hygon дополнительно поддерживают физическое разделение (MIG), при котором устройство разделяется аппаратно. Подробную информацию о каждом производителе см. в матрице поддержки ускорителей оператора.

Просмотр типов экземпляров

Открыть GPU Service > Instance Types. На странице перечислены типы экземпляров каждого кластера службы графического процессора, который вы видите, с именем кластера-владельца в каждой строке:

Снимок экрана: страница «Типы инстансов» со списком типов инстансов в кластерах

  • Имя/Вкус: имя типа (или его отображаемое имя) и вариант, к которому он принадлежит — модель устройства, например NVIDIA-H100-80GB-HBM3 или CPU-only.
  • Единица ЦП/Единица ОЗУ/Хранилище: Ресурсы хоста, предоставляемые на единицу этого типа. Что касается ускорителя, то один блок — это одно целое устройство; Размеры логических срезов и физических разделов определяются на основе них во время создания.
  • Платформа: операционная система и архитектура процессора, полезно при выборе совместимого образа.
  • Кластер: кластер, к которому принадлежит тип.
  • Статус: Active типа можно выбрать в форме Добавить экземпляр графического процессора; Inactive нельзя.

Используйте селектор Filter by cluster на панели инструментов, чтобы сузить список до одного кластера, и поле поиска для сопоставления типов по отображаемому имени или имени — любое значение может отображаться в столбце Name. Фильтрация, сортировка и нумерация страниц применяются на стороне сервера, а порядок столбцов Name сортируется по отображаемой метке. Действия со строкой — деактивировать, активировать, удалить — всегда действуют на кластер, указанный в столбце «Кластер» строки.

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

Вы также можете узнать живую емкость каждого типа с помощью kubectl. Четыре представления акселератора: EXвключительный, SHared, SLiced (логический) и PT (физически разделенный); вид ускорителя и столбец CPU одинаково читают onceMaxRequest/remaining:

kubectl get instancetypes
1
2
3
4
NAME                                          ENTRANCE                          UNIT(CPU/RAM)/STORAGE   ACCELERATOR(EX/SH/SL/PT)   CPU     PHASE
gpustack--generic-linux-amd64                 gpustack-fnv64-3b93966fd73eb9ec   1/2Gi/100Gi             0/0 0/0 0/0 0/0            16/40   Active
gpustack--nvidia-h100-80gb-hbm3-linux-amd64   gpustack-fnv64-e4768a65ca0ce96b   12/192Gi/100Gi          1/1 10/10 100/100 1/7      0/0     Active
gpustack--nvidia-l40s-linux-amd64             gpustack-fnv64-a730f1dca9e26fca   12/128Gi/100Gi          1/1 10/10 100/100 0/0      0/0     Active

В этом прочтении недавно добавленного кластера тип H100 предлагает исключительно одно целое устройство (EX 1/1), десять общих слотов (SH 10/10), полный бюджет логических срезов (SL 100/100) и семь слотов разделов MIG (PT 1/7, от второго узла H100 с включенным MIG). Тип L40S предлагает одно устройство таким же образом, за исключением разделения на разделы (PT 0/0 — L40S не имеет MIG), а общий тип только для ЦП вообще не имеет мощности ускорителя.

Производные типы экземпляров

Когда Derive Instance Types from Nodes имеет значение Включено (по умолчанию) в кластере службы графического процессора, оператор обнаруживает устройства каждого узла и автоматически создает соответствующие типы экземпляров — по одному на каждую модель ускорителя плюс тип только для ЦП. Список выше представляет собой такой производный набор.

ЦП/ОЗУ устройства производного типа получаются из предустановок для каждого продукта, поддерживаемых оператором, как описано в Справочнике по ресурсам единиц типа экземпляра. Объем хранилища всегда составляет 100 ГиБ, а производный тип только для ЦП всегда равен 1 ЦП / 2 ГБ ОЗУ.

Производные типы принадлежат оператору:

  • Их нельзя удалить из пользовательского интерфейса — для них отключено действие Delete:

Снимок экрана: действие «Удалить» отключено для производного типа экземпляра

  • Удаление одного с помощью kubectl также не сохраняется: оператор повторно создает его при следующем согласовании. (Воссоздание производного типа таким способом фактически является поддерживаемым способом изменения его размера после обновления оператора, поскольку ресурсы модуля отмечаются один раз при создании.)

Чтобы навсегда удалить производный тип, сначала установите для Derive Instance Types from Nodes значение Отключено в кластере (см. Дополнительные параметры кластера); затем оператор прекращает создание типов, а существующие производные можно удалить.

Добавление типа экземпляра

Добавьте пользовательский тип экземпляра, если производные не подходят — например, более крупную форму, предназначенную только для ЦП. Нажмите Add Instance Type и заполните форму:

Снимок экрана: форма добавления типа экземпляра

  • Кластер: кластер, в котором создан тип.
  • Имя: имя типа. В нижнем регистре и безопасно для Kubernetes, поскольку оно становится частью имени базового ресурса. Оно должно быть уникальным в пределах кластера: повторное использование имени существующего типа, в том числе производного, отклоняется, а не перезаписывает его.
  • Отображаемое имя: необязательное понятное имя, отображаемое в пользовательском интерфейсе.
  • Вкус: CPU-only или аромат-ускоритель, который несет выбранный кластер. Варианты выбора следуют за полем «Кластер».
  • OS / Arch: Платформа, на которую нацелен тип.
  • ЦП/ОЗУ/хранилище: Ресурсы хоста, предоставленные на единицу.

Нажмите Save. Новый тип появится в списке и в форме Добавить экземпляр графического процессора:

Скриншот: пользовательский тип экземпляра CPU-Large в списке

Примечание

Пользовательский тип экземпляра никогда не модифицируется оператором — производный тип всегда создает только типы и никогда не затрагивает те, которые он не создал только что.

Деактивация и активация типа экземпляра

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

Скриншот: подтверждение деактивации типа экземпляра

Тип изменится на Inactive и его больше нельзя будет выбрать в форме Добавить экземпляр графического процессора:

Скриншот: тип неактивного экземпляра

Нажмите то же действие еще раз и подтвердите, чтобы активировать его обратно:

Скриншот: подтверждение активации типа экземпляра

Удаление типа экземпляра

Откройте меню действий в строке типа и нажмите Delete:

Снимок экрана: действие «Удалить» в меню действий типа экземпляра

Подтвердите удаление:

Снимок экрана: подтверждение удаления типа экземпляра

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

Физическое разделение (MIG)

Устройство с физическими разделами (MIG) не получает свой собственный тип экземпляра: его разделы отображаются как емкость раздела (представление PT) в типе экземпляра устройства, и вы выбираете профиль раздела при добавлении экземпляра.

Оператор поддерживает MIG на ускорителях NVIDIA, T-Head и Hygon. Сам режим MIG является свойством для каждого узла, управляемым администратором — оператор наблюдает за ним, но никогда не включает, не отключает и не перенастраивает его. Чтобы предложить разделы на узле, включите MIG на узле с помощью инструментов вендора и перезапустите там диспетчер устройств оператора, например на узле NVIDIA:

1
2
3
4
# On the node, per GPU or for all GPUs:
sudo nvidia-smi -i <id> -mig 1
# Then, from anywhere with cluster access:
kubectl -n gpustack-system rollout restart ds/gpustack-operator-device-manager-nvidia

Полную процедуру, предварительные условия и ограничения каждого поставщика см. в справочниках операций MIG оператора, включая то, что экземпляры MIG никогда не переживают перезагрузку узла: