AWS เปิดตัว SageMaker HyperPod Inference Gateway สำหรับการกำหนดเส้นทางที่รับรู้ GPU

Amazon Web Services ประกาศ Amazon SageMaker HyperPod Inference Gateway เมื่อ 18 กันยายน 2026, เป็นระบบกำหนดเส้นทางที่เป็น Kubernetes-native และรับรู้ GPU สำหรับการสรุปผลโมเดลภาษาขนาดใหญ่ ที่ทำการติดตั้งเป็นส่วนเสริมที่จัดการได้เพียงหนึ่งเดียวสำหรับ Amazon EKS บนโครงสร้างพื้นฐาน HyperPod ที่มีอยู่. AWS กล่าวว่า gateway สามารถลด latency ของโทเคนแรกได้สูงสุด 82%

ปัญหาการกำหนดเส้นทางเบื้องหลัง Gateway

ตามข้อมูลของ AWS, อัลกอริทึมการกระจายโหลดเริ่มต้นของ Kubernetes เช่น round-robin และ least-connections ไม่สามารถมองเห็นสถานะของ GPU ได้: ว่า pod ใดมีแคช KV ครบ, pod ใดกำลังอยู่ระหว่างการสร้างข้อความแบบบริบทยาว, และว่า pod ใดมี LoRA adapter ที่คำขอต้องการโหลดอยู่ในหน่วยความจำแล้ว. บริษัทระบุว่าคำขอจะสะสมอยู่หลังจาก pod ที่ทำงานหนักในขณะที่ความจุที่ว่างอยู่ไม่ได้ถูกใช้, latency ของโทเคนแรกพุ่งขึ้นเหนือสี่วินาทีในช่วงการจราจรพุ่งกระหน่ำ, การใช้ทรัพยากรกลายเป็นไม่สม่ำเสมอและคาดเดาไม่ได้, และผู้ดำเนินการจึงจัดสรรเกินความจำเป็นเพื่อชดเชย. AWS อธิบายสถานการณ์ที่ผู้ใช้แชทบอทที่ต้องรอ 4.4 วินาทีสำหรับโทเคนแรก แต่กลับได้รับในเวลาไม่ถึง 800 มิลลิวินาที.

สถาปัตยกรรมสองชั้น

Gateway ใช้การออกแบบสองชั้นที่สร้างบน primitive ของ Kubernetes-native. AWS กล่าวว่าใช้สัญญาณ GPU แบบเรียลไทม์เพื่อวางคำขอ inference แต่ละรายการไปยัง pod ที่เหมาะสมที่สุด. ชั้น Tier 1 ติดตั้งโดยตรงบนแต่ละ HyperPod หรือคลัสเตอร์ EKS ในรูปแบบส่วนเสริม amazon-sagemaker-hyperpod-inference และประกอบด้วยสามส่วนประกอบ, ทั้งหมดสร้างบน Gateway API Inference Extension แบบโอเพ่นซอร์ส. Envoy Gateway, พร็อกซีระดับ 7, ทำการยุติการรับทราฟฟิก HTTPS เข้ามาและเปิดเผย endpoint ส่วนตัวหนึ่งรายการต่อคลัสเตอร์. Body-Based Router ตรวจสอบเนื้อหา request ที่เข้ากันได้กับ OpenAI แต่ละรายการ, ดึงฟิลด์ model, และกำหนดเส้นทางคำขอไปยัง pool ของโมเดลที่ถูกต้อง, ทำให้ gateway หนึ่งสามารถให้บริการหลายโมเดลได้.

Endpoint Picker ใช้เมตริก Prometheus แบบเรียลไทม์จากทุก pod ที่ให้บริการโมเดลและประยุกต์อัลกอริทึมการให้คะแนนแบบถ่วงน้ำหนักข้าม scorer ที่ครอบคลุมการใช้แคช KV, ความลึกของคิว, การอยู่ของ LoRA adapter, อัตราการฮิตของแคชพรีฟิกซ์, และคำขอที่กำลังทำงาน. แต่ละ scorer มีน้ำหนักที่กำหนดค่าได้, ทำให้พฤติกรรมการกำหนดเส้นทางสามารถปรับให้เหมาะกับภาระงานเฉพาะได้, เช่นแชทที่ต้องการ latency ต่ำเทียบกับแบตช์ที่เน้น throughput.

Tier 2, Global Inference Router, ถูกระบุว่าจะเปิดให้บริการเร็ว ๆ นี้. AWS กล่าวว่า จะเพิ่มการประสานงานระดับฟลีตทั่วทั้งคลัสเตอร์และภูมิภาคหลายแห่ง, พร้อมการสลับคลัสเตอร์ข้าม (cross-cluster failover), การจำกัดอัตราแบบทั่วโลก, และการจัดรูปแบบทราฟฟิกที่คำนึงถึงต้นทุน. Tier 2 สร้างบน Tier 1, ในขณะที่ gateway ของแต่ละคลัสเตอร์ยังคงจัดการการกำหนดเส้นทางในระดับท้องถิ่นต่อไป.

การปรับใช้, การจัดการความล้มเหลว, และการสังเกตการณ์

การปรับใช้ประกอบด้วยคำสั่ง aws eks create-addon เพียงคำสั่งเดียวและทรัพยากรแบบกำหนดเอง InferenceGatewayConfig หนึ่งรายการที่อธิบายโมเดลและพฤติกรรมการกำหนดเส้นทาง, โดยการปรับใช้เซิร์ฟเวอร์โมเดลที่มีอยู่จะถูกค้นพบผ่านป้ายกำกับ pod. AWS ระบุว่าการติดตั้งไม่ต้องใช้ sidecar, ไม่ต้องใช้ service mesh, และไม่ต้องเปลี่ยนแปลงโค้ดแอปพลิเคชัน. Gateway เปิดเผย endpoint มาตรฐานที่เข้ากันได้กับ OpenAI ผ่าน HTTP; ตามข้อมูลของ AWS, โค้ดไคลเอนต์ที่มีอยู่ทำงานโดยไม่เปลี่ยนแปลง, ไม่ต้องมีการเปลี่ยนแปลง SDK และไม่ต้องมีการลงนาม SigV4 สำหรับทราฟฟิก inference.

สำหรับงานที่ให้บริการ LoRA adapter ที่ปรับแต่งละเอียดบนโมเดลฐานที่ใช้ร่วมกัน, LoRA Affinity Scorer ของ Endpoint Picker จะกำหนดเส้นทางคำขอ adapter ไปยัง pod ที่มี adapter ที่ร้องขออยู่แล้วใน หน่วยความจำ GPU; หากไม่มี pod ใดโหลดไว้, คำขอจะไปยัง pod ที่มีความจุว่างมากที่สุด. AWS กล่าวว่าแนวทางนี้ขจัด latency ของการสลับ adapter.

พฤติกรรมความล้มเหลวที่บันทึกไว้ครอบคลุมการล้มเหลวของ pod, การหมด pool, การล้มเหลวของคลัสเตอร์, และการล้มเหลวของภูมิภาค. เมื่อ pod ล้มเหลว, Endpoint Picker จะตัด pod ที่มีเมตริกล้าสมัยออกและกำหนดเส้นทางไปยัง pod ที่ทำงานปกติ, โดยจะฟื้นตัวโดยอัตโนมัติเมื่อเมตริกกลับมา. เมื่อ pool หมด, gateway จะส่งคืน HTTP 429 พร้อมหัวข้อ Retry-After ในขณะที่การปรับขนาดอัตโนมัติเพิ่มความจุ. เมื่อคลัสเตอร์ล้มเหลว, Global Inference Router จะตรวจจับ heartbeat ที่ล้าสมัยและเปลี่ยนเส้นทางภายใน 35 วินาที, พร้อมการเพิ่มขึ้นอย่างค่อยเป็นค่อยไปเมื่อคลัสเตอร์ถูกนำกลับมาใช้งาน. เมื่อเกิดความล้มเหลวของภูมิภาค, การกำหนดเส้นทางข้ามภูมิภาคจะทำงานโดยอัตโนมัติ, ซึ่ง AWS กล่าวว่ามี latency สูงขึ้นแต่ไม่มีผลต่อความพร้อมใช้งาน.

Gateway ส่งออกเมตริกที่ระดับ pod, pool, cluster, และ fleet: การใช้แคช KV, ความลึกของคิว, คำขอที่กำลังทำงาน, และการอยู่ของ adapter ผ่าน Prometheus ที่ระดับ pod; จำนวนคำขอรวม, ฮิสโตแกรมระยะเวลา, และจำนวนโทเคนผ่าน Prometheus และ Grafana ที่ระดับ pool; ค่าเฉลี่ยของแคช KV, อัตราข้อผิดพลาด, และ latency P99 ผ่าน Amazon CloudWatch ที่ระดับ cluster; รวมถึงการตัดสินใจกำหนดเส้นทาง, เหตุการณ์สลับเส้นทาง, และการโดนจำกัดอัตราผ่าน CloudWatch ที่ระดับ fleet.

ผลการทดสอบตามรายงานของ AWS

AWS กล่าวว่าได้ทำการทดสอบเปรียบเทียบสี่โมเดลที่มีจำนวนพารามิเตอร์ตั้งแต่ 8B ถึง 235B บนอินสแตนซ์ p5.48xlarge ที่ใช้ GPU H100 และอินสแตนซ์ g5 ที่ใช้ GPU A10G. การจราจรทั้งหมดถูกกำหนดเส้นทางผ่าน Application Load Balancer ภายใน, ตรงกับเส้นทางที่คำขอการผลิตเดินทาง, โดยมีกลุ่มโหนดไคลเอนต์เฉพาะที่สร้างโหลดที่ควบคุมได้และเซิร์ฟเวอร์โมเดลแยกออกเป็นกลุ่มโหนดเซิร์ฟเวอร์อื่น. ผลลัพธ์ทุกอย่างใช้การกำหนดค่า routing เริ่มต้นของ gateway โดยไม่มีการปรับแต่งและวัดเทียบกับฐานรอบ round-robin ของ Kubernetes บนสำเนาโมเดลเดียวกัน, ตามข้อมูลของ AWS.

ตามผลลัพธ์ที่รายงานไว้, กลุ่ม GPU รุ่นผสมได้ลดเวลา‑to‑first‑token (P95 และ P99) ลง 97% ทั้งสองสำหรับ Llama-3.1-8B พร้อมการเพิ่มอัตราการทำงาน 8%, และลดลง 98% และ 97% สำหรับ Qwen3-32B พร้อมการเพิ่มอัตราการทำงาน 50%. ภายใต้การจราจรแบบกระตุก, Llama-3.1-70B แสดงการลด P95 และ P99 ลง 94% และ 98% พร้อมอัตราการทำงานเพิ่ม 12%, ในขณะที่ Qwen3-235B มีค่า P95 ที่เทียบเคียงได้และค่า P99 ลดลง 89%. เมื่อใช้คำนำหน้าพรอมต์ร่วมกัน, เวลาแฝง P95 และ P99 ของ Llama-3.1-8B ลดลง 26% และ 43% ตามลำดับ.

AWS กล่าวว่าในกรณีที่มีฟลีตที่สม่ำเสมอเต็มรูปแบบภายใต้การจราจรคงที่, เกตเวย์ทำงานเทียบเท่ากับการกระจายแบบราวด์‑โรบิน, และกำหนดผลลัพธ์ที่เทียบเคียงได้ว่าเป็นความแตกต่างที่อยู่ในช่วงความแปรปรวนระหว่างการรันแต่ละครั้ง. บริษัทระบุว่าการปรับปรุงมีผลมากที่สุดในสถานการณ์ที่ราวด์‑โรบินประสบปัญหามากที่สุด: ฮาร์ดแวร์ผสม, ความต้องการกระตุก, และคำนำหน้าพรอมต์ร่วมกัน.

ความพร้อมใช้งานและแผนงาน

AWS อธิบายว่าเกตเวย์สอดคล้องกับ Kubernetes Gateway API และส่วนขยาย Inference Extension, ถูกกำหนดค่าผ่านการกำหนดทรัพยากรแบบกำหนดเองเพียงหนึ่งรายการ, และเข้ากันได้กับเซิร์ฟเวอร์โมเดลที่รองรับ OpenAI ใด ๆ รวมถึง vLLM, SGLang, และ TGI. การจัดการทำงานผ่าน kubectl, GitOps, Helm, และ ArgoCD, โดยการติดตั้ง, การอัปเกรด, และการย้อนกลับจะจัดการผ่านวงจรชีวิตของ EKS add‑on.

การกำหนดเส้นทางระดับ Tier 1 ต่อคลัสเตอร์พร้อมใช้งานตั้งแต่วันที่ 18 กันยายน 2026 ในภูมิภาคที่มี add‑on การสรุปผลพร้อมใช้งาน. นอกเหนือจาก Global Inference Router, รายการแผนงานที่ระบุของ AWS รวมถึงการแยกการจราจรแบบคาเนอรีซึ่งจะส่งต่อเปอร์เซ็นต์ของการจราจรไปยังเวอร์ชันโมเดลใหม่โดยใช้ทรัพยากรกำหนดเอง InferenceModelRewrite, และการควบคุมการไหลที่จัดประเภทคำขอเป็น Critical, Standard หรือ Sheddable พร้อมการควบคุมการรับเข้าแบบแถบต่อแถบ.