Najlepsze rozwiązania dotyczące procesora GPU dla usługi Azure Kubernetes Service (AKS)

Dotyczy: ✔️ AKS Automatic AKS Standard ✔️

Uruchamianie obciążeń procesora GPU w usłudze AKS wymaga prawidłowej konfiguracji i ciągłej walidacji, aby zapewnić dostępność, bezpieczeństwo i optymalne wykorzystanie zasobów obliczeniowych. W tym artykule opisano najlepsze rozwiązania dotyczące zarządzania węzłami z obsługą procesora GPU, weryfikowania konfiguracji i zmniejszania przerw w obciążeniu.

W przypadku większości produkcyjnych obciążeń AKS zalecanym wyborem domyślnym jest AKS Automatic. Usługa AKS Automatic zapewnia gotową do użycia w środowisku produkcyjnym podstawę ze wstępnie skonfigurowanymi funkcjami operacyjnymi, zabezpieczeniami oraz gotowością zasobników objętą umową SLA, pomagając zespołom zmniejszyć nakład pracy związany z utrzymaniem platformy po wdrożeniu.

Wybieranie usługi AKS Automatic lub AKS Standard dla obciążeń procesora GPU

Skorzystaj z poniższych wskazówek jako punktu wyjścia:

Scenario Zalecana ścieżka Dlaczego
Większość obciążeń produkcyjnych procesora GPU Automatyczne usługi AKS Domyślne ustawienia gotowe do wdrożenia produkcyjnego, wbudowane zabezpieczenia i mniejsze obciążenie związane z obsługą klastra.
Szybsza ścieżka od wdrożenia do stabilnej produkcji Automatyczne usługi AKS Wstępnie skonfigurowana obsługa klastra i przewidywalny przebieg uruchamiania dzięki SLA gotowości podów.
Zaawansowane dostosowywanie platformy i jawna kontrola operacyjna AKS Standard Większa elastyczność w zakresie cyklu życia niestandardowej puli węzłów i dostosowywania platformy.
Wyspecjalizowane, nie domyślne wymagania dotyczące architektury platformy AKS Standard Bardziej ręczna kontrola nad zachowaniem i konfiguracją infrastruktury.

Aby uzyskać więcej informacji, zobacz Wprowadzenie do usługi Azure Kubernetes Service (AKS) Automatic.

Co usługa AKS Automatic zapewnia dla obciążeń produkcyjnych procesorów GPU

Usługa AKS Automatic pomaga w ustanowieniu silnego punktu odniesienia operacyjnego dla obciążeń produkcyjnych procesora GPU, zapewniając:

  • Ustawienia domyślne gotowe do użycia w środowisku produkcyjnym dla konfiguracji klastra.
  • Wbudowane najlepsze rozwiązania i zabezpieczenia.
  • Gotowość zasobnika wspieranego przez umowę SLA do przewidywalnego zachowania uruchamiania.
  • Operacje klastra zarządzanego, które zmniejszają liczbę zadań wykonywanych ręcznie w ciągu dnia 2.

Te domyślne ustawienia platformy nie zastępują najlepszych praktyk na poziomie obciążeń, takich jak mechanizmy kontroli rozmieszczania, sprawdzanie poprawności i zasady izolacji opisane w tym artykule.

Obciążenia procesora GPU, takie jak trenowanie modelu sztucznej inteligencji, wnioskowanie w czasie rzeczywistym, symulacje i przetwarzanie wideo, często zależą od:

  • Poprawność zgodności sterownika procesora GPU i środowiska uruchomieniowego.
  • Dokładne planowanie zasobów procesora GPU.
  • Dostęp do urządzeń sprzętowych gpu wewnątrz kontenerów.

Błędy konfiguracji mogą prowadzić do wysokich kosztów, nieoczekiwanych błędów zadań lub niedostatecznego wykorzystania procesora GPU.

Wymuś lokalizację obciążeń GPU

Domyślnie harmonogram AKS umieszcza zasobniki na dowolnym dostępnym węźle z wystarczającymi zasobami procesora i pamięci. Bez kontrolek umieszczania obciążenia mogą wystąpić dwa problemy:

  • Planista może umieszczać zadania GPU na węzłach bez GPU, przez co zadania te nie mogą się uruchomić.
  • Obciążenia ogólnego przeznaczenia mogą zajmować węzły procesora GPU, marnując kosztowne zasoby.

Aby wymusić prawidłowe rozmieszczenie:

  • Oznacz swoje węzły GPU, używając klucza takiego jak [gpu-vendor].com/gpu: NoSchedule (na przykład nvidia.com/gpu: NoSchedule). To skażenie blokuje planowanie na tych węzłach obciążeń niewykorzystujących GPU.

  • Dodaj zgodną tolerancję w specyfikacji zasobnika obciążenia procesora GPU, aby można je było zaplanować na skażonych węzłach procesora GPU.

  • Zdefiniuj żądania i limity zasobów GPU w swoim podzie, aby harmonogram mógł zarezerwować zasoby GPU. Przykład:

    resources:
      limits:
        [gpu-vendor].com/gpu: 1
    
  • Użyj zasad walidacji lub kontrolerów dopuszczenia, aby wymusić, by obciążenia GPU obejmowały wymagane tolerancje i limity zasobów.

Takie podejście gwarantuje, że tylko zadania przystosowane do pracy z GPU trafiają na węzły GPU i mają dostęp do wyspecjalizowanych zasobów obliczeniowych, których potrzebują.

W usłudze AKS Automatic zabezpieczenia platformy są domyślnie wstępnie skonfigurowane. Nadal stosujesz mechanizmy kontroli rozmieszczania na poziomie obciążenia roboczego, aby wymusić ścisłe zasady planowania GPU.

Weryfikowanie gotowości sterownika procesora GPU i środowiska uruchomieniowego

Przed wdrożeniem produkcyjnych obciążeń procesora GPU zawsze sprawdź, czy pule węzłów procesora GPU są następujące:

  • Wyposażony w zgodne sterowniki procesora GPU.
  • Utrzymywanie DaemonSetu wtyczki urządzenia Kubernetes w dobrej kondycji.
  • Udostępnianie [gpu-vendor].com/gpu jako zasobu podlegającego harmonogramowaniu.

Możesz potwierdzić bieżącą wersję sterownika uruchomioną w pulach węzłów procesora GPU za pomocą interfejsu zarządzania systemem skojarzonego z dostawcą procesora GPU.

Poniższe polecenie uruchamia nvidia-smi w podzie wdrożenia wtyczki urządzenia GPU, aby zweryfikować instalację sterownika i gotowość środowiska uruchomieniowego w puli węzłów z obsługą procesorów graficznych NVIDIA:

kubectl exec -it $"{GPU_DEVICE_PLUGIN_POD}" -n {GPU_NAMESPACE} -- nvidia-smi

Dane wyjściowe powinny przypominać następujące przykładowe dane wyjściowe:

+-----------------------------------------------------------------------------+
|NVIDIA-SMI 570.xx.xx    Driver Version: 570.xx.xx    CUDA Version: 12.x|
...
...

Powtórz polecenie kubectl exec dla każdej puli węzłów GPU, aby sprawdzić wersję sterownika zainstalowanego na węzłach.

W pulach węzłów z obsługą procesorów GPU firmy AMD możesz alternatywnie wdrożyć składniki GPU firmy AMD i wykonać polecenie amd-smi w podzie wtyczki urządzenia ROCm, aby potwierdzić zainstalowaną wersję sterownika.

Aktualizowanie węzłów z obsługą procesora GPU do najnowszego obrazu systemu operacyjnego węzła

Aby zapewnić wydajność, bezpieczeństwo i zgodność obciążeń GPU uruchamianych w usłudze AKS, należy utrzymywać pule węzłów GPU w aktualnym stanie, korzystając z najnowszych zalecanych obrazów systemu operacyjnego węzła. Te aktualizacje są krytyczne, ponieważ:

  • Uwzględnij najnowsze produkcyjne sterowniki GPU, zastępując wszystkie przestarzałe lub wycofane z eksploatacji (EOL) wersje.
  • Są w pełni przetestowane pod kątem zgodności z bieżącą wersją rozwiązania Kubernetes.
  • Rozwiąż znane luki w zabezpieczeniach zidentyfikowane przez dostawców procesora GPU.
  • Uwzględnij najnowsze ulepszenia środowiska uruchomieniowego systemu operacyjnego i kontenera w celu zwiększenia stabilności i wydajności.

Uaktualnij pule węzłów GPU do najnowszego zalecanego obrazu systemu operacyjnego dla węzłów udostępnionego przez usługę AKS, ustawiając kanał automatycznej aktualizacji lub wykonując aktualizację ręczną. Najnowsze wydania obrazów węzłów można monitorować za pomocą narzędzia AKS Release Tracker.

W przypadku większości scenariuszy produkcyjnych zacznij od usługi AKS Automatic jako domyślnego punktu odniesienia. Jeśli używasz usługi AKS Standard, jawnie skonfiguruj kanały uaktualniania i okna obsługi.

Oddzielne obciążenia procesora GPU w przypadku korzystania z klastrów udostępnionych

Jeśli pojedynczy klaster usługi AKS z pulami węzłów GPU obsługuje wiele typów obciążeń GPU, takich jak trenowanie modeli, wnioskowanie w czasie rzeczywistym lub przetwarzanie wsadowe, ważne jest rozdzielenie tych obciążeń, aby:

  • Unikaj przypadkowej ingerencji lub rywalizacji o zasoby między różnymi typami obciążeń.
  • Zwiększ bezpieczeństwo i zachowaj granice zgodności.
  • Uproszczenie zarządzania i monitorowania użycia zasobów procesora GPU na kategorię obciążenia.

Obciążenia GPU można izolować w pojedynczym klastrze AKS przy użyciu przestrzeni nazw i zasad sieciowych. Umożliwia to bardziej przejrzyste zarządzanie dzięki kwotom, limitom i konfiguracjom rejestrowania dedykowanym poszczególnym obciążeniom.

Przykładowy scenariusz

Rozważ klaster usługi AKS hostujący dwa różne typy obciążeń procesora GPU, które nie muszą komunikować się ze sobą:

  • Obciążenia szkoleniowe: zadania trenowania modelu sztucznej inteligencji intensywnie korzystające z zasobów.
  • Obciążenia wnioskowania: usługi wnioskowania w czasie rzeczywistym z uwzględnieniem opóźnień.

Aby oddzielić dwa obciążenia, możesz użyć następujących kroków:

  1. Utwórz dedykowane przestrzenie nazw na typ obciążenia przy użyciu kubectl create namespace polecenia .

    kubectl create namespace gpu-training
    kubectl create namespace gpu-inference
    
  2. Oznacz pody obciążeń GPU według typu, jak pokazano w poniższym przykładzie:

    metadata:
      namespace: gpu-training
      labels:
        workload: training
    
  3. Zastosuj zasady sieciowe, aby odizolować ruch między typami obciążeń. Poniższy manifest blokuje cały ruch przychodzący i wychodzący dla przestrzeni nazw gpu-training (chyba że zostanie to jawnie dozwolone):

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: deny-cross-namespace
      namespace: gpu-training
    spec:
      podSelector: {}
      policyTypes:
      - Ingress
      - Egress
      ingress: []
      egress: []
    

Te zasady:

  • Dotyczy wszystkich zasobników w przestrzeni nazw gpu-training.
  • Domyślnie odrzuca cały ruch przychodzący i wychodzący, zapewniając silną izolację.

Ten model zwiększa przejrzystość, kontrolę i bezpieczeństwo w udostępnionych środowiskach gpu, zwłaszcza gdy typy obciążeń mają różne profile środowiska uruchomieniowego, poziomy ryzyka lub wymagania operacyjne.

Optymalizować wykorzystanie zasobów na węzłach GPU za pomocą technologii Multi-Instance GPU (MIG)

Różne obciążenia procesora GPU mają różne wymagania dotyczące pamięci. Mniejsze wdrożenia, takie jak NVIDIA A100 40 GB, mogą nie potrzebować całego procesora GPU. Jednak pojedyncze obciążenie domyślnie monopolizuje zasób procesora GPU nawet w przypadku niedostatecznego wykorzystania.

Usługa AKS obsługuje optymalizację zasobów węzłów GPU przez dzielenie ich na mniejsze partycje za pomocą technologii wieloinstancyjnego GPU (MIG), dzięki czemu zespoły mogą wydajniej harmonogramować mniejsze zadania. Dowiedz się więcej o obsługiwanych rozmiarach GPU i o tym, jak rozpocząć pracę z wieloinstancyjnymi procesorami GPU w usłudze AKS.

Używanie efemerycznych dysków danych NVMe jako pamięci podręcznej o wysokiej wydajności

W przypadku obciążeń sztucznej inteligencji działających na maszynach wirtualnych z procesorem GPU w usłudze AKS szybki i niezawodny dostęp do magazynu tymczasowego ma kluczowe znaczenie dla maksymalizacji wydajności trenowania i wnioskowania. Efemeryczne dyski danych NVMe zapewniają bezpośrednio do hosta maszyny wirtualnej dołączoną pamięć masową o wysokiej przepustowości i małych opóźnieniach, co znakomicie nadaje się do scenariuszy takich jak buforowanie zestawów danych, przechowywanie pośrednich punktów kontrolnych oraz wag modeli lub zapewnianie tymczasowego miejsca na potrzeby wstępnego przetwarzania danych i analityki.

Podczas wdrażania pul węzłów z GPU dla obciążeń związanych ze sztuczną inteligencją, skonfiguruj efemeryczne dyski danych NVMe, aby służyły jako pamięć podręczna o wysokiej wydajności lub miejsce tymczasowe. Takie podejście pomaga wyeliminować wąskie gardła we/wy, przyspiesza operacje intensywnie korzystające z danych i zapewnia, że zasoby GPU nie są bezczynne podczas oczekiwania na dane.

Azure obsługuje efemeryczne dyski danych NVMe w wielu rodzinach maszyn wirtualnych Azure GPU. W zależności od rozmiaru maszyny wirtualnej z procesorem GPU maszyna wirtualna ma do ośmiu nietrwałych dysków danych NVMe o łącznej pojemności do 28 TiB. Aby uzyskać szczegółowe informacje na temat rozmiarów maszyn wirtualnych, zapoznaj się z dokumentacją serii ND H100 v5 lub dokumentacją rozmiaru maszyny wirtualnej dla wybranej rodziny procesorów GPU.

Aby uprościć aprowizowanie i zarządzanie, użyj usługi Azure Container Storage, która umożliwia automatyczne wykrywanie i organizowanie efemerycznych dysków NVMe dla obciążeń kubernetes.

Zalecane scenariusze obejmują:

  • Buforowanie dużych zestawów danych i punktów kontrolnych modelu na potrzeby trenowania i wnioskowania sztucznej inteligencji.
  • Buforowanie wag modelu w kontekście wnioskowania przez sztuczną inteligencję. Na przykład model KAITO jako artefakt OCI na lokalnym NVMe.
  • Zapewnianie szybkiej przestrzeni tymczasowej dla zadań wsadowych i potoków danych.

Ważne

Dane na efemerycznych dyskach NVMe są tymczasowe i zostaną utracone w przypadku cofnięcia przydziału lub ponownego wdrożenia maszyny wirtualnej. Te dyski są używane tylko w przypadku danych niekrytycznych, przejściowych i przechowywania ważnych informacji na temat trwałych rozwiązań usługi Azure Storage.

Aby uzyskać więcej wskazówek dotyczących efemerycznych dysków danych NVMe, zobacz Najlepsze rozwiązania dotyczące efemerycznych dysków danych NVMe w usłudze AKS.

Aby dowiedzieć się więcej na temat obciążeń usługi AKS i procesora GPU, zobacz następujące artykuły: