Analisis teknikal dan perkongsian amalan: mod pengguna dan mod kernel dalam virtualisasi bekas GPU dwi-enjin

​Cara memaksimumkan kecekapan kuasa pengkomputeran perkakasan adalah perkara yang sangat membimbangkan semua pengendali dan pengguna sumber. Sebagai syarikat AI terkemuka, Baidu mungkin mempunyai senario aplikasi AI yang paling komprehensif dalam industri.

Dalam artikel ini, kami akan berkongsi dan membincangkan penyelesaian virtualisasi kontena GPU dalam senario AI kompleks dan amalan terbaik di kilang.

Bahagian kiri dan kanan gambar di bawah telah ditunjukkan berkali-kali pada masa yang berbeza Tujuan utama meletakkannya di sini adalah untuk menekankan permintaan kuasa pengkomputeran - pertumbuhan eksponen kuasa pengkomputeran perkakasan dan penggunaan. dalam senario aplikasi sebenar Percanggahan antara kecekapan rendah dan pembaziran sumber.

Bahagian di sebelah kiri ialah statistik dari OpenAI Sejak 2012, kuasa pengkomputeran yang diperlukan untuk latihan model telah meningkat dua kali ganda setiap 3.4 bulan Berbanding model besar seperti AlphaGoZero, kuasa pengkomputeran latihan telah meningkat 300,000 kali. dan trend itu berterusan. Di satu pihak, apabila permintaan untuk kuasa pengkomputeran meningkat, prestasi pengkomputeran unit pecutan AI arus perdana juga meningkat dua kali ganda setiap dua tahun. Sebaliknya, kecekapan penggunaan sumber mengehadkan penggunaan penuh prestasi perkakasan.

Bahagian di sebelah kanan ialah hasil analisis beban pembelajaran mesin pusat data Facebook pada tahun 2021. Sebilangan besar kuasa pengkomputeran AI hilang dalam pautan seperti kegagalan, penjadualan, pembaziran masa dan pembaziran unit ruang, dan penggunaan kuasa pengkomputeran sebenar adalah kurang daripada 30%. Kami percaya bahawa ini juga situasi semasa yang dihadapi oleh pengendali infrastruktur domestik utama.

Saya baru sebutkan bahawa kadar penggunaan kluster dalam talian adalah kurang daripada 30%, yang mungkin tidak selari dengan persepsi ramai pelajar. Ramai pelajar dalam talian mungkin pembangun model dan algoritma. Pemahaman umum kami ialah penggunaan boleh kekal sangat tinggi semasa latihan dan ujian, malah boleh mencapai 100% penggunaan.

Namun, apabila model itu dilancarkan dalam persekitaran pengeluaran, ia akan tertakluk kepada banyak kekangan ini menyebabkan kadar penggunaan jatuh jauh daripada jangkaan kami. ​

Mari gunakan ruang terhad untuk meringkaskan kekangan utama:

• Ciri model: Setiap rangkaian model adalah berbeza, dan gabungan pengendali asas yang dipanggil adalah berbeza, pada tahap yang besar menjejaskan penggunaan GPU.
• SLA Perkhidmatan: Perkhidmatan dalam senario yang berbeza memerlukan SLA yang berbeza mempunyai keperluan masa nyata yang tinggi malah perlu dikawal dengan ketat dalam masa 10ms Kemudian perkhidmatan ini tidak boleh meningkatkan penggunaan dengan meningkatkan saiz kelompok 1.
• Corak trafik: Algoritma model yang berbeza menyediakan senario aplikasi yang berbeza, seperti pengecaman OCR, yang mungkin sering dipanggil semasa bekerja. Pengecaman pertuturan lebih kerap dipanggil semasa masa berulang-alik atau hiburan dan masa lapang, yang membawa kepada turun naik puncak dan lembah dalam penggunaan GPU sepanjang hari.
• Kesan pengoptimuman: Bergantung pada kekerapan lelaran model dan senario liputan, butiran pengoptimuman model juga berbeza. Boleh dibayangkan bahawa kadar penggunaan model yang tidak dioptimumkan sepenuhnya sukar untuk mencapai tahap yang tinggi.
• Lewahan kapasiti: Sebelum model disiarkan dalam talian, perancangan kapasiti terperinci mesti dijalankan apakah jumlah trafik maksimum dan sama ada beberapa wilayah diperlukan dalam proses ini, lebihan kapasiti akan dikhaskan yang sukar untuk diabaikan .Penyeledahan ini sukar diabaikan pada masa biasa Ia juga menyebabkan pembaziran kuasa pengkomputeran.

Di bawah kekangan kekangan di atas, kadar penggunaan persekitaran pengeluaran sebenar mungkin yang ingin kami tunjukkan seterusnya. Kami mengabstrak corak penggunaan ini daripada persekitaran pengeluaran dalam talian yang kompleks dan berubah-ubah.

• Jenis min rendah: Seperti yang ditunjukkan dalam rajah kiri atas, ia adalah perniagaan inferens dalam talian yang sebenar Disebabkan oleh pengehadan ciri model dan SLA perkhidmatan, penggunaan puncak GPU hanya 10%, dan penggunaan purata akan menjadi lebih rendah.
• Jenis turun naik puncak dan lembah: Seperti yang ditunjukkan dalam rajah di bawah, ia adalah corak penggunaan biasa perniagaan inferens dalam talian Perkhidmatan ini akan mencapai kemuncak pada siang hari, dan penggunaannya akan berada di palung mulai lewat malam ke pagi berikutnya Purata penggunaan sepanjang hari Kadar penggunaan hanya kira-kira 20%, dan kadar penggunaan yang rendah adalah kurang daripada 10%.
• Jenis lonjakan jangka pendek: Seperti yang ditunjukkan dalam gambar sebelah kanan atas, lengkung penggunaan pada asasnya adalah sama dengan gambar kiri bawah, tetapi akan terdapat dua puncak penggunaan yang jelas semasa waktu utama pada waktu malam, dan kadar penggunaan puncak adalah setinggi 80%. Untuk memenuhi Dari segi kualiti perkhidmatan semasa peringkat puncak, perkhidmatan akan menempah penimbal yang besar semasa proses penggunaan, dan penggunaan sumber purata hanya melebihi 30%.
• Jenis pencetus berkala: Seperti yang ditunjukkan dalam gambar di sebelah kanan, ini ialah mod penggunaan senario latihan dalam talian biasa Tugas latihan dalam talian adalah antara latihan luar talian dan inferens dalam talian . Sebagai contoh, kumpulan data tiba setiap 15 minit, tetapi latihan kumpulan data ini hanya mengambil masa 2-3 minit dan GPU melahu untuk masa yang banyak.

Senario aplikasi AI adalah kompleks dan boleh diubah di atas hanya menyenaraikan empat senario biasa. Cara mengimbangi prestasi perniagaan dan kecekapan sumber dalam senario yang kompleks ialah cabaran pertama yang kami hadapi dalam virtualisasi GPU.

Cabaran kedua yang kami hadapi dalam proses virtualisasi GPU ialah kekurangan mekanisme pengasingan dan pencampuran GPU yang lengkap.

Kami mengambil GPU NVIDIA arus perdana semasa sebagai contoh. Ekosistem perisian dan perkakasan AI biasa dibahagikan kepada beberapa peringkat - lapisan aplikasi & rangka kerja, lapisan masa jalan, lapisan pemacu dan lapisan perkakasan.

Pertama sekali, lapisan atas ialah aplikasi pengguna, yang merangkumi pelbagai rangka kerja biasa seperti PaddlePaddle, TensorFlow, PyTorch, dll. Di bawah lapisan aplikasi ialah lapisan antara muka API yang dikapsulkan oleh pembekal perkakasan, termasuk pelbagai perpustakaan pengendali biasa dan antara muka akses masa jalan perkakasan. Di bawah lapisan antara muka API ini ialah lapisan pemacu yang berkomunikasi dengan perkakasan Lapisan ini terletak dalam keadaan kernel dan merupakan lapisan antara muka perisian yang berkomunikasi secara langsung dengan peranti. Di bahagian bawah ialah perkakasan pecutan AI sebenar, yang bertanggungjawab untuk pelaksanaan pengendali.

Penyelesaian virtualisasi tradisional dilaksanakan dengan menggabungkan keadaan kernel pemacu dan logik virtualisasi perkakasan. Kedua-dua tahap ini ialah IP teras pembekal perkakasan dan secara amnya adalah sumber tertutup. Seperti yang akan dinyatakan kemudian, mekanisme pengasingan asli GPU semasa tidak dapat memenuhi keperluan penggunaan dalam senario asli awan dari segi fleksibiliti dan kekuatan peruntukan.

Selain mekanisme pengasingan, mekanisme pengedaran hibrid yang sedia ada juga sukar untuk memenuhi keperluan senario yang kompleks Kami telah melihat bahawa terdapat banyak penyelesaian sumber terbuka untuk penjadualan sumber terbuka ini hanya menggabungkan dua tugasan dari peringkat sumber pada kad. Dalam senario sebenar, perkongsian mudah akan menyebabkan kesan bersama antara perniagaan, kelewatan ekor panjang dan juga kemerosotan daya pengeluaran, menjadikan perkongsian mudah tidak dapat diterapkan dengan benar dalam persekitaran pengeluaran.

Dalam bahagian analisis corak penggunaan di atas, kami melihat bahawa perniagaan yang berbeza dan senario yang berbeza mempunyai corak penggunaan yang berbeza. Cara mengabstraksi senario perniagaan dan menyesuaikan penyelesaian hibrid adalah kunci untuk melaksanakan persekitaran pengeluaran.

Untuk memberi pemahaman yang lebih menyeluruh tentang pembangunan GPU dan sejarah virtualisasi kepada semua orang, di sini kami menggunakan gambar untuk menunjukkan sejarah pembangunan virtualisasi GPU.

Aplikasi GPU dalam pengkomputeran umum boleh dikesan kembali ke seni bina Tesla era G80 Ia merupakan seni bina generasi pertama untuk melaksanakan pelorek bersatu Ia menggunakan pemproses tujuan umum untuk menggantikan grafik dan imej asal pemprosesan saluran paip puncak dan piksel yang berasingan.

GPU terawal yang diperkenalkan oleh Baidu boleh dikesan kembali kepada seni bina Fermi. Sejak ketika ini, beberapa penyelesaian virtualisasi telah muncul dalam industri, yang kebanyakannya memfokuskan pada rampasan API. Wakil biasa di sini ialah rCUDA, sebuah projek yang asalnya diselenggarakan oleh kumpulan akademik Sehingga baru-baru ini, ia telah mengekalkan kekerapan kemas kini dan lelaran tertentu, tetapi ia nampaknya terutamanya penyelidikan akademik dan belum digunakan secara meluas dalam persekitaran pengeluaran.

Pengenalan GPU berskala besar Baidu adalah berdasarkan seni bina Kepler, seni bina Kepler membuka era komputer AI super X-MAN yang dibangunkan sendiri oleh Baidu. X-MAN 1.0 melaksanakan konfigurasi 16 kad mesin tunggal buat kali pertama, dan boleh merealisasikan nisbah pengikatan dinamik dan fleksibel CPU dan GPU pada tahap perkakasan PCIe. Terhad oleh prestasi satu kad, lebih banyak pertimbangan pada masa itu adalah pengembangan dan bukannya pembahagian.

Prestasi seni bina Pascal, seni bina Volta dan seni bina Turing seterusnya telah bertambah baik dengan pesat, dan permintaan untuk virtualisasi semakin ketara. Kami melihat bahawa dari seni bina Kepler yang terawal, NV secara rasmi menyediakan penyelesaian virtualisasi GRID vGPU, yang pada mulanya disasarkan pada pemaparan grafik dan senario desktop jauh. Sekitar tahun 2019, penyelesaian turut disediakan untuk AI dan senario pengkomputeran berprestasi tinggi. Walau bagaimanapun, penyelesaian ini adalah berdasarkan mesin maya dan jarang digunakan dalam senario AI.

Dalam penjanaan Ampere, NV melancarkan penyelesaian pemisahan instance MIG, yang merealisasikan pemisahan berbilang sumber perkakasan seperti SM, MEM dan L2 Cache pada peringkat perkakasan, memberikan prestasi pengasingan perkakasan yang baik. Walau bagaimanapun, penyelesaian ini disokong bermula dari seni bina Ampere, dan terdapat sekatan tertentu pada model kad. Hanya beberapa model, A100 dan A30, boleh menyokongnya. Dan walaupun selepas menghiris, prestasi satu contoh melebihi kuasa pengkomputeran T4, dan tidak dapat menyelesaikan masalah kecekapan persekitaran pengeluaran semasa dengan baik.

Selepas semua orang mempunyai beberapa tanggapan tentang sejarah seni bina dan maya GPU, mari perkenalkan secara terperinci tahap utama, atau laluan teknikal, untuk merealisasikan virtualisasi GPU.

Untuk mencapai pengasingan virtualisasi sumber, anda memerlukan sumber untuk dipisahkan terlebih dahulu dalam dimensi masa atau ruang Dari perspektif pengguna, pelbagai tugas boleh dilaksanakan secara serentak atau selari.

Di sini kita membincangkan keselarian atau ruang konkurensi pada pelbagai peringkat mod pengguna, mod kernel dan perkakasan.

Memandangkan ekologi perisian dan perkakasan NV adalah sumber tertutup, gambarajah skematik di sini diambil daripada kertas putih seni bina komprehensif kami, kertas terbalik dan pemahaman kami sendiri Kami berharap semua orang akan membetulkan saya tepat pada masanya untuk sebarang ketidaktepatan.

Penyelesaian Mod Pengguna

Mari lihat gambar ini dari atas ke bawah Pertama sekali, berbilang proses secara semula jadi serentak dari perspektif GPU, iaitu pemultipleks pembahagian masa. Pemacu dan perkakasan bertanggungjawab untuk menukar tugas dalam putaran kepingan masa. Dengan menggunakan lapisan mekanisme ini, kami boleh melaksanakan pengehadan pada sumber pengkomputeran dan sumber memori video di peringkat API untuk mencapai kesan virtualisasi. API di sini boleh dibahagikan kepada dua lapisan Lapisan pertama ialah API pemacu Lapisan API ini dekat dengan pemacu dan merupakan satu-satunya cara untuk semua panggilan lapisan atas untuk mengakses GPU API, ia bersamaan dengan mengawal akses sumber pengguna. Biar saya nyatakan di sini bahawa teknologi MPS yang disediakan oleh NV boleh merealisasikan pemultipleksan bahagian spatial, yang juga menyediakan kemungkinan untuk mengoptimumkan lagi prestasi perniagaan. Kami akan mengembangkan secara terperinci dalam bahagian amalan pelaksanaan seterusnya.

Penyelesaian mod kernel

Lapisan bawah seterusnya ialah mod kernel, sama ada ia adalah virtualisasi penuh atau paravirtualisasi di peringkat mesin maya, atau penyelesaian kontena vendor awan utama dalam tempoh dua tahun lalu . Pemintasan panggilan sistem dan rampasan MMIO dilaksanakan pada lapisan kernel Kesukaran terbesar dalam keadaan kernel ialah banyak daftar dan tingkah laku MMIO tidak didokumenkan dengan baik, yang memerlukan kejuruteraan terbalik yang kompleks.

Penyelesaian perkakasan

Di bawah keadaan kernel ialah lapisan perkakasan dijamin pada lapisan ini, sama ada teknologi MIG NV atau teknologi SR-IOV Baidu Kunlun Kuasa pengkomputeran dibahagikan dalam logik perkakasan untuk mencapai keselarian sebenar dan pemultipleksan pembahagian ruang. Sebagai contoh, Kunlun boleh mencapai pembahagian perkakasan 1/3 dan 1/2, dan A100 boleh mencapai pembahagian sumber dengan butiran minimum 1/7.

Kami telah meluangkan banyak masa untuk memperkenalkan anda kepada cabaran dan situasi semasa virtualisasi GPU Seterusnya, mari lihat cara Baidu bertindak balas secara dalaman terhadap cabaran ini.

Gambar ini menunjukkan Baidu Smart Cloud - seni bina virtualisasi kontena GPU dwi-enjin.

Bekas ditekankan di sini kerana kami percaya bahawa pada masa hadapan, aplikasi pautan penuh AI secara beransur-ansur akan menumpu kepada platform asli awan untuk mencapai pembangunan kontena penuh, latihan dan inferens. Menurut penyelidikan Gartner, 70% daripada tugas AI akan digunakan dalam bekas pada tahun 2023. Pengkontenaan dalaman Baidu bermula pada tahun 2011, dan kini mempunyai lebih daripada 10 tahun pengalaman penggunaan dan pengoptimuman Kami juga komited untuk menyumbang bahagian keupayaan produk dan pengalaman pengoptimuman yang diasah dalam kehidupan sebenar kepada komuniti dan majoriti pengguna.

Enjin dwi juga dititikberatkan di sini. Dalam seni bina keseluruhan, kami menggunakan dua set enjin pengasingan, mod pengguna dan mod kernel, untuk memenuhi keperluan pengguna yang berbeza untuk pengasingan, prestasi, kecekapan dan aspek lain.

Di bahagian atas enjin pengasingan ialah lapisan pengumpulan sumber Lapisan ini berdasarkan pemahaman mendalam kami tentang sistem perisian dan perkakasan dan secara beransur-ansur melaksanakan penyahgandingan, keterpencilan dan pengumpulan sumber dipercepatkan AI infrastruktur masa hadapan.

Di bahagian atas lapisan pengumpulan sumber, terdapat lapisan penjadualan sumber bersatu Matrix/k8s (Matrix di sini ialah sistem penjadualan kontena di kilang Baidu, selain daripada mekanisme penjadualan, kami akan berdasarkan perniagaan yang berbeza). senario, Pelbagai strategi pencampuran disarikan, termasuk pencampuran kongsi, percampuran awal, percampuran perkongsian masa, percampuran pasang surut, dsb. Strategi pengedaran campuran ini akan diperluaskan secara terperinci dalam bahagian praktikal berikutnya.

Bergantung pada pengasingan sumber dan penjadualan sumber ialah senario pautan penuh perniagaan AI, termasuk pembangunan model, latihan model dan penaakulan dalam talian.

Seterusnya, saya akan berkongsi dengan anda masing-masing pelaksanaan mod pengguna dan enjin pengasingan mod kernel.

Rajah berikut ialah gambar rajah skema seni bina teras enjin pengasingan mod pengguna. Di bahagian atas rajah seni bina ialah aplikasi pengguna, yang merangkumi pelbagai rangka kerja yang biasa digunakan, seperti PaddlePaddle, TensorFlow, PyTorch, dsb.

Terletak di bawah aplikasi pengguna ialah satu siri antara muka API Hook Berdasarkan set antara muka ini, kami boleh merealisasikan penggunaan tempatan dan pemasangan jauh sumber GPU. Dengan menggantikan perpustakaan dinamik asas yang kerangka kerja bergantung pada, kawalan sumber dan pengasingan dicapai. Adalah penting untuk ambil perhatian bahawa penyelesaian ini benar-benar telus kepada aplikasi, dan operasi penggantian perpustakaan yang diperlukan telah dilengkapkan secara automatik oleh enjin kontena dan bahagian penjadualan.

CUDA API akhirnya akan sampai ke pelaksana melalui dua laluan selepas Hook. Di sini, sebahagian besar API, seperti API pengurusan peranti, tidak melakukan sebarang operasi selepas melalui Cangkuk dan terus melalui kepada pelaksana untuk pelaksanaan. Sebilangan kecil API yang berkaitan dengan aplikasi sumber akan melalui lapisan pemintasan, yang melaluinya satu siri fungsi virtualisasi ruang pengguna boleh dilaksanakan. Logik lapisan ini dilaksanakan dengan cukup cekap, dan kesan ke atas prestasi hampir boleh diabaikan.

Pada masa ini enjin pengasingan mod pengguna boleh menyediakan pelbagai fungsi pengasingan dan kawalan, termasuk pengasingan memori video asas dan pengasingan kuasa pengkomputeran. Kami juga telah mengembangkan banyak ciri lanjutan: pengasingan pengekod, preemption berkualiti tinggi, pengedaran berlebihan memori video, pengumpulan memori video, dsb. ​

Kelebihan penyelesaian mod pengguna ialah prestasi yang baik dan kependaman ekor panjang yang rendah Ia sesuai untuk senario perniagaan yang mengejar prestasi mekanisme dan kecekapan melampau, seperti perniagaan inferens dalam talian yang sensitif terhadap kelewatan. ​

Atas dasar pengasingan, kami menyediakan fungsi jauh Pengenalan alat kawalan jauh akan meningkatkan fleksibiliti konfigurasi sumber dan kecekapan penggunaan akhir artikel ini.

Perkongsian ini adalah perkongsian teknologi Di sini saya akan menggunakan sedikit ruang untuk mengembangkan perkara utama dan kesukaran teknologi jauh, dengan harapan dapat merangsang idea perniagaan dan perbincangan teknikal semua orang.

Menurut tindanan teknologi perisian dan perkakasan yang kami nyatakan dalam cabaran virtualisasi sebelumnya, akses jauh kepada GPU secara amnya boleh dilaksanakan pada lapisan pautan perkakasan, lapisan pemacu, lapisan masa jalan dan lapisan pengguna Walau bagaimanapun, selepas masuk -depth Berdasarkan analisis teknikal dan pemahaman senario perniagaan, kami percaya bahawa yang paling sesuai pada masa ini ialah lapisan masa jalan.

Tentukan laluan teknikal lapisan masa jalan dan bagaimana untuk melaksanakannya? Apa gunanya teknologi? Kami fikir ia adalah terutamanya soal konsistensi semantik. Berdasarkan keterpencilan masa jalan, proses tempatan asal perlu dibahagikan kepada dua proses: klien dan pelayan. Masa jalan CUDA adalah sumber tertutup dan logik pelaksanaan dalaman tidak boleh diterokai. Bagaimana untuk memastikan logik program asal dan semantik API dikekalkan selepas membahagikan proses Di sini kita menggunakan model benang satu-ke-satu untuk memastikan penjajaran logik dan semantik dalam API.

Kesukaran pelaksanaan jauh adalah masalah banyak API Selain perpustakaan dinamik libcudart.so, masa jalan juga melibatkan satu siri perpustakaan dinamik dan API seperti cuDNN, cuBLAS dan cuFFT, yang melibatkan beribu-ribu. antara muka API yang berbeza. Kami menggunakan teknologi kompilasi untuk mencapai penghuraian automatik fail pengepala dan penjanaan kod automatik, dan melengkapkan analisis API tersembunyi melalui kejuruteraan terbalik.

Penyelesaian kepada penyelesaian jauh 0-1 Selepas penyesuaian, keserasian ke belakang yang seterusnya sebenarnya agak mudah untuk diselesaikan. Pada masa ini, nampaknya API CUDA agak stabil, dan versi baharu hanya memerlukan sedikit penyesuaian tambahan.

Pemultipleksan pembahagian ruang dan pemultipleksan pembahagian masa disebut berkali-kali di atas. Berikut ialah penjelasan terperinci:

• Pemultipleksan pembahagian masa: Seperti namanya, ia adalah pemultipleksan pada peringkat kepingan masa. Ini serupa dengan penjadualan proses CPU Dalam satu keping masa, hanya satu proses GPU sedang berjalan. Proses GPU berbilang berjalan secara berselang-seli pada tahap mikro dan hanya boleh serentak. Ini juga mengakibatkan bahawa, dalam sekeping masa tertentu, jika proses tidak dapat menggunakan sumber pengkomputeran dengan baik, sumber pengkomputeran ini dibazirkan.
• Pemultipleksan pembahagian ruang: Berbeza daripada pemultipleksan pembahagian masa, dalam pemultipleksan pembahagian ruang, pada saat mikro tertentu, berbilang proses boleh berjalan pada GPU pada masa yang sama, selagi sumber GPU tidak sepenuhnya digunakan. , Inti bagi proses lain boleh dilancarkan Inti kedua-dua proses itu dijalin dan dijalankan pada tahap mikro, benar-benar merealisasikan keselarian dan menggunakan sumber GPU.

Seperti yang diperkenalkan dalam bahagian gambaran keseluruhan, kaedah virtualisasi biasa pada masa ini, termasuk virtualisasi keadaan kernel dan virtualisasi NVIDIA vGPU, sebenarnya adalah penyelesaian pemultipleksan pembahagian masa berdasarkan putaran kepingan masa di peringkat bawah. ​

NV telah melancarkan MPS - penyelesaian perkhidmatan berbilang proses untuk senario serentak berbilang proses Penyelesaian ini boleh mencapai pemultipleksan pembahagian ruang dan kini merupakan satu-satunya penyelesaian yang mengambil kira kecekapan dan prestasi. ​

Berikut ialah pengenalan ringkas kepada MPS bersamaan dengan menggabungkan konteks dua proses ke dalam satu proses. Ini mempunyai dua faedah:

• Tiada penukaran konteks diperlukan antara proses, mengurangkan overhed penukaran konteks.
• Pada masa yang sama, inti proses yang berbeza dijalin, meningkatkan penggunaan ruang sumber.

Bercakap tentang MPS, kita perlu menyebut kekurangan yang telah dikritik - masalah pengasingan kesalahan. ​

Bagaimana untuk menyelesaikan masalah kestabilan MPS ini? Baidu Intelligent Cloud menggabungkan penjadualan, enjin kontena dan perniagaan terus hidup untuk mencadangkan satu set lengkap penyepaduan proses dan penyelesaian perkongsian.

• Mencapai proses perniagaan yang menarik melalui pengalihan arahan bunuh
• Mencapai pemeriksaan kesihatan dan pengesanan animasi yang digantung melalui mekanisme pengesanan status MPS
• Mencapai proses pengguna automatik melalui penyimpanan perkhidmatan -alive Restart

Penyelesaian ini telah merangkumi 90%+ sumber komersil (perkhidmatan penting yang sensitif terhadap kelewatan) dan telah berjalan selama lebih daripada dua tahun Walaupun memberikan prestasi terbaik, ia dipercayai mampu untuk memuaskan sebahagian besar pengguna Keperluan untuk kestabilan.

Apabila MPS semakin diterima, NV terus meningkatkan kestabilan MPS. Berikut adalah berita baik terlebih dahulu. NV akan meningkatkan kestabilan MPS pada separuh kedua tahun ini, termasuk pengesanan status animasi yang digantung dan proses keluar yang anggun. Fungsi ini akan menjadi sebahagian daripada produk MPS, dan kestabilan serta kemudahan penggunaan MPS akan dipertingkatkan lagi.

Sebelum memperkenalkan fungsi preemption berkualiti tinggi, izinkan saya berkongsi dengan anda senario perniagaan preemption berkualiti tinggi. Menurut perbincangan kami dengan pengguna berbeza di dalam dan di luar kilang, kebanyakan persekitaran pengeluaran aplikasi AI boleh dibahagikan kepada tiga jenis tugas: dalam talian, garisan dekat dan luar talian berdasarkan kepekaan kependaman.

• Tugas dalam talian mempunyai kependaman tertinggi dan secara amnya merupakan tugas inferens yang bertindak balas kepada permintaan pengguna dalam masa nyata
• Tugas garisan secara amnya adalah tugas pemprosesan kelompok dan tidak mempunyai keperluan mengenai kelewatan; log tunggal , tetapi masa penyiapan kumpulan data mempunyai keperluan antara jam hingga minit
• Tugas luar talian tidak mempunyai keperluan untuk kelewatan, hanya memfokuskan pada pemprosesan dan secara amnya merupakan tugas latihan model.

Jika kita mentakrifkan tugas sensitif kelewatan sebagai tugas berkualiti tinggi dan tugasan dekat talian dan luar talian yang tidak sensitif kelewatan sebagai tugas berkualiti rendah. Dan apabila dua jenis tugasan dicampur, keutamaan pelancaran kernel yang berbeza ditakrifkan mengikut keutamaan tugas yang berbeza, iaitu fungsi preemption berkualiti tinggi yang kami nyatakan di atas. ​

Prinsip pelaksanaan ditunjukkan dalam rajah di bawah Enjin pengasingan ruang pengguna mengekalkan baris gilir inti yang logik untuk tugasan berkualiti tinggi dan tugasan berkualiti rendah. Apabila beban keseluruhan adalah rendah, kedua-dua baris gilir dibenarkan untuk melancarkan kernel pada masa yang sama Pada masa ini, kernel kedua-dua baris gilir disilangkan dan dijalankan bersama. Sebaik sahaja beban meningkat, modul pelancaran hierarki akan segera menunggu pelancaran baris gilir berkualiti rendah untuk memastikan kelewatan pelaksanaan tugas berkualiti tinggi.

Kelebihan fungsi ini adalah untuk memastikan daya pengeluaran luar talian sambil mengurangkan atau bahkan mengelakkan kesan tugasan dalam talian.

Begitu juga, kami mula-mula memperkenalkan definisi dan senario percampuran perkongsian masa.

Campuran perkongsian masa adalah sedikit seperti pengadunan kongsi dengan putaran kepingan masa dalam mod pengadunan. Perbezaannya ialah pengedaran hibrid perkongsian masa tidak mencadangkan penyelesaian pertukaran memori video untuk memori video, yang berguna dalam senario di mana memori video diduduki untuk masa yang lama tetapi kuasa pengkomputeran digunakan secara berselang-seli atau dicetuskan sekali-sekala. Apabila proses memerlukan kuasa pengkomputeran, ia memperoleh hak akses kepada memori video Apabila proses menyelesaikan pengiraan, ia melepaskan hak akses kepada memori video, membenarkan proses lain menunggu kebenaran untuk mendapatkan peluang untuk dijalankan. sumber GPU terbiar terputus-putus boleh digunakan sepenuhnya.

Teknologi teras percampuran perkongsian masa ialah pertukaran memori video. Kita boleh membandingkannya dengan swap memori CPU Apabila memori proses tertentu tidak mencukupi, sistem akan menukar sebahagian daripada sumber memori sistem ke cakera mengikut strategi tertentu, dengan itu membebaskan ruang untuk proses berjalan.

Prinsip pelaksanaan pertukaran memori video ditunjukkan dalam rajah di bawah. Kami mengekalkan kumpulan memori video di alamat fizikal memori video dan lapisan atas menggunakan kunci sumber untuk menentukan proses yang mempunyai kebenaran untuk menggunakan GPU. Apabila proses memperoleh kunci, memori video akan dialihkan daripada memori atau cakera ke kolam memori video fizikal, dan selanjutnya dipetakan ke ruang alamat maya untuk digunakan oleh proses. Apabila proses melepaskan kunci, ruang memori maya proses dikhaskan dan memori fizikal dipindahkan ke memori atau cakera. Kunci adalah saling eksklusif. Hanya satu proses boleh mendapatkan kunci Proses lain belum selesai dalam barisan menunggu dan mendapatkan kunci sumber dengan cara FIFO.

Perkara di atas memperkenalkan pelaksanaan fungsi enjin pengasingan mod pengguna Dalam aplikasi sebenar, bagaimanakah prestasi dan apakah kesannya kepada pengguna? Di sini kita pergi terus ke data ujian.

Angka berikut ialah perbandingan data dalam senario di mana kami memilih model biasa ResNet-50 Server pada set ujian awam MLPerf. Lajur dalam rajah mewakili prestasi di bawah pengasingan eksklusif, campuran telanjang, mod pengguna dan pengasingan mod kernel dari kiri ke kanan.

Gambar di sebelah kiri ialah perbandingan daya pemprosesan purata Dalam senario inferens, permintaan dicetuskan secara berselang-seli. Saya ingin menerangkan di sini bahawa daya pengeluaran dalam senario inferens tidak dapat menunjukkan prestasi virtualisasi dengan baik, dan anda harus memberi lebih perhatian kepada kependaman apabila melaksanakannya dalam persekitaran pengeluaran.

Gambar di sebelah kanan ialah perbandingan kependaman kuantil P99. Ia boleh dilihat bahawa dalam mod pengguna di bawah tekanan rendah (QPS = 40), kesan pencampuran telanjang pada kelewatan ekor panjang pada asasnya adalah sama, manakala mod kernel mempunyai kesan yang lebih besar sedikit pada kelewatan ekor panjang yang disebabkan kepada penggunaan pemultipleksan pembahagian masa. Kami terus meningkatkan tekanan Apabila QPS = 60, kelebihan mod pengguna menjadi ketara. Apabila tekanan semakin meningkat, penyelesaian gabungan proses ruang pengguna adalah lebih baik daripada kaedah pengedaran hibrid yang lain.

Walaupun kawalan kelewatan ekor panjang tidak sebaik mod pengguna, dari segi pengasingan, mod kernel mempunyai kelebihan, lebih memfokuskan pada senario dengan keperluan pengasingan yang kukuh. ​

Mari kita lihat pelaksanaan teknikal enjin pengasingan keadaan kernel.

Pertama, mari kita lihat ciri-ciri pelaksanaan virtualisasi keadaan kernel, termasuk yang berikut:

Pelaksanaan keadaan kernel yang baik: menyokong memori video, kuasa pengkomputeran dan pengasingan tahap MB; memori video; kuasa pengkomputeran 1% peruntukan tahap;

Berbeza daripada pelaksanaan mod pengguna, fungsi pengasingan GPU virtualisasi mod kernel dilaksanakan dalam mod kernel. Separuh kiri rajah di bawah ialah gambar rajah seni bina pelaksanaan virtualisasi keadaan kernel kami Dari bawah ke lapisan atas, ia adalah perkakasan GPU, lapisan kernel dan lapisan pengguna.

Tahap perkakasan ialah GPU kami GPU ini boleh menjadi GPU logam kosong atau GPU lutsinar.

Di bawah lapisan kernel ialah pemacu asal GPU, yang sebenarnya mengawal fungsi GPU. Pemacu inilah yang sebenarnya mengendalikan GPU Dan di atas pemacu GPU ialah modul kernel untuk virtualisasi GPU kami melaksanakan. Iaitu, pemacu pemintasan GPU ialah bahagian kuning dan mengandungi tiga fungsi, termasuk pemintasan memori, pemintasan kuasa pengkomputeran dan penjadualan kuasa pengkomputeran. Pengasingan memori video dan pengasingan kuasa pengkomputeran dilaksanakan secara berasingan.

Lapisan pengguna, pertama ialah antara muka pemintasan. Antara muka ini disediakan oleh modul pemintasan dan dibahagikan kepada dua bahagian: satu ialah antara muka fail peranti, dan satu lagi ialah antara muka untuk mengkonfigurasi modul pemintasan. Fail peranti disediakan kepada bekas Mari kita lihat bekas terlebih dahulu. Di atas bekas ialah aplikasi, di bawah ialah masa jalan cuda, dan di bawah ialah pustaka asas cuda, termasuk pemacu api/nvml api, dsb. Dengan menyediakan fail peranti kami kepada bekas sebagai fail peranti palsu, apabila lapisan atas CUDA mengaksesnya, ia akan mengakses fail peranti kami Ini melengkapkan pemintasan akses kepada pemacu GPU oleh perpustakaan asas CUDA.

​Modul pemintasan kami dalam kernel akan memintas semua panggilan sistem yang diakses, memintas dan menghuraikannya, dan kemudian mengubah hala akses sebenar kepada pemacu asas GPU sebenar. Selepas pemacu asas GPU menyelesaikan pemprosesan, ia mengembalikan hasilnya kepada modul pemintasan kami, yang memprosesnya semula, dan akhirnya mengembalikan hasilnya kepada pustaka asas dalam bekas.

Ringkasnya, ia memintas akses perpustakaan asas kepada pemacu GPU dengan mensimulasikan fail peranti, dan melengkapkan pemintasan memori video dan kuasa pengkomputeran melalui operasi seperti pemintasan, penghuraian dan suntikan. ​

Pada masa ini, pengasingan memori video dicapai dengan memintas semua panggilan sistem berkaitan memori video, terutamanya termasuk maklumat memori video, peruntukan memori video dan pelepasan memori video, dsb. Selain itu, pengasingan memori semasa hanya boleh ditetapkan secara statik dan tidak boleh diubah secara dinamik. Walaupun mod pengguna boleh menyokong pembangunan memori video yang berlebihan, mod kernel tidak boleh menyokong pembangunan memori video yang berlebihan.

Dari segi pengasingan kuasa pengkomputeran, dapatkan maklumat yang berkaitan dengan memintas Konteks CUDA proses. Objek penjadualan ialah Konteks CUDA yang berkaitan dengan proses. Sumber pengkomputeran yang sepadan dengan Konteks CUDA termasuk sumber pengkomputeran (Pelaksanaan) dan sumber salinan memori (Salin). Setiap GPU mempunyai satu utas kernel yang menjadualkan semua Konteks CUDA pada GPU ini.

Kami telah melaksanakan 4 algoritma penjadualan kuasa pengkomputeran mod kernel:

• Perkongsian Tetap: Setiap POD diperuntukkan sumber kuasa pengkomputeran tetap, iaitu Kuasa pengkomputeran keseluruhan GPU dibahagikan secara tetap kepada n bahagian, dan setiap POD dibahagikan kepada 1/n kuasa pengkomputeran.
• Perkongsian Sama Sama: Semua POD aktif berkongsi sumber kuasa pengkomputeran secara sama rata, iaitu bilangan POD aktif ialah n, dan setiap POD berkongsi 1/n kuasa pengkomputeran.
• Perkongsian Berat: Setiap POD memperuntukkan sumber kuasa pengkomputeran mengikut berat, iaitu kuasa pengkomputeran keseluruhan GPU diperuntukkan kepada setiap POD mengikut nilai berat. Tidak kira sama ada POD mempunyai beban perniagaan, kuasa pengkomputeran diperuntukkan mengikut berat.
• Burst Weight Share: POD aktif memperuntukkan sumber kuasa pengkomputeran mengikut pemberat, iaitu setiap POD diberikan nilai berat dan POD aktif diperuntukkan kuasa pengkomputeran mengikut nisbah pemberat.

Oleh kerana mod kernel menjadualkan kuasa pengkomputeran melalui kepingan masa, ia tidak begitu mesra kepada perniagaan yang sensitif kelewatan. Kami telah membangunkan teknologi lokasi bersama luar talian secara khusus Melalui lokasi bersama perniagaan dalam talian dan perniagaan luar talian, kami boleh meningkatkan kelajuan tindak balas perniagaan dalam talian dan juga membenarkan perniagaan luar talian berkongsi sumber pengkomputeran GPU untuk mencapai matlamat meningkatkan penggunaan sumber GPU. . Ciri-ciri penggunaan bercampur luar talian kami ialah:

• POD dalam talian: tugas penaakulan, yang biasanya menggunakan sedikit kuasa pengkomputeran.
• POD Luar Talian: tugas latihan, yang biasanya menggunakan sebahagian besar kuasa pengkomputeran.

Apabila POD dalam talian mempunyai beban tugas, ia segera merampas POD luar talian dan menggunakan semua kuasa pengkomputeran untuk menyediakan perkhidmatan inferens. Apabila beban tugas tamat, kuasa pengkomputeran dilepaskan ke POD luar talian. ​

Berikut ialah keputusan penilaian pengasingan kuasa pengkomputeran mod kernel:

Persekitaran ujian ialah kad tunggal V100 SXM2 16G, dan daya pengeluaran ialah diuji dalam senario latihan Ujian ini menggunakan rangka kerja horovod, model ialah resnet50.

Nisbah berat POD 1 dan POD 2 ialah 1:2.

Daripada keputusan rajah di atas, dapat dilihat bahawa nisbah throughput POD 1 dan POD 2 ialah 45~50%, iaitu kira-kira 1/2, iaitu selaras dengan nilai pratetap kami. Pada masa yang sama, POD SUM mengalami kerugian sebanyak 2~4% berbanding dengan Native Kerana pengasingan kuasa pengkomputeran memerlukan operasi pensuisan pada Konteks Cuda, terdapat kerugian yang tidak dapat dielakkan, bagaimanapun, kerugian kami adalah dalam 5%, yang boleh dikatakan berada dalam julat toleransi.

Mari kita bandingkan ciri-ciri mod kernel dan mod pengguna.

Dari segi pengasingan kesalahan, mod kernel mempunyai kelebihan berbanding mod pengguna, dan mod kernel tidak perlu menggantikan perpustakaan asas. Penjadualan kuasa pengkomputeran mod pengguna mengguna pakai pembahagian masa serta pemultipleksan pembahagian ruang, dan mod kernel menggunakan pemultipleksan pembahagian masa. Fungsi lanjutan dalam mod pengguna termasuk lokasi bersama luar talian, pengagihan memori video yang berlebihan ke memori, contoh pengekodan dan penyahkodan (peruntukan bebas pengekodan dan sumber penyahkodan kad pemecut AI), dan kami juga menyokong lokasi bersama luar talian dalam mod kernel.

Cara menggunakan teknologi virtualisasi untuk meningkatkan kecekapan penggunaan GPU dalam senario AI Mari kita kongsikan amalan terbaik dalam senario AI berskala besar berdasarkan kes sebenar di kilang.

Mari kita lihat senario biasa dalam perkhidmatan inferens. Disebabkan oleh seni bina model itu sendiri atau keperluan kependaman perkhidmatan tinggi, sesetengah tugas hanya boleh dijalankan dalam konfigurasi yang saiz kelompoknya sangat kecil, atau walaupun saiz kelompok ialah 1. Ini secara langsung membawa kepada penggunaan GPU jangka panjang yang rendah, malah penggunaan puncak hanya 10%.

Dalam senario ini, perkara pertama yang perlu difikirkan ialah mencampurkan berbilang tugas penggunaan rendah.

Kami meringkaskan strategi pencampuran ini sebagai pencampuran bersama. Sama ada dalam pembangunan, latihan atau senario inferens, kita boleh menggunakan pencampuran dikongsi antara berbilang tugas penggunaan rendah.

Digabungkan dengan teknologi gabungan proses yang dinyatakan di atas, adalah mungkin untuk mencapai pencampuran kongsi 2 kejadian atau malah berbilang kejadian berdasarkan memastikan kelewatan perkhidmatan dan meningkatkan penggunaan sumber lebih daripada 2 kali ganda. ​

Pada masa yang sama, kebanyakan GPU mempunyai sumber codec bebas. Dalam kebanyakan senario, seperti yang ditunjukkan dalam angka kiri bawah, sumber kekal melahu untuk masa yang lama. Berdasarkan sumber pengkomputeran yang dikongsi, kami boleh mencampurkan contoh pengekodan atau penyahkodan untuk meningkatkan lagi prestasi sumber dan mengaktifkan sumber terbiar.

Corak muatan tipikal perkhidmatan inferens ialah terdapat turun naik puncak dan lembah yang jelas sepanjang hari, dan akan berlaku lonjakan trafik jangka pendek yang tidak dapat diramalkan. Ini menunjukkan bahawa walaupun nilai puncak adalah tinggi, purata penggunaan adalah sangat lemah, dengan nilai purata selalunya kurang daripada 30% atau bahkan 20%.

Perubahan jenis ini jelas bagaimana untuk mengoptimumkan kecekapan perkhidmatan yang meningkat dalam tempoh yang singkat? Kami mencadangkan strategi pengedaran campuran preemptive.

Campuran awalan ialah mencampurkan tugas berkualiti rendah yang tidak sensitif kelewatan dengan perkhidmatan berkualiti tinggi dengan nilai puncak tinggi dan kepekaan kelewatan. Kualiti tinggi dan kualiti rendah di sini ditakrifkan oleh pengguna dan diisytiharkan secara eksplisit apabila memohon sumber. Dalam amalan dalaman Baidu, kami mentakrifkan tugasan memberus pangkalan data talian dekat dan luar talian sebagai kualiti rendah Perniagaan jenis ini mempunyai keperluan tertentu untuk pemprosesan dan pada dasarnya tiada keperluan untuk kependaman. ​

Menggunakan mekanisme preemption berkualiti tinggi dalam fungsi virtualisasi, tugasan berkualiti tinggi sentiasa mempunyai inisiatif untuk menduduki sumber. Apabila trafik berada di palung, beban pada keseluruhan kad tidak tinggi, dan tugas optimum rendah boleh berjalan seperti biasa Setelah trafik berada di puncak atau terdapat lonjakan jangka pendek, mekanisme preemption optimum tinggi boleh rasa dalam masa nyata dan kuasa pengkomputeran awalan pada butiran kernel Pada masa ini tugasan berkualiti rendah akan dihadkan aliran atau malah belum selesai sepenuhnya untuk memastikan kualiti perkhidmatan tugasan berkualiti tinggi.

Dalam mod hibrid ini, mungkin terdapat memori video yang tidak mencukupi dan mungkin terdapat banyak redundansi dalam kuasa pengkomputeran. Untuk senario seperti ini, kami menyediakan mekanisme hantaran berlebihan memori video tersirat. Pengguna boleh menggunakan pembolehubah persekitaran untuk mengagihkan memori video secara berlebihan untuk tugasan berkualiti rendah dan menggunakan lebih banyak contoh untuk memastikan kuasa pengkomputeran sentiasa tersedia untuk mengisi palung penggunaan dan memaksimumkan kecekapan penggunaan keseluruhan.

Anda mungkin biasa dengan jenis senario perniagaan ketiga, iaitu senario di mana memori grafik kekal dan kuasa pengkomputeran dicetuskan secara berselang-seli. Perniagaan perwakilan biasa ialah tugas pembangunan dan latihan dalam talian.

Berikut ialah contoh latihan dalam talian. Kami tahu bahawa banyak model perlu dikemas kini dalam talian berdasarkan data pengguna harian atau setiap jam, seperti model pengesyoran, yang memerlukan latihan dalam talian. Berbeza daripada latihan luar talian di mana daya pengeluaran penuh dalam masa nyata, latihan dalam talian perlu mengumpul sekumpulan data dan mencetuskan sesi latihan. Dalam Baidu, model biasa mungkin bahawa kumpulan data tiba dalam 15 minit, tetapi masa latihan sebenar hanya 2 hingga 3 minit Dalam masa yang tinggal, proses latihan berada dalam memori video dan menunggu di sana sehingga kumpulan seterusnya data datang dari huluan. Dalam tempoh ini, kadar penggunaan adalah 0 untuk masa yang lama, menyebabkan banyak pembaziran sumber.

Tugas jenis ini tidak boleh menggunakan pencampuran kongsi atau pencampuran awalan yang dinyatakan di atas kerana memori video pada dasarnya penuh. Digabungkan dengan mekanisme pertukaran memori video yang disebutkan sebelum ini, kami mencadangkan strategi pencampuran perkongsian masa.

Percampuran perkongsian masa adalah serupa dengan pencampuran kongsi putaran kepingan masa, tetapi pada masa ini memori video juga akan ditukar masuk dan keluar bersama-sama dengan konteks pengkomputeran. Memandangkan lapisan virtualisasi asas tidak dapat merasakan apabila perniagaan memerlukan pengiraan, kami mengekalkan kunci sumber global untuk setiap kad GPU. Dan merangkum antara muka C++ dan Python yang sepadan untuk panggilan pengguna. Pengguna hanya perlu memohon kunci ini apabila mereka perlu mengira, dan memori video akan ditukar secara automatik ke ruang memori video dari ruang lain selepas pengiraan selesai, kunci akan dilepaskan, dan memori video yang sepadan akan menjadi ditukar kepada memori atau ruang cakera. Menggunakan antara muka mudah ini, pengguna boleh mencapai perkongsian masa dan penggunaan eksklusif GPU untuk pelbagai tugas. Dalam senario latihan dalam talian, menggunakan percampuran perkongsian masa boleh menjimatkan sehingga 4/5 sumber sambil meningkatkan penggunaan keseluruhan.

Amalan terbaik dalam tiga senario yang dinyatakan di atas telah disahkan dan dilaksanakan secara besar-besaran dalam perniagaan dalaman Baidu. Fungsi berkaitan juga telah dilancarkan pada platform pengkomputeran heterogen Baidu Baige·AI, dan anda boleh memohon dan mencubanya dengan segera.

Di sini saya akan meluangkan masa kira-kira tiga minit bercakap tentang fungsi yang masih dalam pengesahan dalaman Fungsi ini akan dilengkapkan pada platform Baidu Baige dalam masa terdekat untuk menyelesaikan masalah konfigurasi biasa dalam senario AI berskala besar. Masalah seperti nisbah tidak sekata, ketidakseimbangan penawaran dan permintaan, dan pemecahan sumber.

Pelajar yang mengusahakan infrastruktur selalunya akan mendengar konsep seperti penyahgandingan dan pengumpulan sumber. Bagaimana untuk melaksanakan konsep pengumpulan dan mengubahnya menjadi produktiviti sebenar adalah perkara yang telah kami terokai dan promosikan secara aktif. Seawal tahun 2015, kami melaksanakan penyelesaian pengumpulan perkakasan pertama dalam industri berdasarkan penyelesaian Fabrik PCIe, dan melaksanakannya secara besar-besaran dalam Baidu Ini ialah X-MAN 1.0 yang baru disebut (kini telah berkembang kepada 4.0). Konfigurasikan sambung antara CPU dan GPU melalui rangkaian PCIe Fabric untuk merealisasikan peruntukan sumber yang dinamik dan menyelesaikan masalah nisbah dalam pelbagai senario. Terhad oleh sambungan dan protokol perkakasan, penyelesaian ini hanya boleh menyelesaikan pengumpulan dalam kabinet.

Pengumpulan lapisan perisian ialah penyelesaian teknikal yang kami fikir lebih fleksibel. Apabila rangkaian pusat data terus dinaik taraf, rangkaian 100G atau malah 200G akan menjadi konfigurasi standard infrastruktur pada masa hadapan, dan rangkaian berkelajuan tinggi menyediakan lebuh raya komunikasi untuk pengumpulan sumber.

Penyahgandingan dan pengumpulan sumber memberikan perniagaan lebih fleksibiliti dan menyediakan ruang yang lebih besar untuk imaginasi untuk pengoptimuman prestasi. Sebagai contoh, masalah nisbah antara CPU dan GPU, masalah ketidakseimbangan bekalan dan permintaan pendudukan sumber jangka panjang dalam senario pembangunan dan kecekapan rendah, masalah penyekatan tugas pemecahan sumber dalam senario latihan, dan masalah peralatan latihan yang tidak normal dimulakan semula. Senario sedemikian semuanya boleh diselesaikan dalam pengumpulan dan penyelesaian derivatif.

Akhir sekali, semua teknologi maya dan amalan terbaik yang dikongsi di atas telah dilancarkan pada platform pengkomputeran heterogen Baidu Baige AI. Cari "Baidu Baige" di tapak web rasmi Baidu Intelligent Cloud untuk mempercepatkan tugas AI dengan serta-merta dan merangsang imaginasi perniagaan!

Soal Jawab Ditampilkan

S: Sumber am disimpan dalam bekas melalui ruang nama dan cgroup. Bolehkah saya bertanya apakah teknologi yang digunakan GPU untuk mencapai kawalan sumber?

J: Ruang nama dan cgroup ialah kedua-dua mekanisme yang disediakan oleh kernel, dan pada asasnya bergantung pada keupayaan berkaitan yang disediakan oleh perkakasan. Ini tidak wujud pada GPU semasa GPU sedang dan akan ditutup untuk masa yang lama Hanya pembekal perkakasan boleh menyediakan fungsi ini yang boleh dihulurkan ke saluran utama. Penyelesaian tiga pihak semasa adalah semua pelaksanaan bukan standard dalam mod pengguna atau mod kernel, dan pada masa ini tiada cara untuk memasukkannya dalam ruang nama dan kategori cgroup. Tetapi boleh dianggap bahawa apa yang ingin dilaksanakan oleh virtualisasi GPU ialah mekanisme yang sepadan di bawah antara muka ini Sama ada ia boleh diseragamkan adalah satu lagi persoalan yang lebih besar.

S: Sebagai tambahan kepada teknologi maya GPGPU, adakah kita telah membangunkan teknologi maya berkaitan NPU? Sama ada untuk memisahkan daripada timbunan teknologi NV. Terima kasih!

J: Saya faham bahawa NPU yang disebut di sini mestilah Unit Pemprosesan Rangkaian, yang secara amnya merujuk kepada semua perkakasan pecutan AI semasa. Kami sedang mengusahakan penyesuaian virtualisasi perkakasan pecutan AI yang lain. Yang pertama ialah teras Kunlun Kami telah menyesuaikan keupayaan virtualisasi yang disebutkan di atas pada teras Kunlun. Apabila adegan berkembang, perkakasan pecutan arus perdana yang lain akan terus disesuaikan.

S: Adakah mod pengguna dan mod kernel dua produk berbeza?

J: Ia adalah produk yang sama, dengan kaedah pelaksanaan asas yang berbeza, tetapi tahap antara muka pengguna disatukan.

S: Apakah butiran yang boleh dicapai oleh virtualisasi mod pengguna?

J: Kuasa pengkomputeran boleh dibahagikan kepada 1% butiran, dan memori video boleh dibahagikan kepada 1MB.

S: Adakah virtualisasi mod kernel menyebabkan overhed kawalan yang lebih besar?

J: Virtualisasi keadaan kernel adalah berdasarkan penghirisan masa. Overhed di sini disebabkan oleh penghirisan masa pasti akan menyebabkan kehilangan kuasa pengkomputeran. Jika ia merujuk kepada overhed yang disebabkan oleh prestasi aplikasi, adalah benar bahawa mod kernel akan lebih besar daripada mod pengguna.

S: Mengikut pelan pelaksanaan pembahagian masa, inferens dalam talian merasakan purata masa persaingan bebas adalah lebih pantas.

J: Menurut keputusan ujian kami, susunan prestasi daripada baik kepada lemah ialah: gabungan proses, percampuran telanjang (persaingan bebas), dan pengasingan had keras.

S: Bolehkah kedua-dua kaedah virtualisasi GPU wujud bersama dalam kelompok k8s?

J: Dari segi mekanisme dan prinsip, kewujudan bersama adalah mungkin. Tetapi pada masa ini kami tidak mahu reka bentuk menjadi begitu rumit dari perspektif produk, jadi kami masih memisahkannya. Jika terdapat permintaan yang meluas daripada perniagaan seterusnya, kami akan mempertimbangkan untuk melancarkan penyelesaian kewujudan bersama yang serupa.

S: Bolehkah anda memperkenalkan secara terperinci bagaimana penjadual k8s boleh dikembangkan? Adakah ejen pada nod dikehendaki melaporkan topologi GPU dan jumlah keseluruhan?

J: Ya, ini memerlukan ejen yang berdiri sendiri untuk memuat naik sumber (termasuk sumber memori video dan sumber kuasa pengkomputeran) dan maklumat topologi.

S: Adakah anda mempunyai sebarang cadangan tentang pilihan pembahagian masa dan ruang?

J: Untuk tugas penaakulan dalam talian yang sensitif kelewatan, adalah disyorkan untuk memilih penyelesaian pembahagian ruang berdasarkan gabungan proses. Untuk senario yang memerlukan pengasingan yang ketat, disyorkan untuk memilih penyelesaian perkongsian masa. Tiada perbezaan antara keduanya dalam pemilihan adegan lain.

S: Versi CUDA yang manakah boleh disokong oleh mod kernel? Jika NV dikemas kini, berapa lamakah kitaran kemas kini Baidu Smart Cloud?

J: Oleh kerana keadaan kernel dimayakan dalam kernel, tiada keperluan khas untuk versi CUDA Pada masa ini, semua versi CUDA disokong. Jika NV mengemas kini CUDA, tiada kerja sokongan khas dijangka.

S: Untuk menggunakan mod kernel, adakah saya perlu menggunakan imej OS khas yang disediakan oleh Baidu Smart Cloud? Pemandu yang berdedikasi?

J: Mod kernel tidak memerlukan Baidu Smart Cloud untuk menyediakan imej OS khusus. Pada masa ini kami menyokong centos7 dan ubuntu. Tetapi kita perlu menggunakan rangka kerja penggunaan kita sendiri untuk menggunakannya. Tiada keperluan khas untuk imej bekas dan semuanya boleh disokong secara telus.

S: Adakah ia hanya tersedia di awan awam? Bolehkah ia digunakan secara peribadi?

J: Awan awam dan awan peribadi boleh digunakan dan digunakan.

Atas ialah kandungan terperinci Analisis teknikal dan perkongsian amalan: mod pengguna dan mod kernel dalam virtualisasi bekas GPU dwi-enjin. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!