Analisis Mendalam tentang Inferensi LLM Skala Besar — Harshul Jain, Audible & Tanmay Sah, Peneliti AI Independen

AAI Engineer
컴퓨터/소프트웨어경제 뉴스AI/미래기술

스크립트

00:00:00Selamat sore semuanya. Nama saya Harshal Jain dan ini Tanmisha. Dan kami
00:00:21ingin menyambut Anda semua dalam workshop dua jam tentang inferensi LLM.
00:00:26Jadi tujuan dari workshop ini adalah untuk memahami domain ini dari prinsip-prinsip
00:00:33dasar, mendalaminya, dan memahami apa yang terjadi di seluruh
00:00:39industri. Sedikit latar belakang tentang kami. Saya adalah seorang insinyur perangkat lunak senior di
00:00:47Audible. Saya telah membangun platform data ML AI selama lima tahun terakhir dan di
00:00:53samping itu saya menulis buku panduan sumber terbuka ini mengenai inferensi LLM. Dan
00:00:59Tanmay, dia adalah seorang pemodel kuantitatif senior di Xi'an's Bank Corporation. Dia
00:01:06baru saja menyelesaikan PhD-nya dan aktif melakukan penelitian di bidang penguji agen
00:01:12dan model dunia. Jadi, mari kita lihat acungan tangan sebentar di sini. Siapa yang benar-benar baru mengenal inferensi LLM?
00:01:24Baiklah, bagus. Dan siapa yang sudah menerapkan model-model ini ke dalam produksi? Mereka telah
00:01:33melakukan penyesuaian, mereka telah melayani trafik produksi. Oke, bagus. Jadi
00:01:42workshop ini ditujukan untuk tingkat pemula dan menengah. Dan semua
00:01:48slide serta latihan ada di repositori yang akan segera saya bagikan. Berikut adalah
00:01:56agenda singkat untuk workshop ini. Kita akan mulai dengan pernyataan masalah. Kita akan mencoba
00:02:01memahami beberapa kendala seputar inferensi LLM. Kemudian kita memahami apa penyebab kendala tersebut
00:02:08dan membangun fondasi kita dari sana. Selanjutnya kita akan membahas dua
00:02:14jenis pengoptimalan yang kita lakukan, seperti pengoptimalan model dan pengoptimalan
00:02:19penyajian (serving). Lalu kita mulai mempelajari berbagai mesin penyajian yang
00:02:25tersedia untuk menerapkan solusi inferensi LLM kita dalam produksi. Dan kita akan menampilkan beberapa tolok ukur
00:02:32serta diagram keputusan tentang mesin mana yang harus digunakan.
00:02:39Baiklah. Jadi untuk memahami kendalanya, pertama-tama kita perlu tahu apa itu inferensi LLM. Jadi
00:02:47saya rasa banyak dari kita sudah mengetahuinya. Tapi ya, apa pun yang Anda minta AI Anda untuk lakukan,
00:02:55baik itu menghasilkan video, audio, menganalisis teks apa pun, menganalisis laporan medis Anda atau
00:03:02tagihan pajak Anda, semua itu adalah bentuk inferensi LLM. Dan pasar ini bernilai sekitar 23 miliar dolar hari ini.
00:03:12SemiAnalysis baru-baru ini menyampaikan bahwa jika Anda ingin memodelkan kueri pencarian Google dengan LLM, Anda memerlukan penguras keuntungan sekitar 36 miliar dolar.
00:03:25Dan biaya kueri harus kurang dari 0,5 sen agar bisnis pencarian Anda tetap menguntungkan.
00:03:33Di sisi lain, Business Insider menyebutkan bahwa AI Anda harus digunakan dengan tepat dan setiap orang harus mulai mengaudit serta membuat anggaran penggunaan token mereka.
00:03:43Dan semua ini sedang terjadi. Mengapa? Karena perangkat keras Anda terbatas, daya komputasi mahal, inferensi Anda mahal.
00:03:50Dan dengan meningkatnya kebutuhan akan penggunaan AI yang semakin besar, biaya inferensi ini terus meningkat.
00:04:03Jadi statistik ini, ini adalah statistik lama dari OpenAI, tetapi masih berlaku.
00:04:11Jadi jika Anda melihat biaya pelatihan GPT-3, itu sekitar 4,6 juta dolar. Itu adalah biaya satu kali.
00:04:19Tetapi jika Anda melihat biaya inferensi, itu adalah biaya yang berulang karena merupakan biaya operasional yang berskala dengan setiap pengguna yang masuk, setiap token yang masuk, setiap sesi yang dimulai pada AI tersebut.
00:04:36Dan pada dasarnya hanya ada dua cara untuk mengatasi hal ini: satu cara adalah Anda mengurangi penggunaan token Anda.
00:04:47Alternatifnya adalah Anda harus mencoba mengoptimalkan solusi inferensi Anda sebagai penyedia layanan inferensi untuk pelanggan Anda dan untuk diri Anda sendiri.
00:04:58Dan oleh karena itu, kita telah melihat semakin banyak solusi baru yang bermunculan dari waktu ke waktu.
00:05:06Sehingga gagasannya adalah, oke, kita akan mencoba membangun fondasi tersebut yang akan membantu kita memahami dan mengevaluasi apa pun yang dirilis berikutnya.
00:05:18Jadi, ya, untuk memulai, kita akan melakukan demo singkat, yaitu demo singkat mengenai berbagai kendala seputar inferensi.
00:05:28Dan ini adalah sebuah repositori.
00:05:31Maksud saya, Anda dapat menariknya (pull) atau Anda juga dapat membukanya di GitHub.
00:05:36Namanya adalah LLM inference at scale.
00:05:39Sedikit latar belakang di sini, sekitar empat bulan lalu ketika saya belum tahu apa pun tentang inferensi LLM, saya mulai mempelajarinya.
00:05:46Saya melihat banyak sumber yang tersebar.
00:05:49Jadi kami mulai menyatukannya di satu tempat agar dapat bermanfaat bagi banyak orang.
00:05:55Ya, jadi izinkan saya keluar dari mode tayangan slide ini dan mungkin beralih ke mode yang diperluas ini.
00:06:11Ya, jadi di repositori ini, jika Anda melihat berkas README, terdapat tautan ke slide.
00:06:27Jadi ini akan berupa folder tempat Anda memiliki PPTX dan terdapat laporan tolok ukur di dalamnya.
00:06:34Anda selalu dapat mengunduhnya dan untuk keperluan demo, kami memiliki beberapa Jupyter notebook.
00:06:43Kami telah bekerja sama dengan Molab yang merupakan alternatif Google Colab dan apa yang mereka sediakan pada dasarnya adalah GPU RTX 6000 gratis.
00:06:54Jadi ini adalah GPU RAM 100 GB dan kami telah menyiapkan notebook ini sedemikian rupa sehingga mudah untuk dieksperimenkan dan semua aset serta segala sesuatunya telah disetel sebelumnya untuk Anda.
00:07:09Jadi kita akan mulai dengan demo A yang sederhana.
00:07:16Mungkin, mari saya lihat.
00:07:31Ya, jadi ketika menyangkut inferensi, Anda perlu melakukan inferensi pada model tertentu, bukan?
00:07:40Jadi, untuk keperluan workshop, kami menggunakan model Mistral 7B yang sederhana.
00:07:45Ini adalah model kecil dengan ukuran sekitar 15 GB.
00:07:49Jadi kita akan memuatnya ke dalam GPU.
00:07:53Dan kita juga akan melihat beberapa statistik GPU.
00:07:58Jadi kita lihat, oke, kita sedang bekerja pada 6000 Blackwell.
00:08:01Jadi, Anda mungkin berpikir saya tidak menjalankan sel karena saya tidak mempercayai Wi-Fi di konferensi.
00:08:08Jadi, ya, saya mungkin akan membahas hasil yang sebelumnya telah kita jalankan.
00:08:18Ya, jadi kita memiliki GPU berkapasitas 102 GB.
00:08:22Sekarang, hal pertama yang terlintas di benak saya adalah seperti apa konsumsi memori saya ketika saya melakukan inferensi LLM.
00:08:31Jadi saya memuat model ini dan saya melihat, oke, saya memiliki sekitar 15 GB di sini.
00:08:37Jadi saya memiliki sisa sekitar 87,5 GB.
00:08:40Dan sekarang ketika saya melakukan inferensi di sini, yang saya perhatikan adalah semakin banyak masukan yang saya berikan, semakin banyak pula memori yang saya perlukan.
00:08:52Dan jumlahnya meningkat secara perlahan, tetapi tetap meningkat.
00:08:56Jadi bayangkan jika Anda memiliki panjang konteks sekitar 4.000 atau 16.000 atau 32.000 token.
00:09:03Maka memori ini bisa tumbuh sangat besar dan Anda benar-benar bisa mengalami masalah kehabisan memori (out of memory).
00:09:12Jadi jelas ini adalah masalah pertama Anda, yaitu memori yang meningkat seiring dengan bertambahnya token.
00:09:18Dalam bentuk visualisasi sederhana, bentuknya seperti ini.
00:09:24Masalah kedua yang akan Anda lihat adalah waktu untuk token pertama Anda sangat, sangat lambat.
00:09:32Kita mengukurnya dengan metrik bernama TTFT.
00:09:35Itu adalah singkatan darinya.
00:09:37Dan ketika Anda mencoba mengukur TTFT dengan ukuran masukan, Anda akan melihat bahwa semakin panjang konteksnya, semakin lambat pula TTFT tersebut.
00:09:52Jadi sekarang ada dua masalah.
00:09:54Memori Anda meningkat seiring ukuran token.
00:09:56TTFT Anda meningkat seiring ukuran token.
00:09:59Maaf, bukan ukuran token, melainkan ukuran konteks.
00:10:07Dan yang ketiga adalah throughput.
00:10:09Throughput adalah berapa banyak token yang dapat Anda layani per detik?
00:10:13Dan kemudian berapa banyak pengguna yang dapat Anda layani per detik?
00:10:16Jadi jika Anda menggunakan implementasi yang sangat-sangat standar pada sistem lokal Anda, prosesnya akan sangat berurutan (sekuensial).
00:10:24Jadi jika Anda mengirim lima permintaan, kelima permintaan tersebut akan dilayani secara berurutan, bukan secara paralel.
00:10:31Sehingga permintaan Anda pada dasarnya membutuhkan lebih banyak waktu untuk selesai jika Anda memiliki banyak pengguna.
00:10:40Jadi inilah ketiga masalah tersebut.
00:10:43Ada masalah keempat.
00:10:44Saya belum menjelaskannya di sini.
00:10:45Mungkin kita akan membangun pemahaman itu seiring kita maju.
00:10:48Tetapi mari kita ingat bahwa ini adalah tiga masalah utama: memori, TTFT, dan throughput.
00:10:55Baiklah.
00:10:56Saya akan kembali ke slide.
00:11:02Oke.
00:11:03Sempurna.
00:11:04Jadi seharusnya ini.
00:11:17Apakah terlihat?
00:11:18Ya.
00:11:19Terlihat.
00:11:20Terlihat.
00:11:21Ya.
00:11:22Terlihat.
00:11:23Terlihat.
00:11:24Terlihat.
00:11:25Ya.
00:11:26Terlihat.
00:11:27Terlihat.
00:11:28Ya.
00:11:29Terlihat.
00:11:30Ya.
00:11:31Terlihat.
00:11:32Ya.
00:11:33Terlihat.
00:11:34Ya.
00:11:35Terlihat.
00:11:36Terlihat.
00:11:37Ya.
00:11:38Terlihat.
00:11:39Ya.
00:11:40Terlihat.
00:11:41Ya.
00:11:42Terlihat.
00:11:43Ya.
00:11:44Terlihat.
00:11:45Ya.
00:11:46Ya.
00:11:47Jadi di dalam repositori tersebut, jika Anda melihat folder workshop, Anda akan melihat README dan kemudian README
00:11:55memiliki semua tautan, slide, dan demo.
00:12:01Apakah itu berfungsi?
00:12:06Oke.
00:12:07Sempurna.
00:12:09Oke.
00:12:10Sempurna.
00:12:16Oke.
00:12:17Jadi mari kita mulai mempelajari fondasinya.
00:12:19Mari kita mulai memahami apa alasan di balik kendala-kendala tersebut.
00:12:25Dan untuk itu, kita harus melihat pipa (pipeline) inferensi ini.
00:12:32Jadi, kita mendapatkan teks masukan.
00:12:35Teks tersebut bisa memiliki jumlah kata berapa pun.
00:12:38Anda mengonversi kata-kata tersebut menjadi token.
00:12:41Jadi untuk kesederhanaan, Anda bisa menganggap satu kata sama dengan satu token.
00:12:46Kemudian Anda mengubahnya menjadi penyematan (embeddings) lalu mengirimkannya ke transformer.
00:12:53Seperti ada 32 lapisan transformer, tetapi itu khusus untuk Mistral 7.
00:12:58Model yang berbeda memiliki jenis dan jumlah lapisan yang berbeda.
00:13:01Dan kemudian Anda menghasilkan token baru.
00:13:04Dan token itu pada dasarnya kembali ke masukan.
00:13:06Lalu Anda menghasilkan token lain dan itu terus berlanjut.
00:13:09Sekarang di seluruh alur ini, Anda akan melihat sekitar 95% komputasi Anda diambil oleh lapisan-lapisan transformer ini.
00:13:18Jadi ada baiknya melihat apa yang terjadi di dalam lapisan transformer ini.
00:13:24Di dalam lapisan transformer ini, Anda akan memiliki lebih banyak lapisan.
00:13:28Anda memiliki lapisan normalisasi.
00:13:30Anda memiliki lapisan atensi.
00:13:32Anda memiliki lapisan feed forward dan semuanya.
00:13:35Dan lapisan atensi adalah lapisan yang saya rasa sangat, sangat terkenal.
00:13:40Orang-orang pembuat “Attention is all you need”.
00:13:42Saya pikir itu sangat terkenal.
00:13:44Jadi atensi adalah lapisan yang paling banyak menggunakan komputasi.
00:13:48Dan kita perlu memahami apa yang terjadi di dalam lapisan atensi tersebut.
00:13:53Jadi apa yang dilakukan oleh atensi?
00:13:56Jadi jika Anda memiliki teks masukan, teks itu perlu mencari skor atensi dari setiap token terhadap semua token sebelumnya.
00:14:05Dan untuk melakukan itu, yang harus dilakukannya adalah memproyeksikan setiap token ke dalam ruang kunci (key), kueri (query), dan nilai (value).
00:14:14Jadi dalam istilah yang lebih sederhana, pahami saja ini.
00:14:20Seperti jika Anda memiliki 10 token, maka diperlukan 10 vektor kueri, kunci, dan nilai yang berbeda.
00:14:26Jika ada 100 token, Anda akan membutuhkan 100 vektor kunci dan nilai.
00:14:31Jika ada 1000 token, Anda akan membutuhkan 1000 vektor nilai kunci.
00:14:35Jadi jumlah vektor kunci dan nilai Anda akan meningkat seiring dengan bertambahnya ukuran masukan.
00:14:45Dan jika Anda menghitung ukuran KV per token, untuk mistral 7b, hasilnya adalah 131 KV.
00:14:54Ini karena Anda memiliki dua vektor, K dan V.
00:14:59Anda harus mengalikan ukurannya.
00:15:02Satu vektor memiliki sekitar 128 dimensi.
00:15:04Anda harus mengalikannya dengan 32 lapisan transformer.
00:15:08Dan kemudian Anda harus mengalikannya dengan kepala KV (KV heads).
00:15:11Untuk mistral 7b, itu adalah kepala KV.
00:15:15Jumlahnya bukan 32 karena menggunakan jenis mekanisme atensi yang berbeda, yang pasti akan kita bahas.
00:15:23Tapi ya, jadi ukuran KV per token adalah sekitar 131 KV.
00:15:30Sekarang bayangkan jika Anda memiliki konteks 4K, maka ukuran itu menjadi sekitar setengah GB.
00:15:37Jika Anda membuat konteks 16K, ukuran itu menjadi 2,1 GB.
00:15:42Sekarang kalikan dengan jumlah pengguna.
00:15:45Misalnya Anda dapat melayani beberapa pengguna secara bersamaan.
00:15:49Pada saat yang sama di dalam GPU tersebut, Anda bisa memiliki sekitar 42 GB dengan konteks 4K dan 80 pengguna.
00:15:58Dan jika GPU Anda hanya berukuran, katakanlah 24 GB, memori Anda sudah akan habis.
00:16:04Sehingga Anda tidak dapat melayani sebanyak itu pengguna dengan konteks sebanyak itu.
00:16:11Untuk memvisualisasikannya, lihatlah memori GPU.
00:16:14Jadi memori GPU memiliki bobot model yang cukup tetap.
00:16:19Ini adalah bobot yang telah dilatih sebelumnya.
00:16:21Ada juga overhead yang sifatnya tetap.
00:16:24Hal itu juga berubah, tetapi tidak berubah terlalu banyak.
00:16:29Secara keseluruhan, Anda bisa menganggapnya tetap.
00:16:32Dan kemudian ada sisa memori.
00:16:35Jadi sisa memori inilah yang digunakan oleh memori KV Anda, seperti vektor kunci dan nilai.
00:16:41Jadi, bayangkan Anda memiliki satu pengguna.
00:16:46Anda hanya dapat melayani vektor kunci dan nilai sebanyak itu atau token sebanyak itu, yang dapat muat di seluruh memori 80 GB ini, seperti memori yang tersisa.
00:17:00Jadi kita juga dapat menunjukkan ini dengan demo sederhana.
00:17:07Baiklah, bagus.
00:17:08Baiklah, bagus.
00:17:08Coba saya lihat apakah saya benar-benar bisa menjalankan ini.
00:17:14Baiklah, bagus.
00:17:15Coba saya lihat apakah saya benar-benar bisa menjalankan ini.
00:17:15Di mana letaknya ini?
00:17:15Baiklah, bagus.
00:17:16Coba saya lihat apakah saya benar-benar bisa menjalankan ini.
00:17:21Di mana letaknya ini?
00:17:22Baiklah, bagus.
00:17:23Baiklah, bagus.
00:17:24Ya.
00:17:25Ya.
00:17:25Jadi, Anda akan melihat mari saya lihat apakah saya benar-benar bisa menjalankan ini.
00:17:31Coba saya lihat apakah saya benar-benar bisa menjalankan ini.
00:17:33Coba saya lihat apakah saya bisa menjalankan ini.
00:17:34Coba saya lihat apakah saya bisa menjalankan ini.
00:17:35Coba saya lihat apakah saya bisa menjalankan ini.
00:17:36Coba saya lihat apakah saya bisa menjalankan ini.
00:17:37Baiklah, bagus.
00:17:38Ya.
00:17:39Jadi, Anda akan melihat GPU-nya terpasang.
00:17:43Baiklah, bagus.
00:17:44Ya.
00:17:45Jadi, Anda akan melihat GPU-nya terpasang.
00:17:56Jadi, di sini kita hanya mencoba mengonfirmasi memorinya berdasarkan perhitungan matematika dan berdasarkan intuisi yang telah kita bangun.
00:18:13yang telah kita miliki.
00:18:14Jadi, memori modelnya adalah katakanlah jika Anda memiliki 7 miliar parameter, Anda menggunakan
00:18:19presisi 16-bit.
00:18:20Total memori Anda menjadi 14,6 GB.
00:18:23Anda pada dasarnya dapat memverifikasinya dengan matematika.
00:18:27Jadi, jika Anda melakukan semua perhitungan itu, hasilnya adalah 14,6 GB.
00:18:33Sekarang tibalah pada KV dan ukuran KV.
00:18:37Jadi, ukuran KV ini seperti 131 KV per token.
00:18:42Dan jika Anda melakukan perhitungan itu dan mencoba memvisualisasikannya.
00:18:47Oh, tentu.
00:18:52Tunggu.
00:18:53Baiklah.
00:18:54Dan kemudian mari kita visualisasikan ini.
00:19:07Baiklah, bagus.
00:19:10Bagus.
00:19:11Ya.
00:19:12Jadi, ini adalah diagram memori.
00:19:15Jadi, jika Anda melihat saat konteks Anda bertambah, memori Anda akan terus meningkat.
00:19:21Kemudian hal lain yang perlu disadari adalah saat pengguna Anda bertambah, memori Anda juga akan meningkat.
00:19:28Jadi, jika Anda ingin melayani 160 pengguna pada satu GPU, Anda hanya dapat mendukung, Anda hanya dapat mendukung
00:19:37panjang konteks yang lebih kecil.
00:19:40Jadi, selalu ada pertukaran antara panjang konteks apa yang dapat Anda layani versus berapa banyak biaya
00:19:47yang dapat Anda hemat dengan menempatkan beberapa pengguna atau pengguna konkuren ke dalam satu GPU.
00:19:54Jadi, Anda harus selalu mengambil kompromi tersebut.
00:19:57Dan kita akan membahasnya dalam beberapa slide lagi.
00:20:06Bisakah Anda mengulanginya?
00:20:10Maaf.
00:20:11Saya tidak bisa mendengar Anda.
00:20:12Apakah Anda melihat kumpulan yang berbeda dengan panjang konteks yang berbeda sehingga Anda dapat melayani memori yang tepat
00:20:25dari yang benar?
00:20:26Ya.
00:20:27Keren.
00:20:28Keren.
00:20:29Baiklah.
00:20:30Bagus.
00:20:31Jadi, izinkan saya menarik kembali.
00:20:32Jadi, itu adalah memori.
00:20:33Kita perlu memahami mengapa kita mengalami waktu ke token pertama yang lebih lambat ketika kita meningkatkan panjang konteks.
00:20:53panjang.
00:20:54Jadi, untuk itu kita perlu memahami dua fase inferensi.
00:20:58Dan fase tersebut adalah fase pre-fill dan decode.
00:21:01Saya pikir Anda semua, sepertinya ada banyak artikel, tapi kami hanya ingin menjelaskannya.
00:21:06Jadi, ketika Anda mengirim banyak, seperti ketika Anda mengirim token masukan ini, yang ingin Anda lakukan adalah membangun kunci dan vektor nilai yang saya sebutkan untuk semua token.
00:21:20Kemudian Anda ingin menghitung skor atensi setiap token terhadap token sebelumnya.
00:21:27Semua operasi yang Anda lakukan ini sangat, sangat berat secara matriks.
00:21:31Ini adalah operasi yang sangat, sangat berat dalam komputasi.
00:21:34Dan kita semua tahu bahwa GPU sangat cocok untuk beban kerja komputasi yang berat.
00:21:41Jadi, kita menyebut fase pre-fill sebagai terikat komputasi (compute bound).
00:21:46Dan ini memang membutuhkan waktu untuk selesai.
00:21:49Jadi, berapa pun waktu yang dibutuhkan fase ini untuk selesai, itulah waktu menuju token pertama Anda.
00:21:55Jadi, jika Anda memiliki lebih banyak token masukan, Anda harus menghasilkan lebih banyak vektor nilai kunci.
00:22:02Anda harus melakukan lebih banyak matematika atensi.
00:22:05Dan karena itu, TTFT Anda menjadi semakin lambat.
00:22:12Sedangkan jika setelah Anda menghasilkan satu token, Anda harus terus melakukan ini untuk menghasilkan token lainnya, secara berurutan satu demi satu.
00:22:20Tetapi dalam proses tersebut, setiap kali Anda harus membangun vektor kunci dan nilai dari semua token sebelumnya, yang sama seperti tahap pengisian awal.
00:22:30Seperti Anda membangun vektor kunci nilai di sana juga, di sini juga.
00:22:34Tetapi dalam fase dekode, Anda hanya menghitung matematika perhatian untuk token baru.
00:22:40Dan itulah mengapa itu sangat sedikit, lebih sedikit berorientasi pada komputasi.
00:22:45Dan itu juga disebut sebagai terikat memori.
00:22:48Kita akan segera melihatnya mengapa itu disebut sebagai terikat memori.
00:22:54Jadi, dalam garis waktu klasik, Anda akan melihat fase pengisian awal dan dekode seperti ini.
00:22:59Jadi, waktu yang dibutuhkan oleh pengisian awal, itulah waktu Anda ke token pertama.
00:23:03Dan kemudian waktu yang diambil oleh setiap langkah dekode, itulah pada dasarnya latensi antar-token Anda.
00:23:12Jadi, itu seperti metrik keempat yang perlu Anda khawatirkan.
00:23:18Seperti berapa waktu yang dibutuhkan oleh langkah dekode Anda?
00:23:21Baik.
00:23:22Baik.
00:23:23Keren.
00:23:24Sekarang, mengapa langkah dekode atau mengapa dekode membutuhkan waktu?
00:23:34Dan mengapa itu disebut sebagai operasi yang terikat memori?
00:23:38Mari kita coba memahaminya.
00:23:40Untuk memahaminya, kita perlu melihat bagaimana peta matriks pada dasarnya bekerja pada GPU pada tingkat tinggi.
00:23:47Jadi, GPU memiliki dua jenis memori.
00:23:50Anda memiliki memori bandwidth tinggi.
00:23:52Anda memiliki memori bersama.
00:23:55Jadi, memori bandwidth tinggi ukurannya lebih besar, tetapi bandwidthnya lebih rendah.
00:24:01Dengan bandwidth yang lebih rendah, maksud saya Anda dapat mentransfer data darinya pada tingkat yang lebih rendah.
00:24:06Dibandingkan dengan memori bersama, jadi memori bersama ukurannya lebih kecil, tetapi memiliki bandwidth yang sangat, sangat tinggi.
00:24:13Artinya Anda dapat mentransfer data masuk dan keluar darinya dengan sangat cepat.
00:24:19Jadi, ketika Anda harus melakukan peta matriks, Anda harus mengambil data dalam potongan-potongan dari memori bandwidth tinggi.
00:24:27Anda harus memasukkannya ke dalam memori bersama.
00:24:30Lakukan matematika itu.
00:24:32Tulis kembali hasilnya ke dalam memori bandwidth tinggi.
00:24:38Untuk fase pengisian awal, ketika Anda harus melakukan ini, Anda harus melakukan matematika matriks ini hanya sekali.
00:24:46Tetapi untuk fase dekode, Anda harus melakukan matematika matriks ini berulang kali karena Anda menghasilkan setiap token secara berurutan.
00:24:59Dan oleh karena itu, tidak peduli seberapa cepat dekode Anda karena sekarang Anda dapat mentransfer data Anda keluar dari memori bandwidth tinggi ke dalam memori bersama pada kecepatan tertentu.
00:25:14Karena Anda dibatasi oleh kecepatan bandwidth memori bandwidth tinggi.
00:25:18Dan dengan demikian, itu mengatur batas token Anda, seperti pada tingkat apa Anda sebenarnya dapat menghasilkan token dari langkah dekode.
00:25:32Jika Anda melihat ini di plot garis atap, ada bagian kiri yang disebut sebagai terikat memori.
00:25:42Secara matematis, itu diatur oleh intensitas aritmatika.
00:25:47Intensitas aritmatika adalah jumlah operasi flip-flop yang Anda lakukan per byte data yang ditransfer.
00:25:55Jadi, untuk langkah dekode, karena Anda mentransfer banyak data, seperti vektor kunci dan nilai dari semua token sebelumnya, bobot model,
00:26:08tetapi Anda melakukan lebih sedikit komputasi karena Anda menghitung matematika perhatian untuk satu token saja.
00:26:13Jadi, intensitas aritmatikanya sangat rendah.
00:26:18Tetapi untuk fase pengisian awal, Anda mentransfer data sekali, tetapi kemudian Anda melakukan komputasi berat ini.
00:26:27Dan karena itu, intensitas aritmatikanya sangat tinggi.
00:26:30Jadi, sekarang Anda tahu dalam hal matematika, mengapa komputer, mengapa intensitas aritmatika pengisian awal sangat tinggi dibandingkan dengan dekode Anda.
00:26:44Baik.
00:26:46Jadi, ini seperti demo kecil lainnya.
00:26:51Baik.
00:26:52Setiap kali saya harus melakukannya.
00:26:53Baik.
00:26:54Baik.
00:26:55Bagus.
00:26:56Saya harap ini sudah siap.
00:26:58Jadi, ya.
00:26:59Sekali lagi, kita memuat modelnya.
00:27:04Sekarang, ini seperti biaya pengisian awal.
00:27:09Jadi, apa yang pada dasarnya kita lakukan adalah kita mendapatkan teks masukan dan kemudian kita mencoba menghasilkan ini, langkah pengisian awal, jumlah waktu yang dibutuhkannya.
00:27:22Kita melihat bahwa saat kita meningkatkan ukuran token masukan, pengisian awal ini semakin meningkat.
00:27:28Jadi, Anda tahu, dan inilah alasan mengapa DTFT Anda meningkat.
00:27:33Dan kemudian waktu dekode Anda.
00:27:36Jadi, waktu dekode rata-rata tetap kurang lebih sama.
00:27:41Dan dengan demikian, jika mengasumsikan Anda mengabaikan awal dingin, waktu dekode Anda kira-kira berada di sekitar garis rata-rata.
00:27:50Itu masih dipengaruhi oleh ukuran masukan.
00:27:57Bukan berarti itu adalah waktu yang konstan.
00:28:00Dan itu karena masih perlu menarik vektor kunci dan nilai dari memori untuk semua token sebelumnya.
00:28:07Jadi, masih ada sedikit peningkatan waktu yang akan Anda lihat pada langkah dekode.
00:28:15Dan kemudian ini adalah plot garis atap klasik.
00:28:20Baik.
00:28:22Baik.
00:28:23Presentasi.
00:28:24Baik.
00:28:25Baik.
00:28:26Baik.
00:28:27Jadi, sekarang mari kita coba memahami dimensi throughput.
00:28:43Anda ingin memahami berapa banyak pengguna yang sebenarnya dapat Anda layani.
00:28:48Dan saya pikir kita melihat diagram memori GPU di mana kita melihat, oke, ada beberapa memori yang bebas untuk pertumbuhan vektor kunci dan nilai.
00:28:56Baik.
00:28:57Jadi, asumsikan Anda hanya memiliki satu pengguna.
00:29:01Berapa total ukuran KV yang Anda miliki yang dapat Anda dukung?
00:29:09Itu ditentukan oleh batas konteks Anda.
00:29:11Pengguna maksimum yang dapat Anda dukung adalah ketersediaan GPU Anda, memori apa pun yang tersedia di GPU, Anda membaginya dengan ukuran kunci dan nilai per pengguna.
00:29:25Dan ketika Anda melakukan itu, itu menghasilkan pengguna konkuren.
00:29:32Sekarang, asumsikan GPU Anda tetap, model Anda tetap, sehingga ukuran KV Anda per token tetap.
00:29:46Hanya ada dua dimensi yang tersisa di sini, yaitu konteks dan pengguna konkuren Anda.
00:29:53Jika Anda ingin melayani lebih banyak pengguna konkuren, Anda harus mengurangi panjang konteks.
00:29:57Jika Anda mengurangi panjang konteks, Anda dapat memengaruhi kualitas Anda.
00:30:02Jadi, ini adalah dua dimensi saat ini yang kita pertimbangkan.
00:30:09Kemudian jika kita, tetapi dapatkah Anda benar-benar melayani jumlah maksimum pengguna konkuren?
00:30:17Di dunia ideal, mungkin tidak karena setiap bisnis memiliki SLO latensi yang harus kita penuhi.
00:30:27Jadi, jika Anda ingat di langkah dekode saya katakan, waktu untuk dekode masih meningkat jika Anda memiliki lebih banyak masukan.
00:30:37Itu juga meningkat jika Anda memiliki lebih banyak pengguna.
00:30:40Jadi, pada akhirnya latensi antar-token Anda juga terpengaruh jika Anda memiliki ukuran batch yang lebih tinggi.
00:30:51Dan TTFT Anda juga terpengaruh.
00:30:53Jadi, sekarang ada dimensi ketiga yang harus Anda khawatirkan, yaitu latensi Anda.
00:30:58Jadi, tiga dimensi yang Anda miliki adalah kualitas, latensi, dan throughput.
00:31:04Jadi, itu menjadi segitiga kompromi di mana Anda harus memilih di antara keduanya.
00:31:11Jadi, untuk aplikasi obrolan premium, Anda pasti ingin memprioritaskan kualitas dan Anda ingin memprioritaskan latensi.
00:31:21Anda tidak ingin pengguna Anda menunggu, tidak tanpa batas waktu, tetapi mungkin untuk latensi yang lebih besar.
00:31:30Anda selalu dapat mengorbankan jumlah pengguna yang dapat Anda dukung pada GPU dan mungkin mengambil biaya tersebut, dengan lebih berfokus pada pelanggan.
00:31:39Jadi, dalam bentuk, dan jika Anda mempertimbangkan agen, maaf, beban kerja agen asinkron, Anda ingin memprioritaskan kualitas dan throughput.
00:31:53Karena ini adalah tugas yang berjalan lama.
00:31:56Dan Anda ingin melayani sebanyak mungkin tugas konkuren, tetapi dengan kualitas yang sangat, sangat tinggi.
00:32:06Dan seringkali kita berpikir, oke, jika GPU adalah GPU yang sangat mahal, itu mungkin bukan pilihan yang baik untuk kita.
00:32:19Tetapi ternyata itu benar-benar dapat memberi Anda biaya terendah per juta token.
00:32:27Tetapi Anda benar-benar harus mempercayai perhitungan Anda mengenai pengguna maksimum yang Anda inginkan dan Anda benar-benar harus membuat estimasi tersebut dengan benar.
00:32:40Jadi, kita memang memiliki, biarkan saya, oke, bagus.
00:32:55Jadi, untuk kalkulator kapasitas, ada tautan ke kolaborator karena saya sudah akrab dengannya.
00:33:01Saya harus bermigrasi dari seluruh pustaka widget dan saya tidak punya waktu.
00:33:16Jadi, karena malas, saya memilih kolaborator di sana.
00:33:20Permintaan maaf kepada lab saya.
00:33:23Jadi, V-RAM saya terhubung.
00:33:34Baik.
00:33:45Jadi, mungkin Wi-Fi.
00:33:46Baiklah, bagus.
00:34:02Jadi, apa yang telah kita lakukan di sini adalah kita memetakan beberapa GPU dengan V-RAM dan bandwidth mereka, flip-flop, dan biaya per jam.
00:34:11Kemudian kita membangun kalkulator kapasitas yang sederhana ini.
00:34:19Ini hanyalah visualisator KV di mana ketika Anda meningkatkan jumlah token, ukuran KV meningkat.
00:34:29Dan ketika Anda meningkatkan jumlah pengguna, ukuran Anda meningkat pada tingkat yang jauh lebih cepat.
00:34:37Dan kemudian, dalam kalkulator kapasitas ini, biarkan itu berjalan.
00:34:47Jadi, kita memiliki model yaitu model 7 miliar parameter yang kita pilih.
00:34:56Kita mengatur presisi ke FP16.
00:35:01Sekarang, kita memutuskan, cara kita membuat keputusan GPU adalah Anda harus memutuskan apa yang menjadi prioritas Anda, pertama-tama Anda harus memperbaiki satu dimensi yang paling Anda pedulikan.
00:35:15Jadi, untuk obrolan premium, saya menyebutkan bahwa latensi pastinya adalah prioritasnya.
00:35:21Dan kemudian untuk beban kerja asinkron, ukuran batch minimum yang ingin Anda layani dari satu GPU, itulah dimensi kedua.
00:35:31Jadi, hal-hal ini perlu Anda tentukan terlebih dahulu.
00:35:34Jadi, saya akan membahasnya seperti dalam aplikasi obrolan premium.
00:35:39Jadi, saya dapat melanjutkan dengan latensi 10 milidetik.
00:35:44Ukuran batch minimum, saya tidak peduli.
00:35:46Jadi, saya baik-baik saja dengan mungkin dua.
00:35:53Baik.
00:35:54Jadi, mungkin dengan tujuh pengguna konkuren pada satu GPU.
00:35:59Dan batas konteks saya sangat penting bagi saya karena saya ingin fokus pada kualitas juga.
00:36:07Dan jadi, saya melihat beberapa GPU.
00:36:10Jadi, H-108 GB, harganya sekitar 8 dolar per jam.
00:36:15Tetapi, apakah saya 300x?
00:36:19Apakah begitu?
00:36:20Ya.
00:36:21Jadi, harganya sekitar $10 per jam.
00:36:24Jadi, jika Anda melakukan semua perhitungan throughput yang kita bahas sebelumnya, Anda bisa menemukan biaya per juta token Anda.
00:36:34Biaya itu bisa jadi sangat, sangat, bisa jadi lebih murah.
00:36:37Jadi, Anda perlu melakukan perhitungan seperti itu dengan menetapkan dimensi-dimensi tersebut dan Anda perlu memilih GPU untuk menekan biaya inferensi Anda.
00:36:49Jadi, setidaknya ini adalah langkah awal yang bisa Anda ambil untuk mengoptimalkan inferensi.
00:36:56Baiklah.
00:37:01Jadi, slide berikutnya.
00:37:04Biar saya.
00:37:08Baik, bagus.
00:37:10Dan sekarang, hal berikutnya adalah tentang optimasi model.
00:37:15Jadi, sekarang kita pada dasarnya telah membangun fondasi di mana kita memahami beberapa kendala, alasan di balik kendala tersebut, dan mengapa itu terjadi.
00:37:23Bagaimana kita bisa mengatasi masalah kapasitas GPU tersebut.
00:37:29Kita perlu memahami apa yang dapat kita lakukan, seperti apa lagi yang bisa kita lakukan terkait hal ini.
00:37:33Jadi, ini tentang optimasi model dan saya pikir saya ingin mengundang Tanmay.
00:37:39Ia dapat berbicara lebih banyak tentang optimasi model ini mengingat ia pernah mengerjakannya selama masa risetnya.
00:37:47Baik.
00:37:48Baiklah.
00:37:49Saya ambil alih.
00:37:50Saya ambil alih.
00:37:54Ya.
00:37:55Di sini.
00:37:56Baiklah.
00:37:57Halo semuanya.
00:37:58Cek mik.
00:37:59Apakah suara saya terdengar sekarang?
00:38:00Ya.
00:38:01Oke.
00:38:02Jadi, halo.
00:38:03Saya Tanmay Shah.
00:38:04Saya bekerja sebagai pemodel kuantitatif senior dan juga peneliti AI.
00:38:08Fokus saya adalah pada verifikasi agen dan saat ini membangun model dunia.
00:38:13Jadi, untuk topik kali ini, optimasi model.
00:38:16Sebelum kita mulai membahas optimasi model, saya membuat templat riset agar lebih mudah bagi kita untuk memahami semua hal kompleks ini.
00:38:25Jadi, templat kita sederhana.
00:38:28Pertama, kita akan mengidentifikasi masalahnya.
00:38:30Langkah kedua, kita akan menyelesaikan masalah menggunakan dua algoritma.
00:38:34Ini hanyalah algoritma fiktif.
00:38:35Jadi, algoritma pertama disebut algoritma burung unta.
00:38:39Kapan pun kita melihat masalah, seperti burung unta yang memasukkan kepalanya ke dalam pasir.
00:38:46Jadi, hal yang sama akan kita lakukan.
00:38:47Kapan pun kita menghadapi masalah, kita akan mengabaikannya begitu saja.
00:38:51Jadi, ini adalah algoritma penting yang harus kita ikuti.
00:38:55Yang kedua dibuat, yang disebut algoritma piala dunia.
00:38:59Sebagai contoh, kita tidak tahu siapa yang akan memenangkan piala dunia FIFA ini.
00:39:03Jadi, yang dilakukan penyelenggara adalah membagi 48 tim ke dalam 12 grup.
00:39:11Kemudian babak 32 besar, jadi babak 32 besar saat ini sedang berlangsung.
00:39:16Lalu babak 16 besar, kemudian perempat final, lalu semifinal dan final.
00:39:21Jadi, apa yang mereka lakukan adalah memecahnya menjadi masalah-masalah yang lebih kecil dan hasil yang berguna akan maju ke babak berikutnya.
00:39:30Jadi, analogi atau algoritma yang sama akan kita gunakan untuk memahami optimasi model ini dan semua hal tersebut.
00:39:38Jadi, ya, mari kita mulai.
00:39:41Jadi, saya memiliki satu GPU H100.
00:39:46Saya harus menggunakan model sumber terbuka ini, yang disebut model dengan 120 miliar parameter GPT OSS.
00:39:54Jadi, saat ini saya rasa, mereka melatihnya pada BF float 16 dan bobotnya adalah 240 gigabyte.
00:40:02Apa yang harus saya lakukan?
00:40:04Ini adalah masalah yang kita hadapi.
00:40:07Hal pertama, yang harus kita lakukan adalah 240 gigabyte dan H100 80 gigabyte.
00:40:16Jadi, dan saya harus memuatnya hanya dalam satu GPU, bukan di beberapa GPU.
00:40:21Jadi, apa yang bisa kita lakukan?
00:40:22Saya pikir langkah sederhananya adalah mengkompresnya.
00:40:27Tapi bagaimana cara mengkompresnya?
00:40:29Itu adalah tantangan lain.
00:40:30Jadi, jika kita mengkompres BF float 16 ke FP8, ukurannya akan menjadi sekitar 120 gigabyte.
00:40:38Tapi GPU H100 kita tetap berkapasitas 80 gigabyte.
00:40:42Jadi, menurut saya apa yang mereka lakukan adalah mengkompresnya lebih lanjut menjadi MXFP4.
00:40:49Dan saya rasa ukurannya sekitar 65 gigabyte.
00:40:53Jadi, ini adalah sesuatu yang bisa kita lakukan, mengkompres, tetapi pertanyaannya.
00:40:59Jadi, dan kita akan menggunakan algoritma burung unta ini.
00:41:03Kita berasumsi bahwa tidak ada kehilangan kualitas dalam mengkompres model yang lebih besar ke ukuran yang lebih kecil.
00:41:10Jadi, hal kedua, dalam hal ini, oke, ya.
00:41:16Jadi, dalam hal ini, di slide ini, kita telah menggunakan Mistral 7B ini.
00:41:20Jadi, tujuh miliar parameter.
00:41:22Jadi, ini adalah model kecil, tujuh miliar parameter.
00:41:25Jadi, jika Anda mengalikannya dengan dua byte, bobotnya adalah sekitar 14.
00:41:3114,5 gigabyte, yang dapat dengan mudah dimuat ke dalam H100 atau bahkan A40.
00:41:38Jadi, berikutnya, apa yang bisa kita lakukan adalah alih-alih mengkompresnya dari floating point 16, kita dapat menerapkan teknik yang berbeda seperti int8, int4, atau nf4.
00:41:53Jadi, pada dasarnya, kita hanya perlu menggunakan algoritma burung unta dan percaya bahwa tidak ada penurunan kualitas atau semacamnya.
00:42:01Namun, bagaimanapun, kita juga harus membuktikannya secara matematis dengan melakukan pengujian tertentu pada beberapa tolok ukur eksternal apakah metode ini berhasil atau tidak.
00:42:10Jadi, hal ini termasuk dalam kategori kuantisasi pasca-pelatihan.
00:42:16Seseorang juga dapat melakukan ini selama penyetelan halus.
00:42:20Seseorang juga dapat melakukan jenis kuantisasi ini.
00:42:22Hal ini termasuk dalam kategori pelatihan yang sadar kuantisasi.
00:42:25Jadi, mari kita beralih ke masalah kita berikutnya.
00:42:31Jadi, kita memiliki matriks yang sangat besar ini.
00:42:37Jadi, bayangkan saja dimensi 1.000 kali 1.000, matriks A, dan matriks lainnya 1.000 kali 1.000.
00:42:51Jadi, jika Anda mengalikan kedua matriks ini, jumlah operasi yang dibutuhkan adalah 1.000 pangkat tiga.
00:43:00Dan ini menjadi sebuah masalah dari segi komputasi.
00:43:06Jadi, kita ingin perkalian matriks kita menjadi cepat dan menghemat memori.
00:43:13Jadi, apa yang harus kita lakukan?
00:43:15Kita memiliki matriks raksasa.
00:43:17Baiklah, ambil contoh yang ini, 4096 kali 4096.
00:43:23Apa yang harus kita lakukan untuk menyelesaikan masalah kita dalam mempercepat proses dan menghemat memori untuk ukuran 4096 kali 4096.
00:43:33Jadi, hal pertama adalah kita akan menggunakan algoritma World Cup kita.
00:43:37Kita dapat menentukan angka acak, cukup bagi blok tersebut secara vertikal.
00:43:42Tidak masalah angka berapa yang Anda pilih.
00:43:45Jadi, katakanlah kita memiliki 4096 kolom.
00:43:51Kita akan membaginya menjadi kelompok yang masing-masing terdiri dari 128 kolom.
00:43:57Jadi, 128, 128, 128, 128, 128 secara vertikal.
00:44:03Jadi, kita akan mendapatkan 32 blok jika kita membagi angka 4096 ini.
00:44:09Lalu, apa yang akan terjadi dengan melakukan hal ini?
00:44:13Jadi, jika kita membaginya secara vertikal, kita dapat menggunakan beberapa GPU untuk mempercepat proses.
00:44:21Jadi, hal semacam ini disebut perhatian multi-kepala.
00:44:26Jadi, apa lagi yang bisa kita lakukan?
00:44:29Kita memiliki matriks besar seperti yang saya sebutkan, yaitu algoritma burung unta.
00:44:36Jadi, masalah utama kita adalah ukuran.
00:44:39Jadi, apa yang bisa kita lakukan adalah alih-alih memiliki ke-32 blok vertikal tersebut, kita membuang 31 blok.
00:44:49Dan kita berasumsi bahwa satu blok sudah cukup untuk menangani semua kueri.
00:44:57Kehilangan informasi kita akan hampir bisa diabaikan.
00:45:00Dan kita sampai pada algoritma ini.
00:45:04Dan algoritma ini disebut perhatian kueri-tunggal.
00:45:08Jadi, seperti yang bisa kita lihat, saat ini kita berada di dua spektrum.
00:45:12Salah satunya adalah perhatian multi-kepala, di mana kita membaginya menjadi 32 blok dan menggunakan GPU berbeda atau melakukan pemrosesan paralel.
00:45:22Dan pada saat yang sama, kita membuang 31 blok begitu saja.
00:45:26Dan kita menyebutnya sebagai perhatian kueri-tunggal.
00:45:31Jadi, di kedua titik ekstrem tersebut, kita harus mencari jalan tengah.
00:45:38Kita dapat mengatakan bahwa alih-alih membuang ke-31 blok, mungkin kita dapat mengelompokkan beberapa blok menjadi satu.
00:45:49Dan kita dapat berasumsi bahwa blok-blok yang serupa akan memperhatikan jenis kueri yang serupa.
00:45:58Jadi, teknik semacam ini termasuk dalam kategori perhatian kueri berkelompok, yang sangat populer saat ini.
00:46:04Bahkan di Mistral atau model lainnya, perhatian kueri berkelompok ini bekerja dengan baik.
00:46:11Jadi, sekarang kita telah memahami bahwa kita memiliki matriks yang besar.
00:46:16Kita dapat membaginya sesuai keinginan kita dan dengan melakukan perhitungan matematis,
00:46:19membuktikan bahwa tingkat kehilangan informasinya hampir bisa diabaikan.
00:46:23Jadi, apa lagi yang bisa kita lakukan?
00:46:25Jadi, setelah itu, setelah perhatian kueri berkelompok ini,
00:46:34perhatikan, kita memiliki matriks yang besar.
00:46:38Yang satu adalah kunci dan yang satu lagi adalah nilai.
00:46:42Mari kita kompres matriks tersebut menjadi vektor laten.
00:46:47Dan kemudian membuat beberapa algoritma untuk merekonstruksi ulang dari vektor laten ke matriks asli kita.
00:46:55Jadi, strategi semacam ini termasuk dalam kategori ini.
00:46:59Perhatian laten multi-kepala.
00:47:02Namun sekali lagi, metode ini memiliki beberapa masalah dengan RoPE karena RoPE bergantung pada posisi sedangkan metode ini tidak bergantung pada posisi.
00:47:10Jadi, seseorang juga perlu menyertakan indeks untuk kunci agar dapat memetakannya.
00:47:16Tapi sekali lagi, masalah utamanya adalah mengapa kita mengalikan semua matriks besar tersebut.
00:47:25Karena begitulah mekanisme perhatian ini bekerja, di mana setiap token akan memperhatikan setiap token lainnya.
00:47:33Jadi, bagaimana jika kita tidak perlu memperhatikan semua token sebelumnya, melainkan hanya memperhatikan token-token yang penting bagi kita.
00:47:42Jadi, bidang seperti ini sedang berkembang.
00:47:46Jadi, ini masuk dalam sparse attention DeepSeek.
00:47:51Jadi, ya.
00:47:53Dan, ya, jadi, oke.
00:47:56Berikutnya.
00:47:59Ya, jadi yang berikutnya adalah flash attention.
00:48:02Jadi, dalam flash attention, masalah utamanya adalah,
00:48:09jadi saat ini, saat ini, bukan saat ini, tapi sekarang, hampir semua orang menggunakan flash attention, tapi jauh pada tahun 2022 atau 2023.
00:48:20Jadi, begitulah cara kerjanya.
00:48:23Cara kerjanya adalah, matriks Q, K, query, dan key ini berada di HBM.
00:48:34Matriks ini dimuat, pertama, dimuat ke dalam tensor core kita, lalu melakukan beberapa perhitungan, dan kemudian akan ditulis ulang kembali ke HBM.
00:48:47Dan kemudian, proses ini berlanjut beberapa kali.
00:48:51Jadi, dalam flash attention, yang mereka lakukan adalah, alih-alih mengalikan seluruh matriks,
00:48:59mereka membaginya, seperti algoritma World Cup, membagi matriks yang lebih besar menjadi tile kecil,
00:49:05dan hanya memasukkan tile kecil tersebut ke dalam SBM, sehingga dapat memproses perkalian dengan cepat,
00:49:13serta melacak beberapa variabel ini, sehingga mereka dapat menghitung softmax online ini.
00:49:20Jadi, ya, ini hanyalah matematika, jadi jika kita memiliki multi-head attention, jika itu untuk 524 kV,
00:49:34maka itu bergantung pada seberapa banyak pengelompokan yang kita inginkan, dan jadi, jika alih-alih 32 head kV, kita hanya ingin menggunakan 8 head kV,
00:49:47maka kita bisa mendapatkan kompresi 4x lipat, dan ini adalah multi-head latent attention.
00:49:54Rumus ini bergantung dari model ke model, berapa banyak layer yang dimiliki model Anda.
00:50:00Jadi, dalam makalah asli DeepSeek, saya rasa mereka memiliki dimensi sekitar 128, 128, saya tidak ingat dimensi persisnya, tetapi berdasarkan itu,
00:50:11mereka menggunakan satu vektor laten ini, di mana mereka menggunakan 512 sebagai dimensi, dan sekitar 64 untuk indeks rope,
00:50:23dan kemudian mereka menunjukkan bahwa kinerjanya 56x lebih terkompresi daripada multi-head attention.
00:50:32Oke.
00:50:33Ya, jadi ini adalah diagram trade-off, jadi di sini saya rasa kita belum membahas tentang linear attention atau Mamba.
00:50:50Jadi, masalah utama hanyalah semua perkalian matriks ini, saat ini hampir semua orang menggunakan attention.
00:50:56Seandainya di masa depan, jika kita tidak ingin menggunakan attention, alih-alih menghasilkan token secara berurutan, cukup gunakan mungkin model difusi,
00:51:07di mana kita dapat menghasilkan semuanya secara bersamaan, sehingga semua algoritma ini juga akan berubah.
00:51:14Tetapi di sini, saya rasa mereka memiliki dua lagi, satu adalah linear attention dan satu lagi adalah Mamba.
00:51:19Jadi, menurut slide ini, jika kita tidak mengompresi apa pun, MHA adalah saat kita memparalelkan prosesnya.
00:51:29Jadi, tidak ada kehilangan kualitas, jadi itu bagus, dan kemudian grouped query attention ini, yang saya rasa hampir semua model menggunakan semacam GQA dan DSA.
00:51:42Ya.
00:51:43Saya rasa hal yang sama kita sediakan dalam scorecard attention mechanism, jadi saya rasa untuk kualitas MHA ini bagus, throughput-nya lumayan.
00:51:56Dan untuk grouped query attention, itu juga bergantung pada kasus penggunaan Anda, meskipun kualitasnya hampir mirip dengan multi-head attention, kasus penggunaan juga sangat berpengaruh.
00:52:10Ya, multi-query attention hanyalah salah satu bentuk ekstrem.
00:52:13Kita, entah mengapa, berasumsi bahwa kita hanya butuh satu blok, dan semua query akan memperhatikan blok yang lebih kecil tersebut.
00:52:24Jadi, kualitas MQA tidak terlalu bagus.
00:52:29Dan multi-head latent attention ini, ya, jika Anda telah mencoba beberapa model DeepSeek ini, saya rasa mereka melakukan pekerjaan yang hebat dalam hal kualitas, di samping sliding window.
00:52:44Jadi, semua ini adalah beberapa teknik, seperti menyesuaikan window, dan alih-alih mengalikan semuanya, linear attention mengatakan untuk merangkum semuanya terlebih dahulu, lalu melihatnya, dan kemudian Mamba, ini hanyalah model state-space, ya.
00:53:09Jadi, untuk optimasi model, kita juga memiliki dua notebook di sini.
00:53:28Jadi, akan ada, saya harus membuka ini.
00:53:35Oke, jadi untuk kuantisasi seperti demonya, apakah ini sudah dijalankan? Belum.
00:53:51Biarkan saya jalankan ini.
00:53:54Oke, jadi kita memuat modelnya, yaitu Mistral 7B.
00:54:10Jadi, yang ini menggunakan baseline FP16.
00:54:20Tunggu.
00:54:21Apakah sudah berjalan?
00:54:21Tunggu.
00:54:22Apakah sudah berjalan?
00:54:23Oke.
00:54:24Jadi, butuh waktu dua milidetik, sudah berjalan.
00:54:27Apakah ini sudah berjalan?
00:54:28Oke.
00:54:29Jadi, ya, kali ini proses mengambil model tersebut dengan presisi FP16.
00:54:35Oke.
00:54:36Jadi, butuh waktu dua milidetik, sudah berjalan.
00:54:40Apakah ini sudah berjalan?
00:54:41Oke.
00:54:42Jadi, ya, kali ini proses mengambil model tersebut dengan presisi FP16.
00:54:47Wi-Fi-nya.
00:54:58Ini akan memakan waktu.
00:55:03Oke.
00:55:08Ya, karena ini mengunduh bobot model dari Hugging Face.
00:55:14Hah?
00:55:17Ya, jadi Colab berjalan secara online.
00:55:22Ya.
00:55:23Karena perlu melakukan panggilan jaringan melalui Hugging Face dan mengambil datanya.
00:55:30Entahlah, tapi proses unduhannya sepertinya memakan waktu.
00:55:35Oke.
00:55:36Oke.
00:55:37Oke.
00:55:38Oke.
00:55:39Oke.
00:55:40Jadi di sini kita lihat, ukuran memori sekitar 15 GB dengan presisi FP16.
00:56:00Kita sedang mencoba melakukan kompresi 2x lipat, seperti yang dibahas Talmud, menggunakan int 8.
00:56:15Oke.
00:56:16Jadi kita lihat, ukuran memori Anda sekarang menjadi sekitar 0,7, 0,5 GB.
00:56:21Artinya, sekarang Anda memiliki lebih banyak memori bagi KV Anda untuk berkembang.
00:56:27Artinya, Anda dapat menangani batas konteks yang lebih tinggi atau menangani pengguna konkuren yang lebih banyak.
00:56:36Jadi, jika Anda menggunakan int 4, Anda pada dasarnya melakukan kompresi 4x lipat.
00:56:41Sehingga dengan kompresi 4x, ukurannya akan jauh lebih kecil.
00:56:45Saya rasa ukurannya akan sekitar 3 hingga 4 GB.
00:56:50Ya, 4,5 GB.
00:56:51Dan, ya.
00:56:52Jadi ini, tunggu.
00:56:53Jadi ini hanyalah grafik dasar tentang, ini adalah angka-angka teoretis.
00:57:09Kita tidak melakukan pengujian throughput apa pun di sini.
00:57:12Tetapi biasanya, Anda akan melihat memori Anda meningkat.
00:57:15Jadi, Anda juga akan mendapatkan sedikit peningkatan throughput.
00:57:21Dari beberapa benchmark yang kami pelajari, kami melihat kompresi int 8.
00:57:26Memang menghasilkan throughput yang lebih rendah.
00:57:32Oke.
00:57:33Dan kemudian, ada demo tentang mekanisme attention.
00:57:42Jadi untuk attention, oke.
00:57:45Saya harus menjalankan ini.
00:57:58Oke.
00:57:59Jadi sudah berjalan.
00:58:02Oh.
00:58:03Tunggu.
00:58:04Kenapa keterangannya tidak ada GPU yang terdeteksi?
00:58:09Seharusnya tertulis GPU terdeteksi.
00:58:18Oh.
00:58:19Oke.
00:58:29Tunggu.
00:58:30Tunggu.
00:58:30Tunggu.
00:58:50Ini mengejutkan.
00:58:57Sepertinya sistem tidak dapat mendeteksi GPU karena suatu alasan.
00:59:05Kita punya GPU di sini.
00:59:11Oke.
00:59:12Lupakan saja.
00:59:14Ya.
00:59:14Tetapi gagasan dasarnya di sini lebih kepada, saat Anda mencoba beralih untuk mengompresi komputasi, seperti dengan menggunakan mekanisme attention yang berbeda
00:59:26seperti beralih dari multi-head ke grouped query attention lalu ke MLA.
00:59:33Anda akan mulai melihat beberapa optimasi.
00:59:38Saya rasa kemarin malam kami melakukan beberapa benchmarking.
00:59:43Saya ingin mengoreksi bagian ini.
00:59:45Jadi, itu bukanlah 56x.
00:59:48Melainkan 14x.
00:59:50Pada dasarnya demo tersebut memiliki kesalahan penghitungan di mana mereka tidak mengalikannya dengan jumlah layer.
01:00:02Ya.
01:00:03Jadi, mohon maaf atas hal tersebut.
01:00:04Jadi, MLA ini memberikan penghematan sekitar 14x jika dibandingkan dengan multi-head attention.
01:00:15Jadi, sekarang setelah kita memahami titik permasalahan, fondasi, serta salah satu sisi optimasi yaitu optimasi model, kita ingin membahas apa yang dapat Anda lakukan dari sisi serving.
01:00:31Hal pertama yang kita lihat adalah ketika Anda melakukan langkah decode sederhana, Anda menarik bobot model lalu menghitung ulang vektor key dan value untuk semua token sebelumnya.
01:00:50Meskipun Anda telah menghitung vektor-vektor tersebut untuk semua token.
01:00:55Jadi, jelas ada banyak pemborosan komputasi.
01:01:02Dan jika Anda menganalisis kompleksitas waktu dari hal tersebut, hasilnya adalah O dari N kuadrat.
01:01:07Dan cara untuk mengatasinya adalah melalui trade-off klasik terhadap memori.
01:01:12Anda dapat memelihara memori dari vektor-vektor tersebut untuk setiap token dan merujuk memori itu.
01:01:19Jadi, memori tersebut disebut sebagai KVCache.
01:01:24Dan alurnya terlihat seperti ini.
01:01:27Dan berdasarkan KVCache ini, ada empat optimasi yang sangat dimungkinkan.
01:01:35Yang pertama adalah tentang paged attention.
01:01:42Jadi, apa perbedaannya, apa masalahnya saat ini?
01:01:45Jadi, ketika Anda mengirimkan beberapa permintaan sebagai input ke GPU, permintaan-permintaan ini berada dalam satu batch.
01:01:52Setiap permintaan dialokasikan penyimpanan memori yang kontinu.
01:01:58Katakanlah, saya ambil contoh, misalnya sebesar 2 KV.
01:02:05Namun, permintaan Anda sebenarnya hanya membutuhkan, katakanlah, 1 KV.
01:02:11Jadi, ada sekitar 50% fragmentasi memori.
01:02:19Dan fragmentasi ini pada dasarnya menyebabkan pemborosan memori.
01:02:24Artinya, ada ruang di memori yang bisa Anda gunakan untuk melayani lebih banyak permintaan, tetapi Anda tidak bisa melakukannya karena Anda mencari blok memori yang kontinu.
01:02:36Jadi, inspirasinya diambil dari cara kerja sistem operasi (OS).
01:02:41Seperti, Anda mengelola memori logis dan pada dasarnya Anda memiliki memori fisik.
01:02:47Jadi, dalam memori logis, rasanya tetap akan sama, yaitu vektor KV untuk setiap token bersifat kontinu.
01:02:59Tetapi itu akan dipetakan ke alamat fisik yang berbeda.
01:03:06Jadi, itu sangat membantu menghemat banyak memori.
01:03:11Dan itu hanya dimungkinkan karena mereka menganggap memori sebagai sekumpulan blok.
01:03:18Dan Anda akan mengalokasikan blok-blok tersebut secara dinamis sesuai kebutuhan permintaan.
01:03:22Seiring dengan datangnya token-token baru yang membutuhkan memori tersebut.
01:03:27Faktor pendorong lainnya adalah, ketika Anda mengirimkan beberapa permintaan dalam satu batch,
01:03:39GPU memproses permintaan-permintaan tersebut.
01:03:42Tetapi GPU tidak menerima batch baru sampai semua permintaan dalam batch tersebut selesai.
01:03:49Jadi, diagramnya tampak mirip dengan paged attention.
01:03:52Namun di sini lebih berkaitan dengan kapan GPU tersedia untuk mengambil batch berikutnya.
01:03:59Jadi, ada jangka waktu di mana GPU benar-benar menganggur.
01:04:04Dan Anda ingin mengatasi masalah tersebut.
01:04:08Untuk itu, gagasannya adalah, mari kita lakukan continuous batching.
01:04:17Jadi, continuous batching ini juga sangat membantu meningkatkan throughput karena sekarang Anda dapat mengirimkan lebih banyak permintaan dengan cukup cepat.
01:04:24Pastikan bahwa GPU selalu sibuk dan tidak dibiarkan menganggur.
01:04:33Dengan begitu, Anda menghemat daya komputasi tersebut.
01:04:36Yang ketiga adalah prefix caching.
01:04:39Jadi, Anda ingat bahwa KV cache membantu Anda menghemat komputasi untuk satu permintaan di berbagai token.
01:04:46Tapi bagaimana jika Anda memiliki token yang sama di beberapa permintaan?
01:04:53Bagaimana cara Anda mengoptimalkannya?
01:04:55Jadi, prefix caching, yang diperkenalkan oleh vLLM, mengatasi masalah persis seperti itu.
01:05:04Dan kemudian yang ketiga adalah, kita membahas yang keempat sebenarnya.
01:05:10Jadi, kita sudah membahas kuantisasi model, tetapi Anda juga bisa menguantisasi bobot KV.
01:05:21Artinya, sekarang Anda membutuhkan lebih sedikit ruang untuk vektor kunci (key) dan nilai (value) Anda.
01:05:28Itu berarti Anda dapat memuat lebih banyak vektor kunci dan nilai di dalam memori.
01:05:32Dan itu berarti Anda dapat memproses lebih banyak token.
01:05:34Artinya, Anda dapat melayani batas konteks yang lebih besar.
01:05:37Dan itu berarti Anda dapat mempertahankan kualitas model yang lebih tinggi.
01:05:41Dan semua ini sudah tersedia di dalam vLLM.
01:05:51Anda tidak perlu benar-benar menciptakan kembali roda dari awal.
01:05:56Dan Anda dapat menerapkan vLLM ini ke produksi dan melihat pertumbuhan kinerjanya.
01:06:03Jadi, berikutnya kita memiliki tolok ukur (benchmark) yang telah kami lakukan.
01:06:08Jadi, tolok ukur ini—biar saya lihat apakah saya memilikinya.
01:06:14Di sini.
01:06:17Demonstrasinya.
01:06:22Jadi, menjalankan tolok ukur ini memakan waktu sekitar satu jam karena Anda harus terus-menerus menghentikan dan memulai ulang server vLLM serta memuat model dan sebagainya.
01:06:35Jadi, memang butuh banyak waktu untuk pengujian, tetapi saya bisa jelaskan kepada Anda apa yang sedang kami lakukan di sini.
01:06:41Jadi, kami mempertahankan model yang sama, yaitu Mistral 7B.
01:06:46Dan kemudian kami memiliki sekumpulan pertanyaan masukan yang kami kirimkan.
01:06:53Anggap saja itu sebagai prompt.
01:06:56Lalu ada beberapa fungsi pembantu (helper functions) di sini, seperti memeriksa apakah server aktif atau tidak.
01:07:01Server ini adalah server vLLM.
01:07:04Kemudian, ada fungsi pembantu untuk mendapatkan metrik vLLM.
01:07:09Dan saya akan membahas apa saja metrik tersebut.
01:07:14Lalu, ada banyak sekali tolok ukur dan hal lainnya.
01:07:17Dan kemudian Anda harus mengukur penggunaan KV dan sebagainya.
01:07:22Jadi, ini adalah fungsi-fungsi pembantunya.
01:07:24Jadi, baseline-nya sangat sederhana.
01:07:26Yaitu, kita menggunakan baseline Hugging Face.
01:07:29Ini adalah pengiriman teks mentah ke LLM, lalu mendapatkan respons kembali.
01:07:36Kita melihat beberapa hasil di sini.
01:07:38Kita melihat throughput Hugging Face sekitar 51 token per detik.
01:07:44Waktu ke token pertama (TTFT) adalah 54.
01:07:46Dan latensi antar-token adalah 19.
01:07:49Semua ini dijalankan pada GPU H100.
01:07:56Dan kemudian, kami menjalankan server vLLM dengan pengaturan default.
01:08:00Secara default, vLLM menyediakan paged attention, continuous batching, dan KV caching.
01:08:08Jadi, ketiga hal tersebut sudah ada secara default.
01:08:13Dan ketika Anda mencoba membandingkan tolok ukur tersebut, Anda melihat throughput Anda meningkat hampir 15 kali lipat.
01:08:21Anda mampu melayani lebih banyak token per detik.
01:08:24Kemudian, waktu ke token pertama Anda juga meningkat.
01:08:34Lalu, latensi antar-token mengalami penurunan.
01:08:38Dan penggunaan cache KV terhadap pengguna serta terhadap konteks tentu saja meningkat.
01:08:43Sekarang, ketika Anda menerapkan prefix caching ke dalamnya.
01:08:51Dengan prefix caching, Anda dapat melihat bahwa throughput Anda semakin meningkat.
01:08:57TTFT Anda menurun.
01:08:59Latensi antar-token Anda kurang lebih sama.
01:09:02Dan penggunaan KV cache terhadap pengguna cenderung menurun.
01:09:09Sedangkan terhadap konteks, angkanya tidak turun.
01:09:12Kurang lebih sama.
01:09:14Menurut saya ini juga kurang lebih sama.
01:09:16Tidak terlalu menjadi masalah besar.
01:09:19Ketika Anda menerapkan kuantisasi KV di atasnya.
01:09:25Jadi, Anda bisa melihat bahwa throughput-nya hampir mirip.
01:09:33Waktu ke token pertama Anda mirip.
01:09:36Latensi token Anda mirip.
01:09:39Tetapi penggunaan KV Anda benar-benar menurun.
01:09:42Ini karena Anda telah menguantisasi ruang key-value Anda.
01:09:49Dan kemudian ada konsep speculative decoding yang akan dibahas oleh Tanmay.
01:09:54Jadi, ketika Anda mencoba menguji metrik tersebut, Anda juga melihat penggunaan KV yang sedikit lebih rendah di sana.
01:10:06Meskipun hasilnya kurang lebih sama.
01:10:08Jadi, ya, secara keseluruhan, ini adalah metrik-metrik perbandingannya.
01:10:21Sepertinya saya harus memperkecil tampilan.
01:10:25Baiklah.
01:10:26Tidak bisa.
01:10:27Perkecil.
01:10:28Tidak berfungsi.
01:10:29Baguslah.
01:10:30Jadi, ya, inilah tolok ukur vLLM.
01:10:35Ngomong-ngomong, ini adalah pengaturan default untuk produksi.
01:10:38Kami juga akan membagikan pohon keputusan tersebut ketika kita membahas mesin-mesin lainnya.
01:10:48Jadi, kita harus membahas apa saja optimasi inferensi lain yang dapat kita lakukan di atasnya.
01:10:58Dan apa saja solusi lain yang telah bermunculan.
01:11:02Jadi, saya ingin mengundang kembali Tanmay.
01:11:07Ia akan membahas beberapa optimasi ini.
01:11:11Oh, maaf.
01:11:12Saya sangat menyesal.
01:11:13Saya belum mengaktifkan salindia-nya.
01:11:26Apa tadi?
01:11:27Baiklah.
01:11:28Bagus.
01:11:29Sempurna.
01:11:30Yang mana?
01:11:31Speculative decoding.
01:11:32Ya.
01:11:33Terima kasih, Harshal.
01:11:34Ya.
01:11:35Jadi, semua ini adalah speculative decoding.
01:11:40Semua ini adalah, bisa kita bilang, varian rasa yang berbeda dari jenis soda yang sama.
01:11:46Teknik ini termasuk dalam akselerator dekoding.
01:11:51Jadi, yang pertama—kita hanya membahas speculative decoding ini, tetapi ada varian lain seperti self-speculative, Eagle, Medusa.
01:12:01Saya rasa saya hanya menyukai yang ini, algoritma Eagle.
01:12:05Jadi, mari kita mulai dengan speculative decoding.
01:12:06Baiklah.
01:12:07Baik.
01:12:08Jadi, mari kita mulai dengan apa itu speculative decoding.
01:12:09Masalah utamanya adalah dalam arsitektur transformer, semua token ini dihasilkan secara berurutan, satu demi satu.
01:12:26Bagaimana jika kita menggunakan model yang lebih kecil dan membiarkan model yang lebih kecil tersebut menghasilkan, katakanlah, empat atau lima token?
01:12:37Dan model guru ini, atau bisa kita bilang, sesuai algoritma Piala Dunia kita, bisa disebut wasit.
01:12:43Jadi wasit akan memutuskan berapa banyak token yang akan diterima.
01:12:48Dan perulangan ini terus berlanjut.
01:12:51Dan asumsi kita adalah ada domain tertentu di mana hal semacam ini akan berhasil.
01:12:59Seperti mungkin dalam pemrograman, di mana hampir tidak ada kreativitas.
01:13:05Setiap kode atau sintaksisnya hampir serupa.
01:13:08Jadi, mungkin hal itu bisa membantu.
01:13:10Tapi, berdasarkan pengujian pribadi saya, saya sama sekali tidak merasa decoding spekulatif ini berguna.
01:13:18Tapi, teknik lain seperti self-speculative decoding, di mana model guru juga memiliki satu kepala, kepala tambahan, dan itu akan melakukan hal serupa tentang apa yang dilakukan model dasar atau model kecil ini.
01:13:35Tapi, kemudian EGLE ini muncul, EGLE 1, 2, 3, saya tidak tahu sudah ada berapa versinya, tapi intinya alih-alih membuat, alih-alih menghasilkan token, ayo latih model kecil dan ambil fitur dari salah satu lapisan model utama, sehingga alih-alih menghasilkan token, model ini akan menghasilkan fitur tersebut.
01:14:02Jadi, EGLE lebih baik dibandingkan dengan jenis teknologi lainnya ini.
01:14:10Lalu yang lainnya adalah MEDUSA, yang intinya mengatakan bahwa, hasilkan saja semua token ini secara paralel.
01:14:17Oke, jadi di sini, jadi di slide ini.
01:14:21Ya.
01:14:22Slide berikutnya.
01:14:24Oke.
01:14:25Oke.
01:14:26Oke, ya.
01:14:27Oke.
01:14:28Sekarang kita beralih ke, sekarang kita akan membahas mengenai prefix caching ini.
01:14:34Jadi, saya tidak tahu apakah orang-orang menggunakan static prefix caching ini atau tidak.
01:14:39Tapi masalah utamanya dengan prefix caching adalah, terkadang kita mengetik dan membuat semacam kesalahan kecil.
01:14:47Dan static prefix caching standar ini pada dasarnya mengambil sebuah prompt, lalu melakukan hashing.
01:14:53Dan dilanjutkan saat pengguna menanyakan pertanyaan serupa, ia akan mencoba mencocokkan hash tersebut.
01:14:58Jadi, jika hash-nya sama, maka alih-alih menghitung ulang semua k dan v itu, ia akan mengambilnya langsung dari penyimpanan.
01:15:09Tapi, Anda tahu bahwa terkadang kita membuat kesalahan atau mungkin kita hanya mengubah satu kata atau huruf, dan semacamnya.
01:15:15Maka kita akan mendapatkan tingkat cache miss yang sangat tinggi.
01:15:21Maka dari itu, ada yang namanya Radix tree.
01:15:25Jadi, Radix tree semakin sangat populer dan juga karena adanya agen.
01:15:30Jadi, saya pikir hampir semua orang menggunakan agen dan sebagian besar komputasi terjadi pada saat test time atau inferensi.
01:15:38Di mana kita terus-menerus menanyakan jenis pertanyaan dan prompt yang sama.
01:15:42Sebagai contoh, Anda adalah seorang insinyur perangkat lunak ahli dikalikan 200 kali.
01:15:48Perulangan semacam ini terus berlanjut di dalam hal-hal yang bersifat agentic.
01:15:55Di mana hal tersebut diperlukan untuk menyimpan hal-hal serupa di dalam Radix tree.
01:16:03Jadi, Radix tree hanyalah versi lanjutan dari prefix tree di mana kita akan menggabungkan sebuah node jika ia tidak memiliki cabang.
01:16:17Dan untuk pekerjaan semacam ini di mana kita terus mengulang hal yang sama.
01:16:24Radix tree ini sangat membantu dan sglang menggunakan algoritma semacam ini untuk prefix caching.
01:16:35Oke, ya, lalu ada hal lain.
01:16:38Yaitu TensorRT-LLM.
01:16:41Ini sangat membingungkan.
01:16:42Saat pertama kali memulainya, saya sempat kebingungan.
01:16:46Sebenarnya apa itu TensorRT-LLM?
01:16:49Jadi, ya, TensorRT hanyalah semacam SDK standar.
01:16:55TensorRT-LLM adalah mesin inferensi.
01:16:59Sama seperti vLLM dan sglang.
01:17:01Namun masalahnya adalah ini berkaitan dengan NVIDIA.
01:17:05Mereka mengoptimalkan setiap lapisan dan setiap permasalahan.
01:17:10Seperti yang saya sebutkan dalam algoritma Piala Dunia kami, mereka memecah semuanya dan mengoptimalkan semuanya hingga tingkat perangkat keras.
01:17:18Jadi, ya, oke, berikutnya.
01:17:23Ya, jadi untuk lokakarya ini, kami juga melakukan beberapa pembandingan, seperti mana yang terbaik.
01:17:33Jadi, pengaturan kami kurang lebih seperti ini.
01:17:36Jadi, kami melakukan dua jenis pengujian.
01:17:39Yang pertama adalah tanpa pengujian agentic, di mana kami hanya...
01:17:44Jadi, kami menggunakan dataset ShareGPT ini dan menanyakan pertanyaan-pertanyaan tersebut menggunakan vLLM dan sglang.
01:17:57Oke.
01:18:05Ya, oke.
01:18:07Dan izinkan saya memperbesarnya.
01:18:12Oke, bagus.
01:18:13Oke, ya, jadi untuk lokakarya ini, kami menggunakan H100, dan pengujian pertama kami adalah kami menanyakan...
01:18:23Kami mengambil pertanyaan dari ShareGPT dan memasukkannya ke vLLM dan sglang, dan kami menemukan bahwa sebenarnya tidak ada perbedaan statistik tentang mana yang lebih baik.
01:18:34Jadi, keduanya memiliki...
01:18:37Jadi, keduanya memenuhi jenis permintaan per detik, TTFT, dan latensi yang hampir serupa.
01:18:43Namun satu-satunya perbedaan yang kami lihat adalah selama pencabangan agentic.
01:18:50Jadi, yang kami lakukan adalah kami mengajukan pertanyaan serupa bahwa Anda adalah insinyur perangkat lunak terbaik di dunia.
01:18:59Maka selesaikanlah masalah kemacetan lalu lintas di kota.
01:19:04Kemudian, kami memasukkannya ke dalam LLM.
01:19:08LLM menghasilkan beberapa keluaran.
01:19:10Lalu kami melakukan putaran kedua juga.
01:19:13Jadi, begitu LLM menghasilkan keluaran ini, maka pada putaran kedua, kami secara khusus menyebutkan bahwa...
01:19:22berikan ulasan terhadap proposal tersebut dan berikan penilaian dari satu sampai sepuluh.
01:19:28Jadi, ini adalah dua giliran yang kami lakukan, dan perulangan ini terus berlanjut.
01:19:35Apa yang kami temukan adalah untuk alur kerja semacam ini di mana semuanya standar, semua prompt dan rekayasa konteks mulai berperan.
01:19:47Jadi, jika kita melakukan pencabangan agentic ini dengan benar, maka saya pikir SGLang ini tiga hingga empat kali lebih baik.
01:19:54Tapi sekali lagi, ini mungkin bergantung pada pengaturan yang berbeda.
01:19:58Jika Anda melakukannya, Anda mungkin mendapatkan hasil yang berbeda.
01:20:02Oke.
01:20:03Ya.
01:20:04Jadi, saya rasa...
01:20:06Apakah kita mengunggahnya ke GitHub?
01:20:08Ya.
01:20:09Oke.
01:20:10Ya.
01:20:11Jadi, PDF-nya juga ada di Drive.
01:20:15Tautan yang sama dengan slide.
01:20:18Jadi, ringkasan singkat di sini.
01:20:22Jadi, pada throughput beban kerja API standar, Anda akan melihat vLLM dan SGLang akan bernasib sama.
01:20:31Jadi, jika Anda tidak memiliki...
01:20:33Jika Anda memiliki beban kerja standar, pastinya gunakan vLLM.
01:20:36Bagaimanapun, itu adalah bawaan untuk produksi.
01:20:38Tapi apa yang juga dikatakan Tanmay adalah ketika Anda mencoba menjadikannya sebagai beban kerja agentic, di situlah SGLang Anda benar-benar bersinar.
01:20:50Dan ia semacam memberikan semua manfaatnya kepada Anda.
01:20:55Jadi, ya.
01:20:58Pertahankan vLLM sebagai bawaan.
01:21:00Tapi jika Anda memiliki beban kerja agentic, cobalah beralih ke SGLang.
01:21:05Jika Anda tidak puas dengan bagian vLLM.
01:21:09Oke.
01:21:10Biarkan saya...
01:21:15Tunggu.
01:21:18Oke.
01:21:21Dan kemudian ada seperti...
01:21:29Seperti perbandingan yang dilakukan pada 120 miliar.
01:21:33Seperti untuk GPT OSS 120 miliar.
01:21:36Ini adalah tolok ukur yang disiapkan oleh PlayPy.
01:21:42Jadi, ada tautan blog di sini.
01:21:46Oh, bagus.
01:21:48Oke.
01:21:49Ya.
01:21:50Jadi, mereka melakukan tolok ukur serupa dan mereka menyertakan TensorRT-LLM di dalamnya.
01:21:57Tentu saja, Anda selalu dapat membaca tolok ukur ini dan mencoba memahami mana yang pada dasarnya sesuai dengan kasus penggunaan Anda.
01:22:05Seperti yang kami sebutkan mengenai TensorRT, mereka mencoba mengoptimalkan sisi perangkat keras juga, untuk mendapatkan kinerja perangkat keras puncak.
01:22:16Dan kemudian dalam hal ketika Anda ingin memilih mesin Anda, setelah Anda menentukan pilihan antara vLLM, SGLang, TensorRT, ada beberapa mesin baru yang bermunculan.
01:22:29NVIDIA Dynamo tentu saja.
01:22:43Jadi, mereka juga untuk perutean sesi agentic.
01:22:49Hugging Face selalu ada.
01:22:51Itu adalah hal yang lumrah.
01:22:53Lalu ada mesin MSTAR yang baru-baru ini diusulkan oleh Stanford.
01:23:00NVIDIA Dynamo untuk multi-model.
01:23:05Jadi, Anda tentu bisa menjelajahi hal-hal tersebut.
01:23:08Dan ketika Anda mencoba, hanya untuk memberikan ringkasan singkat, kita mulai dengan sebuah dasar.
01:23:15Kita mencoba mencari model apa yang dapat sesuai dengan kasus penggunaan kita.
01:23:22Jadi, Anda bisa memilih seperti DeepSeek.
01:23:27Anda bisa memilih seperti, jangan memilih Mistral 7B.
01:23:30Maksud saya, itu kurang bagus.
01:23:32Tapi, ya.
01:23:35Jadi, Anda memilih model Anda dan Anda ingin memiliki memori yang lebih kecil dan mencoba memuat model yang lebih besar itu ke dalam memori yang lebih kecil.
01:23:44Sehingga Anda dapat menghemat biaya GPU.
01:23:47Jadi, Anda dapat melakukan semua kuantisasi tersebut.
01:23:51Kemudian Anda dapat menerapkan semua pengoptimalan penyajian tersebut dengan menggunakan mesin penyajian yang tepat di balik layar.
01:23:58Sehingga hal itu benar-benar dapat memberikan throughput yang sangat Anda inginkan.
01:24:07Dan sekarang, sesuatu yang dapat Anda lakukan setelah pulang ke rumah karena kita tidak bisa membahas semua materi di sini adalah membaca tentang beberapa informasi sumber seperti berbagai mekanisme perhatian, berbagai mesin ini.
01:24:27Coba baca berbagai tolok ukur yang ada secara daring juga.
01:24:34Dan kemudian, ada banyak panduan mendalam atau fase berikutnya, yaitu mempelajari beberapa strategi penggusuran KV.
01:24:45Jadi, dunia sedang bergerak menuju domain rekayasa cache KV yang terpisah.
01:24:50Jadi, Anda ingin memahami apa yang sedang terjadi di sana.
01:24:52Jadi, penggusuran KV, kompresi cache, memori hibrida.
01:24:57Jadi, ada banyak solusi yang bermunculan di sekitar sana.
01:25:01Jadi, selalu cobalah untuk berpegang pada fondasi tersebut atau dasar-dasarnya atau prinsip-prinsip utamanya.
01:25:08Dan cobalah untuk melihat solusi mana yang pada dasarnya memecahkan masalah apa dan apakah Anda benar-benar perlu masalah tersebut dipecahkan untuk kasus penggunaan Anda.
01:25:17Dan kemudian, ada inferensi LLM terdistribusi yang merupakan topik yang sepenuhnya berbeda.
01:25:26Anda mungkin memerlukan lokakarya dua jam di sana juga untuk membahas semua bagian internalnya, melakukan semua praktik langsung.
01:25:40Ya, dan ini adalah sesuatu yang coba kami usulkan untuk sesi AI Engineer New York, yaitu untuk mendalami bagian lanjutan dari inferensi LLM.
01:25:51Jadi, lokakarya ini lebih diperuntukkan bagi tingkat pemula dan menengah.
01:25:55Jadi, dalam formulir ini kami menyediakan masukan serta ketertarikan.
01:26:02Jika menurut Anda kami perlu melakukan perbaikan tertentu pada bagian tertentu, silakan berikan masukan tersebut.
01:26:09Dan jika Anda ingin melihat lokakarya ini di New York Fair, silakan daftarkan ketertarikan Anda.
01:26:22Hah?
01:26:24Oh, bagaimana bisa?
01:26:27Boom.
01:26:32Coba saya cek dulu.
01:26:37Baiklah.
01:26:38Hah?
01:26:39Ya.
01:26:40URL-nya berfungsi, kan?
01:26:41Ya.
01:26:42Bukan kode QR-nya?
01:26:43Baiklah.
01:26:44Sepertinya saya lupa menautkan keduanya.
01:26:45Baiklah.
01:26:46Keren.
01:26:46Ya.
01:26:47Jadi, jika Anda bisa memberikannya.
01:26:49Baiklah.
01:26:50Keren.
01:26:51Ya.
01:26:52Jadi, jika Anda bisa memberikannya.
01:26:53Baiklah.
01:26:54Ya.
01:26:55Baiklah.
01:26:56Keren.
01:26:57Ya.
01:26:58Jadi, jika Anda bisa memberikannya.
01:26:59Biar saya...
01:27:00Baiklah.
01:27:00Baiklah.
01:27:01Keren.
01:27:02Ya.
01:27:02Jadi, jika Anda bisa memberikannya.
01:27:03Biar saya...
01:27:04Baiklah.
01:27:05Itu sudah bagus.
01:27:06Um, dan ya, saya rasa kita ingin mengakhiri lokakarya ini.
01:27:13Dan saya yakin banyak dari kalian yang memiliki banyak pertanyaan.
01:27:14Jadi, kita bisa membahasnya secara luring.
01:27:15Uh, kita bisa bertemu, eh, dan kita bisa membicarakan pertanyaan-pertanyaan itu.
01:27:16Ya.
01:27:17Tentu.
01:27:18Tentu.
01:27:19Uh, terima kasih semuanya.
01:27:20Terima kasih sudah bergabung.
01:27:21Uh, saya rasa ini sungguh...
01:27:22Uh, terima kasih semuanya.
01:27:23Uh, terima kasih semuanya.
01:27:24Terima kasih sudah bergabung.
01:27:25Uh, terima kasih semuanya.
01:27:26Terima kasih sudah bergabung.
01:27:27Uh, saya rasa ini sungguh...
01:27:28Oh, baiklah.
01:27:29Uh, baiklah.
01:27:30Itu sudah bagus.
01:27:31Uh, dan ya, saya rasa kita ingin mengakhiri lokakarya ini.
01:27:33Uh, dan ya, saya rasa kita ingin mengakhiri lokakarya ini.
01:27:36Dan saya yakin banyak dari kalian yang memiliki banyak pertanyaan.
01:27:39Jadi, kita bisa membahasnya secara luring.
01:27:41Uh, kita bisa bertemu, eh, dan kita bisa, eh, membicarakan pertanyaan-pertanyaan itu.
01:27:42Ya, tentu.
01:27:43Uh, terima kasih semuanya.
01:27:44Uh, saya rasa ini sangat bermakna dan kalian semua datang ke sini.
01:27:49Uh, terima kasih banyak.
01:27:50Ya, terima kasih.

설명

A single token of KV cache on Mistral 7B costs 131 KB. Multiply that by 16,000 tokens of context and 80 concurrent users and the cache alone wants 42 GB of GPU memory, which is why requests start failing on a 24 GB card. Harshul Jain, a senior software engineer at Audible, and Tanmay Sah, an independent AI researcher, spend this workshop building that number up from first principles. They open on three symptoms every team hits: memory that climbs with context length, time to first token that degrades as prompts grow, and throughput that collapses because a naive server answers requests one after another. The rest of the session explains what causes each one, working down through the inference pipeline into the attention layer, then into how a GPU actually splits its memory between fixed model weights and the cache that has to grow. From there the workshop splits optimization in two. Sah takes the model side, using two deliberately silly teaching devices, the ostrich algorithm for assumptions you wave through and the world cup algorithm for problems you cut into brackets, to move from quantization through multi head, multi query, grouped query, and latent attention, then flash attention and tiling. Jain takes the serving side: paged attention borrowed from operating system paging, continuous batching, prefix caching, and KV quantization, each benchmarked against a plain baseline. They close on engine selection, where their own testing found no statistical difference between vLLM and SGLang on standard workloads but a three to four times gap once agentic branching enters the picture. Slides and runnable notebooks are linked in the repo. Speaker info: - https://x.com/hj1393 - https://www.linkedin.com/in/hjain1393/ - https://harshuljain.substack.com/ - https://www.linkedin.com/in/tanmay-sah/ Timestamps: 0:00 - Introductions and what the workshop covers 2:43 - What LLM inference is, and why it costs so much 5:21 - The repo, the slides, and the free GPU notebooks 8:23 - Three pain points, memory, first token, throughput 12:18 - Foundations, the pipeline and the attention layer 14:53 - KV cache math and how GPU memory divides 20:41 - Prefill and decode, and why decode is memory bound 28:41 - Throughput, concurrency, and the trade off triangle 34:02 - The capacity calculator and picking a GPU 37:10 - Model optimization, quantization and attention variants 48:04 - Flash attention, the scorecard, and a demo 1:00:14 - Serving optimizations, paging, batching, caching 1:06:12 - Benchmarking vLLM, and speculative decoding 1:17:27 - vLLM against SGLang, choosing an engine, what to study next

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기