Memproduksi Gateway LLM: Arsitektur, Kompromi, dan Pelajaran Berharga — Kanish Manuja, Twilio
AAI Engineer
Computing/SoftwareManagementInternet Technology
Transcript
00:00:00Saya Ganesh Manuja. Saya seorang insinyur utama di Twilio. Mari kita mulai dengan mengangkat tangan sebentar.
00:00:20Siapa di sini yang pernah melihat pesan, terjadi kesalahan, silakan coba lagi?
00:00:27Baiklah, ada beberapa yang beruntung dan beberapa yang baru saja makan siang dengan baik.
00:00:33Jadi, di balik pesan sederhana itu sebenarnya terdapat sistem yang sangat kompleks yang menyajikan pesan tersebut kepada Anda meskipun penyedia model sedang down.
00:00:45Dan itulah yang akan kita produksi hari ini atau bahas produksi hari ini.
00:00:50Jadi, apa itu gerbang LLM?
00:00:52Gerbang LLM adalah titik masuk atau middleware antara aplikasi Anda dan penyedia model di belakangnya.
00:00:58Ini melakukan banyak hal, perutean, autentikasi, cadangan, batasan tingkat, segala jenis tata kelola yang dapat Anda pikirkan.
00:01:08Dan tepat di jantung gerbang adalah pertarungan antara empat hal.
00:01:13Itu adalah ketersediaan, latensi, pengaman Anda, dan biaya.
00:01:18Jika terjadi degradasi, Anda tidak dapat memaksimalkan keempatnya.
00:01:22Anda harus memilih apa yang Anda inginkan.
00:01:25Jadi, dengan pembicaraan ini, jika Anda menggunakan gerbang LLM, saya ingin membantu Anda membuat pertukaran itu untuk kasus penggunaan Anda.
00:01:35Dan jika Anda mendesain gerbang, saya ingin Anda mendesain atau menyediakan tuas tersebut kepada pemanggil dan pelanggan Anda agar pelanggan Anda senang.
00:01:46Mari kita mulai dengan ketersediaan.
00:01:50Jika Anda memiliki satu penyedia model, langit-langit mereka adalah langit-langit Anda.
00:01:56Pemadaman mereka adalah pemadaman Anda.
00:02:03Jadi, dalam teknik perangkat lunak biasa, cara Anda mengatasi dependensi yang tidak dapat diandalkan adalah dengan mencoba ulang.
00:02:11Mencoba ulang dengan pencadangan eksponensial, dengan jeda acak.
00:02:15Dan ketika semua itu gagal, Anda memiliki pemutus arus yang trip setelah Anda melihat kegagalan yang cukup, dan Anda berhenti memanggil hal sialan itu.
00:02:24Ini tidak cukup untuk LLM.
00:02:26LLM sangat berbeda dibandingkan dengan API Anda yang cepat dan murah yang Anda coba ulang.
00:02:32Mencoba ulang API LLM memangkas anggaran latensi Anda dengan sangat cepat.
00:02:38Dan juga, tersandung pemutus arus ketika Anda memiliki penyedia model lain yang baik-baik saja untuk dirutekan tidak masuk akal.
00:02:47Anda harus menggunakan penyedia model kedua.
00:02:48Dan ketiga, seperti yang saya katakan, panggilannya lambat dan mahal.
00:02:53Jadi, percobaan ulang buta, hanya melipatgandakan biaya dan latensi ekor Anda.
00:02:58Jadi, apa ide yang lebih baik di sini?
00:03:02Ini sebenarnya adalah cadangan per permintaan.
00:03:05Artinya, Anda sebenarnya dapat mencoba penyedia model A dan kemudian, secara berurutan, mencoba penyedia model B jika permintaan Anda ke penyedia model A gagal.
00:03:14Pilihan lain untuk dipertimbangkan di sini adalah Anda dapat memicu permintaan ke kedua penyedia secara paralel, tetapi itu hanya jika Anda sangat, sangat terobsesi dengan latensi, karena itu hanya akan melipatgandakan biaya Anda.
00:03:26Beberapa pola pemutus arus yang serupa juga berlaku di sini untuk LLM.
00:03:32Jika Anda tahu bahwa primer Anda telah gagal selama beberapa waktu, tidak masuk akal untuk mencobanya lagi.
00:03:40Anda mengambilnya dari penyeimbang beban atau jalur permintaan Anda dan memasukkannya ke dalam pendinginan dan kemudian, setelah beberapa menit berlalu, coba masukkan itu kembali lagi.
00:03:51Satu pilihan menarik yang harus Anda buat di sini adalah di mana jumlah kegagalan Anda berada.
00:03:59Anda dapat memutuskan untuk memiliki jumlah kegagalan yang ada di memori pada instance yang melayani lalu lintas Anda, atau Anda dapat memiliki info bersama di mana jumlah kegagalan Anda dibagikan di seluruh armada.
00:04:12Ada trade-off.
00:04:14Jika Anda ingin failover cepat, maka di seluruh armada membantu.
00:04:19Dan dengan instance, dengan penghitung status lokal, masalah yang Anda hadapi adalah setiap kali Anda mengubah ukuran penyebaran, konfigurasi, dan harapan Anda berubah.
00:04:30Jadi sesuatu untuk dipertimbangkan.
00:04:34Apa yang tidak benar-benar ditunjukkan oleh diagram bersih itu adalah beberapa jebakan lain yang akan saya bahas.
00:04:39Jadi cadangan tidak transparan.
00:04:41Meskipun industri ini menyatu pada format yang kompatibel dengan API OpenAI, saya akan mengatakan masih ada nuansa.
00:04:49Jadi Anda harus benar-benar menguji cadangan Anda dengan baik.
00:04:52Mereka dapat memiliki perbedaan dalam skema pemanggilan alat Anda, batas token, alasan berhenti, dan apa saja.
00:04:58Jadi dengan gerbang LLM, Anda dapat memiliki lapisan normalisasi yang dapat memastikan bahwa Anda dapat melakukan cadangan lintas penyedia juga.
00:05:08Hal lain adalah streaming.
00:05:15Jadi pada intinya, tidak ada yang mau menunggu selama 30 detik untuk melihat dinding teks muncul di depan mereka.
00:05:22Jadi ada kasus penggunaan di mana streaming sangat diperlukan.
00:05:26Tetapi itu ada harganya.
00:05:27Anda memperdagangkan tuas Anda.
00:05:29Anda tidak bisa -- begitu Anda memutuskan untuk pergi dengan Penyedia A, Anda harus terus pergi dengan Penyedia A.
00:05:36Anda tidak dapat mengubah penyedia di tengah jalan.
00:05:39Apa pun yang telah dikirim ke klien, itu selesai.
00:05:42Dan di situlah pesan ada yang salah.
00:05:46Itulah yang Anda lihat.
00:05:48Itu bukan karena kemalasan.
00:05:49Itu memang dirancang agar Anda melihatnya.
00:05:52Dan itu adalah salah satu pertukaran.
00:05:54Saya ingin menyebutkan satu hal lain di mana saya telah melihat tim tersandung berulang kali.
00:06:00Mereka benar-benar menyediakan dan menguji penyedia utama mereka dengan sangat baik.
00:06:05Tetapi penyedia kedua, penyedia cadangan, tidak selalu mendapatkan tingkat cinta yang sama.
00:06:11Dan saya akan berpendapat bahwa throughput atau kapasitas atau ruang kepala Anda bahkan harus lebih tinggi untuk penyedia kedua atau penyedia cadangan.
00:06:21Karena itu adalah garis pertahanan terakhir Anda.
00:06:23Jika itu down, aplikasi Anda down.
00:06:29Mari kita bahas latensi.
00:06:31Kegagalan ketersediaan tepat di depan mata Anda.
00:06:34Mereka gagal.
00:06:36Anda mendapatkan alarm.
00:06:37Anda dihubungi.
00:06:38Tetapi latensi tinggi bisa menjadi yang pendiam.
00:06:42Dan mereka harus menerima lebih banyak cinta daripada, saya katakan, menyetel layanan Anda hanya untuk ketersediaan.
00:06:49Satu hal yang perlu disebutkan.
00:06:54Sebuah gerbang dapat menjalankan beban kerja campuran.
00:06:58Dan Anda dapat memiliki permintaan penyematan yang hanya membutuhkan waktu kurang dari satu detik.
00:07:04Anda dapat memiliki permintaan klasifikasi yang membutuhkan waktu kurang dari satu detik.
00:07:07Anda memiliki permintaan obrolan yang memakan waktu tiga detik.
00:07:10Dan permintaan penalaran yang memakan waktu lama.
00:07:13Tunjukkan tangan sebentar.
00:07:15Tunjukkan tangan sebentar jika Anda mengukur latensi agregat untuk seluruh layanan Anda.
00:07:20Yah, itu adalah pertanyaan jebakan.
00:07:23Maaf.
00:07:24Seharusnya tidak.
00:07:25Itu tidak masuk akal.
00:07:26Itu bohong.
00:07:27Anda harus melacak P99 Anda per model per rute, bukan angka selebar gerbang.
00:07:32Angka selebar gerbang tidak masuk akal, terutama jika Anda menjalankan beban kerja campuran.
00:07:36Dan saya harap Anda tidak, bagi mereka yang mengangkat tangan.
00:07:40Hal lain yang benar-benar dapat -- saya tidak cukup menekankan hal ini adalah bagi Anda untuk menyetel batas waktu pada setiap kelas model per rute.
00:07:49Di situlah -- itulah akar penyebab nomor satu dari pemadaman diam-diam Anda.
00:07:54Jika Anda tidak memiliki batas waktu, gerbang Anda berpikir, permintaan Anda sedang dilayani dengan senang hati, padahal sebenarnya tidak.
00:08:00Dan saya akan meninggalkan Anda dengan pesan ini untuk latensi, khususnya.
00:08:05Normal model penalaran sebenarnya adalah pemadaman model obrolan.
00:08:09Jadi Anda pasti perlu melacak latensi per rute.
00:08:13Oke, ini adalah yang paling menyakitkan atau slide yang memberi saya ketakutan terbanyak, yaitu model penalaran dan perute.
00:08:24Jadi di sinilah, sungguh, latensinya tidak dapat diprediksi.
00:08:29Dan model penalaran, mereka tidak memberi Anda -- mereka sangat tidak deterministik, lebih tidak deterministik daripada model normal Anda.
00:08:40Anda tidak dapat menyetel suhu ke nol dalam banyak kasus.
00:08:43Dan prompt yang sama dapat memakan waktu mulai dari dua detik hingga 60 detik.
00:08:48Dan kita telah melihatnya dalam produksi, di mana P99 tiba-tiba melonjak hingga 60 detik tanpa alasan yang jelas.
00:08:53Jadi itu -- meskipun tidak ada solusi magis untuk itu, saya akan menyarankan agar Anda setidaknya mulai dengan memperbaiki tingkat penalaran per rute.
00:09:03Jadi dengan model perute, mereka menyembunyikan abstraksi itu di belakang Anda.
00:09:08Seperti, mereka memilih model mana yang akan dijalankan.
00:09:11Dan saya sangat menyarankan agar Anda setidaknya membuat sebanyak mungkin -- Anda membuat permintaan sedeterministik mungkin dengan sistem yang tidak deterministik.
00:09:23Ide lain adalah melindungi bagian ekor.
00:09:26Anda dapat memiliki -- Anda dapat memicu permintaan lain jika permintaan utama Anda sebenarnya menghabiskan, katakanlah, P90 dari anggaran latensi Anda.
00:09:37Ini dapat melindungi -- ini benar-benar dapat melindungi ekor P99 untuk layanan Anda.
00:09:44Baiklah, ini adalah salah satu favorit saya.
00:09:47Untuk menjaga keamanan model Anda, Anda harus memiliki pengaman.
00:09:53Dan dengan itu, pengaman diperlukan untuk mencegah layanan Anda dari serangan injeksi prompt, menjaga filter PII tetap ada, memiliki filter toksisitas, menjaga LM agar tidak mengumpat pada pelanggan Anda.
00:10:08Semua hal baik itu.
00:10:11Tetapi sama seperti penyedia model, ada juga pertukaran.
00:10:15Pengaman seperti layanan lainnya.
00:10:18Itu bisa down.
00:10:19Itu bisa tidak dapat diandalkan.
00:10:21Dan di situlah Anda harus memilih.
00:10:24Apakah Anda gagal terbuka atau gagal tertutup?
00:10:27Ketika saya katakan gagal terbuka, Anda masih dapat melayani permintaan bahkan jika pengaman Anda down.
00:10:32Gagal tertutup, Anda memblokir permintaan dan berkata, hei, saya tidak tersedia.
00:10:36Itulah kompromi antara ketersediaan dan keamanan sampai tingkat tertentu.
00:10:41Meskipun tidak ada jawaban universal, ini sangat bergantung pada kasus penggunaan Anda.
00:10:45Anda dapat memutuskan, misalnya, filter toksisitas, jika tidak aktif dan berjalan, Anda tetap dapat melayani permintaan tersebut.
00:10:53Jadi pilihan bawaannya harus berupa skenario terburuk yang dapat Anda toleransi.
00:11:02Ada beberapa hal yang sebenarnya dapat Anda lakukan untuk meningkatkan perilaku sistem Anda saat menghadapi kendala keamanan yang mati dan mengelola ketidakandalan dari pengaman itu sendiri.
00:11:17Jadi yang pertama adalah anggaran waktu.
00:11:20Permintaan Anda tidak boleh dibatasi oleh durasi pengaman Anda.
00:11:25LLM harus selalu menjadi langkah penentu tarif.
00:11:29Jadi pastikan Anda memiliki batas waktu dan pengaman tersebut berjalan dengan anggaran waktu tertentu.
00:11:38Hal penting lainnya adalah cadangan.
00:11:40Anda mungkin tahu, dan saya telah membahasnya, kita selalu mendiskusikan cadangan terkait penyedia model.
00:11:47Tetapi pengaman juga merupakan layanan penting, di mana Anda dapat mempertimbangkan cadangan, memiliki penyedia sekunder, pemeriksaan sekunder, dan menyimpan keputusan dalam cache agar layanan Anda tetap tersedia saat penyedia pengaman sedang down.
00:12:03Pilihan menarik lainnya yang muncul terkait dengan pengaman adalah penempatan pengaman tersebut.
00:12:10Biasanya, Anda dapat menempatkan pengaman dalam tiga cara.
00:12:15Anda dapat memiliki pra-kait yang berjalan di mana pengaman benar-benar berjalan pada masukan.
00:12:19Anda bisa — dan itu mungkin yang paling aman, tetapi hal itu menambah latensi serial pada permintaan Anda.
00:12:26Cara lainnya adalah secara paralel.
00:12:29Ini adalah salah satu favorit saya, namun perlu dicatat, streaming tidak akan bekerja dengan baik di sini dengan cara paralel.
00:12:35Jadi jika Anda khusus memproduksi output terstruktur, mohon jangan melakukan streaming padanya.
00:12:40Cobalah menghemat latensi Anda dan jalankan pengaman ini secara bersamaan untuk output terstruktur Anda.
00:12:46Satu lagi adalah pasca-kait.
00:12:48Ini adalah yang terbaik untuk pemantauan output, audit output Anda, dan sebagainya.
00:12:58Jadi, sejauh ini, saya telah membahas semua hal yang bisa salah terkait dengan dependensi kita.
00:13:06Kita belum membahas bahwa kita sebenarnya menambahkan dependensi lain di jalur permintaan itu sendiri, yaitu gateway pusat — atau gateway LLM itu sendiri.
00:13:15Ada beberapa hal di mana kita pernah mengalami masalah, dan kita telah memetik beberapa pelajaran yang ingin saya bagikan kepada Anda jika Anda sedang mengerjakan gateway LLM atau menggunakannya.
00:13:25Pertama adalah batas bersama.
00:13:28Pastikan kunci API Anda dipisahkan per rute, per kasus penggunaan, sekecil mungkin — ke tingkat sekecil yang dapat Anda bayangkan.
00:13:40Memiliki penyewa yang bising dapat menjadi salah satu masalah terbesar di sini.
00:13:47Hal lain adalah pelepasan beban.
00:13:50Ini adalah fitur yang harus Anda, sebagai bagian dari buku panduan dan simulasi latihan Anda, pastikan gateway yang Anda gunakan mendukung pelepasan beban.
00:13:59Karena ketika Anda mengalami badai percobaan ulang, akan sangat sulit untuk melakukan penskalaan keluar.
00:14:03Anda tidak bisa begitu saja menskalakan layanan yang berada di bawah badai percobaan ulang.
00:14:07Dan semua server web ini memiliki antrean internal, dan mereka dapat dikonfigurasi.
00:14:13Pastikan antrean tersebut terbatas, dan mereka tidak dapat menerima permintaan yang tidak terbatas.
00:14:19Dan jika Anda ingin memiliki beberapa logika kustom, Anda bahkan dapat memiliki prioritas lalu lintas di sini juga, untuk memastikan dalam kondisi beban tinggi kasus penggunaan terpenting Anda dilayani dengan baik.
00:14:29Hal terakhir yang ingin saya bahas adalah keseluruhan gagasan tentang gateway pusat itu sendiri.
00:14:38Itu adalah satu titik kegagalan tunggal.
00:14:40Jadi jika Anda berpikir untuk memiliki gateway pusat untuk seluruh perusahaan Anda untuk dua LLM, saya menyarankan untuk memikirkan kembali hal itu dan melihat apa saja alasan yang mendasarinya.
00:14:52Apa yang saya perhatikan adalah dalam kebanyakan skenario, bukan gateway pusat yang mereka inginkan.
00:14:57Mereka menginginkan tata kelola yang disentralisasi.
00:15:00Dan ada jalur ke depan di mana Anda benar-benar dapat mendesentralisasikan gateway dan tetap memusatkan tata kelola.
00:15:07Jadi jangan mencoba memusatkan lalu lintas Anda, tetapi Anda dapat menggunakan plugin, Anda dapat memiliki kode kustom yang dapat memusatkan tata kelola Anda.
00:15:17Tata kelola dapat berupa pelacakan biaya, manajemen batas tarif, dan ada solusi lain yang mungkin.
00:15:24Jadi jelajahi hal-hal tersebut sebelum Anda memutuskan untuk memiliki satu gateway pusat untuk seluruh perusahaan Anda.
00:15:30Hal itu dapat dikelola oleh satu tim tunggal, namun saya tidak menyarankan menerapkannya sebagai satu penerapan tunggal untuk seluruh perusahaan, meskipun hal itu didistribusikan.
00:15:43Karena itu, saya ingin mengakhiri pembicaraan ini dengan catatan pribadi.
00:15:47Jadi hari ini adalah hari ulang tahun anak saya, dan saya berada di sini berbicara dengan orang asing tentang pemutusan sirkuit.
00:15:54Jadi hal minimal yang dapat Anda lakukan untuk saya adalah tolong pergi dan cegah satu insiden untuk saya dan untuk pelanggan Anda.
00:16:02Terima kasih.
00:16:03Jika Anda memiliki pertanyaan, silakan.
00:16:06.