Ketergantungan perangkat keras — apa itu dan mengapa itu menjadi masalah [Q&A]

Kami saat ini berada di tengah kekurangan chip global, sementara pada saat yang sama perusahaan perangkat keras besar seperti Intel, NVIDIA, dan Arm ingin mendominasi pasar perangkat keras untuk aplikasi AI dan ML.

Ini menciptakan masalah di mana model harus disetel dan dioptimalkan sesuai dengan spesifikasi perangkat keras dan kerangka kerja perangkat lunak tertentu, mengorbankan portabilitas yang telah diterima begitu saja oleh industri..

Kami berbicara dengan Jason Knight, CPO di OctoML, untuk mencari tahu mengapa ketergantungan perangkat keras menjadi masalah seperti itu.

BN: Bisakah Anda menjelaskan apa yang Anda maksud saat mengatakan ‘ketergantungan perangkat keras’ sehubungan dengan penerapan model dan aplikasi ML?

JK: Umumnya, saat model ML dibuat dan dilatih, hal itu dilakukan oleh ilmuwan data menggunakan perangkat lunak dan perangkat keras yang cocok untuk menangani komputasi dan data dalam jumlah besar. Ini menciptakan ketergantungan implisit dan eksplisit antara perangkat keras, tempat model dilatih dan tempat model dapat diterapkan.

Mari kita ambil contoh ini: Python adalah lingua-franca pelatihan ML hari ini, tetapi pengembang mungkin ingin menerapkan model itu ke perangkat atau basis kode di mana Python bukan pilihan yang baik. Karena bahasa yang ditafsirkan seperti Python jarang digunakan dalam konteks tersemat dan seluler, pengembang mungkin tidak dapat menerapkan model sama sekali tanpa mengeluarkan upaya porting yang signifikan.

Ketergantungan perangkat keras yang lebih halus muncul saat model ‘cukup cepat’ saat dijalankan pada perangkat keras tempat ia dilatih, tetapi terlalu lambat — atau tidak cocok sama sekali — pada perangkat yang ingin Anda terapkan model dan aplikasi Anda. Masalah kinerja dapat berasal dari kinerja teoretis mentah yang tidak cukup tinggi – misalnya di mana mesin kuantisasi tertentu tidak ada – atau lebih halus: implementasi perangkat lunak dari operator yang Anda andalkan (dan bekerja dengan baik) saat membangun model memberikan kinerja yang lebih rendah pada perangkat target Anda karena keterbatasan perangkat lunak, berlawanan dengan keterbatasan perangkat keras.

Ketergantungan lebih lanjut juga dapat diperkenalkan oleh tumpukan perangkat lunak yang mengelilingi eksekusi model. Misalnya, Anda mungkin terbiasa dengan penginstalan dan dukungan driver perangkat vendor GPU dan batasan pustaka, hanya untuk mengalami masalah saat beralih ke tumpukan vendor lain dan sekarang kehilangan penghitung kinerja, kemampuan debug, atau karakteristik pelambatan termal yang Anda gunakan ke platform perangkat keras lain.

Semua faktor ini digabungkan untuk menciptakan penghalang yang sangat tinggi bagi pengembang, tim, atau perusahaan untuk beralih dari satu platform dalam pelatihan ke platform lain untuk penerapan (atau bermigrasi dari satu platform penerapan ke platform lainnya).

BN: Apa akibat dari ketergantungan ini?

JK: Pandangan 30.000 kaki adalah kurangnya kelincahan memperlambat inovasi. Kita semua sangat setuju bahwa ML bukan lagi konsep ‘visioner’. Bisnis memperoleh nilai bisnis praktis, dan meningkatkan investasi setiap tahun. ML membantu memajukan ilmu pengetahuan dan perawatan kesehatan. Namun, kami mencapai titik pengembalian yang semakin berkurang. ROI bisa lebih besar; kecepatan ML membantu mengungkap terobosan di area yang disebutkan di atas bisa lebih cepat.

Namun, sumber daya/biaya/waktu yang diperlukan untuk menerapkan ML mendorong bisnis untuk lebih fokus pada anggaran daripada inovasi — terutama mengingat ekonomi saat ini. Dan ini tidak mengherankan mengingat 90 persen biaya komputasi ML terkait dengan beban kerja produksi inferensi.

Hal ini membuat banyak orang di industri menggaruk-garuk kepala bertanya-tanya: mengapa kita tidak memiliki opsi hemat biaya untuk mengubah model pada kinerja puncak seperti yang kita lakukan dengan pengembangan perangkat lunak standar di cloud? Ini adalah masalah utama yang kami hadapi di industri ML saat ini.

BN: Adakah perangkat lunak yang ‘dibangun ke dalam’ perangkat keras tertentu? Apakah itu tidak cukup?

JK: Bahkan di dunia yang sempurna, di mana semua perangkat lunak ML yang disediakan vendor perangkat keras memberikan kinerja optimal untuk setiap beban kerja ML dan memiliki setiap fitur yang diinginkan pengembang, masih ada batasan perangkat keras seperti ukuran memori, lebar pita memori, kecepatan komputasi, dukungan format kuantisasi , dll. yang menciptakan penghalang antara memindahkan model ML antara satu platform perangkat keras dan lainnya. Ada juga biaya peralihan yang dijelaskan di atas antara pelatihan dan penerapan ekosistem perangkat lunak.

Dan mari kita perjelas: perangkat lunak ML di semua level tumpukan jauh dari sempurna. Bidang bergerak dengan cepat dan pencarian untuk menyatu pada pola perangkat lunak bersama/optimal masih dalam proses. Kami masih jauh dari ML yang setara dengan POSIX, x86, tumpukan jaringan OSI, HTTP, atau konvergensi API universal lainnya yang telah terjadi dalam sejarah komputasi. Dan sebagai hasilnya, masih banyak titik kasar dalam implementasi yang Anda temukan karena vendor perangkat keras berjuang untuk mengikuti kecepatan inovasi.

BN: Bagaimana praktisi ML dapat memutuskan ketergantungan ini?

JK: Jalan pintas yang digunakan sebagian besar praktisi ML saat ini (sedapat mungkin) adalah mengatasi masalah dengan mencoba mempertahankan lingkungan pelatihan (baik perangkat lunak maupun perangkat keras) yang semirip mungkin dengan lingkungan penerapan Anda. Namun, ini seringkali mahal (perangkat keras yang terlalu besar/khusus pada saat penerapan) dan banyak praktisi tidak memiliki pilihan ini. ‘Solusi’ ini adalah salah satu alasan mengapa NVIDIA begitu kuat di pasar ML pada umumnya: penetrasi pasar mereka yang tinggi dalam pelatihan ML menempatkan pusat ‘massa ekosistem ML’ sangat menguntungkan mereka.

Untuk menghentikan ketergantungan, kami memerlukan abstraksi yang lebih baik antara praktisi ML dan perangkat keras yang mereka andalkan. Ini akan memakan waktu (seperti yang dilakukan semua konsolidasi industri) dan dua kali lipat karena laju inovasi dalam ML masih sangat cepat. Saya berharap kita akan melihat upaya yang paling terkonsentrasi untuk menghentikan upaya datang dari penyedia cloud (yang ingin pengguna mereka memigrasikan beban kerja ML komputasi yang berat ke platform komputasi milik mereka yang semakin meningkat) dan memotivasi startup yang mampu menerapkan solusi inovatif untuk berkreasi abstraksi baru ini. Salah satu contohnya adalah OctoML, yang menggunakan pembelajaran mesin untuk mengembangkan pengalaman perangkat lunak ML portabel bagi pengguna untuk mengambil model dan mengoptimalkannya untuk berbagai perangkat keras.

BN: Apakah menurut Anda ini adalah masalah yang dapat diatasi sekarang atau akan memakan waktu beberapa tahun?

JK: Kami dapat membuat terobosan signifikan dengan upaya terfokus dengan mengabstraksi beberapa kerumitan ini untuk pengguna. Tetapi untuk industri yang lebih luas untuk bersatu pada satu atau dua API/kerangka kerja/standar terbuka akan memakan waktu lima tahun lebih, jika pernah.

Untuk melihat bagaimana ini bisa terjadi, lihat industri komputasi terdistribusi di mana kami memiliki Kubernetes sebagai standar defacto saat ini, namun masih ada sejumlah besar inovasi yang terjadi dalam domain Fungsi-sebagai-Layanan untuk melampaui Kubernetes sebagai API untuk menerapkan beban kerja web. Atau lebih jauh lagi ke industri basis data yang baru-baru ini melihat ledakan NoSQL dan sekarang menghosting platform data lake seperti Snowflake.

BN: Pada akhirnya, apa yang akan dimungkinkan oleh kemandirian perangkat keras?

JK: Kemandirian perangkat keras akan memungkinkan inovasi yang lebih cepat dalam aplikasi cerdas. Saat ini kemampuan untuk meluncurkan aplikasi AI yang canggih seperti ChatGPT, StableDiffusion, atau AlphaZero hanya tersedia untuk teknolog paling berbakat dengan kantong tebal untuk melayani model besar pada perangkat keras yang mahal. Kemandirian perangkat keras yang sebenarnya akan memungkinkan abstraksi yang lebih baik untuk pengembang aplikasi yang menurunkan kompleksitas dan biaya penerapan ML. Ini terutama akan membuka inovasi untuk ML di edge, di mana berbagai perangkat keras akselerasi ML baru saja muncul tetapi masih terkunci di belakang (seringkali) API eksklusif dan implementasi yang memperlambat laju inovasi.

Kredit gambar: Alexmit/depositphotos.com