AWS ra mắt SageMaker HyperPod Inference Gateway cho định tuyến nhận thức GPU

Amazon Web Services công bố Amazon SageMaker HyperPod Inference Gateway vào ngày 18 tháng 9 năm 2026, một hệ thống định tuyến nhận thức GPU, bản địa Kubernetes, dành cho suy luận mô hình ngôn ngữ lớn, được triển khai như một tiện ích bổ sung quản lý duy nhất cho Amazon EKS trên cơ sở hạ tầng HyperPod hiện có. AWS cho biết cổng này có thể giảm độ trễ token đầu tiên lên tới 82%.

Vấn đề định tuyến đằng sau cổng

Theo AWS, các thuật toán cân bằng tải mặc định của Kubernetes như vòng tròn (round-robin) và kết nối ít nhất (least-connections) không có khả năng nhìn thấy trạng thái GPU: pod nào đã bão hòa bộ nhớ đệm KV, pod nào đang ở giữa quá trình sinh ngữ cảnh dài, và pod nào đã có bộ điều hợp LoRA mà yêu cầu cần tải trong bộ nhớ. Công ty cho biết các yêu cầu tích tụ phía sau các pod bận trong khi công suất nhàn rỗi không được sử dụng, độ trễ token đầu tiên tăng lên trên bốn giây trong các đợt tải đột biến, mức sử dụng trở nên không đồng đều và khó dự đoán, và các nhà vận hành phải cung cấp quá mức để bù đắp. AWS mô tả một kịch bản trong đó người dùng chatbot chờ 4,4 giây để nhận token đầu tiên nhưng thực tế nhận được trong vòng dưới 800 mili giây.

Kiến trúc Hai Tầng

Cổng này sử dụng thiết kế hai tầng dựa trên các primitive bản địa Kubernetes. AWS cho biết nó sử dụng tín hiệu GPU thời gian thực để đặt mỗi yêu cầu suy luận vào pod phù hợp nhất. Tầng 1 được cài đặt trực tiếp trên mỗi HyperPod hoặc cụm EKS dưới dạng tiện ích bổ sung amazon-sagemaker-hyperpod-inference và bao gồm ba thành phần, tất cả được xây dựng trên Gateway API Inference Extension mã nguồn mở. Envoy Gateway, một proxy lớp‑7, chấm dứt lưu lượng HTTPS đến và cung cấp một endpoint riêng tư duy nhất cho mỗi cụm. Bộ định tuyến dựa trên nội dung (Body‑Based Router) kiểm tra mỗi thân yêu cầu tương thích OpenAI, trích xuất trường model và định tuyến yêu cầu tới pool model phù hợp, do đó một cổng có thể phục vụ nhiều mô hình.

Endpoint Picker tiêu thụ các chỉ số Prometheus thời gian thực từ mọi pod phục vụ mô hình và áp dụng thuật toán chấm điểm có trọng số trên các bộ chấm điểm bao gồm việc sử dụng bộ nhớ đệm KV, độ sâu hàng đợi, thời gian tồn tại bộ điều hợp LoRA, tỷ lệ hit bộ nhớ đệm tiền tố, và các yêu cầu đang chạy. Mỗi bộ chấm điểm mang một trọng số có thể cấu hình, cho phép hành vi định tuyến được điều chỉnh cho khối lượng công việc cụ thể, chẳng hạn như trò chuyện nhạy cảm với độ trễ so với batch tối ưu hoá thông lượng.

Tầng 2, Global Inference Router, được liệt kê là sẽ ra mắt sớm. AWS cho biết sẽ bổ sung khả năng phối hợp toàn bộ đội xe trên nhiều cụm và khu vực, với chuyển đổi dự phòng giữa các cụm, giới hạn tốc độ toàn cầu, và định hình lưu lượng dựa trên chi phí. Tầng 2 xây dựng trên nền Tầng 1, trong khi cổng mỗi cụm vẫn tiếp tục xử lý định tuyến nội bộ.

Triển khai, Xử lý Lỗi và Khả năng Quan sát

Triển khai bao gồm một lệnh aws eks create-addon duy nhất và một tài nguyên tùy chỉnh InferenceGatewayConfig khai báo, định nghĩa các mô hình và hành vi định tuyến, với các triển khai máy chủ mô hình hiện có được phát hiện qua nhãn pod. AWS cho biết việc cài đặt không yêu cầu sidecar, không cần service mesh và không cần thay đổi mã ứng dụng. Cổng này cung cấp một endpoint tiêu chuẩn tương thích OpenAI qua HTTP; theo AWS, mã khách hiện có hoạt động mà không thay đổi, không cần thay đổi SDK và không cần ký SigV4 cho lưu lượng suy luận.

Đối với các khối lượng công việc phục vụ các bộ điều hợp LoRA đã tinh chỉnh trên một mô hình cơ sở chia sẻ, LoRA Affinity Scorer của Endpoint Picker định tuyến các yêu cầu bộ điều hợp tới các pod đã có bộ điều hợp yêu cầu tồn tại trong bộ nhớ GPU; nếu không có pod nào tải sẵn, yêu cầu sẽ được chuyển tới pod có dung lượng khả dụng nhiều nhất. AWS cho biết điều này loại bỏ độ trễ chuyển đổi bộ điều hợp.

Các hành vi lỗi được ghi lại bao gồm lỗi pod, cạn kiệt pool, lỗi cụm và lỗi khu vực. Khi pod gặp lỗi, Endpoint Picker loại trừ các pod có chỉ số lỗi thời và định tuyến tới các pod khỏe mạnh, tự động phục hồi khi chỉ số trở lại. Khi pool cạn kiệt, cổng trả về HTTP 429 kèm tiêu đề Retry-After trong khi tự động mở rộng thêm dung lượng. Khi cụm gặp lỗi, Global Inference Router phát hiện heartbeat lỗi thời và chuyển hướng lưu lượng trong vòng 35 giây, với việc tăng dần khi cụm được đưa lại. Khi khu vực gặp lỗi, định tuyến xuyên khu vực tự động kích hoạt, mà AWS cho biết sẽ gây độ trễ cao hơn nhưng không ảnh hưởng đến tính sẵn sàng.

Cổng này phát ra các chỉ số ở mức pod, pool, cụm và đội xe: việc sử dụng bộ nhớ đệm KV, độ sâu hàng đợi, các yêu cầu đang chạy và thời gian tồn tại bộ điều hợp thông qua Prometheus ở mức pod; tổng số yêu cầu, biểu đồ thời lượng và số lượng token thông qua Prometheus và Grafana ở mức pool; trung bình bộ nhớ đệm KV, tỷ lệ lỗi và độ trễ P99 thông qua Amazon CloudWatch ở mức cụm; và quyết định định tuyến, sự kiện chuyển đổi dự phòng và số lần giới hạn tốc độ thông qua CloudWatch ở mức đội xe.

Kết quả Đánh giá Tiêu chuẩn do AWS Báo cáo

AWS cho biết họ đã thực hiện đánh giá tiêu chuẩn cho bốn mô hình có từ 8 tỷ đến 235 tỷ tham số trên các instance p5.48xlarge với GPU H100 và các instance g5 với GPU A10G. Tất cả lưu lượng được định tuyến qua các Application Load Balancer nội bộ, khớp với đường đi của một yêu cầu sản xuất, với một nhóm nút khách hàng chuyên dụng tạo tải kiểm soát và các máy chủ mô hình được cô lập trên một nhóm nút máy chủ riêng biệt. Mỗi kết quả sử dụng cấu hình định tuyến mặc định của cổng mà không có tinh chỉnh và được đo so với baseline vòng tròn Kubernetes trên các bản sao mô hình giống nhau, theo AWS.

Trong các kết quả được báo cáo, một đội ngũ GPU hỗn hợp thế hệ đã giảm thời gian đến token đầu tiên (latency) P95 và P99 xuống 97% cho Llama-3.1-8B, đồng thời tăng thông lượng lên 8%, và giảm 98% và 97% cho Qwen3-32B, với mức tăng thông lượng 50%. Khi lưu lượng đột biến, Llama-3.1-70B đạt mức giảm P95 và P99 lần lượt là 94% và 98% với thông lượng cao hơn 12%, trong khi Qwen3-235B cho thấy độ trễ P95 tương đương và P99 giảm 89%. Với các tiền tố prompt được chia sẻ, độ trễ P95 và P99 của Llama-3.1-8B giảm 26% và 43%.

AWS cho biết rằng trên một đội ngũ đồng nhất hoàn toàn trong điều kiện lưu lượng ổn định, gateway hoạt động tương đương với vòng quay (round-robin), và họ định nghĩa kết quả tương đương là sự khác biệt nằm trong độ biến thiên giữa các lần chạy. Công ty cho biết các cải tiến lớn nhất xuất hiện ở những nơi vòng quay gặp khó khăn nhất: phần cứng hỗn hợp, nhu cầu đột biến và các tiền tố prompt được chia sẻ.

Khả dụng và Lộ trình

AWS mô tả gateway tuân thủ chuẩn Kubernetes Gateway API và Phần mở rộng Inference của nó, được cấu hình thông qua một định nghĩa tài nguyên tùy chỉnh duy nhất, và tương thích với bất kỳ máy chủ mô hình nào tương thích với OpenAI, bao gồm vLLM, SGLang và TGI. Quản lý thực hiện qua kubectl, GitOps, Helm và ArgoCD, với việc cài đặt, nâng cấp và khôi phục được xử lý thông qua vòng đời add-on EKS.

Định tuyến cấp Tier 1 cho mỗi cụm đã khả dụng kể từ ngày 18 tháng 9 năm 2026, ở các khu vực mà add-on inference có sẵn. Ngoài Bộ định tuyến Inference Toàn cầu, các mục lộ trình có tên của AWS bao gồm việc chia tách lưu lượng canary, sẽ định tuyến một phần trăm lưu lượng tới các phiên bản mô hình mới bằng cách sử dụng tài nguyên tùy chỉnh InferenceModelRewrite, và kiểm soát luồng (flow control) phân loại yêu cầu thành Critical, Standard hoặc Sheddable với kiểm soát nhập khẩu theo dải.