AWS Meluncurkan SageMaker HyperPod Inference Gateway untuk Penataan Rute Berbasis GPU

Amazon Web Services mengumumkan Amazon SageMaker HyperPod Inference Gateway pada 18 September 2026, sebuah sistem penataan rute berbasis GPU yang bersifat native Kubernetes untuk inferensi model bahasa besar yang dipasang sebagai satu add-on terkelola untuk Amazon EKS pada infrastruktur HyperPod yang ada. AWS menyatakan bahwa gateway ini dapat mengurangi latensi token pertama hingga 82%.

Masalah Penataan Rute di Balik Gateway

Menurut AWS, algoritma penyeimbangan beban default Kubernetes seperti round-robin dan least-connections tidak memiliki visibilitas terhadap status GPU: pod mana yang telah jenuh pada cache KV, mana yang berada di tengah proses generasi konteks panjang, dan mana yang sudah memuat adaptor LoRA yang dibutuhkan permintaan di memori. Perusahaan menyatakan bahwa permintaan menumpuk di belakang pod yang sibuk sementara kapasitas menganggur tidak terpakai, latensi token pertama melonjak di atas empat detik saat lonjakan lalu lintas, pemanfaatan menjadi tidak merata dan tidak dapat diprediksi, serta operator melakukan over-provision untuk mengimbanginya. AWS menggambarkan sebuah skenario di mana pengguna chatbot yang menunggu 4,4 detik untuk token pertama justru melihatnya dalam kurang dari 800 milidetik.

Arsitektur Dua Tingkat

Gateway ini menggunakan desain dua tingkat yang dibangun di atas primitif native Kubernetes. AWS menyatakan bahwa ia memanfaatkan sinyal GPU waktu nyata untuk menempatkan setiap permintaan inferensi pada pod yang paling cocok. Tingkat 1 dipasang langsung pada setiap HyperPod atau klaster EKS sebagai add-on amazon-sagemaker-hyperpod-inference dan terdiri dari tiga komponen, semuanya dibangun di atas ekstensi open-source Gateway API Inference Extension. Envoy Gateway, sebuah proxy lapisan-7, menghentikan lalu lintas HTTPS yang masuk dan mengekspos satu endpoint pribadi per klaster. Body-Based Router memeriksa setiap badan permintaan yang kompatibel dengan OpenAI, mengekstrak bidang model, dan mengarahkan permintaan ke kumpulan model yang tepat, sehingga satu gateway dapat melayani banyak model.

Endpoint Picker mengonsumsi metrik Prometheus waktu nyata dari setiap pod yang melayani model dan menerapkan algoritma penilaian berbobot di antara penilai yang mencakup pemanfaatan cache KV, kedalaman antrean, keberadaan adaptor LoRA, tingkat hit cache prefiks, dan permintaan yang sedang berjalan. Setiap penilai memiliki bobot yang dapat dikonfigurasi, memungkinkan perilaku penataan rute disesuaikan untuk beban kerja tertentu, seperti obrolan sensitif latensi versus batch yang dioptimalkan untuk throughput.

Tingkat 2, Global Inference Router, tercantum akan segera hadir. AWS menyatakan bahwa ia akan menambahkan koordinasi lintas armada pada banyak klaster dan wilayah, dengan failover lintas klaster, pembatasan laju global, dan penyesuaian lalu lintas yang memperhatikan biaya. Tingkat 2 dibangun di atas Tingkat 1, sementara gateway per-klaster masing-masing tetap menangani penataan rute lokal.

Penyebaran, Penanganan Kegagalan, dan Observabilitas

Penyebaran terdiri dari satu perintah aws eks create-addon dan satu sumber daya khusus InferenceGatewayConfig deklaratif yang mendefinisikan model dan perilaku penataan rute, dengan penyebaran server model yang ada ditemukan melalui label pod. AWS menyatakan bahwa instalasi tidak memerlukan sidecar, service mesh, maupun perubahan kode aplikasi. Gateway ini mengekspos endpoint standar yang kompatibel dengan OpenAI melalui HTTP; menurut AWS, kode klien yang ada berfungsi tanpa perubahan, tanpa perubahan SDK dan tanpa penandatanganan SigV4 untuk lalu lintas inferensi.

Untuk beban kerja yang menyajikan adaptor LoRA yang telah disesuaikan pada model dasar bersama, LoRA Affinity Scorer milik Endpoint Picker mengarahkan permintaan adaptor ke pod yang sudah memiliki adaptor yang diminta berada dalam memori GPU; jika tidak ada pod yang memuatnya, permintaan akan diarahkan ke pod dengan kapasitas tersedia terbanyak. AWS menyatakan bahwa hal ini menghilangkan latensi pertukaran adaptor.

Perilaku kegagalan yang didokumentasikan mencakup kegagalan pod, kehabisan pool, kegagalan klaster, dan kegagalan regional. Pada kegagalan pod, Endpoint Picker mengecualikan pod dengan metrik usang dan mengarahkan ke pod yang sehat, pulih secara otomatis ketika metrik kembali. Pada kehabisan pool, gateway mengembalikan HTTP 429 dengan header Retry-After sementara autoscaling menambah kapasitas. Pada kegagalan klaster, Global Inference Router mendeteksi detak jantung yang usang dan mengalihkan lalu lintas dalam 35 detik, dengan peningkatan bertahap ketika klaster kembali diperkenalkan. Pada kegagalan regional, penataan rute lintas wilayah diaktifkan secara otomatis, yang menurut AWS menimbulkan latensi lebih tinggi namun tidak memengaruhi ketersediaan.

Gateway ini menghasilkan metrik pada tingkat pod, pool, klaster, dan armada: pemanfaatan cache KV, kedalaman antrean, permintaan yang berjalan, dan keberadaan adaptor melalui Prometheus pada tingkat pod; total permintaan, histogram durasi, dan hitungan token melalui Prometheus dan Grafana pada tingkat pool; rata-rata cache KV, tingkat kesalahan, dan latensi P99 melalui Amazon CloudWatch pada tingkat klaster; serta keputusan penataan rute, peristiwa failover, dan hit pembatas laju melalui CloudWatch pada tingkat armada.

Hasil Benchmark yang Dilaporkan AWS

AWS menyatakan bahwa mereka melakukan benchmark pada empat model dengan parameter antara 8B hingga 235B pada instance p5.48xlarge dengan GPU H100 dan instance g5 dengan GPU A10G. Semua lalu lintas diarahkan melalui Application Load Balancer internal, menyesuaikan jalur yang ditempuh permintaan produksi, dengan grup node klien khusus yang menghasilkan beban terkontrol dan server model yang terisolasi pada grup node server terpisah. Setiap hasil menggunakan konfigurasi penataan rute default gateway tanpa penyetelan dan diukur dibandingkan dengan baseline round-robin Kubernetes pada replika model yang sama, menurut AWS.

Dalam hasil yang dilaporkan, armada GPU generasi campuran memotong latency time-to-first-token P95 dan P99 sebesar 97% masing‑masing untuk Llama-3.1-8B, dengan peningkatan throughput sebesar 8%, dan sebesar 98% dan 97% untuk Qwen3-32B, dengan peningkatan throughput sebesar 50%. Pada trafik berlonjakan, Llama-3.1-70B mencatat penurunan P95 dan P99 masing‑masing sebesar 94% dan 98% dengan throughput 12% lebih tinggi, sementara Qwen3-235B menunjukkan latency P95 yang sebanding dan P99 yang lebih rendah sebesar 89%. Dengan prefiks prompt bersama, latency P95 dan P99 Llama-3.1-8B turun masing‑masing 26% dan 43%.

AWS menyatakan bahwa pada armada yang sepenuhnya seragam dengan trafik stabil, gateway beroperasi sebanding dengan round-robin, dan mereka mendefinisikan hasil yang sebanding sebagai perbedaan dalam variansi antar‑run. Perusahaan menyebutkan bahwa peningkatan paling signifikan terjadi pada kondisi di mana round-robin paling kesulitan: perangkat keras campuran, permintaan berlonjakan, dan prefiks prompt bersama.

Ketersediaan dan Peta Jalan

AWS menggambarkan gateway ini sebagai sesuai dengan Kubernetes Gateway API dan Inference Extension‑nya, dikonfigurasi melalui satu definisi sumber daya khusus, serta kompatibel dengan server model apa pun yang mendukung OpenAI, termasuk vLLM, SGLang, dan TGI. Manajemen dilakukan melalui kubectl, GitOps, Helm, dan ArgoCD, dengan instalasi, pembaruan, dan pemulihan ditangani melalui siklus hidup add‑on EKS.

Routing per‑cluster Tingkat 1 tersedia mulai 18 September 2026, di wilayah di mana add‑on inference tersedia. Di luar Global Inference Router, item peta jalan bernama AWS mencakup pembagian trafik canary, yang akan mengarahkan persentase trafik ke versi model baru menggunakan sumber daya khusus InferenceModelRewrite, serta kontrol aliran yang mengklasifikasikan permintaan sebagai Critical, Standard, atau Sheddable dengan kontrol admisi per‑band.