Klaster Besar untuk Model Kecil — Daniel Svonava, Superlinked
AAI Engineer
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00Peninjau: Denise RQ
00:00:12Baiklah.
00:00:14Kurasa kalian bisa mendengarku.
00:00:15Aku sendiri tentu bisa mendengar suaraku.
00:00:19Siapa pun yang duduk lebih dekat bakal dapat kaus.
00:00:21Aku serius.
00:00:22Ada satu tas penuh berisi kaus di sebelah sini.
00:00:25Dan juga untuk pertanyaan.
00:00:26Mungkin akan ada beberapa pertanyaan di akhir.
00:00:28Jika bertanya, Anda juga bakal mendapatkan kaus.
00:00:31Dan jika bisa menebak apa gambar latar slide ini,
00:00:35Anda juga bakal dapat kaus.
00:00:39Ada yang mau menebak?
00:00:42Apa yang divisualisasikan di situ?
00:00:44Gambar di latar belakang ini.
00:00:49Tidak ada?
00:00:50Ada yang pernah melihat model transformer?
00:00:55Ya, pengodean posisi (positional encoding).
00:00:57Bagus sekali.
00:00:58Anda dapat kausnya, Pak.
00:00:59Baiklah.
00:01:00Jadi hari ini kita pada dasarnya bakal membahas model open source berukuran kecil, seberapa bagus Performanya sekarang, dan bagaimana mereka menciptakan tantangan unik saat Anda ingin menyajikannya dalam jumlah banyak di cloud milik Anda sendiri.
00:01:15Semua yang bakal kita bahas pada dasarnya bersifat open source.
00:01:19Buat sendiri (DIY).
00:01:20Ini jenis hal yang bisa Anda, tahu lah, jalankan dengan satu perintah dan kuasai seluruh stack-nya.
00:01:26Jadi tidak ada bagian teka-teki yang bersifat proprietary di sini.
00:01:31Mari kita mulai.
00:01:33Oke.
00:01:34Oke.
00:01:35Ini berfungsi.
00:01:36Oke.
00:01:37Jadi, model-model kecil.
00:01:38Apa yang dimaksud dengan model kecil?
00:01:40Tergantung siapa yang Anda tanyakan, tetapi menurut pandanganku, ini pada dasarnya adalah model yang dapat dijalankan pada perangkat keras NVIDIA generasi dua atau tiga tahun lalu.
00:01:49Masing-masing model muat dalam satu GPU, sehingga mudah untuk disajikan.
00:01:56GPU tersebut mudah didapat dan harganya juga terjangkau.
00:02:01Kebanyakan orang berpikir, oke, model kecil pasti ada kompromi dalam hal kualitas hasil.
00:02:10Semoga lewat presentasi ini aku berhasil meyakinkan Anda bahwa untuk tugas-tugas spesifik, Performanya bisa menyamai atau bahkan melampaui model terdepan (frontier), dan Anda tetap mendapat manfaat nyata lainnya.
00:02:22Tentu saja, penghematan biaya berkali-kali lipat dan potensi peningkatan latensi atau throughput yang sangat besar.
00:02:35Jadi ini salah satu grafik yang suka kami tampilkan.
00:02:38Ini adalah indeks kecerdasan Artificial Analysis dari waktu ke waktu.
00:02:42Dan yang biasanya tidak mereka perlihatkan adalah bahwa ada rincian model open source yang perlu dipertimbangkan.
00:02:49Ada GLM 5.2 dan sejenisnya, jenis model open source terdepan dengan katakanlah 750 miliar parameter.
00:02:57Namun ada juga model open source kecil yang membuntuti model besar dan model terdepan tersebut.
00:03:04Bisa dilihat bahwa model terdepan saat ini mulai mengalami penurunan hasil marginal (diminishing returns), sementara model-model kecil mulai mengejar.
00:03:10Jadi Anda melihat adanya konvergensi, kejenuhan di tingkat atas, dan pertumbuhan pada model-model kecil.
00:03:16Katakanlah QN 3627B punya Performa yang kurang lebih setara dengan GPT 5.1.
00:03:23Jadi jika Anda memiliki alur kerja atau pipeline yang bisa berjalan dengan GPT 5.1,
00:03:29sekarang Anda bisa memindahkannya ke model kecil dan mendapatkan semua manfaat yang telah kita bahas.
00:03:35Jadi model kecil tidak bisa dipandang sebelah mata lagi.
00:03:38Nah, ini juga tentang bagaimana Anda menggunakan model-model kecil tersebut.
00:03:44Jadi Anda tidak bisa memperlakukan QN 36 berparameter 27 miliar itu sebagai model umum serbaguna yang bisa diberi prompt untuk tugas apa saja.
00:03:53Tidak, Anda perlu menerapkan pendekatan di mana Anda memilah bagian-bagian tugas dari beban kerja model umum tersebut.
00:04:00Kemudian untuk setiap tugas, Anda tentukan model open source mana yang paling cocok.
00:04:05Anda jalankan beberapa evaluasi, dan mungkin melakukan penyesuaian yang akan kita bahas nanti.
00:04:08Dengan begitu, Anda bisa mencapai kualitas yang tepat untuk benar-benar menerapkannya ke tingkat produksi.
00:04:15Berikut adalah contoh agen peninjau kontrak yang menggunakan sembilan model berbeda.
00:04:20Bentuk seperti inilah yang akan Anda lihat pada beban kerja dan agen Anda saat beralih menggunakan model-model kecil untuk sistem Anda.
00:04:28Anda akan mulai melihat bahwa, Alih-alih membombardir satu API atau satu model dengan banyak permintaan berbeda,
00:04:36Anda akan lebih memilih memakai serangkaian model.
00:04:38Lalu masalahnya adalah, bagaimana cara menyajikan semua model berbeda ini tanpa membuat tim infrastruktur kewalahan?
00:04:45Dan ini barulah salah satu agen yang mungkin Anda jalankan.
00:04:48Mungkin ada 10 agen seperti ini di perusahaan Anda.
00:04:51Jadi bagaimana cara kita menangani perluasan cakupan infrastruktur seperti ini?
00:04:57Untuk semua tugas berbeda yang aku sebutkan tadi, sudah ada model open source yang siap digunakan.
00:05:05Mulai dari OCR, tanya jawab dokumen, pelabelan gambar, pembuatan SQL, hingga peninjauan kode.
00:05:14Tersedia model-model open source yang sudah di-fine-tune dan dilatih khusus untuk tugas-tugas tersebut.
00:05:19Jika menggunakan model open source yang dilatih untuk OCR resi berbahasa Vietnam, proyek tersebut tentu sudah memproses data resi bahasa Vietnam paling banyak.
00:05:28Pasti ada seseorang yang menyempatkan waktu untuk mengumpulkan data sebanyak mungkin.
00:05:32Dan untuk tugas itu, model tersebut akan mengungguli hampir semua model lainnya.
00:05:35Dan ada ratusan ribu model seperti itu di Hugging Face.
00:05:41Semuanya sudah ada di sana dan gratis, sebagian besar dengan lisensi yang sangat bebas.
00:05:46Jadi modelnya sudah ada, itu bukan kendalanya.
00:05:50Dan kita sudah membicarakan AI open source sejak tahun 2024.
00:05:56Namun sejauh ini perkembangannya belum benar-benar terwujud.
00:05:59Penerapan AI open source di perusahaan-perusahaan saat ini pada dasarnya cuma sebatas AWS Bedrock.
00:06:05Padahal kalau dilihat katalog model di Bedrock, pilihan jenis model yang tersedia sangat terbatas.
00:06:14Model-modelnya sering kali sudah lama, tertinggal dua hingga tiga tahun dari teknologi terkini.
00:06:19Dan ketika melakukan fine-tuning di Bedrock, Anda tidak benar-benar memiliki artifak hasil fine-tuning atau pelatihannya.
00:06:25Sehingga Anda tidak bisa memanfaatkannya sebagai keunggulan nyata bagi bisnis Anda.
00:06:29Hasilnya tetap terikat pada penyajian dari infrastruktur Bedrock.
00:06:32Sekarang di luar opsi proprietary, jika Anda menyajikan model kecil di infrastruktur open source seperti VLLM, SGLang, atau solusi lainnya,
00:06:41ketahuilah bahwa sistem ini tidak dioptimalkan untuk model atau kombinasi model dan perangkat keras tertentu.
00:06:48Anda harus melakukan penyetelan sendiri; inilah bagian “buat sendiri” itu.
00:06:51Semua alat ini dilengkapi panduan tentang cara melakukan penyetelan, parameter sweep, penyesuaian dengan trafik Anda, dan sebagainya.
00:07:00Setiap kali Anda mencoba mengadopsi salah satu alat ini, prosesnya seperti proyek riset tanpa akhir.
00:07:05Jadi ini bukan sesuatu yang tinggal Anda ambil lalu diselesaikan seperti proyek rekayasa biasa,
00:07:10di mana seminggu kemudian Anda langsung punya infrastruktur penyajian berkinerja tinggi.
00:07:14Sistemnya tidak bekerja seperti itu.
00:07:15Dan itulah masalah klasik dari perangkat lunak open source.
00:07:19Segalanya terlalu banyak menuntut Anda untuk membangun sendiri.
00:07:21Selain belum dioptimalkan untuk model kecil, beban kerja dan trafik model kecil yang menggunakan banyak model berbeda
00:07:32justru membalikkan persamaan untuk klaster inferensi.
00:07:37Biasanya, saat mencoba menyajikan satu model besar, masalah Anda adalah bagaimana membagi model tersebut ke beberapa GPU.
00:07:44Bagaimana cara memasang router di bagian atas yang memahami status semua worker ini, seperti status KVCache dan sebagainya,
00:07:51lalu membuat keputusan rute dari atas ke bawah tentang worker atau grup worker mana yang harus menangani permintaan tersebut.
00:07:59Penyusunannya sangat bersifat top-down.
00:08:01Namun jika Anda memiliki banyak permintaan kecil dan cepat, rute top-down seperti ini justru menjadi kemacetan (bottleneck).
00:08:09Karena router mendapatkan versi status worker yang sedikit tertinggal, sehingga sangat sulit untuk memaksimalkan beban kerja worker
00:08:16jika keputusan awal harus dibuat di tingkat atas yang wajib menyeimbangkan antrean lokal di setiap worker secara sempurna.
00:08:26Sebab ada sangat banyak permintaan berukuran kecil.
00:08:29Kami telah bereksperimen dengan router VLLM dan SGLang untuk model kecil dengan jenis trafik seperti ini,
00:08:37dan sangat sulit untuk membuat penggunaan GPU Anda melebihi 20% hingga 30% di bawah beban kerja konstan.
00:08:44Masalah utamanya adalah ukuran batch tersebut tidak terbagi dengan benar karena adanya hambatan pada routing.
00:08:51Masalah ketiga adalah, pada model kecil, Anda sangat diuntungkan oleh LoRA dan adaptasi model secara umum.
00:08:57Sehingga lalu lintas yang harus Anda layani mencakup permintaan dari orang-orang yang datang dan berkata,
00:09:03“Hei, aku punya 10 LoRA. Bagaimana cara menggunakannya di stack penyajian kita?”
00:09:08Atau, “Aku punya model fine-tune khusus yang kubuat tadi malam, dan aku ingin menggunakannya di tingkat produksi.”
00:09:14Diskusi antara AI engineer dan tim infrastruktur untuk menerapkan LoRA
00:09:21serta model kustom tersebut adalah hal yang memakan waktu.
00:09:24Pada dasarnya, penghambat utama kecepatan organisasi adalah komunikasi interaktif yang berbelit-belit.
00:09:30Idealnya, Anda ingin insinyur infrastruktur fokus pada pekerjaan mereka, dan AI engineer fokus pada tugas mereka sendiri.
00:09:37Mereka tidak perlu terus berkoordinasi untuk operasional sehari-hari.
00:09:41Jadi pada dasarnya mereka tidak saling menghambat.
00:09:45Kebutuhan adaptasi model kecil seperti ini merusak alur kerja tersebut dan memicu banyak koordinasi bolak-balik.
00:09:51Dan itu adalah masalah, bukan?
00:09:54Jadi ini adalah beberapa tantangan terkait, oke, kita punya banyak model kecil.
00:09:58Bagaimana kita memiliki klaster? Bagaimana kita menyajikannya secara efisien?
00:10:02Jadi kami telah mencoba menangani masalah ini selama beberapa waktu.
00:10:05Saya Daniel, dari Superlinked. Saya tadi melewatkan perkenalan.
00:10:09Jadi kami adalah perusahaan yang didukung VC dari San Francisco.
00:10:13Dan kami telah membangun sistem pencarian dan pemrosesan dokumen serta agen berbasis AI selama beberapa tahun terakhir.
00:10:20Dan titik kendala utama kami selalu pada inferensi, khususnya masalah-masalah yang telah saya jelaskan.
00:10:26Jadi kami telah melakukan iterasi demi iterasi dan mengeksplorasi berbagai topologi klaster untuk menjalankan jajaran model kecil yang luas di berbagai lingkungan.
00:10:37Karena terkadang Anda perlu men-deploy bersama platform tertentu di lingkungan tempat yang entah apa yang tersedia di sana.
00:10:44Model kecil memudahkannya karena di lingkungan apa pun, mendapatkan L4 atau semacam kuota GPU kecil jauh lebih mudah.
00:10:52Jadi ini semacam -- saya akan menjelaskan sedikit tentang topologi klaster yang akhirnya kami pilih.
00:10:58Dan omong-omong, seluruh proyek ini berlisensi Apache 2.0, sepenuhnya sumber terbuka.
00:11:03Kalian bisa langsung mengambil dan membungkusnya, lalu kalian menjadi startup inferensi.
00:11:08Ini sumber terbuka dari tingkat control plane hingga ke bagian yang berjalan di GPU.
00:11:14Jadi kami memberikan semuanya tanpa ada yang ditahan.
00:11:18Dan topologinya pada dasarnya memiliki sebuah gateway.
00:11:21Alih-alih menggunakan router yang menentukan di awal ke mana permintaan pergi, ada gateway yang menguraikan sebagian permintaan dan melampirkan metadata.
00:11:30Menyisipkan permintaan itu ke dalam antrean bersama dan ke beberapa saluran sampingan.
00:11:36Saya akan membahasnya sedikit lebih dalam.
00:11:37Kemudian para worker menarik dari antrean terpusat itu alih-alih mendorong data langsung ke worker.
00:11:44Dengan cara ini, mereka dapat mengoptimalkan kapasitas mereka sendiri dengan lebih baik.
00:11:47Lalu pengaturan worker -- kurasa saya punya salindia untuk itu -- akan menjelaskan bagaimana kami menyerap kompleksitas berbagai arsitektur model
00:11:57menjadi serangkaian worker yang koheren yang tidak memiliki persyaratan Python yang saling bentrok dan semacamnya.
00:12:03Jadi itulah gambaran topologi secara keseluruhan.
00:12:06Dan ini adalah alur hidup dari sebuah permintaan.
00:12:11Mungkin saya akan menyoroti beberapa hal dari sini.
00:12:15Salah satu hal yang tidak kami sukai dari standar API OpenAI adalah JSON berformat base64.
00:12:25Tidak bagus untuk model kecil, tidak bagus untuk throughput tinggi.
00:12:28Jadi kami menggunakan MessagePack secara menyeluruh, seperti format biner.
00:12:31Dengan cara ini kami juga bisa mendorong semua data multimodal melalui API gateway yang sebenarnya.
00:12:37Jadi tidak ada skenario seperti data biner di sini dan permintaan di sebelah sana.
00:12:42Lalu klaster membutuhkan akses ke cloud storage Anda untuk mulai memuat data biner, gambar, atau video.
00:12:48Kami mengodekan semuanya dan mendorongnya melalui gateway.
00:12:53Lalu gateway memisahkan beberapa bagian yang lebih berat agar tidak menyumbat antrean internal dan menundanya ke cloud storage saat permintaan dalam antrean.
00:13:02Jadi gateway memecah beberapa permintaan yang berukuran, katakanlah, di atas satu megabita dan menggunakan cloud storage di backend.
00:13:09Tetapi sebagai pengguna, Anda mendorong semua bit dan byte ke lapisan API dan ini menjadi antarmuka yang bersih karena hal itu.
00:13:19Jadi pada dasarnya seluruh tumpukan adalah REST, gateway REST, worker REST, dan melalui socket secara lokal terhubung ke berbagai runtime.
00:13:30Dan kami memiliki PyTorch, Candle, dan SGLang sebagai runtime.
00:13:35Lalu saat melakukan optimasi, saya akan menjelaskan bagaimana kami memastikan runtime apa pun yang kami gunakan
00:13:43dan kode mana pun yang berjalan di runtime tersebut adalah yang paling efisien.
00:13:47Kami memiliki ikal riset otomatis untuk itu.
00:13:50Tapi ya, alur hidup dari sebuah permintaan kurang lebih seperti itu.
00:13:54Dan satu tips kecil adalah Anda harus memastikan gateway, yang merupakan hal pertama yang diakses oleh permintaan, tidak melakukan terlalu banyak pekerjaan.
00:14:05Karena jika tidak, itu akan menjadi kemacetan, bukan?
00:14:07Jadi Anda bahkan tidak perlu menguraikan seluruh permintaan.
00:14:09Anda harus bisa melihat paket dan memahami bentuk umum dari apa yang datang, melakukan anotasi,
00:14:16lalu Anda memiliki worker, berapa pun jumlahnya, ratusan GPU yang melihat status antrean lalu menarik dari sana.
00:14:25Dan antrean menggunakan NATS JetStream, dan sistem itu bisa menangani jutaan permintaan per detik.
00:14:32Sangat sulit bagi bagian itu untuk menjadi titik kemacetan.
00:14:35Jadi, ya, idealnya Anda tidak ingin melakukan serialisasi dan deserialisasi saat melewati semua komponen ini.
00:14:42Itu adalah hal yang cukup jelas.
00:14:45Ini adalah animasi singkat yang menunjukkan gagasan di balik pengantrean terpusat, ya?
00:14:51Alih-alih router teratas yang mencoba mengisi antrean lokal dengan pas, yang pada dasarnya mustahil,
00:15:01seluruh idenya adalah, bisakah kita memusatkan pengantrean dan bisakah worker mengambil tugas membentuk batch mereka sendiri
00:15:09batch dengan prediksi mereka sendiri tentang biaya batch, lalu menjadi jauh lebih efisien?
00:15:15Sekarang, satu tips dan catatan sampingan, begitu Anda mulai mengerjakan hal-hal ini, Anda menyadari bahwa sebenarnya sangat sulit memprediksi berapa banyak item yang harus diambil dari antrean bersama agar ukuran batch benar-benar optimal.
00:15:30Jadi Anda akan menginginkan mekanisme yang memungkinkan Anda mengembalikan beberapa hal ke dalam antrean.
00:15:35Jika Anda menyadari, “Oh, saya menarik terlalu banyak.”
00:15:37Dan itu membutuhkan lompatan jaringan, bukan?
00:15:39Jadi itu adalah sebuah masalah.
00:15:40Dan kami memiliki optimasi khusus untuk itu bagi mesin yang memiliki beberapa GPU secara lokal, bukan?
00:15:46Jadi ada elemen pengantrean lokal mesin tambahan yang memanfaatkan fakta bahwa proses lokal yang berjalan pada beberapa GPU di satu mesin dapat bernegosiasi dengan antrean secara bolak-balik,
00:15:59yang mana melalui jaringan, akan menambah beberapa milidetik ekstra.
00:16:03Jadi kami tidak melakukannya melalui jaringan, hanya saat kami menempatkan worker bersama di mesin multi-GPU.
00:16:11Dan maksud saya, kita tidak sedang membicarakan perbedaan 5% di sini, kan?
00:16:16Jadi, Anda memusatkan antrean dan sekarang Anda mendapatkan dua kali lipat throughput klaster.
00:16:19Jadi ini sangat signifikan.
00:16:22Saya menyebutkan tiga runtime yang berbeda.
00:16:25Jadi, pada dasarnya, katakanlah untuk model encoder-only, kami menulis kode PyTorch.
00:16:33Dan kami mengoptimalkannya serta memiliki ikal riset otomatis yang mengoptimalkannya.
00:16:38Sama halnya dengan Candle.
00:16:39Kami mulai mencoba Candle belum lama ini.
00:16:42Kami masih belum bisa membuatnya berkinerja mendekati performa PyTorch.
00:16:45Jadi ini lebih merupakan proyek riset.
00:16:47Ini soal dependensi, seperti, gambar Docker worker dengan PyTorch berukuran sekitar 12 gigabita.
00:16:54Dan biner worker dengan Candle yang tertaut secara statis mungkin hanya sekitar 10% dari itu, kan?
00:17:01Dan jika Anda peduli tentang boot dari kondisi dingin dan memuat gambar-gambar ini di banyak mesin,
00:17:08penurunan dari 12 gigabita menjadi sekitar satu gigabita memberikan perbedaan yang sangat besar.
00:17:13Jadi itulah motivasi di balik Candle.
00:17:15Hanya saja, mendapatkan performa yang sama dari PyTorch memang sangat sulit.
00:17:20Lalu SGLang kami gunakan di sana sebagai semacam acuan utama.
00:17:25Kami harus berkinerja setidaknya sebaik SGLang dengan penyesuaian optimal dari semua parameter yang saya sebutkan tadi.
00:17:34Berikut adalah beberapa angka.
00:17:37Sebagai contoh, ketika kami membungkus SGLang dengan socket dan dengan sidecar Rust kami,
00:17:43sebenarnya kami dapat meningkatkan performa SGLang murni hanya karena kami melakukan sesuatu pada sisi pemrosesan batch yang tidak dilakukan SGLang secara bawaan.
00:17:54Dan mungkin Anda bisa membuatnya melakukan itu.
00:17:57Jika Anda mengembangkan plugin kustom ke dalam SGLang dan semacamnya,
00:18:00mungkin Anda bisa menyamai performa kami karena, Anda tahu,
00:18:04Anda bisa mendorong logika yang sama ke dalam server inti SGLang.
00:18:07Tetapi sekarang Anda mengembangkan kode kustom yang hanya bekerja dengan SGLang.
00:18:11Dan pelajaran utama dari model kecil adalah bahwa runtime-nya sangat beragam, bukan?
00:18:16Anda tidak harus terjebak dengan satu runtime tertentu karena ada, Anda tahu,
00:18:22kami memiliki sekitar 50 adapter berbeda saat ini yang kami parametrisasi untuk berbagai model.
00:18:28Jadi Anda harus bisa menangani kompleksitas mendasar seperti ini.
00:18:32Dan caranya mungkin bukan dengan membuat banyak plugin untuk satu runtime spesifik.
00:18:36Caranya mungkin melalui semacam abstraksi, yang dalam kasus kami adalah konsep sidecar Rust ini dan kemudian socket.
00:18:47Sekarang saya akan membicarakan beberapa angka yang berbeda, tetapi dalam hal istilah seputar pengukuran kinerja,
00:18:53“titik belok” adalah konsep saat Anda meningkatkan lalu lintas pada server,
00:18:57saat Anda meminta lebih banyak throughput darinya,
00:19:01dan server memberi Anda lebih banyak throughput, saat itulah grafik naik secara linier.
00:19:05Lalu pada titik tertentu Anda mencapai titik di mana Anda meminta lebih banyak tetapi tidak ada peningkatan.
00:19:09Jadi grafiknya mendatar dan latensinya naik.
00:19:12Jadi kami menyebutnya titik belok dan itu adalah konsep yang berguna dalam pengukuran kinerja,
00:19:17karena itu merupakan titik jenuhnya, bukan?
00:19:20Itu adalah performa maksimum tanpa merusak latensi.
00:19:23Hanya untuk memberi Anda gambaran tentang apa yang mungkin dilakukan pada perangkat keras yang relatif kecil, kan?
00:19:32Dan berbagai jenis model kecil.
00:19:34Ini diukur pada RTX Pro 6000.
00:19:37Kami biasanya bekerja dengan NVIDIA L4, A100, RTX Pro 6000, H100, di kisaran seperti itu.
00:19:46Sekali lagi, GPU tersebut jauh lebih mudah tersedia sesuai kebutuhan di cloud mana pun.
00:19:52Sebagian besar benua memiliki kuotanya.
00:19:56Dan pada perangkat keras seperti ini, untuk model embedding,
00:20:01bahkan hingga ratusan juta parameter,
00:20:05Anda bisa mendapatkan ratusan ribu token per detik yang dienkode ke dalam embedding, bukan?
00:20:12Bayangkan Anda duduk di sana sekarang, mengakses pohon embedding teks di API OpenAI.
00:20:17Sebaliknya, Anda bisa memakai satu GPU dan memasukkan setengah juta token per detik untuk mendapatkan vektornya.
00:20:26Paham, kan?
00:20:28Apakah ini masuk akal?
00:20:31Anda memasukkan setengah juta token per detik ke satu GPU yang ukurannya tidak terlalu besar,
00:20:38lalu mendapatkan embedding vektor untuk sistem pencarian Anda, alih-alih memasukkan semuanya ke endpoint embedding terkelola dan membayar jauh lebih mahal.
00:20:49Bukan?
00:20:50Dan Anda bisa mendapatkan latensi hanya belasan milidetik untuk panggilan ini.
00:20:55Jika memakai API Cohere atau OpenAI, latensinya bisa mencapai ratusan milidetik.
00:21:02Ini bukanlah hal yang rumit.
00:21:03Anda bisa menghemat biaya secara masif, meningkatkan latensi dengan drastis, dan mengoperasikannya dengan mudah menggunakan beberapa GPU serta infrastruktur pendukung.
00:21:17Jadi ini adalah peluang yang sangat mudah. Jika ingin mulai dengan model sumber terbuka atau model kecil, embedding adalah pilihan paling logis.
00:21:26Tapi tidak berhenti di situ.
00:21:27Katakanlah Anda ingin mencoba pengenalan entitas bernama (NER).
00:21:33Atau pencarian multi-vektor, bahkan generatif untuk teks atau output terstruktur, dan sejenisnya.
00:21:42Anda bisa menghasilkan ribuan token output per detik dari model generatif khusus tugas, misalnya sekitar lima ratus per detik untuk satu GPU di bagian bawah itu.
00:21:58Jika Anda membuat data sintetis atau anotasi untuk fine-tuning dan evaluasi, jangan lakukan itu di endpoint terkelola.
00:22:11Itu tugas yang sempurna karena berada di bawah kendali Anda.
00:22:14Anda bisa meninjau kualitasnya.
00:22:16Itu tugas yang tepat untuk model sumber terbuka di infrastruktur Anda sendiri.
00:22:20Lalu, jika infrastruktur GPU Anda cukup memadai, skalabilitasnya akan meningkat secara linier sesuai jumlah GPU.
00:22:31Gagasan lain jika Anda menyajikan model kecil adalah, biasanya Anda memiliki worker pool per model, bukan?
00:22:44Anda punya sekumpulan worker dan node yang memiliki GPU, lalu Anda menjalankannya dan memuat model terlebih dahulu.
00:22:51Model tersebut membutuhkan waktu puluhan menit untuk dimuat karena memiliki ratusan miliar parameter.
00:22:55Lalu Anda senang karena akhirnya selesai dimuat dan worker pool siap digunakan.
00:22:59Pola pikir seperti ini tidak cocok untuk model kecil.
00:23:02Cepat sedikit.
00:23:04Berapa sisa waktunya?
00:23:06Lewat enam menit.
00:23:07Oh, lewat enam menit.
00:23:08Baiklah.
00:23:09Oke.
00:23:10Menyatukan beberapa model di GPU yang sama itu lebih cepat.
00:23:12Ini tentang bagaimana Anda tetap ingin mengunci beberapa model, tetapi juga menerapkan pemuatan lambat (lazy loading) dan pengosongan berdasarkan beban memori.
00:23:26Anda harus mencari cara untuk menggabungkan keduanya.
00:23:28Ada sedikit pembahasan tentang riset otomatis.
00:23:32Kami memiliki alur riset otomatis untuk menambahkan dukungan bagi model baru dan performanya.
00:23:39Kami membuat banyak alat internal untuk melakukan pengukuran yang dimasukkan ke alur riset otomatis demi meningkatkan performanya.
00:23:47Dan yang paling penting, saat kami merilis dukungan untuk suatu model, semua optimasinya sudah selesai.
00:23:53Jadi tidak ada lagi istilah mencari parameter secara manual.
00:23:55Kami menyertakan konfigurasi lengkap secara menyeluruh untuk seluruh kluster.
00:24:00Ini adalah pengoperasian untuk alur riset otomatis.
00:24:03Ada semacam meta loop yang membangun sistem pengujian yang kemudian menjalankan alurnya.
00:24:08Di bagian atas ada dasbor yang membantu Anda memahami cara kerjanya.
00:24:12Kami memiliki antarmuka khusus untuk itu.
00:24:15Salah satu hasilnya adalah LoRA yang hanya membutuhkan biaya pelatihan 80 sen dan meningkatkan kualitas pencarian istilah hukum Jerman sebesar 18% sebagai bukti konsep.
00:24:27Sekian dari saya.
00:24:29Jadi model kecil itu sangat bagus.
00:24:30Model tersebut relatif mudah disajikan.
00:24:32Jauh lebih murah dan lebih cepat.
00:24:35Langkah yang cerdas.
00:24:36Dan kode QR itu mengarah ke repositori GitHub kluster kami yang baru saja saya jelaskan.
00:24:43Beri kami star.
00:24:44Dan selamat mencoba self-hosting.
00:24:45Terima kasih.
00:24:46Terima kasih.
00:24:47Terima kasih.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video