Amazon HyperPod Inference Gateway: Cara Pakai Routing LLM di EKS

Serve model bahasa besar di GPU cluster itu mahal. Yang sering bikin boros bukan cuma ukuran model — tapi routing bodoh. Load balancer Kubernetes biasa (round-robin / least-connections) tidak tahu KV cache hampir penuh, antrian dalam, atau adapter LoRA mana yang sudah ada di memori.

Amazon SageMaker HyperPod Inference Gateway masuk di situ. AWS mengumumkannya lewat blog Machine Learning 18 September 2026, lalu What’s New 24 September 2026. Intinya: addon EKS yang route request LLM berdasarkan sinyal GPU real-time, tanpa ubah kode client. Klaim kasar: first-token latency bisa turun sampai 82%, P99 TTFT di skenario berat 97–98% lebih rendah dibanding round-robin.

Artikel ini bedah apa itu HyperPod Inference Gateway, arsitektur tiga komponen, cara pasang dalam hitungan menit, angka benchmark, plus catatan buat tim yang jalanin LLM dari Indonesia — biar teman-teman tidak over-promise ke bos sebelum cek prasyarat cluster.

Apa itu HyperPod Inference Gateway

HyperPod Inference Gateway adalah lapisan routing LLM-aware di depan pod model di cluster SageMaker HyperPod yang jalan di Amazon EKS. Bukan mengganti Inference Operator — gateway duduk di depan pod yang sudah di-orchestrate operator.

Alur singkat tiap request:

1. Envoy Gateway — terima HTTPS, satu private endpoint per cluster.
2. Body-Based Router (BBR) — baca field model di body OpenAI-compatible, resolve nama LoRA ke base model, set header internal.
3. Endpoint Picker (EPP / scheduler) — skor pod kandidat dari metrik model server, lalu pilih pod terbaik.

Yang dihitung EPP (versi blog AWS):

• KV cache utilization — hindari pod yang memori key-value hampir penuh
• Queue depth — hindari antrian dalam
• LoRA adapter residency — prefer pod yang sudah load adapter yang diminta
• Prefix cache hit rate — prefer pod yang mungkin hit cache prompt bersama
• Predicted latency dan running requests — seimbangkan beban aktif

Hasil praktis: satu URL gateway bisa layani banyak model. Client tetap kirim schema OpenAI (/v1/chat/completions). Tidak perlu Sidecar mesh sendiri, tidak perlu rewrite SDK.

Peringatan: Endpoint gateway default tanpa auth request-level. Kalau spec.auth.jwt tidak di-set, siapa saja yang menjangkau endpoint (lewat VPC) bisa kirim traffic. AWS sangat menyarankan JWT di setiap gateway.

Kenapa round-robin bikin GPU boros

Di trafik LLM, pod tidak “sama sibuk”-nya. Satu pod bisa sedang generate konteks panjang, KV cache penuh, sementara tetangga idle. Round-robin tetap kirim request ke pod penuh → first token melonjak (AWS contohkan 4+ detik di burst), GPU terasa “penuh” padahal sebagian idle.

Tiga skenario yang paling sering kena:

1. GPU campuran — H100 dan A10G di fleet yang sama; round-robin tidak peduli kapasitas memori.
2. Traffic bursty — chat peak jam kerja; satu replica naik-turun overload.
3. Shared prompt prefix — multi-turn chat atau dokumen Q&A yang reuse prefix; tanpa affinity, cache prefix sia-sia.

HyperPod Inference Gateway menjawab dengan skor real-time dari Prometheus metrics tiap pod. Di fleet seragam + trafik rata, AWS bilang performanya setara round-robin — artinya nilai terbesar muncul saat kondisi produksi yang “kotor”: hardware campur, burst, dan prefix bersama.

Cara pasang: addon EKS + InferenceGatewayConfig

Gateway datang lewat addon amazon-sagemaker-hyperpod-inference, mulai versi v2.0.0-eksbuild.2 (docs juga menyebut jalur v2.0.0-eksbuild.1 di contoh blog). Kalau cluster tidak kenal CRD InferenceGatewayConfig, versi addon-nya terlalu lama — update dulu.

Prasyarat yang sering dilupakan

1. Cluster SageMaker HyperPod di EKS sudah jalan; model pod sudah di-deploy (Inference Operator).
2. Model server: vLLM ≥ v0.9.2 atau SGLang ≥ v0.3.5.post1 (versi lama: metrik KV cache beda nama / flag --enable-metrics gagal).
3. cert-manager di cluster kalau pakai TLS auto-issue.
4. AWS Load Balancer Controller untuk endpoint tipe ALB.
5. Namespace kerja gateway: hyperpod-inference-system.
6. Role IRSA buat import sertifikat ke ACM kalau auto-issue TLS (buat sebelum install addon).

Install addon (contoh blog)

aws eks create-addon \
  --cluster-name my-hyperpod-cluster \
  --addon-name amazon-sagemaker-hyperpod-inference \
  --addon-version v2.0.0-eksbuild.1 \
  --configuration-values '{"inferenceGateway": {"enabled": true}, "inferenceOperator": {"enabled": true}}'

Label pod model

Gateway menemukan pod lewat label selector. Contoh:

spec:
  template:
    metadata:
      labels:
        app: vllm-llama

Cek label di cluster:

kubectl get pods -n NAMESPACE --show-labels

Apply InferenceGatewayConfig

Satu CRD mendefinisikan BBR, TLS, auth, dan scheduler per model:

apiVersion: inference.sagemaker.aws.amazon.com/v1alpha1
kind: InferenceGatewayConfig
metadata:
  name: my-gateway
spec:
  tls: {}
  bbr:
    enabled: true
  schedulers:
    - name: llama-70b
      modelName: "llama-3.1-70b"
      modelSelector:
        matchLabels:
          app: vllm-llama
      targetPort: 8000
      scheduler: llm-d

Untuk model yang di-manage lewat InferenceEndpointConfig, nyalakan routing gateway lewat field spec.inferenceGateway.enabled.

Kirim request (OpenAI-compatible)

curl -X POST "http://<gateway-endpoint>/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-70b",
    "messages": [{"role": "user", "content": "What is Kubernetes?"}],
    "max_tokens": 100
  }'

Tidak perlu ubah SDK. Tidak perlu SigV4 khusus untuk traffic inference di jalur ini — HTTP biasa + schema OpenAI. Multi-model: BBR baca field model, arahkan ke pool yang benar. Satu gateway, banyak model.

Baca juga Gemini Live Guided Vision: Cara Pakai di Android

flowchart LR
  Client[Client OpenAI SDK] --> Envoy[Envoy Gateway]
  Envoy --> BBR[Body-Based Router]
  BBR --> EPP[Endpoint Picker]
  EPP --> P1[Pod vLLM A]
  EPP --> P2[Pod vLLM B]
  EPP --> P3[Pod SGLang C]

Angka benchmark: TTFT dan throughput

AWS menguji empat model (8B sampai 235B) di instance p5.48xlarge (H100) dan g5 (A10G), traffic lewat ALB internal, client dan server di node group terpisah. Konfigurasi routing gateway: default, tanpa tuning. Baseline: round-robin Kubernetes di replica yang sama.

Ringkasan yang dipublikasikan:

“Sebanding” = beda masih dalam variasi antar run. Narasi yang diulang AWS: chatbot yang nunggu first token 4,4 detik bisa turun ke di bawah 800 ms di skenario yang mereka tunjukkan.

LoRA: EPP punya LoRA Affinity Scorer — request adapter diarahkan ke pod yang sudah load adapter di GPU memory, supaya tidak bayar swap adapter tiap kali.

Failure handling (Tier 1):

Observability: metrik pod (KV cache, queue, adapter) lewat Prometheus; pool-level histogram; cluster/fleet lewat CloudWatch.

Tier 1 sekarang, Tier 2 menyusul

Yang GA sekarang adalah Tier 1 — per-cluster gateway (EKS managed addon) di region yang sudah mendukung HyperPod inference addon.

Tier 2 — Global Inference Router (GIR) masih coming soon: routing lintas cluster/region, rate limiting global, cost-tier-aware traffic shaping. Tier 2 duduk di atas Tier 1; gateway lokal tetap jalan.

Roadmap lain yang disebut di blog:

1. Canary traffic splitting lewat InferenceModelRewrite CRD
2. Flow control / priority bands (Critical, Standard, Sheddable)

Untuk perencanaan kapasitas 2026 akhir: anggap Tier 1 sebagai fondasi production; jangan jual slide “global failover GIR” sebelum AWS umumkan GA.

Cocok dicoba dari Indo minggu ini

Buat tim product/ML di Indonesia yang sudah (atau mau) serve LLM di AWS, HyperPod Inference Gateway relevan kalau stack-nya sudah dekat EKS + vLLM/SGLang. Region HyperPod mengikuti ketersediaan addon inference — cek konsol/region list terkini sebelum janji SLA ke klien.

Yang praktis dicek minggu ini:

1. Apakah sudah punya HyperPod di EKS? Kalau masih pure EKS biasa tanpa HyperPod, gateway ini bukan drop-in untuk cluster generik — prasyaratnya HyperPod inference stack.
2. Model server version — upgrade vLLM/SGLang dulu; metrik KV cache harus terbaca.
3. Auth JWT — jangan expose endpoint ke VPC bersama tanpa spec.auth.jwt. Di perusahaan Indo yang share VPC antar tim, ini sering jadi lubang.
4. Biaya — gateway sendiri tidak punya harga add-on terpisah di What’s New; yang dibayar tetap compute HyperPod/EKS (GPU). Hematannya datang dari utilisasi GPU lebih sehat, bukan dari “SKU gratis ajaib”.
5. Latency ke user Indo — first-token di dalam cluster bisa turun drastis, tapi RTT ke user tetap tergantung region (mis. Singapore/Jakarta vs US). Gateway tidak mengganti CDN.
6. UMKM / startup tanpa cluster GPU — jalur Managed API (Bedrock, dll.) biasanya lebih masuk akal dulu. HyperPod cocok buat tim yang sudah bayar GPU sendiri dan ngerasa round-robin “aneh mahal”.

Ide uji 5 hari tanpa drama:

1. Hari 1: pastikan addon ≥ v2.0.0 dan CRD InferenceGatewayConfig muncul.
2. Hari 2: satu model, satu scheduler, uji curl OpenAI-compatible.
3. Hari 3: nyalakan JWT + TLS; uji 429 saat pool penuh.
4. Hari 4: bandingkan P95 TTFT round-robin vs gateway di load test kecil.
5. Hari 5: tambah model kedua / LoRA; cek BBR + affinity di metrik.

Kalau stack sudah AWS + HyperPod, ini salah satu tombol paling “high leverage” buat latency chat agent. Kalau belum, jangan paksa — bayar dulu utang operasional cluster.

Checklist

• Cluster HyperPod di EKS + Inference Operator sudah jalan
• Addon amazon-sagemaker-hyperpod-inference ≥ v2.0.0 dengan inferenceGateway.enabled
• vLLM ≥ 0.9.2 atau SGLang ≥ 0.3.5.post1 + metrics aktif
• cert-manager + Load Balancer Controller siap (kalau pakai TLS/ALB)
• IRSA role untuk ACM import dibuat sebelum addon (TLS auto-issue)
• Label pod model cocok dengan modelSelector
• InferenceGatewayConfig + (opsional) spec.inferenceGateway.enabled di endpoint
• JWT auth di-set — jangan andalkan VPC saja
• Load test: bandingkan TTFT P95/P99 vs round-robin
• Dashboard Prometheus/CloudWatch untuk KV cache & queue depth

Poin penting

• HyperPod Inference Gateway = routing GPU-aware di depan pod LLM HyperPod/EKS
• Tiga bagian: Envoy + Body-Based Router + Endpoint Picker
• Install lewat EKS addon; config lewat CRD InferenceGatewayConfig
• Client tetap OpenAI-compatible; multi-model & LoRA affinity built-in
• Klaim besar di mixed GPU / burst: TTFT turun tajam vs round-robin
• Tier 1 per-cluster sudah ada; Tier 2 global masih coming soon
• Wajib JWT — default endpoint tidak punya request auth

Referensi

1. Amazon Web Services (2026). Amazon SageMaker HyperPod Inference Gateway for scalable LLM inference — What’s New
2. AWS Machine Learning Blog / Vinay Arora, Piyush Daftary, Shreya Gangishetty (2026). Introducing Amazon SageMaker HyperPod Inference Gateway
3. AWS Documentation (2026). Inference Gateway for Amazon SageMaker HyperPod Inference
4. AWS Documentation (2026). Amazon SageMaker HyperPod Inference release notes
5. AWS Documentation (2026). Amazon SageMaker HyperPod on Amazon EKS
6. AWS (2026). Amazon SageMaker HyperPod product page
7. AWS (2026). SageMaker pricing
8. The Clarity (2026). HyperPod's inference gateway scores KV cache and LoRA residency before it picks a pod
9. Kubernetes SIG / Gateway API Inference Extension (2026). Upstream primitives referenced by HyperPod Inference Gateway
10. vLLM Project (2026). Metrics and OpenAI-compatible serving documentation
11. SGLang Project (2026). Server metrics and --enable-metrics guidance
12. AWS Prescriptive Guidance (2026). Gen AI inference architecture and best practices on AWS — HyperPod section