Dapatkan hosting latensi rendah untuk model ML berbasis pohon keputusan di Server Inferensi NVIDIA Triton di Amazon SageMaker

Penerapan model pembelajaran mesin (ML) dapat memiliki persyaratan kinerja dan latensi yang sangat menuntut untuk bisnis saat ini. Kasus penggunaan seperti deteksi penipuan dan penempatan iklan 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, logika pemilihan model, agregasi model, dan pascapemrosesan. Dalam skala besar, ini sering kali berarti mempertahankan volume lalu lintas yang besar sambil mempertahankan latensi yang rendah. Pola desain umum termasuk saluran pipa inferensi serial, ensemble (scatter-gather), dan alur kerja logika bisnis, yang menghasilkan realisasi seluruh alur kerja permintaan sebagai Directed Acyclic Graph (DAG). Namun, karena alur kerja menjadi lebih kompleks, hal ini dapat menyebabkan peningkatan waktu respons secara keseluruhan, yang pada gilirannya dapat berdampak negatif pada pengalaman pengguna akhir dan membahayakan tujuan bisnis. Triton dapat mengatasi kasus penggunaan ini di mana beberapa model disusun dalam pipeline dengan tensor input dan output yang terhubung di antaranya, membantu Anda mengatasi beban kerja ini.

Saat Anda mengevaluasi sasaran Anda terkait dengan inferensi model ML, banyak opsi dapat dipertimbangkan, tetapi hanya sedikit yang mampu dan terbukti seperti Amazon SageMaker dengan Server Inferensi Triton. SageMaker dengan Triton Inference Server telah menjadi pilihan populer bagi banyak pelanggan karena dibuat khusus untuk memaksimalkan throughput dan pemanfaatan perangkat keras dengan latensi inferensi ultra-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. Selain itu, Server Inferensi Triton terintegrasi dengan SageMaker, layanan ML ujung ke ujung yang terkelola sepenuhnya, menyediakan opsi inferensi waktu nyata untuk model hosting.

Dalam posting ini, kami berjalan melalui penggelaran beban kerja ansambel deteksi penipuan ke SageMaker dengan Triton Inference Server.

Ikhtisar solusi

Sangat penting bagi setiap proyek untuk memiliki daftar persyaratan dan perkiraan upaya, untuk memperkirakan total biaya proyek. Sangat penting untuk memperkirakan laba atas investasi (ROI) yang mendukung keputusan suatu organisasi. Beberapa pertimbangan yang perlu diperhatikan saat memindahkan beban kerja ke Triton meliputi:

Estimasi upaya adalah kunci dalam pengembangan perangkat lunak, dan pengukurannya sering didasarkan pada input yang tidak lengkap, tidak pasti, dan berisik. Beban kerja ML tidak berbeda. Beberapa faktor akan memengaruhi arsitektur untuk inferensi ML, beberapa di antaranya adalah:

• Anggaran latensi sisi klien – Ini menentukan waktu tunggu maksimum bolak-balik sisi klien yang dapat diterima untuk respons inferensi, biasanya dinyatakan dalam persentil. Untuk beban kerja yang memerlukan anggaran latensi mendekati puluhan milidetik, transfer jaringan bisa menjadi mahal, jadi menggunakan model di edge akan lebih cocok.
• Ukuran distribusi muatan data – Muatan, sering disebut sebagai Badan Pesan, adalah data permintaan yang dikirimkan dari klien ke model, serta data respons yang dikirimkan dari model ke klien. Ukuran muatan seringkali memiliki dampak besar pada latensi dan harus dipertimbangkan.
• Format data – Ini menentukan bagaimana payload dikirim ke model ML. Format dapat dibaca manusia, seperti JSON dan CSV, namun ada juga format biner, yang sering kali dikompresi dan berukuran lebih kecil. Ini adalah pertukaran antara overhead kompresi dan ukuran transfer, yang berarti bahwa siklus dan latensi CPU ditambahkan untuk mengompres atau mendekompresi, untuk menghemat byte yang ditransfer melalui jaringan. Posting ini menunjukkan cara memanfaatkan format JSON dan biner.
• Tumpukan perangkat lunak dan komponen yang diperlukan – Tumpukan adalah kumpulan komponen yang beroperasi bersama untuk mendukung aplikasi ML, termasuk sistem operasi, runtime, dan lapisan perangkat lunak. Triton hadir dengan kerangka kerja ML populer bawaan, yang disebut backends, seperti ONNX, TensorFlow, FIL, OpenVINO, Python asli, dan lainnya. Anda juga dapat menulis latar belakang kustom untuk komponen buatan Anda sendiri. Posting ini membahas model XGBoost dan pra-pemrosesan data, yang masing-masing kami migrasikan ke backend FIL dan Python Triton yang disediakan NVIDIA.

Semua faktor ini harus memainkan peran penting dalam mengevaluasi kinerja beban kerja Anda, tetapi dalam kasus penggunaan ini kami fokus pada pekerjaan yang diperlukan untuk memindahkan model ML Anda agar dihosting di SageMaker dengan Triton Inference Server. Secara khusus, kami menggunakan contoh ansambel deteksi penipuan yang terdiri dari model XGBoost dengan logika prapemrosesan yang ditulis dengan Python.

Server Inferensi NVIDIA Triton

Server Inferensi Triton telah dirancang dari bawah ke atas untuk memungkinkan tim menerapkan, menjalankan, dan menskalakan model AI terlatih dari kerangka kerja apa pun pada infrastruktur berbasis GPU atau CPU. Selain itu, telah dioptimalkan untuk menawarkan inferensi berkinerja tinggi dalam skala besar dengan fitur-fitur seperti batching dinamis, proses bersamaan, konfigurasi model yang optimal, ansambel model, dan dukungan untuk input streaming.

Diagram berikut menunjukkan contoh pipa ansambel NVIDIA Triton.

Beban kerja harus mempertimbangkan kemampuan yang disediakan Triton bersama dengan hosting SageMaker untuk memaksimalkan manfaat yang ditawarkan. Misalnya, Triton mendukung HTTP serta API C, yang memungkinkan fleksibilitas serta pengoptimalan muatan saat dibutuhkan. Seperti yang disebutkan sebelumnya, Triton mendukung beberapa kerangka kerja populer, termasuk TensorFlow, PyTorch, ONNX, XGBoost, dan NVIDIA TensorRT. Kerangka kerja ini didukung melalui backend Triton, dan dalam kasus yang jarang terjadi bahwa backend tidak mendukung kasus penggunaan Anda, Triton memungkinkan Anda untuk mengimplementasikannya sendiri dan mengintegrasikannya dengan mudah.

Diagram berikut menunjukkan contoh arsitektur NVIDIA Triton.

NVIDIA Triton di SageMaker

Hosting SageMaker services adalah kumpulan fitur SageMaker yang ditujukan untuk membuat penerapan dan penyajian model menjadi lebih mudah. Ini menyediakan berbagai opsi untuk dengan mudah menerapkan, menskalakan otomatis, memantau, dan mengoptimalkan model ML yang disesuaikan untuk berbagai kasus penggunaan. Ini berarti Anda dapat mengoptimalkan penerapan untuk semua jenis pola penggunaan, mulai dari persisten dan selalu tersedia dengan opsi tanpa server, hingga kebutuhan inferensi sementara, berjalan lama, atau batch.

Di bawah payung hosting SageMaker juga terdapat kumpulan Inferensi SageMaker Deep Learning Containers (DLC), yang telah dikemas sebelumnya dengan perangkat lunak server model yang sesuai untuk kerangka kerja ML yang didukung terkait. Hal ini memungkinkan Anda mencapai kinerja inferensi tinggi tanpa penyiapan server model, yang seringkali merupakan aspek teknis paling kompleks dari penerapan model dan secara umum bukan bagian dari keahlian ilmuwan data. Server inferensi Triton sekarang tersedia pada DLC SageMaker.

Pilihan yang luas, modularitas, dan kemudahan penggunaan kerangka kerja penyajian yang berbeda menjadikan SageMaker dan Triton pasangan yang kuat.

Dukungan backend NVIDIA FIL

Dengan Rilis versi 22.05 dari Triton, NVIDIA kini mendukung model hutan yang dilatih oleh beberapa kerangka kerja ML populer, termasuk XGBoost, LightGBM, Scikit-learn, dan cuML. Saat menggunakan backend FIL untuk Triton, Anda harus memastikan bahwa artefak model yang Anda berikan didukung. Misalnya, FIL mendukung model_type xgboost, xgboost_json, lightgbm, atau treelite_checkpoint, yang menunjukkan apakah model yang disediakan masing-masing dalam format biner XGBoost, format XGBoost JSON, format teks LightGBM, atau format biner Treelite.

Dukungan backend ini penting untuk kami gunakan dalam contoh kami karena FIL mendukung model XGBoost. Satu-satunya pertimbangan yang harus diperiksa adalah memastikan bahwa model yang kami terapkan mendukung format biner atau JSON.

Selain memastikan bahwa Anda memiliki format model yang tepat, pertimbangan lain harus diambil. Backend FIL untuk Triton menyediakan opsi yang dapat dikonfigurasi bagi pengembang untuk menyesuaikan beban kerja mereka dan mengoptimalkan kinerja model yang dijalankan. Konfigurasi dynamic_batching memungkinkan Triton untuk menahan permintaan sisi klien dan mengelompokkannya di sisi server, agar dapat menggunakan komputasi paralel FIL secara efisien untuk menyimpulkan seluruh kumpulan bersama-sama. Pilihan max_queue_delay_microseconds menawarkan kontrol gagal-aman berapa lama Triton menunggu untuk membentuk batch. FIL hadir dengan penjelasan Shapley, yang dapat diaktifkan dengan konfigurasi treeshap_output; namun, Anda harus ingat bahwa keluaran Shapley merusak kinerja karena ukuran keluarannya. Aspek penting lainnya adalah storage_type untuk trade-off antara jejak memori dan runtime. Misalnya, menggunakan penyimpanan sebagai SPARSE dapat mengurangi konsumsi memori, sedangkan DENSE dapat mengurangi performa menjalankan model Anda dengan mengorbankan penggunaan memori yang lebih tinggi. Memutuskan pilihan terbaik untuk masing-masing ini bergantung pada beban kerja dan anggaran latensi Anda, jadi sebaiknya lihat lebih dalam semua opsi di FAQ backend FIL dan daftar konfigurasi yang tersedia di FIL.

Langkah-langkah untuk meng-host model di triton

Mari kita lihat kasus penggunaan deteksi penipuan sebagai contoh apa yang harus dipertimbangkan saat memindahkan beban kerja ke Triton.

Identifikasi beban kerja Anda

Dalam kasus penggunaan ini, kami memiliki model deteksi penipuan yang digunakan selama proses checkout pelanggan ritel. Pipeline inferensi menggunakan algoritma XGBoost dengan logika preprocessing yang mencakup persiapan data untuk preprocessing.

Identifikasi metrik kinerja saat ini dan target serta sasaran lain yang mungkin berlaku

Anda mungkin menemukan bahwa waktu inferensi ujung-ke-ujung Anda terlalu lama untuk dapat diterima. Sasaran Anda adalah beralih dari latensi puluhan milidetik ke latensi satu digit untuk volume permintaan yang sama dan throughput masing-masing. Anda menentukan bahwa sebagian besar waktu digunakan oleh prapemrosesan data dan model XGBoost. Faktor lain seperti jaringan dan ukuran muatan memainkan peran minimal dalam overhead yang terkait dengan waktu inferensi ujung ke ujung.

Bekerja mundur untuk menentukan apakah Triton dapat meng-host beban kerja Anda berdasarkan kebutuhan Anda

Untuk menentukan apakah Triton dapat memenuhi kebutuhan Anda, Anda perlu memperhatikan dua bidang utama yang menjadi perhatian. Yang pertama adalah memastikan bahwa Triton dapat melayani dengan opsi ujung depan yang dapat diterima seperti HTTP atau C API.

Seperti disebutkan sebelumnya, penting juga untuk menentukan apakah Triton mendukung backend yang dapat melayani artefak Anda. Triton mendukung sejumlah backends yang dibuat khusus untuk mendukung berbagai kerangka kerja seperti PyTorch dan TensorFlow. Periksa untuk memastikan bahwa model Anda didukung dan Anda memiliki format model yang tepat seperti yang diharapkan Triton. Untuk melakukan ini, periksa dulu untuk melihat format model apa yang didukung backend Triton. Dalam banyak kasus, ini tidak memerlukan perubahan apa pun untuk model. Dalam kasus lain, model Anda mungkin memerlukan transformasi ke format yang berbeda. Bergantung pada sumber dan format target, tersedia berbagai opsi, seperti mengubah a File acar Python untuk menggunakan format pos pemeriksaan biner Treelite.

Untuk kasus penggunaan ini, kami menentukan Bagian belakang FIL dapat mendukung model XGBoost tanpa perubahan yang diperlukan dan kami dapat menggunakan Latar belakang python untuk pra-pemrosesan. Dengan fitur ansambel Triton, Anda dapat lebih mengoptimalkan beban kerja Anda dengan menghindari panggilan jaringan yang mahal antara instans hosting.

Buat rencana dan perkirakan upaya yang diperlukan untuk menggunakan Triton untuk hosting

Mari kita bicara tentang rencana untuk memindahkan model Anda ke Triton. Setiap penerapan Triton memerlukan hal berikut:

• Artefak model yang dibutuhkan oleh backend Triton
• File konfigurasi Triton
• Folder repositori model dengan struktur yang tepat

Kami menunjukkan contoh cara membuat dependensi penerapan ini nanti di posting ini.

Jalankan rencana dan validasi hasilnya

Setelah Anda membuat file dan artefak yang diperlukan dalam repositori model yang terstruktur dengan benar, Anda perlu menyesuaikan penerapan dan mengujinya untuk memvalidasi bahwa Anda sekarang telah mencapai metrik target Anda.

Pada titik ini, Anda dapat menggunakan Rekomendasi Inferensi SageMaker untuk menentukan jenis instans titik akhir yang terbaik untuk Anda berdasarkan kebutuhan Anda. Selain itu, Triton menyediakan alat untuk melakukan optimasi build untuk mendapatkan performa yang lebih baik.

Organisasi

Sekarang mari kita lihat detail implementasinya. Untuk ini kami telah menyiapkan dua buku catatan yang memberikan contoh apa yang dapat diharapkan. Itu buku catatan pertama menunjukkan pelatihan model XGBoost yang diberikan serta logika prapemrosesan yang digunakan untuk waktu pelatihan dan inferensi. Itu buku catatan kedua menunjukkan bagaimana kami mempersiapkan artefak yang diperlukan untuk penerapan di Triton.

Buku catatan pertama menunjukkan buku catatan yang ada yang dimiliki organisasi Anda yang menggunakan CEPAT suite perpustakaan dan kernel RAPIDS Conda. Instans ini berjalan pada jenis instans G4DN yang disediakan oleh AWS, yang dipercepat GPU dengan menggunakan prosesor NVIDIA T4.

Tugas prapemrosesan dalam contoh ini mendapat manfaat dari akselerasi GPU dan banyak menggunakan pustaka cuML dan cuDF. Contohnya adalah dalam kode berikut, di mana kami menunjukkan pengkodean label kategoris menggunakan cuML. Kami juga menghasilkan label_encoders.pkl file yang dapat kita gunakan untuk membuat serial encoder dan menggunakannya untuk preprocessing selama waktu inferensi.

Notebook pertama diakhiri dengan melatih model XGBoost kami dan menyimpan artefak yang sesuai.

Dalam skenario ini, kode pelatihan sudah ada dan tidak ada perubahan yang diperlukan untuk model pada waktu pelatihan. Selain itu, meskipun kami menggunakan akselerasi GPU untuk prapemrosesan selama pelatihan, kami berencana menggunakan CPU untuk prapemrosesan pada waktu inferensi. Kami menjelaskan lebih lanjut nanti di posting.

Sekarang mari kita beralih ke notebook kedua dan mengingat apa yang kita butuhkan untuk penerapan Triton yang sukses.

Pertama, kita membutuhkan artefak model yang dibutuhkan oleh backend. File yang perlu kita buat untuk ensemble ini meliputi:

• Artefak pra-pemrosesan (model.py, label_encoders.pkl)
• Artefak model XGBoost (xgboost.json)

Backend Python di Triton mengharuskan kita untuk menggunakan lingkungan Conda sebagai ketergantungan. Dalam hal ini, kami menggunakan backend Python untuk melakukan praproses data mentah sebelum memasukkannya ke dalam model XGBoost yang dijalankan di backend FIL. Meskipun awalnya kami menggunakan pustaka RAPIDS cuDF dan cuML untuk melakukan prapemrosesan data (seperti yang dirujuk sebelumnya menggunakan GPU kami), di sini kami menggunakan Pandas dan Scikit-learn sebagai dependensi prapemrosesan untuk waktu inferensi (menggunakan CPU kami). Kami melakukan ini karena tiga alasan:

• Untuk menunjukkan cara membuat lingkungan Conda untuk dependensi Anda dan cara mengemasnya di format yang diharapkan oleh backend Python Triton.
• Dengan menunjukkan model prapemrosesan yang berjalan di backend Python pada CPU sementara model XGBoost berjalan di GPU di backend FIL, kami menggambarkan bagaimana setiap model dalam pipa ensemble Triton dapat berjalan pada kerangka kerja yang berbeda backend, dan berjalan pada perangkat keras yang berbeda dengan berbeda konfigurasi.
• Ini menyoroti bagaimana perpustakaan RAPIDS (cuDF, cuML) kompatibel dengan rekan-rekan CPU mereka (Panda, Scikit-learn). Dengan cara ini, kita dapat menunjukkan caranya LabelEncoders dibuat dalam cuML dapat digunakan di Scikit-belajar dan sebaliknya. Perhatikan bahwa jika Anda mengharapkan untuk memproses data tabular dalam jumlah besar selama waktu inferensi, Anda masih dapat menggunakan RAPIDS untuk mempercepat GPU.

Ingatlah bahwa kami menciptakan label_encoders.pkl file di buku catatan pertama. Tidak ada lagi yang bisa dilakukan untuk pengkodean kategori selain memasukkannya ke dalam . kami model.py file untuk pra-pemrosesan.

Untuk membuat file model.py yang diperlukan oleh backend Triton Python, kami mematuhi: pemformatan yang diperlukan oleh backend dan sertakan logika Python kami untuk memproses tensor yang masuk dan menggunakan encoder label yang dirujuk sebelumnya. Anda dapat meninjau fillet digunakan untuk preprocessing.

Untuk model XGBoost, tidak ada lagi yang perlu dilakukan. Kami melatih model di notebook pertama dan backend FIL Triton tidak memerlukan upaya tambahan untuk model XGBoost.

Selanjutnya, kita memerlukan file konfigurasi Triton. Setiap model dalam ansambel Triton membutuhkan: config.pbtxt mengajukan. Selain itu, kami juga membuat config.pbtxt file untuk ansambel secara keseluruhan. File-file ini memungkinkan Triton untuk mengetahui metadata tentang ensemble dengan informasi seperti input dan output yang kami harapkan serta membantu mendefinisikan DAG yang terkait dengan ensemble.

Terakhir, untuk menerapkan model di Triton, kita memerlukan folder repositori model kita untuk memiliki struktur folder yang tepat. Triton memiliki persyaratan khusus untuk tata letak repositori model. Dalam direktori repositori model tingkat atas, setiap model memiliki sub-direktori sendiri yang berisi informasi untuk model yang sesuai. Setiap direktori model di Triton harus memiliki setidaknya satu sub-direktori numerik yang mewakili versi model. Untuk kasus penggunaan kami, struktur yang dihasilkan akan terlihat seperti berikut.

Setelah kami memiliki tiga prasyarat ini, kami membuat file terkompresi sebagai kemasan untuk penyebaran dan mengunggahnya ke Layanan Penyimpanan Sederhana Amazon (Amazon S3).

Kami sekarang dapat membuat model SageMaker dari repositori model yang kami unggah ke Amazon S3 pada langkah sebelumnya.

Pada langkah ini, kami juga menyediakan variabel lingkungan tambahan SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, yang menentukan nama model yang akan dimuat oleh Triton. Nilai kunci ini harus cocok dengan nama folder dalam paket model yang diunggah ke Amazon S3. Variabel ini opsional dalam kasus model tunggal. Dalam hal model ansambel, kunci ini harus ditentukan agar Triton dapat memulai di SageMaker.

Selain itu, Anda dapat mengatur SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT dan SAGEMAKER_TRITON_THREAD_COUNT untuk mengoptimalkan jumlah thread. Kedua nilai konfigurasi membantu menyesuaikan jumlah utas yang berjalan pada CPU Anda, sehingga Anda dapat memperoleh pemanfaatan yang lebih baik dengan meningkatkan nilai ini untuk CPU dengan jumlah inti yang lebih banyak. Dalam sebagian besar kasus, nilai default sering kali berfungsi dengan baik, tetapi mungkin ada baiknya bereksperimen untuk melihat apakah efisiensi lebih lanjut dapat diperoleh untuk beban kerja Anda.

Dengan model sebelumnya, kita membuat konfigurasi titik akhir di mana kita dapat menentukan jenis dan jumlah instance yang kita inginkan di titik akhir.

Terakhir, kami menggunakan konfigurasi titik akhir sebelumnya untuk membuat titik akhir SageMaker baru dan menunggu penerapan selesai. Statusnya berubah menjadi InService setelah penyebaran berhasil.

Itu dia! Titik akhir Anda sekarang siap untuk pengujian dan validasi. Pada titik ini, Anda mungkin ingin menggunakan berbagai alat untuk membantu mengoptimalkan jenis dan konfigurasi instans Anda untuk mendapatkan performa terbaik. Gambar berikut memberikan contoh keuntungan yang dapat dicapai dengan menggunakan backend FIL untuk model XGBoost di Triton.

Kesimpulan

Dalam posting ini, kami memandu Anda dalam menerapkan beban kerja ansambel XGBoost ke SageMaker dengan Server Inferensi Triton. Memindahkan beban kerja ke Triton di SageMaker dapat menjadi pengembalian investasi yang menguntungkan. Seperti halnya adopsi teknologi, proses dan rencana pemeriksaan adalah kuncinya, dan kami merinci proses lima langkah untuk memandu Anda melalui apa yang harus dipertimbangkan saat memindahkan beban kerja Anda. Selain itu, kami mendalami langkah-langkah yang diperlukan untuk menerapkan ansambel yang menggunakan prapemrosesan Python dan model XGBoost di Triton di SageMaker.

SageMaker menyediakan alat untuk menghapus pekerjaan berat yang tidak terdiferensiasi dari setiap tahap siklus hidup ML, sehingga memfasilitasi eksperimen dan eksplorasi cepat yang diperlukan untuk mengoptimalkan penerapan model Anda sepenuhnya. Dukungan hosting SageMaker untuk Triton Inference Server memungkinkan beban kerja transaksi per detik (TPS) dengan latensi rendah.

Anda dapat menemukan buku catatan yang digunakan untuk contoh ini di GitHub.

---

Tentang Penulis

James Taman adalah Arsitek Solusi di Amazon Web Services. Dia bekerja dengan Amazon.com untuk merancang, membangun, dan menerapkan solusi teknologi di AWS, dan memiliki minat khusus pada AI dan pembelajaran mesin. Di waktu luangnya, ia senang mencari budaya baru, pengalaman baru, dan mengikuti perkembangan teknologi terkini.

Jia Hong Liu adalah Arsitek Solusi di tim Penyedia Layanan Cloud di NVIDIA. Dia membantu klien dalam mengadopsi pembelajaran mesin dan solusi AI yang memanfaatkan komputasi akselerasi NVIDIA untuk mengatasi tantangan pelatihan dan inferensi mereka. Di waktu senggang, ia menikmati origami, proyek DIY, dan bermain basket.

Kshitiz Gupta adalah Arsitek Solusi di NVIDIA. Dia senang mendidik pelanggan cloud tentang teknologi GPU AI yang ditawarkan NVIDIA dan membantu mereka mempercepat pembelajaran mesin dan aplikasi pembelajaran mendalam mereka. Di luar pekerjaan, ia menikmati lari, hiking, dan mengamati satwa liar.

Bruno Aguiar de Melo adalah Insinyur Pengembangan Perangkat Lunak di Amazon.com, di mana dia membantu tim sains untuk membangun, menerapkan, dan melepaskan beban kerja ML. Dia tertarik pada aspek instrumentasi dan yang dapat dikontrol dalam fase pemodelan/desain ML yang harus dipertimbangkan dan diukur dengan pemahaman bahwa kinerja eksekusi model sama pentingnya dengan kinerja kualitas model, terutama dalam kasus penggunaan yang dibatasi latensi. Di waktu luangnya, ia menikmati anggur, permainan papan, dan memasak.

Eliut Triana adalah Manajer Hubungan Pengembang di NVIDIA. Dia menghubungkan pemimpin produk, pengembang, dan ilmuwan Amazon dan AWS dengan teknologi dan pemimpin produk NVIDIA untuk mempercepat beban kerja Amazon ML/DL, produk EC2, dan layanan AI AWS. Selain itu, Eliuth adalah pengendara sepeda gunung, pemain ski, dan pemain poker yang bersemangat.