Aplikasi machine learning (ML) rumit untuk diterapkan dan sering kali memerlukan kemampuan untuk melakukan hyper-scale, dan memiliki persyaratan latensi sangat rendah serta anggaran biaya yang ketat. Kasus penggunaan seperti deteksi penipuan, rekomendasi produk, dan prediksi lalu lintas adalah contoh di mana milidetik penting dan sangat penting untuk kesuksesan bisnis. Perjanjian tingkat layanan (SLA) yang ketat harus dipenuhi, dan permintaan tipikal mungkin memerlukan beberapa langkah seperti prapemrosesan, transformasi data, rekayasa fitur, logika pemilihan model, agregasi model, dan pemrosesan pasca.
Men-deploy model ML dalam skala besar dengan biaya yang dioptimalkan dan efisiensi komputasi bisa menjadi tugas yang sulit dan rumit. Setiap model memiliki kelebihan dan ketergantungannya sendiri berdasarkan sumber data eksternal serta lingkungan runtime seperti kekuatan CPU/GPU dari sumber daya komputasi yang mendasarinya. Aplikasi mungkin memerlukan beberapa model ML untuk melayani satu permintaan inferensi. Dalam skenario tertentu, permintaan mungkin mengalir di beberapa model. Tidak ada pendekatan satu ukuran untuk semua, dan penting bagi praktisi ML untuk mencari metode yang telah dicoba dan terbukti untuk mengatasi tantangan hosting ML yang berulang. Hal ini menyebabkan evolusi pola desain untuk hosting model ML.
Dalam postingan ini, kami mengeksplorasi pola desain umum untuk membangun aplikasi ML Amazon SageMaker.
Pola desain untuk membangun aplikasi ML
Mari kita lihat pola desain berikut yang digunakan untuk menghosting aplikasi ML.
Aplikasi ML berbasis model tunggal
Ini adalah opsi yang bagus ketika kasus penggunaan ML Anda memerlukan satu model untuk melayani permintaan. Model diterapkan pada infrastruktur komputasi khusus dengan kemampuan untuk menskalakan berdasarkan lalu lintas input. Opsi ini juga ideal ketika aplikasi klien memiliki persyaratan inferensi latensi rendah (dalam urutan milidetik atau detik).
Aplikasi ML berbasis multi-model
Untuk membuat hosting lebih hemat biaya, pola desain ini memungkinkan Anda menghosting beberapa model pada infrastruktur penyewa yang sama. Beberapa model ML dapat berbagi sumber daya host atau penampung, termasuk menyimpan model ML yang paling sering digunakan dalam memori ke dalam cache, sehingga menghasilkan pemanfaatan memori dan sumber daya komputasi yang lebih baik. Bergantung pada jenis model yang Anda pilih untuk diterapkan, hosting bersama model dapat menggunakan metode berikut:
- Hosting multi-model โ Opsi ini memungkinkan Anda menghosting beberapa model menggunakan wadah penyajian bersama pada satu titik akhir. Fitur ini ideal jika Anda memiliki banyak model serupa yang dapat Anda sajikan melalui wadah penyajian bersama dan tidak perlu mengakses semua model pada saat yang bersamaan.
- Hosting multi-kontainer โ Opsi ini ideal jika Anda memiliki beberapa model yang berjalan di stack layanan yang berbeda dengan kebutuhan sumber daya yang sama, dan jika model individual tidak memiliki lalu lintas yang memadai untuk menggunakan kapasitas penuh dari instans titik akhir. Hosting multi-kontainer memungkinkan Anda menerapkan beberapa kontainer yang menggunakan model atau kerangka kerja berbeda pada satu titik akhir. Modelnya bisa benar-benar heterogen, dengan tumpukan penyajian independennya sendiri.
- Model ansambel โ Dalam banyak kasus penggunaan produksi, seringkali terdapat banyak model upstream yang memasukkan input ke model downstream tertentu. Di sinilah ansambel berguna. Pola ansambel melibatkan pencampuran keluaran dari satu atau lebih model dasar untuk mengurangi kesalahan generalisasi dari prediksi. Model dasar dapat beragam dan dilatih oleh algoritma yang berbeda. Ansambel model dapat mengungguli model tunggal karena kesalahan prediksi model berkurang ketika pendekatan ansambel digunakan.
Berikut ini adalah kasus penggunaan umum dari pola ansambel dan diagram pola desain yang sesuai:
- Sebarkan-kumpulkan โ Dalam pola scatter-gather, permintaan inferensi dialihkan ke sejumlah model. Agregator kemudian digunakan untuk mengumpulkan respons dan menyaringnya menjadi respons inferensi tunggal. Misalnya, kasus penggunaan klasifikasi gambar dapat menggunakan tiga model berbeda untuk melakukan tugas tersebut. Pola scatter-gather memungkinkan Anda menggabungkan hasil dari inferensi yang dijalankan pada tiga model berbeda dan memilih model klasifikasi yang paling memungkinkan.
- Model agregat โ Dalam pola agregasi, output dari beberapa model dirata-ratakan. Untuk model klasifikasi, prediksi beberapa model dievaluasi untuk menentukan kelas yang menerima suara terbanyak dan diperlakukan sebagai hasil akhir dari ansambel. Misalnya, dalam masalah klasifikasi dua kelas untuk mengklasifikasikan satu set buah sebagai jeruk atau apel, jika dua model memilih jeruk dan satu model memilih apel, maka hasil agregat akan menjadi jeruk. Agregasi membantu memerangi ketidakakuratan dalam model individual dan membuat output lebih akurat.
- Seleksi dinamis โ Pola lain untuk model ansambel adalah melakukan pemilihan model secara dinamis untuk atribut masukan yang diberikan. Misalnya, dalam input gambar buah tertentu, jika input berisi jeruk, model A akan digunakan karena dikhususkan untuk jeruk. Jika input berisi apel, model B akan digunakan karena dikhususkan untuk apel.
- Aplikasi ML inferensi serial โ Dengan pola inferensi serial, juga dikenal sebagai pipeline inferensi, kasus penggunaan memiliki persyaratan untuk melakukan praproses data yang masuk sebelum menjalankan model ML terlatih untuk membuat inferensi. Selain itu, dalam beberapa kasus, inferensi yang dihasilkan mungkin perlu diproses lebih lanjut, sehingga dapat dengan mudah digunakan oleh aplikasi hilir. Pipa inferensi memungkinkan Anda menggunakan kembali kode prapemrosesan yang sama yang digunakan selama pelatihan model untuk memproses data permintaan inferensi yang digunakan untuk prediksi.
- Logika bisnis โ Memproduksi ML selalu melibatkan logika bisnis. Pola logika bisnis melibatkan semua yang diperlukan untuk melakukan tugas ML yang bukan inferensi model ML. Ini termasuk memuat model dari Layanan Penyimpanan Sederhana Amazon (Amazon S3), misalnya, pencarian basis data untuk memvalidasi input, memperoleh fitur yang telah dihitung sebelumnya dari penyimpanan fitur, dan seterusnya. Setelah langkah-langkah logika bisnis ini selesai, input diteruskan ke model ML.
Opsi inferensi ML
Untuk penerapan model, penting untuk bekerja mundur dari kasus penggunaan Anda. Berapa frekuensi prediksi? Apakah Anda mengharapkan lalu lintas langsung ke aplikasi Anda dan respons waktu nyata ke klien Anda? Apakah Anda memiliki banyak model yang dilatih untuk subkumpulan data yang berbeda untuk kasus penggunaan yang sama? Apakah lalu lintas prediksi berfluktuasi? Apakah latensi inferensi menjadi perhatian? Berdasarkan perincian ini, semua pola desain sebelumnya dapat diimplementasikan menggunakan opsi penyebaran berikut:
- Inferensi waktu nyata โ Inferensi real-time ideal untuk beban kerja inferensi di mana Anda memiliki persyaratan real-time, interaktif, dan latensi rendah. Beban kerja inferensi ML real-time dapat mencakup aplikasi ML berbasis model tunggal, di mana aplikasi hanya memerlukan satu model ML untuk melayani satu permintaan, atau aplikasi ML berbasis multimodel, di mana aplikasi memerlukan beberapa model ML untuk melayani satu meminta.
- Inferensi hampir real-time (asinkron). โ Dengan inferensi waktu hampir nyata, Anda dapat mengantri permintaan masuk. Ini dapat digunakan untuk menjalankan inferensi pada input yang berukuran ratusan MB. Ini beroperasi dalam waktu hampir nyata dan memungkinkan pengguna untuk menggunakan input untuk inferensi, dan membaca output dari titik akhir dari bucket S3. Ini sangat berguna terutama dalam kasus dengan NLP dan visi komputer, di mana terdapat muatan besar yang memerlukan waktu pemrosesan awal yang lebih lama.
- Inferensi batch โ Inferensi batch dapat digunakan untuk menjalankan inferensi offline pada kumpulan data besar. Karena berjalan offline, inferensi batch tidak menawarkan latensi terendah. Di sini, permintaan inferensi diproses dengan pemicu terjadwal atau berbasis peristiwa dari tugas inferensi batch.
- Inferensi tanpa server โ Inferensi tanpa server ideal untuk beban kerja yang memiliki periode tidak aktif di antara lonjakan lalu lintas dan dapat mentolerir latensi beberapa detik ekstra (cold start) untuk pemanggilan pertama setelah periode tidak aktif. Misalnya, layanan chatbot atau aplikasi untuk mengolah formulir atau menganalisis data dari dokumen. Dalam hal ini, Anda mungkin menginginkan opsi inferensi online yang dapat secara otomatis menyediakan dan menskalakan kapasitas komputasi berdasarkan volume permintaan inferensi. Dan selama waktu idle, itu harus dapat mematikan kapasitas komputasi sepenuhnya sehingga Anda tidak dikenakan biaya. Inferensi tanpa server menghilangkan beban berat yang tidak dapat dibedakan dalam memilih dan mengelola server dengan meluncurkan sumber daya komputasi secara otomatis dan menskalakannya masuk dan keluar tergantung pada lalu lintas.
Gunakan fungsi kebugaran untuk memilih opsi inferensi ML yang tepat
Memutuskan opsi hosting yang tepat itu penting karena berdampak pada pengguna akhir yang dirender oleh aplikasi Anda. Untuk tujuan ini, kami meminjam konsep fungsi kebugaran, yang diciptakan oleh Neal Ford dan rekannya dari AWS Partner ThoughtWorks dalam pekerjaan mereka Membangun Arsitektur Evolusioner. Fungsi kebugaran memberikan penilaian preskriptif dari berbagai opsi hosting berdasarkan tujuan pelanggan. Fungsi kebugaran membantu Anda mendapatkan data yang diperlukan untuk memungkinkan evolusi terencana arsitektur Anda. Mereka menetapkan nilai terukur untuk menilai seberapa dekat solusi Anda dengan pencapaian tujuan yang Anda tetapkan. Fungsi kebugaran dapat dan harus diadaptasi seiring perkembangan arsitektur untuk memandu proses perubahan yang diinginkan. Ini memberi arsitek alat untuk memandu tim mereka sambil mempertahankan otonomi tim.
Ada lima fungsi kebugaran utama yang menjadi perhatian pelanggan saat memilih opsi inferensi ML yang tepat untuk menghosting model dan aplikasi ML mereka.
Fungsi kebugaran | Deskripsi Produk |
Biaya |
Menerapkan dan memelihara model ML dan aplikasi ML pada kerangka kerja yang dapat diskalakan adalah proses bisnis yang penting, dan biayanya dapat sangat bervariasi tergantung pada pilihan yang dibuat tentang infrastruktur hosting model, opsi hosting, kerangka kerja ML, karakteristik model ML, pengoptimalan, kebijakan penskalaan, dan banyak lagi. Beban kerja harus memanfaatkan infrastruktur perangkat keras secara optimal untuk memastikan bahwa biaya tetap terkendali. Fungsi kebugaran ini secara khusus mengacu pada biaya infrastruktur, yang merupakan bagian dari total biaya kepemilikan (TCO) keseluruhan. Biaya infrastruktur adalah biaya gabungan untuk penyimpanan, jaringan, dan komputasi. Penting juga untuk memahami komponen TCO lainnya, termasuk biaya operasional dan biaya keamanan dan kepatuhan. Biaya operasional adalah gabungan biaya pengoperasian, pemantauan, dan pemeliharaan infrastruktur ML. Biaya operasional dihitung sebagai jumlah insinyur yang dibutuhkan berdasarkan setiap skenario dan gaji tahunan insinyur, yang dikumpulkan selama periode tertentu. Pelanggan yang menggunakan solusi ML yang dikelola sendiri di Cloud komputasi elastis Amazon (Amazon EC2), Layanan Kontainer Amazon Elastic (Amazon ECS), dan Layanan Amazon Elastic Kubernetes (Amazon EKS) perlu membangun sendiri peralatan operasional. Pelanggan yang menggunakan SageMaker dikenakan TCO yang jauh lebih sedikit. Inferensi SageMaker adalah layanan yang terkelola sepenuhnya dan memberikan kemampuan siap pakai untuk menerapkan model ML untuk inferensi. Anda tidak perlu menyediakan instans, memantau kesehatan instans, mengelola update atau patch keamanan, mengeluarkan metrik operasional, atau membangun pemantauan untuk beban kerja inferensi ML Anda. Ini memiliki kemampuan bawaan untuk memastikan ketersediaan dan ketahanan yang tinggi. SageMaker mendukung keamanan dengan enkripsi end-to-end saat istirahat dan transit, termasuk enkripsi volume root dan Toko Blok Elastis Amazon volume (Amazon EBS), Cloud Pribadi Virtual Amazon dukungan (Amazon VPC), Tautan Pribadi AWS, kunci yang dikelola pelanggan, Identitas AWS dan Manajemen Akses (IAM) kontrol akses berbutir halus, AWS CloudTrail audit, enkripsi internode untuk pelatihan, kontrol akses berbasis tag, isolasi jaringan, dan Proksi Aplikasi Interaktif. Semua fitur keamanan ini disediakan di luar kotak di SageMaker, dan dapat menghemat puluhan bulan upaya pengembangan bisnis selama periode 3 tahun. SageMaker adalah layanan yang memenuhi syarat HIPAA, dan disertifikasi berdasarkan PCI, SOC, GDPR, dan ISO. SageMaker juga mendukung titik akhir FIPS. Untuk informasi lebih lanjut tentang TCO, lihat Total biaya kepemilikan Amazon SageMaker. |
Latensi inferensi | Banyak model dan aplikasi ML sangat kritis terhadap latensi, di mana latensi inferensi harus berada dalam batas yang ditentukan oleh tujuan tingkat layanan. Latensi inferensi bergantung pada banyak faktor, termasuk ukuran dan kompleksitas model, platform perangkat keras, lingkungan perangkat lunak, dan arsitektur jaringan. Misalnya, model yang lebih besar dan lebih kompleks membutuhkan waktu lebih lama untuk menjalankan inferensi. |
Throughput (transaksi per detik) | Untuk inferensi model, pengoptimalan throughput sangat penting untuk penyempurnaan kinerja dan pencapaian tujuan bisnis aplikasi ML. Karena kami terus maju dengan cepat dalam semua aspek ML, termasuk implementasi operasi matematika tingkat rendah dalam desain chip, pustaka khusus perangkat keras memainkan peran yang lebih besar dalam pengoptimalan kinerja. Berbagai faktor seperti ukuran muatan, lompatan jaringan, sifat lompatan, fitur grafik model, operator dalam model, serta profil CPU, GPU, dan memori dari instance hosting model memengaruhi throughput model ML. |
Kompleksitas konfigurasi penskalaan | Sangat penting bagi model atau aplikasi ML untuk berjalan pada kerangka kerja yang dapat diskalakan yang dapat menangani permintaan lalu lintas yang bervariasi. Ini juga memungkinkan penggunaan maksimum sumber daya CPU dan GPU dan mencegah penyediaan sumber daya komputasi yang berlebihan. |
Pola lalu lintas yang diharapkan | Model atau aplikasi ML dapat memiliki pola lalu lintas yang berbeda, mulai dari lalu lintas langsung real-time berkelanjutan hingga puncak ribuan permintaan per detik secara berkala, dan dari pola permintaan yang jarang dan tidak dapat diprediksi hingga permintaan batch offline pada kumpulan data yang lebih besar. Bekerja mundur dari pola lalu lintas yang diharapkan disarankan untuk memilih opsi hosting yang tepat untuk model ML Anda. |
Menerapkan model dengan SageMaker
SageMaker adalah layanan AWS yang dikelola sepenuhnya yang memberi setiap pengembang dan ilmuwan data kemampuan untuk dengan cepat membangun, melatih, dan menerapkan model ML dalam skala besar. Dengan inferensi SageMaker, Anda dapat menerapkan model ML pada titik akhir yang dihosting dan mendapatkan hasil inferensi. SageMaker menyediakan berbagai pilihan perangkat keras dan fitur untuk memenuhi kebutuhan beban kerja Anda, memungkinkan Anda memilih lebih dari 70 jenis instans dengan akselerasi perangkat keras. SageMaker juga dapat memberikan rekomendasi jenis instans inferensi menggunakan fitur baru bernama SageMaker Inference Recommender, jika Anda tidak yakin mana yang paling optimal untuk beban kerja Anda.
Anda dapat memilih opsi penerapan untuk memenuhi kasus penggunaan Anda dengan sebaik-baiknya, seperti inferensi waktu nyata, asinkron, batch, dan bahkan titik akhir tanpa server. Selain itu, SageMaker menawarkan berbagai strategi penerapan seperti canary, biru hijau, bayangan, dan pengujian A/B untuk penerapan model, bersama penerapan hemat biaya dengan titik akhir multimodel, multikontainer, dan penskalaan elastis. Dengan inferensi SageMaker, Anda dapat melihat metrik kinerja untuk titik akhir Anda amazoncloudwatch, skala titik akhir secara otomatis berdasarkan lalu lintas, dan perbarui model Anda dalam produksi tanpa kehilangan ketersediaan apa pun.
SageMaker menawarkan empat opsi untuk menerapkan model Anda sehingga Anda dapat mulai membuat prediksi:
- Inferensi waktu nyata โ Ini cocok untuk beban kerja dengan persyaratan latensi milidetik, ukuran muatan hingga 6 MB, dan waktu pemrosesan hingga 60 detik.
- Transformasi batch โ Ini sangat ideal untuk prediksi offline pada sejumlah besar data yang tersedia di muka.
- Inferensi asinkron โ Ini dirancang untuk beban kerja yang tidak memiliki persyaratan latensi sub-detik, ukuran muatan hingga 1 GB, dan waktu pemrosesan hingga 15 menit.
- Inferensi tanpa server โ Dengan inferensi tanpa server, Anda dapat menerapkan model ML dengan cepat untuk inferensi tanpa harus mengonfigurasi atau mengelola infrastruktur yang mendasarinya. Selain itu, Anda hanya membayar kapasitas komputasi yang digunakan untuk memproses permintaan inferensi, yang ideal untuk beban kerja intermiten.
Diagram berikut dapat membantu Anda memahami opsi penerapan model hosting SageMaker bersama dengan evaluasi fungsi kebugaran terkait.
Mari jelajahi setiap opsi penerapan secara lebih mendetail.
Inferensi waktu nyata di SageMaker
Inferensi real-time SageMaker direkomendasikan jika Anda memiliki lalu lintas berkelanjutan dan memerlukan latensi yang lebih rendah dan konsisten untuk permintaan Anda dengan ukuran payload hingga 6 MB, dan waktu pemrosesan hingga 60 detik. Anda menerapkan model Anda ke layanan hosting SageMaker dan mendapatkan titik akhir yang dapat digunakan untuk inferensi. Titik akhir ini dikelola sepenuhnya dan mendukung penskalaan otomatis. Inferensi real-time populer untuk kasus penggunaan saat Anda mengharapkan respons latensi rendah dan sinkron dengan pola lalu lintas yang dapat diprediksi, seperti rekomendasi yang dipersonalisasi untuk produk dan layanan atau kasus penggunaan deteksi penipuan transaksional.
Biasanya, aplikasi klien mengirimkan permintaan ke titik akhir HTTPS SageMaker untuk mendapatkan inferensi dari model yang diterapkan. Anda dapat menerapkan beberapa varian model ke titik akhir HTTPS SageMaker yang sama. Ini berguna untuk menguji variasi model dalam produksi. Penskalaan otomatis memungkinkan Anda menyesuaikan secara dinamis jumlah instans yang disediakan untuk model sebagai respons terhadap perubahan beban kerja Anda.
Tabel berikut memberikan panduan untuk mengevaluasi inferensi real-time SageMaker berdasarkan fungsi kebugaran.
Fungsi kebugaran | Deskripsi Produk |
Biaya |
Titik akhir real-time menawarkan respons sinkron terhadap permintaan inferensi. Karena titik akhir selalu berjalan dan tersedia untuk memberikan respons inferensi sinkron waktu nyata, Anda membayar untuk menggunakan instans. Biaya dapat bertambah dengan cepat saat Anda menerapkan beberapa titik akhir, terutama jika titik akhir tidak sepenuhnya memanfaatkan instans yang mendasarinya. Memilih instans yang tepat untuk model Anda membantu memastikan Anda memiliki instans berperforma terbaik dengan biaya terendah untuk model Anda. Penskalaan otomatis disarankan untuk menyesuaikan kapasitas secara dinamis bergantung pada lalu lintas untuk mempertahankan kinerja yang stabil dan dapat diprediksi dengan biaya serendah mungkin. SageMaker memperluas akses ke keluarga instans ML berbasis Graviton2 dan Graviton3. Graviton AWS prosesor dibuat khusus oleh Amazon Web Services menggunakan inti Arm Neoverse 64-bit untuk memberikan kinerja harga terbaik untuk beban kerja cloud Anda yang berjalan di Amazon EC2. Dengan instans berbasis Graviton, Anda memiliki lebih banyak opsi untuk mengoptimalkan biaya dan performa saat menerapkan model ML di SageMaker. SageMaker juga mendukung Instans Inf1, memberikan inferensi ML berperforma tinggi dan hemat biaya. Dengan 1โ16 Chip AWS Inferentia per instans, instans Inf1 dapat menskalakan kinerja dan memberikan throughput hingga tiga kali lebih tinggi dan biaya per inferensi hingga 50% lebih rendah dibandingkan dengan instans berbasis GPU AWS. Untuk menggunakan instans Inf1 di SageMaker, Anda dapat mengompilasi model terlatih menggunakan Amazon SageMaker Neo dan pilih instans Inf1 untuk menerapkan model terkompilasi di SageMaker. Anda juga dapat menjelajahi Paket Hemat untuk SageMaker untuk mendapatkan keuntungan dari penghematan biaya hingga 64% dibandingkan dengan harga on-demand. Saat Anda membuat titik akhir, SageMaker melampirkan volume penyimpanan EBS ke setiap instans komputasi ML yang menghosting titik akhir. Ukuran volume penyimpanan bergantung pada jenis instans. Biaya tambahan untuk titik akhir real-time mencakup biaya GB per bulan penyimpanan yang disediakan, ditambah data GB yang diproses di dalam dan data GB yang diproses di luar instans titik akhir. |
Latensi inferensi | Inferensi real-time ideal saat Anda memerlukan titik akhir persisten dengan persyaratan latensi milidetik. Ini mendukung ukuran muatan hingga 6 MB, dan waktu pemrosesan hingga 60 detik. |
Throughput |
Nilai ideal throughput inferensi bersifat subyektif terhadap faktor-faktor seperti model, ukuran input model, ukuran batch, dan jenis instans titik akhir. Sebagai praktik terbaik, tinjau metrik CloudWatch untuk permintaan input dan pemanfaatan sumber daya, dan pilih jenis instans yang sesuai untuk mencapai throughput yang optimal. Aplikasi bisnis dapat dioptimalkan melalui throughput atau dioptimalkan latensi. Misalnya, pengelompokan dinamis dapat membantu meningkatkan throughput untuk aplikasi yang sensitif terhadap latensi menggunakan inferensi real-time. Namun, ada batasan untuk ukuran batch, yang tanpanya latensi inferensi dapat terpengaruh. Latensi inferensi akan meningkat saat Anda meningkatkan ukuran batch untuk meningkatkan throughput. Oleh karena itu, inferensi real-time merupakan opsi ideal untuk aplikasi yang sensitif terhadap latensi. SageMaker menyediakan opsi inferensi asinkron dan transformasi batch, yang dioptimalkan untuk memberikan throughput yang lebih tinggi dibandingkan dengan inferensi real-time jika aplikasi bisnis dapat mentolerir latensi yang sedikit lebih tinggi. |
Kompleksitas konfigurasi penskalaan |
Dukungan titik akhir waktu nyata SageMaker penskalaan otomatis keluar dari kotak. Saat beban kerja meningkat, penskalaan otomatis membuat lebih banyak instans online. Saat beban kerja berkurang, penskalaan otomatis menghapus instans yang tidak perlu, membantu Anda mengurangi biaya komputasi. Tanpa penskalaan otomatis, Anda perlu menyediakan lalu lintas puncak atau ketidaktersediaan model risiko. Kecuali lalu lintas ke model Anda stabil sepanjang hari, akan ada kelebihan kapasitas yang tidak terpakai. Hal ini menyebabkan rendahnya pemanfaatan dan pemborosan sumber daya. Dengan SageMaker, Anda dapat mengonfigurasi berbagai opsi penskalaan berdasarkan pola lalu lintas yang diharapkan. Penskalaan sederhana atau penskalaan pelacakan target ideal saat Anda ingin menskalakan berdasarkan metrik CloudWatch tertentu. Anda dapat melakukannya dengan memilih metrik tertentu dan menyetel nilai ambang batas. Metrik yang disarankan untuk opsi ini rata-rata Jika memerlukan konfigurasi lanjutan, Anda dapat menyetel kebijakan penskalaan bertahap untuk secara dinamis menyesuaikan jumlah instans yang akan diskalakan berdasarkan ukuran pelanggaran alarm. Ini membantu Anda mengonfigurasi respons yang lebih agresif saat permintaan mencapai tingkat tertentu. Anda dapat menggunakan opsi penskalaan terjadwal saat Anda mengetahui bahwa permintaan mengikuti jadwal tertentu pada hari, minggu, bulan, atau tahun. Ini membantu Anda menentukan jadwal satu kali atau jadwal berulang atau ekspresi cron bersama dengan waktu mulai dan berakhir, yang membentuk batas kapan tindakan penskalaan otomatis dimulai dan berhenti. Untuk lebih jelasnya, lihat Mengonfigurasi titik akhir inferensi penskalaan otomatis di Amazon SageMaker dan Muat uji dan optimalkan titik akhir Amazon SageMaker menggunakan penskalaan otomatis. |
Pola lalu lintas | Inferensi real-time ideal untuk beban kerja dengan pola lalu lintas yang berkelanjutan atau teratur. |
Inferensi asinkron di SageMaker
Inferensi asinkron SageMaker adalah kemampuan baru di SageMaker yang mengantrikan permintaan masuk dan memprosesnya secara asinkron. Opsi ini ideal untuk permintaan dengan ukuran payload yang besar (hingga 1 GB), waktu pemrosesan yang lama (hingga 15 menit), dan persyaratan latensi hampir real-time. Contoh beban kerja untuk inferensi asinkron mencakup perusahaan layanan kesehatan yang memproses gambar atau video biomedis beresolusi tinggi seperti ekokardiogram untuk mendeteksi anomali. Aplikasi ini menerima semburan lalu lintas masuk pada waktu yang berbeda dalam satu hari dan memerlukan pemrosesan hampir waktu nyata dengan biaya rendah. Waktu pemrosesan untuk permintaan ini dapat berkisar dalam urutan menit, menghilangkan kebutuhan untuk menjalankan inferensi real-time. Alih-alih, muatan input dapat diproses secara asinkron dari penyimpanan objek seperti Amazon S3 dengan antrean otomatis dan ambang konkurensi yang ditentukan sebelumnya. Setelah diproses, SageMaker menempatkan respons inferensi di lokasi Amazon S3 yang dikembalikan sebelumnya. Secara opsional, Anda dapat memilih untuk menerima pemberitahuan keberhasilan atau kesalahan melalui Layanan Pemberitahuan Sederhana Amazon (Amazon SNS).
Tabel berikut memberikan panduan untuk mengevaluasi inferensi asinkron SageMaker berdasarkan fungsi kebugaran.
Fungsi kebugaran | Deskripsi Produk |
Biaya | Inferensi asinkron adalah pilihan tepat untuk beban kerja sensitif biaya dengan muatan besar dan lalu lintas yang meledak. Inferensi asinkron memungkinkan Anda menghemat biaya dengan otomatis menskalakan jumlah instans ke nol saat tidak ada permintaan untuk diproses, sehingga Anda hanya membayar saat titik akhir memproses permintaan. Permintaan yang diterima saat tidak ada instans akan diantrekan untuk diproses setelah titik akhir ditingkatkan. |
Latensi inferensi | Inferensi asinkron ideal untuk kebutuhan latensi hampir real-time. Permintaan ditempatkan dalam antrean dan diproses segera setelah komputasi tersedia. Ini biasanya menghasilkan latensi puluhan milidetik. |
Throughput | Inferensi asinkron ideal untuk kasus penggunaan yang tidak sensitif latensi, karena aplikasi tidak harus berkompromi pada throughput. Permintaan tidak dibatalkan selama lonjakan lalu lintas karena titik akhir inferensi asinkron mengantri permintaan, bukan menjatuhkannya. |
Kompleksitas konfigurasi penskalaan |
Dukungan SageMaker penskalaan otomatis untuk titik akhir asinkron. Tidak seperti endpoint yang dihosting secara real-time, endpoint inferensi asinkron mendukung penurunan skala instance menjadi nol dengan menyetel kapasitas minimum ke nol. Untuk titik akhir asinkron, SageMaker sangat menyarankan agar Anda membuat konfigurasi kebijakan untuk penskalaan pelacakan target untuk model (varian) yang diterapkan. Untuk kasus penggunaan yang dapat mentolerir pinalti cold start beberapa menit, Anda dapat secara opsional menurunkan jumlah instans titik akhir menjadi nol saat tidak ada permintaan yang belum diselesaikan dan menskalakan cadangan saat permintaan baru tiba sehingga Anda hanya membayar untuk durasi yang titik akhir secara aktif memproses permintaan. |
Pola lalu lintas | Titik akhir asinkron mengantri permintaan masuk dan memprosesnya secara asinkron. Mereka adalah opsi yang bagus untuk pola lalu lintas yang terputus-putus atau jarang. |
Inferensi batch di SageMaker
Transformasi batch SageMaker ideal untuk prediksi offline pada kumpulan data besar yang tersedia di awal. Fitur transformasi batch adalah metode performa tinggi dan throughput tinggi untuk mengubah data dan menghasilkan inferensi. Ini ideal untuk skenario di mana Anda berurusan dengan kumpulan data yang besar, tidak memerlukan latensi subdetik, atau perlu melakukan praproses dan mengubah data pelatihan. Pelanggan di domain tertentu seperti periklanan dan pemasaran atau layanan kesehatan sering kali perlu membuat prediksi offline pada kumpulan data hiperskala di mana throughput tinggi sering kali menjadi tujuan kasus penggunaan dan latensi tidak menjadi perhatian.
Saat tugas transformasi batch dimulai, SageMaker menginisialisasi instance komputasi dan mendistribusikan beban kerja inferensi di antaranya. Ini melepaskan sumber daya saat pekerjaan selesai, jadi Anda hanya membayar apa yang digunakan selama menjalankan pekerjaan Anda. Saat tugas selesai, SageMaker menyimpan hasil prediksi di bucket S3 yang Anda tentukan. Tugas inferensi batch biasanya merupakan kandidat yang baik untuk penskalaan horizontal. Setiap pekerja dalam cluster dapat beroperasi pada subset data yang berbeda tanpa perlu bertukar informasi dengan pekerja lain. AWS menawarkan beberapa opsi penyimpanan dan komputasi yang memungkinkan penskalaan horizontal. Contoh beban kerja untuk transformasi batch SageMaker mencakup aplikasi offline seperti aplikasi perbankan untuk memprediksi churn pelanggan tempat pekerjaan offline dapat dijadwalkan untuk dijalankan secara berkala.
Tabel berikut memberikan panduan untuk mengevaluasi transformasi batch SageMaker berdasarkan fungsi kebugaran.
Fungsi kebugaran | Deskripsi Produk |
Biaya | Transformasi batch SageMaker memungkinkan Anda menjalankan prediksi pada set data batch besar atau kecil. Anda dikenai biaya untuk jenis instans yang Anda pilih, berdasarkan durasi penggunaan. SageMaker mengelola penyediaan sumber daya di awal tugas dan melepaskannya saat tugas selesai. Tidak ada biaya pemrosesan data tambahan. |
Latensi inferensi | Anda dapat menggunakan pemanggilan berbasis acara atau terjadwal. Latensi dapat bervariasi bergantung pada ukuran data inferensi, konkurensi tugas, kompleksitas model, dan kapasitas instans komputasi. |
Throughput |
Pekerjaan transformasi batch dapat dilakukan pada berbagai kumpulan data, dari data berukuran petabyte hingga kumpulan data yang sangat kecil. Tidak perlu mengubah ukuran kumpulan data yang lebih besar menjadi potongan data yang kecil. Anda dapat mempercepat tugas transformasi batch dengan menggunakan nilai optimal untuk parameter seperti MaxPayloadInMB, MaxConcurrentTransforms, atau Strategi Batch. Nilai ideal untuk Pemrosesan batch dapat meningkatkan throughput dan mengoptimalkan sumber daya Anda karena membantu menyelesaikan lebih banyak inferensi dalam jumlah waktu tertentu dengan mengorbankan latensi. Untuk mengoptimalkan penerapan model untuk throughput yang lebih tinggi, pedoman umumnya adalah meningkatkan ukuran batch hingga throughput menurun. |
Kompleksitas konfigurasi penskalaan | Transformasi batch SageMaker digunakan untuk inferensi offline yang tidak sensitif terhadap latensi. |
Pola lalu lintas | Untuk inferensi offline, tugas transformasi batch dijadwalkan atau dimulai menggunakan pemicu berbasis peristiwa. |
Inferensi tanpa server di SageMaker
Inferensi tanpa server SageMaker memungkinkan Anda menerapkan model ML untuk inferensi tanpa harus mengonfigurasi atau mengelola infrastruktur yang mendasarinya. Berdasarkan volume permintaan inferensi yang diterima model Anda, inferensi tanpa server SageMaker secara otomatis menyediakan, menskalakan, dan mematikan kapasitas komputasi. Akibatnya, Anda hanya membayar waktu komputasi untuk menjalankan kode inferensi dan jumlah data yang diproses, bukan untuk waktu diam. Anda dapat menggunakan algoritme bawaan SageMaker dan wadah yang melayani kerangka kerja ML untuk menerapkan model Anda ke titik akhir inferensi tanpa server atau memilih untuk membawa wadah Anda sendiri. Jika lalu lintas menjadi dapat diprediksi dan stabil, Anda dapat dengan mudah memperbarui dari titik akhir inferensi tanpa server ke titik akhir waktu-nyata SageMaker tanpa perlu melakukan perubahan pada citra penampung Anda. Dengan inferensi tanpa server, Anda juga mendapat manfaat dari fitur SageMaker lainnya, termasuk metrik bawaan seperti jumlah pemanggilan, kesalahan, latensi, metrik host, dan kesalahan di CloudWatch.
Tabel berikut memberikan panduan untuk mengevaluasi inferensi tanpa server SageMaker berdasarkan fungsi kebugaran.
Fungsi kebugaran | Deskripsi Produk |
Biaya | Dengan model bayar sesuai penggunaan, inferensi tanpa server adalah opsi hemat biaya jika Anda memiliki pola lalu lintas yang jarang atau terputus-putus. Anda hanya membayar selama durasi titik akhir memproses permintaan, dan karenanya dapat menghemat biaya jika pola lalu lintas terputus-putus. |
Latensi inferensi |
Titik akhir tanpa server menawarkan latensi inferensi rendah (dalam urutan milidetik hingga detik), dengan kemampuan untuk menskalakan secara instan dari puluhan hingga ribuan inferensi dalam hitungan detik berdasarkan pola penggunaan, membuatnya ideal untuk aplikasi ML dengan lalu lintas yang terputus-putus atau tidak dapat diprediksi. Karena endpoint tanpa server menyediakan resource komputasi sesuai permintaan, endpoint Anda mungkin mengalami latensi beberapa detik tambahan (cold start) untuk pemanggilan pertama setelah periode nonaktif. Waktu mulai dingin bergantung pada ukuran model Anda, berapa lama untuk mengunduh model Anda, dan waktu mulai penampung Anda. |
Throughput | Saat mengonfigurasi titik akhir tanpa server, Anda dapat menentukan ukuran memori dan jumlah maksimum pemanggilan bersamaan. Inferensi tanpa server SageMaker secara otomatis menetapkan sumber daya komputasi sebanding dengan memori yang Anda pilih. Jika Anda memilih ukuran memori yang lebih besar, penampung Anda memiliki akses ke lebih banyak vCPU. Sebagai aturan umum, ukuran memori setidaknya harus sebesar ukuran model Anda. Ukuran memori yang bisa Anda pilih adalah 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB, dan 6144 MB. Berapa pun ukuran memori yang Anda pilih, titik akhir tanpa server memiliki penyimpanan disk singkat sebesar 5 GB. |
Kompleksitas konfigurasi penskalaan | Titik akhir tanpa server secara otomatis meluncurkan sumber daya komputasi dan menskalakannya masuk dan keluar tergantung pada lalu lintas, sehingga tidak perlu memilih jenis instans atau mengelola kebijakan penskalaan. Ini menghilangkan beban berat dalam memilih dan mengelola server. |
Pola lalu lintas | Inferensi tanpa server ideal untuk beban kerja dengan pola lalu lintas yang jarang atau terputus-putus. |
Buat model pola desain hosting di SageMaker
Titik akhir inferensi SageMaker menggunakan wadah Docker untuk menghosting model ML. Wadah memungkinkan Anda mengemas perangkat lunak ke dalam unit standar yang berjalan secara konsisten pada platform apa pun yang mendukung Docker. Hal ini memastikan portabilitas lintas platform, penerapan infrastruktur yang tidak dapat diubah, dan manajemen perubahan serta implementasi CI/CD yang lebih mudah. SageMaker menyediakan kontainer terkelola siap pakai untuk kerangka kerja populer seperti Apache MXNet, TensorFlow, PyTorch, Sklearn, dan Hugging Face. Untuk daftar lengkap image container SageMaker yang tersedia, lihat Tersedia Gambar Deep Learning Containers. Jika SageMaker tidak memiliki wadah yang didukung, Anda juga dapat membangun wadah Anda sendiri (BYOC) dan mendorong citra kustom Anda sendiri, menginstal dependensi yang diperlukan untuk model Anda.
Untuk menerapkan model di SageMaker, Anda memerlukan wadah (wadah kerangka kerja terkelola SageMaker atau BYOC) dan instans komputasi untuk menghosting wadah. SageMaker mendukung beberapa opsi lanjutan untuk pola desain hosting model ML umum di mana model dapat dihosting di satu penampung atau dihosting bersama di penampung bersama.
Aplikasi ML real-time dapat menggunakan satu model atau beberapa model untuk melayani satu permintaan prediksi. Diagram berikut menampilkan berbagai skenario inferensi untuk aplikasi ML.
Mari jelajahi opsi hosting SageMaker yang cocok untuk setiap skenario inferensi sebelumnya. Anda dapat merujuk ke fungsi kebugaran untuk menilai apakah itu opsi yang tepat untuk kasus penggunaan tertentu.
Hosting aplikasi ML berbasis model tunggal
Ada beberapa opsi untuk menghosting aplikasi ML berbasis model tunggal menggunakan layanan hosting SageMaker bergantung pada skenario penerapan.
Titik akhir model tunggal
Titik akhir model tunggal SageMaker memungkinkan Anda menghosting satu model pada wadah yang dihosting pada instans khusus untuk latensi rendah dan throughput tinggi. Titik akhir ini dikelola sepenuhnya dan mendukung penskalaan otomatis. Anda dapat mengonfigurasi titik akhir model tunggal sebagai titik akhir yang disediakan tempat Anda meneruskan konfigurasi infrastruktur titik akhir seperti jenis dan jumlah instans, atau titik akhir tanpa server tempat SageMaker secara otomatis meluncurkan sumber daya komputasi dan menskalakannya masuk dan keluar tergantung pada lalu lintas, menghilangkan kebutuhan untuk memilih jenis instans atau mengelola kebijakan penskalaan. Titik akhir tanpa server adalah untuk aplikasi dengan lalu lintas yang terputus-putus atau tidak dapat diprediksi.
Diagram berikut menunjukkan skenario inferensi titik akhir model tunggal.
Tabel berikut memberikan panduan untuk mengevaluasi fungsi kesesuaian untuk titik akhir model tunggal yang disediakan. Untuk evaluasi fungsi kebugaran titik akhir tanpa server, lihat bagian titik akhir tanpa server di postingan ini.
Fungsi kebugaran | Deskripsi Produk |
Biaya | Anda dikenai biaya untuk penggunaan jenis instans yang Anda pilih. Karena titik akhir selalu berjalan dan tersedia, biaya dapat bertambah dengan cepat. Memilih instans yang tepat untuk model Anda membantu memastikan Anda memiliki instans berperforma terbaik dengan biaya terendah untuk model Anda. Penskalaan otomatis disarankan untuk menyesuaikan kapasitas secara dinamis bergantung pada lalu lintas untuk mempertahankan kinerja yang stabil dan dapat diprediksi dengan biaya serendah mungkin. |
Latensi inferensi | Titik akhir model tunggal menyediakan inferensi waktu-nyata, interaktif, dan sinkron dengan persyaratan latensi milidetik. |
Throughput | Throughput dapat dipengaruhi oleh berbagai faktor, seperti ukuran input model, ukuran batch, jenis instance endpoint, dan sebagainya. Direkomendasikan untuk meninjau metrik CloudWatch untuk permintaan input dan pemanfaatan sumber daya, dan memilih jenis instans yang sesuai untuk mencapai throughput yang optimal. SageMaker menyediakan fitur untuk mengelola sumber daya dan mengoptimalkan performa inferensi saat menerapkan model ML. Kamu bisa optimalkan kinerja model menggunakan Neo, atau gunakan instans Inf1 untuk throughput yang lebih baik dari model yang dihosting SageMaker menggunakan instans GPU untuk titik akhir Anda. |
Kompleksitas konfigurasi penskalaan | Penskalaan otomatis didukung di luar kotak. SageMaker merekomendasikan untuk memilih yang sesuai konfigurasi penskalaan dengan melakukan tes beban. |
Pola lalu lintas | Titik akhir model tunggal ideal untuk beban kerja dengan pola lalu lintas yang dapat diprediksi. |
Co-hosting beberapa model
Saat Anda berurusan dengan sejumlah besar model, menerapkan masing-masing pada titik akhir individu dengan wadah dan instans khusus dapat menghasilkan peningkatan biaya yang signifikan. Selain itu, juga menjadi sulit untuk mengelola begitu banyak model dalam produksi, khususnya ketika Anda tidak perlu memanggil semua model pada saat yang sama tetapi tetap membutuhkannya untuk tersedia setiap saat. Menghosting bersama beberapa model pada sumber daya komputasi dasar yang sama memudahkan pengelolaan penerapan ML dalam skala besar dan menurunkan biaya hosting melalui peningkatan penggunaan titik akhir dan sumber daya komputasi dasarnya. SageMaker mendukung opsi co-hosting model lanjutan seperti multi-model endpoint (MME) untuk model homogen dan multi-container endpoint (MCE) untuk model heterogen. Model homogen menggunakan framework ML yang sama pada wadah layanan bersama, sedangkan model heterogen memungkinkan Anda menerapkan beberapa wadah penyajian yang menggunakan model atau kerangka kerja berbeda pada satu titik akhir.
Diagram berikut menampilkan opsi hosting bersama model menggunakan SageMaker.
Titik akhir multi-model SageMaker
SageMaker MME memungkinkan Anda menghosting beberapa model menggunakan wadah penyajian bersama pada satu titik akhir. Ini adalah solusi yang dapat diskalakan dan hemat biaya untuk menerapkan sejumlah besar model yang memenuhi kasus penggunaan, kerangka kerja, atau logika inferensi yang sama. MME dapat secara dinamis melayani permintaan berdasarkan model yang dipanggil oleh penelepon. Ini juga mengurangi overhead penerapan karena SageMaker mengelola pemuatan model dalam memori dan menskalakannya berdasarkan pola lalu lintas ke model tersebut. Fitur ini ideal jika Anda memiliki banyak model serupa yang dapat Anda sajikan melalui wadah penyajian bersama dan tidak perlu mengakses semua model pada saat yang bersamaan. Titik akhir multi-model juga memungkinkan pembagian waktu sumber daya memori di seluruh model Anda. Ini bekerja paling baik ketika model cukup mirip dalam ukuran dan latensi pemanggilan, memungkinkan MME untuk secara efektif menggunakan instans di semua model. MME SageMaker mendukung hosting model yang didukung CPU dan GPU. Dengan menggunakan model yang didukung GPU, Anda dapat menurunkan biaya penerapan model melalui peningkatan penggunaan titik akhir dan instans komputasi terakselerasi yang mendasarinya. Untuk kasus penggunaan MME di dunia nyata, lihat Cara menskalakan inferensi pembelajaran mesin untuk kasus penggunaan SaaS multi-penyewa.
Tabel berikut memberikan panduan untuk mengevaluasi fungsi kebugaran untuk MME.
Fungsi kebugaran | Deskripsi Produk |
Biaya |
MME mengaktifkan penggunaan wadah penyajian bersama untuk menghosting ribuan model pada satu titik akhir. Ini mengurangi biaya hosting secara signifikan dengan meningkatkan pemanfaatan titik akhir dibandingkan dengan menggunakan titik akhir model tunggal. Misalnya, jika Anda memiliki 10 model untuk diterapkan menggunakan instans ml.c5.large, berdasarkan Harga SageMaker, biaya untuk memiliki 10 titik akhir persisten model tunggal adalah: 10 * $0.102 = $1.02 per jam. Sedangkan dengan satu MME yang menghosting 10 model, kami mencapai penghematan biaya 10 kali lipat: 1 * $0.102 = $0.102 per jam. |
Latensi inferensi |
Secara default, cache MME model yang sering digunakan di memori dan di disk untuk menyediakan inferensi latensi rendah. Model yang di-cache dibongkar atau dihapus dari disk hanya ketika wadah kehabisan memori atau ruang disk untuk mengakomodasi model yang baru ditargetkan. MME memungkinkan pemuatan model yang lambat, yang berarti model dimuat ke dalam memori saat dipanggil untuk pertama kali. Ini mengoptimalkan pemanfaatan memori; namun, ini menyebabkan lonjakan waktu respons pada pemuatan pertama, yang mengakibatkan masalah start dingin. Oleh karena itu, MME juga cocok untuk skenario yang dapat mentolerir pinalti latensi terkait start-dingin sesekali yang terjadi saat menggunakan model yang jarang digunakan. Untuk memenuhi tujuan latensi dan throughput aplikasi ML, instans GPU lebih disukai daripada instans CPU (mengingat penawaran daya komputasi GPU). Dengan dukungan MME untuk GPU, Anda dapat menerapkan ribuan model pembelajaran mendalam di belakang satu titik akhir SageMaker. MME dapat menjalankan beberapa model pada inti GPU, berbagi instans GPU di belakang titik akhir di beberapa model, dan memuat dan membongkar model secara dinamis berdasarkan lalu lintas yang masuk. Dengan ini, Anda dapat menghemat biaya secara signifikan dan mencapai kinerja harga terbaik. Jika kasus penggunaan Anda menuntut persyaratan transaksi per detik (TPS) atau latensi yang jauh lebih tinggi, sebaiknya hosting model di titik akhir khusus. |
Throughput |
Nilai ideal throughput inferensi MME bergantung pada faktor seperti model, ukuran muatan, dan jenis instans titik akhir. Jumlah memori instance yang lebih tinggi memungkinkan Anda memuat lebih banyak model dan siap melayani permintaan inferensi. Anda tidak perlu membuang waktu memuat model. Jumlah vCPU yang lebih tinggi memungkinkan Anda menjalankan lebih banyak model unik secara bersamaan. MME secara dinamis memuat dan membongkar model ke dan dari memori instan, yang dapat memengaruhi kinerja I/O. MME SageMaker dengan GPU bekerja menggunakan Server Inferensi NVIDIA Triton, yang merupakan perangkat lunak penyajian inferensi sumber terbuka yang menyederhanakan proses penyajian inferensi dan memberikan kinerja inferensi yang tinggi. SageMaker memuat model ke memori wadah NVIDIA Triton pada instans yang dipercepat GPU dan melayani permintaan inferensi. Inti GPU digunakan bersama oleh semua model dalam satu instans. Jika model sudah dimuat dalam memori penampung, permintaan berikutnya akan dilayani lebih cepat karena SageMaker tidak perlu mengunduh dan memuatnya lagi. Pengujian dan analisis kinerja yang tepat direkomendasikan dalam penerapan produksi yang sukses. SageMaker menyediakan metrik CloudWatch untuk titik akhir multi-model sehingga Anda dapat menentukan penggunaan titik akhir dan rasio hit cache untuk membantu mengoptimalkan titik akhir Anda. |
Kompleksitas konfigurasi penskalaan | Titik akhir multi-model SageMaker sepenuhnya mendukung penskalaan otomatis, yang mengelola replika model untuk memastikan skala model berdasarkan pola lalu lintas. Namun, pengujian beban yang tepat disarankan untuk menentukan ukuran optimal instans untuk penskalaan titik akhir secara otomatis. Ukuran armada MME yang tepat penting untuk menghindari terlalu banyak model yang dibongkar. Memuat ratusan model pada beberapa instans yang lebih besar dapat menyebabkan pelambatan dalam beberapa kasus, dan menggunakan instans yang lebih banyak dan lebih kecil mungkin lebih disukai. Untuk memanfaatkan penskalaan model otomatis di SageMaker, pastikan Anda memilikinya contoh pengaturan penskalaan otomatis untuk menyediakan kapasitas instans tambahan. Siapkan kebijakan penskalaan tingkat titik akhir Anda dengan parameter khusus atau pemanggilan per menit (disarankan) untuk menambahkan lebih banyak instans ke armada titik akhir. Laju pemanggilan yang digunakan untuk memicu peristiwa penskalaan otomatis didasarkan pada kumpulan prediksi agregat di seluruh kumpulan model lengkap yang dilayani oleh titik akhir. |
Pola lalu lintas | MME ideal jika Anda memiliki banyak model berukuran serupa yang dapat Anda sajikan melalui wadah penyajian bersama dan tidak perlu mengakses semua model pada saat yang bersamaan. |
Titik akhir multikontainer SageMaker
SageMaker MCE mendukung penggelaran hingga 15 kontainer yang menggunakan model atau kerangka kerja berbeda pada satu titik akhir, dan menerapkannya secara mandiri atau berurutan untuk inferensi latensi rendah dan penghematan biaya. Modelnya bisa benar-benar heterogen, dengan tumpukan penyajian independennya sendiri. Menghosting beberapa model dengan aman dari kerangka kerja yang berbeda pada satu instans dapat menghemat biaya hingga 90%.
Pola pemanggilan MCE adalah sebagai berikut:
- Pipa inferensi โ Wadah dalam MME dapat dipanggil dalam urutan linier, juga dikenal sebagai a pipa inferensi serial. Mereka biasanya digunakan untuk memisahkan preprocessing, model inference, dan postprocessing ke dalam wadah independen. Keluaran dari wadah saat ini diteruskan sebagai masukan ke wadah berikutnya. Mereka direpresentasikan sebagai model pipa tunggal di SageMaker. Pipa inferensi dapat digunakan sebagai MME, di mana salah satu wadah dalam pipa dapat secara dinamis melayani permintaan berdasarkan model yang dipanggil.
- Doa langsung - Dengan pemanggilan langsung, permintaan dapat dikirim ke wadah inferensi tertentu yang dihosting di MCE.
Tabel berikut memberikan panduan dalam mengevaluasi fungsi kebugaran untuk MCE.
Fungsi kebugaran | Deskripsi Produk |
Biaya | MCE memungkinkan Anda menjalankan hingga 15 penampung ML yang berbeda pada satu titik akhir dan menjalankannya secara terpisah, sehingga menghemat biaya. Opsi ini ideal jika Anda memiliki beberapa model yang berjalan di stack layanan yang berbeda dengan kebutuhan sumber daya yang serupa, dan jika model individual tidak memiliki lalu lintas yang memadai untuk memanfaatkan kapasitas penuh instance titik akhir. Oleh karena itu, MCE lebih hemat biaya daripada titik akhir model tunggal. MCE menawarkan respons inferensi sinkron, yang berarti titik akhir selalu tersedia dan Anda membayar waktu aktif instans. Biaya dapat bertambah tergantung pada jumlah dan jenis instans. |
Latensi inferensi | MCE ideal untuk menjalankan aplikasi ML dengan framework dan algoritme ML yang berbeda untuk setiap model yang jarang diakses tetapi masih memerlukan inferensi latensi rendah. Model selalu tersedia untuk inferensi latensi rendah dan tidak ada masalah cold start. |
Throughput | MCE dibatasi hingga 15 kontainer pada titik akhir multi-kontainer, dan inferensi GPU tidak didukung karena pertentangan sumber daya. Untuk titik akhir multi-kontainer yang menggunakan mode pemanggilan langsung, SageMaker tidak hanya menyediakan metrik tingkat instans seperti pada titik akhir umum lainnya, tetapi juga mendukung metrik per-kontainer. Sebagai praktik terbaik, tinjau metrik CloudWatch untuk permintaan input dan pemanfaatan sumber daya, dan pilih jenis instans yang sesuai untuk mencapai throughput yang optimal. |
Kompleksitas konfigurasi penskalaan | MCE mendukung penskalaan otomatis. Namun, untuk mengonfigurasi penskalaan otomatis, sebaiknya model di setiap penampung menunjukkan penggunaan dan latensi CPU yang serupa pada setiap permintaan inferensi. Hal ini direkomendasikan karena jika lalu lintas ke titik akhir multi-kontainer beralih dari model penggunaan CPU rendah ke model penggunaan CPU tinggi, tetapi keseluruhan volume panggilan tetap sama, titik akhir tidak diskalakan, dan mungkin tidak ada cukup instance untuk menangani semua permintaan ke model penggunaan CPU yang tinggi. |
Pola lalu lintas | MCE ideal untuk beban kerja dengan pola lalu lintas berkelanjutan atau reguler, untuk menghosting model di berbagai kerangka kerja (seperti TensorFlow, PyTorch, atau Sklearn) yang mungkin tidak memiliki lalu lintas yang cukup untuk memenuhi kapasitas penuh instans titik akhir. |
Hosting aplikasi ML berbasis multi-model
Banyak aplikasi bisnis perlu menggunakan beberapa model ML untuk melayani satu permintaan prediksi kepada konsumen mereka. Misalnya, sebuah perusahaan retail yang ingin memberikan rekomendasi kepada para penggunanya. Aplikasi ML dalam kasus penggunaan ini mungkin ingin menggunakan model khusus yang berbeda untuk merekomendasikan kategori produk yang berbeda. Jika perusahaan ingin menambahkan personalisasi pada rekomendasi dengan menggunakan informasi pengguna individual, jumlah model kustom akan semakin meningkat. Menghosting setiap model kustom pada instans komputasi yang berbeda tidak hanya mahal, tetapi juga menyebabkan kurangnya pemanfaatan sumber daya hosting jika tidak semua model sering digunakan. SageMaker menawarkan opsi hosting yang efisien untuk aplikasi ML berbasis multi-model.
Diagram berikut menampilkan opsi hosting multi-model untuk satu titik akhir menggunakan SageMaker.
Pipa inferensi serial
Inference pipeline adalah model SageMaker yang terdiri dari urutan linier 2โ15 kontainer yang memproses permintaan inferensi pada data. Anda menggunakan pipeline inferensi untuk menentukan dan menerapkan kombinasi apa pun dari algoritme bawaan SageMaker yang telah dilatih sebelumnya dan algoritme kustom Anda sendiri yang dikemas dalam wadah Docker. Anda dapat menggunakan pipeline inferensi untuk menggabungkan tugas sains data prapemrosesan, prediksi, dan pascapemrosesan. Keluaran dari satu wadah diteruskan sebagai masukan ke wadah berikutnya. Saat menentukan wadah untuk model pipa, Anda juga menentukan urutan di mana wadah dijalankan. Mereka direpresentasikan sebagai model pipa tunggal di SageMaker. Pipa inferensi dapat digunakan sebagai MME, di mana salah satu wadah dalam pipa dapat secara dinamis melayani permintaan berdasarkan model yang dipanggil. Anda juga dapat menjalankan a transformasi batch pekerjaan dengan pipa inferensi. Pipa inferensi dikelola sepenuhnya.
Tabel berikut memberikan panduan untuk mengevaluasi fungsi kesesuaian untuk hosting model ML menggunakan pipeline inferensi serial.
Fungsi kebugaran | Deskripsi Produk |
Biaya | Pipeline inferensi serial memungkinkan Anda menjalankan hingga 15 container ML yang berbeda pada satu titik akhir, yang menghasilkan efektivitas biaya untuk menghosting container inferensi. Tidak ada biaya tambahan untuk menggunakan fitur ini. Anda hanya membayar untuk instans yang berjalan di titik akhir. Biaya dapat bertambah tergantung pada jumlah dan jenis instans. |
Latensi inferensi | Saat aplikasi ML di-deploy sebagai pipeline inferensi, data di antara model yang berbeda tidak meninggalkan ruang penampung. Pemrosesan fitur dan inferensi berjalan dengan latensi rendah karena kontainer ditempatkan bersama pada instans EC2 yang sama. |
Throughput | Dalam model pipeline inferensi, SageMaker menangani pemanggilan sebagai urutan permintaan HTTP. Kontainer pertama dalam pipa menangani permintaan awal, kemudian respons perantara dikirim sebagai permintaan ke wadah kedua, dan seterusnya, untuk setiap wadah dalam pipa. SageMaker mengembalikan respons akhir ke klien. Throughput bersifat subjektif terhadap faktor-faktor seperti model, ukuran input model, ukuran batch, dan jenis instance titik akhir. Sebagai praktik terbaik, tinjau metrik CloudWatch untuk permintaan input dan pemanfaatan sumber daya, dan pilih jenis instans yang sesuai untuk mencapai throughput yang optimal. |
Kompleksitas konfigurasi penskalaan | Pipeline inferensi serial mendukung penskalaan otomatis. Namun, untuk mengonfigurasi penskalaan otomatis, sebaiknya model di setiap penampung menunjukkan penggunaan dan latensi CPU yang serupa pada setiap permintaan inferensi. Hal ini direkomendasikan karena jika lalu lintas ke titik akhir multi-kontainer beralih dari model penggunaan CPU rendah ke model penggunaan CPU tinggi, tetapi keseluruhan volume panggilan tetap sama, titik akhir tidak akan diskalakan dan mungkin tidak ada cukup instance untuk menangani semua permintaan ke model pemanfaatan CPU yang tinggi. |
Pola lalu lintas |
Pipeline inferensi serial ideal untuk pola lalu lintas yang dapat diprediksi dengan model yang berjalan berurutan pada titik akhir yang sama. |
Menerapkan ansambel model (Triton DAG):
SageMaker menawarkan integrasi dengan Server Inferensi NVIDIA Triton melalui Kontainer Server Inferensi Triton. Wadah ini mencakup Server Inferensi NVIDIA Triton, dukungan untuk kerangka kerja ML umum, dan variabel lingkungan berguna yang memungkinkan Anda mengoptimalkan kinerja di SageMaker. Dengan image container NVIDIA Triton, Anda dapat dengan mudah menayangkan model ML dan mendapatkan keuntungan dari pengoptimalan performa, batching dinamis, dan dukungan multi-framework yang disediakan oleh NVIDIA Triton. Triton membantu memaksimalkan pemanfaatan GPU dan CPU, selanjutnya menurunkan biaya inferensi.
Dalam kasus penggunaan bisnis saat aplikasi ML menggunakan beberapa model untuk melayani permintaan prediksi, jika setiap model menggunakan kerangka kerja yang berbeda atau dihosting pada instans terpisah, ini dapat menyebabkan peningkatan beban kerja dan biaya serta peningkatan latensi keseluruhan. Server Inferensi NVIDIA Triton SageMaker mendukung penerapan model dari semua kerangka kerja utama, seperti TensorFlow GraphDef, TensorFlow SavedModel, ONNX, PyTorch TorchScript, TensorRT, dan format model Python/C++ dan banyak lagi. Ansambel model Triton merepresentasikan pipeline dari satu atau lebih model atau logika preprocessing dan postprocessing, dan koneksi tensor input dan output di antaranya. Satu permintaan inferensi ke ansambel memicu jalannya seluruh pipeline. Triton juga memiliki beberapa algoritme penjadwalan dan pengelompokan bawaan yang menggabungkan permintaan inferensi individual untuk meningkatkan throughput inferensi. Keputusan penjadwalan dan pengelompokan ini transparan bagi klien yang meminta inferensi. Model dapat dijalankan pada CPU atau GPU untuk fleksibilitas maksimum dan untuk mendukung kebutuhan komputasi yang heterogen.
Hosting beberapa model yang didukung GPU pada titik akhir multi-model didukung melalui Server Inferensi SageMaker Triton. Server Inferensi NVIDIA Triton telah diperluas untuk mengimplementasikan Kontrak API MME, untuk berintegrasi dengan MME. Anda dapat menggunakan Server Inferensi NVIDIA Triton, yang membuat konfigurasi repositori model untuk backend kerangka kerja yang berbeda, untuk menerapkan MME dengan penskalaan otomatis. Fitur ini memungkinkan Anda menskalakan ratusan model yang sangat dipersonalisasi yang disesuaikan untuk memenuhi pengalaman pengguna akhir yang unik dalam aplikasi AI. Anda juga dapat menggunakan fitur ini untuk mencapai kinerja harga yang diperlukan untuk aplikasi inferensi Anda menggunakan GPU fraksional. Untuk mempelajari lebih lanjut, lihat Jalankan beberapa model pembelajaran mendalam di GPU dengan titik akhir multi-model Amazon SageMaker.
Tabel berikut memberikan panduan untuk mengevaluasi fungsi kesesuaian untuk hosting model ML menggunakan MME dengan dukungan GPU pada wadah inferensi Triton. Untuk titik akhir model tunggal dan evaluasi fungsi kebugaran titik akhir tanpa server, lihat bagian sebelumnya dalam posting ini.
Fungsi kebugaran | Deskripsi Produk |
Biaya | SageMaker MME dengan dukungan GPU menggunakan Triton Inference Server menyediakan cara yang dapat diskalakan dan hemat biaya untuk menerapkan sejumlah besar model deep learning di belakang satu titik akhir SageMaker. Dengan MME, beberapa model berbagi instans GPU di balik titik akhir. Ini memungkinkan Anda untuk memecahkan biaya hosting beberapa model yang meningkat secara linier dan menggunakan kembali infrastruktur di semua model. Anda membayar waktu aktif instans. |
Latensi inferensi |
SageMaker dengan Triton Inference Server dibuat khusus untuk memaksimalkan throughput dan pemanfaatan perangkat keras dengan latensi inferensi sangat rendah (milidetik satu digit). Ini memiliki berbagai kerangka kerja ML yang didukung (termasuk TensorFlow, PyTorch, ONNX, XGBoost, dan NVIDIA TensorRT) dan backend infrastruktur, termasuk GPU NVIDIA, CPU, dan Inferensi AWS. Dengan dukungan MME untuk GPU menggunakan Server Inferensi SageMaker Triton, Anda dapat menerapkan ribuan model pembelajaran mendalam di belakang satu titik akhir SageMaker. SageMaker memuat model ke memori wadah NVIDIA Triton pada instans yang dipercepat GPU dan melayani permintaan inferensi. Inti GPU digunakan bersama oleh semua model dalam satu instans. Jika model sudah dimuat dalam memori penampung, permintaan berikutnya akan dilayani lebih cepat karena SageMaker tidak perlu mengunduh dan memuatnya lagi. |
Throughput |
MME menawarkan kemampuan untuk menjalankan beberapa pembelajaran mendalam atau model ML pada GPU, pada saat yang sama, dengan Triton Inference Server. Ini memungkinkan Anda dengan mudah menggunakan multi-kerangka kerja NVIDIA Triton, inferensi kinerja tinggi yang melayani penerapan model yang dikelola sepenuhnya SageMaker. Triton mendukung semua inferensi berbasis NVIDIA GPU-, x86-, Armยฎ CPU-, dan AWS Inferentia. Ini menawarkan batching dinamis, operasi bersamaan, konfigurasi model optimal, ansambel model, dan input audio dan video streaming untuk memaksimalkan throughput dan pemanfaatan. Faktor lain seperti ukuran jaringan dan payload mungkin memainkan peran minimal dalam overhead yang terkait dengan inferensi. |
Kompleksitas konfigurasi penskalaan |
MME dapat menskalakan secara horizontal menggunakan kebijakan penskalaan otomatis, dan menyediakan instans komputasi GPU tambahan berdasarkan metrik seperti Dengan server inferensi Triton, Anda dapat dengan mudah membuat wadah khusus yang menyertakan model Anda dengan Triton dan membawanya ke SageMaker. SageMaker Inference akan menangani permintaan dan menskalakan container secara otomatis saat penggunaan meningkat, membuat penerapan model dengan Triton di AWS menjadi lebih mudah. |
Pola lalu lintas |
MME ideal untuk pola lalu lintas yang dapat diprediksi dengan model yang dijalankan sebagai DAG pada titik akhir yang sama. SageMaker menangani pembentukan lalu lintas ke titik akhir MME dan mempertahankan salinan model yang optimal pada instans GPU untuk performa harga terbaik. Ini terus merutekan lalu lintas ke instance tempat model dimuat. Jika sumber daya instans mencapai kapasitas karena penggunaan yang tinggi, SageMaker akan membongkar model yang paling jarang digunakan dari penampung untuk mengosongkan sumber daya guna memuat model yang lebih sering digunakan. |
Praktik terbaik
Pertimbangkan praktik terbaik berikut:
- Kohesi tinggi dan kopling rendah antar model โ Host model dalam wadah yang sama yang memiliki kohesi tinggi (mendorong fungsionalitas bisnis tunggal) dan merangkumnya bersama untuk kemudahan pemutakhiran dan pengelolaan. Pada saat yang sama, pisahkan model-model itu satu sama lain (host di wadah yang berbeda) sehingga Anda dapat dengan mudah memutakhirkan satu model tanpa memengaruhi model lainnya. Host beberapa model yang menggunakan wadah berbeda di belakang satu titik akhir dan kemudian aktifkan secara terpisah atau tambahkan logika prapemrosesan dan pascapemrosesan model sebagai pipa inferensi serial.
- Latensi inferensi โ Kelompokkan model yang digerakkan oleh fungsionalitas bisnis tunggal dan tempatkan mereka dalam satu wadah untuk meminimalkan jumlah lompatan dan oleh karena itu meminimalkan latensi keseluruhan. Ada peringatan lain, seperti jika model yang dikelompokkan menggunakan banyak kerangka kerja; Anda juga dapat memilih untuk menghosting di beberapa wadah tetapi menjalankan di host yang sama untuk mengurangi latensi dan meminimalkan biaya.
- Kelompokkan model ML secara logis dengan kohesi tinggi โ Grup logis dapat terdiri dari model yang homogen (misalnya, semua model XGBoost) atau heterogen (misalnya, beberapa XGBoost dan beberapa BERT). Ini mungkin terdiri dari model yang digunakan bersama di beberapa fungsi bisnis atau mungkin khusus untuk memenuhi hanya satu fungsi bisnis.
- Model bersama โ Jika grup logis terdiri dari model bersama, kemudahan pemutakhiran model dan latensi akan memainkan peran utama dalam merancang titik akhir SageMaker. Misalnya, jika latensi adalah prioritas, sebaiknya tempatkan semua model dalam satu wadah di belakang satu titik akhir SageMaker untuk menghindari banyak lompatan. Sisi negatifnya adalah jika salah satu model perlu ditingkatkan, ini akan mengakibatkan peningkatan semua titik akhir SageMaker yang relevan yang menghosting model ini.
- Model yang tidak dibagikan โ Jika grup logis hanya terdiri dari model khusus fitur bisnis dan tidak dibagikan dengan grup lain, kompleksitas pengemasan dan dimensi latensi akan menjadi kunci untuk dicapai. Sebaiknya hosting model ini dalam satu wadah di belakang satu titik akhir SageMaker.
- Penggunaan perangkat keras yang efisien (CPU, GPU) โ Kelompokkan model berbasis CPU bersama-sama dan simpan di host yang sama sehingga Anda dapat menggunakan CPU secara efisien. Demikian pula, kelompokkan model berbasis GPU sehingga Anda dapat menggunakan dan menskalakannya secara efisien. Ada beban kerja hibrid yang membutuhkan CPU dan GPU pada host yang sama. Menghosting model CPU-only dan GPU-only pada host yang sama harus didorong oleh kohesi tinggi dan persyaratan latensi aplikasi. Selain itu, biaya, kemampuan untuk menskalakan, dan radius ledakan pada dampak jika terjadi kegagalan adalah dimensi utama yang harus diperhatikan.
- Fungsi kebugaran โ Gunakan fungsi kebugaran sebagai panduan untuk memilih opsi hosting ML.
Kesimpulan
Dalam hal hosting ML, tidak ada pendekatan yang cocok untuk semua. Praktisi ML harus memilih pola desain yang tepat untuk mengatasi tantangan hosting ML mereka. Mengevaluasi fungsi kebugaran memberikan panduan preskriptif dalam memilih opsi hosting ML yang tepat.
Untuk detail lebih lanjut tentang masing-masing opsi hosting, lihat postingan berikut dalam seri ini:
Tentang penulis
Dhawal Patel adalah Arsitek Pembelajaran Mesin Utama di AWS. Dia telah bekerja dengan organisasi mulai dari perusahaan besar hingga perusahaan rintisan menengah pada masalah yang terkait dengan komputasi terdistribusi, dan Kecerdasan Buatan. Dia berfokus pada Deep learning termasuk domain NLP dan Computer Vision. Dia membantu pelanggan mencapai inferensi model kinerja tinggi di SageMaker.
Deepali Rajale adalah Manajer Akun Teknis Spesialis AI/ML di Amazon Web Services. Dia bekerja dengan pelanggan perusahaan memberikan panduan teknis tentang penerapan solusi pembelajaran mesin dengan praktik terbaik. Di waktu luangnya, dia menikmati hiking, film, dan berkumpul dengan keluarga dan teman.
Saurabh Trikande adalah Manajer Produk Senior untuk Inferensi Amazon SageMaker. Dia bersemangat bekerja dengan pelanggan dan termotivasi oleh tujuan mendemokratisasi pembelajaran mesin. Dia berfokus pada tantangan inti yang terkait dengan penerapan aplikasi ML yang kompleks, model ML multi-penyewa, pengoptimalan biaya, dan membuat penerapan model pembelajaran mendalam lebih mudah diakses. Di waktu luangnya, Saurabh menikmati hiking, belajar tentang teknologi inovatif, mengikuti TechCrunch, dan menghabiskan waktu bersama keluarganya.
- Konten Bertenaga SEO & Distribusi PR. Dapatkan Amplifikasi Hari Ini.
- Platoblockchain. Intelijen Metaverse Web3. Pengetahuan Diperkuat. Akses Di Sini.
- Sumber: https://aws.amazon.com/blogs/machine-learning/model-hosting-patterns-in-amazon-sagemaker-part-1-common-design-patterns-for-building-ml-applications-on-amazon-sagemaker/
- 1
- 10
- 100
- 11
- 39
- 7
- 70
- a
- kemampuan
- Sanggup
- Tentang Kami
- dipercepat
- mengakses
- diakses
- dapat diakses
- menampung
- Akun
- tepat
- Mencapai
- mencapai
- di seluruh
- Tindakan
- aktif
- tambahan
- Tambahan
- Selain itu
- alamat
- memajukan
- maju
- Keuntungan
- pengiklanan
- mempengaruhi
- Setelah
- pengumpulan
- Agregator
- agresif
- perjanjian
- AI
- AI / ML
- alarm
- algoritma
- Semua
- Membiarkan
- memungkinkan
- sudah
- selalu
- Amazon
- Amazon EC2
- Amazon SageMaker
- Amazon Web Services
- jumlah
- analisis
- menganalisa
- dan
- dan infrastruktur
- tahunan
- Lain
- Apache
- api
- Apple
- Aplikasi
- aplikasi
- pendekatan
- sesuai
- aplikasi
- arsitektur
- ARM
- buatan
- kecerdasan buatan
- aspek
- penilaian
- terkait
- atribut
- audio
- audit
- mobil
- Otomatis
- secara otomatis
- secara otomatis
- tersedianya
- tersedia
- rata-rata
- AWS
- kembali
- bersandaran
- Perbankan
- mendasarkan
- berdasarkan
- karena
- menjadi
- menjadi
- sebelum
- di belakang
- makhluk
- manfaat
- TERBAIK
- Praktik Terbaik
- Lebih baik
- antara
- biomedis
- Memblokir
- Peminjaman
- batas-batas
- Kotak
- pelanggaran
- Istirahat
- membawa
- Membawa
- Anggaran
- membangun
- Bangunan
- dibangun di
- built-in
- bisnis
- Aplikasi Bisnis
- Proses bisnis
- bisnis
- Cache
- dihitung
- panggilan
- bernama
- pemanggil
- calon
- kemampuan
- Kapasitas
- yang
- kasus
- kasus
- kategori
- penyebab
- tertentu
- Tersertifikasi
- tantangan
- perubahan
- Perubahan
- karakteristik
- dibebankan
- ChatBot
- memeriksa
- keping
- pilihan
- pilihan
- Pilih
- memilih
- kelas
- klasifikasi
- Klasifikasi
- klien
- klien
- Penyelesaian
- awan
- Kelompok
- kode
- diciptakan
- rekan
- mengumpulkan
- memerangi
- kombinasi
- menggabungkan
- bergabung
- Umum
- Perusahaan
- perusahaan
- dibandingkan
- lengkap
- sama sekali
- kompleks
- kompleksitas
- pemenuhan
- komponen
- tersusun
- kompromi
- kekuatan komputasi
- menghitung
- komputer
- Visi Komputer
- komputasi
- konsep
- Perhatian
- bersamaan
- konfigurasi
- koneksi
- konsisten
- dikonsumsi
- Konsumen
- Wadah
- Wadah
- mengandung
- terus
- terus
- kontinu
- kontrol
- Core
- Sesuai
- Biaya
- penghematan biaya
- hemat biaya
- Biaya
- bisa
- membuat
- menciptakan
- kritis
- sangat penting
- terbaru
- adat
- pelanggan
- pelanggan
- DAG
- data
- pengolahan data
- ilmu data
- ilmuwan data
- Basis Data
- kumpulan data
- hari
- berurusan
- keputusan
- dedicated
- mendalam
- belajar mendalam
- Default
- mendefinisikan
- menyampaikan
- Permintaan
- tuntutan
- Demokratisasi
- Tergantung
- tergantung
- menyebarkan
- dikerahkan
- penggelaran
- penyebaran
- penyebaran
- Mendesain
- pola desain
- dirancang
- rinci
- rincian
- Deteksi
- Menentukan
- Pengembang
- Pengembangan
- diagram
- berbeda
- sulit
- ukuran
- langsung
- berbeda
- didistribusikan
- komputasi terdistribusi
- beberapa
- Buruh pelabuhan
- dokumen
- Tidak
- domain
- Dont
- turun
- Download
- Kelemahan
- didorong
- menjatuhkan
- Jatuhan
- selama
- dinamis
- setiap
- Terdahulu
- mudah
- mudah
- Efektif
- efektif
- efektivitas
- efisiensi
- efisien
- efisien
- usaha
- antara
- menghilangkan
- aktif
- memungkinkan
- enkripsi
- ujung ke ujung
- Titik akhir
- Teknik
- Insinyur
- cukup
- memastikan
- Memastikan
- Enterprise
- perusahaan
- Seluruh
- Lingkungan Hidup
- kesalahan
- kesalahan
- terutama
- dievaluasi
- evaluasi
- Bahkan
- Acara
- segala sesuatu
- evolusi
- contoh
- contoh
- Pasar Valas
- pameran
- mengharapkan
- diharapkan
- pengalaman
- Pengalaman
- menyelidiki
- ekspresi
- luar
- tambahan
- Menghadapi
- faktor
- Kegagalan
- hampir
- keluarga
- keluarga
- lebih cepat
- Fitur
- Fitur
- pemberian makanan
- beberapa
- terakhir
- Pertama
- pertama kali
- kebugaran
- ARMADA KAPAL
- keluwesan
- aliran
- berubah-ubah
- berfokus
- berikut
- berikut
- Ford
- bentuk
- bentuk
- fraksional
- Kerangka
- kerangka
- penipuan
- deteksi penipuan
- Gratis
- Frekuensi
- sering
- teman
- dari
- Buah-buahan
- penuh
- sepenuhnya
- fungsi
- fungsionalitas
- fungsi
- fungsi
- lebih lanjut
- GDPR
- Umum
- dihasilkan
- menghasilkan
- mendapatkan
- Memberikan
- diberikan
- tujuan
- Anda
- baik
- GPU
- GPU
- grafik
- besar
- lebih besar
- sangat
- Kelompok
- Grup
- Tumbuh
- membimbing
- menangani
- Menangani
- berguna
- Perangkat keras
- memiliki
- Kesehatan
- kesehatan
- membantu
- membantu
- membantu
- di sini
- High
- kinerja tinggi
- resolusi tinggi
- lebih tinggi
- Memukul
- Horisontal
- tuan rumah
- host
- tuan
- biaya hosting
- layanan hosting
- Seterpercayaapakah Olymp Trade? Kesimpulan
- Namun
- HTML
- HTTPS
- Ratusan
- Hibrida
- ideal
- identitas
- Siaga
- gambar
- Klasifikasi gambar
- gambar
- abadi
- Dampak
- dampak
- dampak
- melaksanakan
- diimplementasikan
- mengimplementasikan
- penting
- memperbaiki
- meningkatkan
- in
- memasukkan
- termasuk
- Termasuk
- masuk
- Meningkatkan
- Pada meningkat
- Meningkatkan
- meningkatkan
- independen
- secara mandiri
- sendiri-sendiri
- informasi
- Infrastruktur
- mulanya
- inovatif
- teknologi inovatif
- memasukkan
- Instalasi
- contoh
- sebagai gantinya
- mengintegrasikan
- integrasi
- Intelijen
- interaktif
- melibatkan
- ISO
- isolasi
- IT
- Pekerjaan
- Jobs
- kunci
- kunci-kunci
- Tahu
- dikenal
- besar
- lebih besar
- Latensi
- jalankan
- meluncurkan
- peluncuran
- memimpin
- terkemuka
- Memimpin
- BELAJAR
- pengetahuan
- Meninggalkan
- Dipimpin
- Tingkat
- perpustakaan
- pengangkatan
- Terbatas
- batas
- Daftar
- hidup
- memuat
- pemuatan
- beban
- tempat
- Panjang
- lagi
- melihat
- kehilangan
- Lot
- Rendah
- mesin
- Mesin belajar
- terbuat
- Utama
- memelihara
- mempertahankan
- utama
- membuat
- MEMBUAT
- Membuat
- mengelola
- berhasil
- pengelolaan
- manajer
- mengelola
- pelaksana
- banyak
- Marketing
- matematis
- hal
- Maksimalkan
- maksimum
- cara
- Pelajari
- Memori
- metode
- metode
- metrik
- Metrik
- mungkin
- minimal
- minimum
- menit
- Percampuran
- ML
- mode
- model
- model
- Memantau
- pemantauan
- Bulan
- bulan
- lebih
- paling
- termotivasi
- bioskop
- Titik Akhir Multi-Model
- beberapa
- banyaknya
- Alam
- perlu
- Perlu
- kebutuhan
- jaringan
- New
- berikutnya
- nLP
- pemberitahuan
- pemberitahuan
- jumlah
- Nvidia
- obyek
- tujuan
- target
- mendapatkan
- sesekali
- menawarkan
- Penawaran
- Pengunjung
- ONE
- secara online
- open source
- beroperasi
- beroperasi
- operasi
- operasional
- Operasi
- operator
- optimal
- optimasi
- Optimize
- dioptimalkan
- Mengoptimalkan
- mengoptimalkan
- pilihan
- Opsi
- Jeruk
- urutan
- organisasi
- Lainnya
- terkemuka
- secara keseluruhan
- sendiri
- kepemilikan
- paket
- pengemasan
- parameter
- bagian
- tertentu
- pasangan
- Lulus
- bergairah
- Patch
- pola
- pola
- Membayar
- Puncak
- Melakukan
- prestasi
- melakukan
- periode
- berkala
- periode
- Personalisasi
- Personalized
- memilih
- pipa saluran
- Tempat
- Tempat
- berencana
- rencana
- Platform
- Platform
- plato
- Kecerdasan Data Plato
- Data Plato
- Bermain
- plus
- Kebijakan
- kebijaksanaan
- Populer
- mungkin
- Pos
- Posts
- kekuasaan
- praktek
- praktek
- Bisa ditebak
- memprediksi
- ramalan
- Prediksi
- disukai
- sebelumnya
- harga pompa cor beton mini
- Utama
- prioritas
- swasta
- Masalah
- masalah
- proses
- Diproses
- proses
- pengolahan
- prosesor
- Produk
- manajer produk
- Produksi
- Produk
- Profil
- tepat
- memberikan
- disediakan
- menyediakan
- menyediakan
- ketentuan
- wakil
- tujuan
- Dorong
- pytorch
- segera
- jarak
- mulai
- cepat
- Penilaian
- Tarif
- mencapai
- Mencapai
- Baca
- siap
- nyata
- dunia nyata
- real-time
- menerima
- diterima
- menerima
- sarankan
- Rekomendasi
- rekomendasi
- direkomendasikan
- merekomendasikan
- merekomendasikan
- berulang
- menurunkan
- mengurangi
- mengacu
- Bagaimanapun juga
- reguler
- terkait
- Pers
- relevan
- sisa
- gudang
- diwakili
- merupakan
- permintaan
- permintaan
- membutuhkan
- wajib
- kebutuhan
- Persyaratan
- membutuhkan
- sumber
- Sumber
- tanggapan
- ISTIRAHAT
- mengakibatkan
- dihasilkan
- Hasil
- eceran
- Pengembalian
- ulasan
- Risiko
- Peran
- akar
- Rute
- Aturan
- Run
- berjalan
- SaaS
- pembuat bijak
- Inferensi SageMaker
- gaji
- sama
- Save
- penghematan
- Tabungan
- terukur
- Skala
- sisik
- skala
- skenario
- menjadwalkan
- dijadwalkan
- Ilmu
- ilmuwan
- Kedua
- detik
- Bagian
- bagian
- aman
- keamanan
- memilih
- seleksi
- senior
- peka
- Urutan
- serial
- Seri
- melayani
- Tanpa Server
- Server
- melayani
- layanan
- Layanan
- porsi
- set
- pengaturan
- beberapa
- membentuk
- Share
- berbagi
- Pergeseran
- harus
- Pertunjukkan
- penting
- signifikan
- mirip
- Demikian pula
- Sederhana
- tunggal
- Ukuran
- ukuran
- kecil
- lebih kecil
- So
- Perangkat lunak
- larutan
- Solusi
- beberapa
- sumber
- Space
- spesialis
- khusus
- tertentu
- Secara khusus
- ditentukan
- kecepatan
- Pengeluaran
- sepatu berduri
- stabil
- tumpukan
- Tumpukan
- awal
- mulai
- dimulai
- startup
- Startups
- mantap
- Langkah
- Tangga
- Masih
- Berhenti
- penyimpanan
- menyimpan
- strategi
- Streaming
- Ketat
- sangat
- selanjutnya
- sukses
- sukses
- seperti itu
- cukup
- cocok
- mendukung
- Didukung
- Mendukung
- gelora
- tabel
- Mengambil
- Dibutuhkan
- target
- ditargetkan
- tugas
- tugas
- tim
- tim
- TechCrunch
- Teknis
- Teknologi
- penyewa
- tensorflow
- uji
- pengujian
- Grafik
- mereka
- diri
- dengan demikian
- karena itu
- ribuan
- tiga
- ambang
- Melalui
- di seluruh
- keluaran
- waktu
- kali
- untuk
- bersama
- terlalu
- alat
- Total
- terima kasih
- Pelacakan
- lalu lintas
- Pelatihan VE
- terlatih
- Pelatihan
- transaksional
- Transaksi
- Mengubah
- Transformasi
- mengubah
- transit
- jelas
- memicu
- Pelaut
- MENGHIDUPKAN
- jenis
- khas
- khas
- bawah
- pokok
- memahami
- unik
- unit
- tak terduga
- terpakai
- Memperbarui
- Pembaruan
- meningkatkan
- upgrade
- uptime
- penggunaan
- menggunakan
- gunakan case
- Pengguna
- Pengguna
- biasanya
- Penggunaan
- dimanfaatkan
- MENGESAHKAN
- nilai
- Nilai - Nilai
- Varian
- berbagai
- melalui
- Video
- Video
- View
- maya
- penglihatan
- volume
- Memilih
- orang
- Limbah
- jaringan
- layanan web
- minggu
- Apa
- Apa itu
- yang
- sementara
- lebar
- Rentang luas
- akan
- dalam
- tanpa
- Kerja
- bekerja
- pekerja
- pekerja
- kerja
- bekerja
- dunia
- akan
- XGBoost
- tahun
- Kamu
- Anda
- zephyrnet.dll
- nol