Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Menyebarkan model di Amazon SageMaker HyperPod
Amazon SageMaker HyperPod sekarang melampaui pelatihan untuk menghadirkan platform inferensi komprehensif yang menggabungkan fleksibilitas Kubernetes dengan keunggulan operasional layanan terkelola. AWS Terapkan, skala, dan optimalkan model pembelajaran mesin Anda dengan keandalan tingkat perusahaan menggunakan HyperPod komputasi yang sama di seluruh siklus hidup model.
Amazon SageMaker HyperPod menawarkan antarmuka penerapan fleksibel yang memungkinkan Anda menerapkan model melalui beberapa metode termasuk kubectl, Python SDK, Amazon Studio UI, atau CLI. SageMaker HyperPod Layanan ini menyediakan kemampuan penskalaan otomatis tingkat lanjut dengan alokasi sumber daya dinamis yang melakukan penyesuaian otomatis berdasarkan permintaan. Selain itu, ini mencakup fitur observabilitas dan pemantauan komprehensif yang melacak metrik penting seperti time-to-first-token, latensi, dan pemanfaatan GPU untuk membantu Anda mengoptimalkan kinerja.
catatan
Saat menerapkan pada instance berkemampuan GPU, Anda dapat menggunakan partisi GPU dengan teknologi Multi-Instance GPU (MIG) untuk menjalankan beberapa beban kerja inferensi pada satu GPU. Hal ini memungkinkan pemanfaatan GPU yang lebih baik dan optimalisasi biaya. Untuk informasi selengkapnya tentang mengonfigurasi partisi GPU, lihat. Menggunakan partisi GPU di Amazon SageMaker HyperPod
Infrastruktur terpadu untuk pelatihan dan inferensi
Maksimalkan pemanfaatan GPU Anda dengan mentransisikan sumber daya komputasi secara mulus antara beban kerja pelatihan dan inferensi. Ini mengurangi total biaya kepemilikan sambil mempertahankan kontinuitas operasional.
Opsi penerapan siap perusahaan
Terapkan model dari berbagai sumber termasuk model bobot terbuka dan terjaga keamanannya dari Amazon SageMaker JumpStart dan model khusus dari Amazon S3 dan Amazon FSx dengan dukungan untuk arsitektur inferensi simpul tunggal dan multi-node.
Caching nilai Kunci (KV) berjenjang terkelola dan perutean cerdas
Caching KV menyimpan vektor nilai kunci yang telah dihitung sebelumnya setelah memproses token sebelumnya. Saat token berikutnya diproses, vektor tidak perlu dihitung ulang. Melalui arsitektur caching dua tingkat, Anda dapat mengonfigurasi cache L1 yang menggunakan memori CPU untuk penggunaan kembali lokal latensi rendah, dan cache L2 yang memanfaatkan Redis untuk mengaktifkan berbagi cache tingkat node yang dapat diskalakan.
Perutean cerdas menganalisis permintaan yang masuk dan mengarahkannya ke instance inferensi yang kemungkinan besar memiliki pasangan nilai kunci cache yang relevan. Sistem memeriksa permintaan dan kemudian merutekkannya berdasarkan salah satu strategi perutean berikut:
prefixaware— Permintaan berikutnya dengan awalan prompt yang sama dirutekan ke instance yang samakvaware— Permintaan masuk dirutekan ke instance dengan tingkat hit cache KV tertinggi.session— Permintaan dari sesi pengguna yang sama dirutekan ke instance yang sama.roundrobin— Bahkan distribusi permintaan tanpa mempertimbangkan status cache KV.
Untuk informasi selengkapnya tentang cara mengaktifkan fitur ini, lihatKonfigurasikan caching KV dan perutean cerdas untuk meningkatkan kinerja.
Cache L2 bawaan Dukungan Penyimpanan Berjenjang untuk KV Caching
Dibangun di atas infrastruktur cache KV yang ada, HyperPod sekarang mengintegrasikan penyimpanan berjenjang sebagai opsi backend L2 tambahan bersama Redis. Dengan penyimpanan berjenjang SageMaker terkelola bawaan, ini menawarkan peningkatan kinerja. Peningkatan ini memberi pelanggan opsi yang lebih skalabel dan efisien untuk pembongkaran cache, terutama bermanfaat untuk beban kerja inferensi LLM throughput tinggi. Integrasi mempertahankan kompatibilitas dengan server model VLLM yang ada dan kemampuan routing sambil menawarkan kinerja yang lebih baik.
catatan
Enkripsi data: Data cache KV (kunci perhatian dan nilai) disimpan tidak terenkripsi saat istirahat untuk mengoptimalkan latensi inferensi dan meningkatkan kinerja. Untuk beban kerja dengan encryption-at-rest persyaratan ketat, pertimbangkan enkripsi lapisan aplikasi permintaan dan tanggapan, atau nonaktifkan caching.
Isolasi data: Saat menggunakan penyimpanan berjenjang terkelola sebagai backend cache L2, beberapa penerapan inferensi dalam penyimpanan cache berbagi cluster tanpa isolasi. Data cache L2 KV (kunci perhatian dan nilai) dari penerapan yang berbeda tidak dipisahkan. Untuk beban kerja yang memerlukan isolasi data (skenario multi-penyewa, tingkat klasifikasi data yang berbeda), terapkan ke cluster terpisah atau gunakan instance Redis khusus.
Penerapan tipe multi-instance dengan failover otomatis
HyperPod Inferensi mendukung penerapan tipe multi-instance untuk meningkatkan keandalan penerapan dan pemanfaatan sumber daya. Tentukan daftar tipe instans yang diprioritaskan dalam konfigurasi penerapan Anda, dan sistem secara otomatis memilih dari alternatif yang tersedia saat jenis instans pilihan Anda tidak memiliki kapasitas. Penjadwal Kubernetes menggunakan afinitas preferredDuringSchedulingIgnoredDuringExecution node untuk mengevaluasi tipe instance dalam urutan prioritas, menempatkan beban kerja pada tipe instans prioritas tertinggi yang tersedia sambil memastikan penerapan bahkan ketika sumber daya pilihan tidak tersedia. Kemampuan ini mencegah kegagalan penerapan karena kendala kapasitas sambil mempertahankan preferensi biaya dan kinerja Anda, memastikan ketersediaan layanan berkelanjutan bahkan selama fluktuasi kapasitas cluster.
Afinitas simpul khusus untuk kontrol penjadwalan granular
HyperPod Inferensi mendukung afinitas node khusus untuk mengontrol penempatan beban kerja di luar pemilihan tipe instance. Tentukan kriteria pemilihan simpul seperti distribusi zona ketersediaan, pemfilteran tipe kapasitas (sesuai permintaan vs. tempat), atau label node khusus melalui bidang. nodeAffinity Sistem ini mendukung batasan penempatan wajib menggunakan requiredDuringSchedulingIgnoredDuringExecution dan preferensi opsional melaluipreferredDuringSchedulingIgnoredDuringExecution, memberikan kontrol penuh atas keputusan penjadwalan pod sambil mempertahankan fleksibilitas penerapan.
catatan
Kami mengumpulkan metrik operasional rutin tertentu untuk menyediakan ketersediaan layanan penting. Pembuatan metrik ini sepenuhnya otomatis dan tidak melibatkan tinjauan manusia terhadap beban kerja inferensi model yang mendasarinya. Metrik ini terkait dengan operasi penyebaran, manajemen sumber daya, dan pendaftaran titik akhir.
