Menjalankan Sistem Inferensi Terdistribusi dalam Skala Besar — Nishant Gupta & Naman Ahuja, Meta
AAI Engineer
Computing/SoftwareInternet Technology
Transcript
00:00:00Selamat pagi semuanya. Selamat datang di Influence Talk pertama di hari terakhir AI Engineering
00:00:17World Fair. Nama saya Nishan Gupta dan hari ini saya didampingi oleh rekan pembicara saya, Naman Ahuja.
00:00:23Kami bekerja membangun efisiensi, pelatihan, dan infrastruktur inferensi di Meta.
00:00:27Hari ini, kita akan membahas tentang cara mengoperasikan sistem inferensi terdistribusi dalam skala besar.
00:00:32Seperti yang kita semua tahu, inferensi bukan lagi sekadar artefak penelitian yang dijadikan produk.
00:00:37Ini adalah beban kerja infrastruktur hiperskala mendasar yang berkembang sangat pesat.
00:00:43Lalu lintas inferensi sudah melampaui mikrolayanan terbesar di dunia
00:00:47dan tingkat pertumbuhannya adalah yang tercepat dari beban kerja apa pun yang pernah kita lihat.
00:00:54Mari kita mundur ke sekitar tahun 2008 dan mencoba membandingkan era AI dengan era komputasi awan.
00:01:00Di sekitar tahun 2008, komputasi awan dimulai sebagai penawaran mesin virtual.
00:01:05Rekayasa yang menarik saat itu adalah virtualisasi.
00:01:07Kemudian seiring waktu, nilainya berpindah ke tingkat atas, ke penjadwal seperti Borg, Kubernetes, Mesos.
00:01:14Lalu ke service mesh, autoscaler, dan ke berbagai platform yang dibangun di atasnya.
00:01:18Lapisan orkestrasi inilah yang sebenarnya menangkap nilai dan kompleksitas tersebut.
00:01:24AI berada di jalur yang persis sama, tetapi dipadatkan ke dalam beberapa tahun terakhir alih-alih satu dekade.
00:01:30Kita memulai dengan model-model sederhana yang berjalan di GPU.
00:01:33Kemudian kita melihat evolusi kerangka kerja penyaji model seperti VLLM, TorchServe, Triton, dan kini kita menyaksikan lapisan orkestrasi muncul secara real-time, menangani tantangan rumit dalam perutean, manajemen KV cache, desagregasi prefill-decode, dan penggabungan multimodel.
00:01:51Fase berikutnya dari era AI ini bukan hanya tentang model, kernel, atau optimasi terbaik.
00:01:57Ini adalah tentang seluruh ekosistem.
00:01:58Ini tentang control plane dan orkestrasi, dan inilah yang akan menjadi fokus kita dalam presentasi ini.
00:02:06Jadi, mari kita bahas sedikit tentang lonjakan permintaan berbasis agen.
00:02:09Pada penyajian web klasik sebelum beban kerja inferensi AI dimulai, kapasitas berskala secara linier dengan pengguna, tergantung jenis beban kerjanya.
00:02:17Dua kali lipat pengguna berarti dua kali lipat QPS, dua kali lipat armada infrastruktur jika tanpa optimasi, dan perencanaan kapasitas sebagian besar hanya analisis lembar kerja.
00:02:28Dalam penyajian agen baru ini, kapasitas berskala dengan jumlah pengguna dikali jumlah panggilan per pengguna, dikali jumlah token, yang bervariasi tergantung pada model, optimasi, dan SKU perangkat keras yang Anda miliki.
00:02:40Satu chatbot bisa memiliki satu panggilan model per giliran, yang kini berkembang menjadi 10 hingga 20 untuk copilot dan 50 untuk agen riset, dan kini mencapai ribuan panggilan untuk beban kerja otonom tanpa campur tangan manusia.
00:02:54Kesimpulan utamanya adalah Anda tidak bisa merencanakan kapasitas untuk agen dengan cara yang sama seperti mikrolayanan.
00:03:00Kita perlu memikirkan elastisitas dan menerapkan penjadwalan serta kontrol penerimaan yang peka terhadap beban kerja.
00:03:08Sekarang, mari kita mendalami perbedaan, kelebihan dan kekurangan, antara penyajian mikrolayanan tradisional versus penyajian inferensi modern di berbagai dimensi utama ini.
00:03:19Bentuk permintaan.
00:03:20Mikrolayanan mengasumsikan permintaan yang singkat dan seragam, sedangkan permintaan LLM yang kita lihat dalam beban kerja kita dapat bervariasi dari 50 token hingga 100.000 token, dengan profil komputasi yang sangat berbeda antara tahap prefill dan decode.
00:03:33Untuk pembentukan batch, tumpukan klasik untuk mikrolayanan melakukan penggabungan batch sebagian besar di lapisan load-balancer, jika ada.
00:03:40Namun, penyajian LLM memerlukan pembentukan batch dalam proses secara kontinu, jika tidak, throughput akan anjlok drastis.
00:03:48Status.
00:03:49Sebagian besar mikrolayanan klasik bersifat tanpa status (stateless) di luar lapisan penyimpanan.
00:03:54Namun, penyajian LLM membutuhkan status per permintaan yang sangat besar, yaitu KV Cache, yang sangat mahal untuk dibuat dan lebih mahal lagi jika dibuang.
00:04:02Unit skalabilitas.
00:04:03Unit skalabilitas.
00:04:05Ketika memikirkan mikrolayanan tradisional, kita bisa menjalankannya di CPU murah dalam pod.
00:04:11Namun untuk inferensi modern, kita harus menjalankannya di GPU yang 100 kali lebih mahal, 10 kali lebih lambat untuk didapatkan, dan tidak bisa kita sediakan secara berlebihan secara sembarangan.
00:04:20Jika tidak, itu akan menyebabkan pemborosan yang sangat besar.
00:04:23Mode kegagalan.
00:04:25Ketika Anda memikirkan mikrolayanan tradisional seperti yang dibuat sebagian besar dari kita selama beberapa tahun terakhir, bahkan jika host atau pod mengalami crash, kita bisa memulaikannya kembali.
00:04:34Kita bisa membangun kembali statusnya jika diperlukan.
00:04:36Namun untuk inferensi model, dibutuhkan waktu yang sangat lama untuk berpindah dari awal yang dingin ke siap pakai.
00:04:42Dan jika GPU terhenti di tengah proses decode, GPU dapat kehilangan ribuan token dalam proses, dan menyebabkan penumpukan antrean.
00:04:50Kesimpulannya adalah kemacetan utama bukan sekadar pada modelnya.
00:04:53Melainkan pada orkestrasinya itu sendiri.
00:04:58Seperti yang bisa kita lihat dalam keputusan tersembunyi di balik sebuah prompt ini, ketika kita menggunakan aplikasi berbasis agen, diperlukan serangkaian langkah di balik layar.
00:05:06Kita harus melakukan otentikasi.
00:05:07Kita harus memilih model, tergantung pada jenis permintaannya.
00:05:09Kita harus memilih wilayah tujuan.
00:05:11Kita harus melakukan kontrol penerimaan.
00:05:12Kita harus melakukan pencarian cache.
00:05:14Kita harus menjalankannya di GPU.
00:05:17Kita harus melakukan pembentukan batch.
00:05:18Dan ada serangkaian langkah lain yang terlibat.
00:05:19Dan seperti yang dapat kita lihat, dari semua langkah ini, hanya satu langkah yang membutuhkan model, yaitu prefill decode.
00:05:25Baik itu inferensi terpisah, maupun inferensi tidak terpisah.
00:05:29Langkah-langkah lain membutuhkan infrastruktur.
00:05:31Kecerdasan mungkin terletak pada model, tetapi ekonomis, keandalan, dan pengalaman pengguna semuanya ada di infrastruktur.
00:05:38Itulah mengapa banyak tim platform di berbagai perusahaan memberikan dampak yangjauh lebih besar pada kualitas dan keberhasilan produk dibandingkan sebelumnya.
00:05:50Sebagian besar dari kita di ruangan ini memiliki keahlian mendalam di satu, dua, atau tiga lapisan.
00:05:54Kita mungkin mengelola kernel atau optimasi kernel.
00:05:57Kita mungkin mengelola perutean atau produk itu sendiri.
00:05:59Atau kita mungkin mengoperasikan infrastruktur GPU atau kluster itu sendiri.
00:06:03Namun sangat sedikit dari kita yang telah mengoperasikan seluruh tumpukan atau memikirkannya secara menyeluruh dari awal hingga akhir.
00:06:08Seperti yang bisa Anda lihat pada lapisan-lapisan ini, lapisan ini tidaklah baru.
00:06:11Mereka sudah ada selama 20 tahun atau lebih.
00:06:13Yang baru adalah kombinasi dan keterikatan di antara mereka.
00:06:18Keputusan di lapisan perutean dapat mengubah tingkat keberhasilan cache di lapisan model, yang dapat mengubah komposisi batch, yang dapat mengubah utilisasi GPU, yang dapat mengubah keputusan autoscaling karena perubahan utilisasi GPU.
00:06:32Jadi semuanya saling terikat.
00:06:33Ketika ada penurunan performa dalam beban kerja inferensi kita, ini bukan sekadar memahami apa yang terjadi di lapisan caching atau kontrol penerimaan.
00:06:41Kita perlu memikirkan tumpukan tersebut dari atas ke bawah.
00:06:43Dan ketika kita melihat adanya kendala, sangat penting untuk memahami di lapisan mana kendala itu berada agar kita dapat berinvestasi dengan tepat.
00:06:54Sekarang, mendalami bagaimana sebuah prompt bekerja, ketika kita memiliki prompt untuk aplikasi apa pun, baik itu hanya untuk menghasilkan gambar, tugas penelitian, atau orkestrasi multi-agen yang rumit, kurang lebih melibatkan serangkaian langkah ini.
00:07:08Prompt akan masuk ke gateway.
00:07:10Kemudian masuk ke router, setelah itu dilakukan pencarian cache jika permintaan pernah terlihat sebelumnya.
00:07:17Lalu masuk ke penjadwal, yang memutuskan di kluster GPU mana dan di perangkat keras apa perintah itu harus berjalan.
00:07:22Bisa di NVIDIA, AMD, atau chip silikon internal Anda, yang kemudian masuk ke runtime penyaji yang sesuai, VLLM, SGLang, atau apa pun yang kita gunakan.
00:07:30Dan kemudian kita mengalirkan kembali responsnya ke pengguna sesuai dengan profil SLO waktu hingga token pertama dan waktu antar setiap token, sambil memastikan throughput sesuai dengan yang diinginkan pengguna.
00:07:41Seperti yang bisa kita lihat, inferensi ini bertindak seperti transaksi terdistribusi.
00:07:45Setiap panah dalam diagram ini adalah lompatan jaringan.
00:07:47Setiap lompatan ini dapat mencoba ulang.
00:07:50Dapat mengalami batas waktu (time out).
00:07:51Dapat dialihkan ke cadangan.
00:07:53Bahkan bisa gagal.
00:07:54Dan masing-masing lompatan ini akan memiliki SLO, dan sedang mengalirkan kembali data ke pengguna.
00:08:00Jadi jika gagal, semantik kegagalan parsial jauh lebih sulit ditangani daripada panggilan RPC biasa.
00:08:06Bayangkan apa yang terjadi jika kita telah mengalirkan 200 token kembali ke pengguna, dan tiba-tiba host GPU dihentikan karena acara pemeliharaan yang terjadwal,
00:08:15terencana, atau tidak terencana.
00:08:16Kita tidak bisa begitu saja mencoba ulang.
00:08:17Kita harus memikirkannya secara holistik.
00:08:19Di sinilah alasannya mengapa kita tidak bisa membangun keandalan di tingkat ujung (edge).
00:08:23Itu harus menjadi properti dari control plane, karena control plane-lah yang melihat seluruh alur kerja.
00:08:31Sekarang, mari kita bicara tentang penjadwal dan beberapa optimasi serta cara memikirkannya.
00:08:37Untuk mikrolayanan tradisional, kita biasa memikirkan pemadatan (bin packing) mikrolayanan tradisional dalam tiga atau empat dimensi.
00:08:43Bisa jadi pada sosialisasi, memori CPU, atau empat domain, tergantung apakah Anda menggunakan AWS atau penyedia cloud internal sendiri.
00:08:52Namun untuk inferensi, penjadwal harus menyadari setidaknya tujuh poros saat kita menjadwalkan permintaan tertentu.
00:08:59Penjadwal harus menyadari jenis GPU.
00:09:00Bisa ada n jumlah perangkat keras heterogen di kluster Anda, H100 versus E100 versus B200, dengan topologi jaringan yang berbeda.
00:09:09Penjadwal harus mengetahui ruang bebas HBM, yaitu status KV cache.
00:09:13Bobot model, apakah sudah dimuat, apakah dingin, atau apakah sudah hangat dan kita harus melakukan permulaan dingin.
00:09:19Penjadwal harus menyadari prioritas penyewa.
00:09:21Bisa ada n jumlah penyewa yang berjalan di kluster multi-tenant tersebut dengan profil SLO yang berbeda.
00:09:27Kita juga harus menyadari konteks alur kerja.
00:09:30Apakah kita berada di langkah ketiga penalaran yang telah menghabiskan X dolar, atau di tahap awal dan kita bisa menghentikan alur kerja jika alokasinya berlebihan?
00:09:39Kita juga harus memikirkan anggaran latensi, tergantung pada jenis aplikasi agen yang kita bangun.
00:09:44Jadi ini membawa kita pada gagasan bahwa kita harus memastikan untuk menerapkan penjadwalan yang peka terhadap agen.
00:09:49Kita harus memastikan bahwa kita menempatkan pekerjaan yang akan selesai paling cepat dan paling murah, alih-alih menempatkannya di GPU acak.
00:09:58Contoh konkretnya adalah penjadwal perlu menyadari bahwa permintaan R berada di langkah ketiga dari lima langkah alur kerja,
00:10:05dan di langkah satu dan dua telah menghabiskan X plus Y dolar.
00:10:09Jadi jika langkah ketiga gagal, seluruh alur kerja akan dihentikan, dan kita telah membuang semua sumber daya komputasi tersebut.
00:10:14Itulah mengapa orkestrasi yang peka terhadap alur kerja sangat, sangat penting,
00:10:18karena itu akan mengubah keputusan penerimaan, prioritas, dan cara kita mencoba ulang.
00:10:25Sekarang mari kita bicara tentang optimasi.
00:10:27Saya tidak akan mendalami terlalu banyak optimasi.
00:10:29Ada banyak penelitian yang sudah dilakukan di luar sana, tetapi saya ingin membagikan sebuah kerangka kerja,
00:10:34yang setidaknya suka saya gunakan terkait hal ini, dan kita dapat membaginya menjadi empat kuadran.
00:10:40Pertama, bisakah kita menghindari pekerjaan tersebut?
00:10:42Artinya, bisakah kita melewatinya sepenuhnya melalui caching, dengan teknik seperti prefix caching, response caching, semantic caching?
00:10:48Kedua, bisakah kita berbagi pekerjaan tersebut?
00:10:51Bisakah beberapa permintaan berbagi komputasi melalui pembentukan batch?
00:10:54Contohnya pembentukan batch kontinu, prefill decode, chunk prefill, speculative decoding.
00:10:59Ketiga, bisakah kita memindahkan pekerjaan tersebut?
00:11:01Bisakah kita mengirimkannya ke model yang lebih murah atau lebih dekat dengan pengguna?
00:11:05Sebagian besar melalui pengalihan rute, bisakah kita mengarahkannya ke model yang lebih kecil, wilayah yang lebih murah, atau teknik lainnya?
00:11:12Dan terakhir, bisakah kita menunda pekerjaannya?
00:11:13Bisakah kita menunggu momen yang lebih baik melalui kontrol penerimaan dan antrean, yang menuntut kita memahami kelas prioritas dari permintaan ini dan menerapkan penjadwalan sadar tenggat waktu?
00:11:25Kerangka kerja ini sangat andal karena berlaku untuk berbagai teknologi.
00:11:29Anda mungkin menggunakan VLM, SG-Lang, atau TensorRT, tetapi setiap teknik masuk ke dalam salah satu kuadran ini.
00:11:35Jadi, kapan pun kita memikirkan optimasi untuk model kita, kita harus membandingkan dan mempertimbangkannya dengan teknik sebelumnya,
00:11:41serta melihat bagaimana semuanya saling melengkapi.
00:11:47Ketika kita memikirkan skala, penting untuk tidak hanya memikirkan performa model.
00:11:51Kita juga harus memikirkan biaya dan aspek ekonominya.
00:11:54Di situlah pentingnya memahami metrik apa yang sedang ingin kita optimalkan.
00:11:58Karena biaya bukan sekadar biaya GPU atau model.
00:12:02Ini adalah biaya dari seluruh parameter, percobaan ulang, penyimpanan, kegagalan, jaringan, dan tentu saja biaya operasional pengembangan dan semacamnya.
00:12:09Yang penting adalah memahami apa indikator kinerja utama untuk produk Anda yang akan memberi nilai tambah bagi pengguna.
00:12:17Jadi, mengoptimalkan biaya per token atau biaya per permintaan saja tidaklah cukup.
00:12:22Kita harus mengoptimalkan biaya per tugas yang berhasil, karena inilah yang sebenarnya dipedulikan oleh pengguna.
00:12:26Jika Anda mampu mengoptimalkannya, biaya untuk produk secara keseluruhan akan menurun dan pengguna akan jauh lebih puas.
00:12:36Sekarang mari kita bahas tentang keandalan, sedikit tentang keandalan dan artinya dalam mencegah kegagalan beruntun.
00:12:43Masalah kegagalan bukanlah sekadar GPU yang diserobot atau mati.
00:12:46Bagian yang menarik adalah ikatan umpan balik yang menyertainya.
00:12:49GPU bisa mengalami penurunan performa, latensi meningkat, klien mencoba ulang, kedalaman antrean melonjak, dan GPU yang sehat akan jenuh, yang memicu lebih banyak percobaan ulang dan kegagalan regional yang lebih luas.
00:13:02Ini adalah kegagalan beruntun yang klasik, tetapi dengan sedikit variasi pada aplikasi generatif: cache KV.
00:13:09Kita tidak bisa begitu saja melakukan restart atau mengalihkan rute ke kluster lain.
00:13:13Pool yang dingin harus dipanaskan terlebih dahulu sebelum bisa menyerap lalu lintas, dan selama itu pool yang panas harus menampung seluruh permintaan.
00:13:20Itulah mengapa penting untuk merancang pemutus sirkuit dengan sangat matang.
00:13:24Pemutus sirkuit pada lapisan pengalihan rute, kontrol penerimaan, dan pengurangan beban yang terikat pada kedalaman antrean, bukan sekadar penggunaan CPU atau memori.
00:13:34Kita juga harus memikirkan anggaran percobaan ulang, karena jika tidak, biayanya bisa membengkak jauh lebih cepat.
00:13:43Sekarang saya serahkan kepada rekan pembicara saya, Naman, untuk melanjutkan presentasi ini.
00:13:50Terima kasih.
00:14:20Saya serahkan kepada rekan pembicara saya, Naman.
00:14:22Saya serahkan kepada rekan pembicara saya, Naman.
00:14:25Saya serahkan kepada rekan pembicara saya, Naman.
00:14:26Saya serahkan kepada rekan pembicara saya, Naman.
00:14:27Saya serahkan kepada rekan pembicara saya, Naman.
00:14:28Saya serahkan kepada rekan pembicara saya, Naman.
00:14:29Saya serahkan kepada rekan pembicara saya, Naman.
00:14:30Saya serahkan kepada rekan pembicara saya, Naman.
00:14:31Saya serahkan kepada rekan pembicara saya, Naman.
00:14:32Saya serahkan kepada rekan pembicara saya, Naman.
00:14:33Saya serahkan kepada rekan pembicara saya, Naman.
00:14:34Saya serahkan kepada rekan pembicara saya, Naman.
00:14:35Saya serahkan kepada rekan pembicara saya, Naman.
00:14:36Saya serahkan kepada rekan pembicara saya, Naman.
00:14:54Oke, ini sepertinya berfungsi.
00:14:57Maaf atas kendalanya.
00:14:58Jadi, ketika inferensi mencapai skala produksi,
00:15:00bentuknya mulai tampak seperti sistem terdistribusi.
00:15:03Kita tidak lagi sekadar memanggil model.
00:15:06Ini lebih seperti masalah sistem terdistribusi klasik.
00:15:09Dalam sistem terdistribusi, kita berbicara tentang antrean, penjadwalan,
00:15:13skala otomatis, dan isolasi kesalahan.
00:15:14Ini adalah beberapa dimensinya.
00:15:16Inferensi memiliki semua masalah ini,
00:15:18tetapi kini ada batasan-batasan baru.
00:15:20Alih-alih memori CPU saja, kita memiliki CPU, HBM, cache KV,
00:15:25dan biaya per tugas yang berhasil.
00:15:27Jadi pertanyaan utamanya menjadi,
00:15:28bagaimana platform mengetahui apa yang harus dilakukan selanjutnya?
00:15:31Di sinilah observabilitas berperan.
00:15:34Ini bukan sekadar tentang dasbor.
00:15:35Ini tentang bagaimana memberikan sinyal input ke ikatan kontrol.
00:15:39Telemetri, bidang, analisis, lalu analisis mendorong keputusan,
00:15:43menangani masalah dan perubahan penjadwalan serta rute,
00:15:45dan akhirnya, kita tinggal mengulang prosesnya.
00:15:47Saya akan memberikan gambaran umum tentang beberapa metrik penting.
00:15:50Yang pertama adalah waktu hingga token pertama,
00:15:52yang memberi tahu berapa lama waktu yang dibutuhkan
00:15:56untuk mendapatkan respons pertama.
00:15:58Lalu ada rasio penggunaan,
00:16:00yang menunjukkan apakah memori atau komputasi yang menjadi kendalanya.
00:16:04Kita memiliki keberhasilan per dolar yang memberi tahu
00:16:06apakah platform benar-benar memberikan hasil
00:16:08dan bekerja secara efisien.
00:16:10Dan terakhir, ada latensi jejak ujung-ke-ujung
00:16:12yang menunjukkan berapa banyak waktu yang dihabiskan
00:16:15di seluruh jalur permintaan.
00:16:19Ada kompromi utama antara latensi, biaya, dan throughput.
00:16:22Anda tidak bisa mendapatkan semuanya sekaligus.
00:16:24Ini mirip dengan teorema CAP.
00:16:26Jika saya meningkatkan ukuran batch,
00:16:28saya meningkatkan throughput dan efisiensi biaya,
00:16:31tetapi hal itu dapat memperburuk latensi batas.
00:16:33Jika saya menggunakan dekoding spekulatif,
00:16:35saya mungkin memperbaiki latensi, tetapi membutuhkan ekstra komputasi.
00:16:38Pada akhirnya, biaya per token pun akan meningkat.
00:16:41Dan terakhir, saya bisa menggunakan model sederhana yang lebih kecil.
00:16:44Saya bisa mengurangi latensi dan biaya,
00:16:45tetapi kualitas responsnya akan rendah.
00:16:48Ujung-ujungnya, saya harus menganalisis kegagalan dan mencoba ulang,
00:16:50yang membuat biayanya naik kembali.
00:16:52Jadi setiap keputusan penyajian akan menggeser
00:16:54posisi sistem di dalam segitiga ini.
00:16:56Dan tugas kita adalah menemukan pengaturan yang paling pas.
00:16:58Ini hanyalah masalah optimasi sekarang.
00:17:03Ke sinilah arah industri saat ini.
00:17:05Inferensi membutuhkan bidang kontrolnya sendiri.
00:17:07Semua yang kita bahas-- pengalihan rute, batching, caching,
00:17:10penjadwalan, keandalan--
00:17:12semua itu tidak bisa lagi menjadi tombol yang terpisah.
00:17:15Semuanya menyatu menjadi satu lapisan logis.
00:17:17Sebut saja bidang kontrol inferensi.
00:17:19Dulu kita mengelola VM dalam sistem terdistribusi.
00:17:21Kita memiliki penjadwal skala otomatis.
00:17:23Dan kita memiliki Kubernetes, yang mengubah semua ini menjadi bidang kontrol.
00:17:27Inferensi sedang mengalami transisi yang sama sekarang.
00:17:30Model-model mulai menjadi sumber daya.
00:17:32GPU, kvcache, token, latensi, dan biaya kini dijadwalkan secara teratur.
00:17:36Control plane memutuskan model mana yang melayani permintaan mana
00:17:40dan bagaimana proses pemrosesannya dikelompokkan.
00:17:42Jadi, baik kita membangun lapisan ini secara internal,
00:17:44menggunakan sumber terbuka, atau dari vendor,
00:17:46desain utamanya adalah mengasumsikan lapisan tersebut akan ada.
00:17:50Sekarang mari kita bahas beberapa pelajaran operasional
00:17:53yang telah kita alami dalam infrastruktur AI
00:17:55dan bagaimana itu dapat diterapkan di sini.
00:17:57Pelajaran pertama adalah bahwa hambatan infrastruktur
00:18:00biasanya muncul sebelum hambatan pada model.
00:18:02Dalam produksi, banyak kegagalan bisa terjadi,
00:18:04tetapi itu bisa saja hanya terkait penjadwalan dan perutean
00:18:07atau masalah kapasitas.
00:18:08Jadi ini tidak berkaitan dengan inferensi.
00:18:10Ini adalah masalah infrastruktur.
00:18:12Lalu kita memiliki elastisitas.
00:18:14Kita membutuhkan elastisitas dalam sistem.
00:18:15Kita bisa menambah lebih banyak GPU, tetapi ini tidak benar-benar menyelesaikan masalah.
00:18:18Kita hanya menyembunyikan masalahnya.
00:18:20Lalu solusi kita untuk penjadwalan keputusan
00:18:24dapat mengungguli efisiensi teknis.
00:18:26Armada yang sama dapat memberikan hasil yang sangat optimal,
00:18:28tergantung bagaimana Anda menjadwalkannya
00:18:30atau bagaimana Anda mengelompokkannya.
00:18:31Lalu kita memiliki control loop, yang mengalahkan proses manual.
00:18:35Platform harus dapat merasakan, mendeteksi,
00:18:37dan beradaptasi secara otomatis dengan sistem.
00:18:39Jadi poin utamanya adalah jangan mengoptimalkan jumlah token.
00:18:43Optimalkan untuk keberhasilan tugas.
00:18:48Jadi inilah pergeseran lebih luas yang ingin saya sampaikan.
00:18:51Fase pertama infrastruktur AI adalah tentang model yang lebih baik.
00:18:54Kita menginvestasikan banyak waktu untuk meningkatkan model kita,
00:18:56membuatnya lebih cerdas,
00:18:58dan menciptakan tolok ukur yang lebih baik.
00:19:00Fase saat ini adalah tentang inferensi yang lebih cepat,
00:19:03latensi yang lebih rendah, pengelompokan yang lebih baik,
00:19:05serta penggunaan GPU yang lebih optimal.
00:19:08Namun fase berikutnya adalah tentang orkestrasi.
00:19:10Artinya, GPU, memori, cache, dan semuanya,
00:19:13itu hanyalah sumber daya,
00:19:14dan perlu dijadwalkan serta dikendalikan.
00:19:17Tim yang memahami hal ini sejak awal
00:19:19akan membangun infrastruktur untuk masa depan.
00:19:21Jadi kesimpulannya adalah,
00:19:23infrastruktur bukan lagi masalah penayangan.
00:19:25Ini adalah masalah orkestrasi.
00:19:27Terima kasih.
00:19:29Terima kasih.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video