AWS dodaje partycjonowanie procesorów graficznych NVIDIA do punktów końcowych wnioskowania SageMaker

Amazon Web Services (AWS) ogłosiło obsługę technologii NVIDIA Multi-Instance GPU w Amazon SageMaker Inference 6 listopada 2026 r., umożliwiając współdzielenie jednego akceleratora przez wiele modeli odizolowanych sprzętowo w punktach końcowych czasu rzeczywistego, zamiast przydzielania całego procesora graficznego każdemu wdrożeniu.

Funkcja ta rozwiązuje dwa problemy związane z przydzielaniem całego procesora graficznego. Liczba akceleratorów ogranicza liczbę modeli, które może obsługiwać instancja, niezależnie od tego, jak mało pamięci lub mocy obliczeniowej wykorzystuje każdy model, a klienci rozważający nowszy procesor graficzny muszą przydzielić całe urządzenie. Technologia Multi-Instance GPU (MIG) zapewnia natomiast każdej partycji stały udział jednostek obliczeniowych i wydzielony blok pamięci, a izolację wymusza sprzętowo. Ponieważ każdy model pozostaje załadowany, takie rozwiązanie pozwala również uniknąć opóźnienia, które występuje, gdy punkt końcowy obsługujący wiele modeli ładuje model do współdzielonego urządzenia przy pierwszym użyciu.

Partycjonowanie jest dostępne wyłącznie w punktach końcowych czasu rzeczywistego korzystających z komponentów wnioskowania — mechanizmu SageMaker służącego do wdrażania kilku modeli w jednym punkcie końcowym i określania przydzielanej im mocy obliczeniowej. Nie można partycjonować punktów końcowych z jednym modelem, punktów końcowych bezserwerowych ani heterogenicznych pul instancji. Funkcja ta nie obejmuje również zadań asynchronicznych, ponieważ wywołanie asynchroniczne nie może wskazywać komponentu wnioskowania.

Salesforce pomogło określić wymagania i zweryfikować wstępną implementację. Richard Chang, architekt oprogramowania w Salesforce, powiedział, że firma spodziewa się, iż MIG pozwoli bezpiecznie konsolidować obciążenia, zwiększyć wykorzystanie procesorów graficznych i obniżyć koszty wnioskowania, a jednocześnie zapewnić przewidywalną wydajność i izolację. Salesforce przygotowuje się do sprawdzenia oprogramowania na reprezentatywnych obciążeniach produkcyjnych, dlatego korzyści te są oczekiwaniami, a nie wynikami odnotowanymi w środowisku produkcyjnym.

Za partycjonowanie odpowiadają dwa pola API

Dokumentacja dla deweloperów SageMaker AI opisuje dwa opcjonalne pola: AcceleratorPartitionLayouts określa podział zasobów w wariancie produkcyjnym, a AcceleratorPartitionType wybiera profil używany przez komponent wnioskowania. Nie wprowadzono nowych operacji API, typów zasobów ani działań AWS Identity and Access Management, a pominięcie obu pól pozwala zachować dotychczasowe działanie punktu końcowego.

Wybrany układ jest stosowany jednakowo do każdego akceleratora we wszystkich instancjach danego wariantu. W przykładzie AWS każdy z ośmiu układów A100 w ml.p4d.24xlarge zostaje podzielony na mig-4g.20gb, mig-2g.10gb oraz mig-1g.5gb partycje, co daje łącznie 24 partycje w punkcie końcowym. Każda kopia komponentu wnioskowania zajmuje jedną żądaną partycję, natomiast InvokeEndpoint nadal umożliwia wskazywanie modeli według nazwy komponentu, bez identyfikatora partycji. AWS podało, że w przeprowadzonych testach podział akceleratorów wydłużył proces udostępniania zasobów o około 17 sekund.

Izolacja obejmuje moc obliczeniową i pamięć procesora graficznego, ale nie cały host. Modele działające na jednej instancji nadal współdzielą procesor hosta, pamięć hosta, pamięć masową, sieć i trasowanie ruchu do punktu końcowego. Komponent, który zażąda profilu nieobecnego w układzie, zostaje odrzucony zamiast otrzymać cały procesor graficzny. Zmiana układu działającego punktu końcowego wymaga utworzenia nowego punktu końcowego i przeniesienia ruchu; przeniesienie komponentu do innego profilu wymaga utworzenia nowego komponentu.

AWS porównuje partycję H100 z całym układem A100

AWS porównało jedną mig-3g.40gb partycję H100 z całym układem A100-40GB, używając modelu Llama-3.1-8B-Instruct w produkcyjnych punktach końcowych SageMaker czasu rzeczywistego. W obu konfiguracjach zastosowano jedną replikę modelu, identyczne kontenery, tokenizery i konfiguracje klienta, a narzędzie genai-bench generowało pięć wzorców ruchu przy poziomach współbieżności od 2 do 512. Przewodnik NVIDIA po profilach podaje, że testowany profil H100 przydziela trzy z siedmiu udziałów procesorów strumieniowych i cztery z ośmiu jednostek pamięci. Obie konfiguracje mają porównywalną pojemność pamięci, ale różnią się przydziałem mocy obliczeniowej.

W testach AWS odnotowało, że przy obciążeniu, przy którym korzyść kosztowa była największa w danym scenariuszu, partycja H100 zapewniała o 53%–89% więcej tokenów wyjściowych na sekundę. Opóźnienie między tokenami było niższe o 8,9%–42,1%, a czas do pierwszego tokenu — o 5,6%–47,5%. Przy najwyższym poziomie współbieżności w zadaniach obejmujących 6000 i 8000 tokenów A100 nie dotrzymał terminu obsługi od jednej trzeciej do połowy żądań, podczas gdy partycja nie zawiodła w przypadku żadnego z nich.

Analiza kosztów AWS, przedstawiona jako porównanie poszczególnych przypadków, a nie uniwersalny werdykt, wykazała, że po przekroczeniu progu rentowności właściwego dla danego obciążenia koszt miliona tokenów wyjściowych był niższy o 18%–34%. Próg ten przypadał przy współbieżności 64 dla promptów o długości 100 tokenów oraz przy współbieżności 4 dla promptów o długości 8000 tokenów. Poniżej tego progu cały układ A100 pozostawał tańszy, dlatego starszy procesor graficzny bez podziału może lepiej sprawdzać się przy krótkich danych wejściowych lub niskiej współbieżności. Porównanie kosztu jednostkowego polegało na podzieleniu cen instancji w modelu płatności na żądanie przez liczbę testowanych jednostek w każdej instancji.

Obsługiwany sprzęt i ograniczenia operacyjne

W chwili premiery funkcja obejmuje cztery rodziny instancji, a liczba partycji i dostępne profile zależą od akceleratora:

Partycjonowanie GPU jest dostępne w regionach US East (Wirginia Północna), US East (Ohio), US West (Oregon), Azja i Pacyfik (Singapur), Azja i Pacyfik (Tokio), Europa (Frankfurt) i Europa (Irlandia), zależnie od dostępności instancji w danym regionie i limitu przydziału punktów końcowych. Żadna partycja nie obejmuje wielu akceleratorów, dlatego modele wymagające całego GPU lub wielu GPU nadal potrzebują pełnych urządzeń.

Klienci nadal płacą za instancję z pełnym GPU; partycjonowanie może zwiększyć dostępną pojemność, ale nie obniża stawki godzinowej. Partycjonowane punkty końcowe i ich komponenty wnioskowania nie publikują również w CloudWatch wskaźników wykorzystania GPU, CPU ani pamięci, choć wskaźniki liczby wywołań i opóźnień pozostają dostępne. W przypadku P4d, mig-1g.10gb profil wymaga sterownika NVIDIA w wersji R525 lub nowszej, a AWS zaleca klientom nowszy obraz AMI do wnioskowania, ponieważ domyślny obraz go nie zawiera.

W kontekście planowania pojemności ta premiera zmienia każdy obsługiwany akcelerator w kilka partycji GPU o stałych rozmiarach, ale wdrożenie o większej gęstości i izolacji sprzętowej wiąże się z rozliczaniem za całą instancję, układami, których nie można zmieniać w miejscu wdrożenia, oraz ograniczonymi danymi telemetrycznymi o wykorzystaniu zasobów. Benchmark AWS pokazuje, jak ważne jest mierzenie rzeczywistego ruchu: w tych testach partycja H100 zapewniała lepszą wydajność i niższe koszty przy większym obciążeniu zadaniami z długim kontekstem, natomiast wyniki dotyczące progu rentowności wskazywały, że przy lżejszych obciążeniach tańsze było użycie całego A100.