AWS Merinci HyperPod InstantStart Control Plane Sumber Terbuka untuk Operasi Agen

Amazon Web Services telah merinci HyperPod InstantStart, sebuah control plane sumber terbuka yang menggabungkan orkestrasi Amazon EKS dengan kemampuan terkelola dari Amazon SageMaker HyperPod, dalam sebuah post AWS Machine Learning Blog yang diterbitkan pada 4 September 2026. Proyek ini memadukan antarmuka web dengan agen AI yang merencanakan dan mengeksekusi operasi klaster bertahap melalui alat Model Context Protocol.

InstantStart berjalan sebagai satu kontainer manajemen out-of-band di dalam akun AWS pengguna, memanggil API layanan AWS dan API Kubernetes tanpa berada di jalur data pekerjaan pelatihan atau permintaan inferensi. Setiap sumber daya yang dibuatnya adalah objek standar AWS atau Kubernetes yang tetap dapat diperiksa dengan AWS Command Line Interface dan kubectl. Antarmuka web, REST API, dan alat MCP yang digunakan agen merupakan tiga wajah dari kontainer yang sama, sehingga kedua antarmuka masuk melalui satu backend dan melewati validasi yang sama.

Satu Backend di Balik Dua Antarmuka

Argumen desain utama postingan ini adalah bahwa alat MCP membungkus REST API control plane sendiri alih‑alih AWS CLI atau SDK, sehingga satu validasi yang ditambahkan melindungi browser dan agen sekaligus. Pada antarmuka web, membuat klaster dengan dependensi terpasang, pemulihan node otomatis aktif, dan penyimpanan terpasang disajikan sebagai formulir dan panel kemajuan; pada terminal, itu menjadi satu kalimat bahasa alami untuk konfigurasi agen yang disebut hypd-inst-agent, dibangun untuk Kiro CLI. Agen kemudian menyusun urutan kerja: pembuatan control‑plane EKS, pemilihan klaster aktif, rekonsiliasi dependensi, pembuatan klaster HyperPod, dan penyiapan penyimpanan. AWS menyatakan bahwa pembuatan control‑plane EKS selesai dalam kira‑kira 8 hingga 12 menit, dan setiap tahap berikutnya mencatat statusnya sendiri serta dapat di‑retry secara independen.

Tiga aturan alur kerja dikodekan dalam keterampilan agen proyek, yang dalam postingan digambarkan sebagai playbook markdown yang versi‑nya disimpan dalam repositori. Agen memantau setiap operasi yang berlangsung lama hingga mencapai status terminal alih‑alih melaporkan permintaan yang dikirim. Ia hanya mengajukan pertanyaan tingkat keputusan, seperti Zona Ketersediaan, tipe instance, dan tipe kapasitas, sementara subnet CIDR, tabel rute, dan grup keamanan diperlakukan sebagai pekerjaan control‑plane. Dan ia melakukan inspeksi sebelum membuat, dengan menampilkan daftar klaster yang ada serta menanyakan zona dan tipe instance yang valid sebelum menawarkan pilihan.

Kemampuan Terkelola sebagai Status yang Direkonsiliasi

InstantStart membuat klaster HyperPod dengan pemulihan node otomatis diaktifkan, di mana HyperPod dapat me‑restart atau mengganti node yang rusak berdasarkan agen pemantau kesehatan, pemeriksaan kesehatan dasar, serta pemeriksaan kesehatan mendalam opsional yang menguji stres GPU dan konektivitas Elastic Fabric Adapter sebelum node menerima pekerjaan. Ketika pengguna menambahkan grup instance, tipe kapasitas, mode antarmuka jaringan, dan penempatan subnet diselesaikan sebagai satu operasi saat pembuatan; tipe kapasitas dan mode antarmuka hanya‑EFA tetap tetap selama masa hidup grup. Control plane mengarahkan setiap jalur kapasitas melalui satu fungsi yang menyediakan subnet komputasi berukuran /20 untuk armada akselerator besar.

Autoscaling node berbasis Karpenter yang dikelola HyperPod menentukan berapa banyak kapasitas yang berjalan pada suatu waktu, dengan AWS mengoperasikan kontroler Karpenter itu sendiri dan node diluncurkan dari grup instance HyperPod yang skalanya naik dari nol. Postingan mencatat satu batas cakupan: Karpenter yang dikelola mengatur grup instance HyperPod, bukan kapasitas Amazon EC2 umum.

Panel Fitur Lanjutan menampilkan kemampuan terkelola HyperPod, termasuk operator pelatihan, operator inferensi, checkpoint bertingkat yang dikelola, dan autoscaling yang dikelola, dengan setiap saklar dipetakan ke operasi backend yang sadar dependensi. Mengaktifkan checkpoint bertingkat menyediakan rantai identitas yang meliputi akun layanan Kubernetes, peran dan kebijakan IAM, hubungan kepercayaan OpenID Connect, serta anotasi binding, dan menonaktifkannya menghapus rantai yang sama. Postingan juga menjelaskan kontrak diff eksplisit yang diadopsi setelah bug awal: antarmuka hanya mengirimkan bidang yang benar‑benar diubah pengguna, dan backend membaca keadaan klaster aktual serta tidak melakukan apa‑apa ketika permintaan dan keadaan aktual sudah cocok.

Jalur Pelatihan dan Inferensi

Untuk pelatihan, InstantStart menawarkan dua jalur pengiriman. Operator pelatihan HyperPod, yang dipasang sebagai add‑on EKS, menambahkan pemulihan kesalahan tingkat proses, deteksi pekerjaan yang menggantung melalui pemantauan pola log, dan deteksi outlier, dengan pekerjaan yang dikirim sebagai sumber daya HyperPodPyTorchJob yang membawa anggaran pemulihan yang terlihat. Jalur kedua adalah KubeRay standar, ditujukan untuk beban kerja native Ray seperti reinforcement learning. Di atas keduanya terdapat lapisan resep untuk skrip PyTorch biasa, LLaMA‑Factory, MS‑Swift, dan VERL reinforcement learning, semua berbagi satu kontrak data di mana bucket Amazon S3 yang sama dipasang di lingkungan pengembangan dan di dalam pod. Log pekerjaan mengalir ke browser lewat WebSocket, dan resep dapat melaporkan metrik seperti throughput pelatihan ke MLflow yang dikelola pada Amazon SageMaker AI.

Inferensi juga memiliki dua jalur. Jalur terkelola menyerahkan siklus hidup ke operator inferensi HyperPod, dengan caching KV bertingkat yang dikelola dan strategi routing cerdas yang dideklarasikan bersama endpoint. Jalur yang dikelola sendiri menyebarkan kontainer layanan pilihan pengguna, seperti vLLM atau SGLang, sebagai penyebaran Kubernetes standar, dengan bentuk layanan termasuk load balancer eksternal, layanan internal klaster, dan kumpulan model pekerja GPU hangat yang dapat dialokasikan kembali dengan mengubah label. Untuk layanan SGLang multi‑replica, control plane dapat menyebarkan router SGLang dengan routing yang sadar cache dan menggerakkan autoscaling melalui Kubernetes Event‑driven Autoscaling.

Alat Agen dan Batasannya

Server MCP mempublikasikan 38 alat yang mencakup siklus hidup klaster, grup instance, fitur terkelola, penyimpanan, pengunduhan model, penyebaran inferensi, pekerjaan, dan operasi node, menurut postingan. Setiap alat yang memodifikasi menamai alat status yang menentukan penyelesaian, dan operasi menyimpan fase mereka sebelum pemantauan dimulai sehingga retry agen tidak dapat memutar ulang mutasi. Repositori GitHub proyek menggambarkan platform sebagai sistem terintegrasi pelatihan‑dan‑inferensi yang dibangun di atas SageMaker HyperPod dan orkestrasi EKS standar, dan README‑nya menyatakan bahwa alat MCP membungkus API backend proyek untuk kepatuhan praktik terbaik sementara keterampilan agen mengorkestrasi alur kerja ujung‑ke‑ujung dengan nol penyiapan lokal selain agen.

Postingan menggambar batas operasional yang eksplisit. Keterampilan diagnostik yang dibundel untuk NCCL, kesehatan node, dan kegagalan pembuatan klaster menyelidiki secara read‑only sendiri, menyajikan perintah yang mengubah status sebagai saran, dan meningkatkan urutan penyelidikan, reboot, lalu penggantian. IAM, otorisasi Kubernetes, kontrol jaringan, dan validasi backend tetap menjadi batas keamanan yang sebenarnya; agen memperluas akses ke control plane tanpa memperluas hak istimewanya. AWS juga menasihati bahwa pelatihan elastis saat ini tidak mencakup Spot Instances, checkpoint bertingkat yang dikelola, dan pelatihan tanpa checkpoint, serta bahwa kuota penggunaan klaster SageMaker HyperPod dan reservasi rencana pelatihan untuk tipe GPU kelas atas perlu diatur sebelum klaster pertama.

Deployment dimulai dari templat CloudFormation yang membuat lingkungan manajemen, bucket S3 bersama, dan peran IAM pendukung, dengan antarmuka web disajikan dari kontainer pada port 3099 dan dapat diakses melalui sesi port‑forwarding AWS Systems Manager.