AWS uvádí SageMaker HyperPod Inference Gateway pro GPU‑vědomé směrování

Amazon Web Services oznámila Amazon SageMaker HyperPod Inference Gateway dne 18. září 2026, nativní řešení pro Kubernetes, GPU‑vědomé směrování pro inferenci velkých jazykových modelů, které se nasazuje jako jediný spravovaný doplněk pro Amazon EKS na stávající infrastruktuře HyperPod. AWS uvedla, že brána může snížit latenci prvního tokenu až o 82 %.

Problém se směrováním za bránou

Podle AWS, výchozí algoritmy vyvažování zátěže v Kubernetes, jako je round-robin a least-connections, nemají přehled o stavu GPU: které pody mají nasycené KV cache, které jsou uprostřed dlouhých generací kontextu a které již mají načtený adaptér LoRA požadovaný v paměti. Společnost uvedla, že požadavky se hromadí za vytíženými pody, zatímco nevyužitá kapacita zůstává nevyužitá, latence prvního tokenu stoupá nad čtyři sekundy během špiček provozu, využití se stává nerovnoměrným a nepředvídatelným a provozovatelé nadměrně přidělují kapacitu jako kompenzaci. AWS popsal scénář, ve kterém uživatel chatbotu čeká 4,4 sekundy na první token, místo toho jej vidí za méně než 800 milisekund.

Dvoustupňová architektura

Brána používá dvoustupňový návrh postavený na nativních primitivách Kubernetes. AWS uvedla, že využívá signály GPU v reálném čase k umístění každého požadavku na inferenci na nejvhodnější pod. Úroveň 1 se instaluje přímo na každý HyperPod nebo EKS cluster jako doplněk amazon-sagemaker-hyperpod-inference a sestává ze tří komponent, všechny postavených na open‑source rozšíření Gateway API Inference Extension. Envoy Gateway, proxy úrovně 7, ukončuje příchozí HTTPS provoz a zpřístupňuje jeden soukromý koncový bod na cluster. Body‑Based Router kontroluje každé příchozí požadavky kompatibilní s OpenAI, extrahuje pole model a směruje požadavek do správného modelového fondu, takže jedna brána může obsluhovat více modelů.

Endpoint Picker spotřebovává metriky Prometheus v reálném čase ze všech podů sloužících modelům a aplikuje vážený algoritmus hodnocení napříč hodnotiteli zahrnujícími využití KV cache, hloubku fronty, přítomnost LoRA adaptéru, míru zásahů prefixové cache a běžící požadavky. Každý hodnotitel má konfigurovatelnou váhu, což umožňuje ladit chování směrování pro konkrétní pracovní zátěž, například chat citlivý na latenci oproti dávkám optimalizovaným na propustnost.

Úroveň 2, Global Inference Router, je uvedena jako připravovaná. AWS uvedla, že přidá koordinaci celého fondu napříč více clustery a regiony, s přepínáním mezi clustery, globálním omezením rychlosti a tvarováním provozu s ohledem na náklady. Úroveň 2 staví na Úrovni 1, zatímco brána každého clusteru nadále zajišťuje lokální směrování.

Nasazení, zpracování selhání a sledovatelnost

Nasazení se skládá z jediného příkazu aws eks create-addon a jedné deklarativní vlastní zdroje InferenceGatewayConfig, která definuje modely a chování směrování, přičemž existující nasazení serverů modelů jsou objevena pomocí štítků podů. AWS uvedla, že instalace nevyžaduje žádné sidecar kontejnery, žádnou síť služeb ani změny aplikačního kódu. Brána zpřístupňuje standardní endpoint kompatibilní s OpenAI přes HTTP; podle AWS existující klientský kód funguje beze změny, bez úprav SDK a bez podepisování SigV4 pro inferenční provoz.

Pro pracovní zátěže, které nasazují jemně doladěné LoRA adaptéry na sdíleném základním modelu, LoRA Affinity Scorer v Endpoint Pickeru směruje požadavky na adaptér na pody, které již mají požadovaný adaptér umístěný v GPU paměť; pokud žádný pod není načten, požadavek jde na pod s největší dostupnou kapacitou. AWS uvedla, že tím se eliminuje latence výměny adaptéru.

Dokumentované chování při selhání zahrnuje selhání podu, vyčerpání fondu, selhání clusteru a selhání regionu. Při selhání podu Endpoint Picker vylučuje pody se zastaralými metrikami a směruje požadavky na zdravé pody, automaticky se zotavuje, jakmile metriky obnoví. Při vyčerpání fondu brána vrací HTTP 429 s hlavičkou Retry‑After, zatímco automatické škálování přidává kapacitu. Při selhání clusteru Global Inference Router detekuje zastaralý heartbeat a přesměruje provoz během 35 sekund, s postupným navyšováním, když je cluster znovu zaveden. Při selhání regionu se aktivuje automatické směrování mezi regiony, což AWS uvedla, že přináší vyšší latenci, ale nemá dopad na dostupnost.

Brána odesílá metriky na úrovních podu, fondu, clusteru a celého fondu: využití KV cache, hloubka fronty, běžící požadavky a přítomnost adaptéru prostřednictvím Prometheus na úrovni podu; celkový počet požadavků, histogramy doby trvání a počet tokenů přes Prometheus a Grafana na úrovni fondu; průměrná KV cache, chybová míra a latence P99 přes Amazon CloudWatch na úrovni clusteru; a rozhodnutí o směrování, události přepnutí a zásahy limitu rychlosti přes CloudWatch na úrovni celého fondu.

Výsledky benchmarku hlášené AWS

AWS uvedla, že benchmarkovala čtyři modely s počtem parametrů od 8 B do 235 B na instancích p5.48xlarge s GPU H100 a instancích g5 s GPU A10G. Veškerý provoz byl směrován přes interní Application Load Balancery, což odpovídá cestě, kterou prochází produkční požadavek, s dedikovanou skupinou klientských uzlů generující kontrolované zatížení a servery modelů izolované v samostatné skupině serverových uzlů. Každý výsledek používá výchozí konfiguraci směrování brány bez ladění a je měřen vůči základnímu Kubernetes round‑robin nasazení na stejných replikách modelu, podle AWS.

Ve zveřejněných výsledcích smíšená flotila GPU různých generací snížila latenci time-to-first-token P95 a P99 o 97 % u modelu Llama‑3.1‑8B, s 8 % nárůstem propustnosti, a o 98 % a 97 % u modelu Qwen3‑32B, s 50 % nárůstem propustnosti. Při výkyvné zátěži dosáhl model Llama‑3.1‑70B snížení P95 a P99 o 94 % a 98 % při 12 % vyšší propustnosti, zatímco Qwen3‑235B vykázal srovnatelnou latenci P95 a o 89 % nižší P99. Při sdílených předponách výzvy klesla latence P95 a P99 modelu Llama‑3.1‑8B o 26 % a 43 %.

AWS uvedla, že při plně jednotné flotile za stálé zátěže funguje brána na úrovni round‑robin a definovala srovnatelné výsledky jako rozdíly spadající do rozptylu mezi jednotlivými běhy. Společnost dále uvedla, že největší zlepšení jsou tam, kde round‑robin selhává nejvíce: smíšený hardware, výkyvná poptávka a sdílené předpony výzev.

Dostupnost a plán vývoje

AWS popisuje bránu jako kompatibilní s Kubernetes Gateway API a jeho rozšířením Inference Extension, konfigurovatelnou pomocí jediné vlastní definice zdroje a kompatibilní s libovolným serverem modelů kompatibilním s OpenAI, včetně vLLM, SGLang a TGI. Správa probíhá přes kubectl, GitOps, Helm a ArgoCD, přičemž instalace, aktualizace a návrat k předchozí verzi jsou řešeny prostřednictvím životního cyklu doplňku EKS.

Routing úrovně Tier 1 na úrovni clusteru je k dispozici od 18. září 2026 v regionech, kde je dostupný doplněk inference. Kromě globálního routeru inference zahrnují pojmenované položky v plánu AWS kanárské rozdělení provozu, které bude směrovat procento provozu na nové verze modelů pomocí vlastních zdrojů InferenceModelRewrite, a řízení toku, které klasifikuje požadavky jako Kritické, Standardní nebo Odložitelné s řízením přístupu na úrovni pásma.