AWS lansează SageMaker HyperPod Inference Gateway pentru rutare conștientă de GPU

Amazon Web Services a anunțat Amazon SageMaker HyperPod Inference Gateway pe 18 septembrie 2026, un sistem de rutare nativ Kubernetes, conștient de GPU, pentru inferență de modele lingvistice mari, care se implementează ca un singur supliment gestionat pentru Amazon EKS pe infrastructura HyperPod existentă. AWS a declarat că gateway‑ul poate reduce latența primului token cu până la 82%.

Problema de rutare din spatele gateway‑ului

Conform AWS, algoritmii de echilibrare a încărcării impliciți în Kubernetes, cum ar fi round‑robin și least‑connections, nu au vizibilitate asupra stării GPU: care poduri au cache‑urile KV saturate, care sunt la jumătatea generațiilor cu context lung și care au deja adaptorul LoRA necesar încărcat în memorie. Compania a afirmat că cererile se acumulează în spatele podurilor ocupate, în timp ce capacitatea inactivă rămâne neutilizată, latența primului token crește peste patru secunde în timpul vârfurilor de trafic, utilizarea devine inegală și imprevizibilă, iar operatorii supra‑dimensionează pentru a compensa. AWS a descris un scenariu în care un utilizator de chatbot, așteptând 4,4 secunde pentru primul token, îl primește în sub 800 de milisecunde.

Arhitectură în două niveluri

Gateway‑ul folosește un design în două niveluri construit pe primitive native Kubernetes. AWS a declarat că utilizează semnale GPU în timp real pentru a aloca fiecare cerere de inferență podului cel mai potrivit. Nivelul 1 se instalează direct pe fiecare HyperPod sau cluster EKS ca suplimentul amazon-sagemaker-hyperpod-inference și este compus din trei componente, toate bazate pe extensia open‑source Gateway API Inference. Envoy Gateway, un proxy de nivel‑7, termină traficul HTTPS de intrare și expune un singur punct final privat pentru fiecare cluster. Routerul bazat pe corp inspectează corpul fiecărei cereri compatibile OpenAI, extrage câmpul model și direcționează cererea către grupul de modele corect, astfel încât un singur gateway să poată servi mai multe modele.

Selectorul de endpoint-uri consumă metrici Prometheus în timp real de la fiecare pod care servește modele și aplică un algoritm de scorare ponderată pe baza evaluatorilor care acoperă utilizarea cache‑ului KV, adâncimea cozii, rezidența adaptorului LoRA, rata de hit a cache‑ului de prefix și cererile în curs. Fiecare evaluator are o greutate configurabilă, permițând ajustarea comportamentului de rutare pentru o sarcină specifică, cum ar fi chatul sensibil la latență versus loturile optimizate pentru debit.

Nivelul 2, Routerul Global de Inferență, este anunțat ca urmează să fie disponibil. AWS a declarat că va adăuga coordonare la nivel de flotă între mai multe clustere și regiuni, cu failover între clustere, limitare globală a ratei și modelare a traficului în funcție de costuri. Nivelul 2 se construiește peste Nivelul 1, în timp ce gateway‑ul fiecărui cluster continuă să gestioneze rutarea locală.

Implementare, gestionarea erorilor și observabilitate

Implementarea constă într-o singură comandă aws eks create-addon și o resursă personalizată declarativă InferenceGatewayConfig care definește modelele și comportamentul de rutare, cu implementările existente ale serverelor de modele descoperite prin etichetele podurilor. AWS a afirmat că instalarea nu necesită sidecar‑uri, nici mesh de servicii și nici modificări ale codului aplicației. Gateway‑ul expune un punct final standard compatibil OpenAI prin HTTP; conform AWS, codul client existent funcționează neschimbat, fără modificări ale SDK‑ului și fără semnare SigV4 pentru traficul de inferență.

Pentru sarcini de lucru care servesc adaptoare LoRA ajustate fin pe un model de bază partajat, evaluatorul de afinitate LoRA al Selectorului de endpoint-uri direcționează cererile de adaptor către podurile care au deja adaptorul solicitat rezident în memorie GPU; dacă niciun pod nu îl are încărcat, cererea este trimisă către podul cu cea mai mare capacitate disponibilă. AWS a declarat că aceasta elimină latența schimbului de adaptoare.

Comportamente de eșec documentate acoperă eșecul podului, epuizarea pool‑ului, eșecul clusterului și eșecul regional. În cazul eșecului unui pod, Selectorul de endpoint-uri exclude podurile cu metrici învechite și direcționează către poduri sănătoase, recuperând automat când metricile reîncep. În cazul epuizării pool‑ului, gateway‑ul returnează HTTP 429 cu un antet Retry-After în timp ce auto‑scalarea adaugă capacitate. În cazul eșecului clusterului, Routerul Global de Inferență detectează un semnal de viață învechit și redirecționează traficul în decurs de 35 de secunde, cu creștere treptată când clusterul este reintrodus. În cazul eșecului regional, rutarea inter‑regională se activează automat, ceea ce AWS a precizat că implică o latență mai mare, dar fără impact asupra disponibilității.

Gateway‑ul emite metrici la nivelurile pod, pool, cluster și flotă: utilizarea cache‑ului KV, adâncimea cozii, cererile în curs și rezidența adaptorului prin Prometheus la nivelul podului; totalurile de cereri, histogramă de durată și numărul de tokeni prin Prometheus și Grafana la nivelul pool‑ului; media cache‑ului KV, rata de eroare și latența P99 prin Amazon CloudWatch la nivelul clusterului; și deciziile de rutare, evenimentele de failover și numărul de limitări de rată prin CloudWatch la nivelul flotei.

Rezultatele benchmark-ului raportate de AWS

AWS a declarat că a testat patru modele cu parametri între 8 miliarde și 235 miliarde pe instanțe p5.48xlarge cu GPU‑uri H100 și instanțe g5 cu GPU‑uri A10G. Tot traficul a fost rutat prin Load Balancere de aplicație interne, replicând calea parcursă de o cerere de producție, cu un grup dedicat de noduri client care generează sarcină controlată și servere de modele izolate pe un grup separat de noduri server. Fiecare rezultat folosește configurația implicită de rutare a gateway‑ului fără ajustări și este comparat cu un punct de referință round‑robin Kubernetes pe aceleași replici de model, conform AWS.

În rezultatele raportate, o flotă GPU mixtă pe generații a redus timpul până la primul token (latency) P95 și P99 cu 97 % fiecare pentru Llama-3.1-8B, cu o creștere a debitului de 8 %, și cu 98 % și 97 % pentru Qwen3-32B, cu o creștere a debitului de 50 %. În condiții de trafic exploziv, Llama-3.1-70B a înregistrat reduceri P95 și P99 de 94 % și 98 % cu un debit cu 12 % mai mare, în timp ce Qwen3-235B a prezentat o latență P95 comparabilă și o reducere P99 cu 89 %. Cu prefixe de prompt partajate, latența P95 și P99 a Llama-3.1-8B a scăzut cu 26 % și respectiv 43 %.

AWS a declarat că, pe o flotă complet uniformă în condiții de trafic constant, gateway‑ul are performanțe comparabile cu round‑robin, iar rezultatele considerate comparabile sunt cele cu diferențe în interiorul variației între rulări. Compania a precizat că îmbunătățirile sunt cele mai mari acolo unde round‑robin întâmpină cele mai mari dificultăți: hardware mixt, cerere explozivă și prefixe de prompt partajate.

Disponibilitate și plan de dezvoltare

AWS descrie gateway‑ul ca fiind conform cu Kubernetes Gateway API și extensia sa de inferență, configurat printr-o singură definiție de resursă personalizată și compatibil cu orice server de modele compatibil cu OpenAI, inclusiv vLLM, SGLang și TGI. Administrarea se realizează prin kubectl, GitOps, Helm și ArgoCD, iar instalarea, actualizările și revenirea la versiuni anterioare sunt gestionate prin ciclul de viață al add‑on‑ului EKS.

Rutarea de nivel 1 pe cluster este disponibilă începând cu 18 septembrie 2026, în regiunile în care add‑on‑ul de inferență este disponibil. Dincolo de Global Inference Router, elementele de plan de dezvoltare enumerate de AWS includ împărțirea traficului canary, care va direcționa un procent din trafic către noi versiuni de modele utilizând resurse personalizate InferenceModelRewrite, și controlul fluxului care clasifică cererile ca Critice, Standard sau Eliminabile, cu control de admitere pe fiecare bandă.