AWS wprowadza SageMaker HyperPod Inference Gateway dla routingu świadomego GPU

Amazon Web Services ogłosiło Amazon SageMaker HyperPod Inference Gateway 18 września 2026 r., natywny dla Kubernetes, system routingu świadomego GPU dla inferencji dużych modeli językowych, który wdraża się jako pojedynczy zarządzany dodatek dla Amazon EKS na istniejącej infrastrukturze HyperPod. AWS podało, że brama może skrócić opóźnienie pierwszego tokenu nawet o 82%.

Problem routingu stojący za bramą

Według AWS, domyślne algorytmy równoważenia obciążenia Kubernetes, takie jak round-robin i least-connections, nie mają wglądu w stan GPU: które pod’y mają nasycone pamięci KV, które są w połowie generacji długiego kontekstu oraz które już mają załadowany w pamięci adapter LoRA potrzebny żądaniu. Firma podała, że żądania gromadzą się za zajętymi pod’ami, podczas gdy nieużywana pojemność pozostaje niewykorzystana, opóźnienie pierwszego tokenu gwałtownie rośnie powyżej czterech sekund podczas nagłych skoków ruchu, wykorzystanie staje się nierówne i nieprzewidywalne, a operatorzy nadmiernie przydzielają zasoby, aby to zrekompensować. AWS opisało scenariusz, w którym użytkownik czatu oczekujący 4,4 sekundy na pierwszy token otrzymuje go w mniej niż 800 milisekund.

Architektura dwuwarstwowa

Bramka wykorzystuje dwuwarstwowy projekt oparty na natywnych elementach Kubernetes. AWS podało, że używa sygnałów GPU w czasie rzeczywistym, aby umieścić każde żądanie inferencji na najbardziej odpowiednim podzie. Warstwa 1 instalowana jest bezpośrednio na każdym HyperPod lub klastrze EKS jako dodatek amazon-sagemaker-hyperpod-inference i składa się z trzech komponentów, wszystkie oparte na otwarto‑źródłowym rozszerzeniu Gateway API Inference. Envoy Gateway, proxy warstwy‑7, kończy przychodzący ruch HTTPS i udostępnia pojedynczy prywatny punkt końcowy na klaster. Body-Based Router analizuje każdy przychodzący żądanie zgodne z OpenAI, wyodrębnia pole model i kieruje żądanie do właściwej puli modeli, tak aby jedna bramka mogła obsługiwać wiele modeli.

Endpoint Picker pobiera metryki Prometheus w czasie rzeczywistym z każdego poda serwującego modele i stosuje ważony algorytm punktacji obejmujący oceny dotyczące wykorzystania pamięci KV, głębokości kolejki, obecności adaptera LoRA, wskaźnika trafień pamięci prefiksowej oraz bieżących żądań. Każda ocena posiada konfigurowalną wagę, co pozwala dostosować zachowanie routingu do konkretnego obciążenia, takiego jak czat wrażliwy na opóźnienia versus wsadowe przetwarzanie zoptymalizowane pod kątem przepustowości.

Warstwa 2, Global Inference Router, jest zapowiedziana jako wkrótce dostępna. AWS podało, że doda koordynację całej floty w wielu klastrach i regionach, z przełączaniem awaryjnym między klastrami, globalnym ograniczaniem szybkości oraz kształtowaniem ruchu uwzględniającym koszty. Warstwa 2 opiera się na Warstwie 1, podczas gdy bramka każdego klastra nadal obsługuje lokalny routing.

Wdrożenie, obsługa awarii i obserwowalność

Wdrożenie składa się z jednego polecenia aws eks create-addon oraz jednego deklaratywnego zasobu InferenceGatewayConfig, który definiuje modele i zachowanie routingu, przy czym istniejące wdrożenia serwerów modeli są wykrywane poprzez etykiety podów. AWS podało, że instalacja nie wymaga sidecarów, siatki usług ani zmian w kodzie aplikacji. Bramka udostępnia standardowy punkt końcowy zgodny z OpenAI przez HTTP; według AWS, istniejący kod klienta działa bez zmian, bez modyfikacji SDK i bez podpisywania SigV4 dla ruchu inferencyjnego.

W przypadku obciążeń serwujących dostrojone adaptery LoRA na wspólnym modelu bazowym, LoRA Affinity Scorer w Endpoint Picker kieruje żądania adaptera do podów, które już mają żądany adapter zamieszczony w pamięci GPU; jeśli żaden pod go nie ma załadowanego, żądanie trafia do poda z największą dostępną pojemnością. AWS podało, że eliminuje to opóźnienie wymiany adaptera.

Udokumentowane zachowania w przypadku awarii obejmują awarię poda, wyczerpanie puli, awarię klastra oraz awarię regionu. W przypadku awarii poda, Endpoint Picker wyklucza pod’y ze starymi metrykami i kieruje ruch do zdrowych pod’ów, przywracając się automatycznie po wznowieniu metryk. Przy wyczerpaniu puli bramka zwraca HTTP 429 z nagłówkiem Retry-After, podczas gdy autoskalowanie dodaje pojemność. W przypadku awarii klastra Global Inference Router wykrywa przestarzałe sygnały serca i przekierowuje ruch w ciągu 35 sekund, z stopniowym zwiększaniem po ponownym wprowadzeniu klastra. W przypadku awarii regionu routing międzyregionowy uruchamia się automatycznie, co, według AWS, powoduje wyższe opóźnienie, ale nie wpływa na dostępność.

Bramka generuje metryki na poziomach poda, puli, klastra i floty: wykorzystanie pamięci KV, głębokość kolejki, bieżące żądania i obecność adapterów poprzez Prometheus na poziomie poda; sumy żądań, histogramy czasu trwania i liczbę tokenów poprzez Prometheus i Grafana na poziomie puli; średnią pamięć KV, wskaźnik błędów i opóźnienie P99 poprzez Amazon CloudWatch na poziomie klastra; oraz decyzje routingu, zdarzenia przełączenia awaryjnego i trafienia limitu szybkości poprzez CloudWatch na poziomie floty.

Wyniki benchmarków zgłoszone przez AWS

AWS podało, że przeprowadziło benchmarki czterech modeli o liczbie parametrów od 8 mld do 235 mld na instancjach p5.48xlarge z GPU H100 oraz instancjach g5 z GPU A10G. cały ruch był kierowany przez wewnętrzne Application Load Balancery, odzwierciedlając ścieżkę, jaką pokonuje żądanie produkcyjne, przy dedykowanej grupie węzłów klienta generującej kontrolowane obciążenie oraz serwerach modeli izolowanych w osobnej grupie węzłów serwerowych. Każdy wynik wykorzystuje domyślną konfigurację routingu bramki bez tuningu i jest porównywany z bazą round-robin Kubernetes na tych samych replikach modeli, według AWS.

W zgłoszonych wynikach flota GPU o mieszanej generacji skróciła czas do pierwszego tokenu (latencję P95 i P99) o 97 % dla Llama‑3.1‑8B, przy 8 % wzroście przepustowości, oraz o 98 % i 97 % dla Qwen3‑32B, przy 50 % wzroście przepustowości. Przy ruchu burzliwym Llama‑3.1‑70B odnotowała redukcję P95 i P99 o 94 % i 98 % przy 12 % wyższej przepustowości, natomiast Qwen3‑235B wykazała porównywalną latencję P95 i o 89 % niższą P99. Przy wspólnych prefiksach zapytań latencja P95 i P99 Llama‑3.1‑8B spadła o 26 % i 43 %.

AWS poinformowało, że przy w pełni jednorodnej flocie i stałym ruchu brama działa na równi z algorytmem round‑robin, a wyniki uznaje za porównywalne, jeśli różnice mieszczą się w zmienności pomiędzy kolejnymi uruchomieniami. Firma zaznaczyła, że największe usprawnienia występują tam, gdzie round‑robin ma najwięcej problemów: mieszany sprzęt, burzliwe zapotrzebowanie oraz wspólne prefiksy zapytań.

Dostępność i plan rozwoju

AWS opisuje bramę jako zgodną z Kubernetes Gateway API oraz jego rozszerzeniem Inference, konfigurowaną za pomocą pojedynczej definicji zasobu niestandardowego i kompatybilną z dowolnym serwerem modeli obsługującym OpenAI, w tym vLLM, SGLang i TGI. Zarządzanie odbywa się przy użyciu kubectl, GitOps, Helm i ArgoCD, a instalacja, aktualizacje i przywracanie są obsługiwane w ramach cyklu życia dodatku EKS.

Routing typu Tier 1 na poziomie klastra jest dostępny od 18 września 2026 r. w regionach, w których dostępny jest dodatek inference. Poza Global Inference Router, wymienione w planie rozwoju elementy AWS obejmują podział ruchu typu canary, który będzie kierował określony procent ruchu do nowych wersji modeli przy użyciu niestandardowych zasobów InferenceModelRewrite, oraz kontrolę przepływu, klasyfikującą żądania jako Krytyczne, Standardowe lub Odrzucone, z kontrolą przyjęć w poszczególnych pasmach.