Amazon ogłosił obsługę partycjonowania GPU w SageMaker Inference za pomocą technologii NVIDIA Multi-Instance GPU, czyli MIG. Jedno fizyczne GPU można podzielić na sprzętowo izolowane partycje, z których każda otrzymuje stały udział zasobów obliczeniowych oraz wydzielony blok pamięci. Zależnie od GPU technologia MIG może utworzyć do siedmiu instancji. Każda ma własne zasoby obliczeniowe, pamięć podręczną, pamięć i przepustowość pamięci.

Dla modelu można więc wybrać obsługiwany profil partycji zamiast automatycznie przydzielać całe urządzenie. Po wskazaniu profili SageMaker AI zajmuje się konfiguracją GPU, rozmieszczeniem modeli i skalowaniem. Izolacji sprzętowej partycji MIG nie należy jednak utożsamiać z pełną granicą między dzierżawcami: modele na jednej instancji nadal współdzielą procesor hosta, pamięć systemową, zasoby dyskowe, sieć i trasowanie endpointu.

Zakres obsługiwanych wdrożeń

Partycjonowanie GPU działa na endpointach czasu rzeczywistego używających komponentów inferencyjnych. Nie jest obsługiwane przez endpointy jednego modelu, endpointy serverless, heterogeniczne pule instancji ani obciążenia asynchroniczne. Przed uwzględnieniem partycjonowania w istniejącym wdrożeniu trzeba zatem sprawdzić zarówno typ endpointu, jak i akcelerator.

Partycja nie może obejmować kilku akceleratorów. Modele wymagające całego akceleratora lub wielu GPU muszą nadal korzystać z pełnych urządzeń. Wybrany profil musi być oferowany przez wskazane GPU, a łączna liczba jednostek obliczeniowych i pamięci w układzie nie może przekroczyć pojemności jednego urządzenia. Nieprawidłowy układ zostanie odrzucony, zamiast zostać automatycznie zastąpiony całym akceleratorem.

Dwa opcjonalne pola API

Funkcja dodaje dwa opcjonalne pola. AcceleratorPartitionLayouts w wariancie produkcyjnym deklaruje układ akceleratora. AcceleratorPartitionType w komponencie inferencyjnym wybiera typ partycji dla modelu. Partycjonowanie nie wprowadza nowych operacji API, typów zasobów ani akcji IAM. Pominięcie obu pól zachowuje dotychczasowe działanie endpointu, a sposób wywoływania modelu pozostaje bez zmian.

Układ partycji jest wybierany podczas tworzenia endpointu. Zmiana profilu partycji komponentu inferencyjnego wymaga utworzenia nowego komponentu. Zmiana podziału GPU dla endpointu wymaga nowego endpointu i migracji ruchu. Układ jest więc decyzją związaną z cyklem życia wdrożenia, a nie ustawieniem, które można dowolnie przełączać w istniejącym obiekcie.

Wyniki benchmarku podane przez Amazon

Amazon opisał benchmark modelu Llama-3.1-8B-Instruct. W tym pomiarze jedna partycja H100 mig-3g.40gb generowała więcej tokenów wyjściowych na sekundę oraz osiągała niższe opóźnienie między tokenami i krótszy czas do pierwszego tokenu niż całe A100-40GB. Przewagę odnotowano dla wszystkich kształtów ruchu i poziomów współbieżności objętych testem.

W tym samym benchmarku, powyżej punktów przecięcia zależnych od obciążenia, partycja H100 była według opublikowanych wyników o 18–34 procent tańsza w przeliczeniu na milion tokenów wyjściowych. Poniżej tych punktów tańsze było całe A100. Wyniki dotyczą wyłącznie badanego modelu, endpointów, konfiguracji, kształtów ruchu, poziomów współbieżności, cen i Regionu. Inne obciążenia wymagają osobnego pomiaru.

Dostępność i rozliczenia

Partycjonowanie GPU jest dostępne dla rodzin instancji P4d, P5, G7 i G7e w regionach US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), Europe (Frankfurt) oraz Europe (Ireland). Dostępność instancji różni się między Regionami, a lista nie dowodzi, że każdy obsługiwany typ instancji jest oferowany w każdym wymienionym Regionie.

Klienci nadal płacą za całą instancję GPU według jej istniejącej stawki godzinowej. Partycje nie są rozliczane niezależnie, a sam podział nie zmienia godzinowej ceny instancji. Rezultat ekonomiczny zależy więc od ilości użytecznej pracy uzyskanej z opłaconej instancji oraz od charakterystyki konkretnego obciążenia, a nie od osobnej ceny pojedynczej partycji.

Plan wdrożenia powinien zatem uwzględniać obsługiwany endpoint czasu rzeczywistego, profil oferowany przez wybrane GPU i układ mieszczący się w granicach jednego urządzenia. Konieczność tworzenia nowych komponentów albo nowego endpointu przy zmianach profilu i podziału oznacza również, że konfigurację należy zweryfikować przed migracją ruchu. W tych granicach MIG umożliwia dobranie mniejszej części GPU bez zmiany ustalonego sposobu wywoływania modeli.