Pola umum yang kami amati adalah bahwa pembuatan dan penerapan model ML tujuan produksi dilakukan oleh tim yang berbeda, biasanya tim algoritme ML dan tim operasi perangkat. Tim ML menangani pelatihan dan evaluasi model, sedangkan tim perangkat bertanggung jawab untuk memigrasikan model ke lingkungan produksi.

Pemisahan seperti itu sebagian disebabkan oleh fakta bahwa pelatihan dan inferensi telah menyimpang, mengenai platform perangkat keras dan kumpulan perangkat lunak. Sebelumnya, kami menggunakan Caffe di server GPU untuk pelatihan dan penyajian. Saat ini, orang menggunakan alat dan server canggih untuk pelatihan, lalu menerapkan model ke runtime yang sangat optimal dan beragam perangkat. Masalah penerapan sering ditemui karena kompleksitas model dan keterbatasan perangkat keras, dan tim ML biasanya perlu mengandalkan masukan dari tim operasi perangkat untuk menyelesaikan masalah ini.

Akibatnya, teknisi Machine Learning (MLE) sering kali tidak memiliki wawasan yang sangat mendasar tentang penerapan model mereka sendiri. Penyebaran model saat ini sering kali merupakan pipa buatan sendiri yang terdiri dari beberapa skrip Bash/Python yang tersebar di berbagai mesin dan lingkungan. Ini juga melibatkan beberapa pustaka sumber terbuka atau perangkat khusus vendor untuk konversi model, kuantisasi, penyetelan kinerja, dan verifikasi akurasi. Ini bukan pengalaman yang menyenangkan, dibandingkan dengan pengembangan model di lingkungan Python cloud-native.

Selain kerumitan perkakas, kurangnya interpretasi kinerja adalah masalah lain. Pembuatan profil laporan dari rantai alat hilir sering kali memerlukan pengetahuan domain untuk dipahami dan diubah menjadi wawasan model yang dapat ditindaklanjuti, seperti dalam contoh TensorRT berikut. Seiring dengan alur konversi model yang panjang, sulit bagi pengembang ML untuk mengidentifikasi kemacetan kinerja sebenarnya dari model mereka sendiri dan membuat perubahan yang tepat.

Terlepas dari kelemahan-kelemahan ini, pemisahan antara merancang dan menerapkan model masih menjadi norma di industri, karena biasanya membutuhkan keahlian yang sama sekali berbeda. “Sulit untuk menyewa ahli ML atau ahli perangkat, apalagi ahli dari keduanya”, itulah yang terus kami dengar dari pelanggan kami. Namun bukan berarti kita harus tetap mentolerir alur kerja ML saat ini.

Dalam Perangkat Lunak 1.0, sulit membayangkan bahwa sebuah program ditulis oleh seorang insinyur dan dikompilasi oleh insinyur lain. Pemrogram dapat mengkompilasi kode sendiri, dengan sedikit atau tanpa pengetahuan tentang tahapan dasar seperti perakitan dan penautan, sambil tetap dapat memperoleh wawasan yang berarti untuk memperbaiki kode mereka. Tanpa wawasan seperti itu, proses debug bisa menjadi bolak-balik tanpa akhir antara dua insinyur yang tidak berbicara bahasa satu sama lain.

Sejauh ini, masalah paling umum yang kami lihat yang menunda penerapan model ML adalah:

1. Latensi/throughput yang tidak dapat ditolerir
2. Operator tidak didukung
3. Ketidakcocokan akurasi

Alur kerja yang sederhana dan mudah dipahami untuk penerapan dan diagnosis model adalah solusinya. Antarmuka yang dapat digunakan dan dipahami oleh teknisi ML sendiri akan sangat meningkatkan produktivitas.

Membangun kompiler ML yang sangat kuat hanyalah bagian dari solusi, karena ada beberapa perbedaan mendasar antara Perangkat Lunak 2.0 dan Perangkat Lunak 1.0: pertama, operator baru terus diluncurkan dari akademisi dan banyak di antaranya tidak dapat disusun dari operator yang sudah ada; kedua, model ML dapat mentolerir penggantian operator yang tidak mempertahankan fungsi dan tetap mempertahankan akurasi yang sama, yang memberikan lebih banyak fleksibilitas penyesuaian untuk pengembang ML. Namun, kami tidak akan membahas detailnya, karena mungkin ada baiknya membuat blog terpisah untuk membahas tentang penyesuaian model untuk penerapan.

Di OmniML , kami memulai dengan membuat alat internal bagi teknisi kami untuk menerapkan dan membuat profil model ML mereka tanpa perlu repot mempelajari perangkat keras dan rantai alat ML-nya. Kami segera menyadari peningkatan kinerja alat tersebut. Selain itu, antarmuka terpadu dan kaya informasi ini memungkinkan manusia dan algoritme untuk membuka peluang pengoptimalan model yang hebat. Oleh karena itu, fitur tersebut kini tersedia secara resmi di produk OmniML: Omnimizer dan Omnimizer Enterprise .

Omnimizer — platform pengoptimalan dan penyebaran model terpadu

Omnimizer terutama dirancang untuk insinyur ML yang mendesain dan melatih model PyTorch. Ini membantu mereka mengidentifikasi cacat desain dan mengurangi waktu produksi.

Omnimizer menyediakan antarmuka PyTorch-native dan cloud-native untuk menguji model dengan cepat pada perangkat keras target. Pengguna hanya perlu menentukan konfigurasi penerapan tingkat tinggi, lalu mengirim permintaan ke cloud perangkat yang dihosting OmniML. Informasi penerapan utama, termasuk latensi keseluruhan, latensi berlapis, dan kesalahan penerapan (jika ada), akan dilaporkan kembali dengan cara paling sederhana yang dapat dipahami oleh pakar non-perangkat keras.

Omnimizer memungkinkan pengguna untuk membandingkan akurasi pada perangkat dengan model aslinya dengan mudah. Ini menghilangkan kerepotan mentransfer model dan data ke perangkat yang berbeda, membiasakan diri dengan OS dan rantai alat yang berbeda, dan memelihara banyak skrip yang tidak teratur dan dipenuhi bug. Dalam contoh berikut, pengguna bisa mendapatkan keluaran model dalam antarmuka mirip PyTorch, sementara inferensi sebenarnya terjadi pada perangkat jarak jauh, misalnya GPU kelas server atau smartphone.

Omnimizer bukan hanya pustaka perangkat lunak, tetapi juga platform MLOps yang menyediakan antarmuka ramah pengguna untuk menavigasi detail kinerja, berbagi wawasan model, dan mereproduksi lingkungan penerapan. Pengguna dapat melihat langkah-langkah penerapan, mendapatkan latensi pembandingan, dan mendapatkan pemahaman yang lebih baik tentang model mereka di perangkat keras.

Omnimizer Enterprise — Keluarkan potensi penuh perangkat keras AI

Dibandingkan dengan versi komunitas yang membantu penerapan dan pengoptimalan model, versi perusahaan menyediakan pengoptimalan model otomatis berdasarkan penelitian bertahun-tahun tentang Neural Architecture Search (NAS) dan penyesuaian ekstensif untuk kebutuhan perusahaan.

NAS selalu dianggap sebagai proses mahal yang membutuhkan keahlian mendalam dalam ruang pencarian dan desain tugas proxy. Dengan Omnimizer, setiap pengguna dapat menerapkan NAS untuk menyesuaikan model mereka untuk perangkat keras target. Proses ini hanya memerlukan beberapa baris perubahan kode, biaya pelatihan rendah, dan yang terpenting, tidak perlu menjadi ahli dalam desain model dan kinerja perangkat keras.

Omnimizer dapat dengan mudah diintegrasikan dengan repositori sumber terbuka dan mempercepat model siap pakai dengan sedikit pengoptimalan manual. Sejauh ini OmniML dan pelanggannya telah mendemonstrasikan peningkatan kecepatan 1,2–6,8x pada platform NVIDIA dan Qualcomm. Repositori ini akan terbuka untuk pengguna perusahaan sebagai contoh:

• YOLO-X (deteksi objek)
• EfficientDet (deteksi objek)
• YOLO-P (model multitugas untuk berkendara otonom)
• DDRNet (segmentasi semantik)
• ResNet (klasifikasi gambar)
• DD3D (deteksi objek 3D)
• RAFT (aliran optik)
• DistiBERT (terjemahan mesin)

Coba Omnimizer!

Omnimizer Beta baru saja dirilis. Daftar sekarang di situs web OmniML dan mulai optimalkan alur kerja Anda!

Di Wu, Song Han, Lucas Liebenwein, Riyad Islam, Keval Morabia, 
Asma K.T. Beevi, Henry Guo and Shengliang Xu also contributed to this article.