Continuous Batching pada LLM: Cara Meningkatkan Throughput Inferensi AI

Ketika sebuah aplikasi AI melayani banyak pengguna sekaligus, tantangannya bukan hanya seberapa cepat model menghasilkan token, tetapi juga bagaimana GPU digunakan tanpa membuat pengguna menunggu terlalu lama. Salah satu teknik di sisi server adalah continuous batching, yaitu penjadwalan permintaan generasi secara dinamis agar slot komputasi yang sudah kosong dapat segera dipakai oleh permintaan lain.

Teknik ini berguna untuk layanan chatbot, ringkasan dokumen, asisten pemrograman, dan API generatif yang menerima permintaan dengan panjang prompt serta jumlah token keluaran yang berbeda-beda. Namun, continuous batching bukan tombol ajaib: hasilnya tetap bergantung pada model, memori GPU, pola trafik, dan target latensi.

Apa Itu Continuous Batching?

Batching menggabungkan beberapa permintaan agar model memprosesnya dalam satu kelompok komputasi. Pada static batching, sekumpulan permintaan biasanya berjalan sebagai satu batch sampai selesai. Jika satu permintaan menghasilkan jawaban panjang sedangkan yang lain selesai lebih cepat, slot milik permintaan pendek dapat menganggur sementara batch menunggu anggota yang tersisa.

Continuous batching mengubah cara penjadwalan itu. Pada model generatif, server mengevaluasi ulang anggota batch pada setiap langkah generasi. Ketika sebuah permintaan selesai, slotnya dapat diisi permintaan baru tanpa menunggu semua permintaan lain di batch awal berakhir. Karena panjang jawaban sulit diprediksi, pendekatan ini dapat mengurangi waktu komputasi yang terbuang.

Bagaimana Cara Kerjanya?

Secara sederhana, server menerima prompt, menyiapkan representasi token, lalu menjalankan fase pemrosesan prompt dan fase generasi token. Setelah generasi dimulai, permintaan yang masih aktif membutuhkan langkah komputasi berulang. Scheduler memantau permintaan yang selesai, membebaskan sumber daya yang bisa digunakan kembali, kemudian memasukkan permintaan baru sesuai kapasitas yang tersedia.

Dalam layanan LLM, memori untuk menyimpan konteks perhatian selama generasi—sering disebut KV cache—menjadi faktor penting. Panjang konteks dan jumlah token yang sudah dihasilkan memengaruhi kebutuhan memori tiap permintaan. Karena itu, scheduler tidak cukup hanya menghitung jumlah permintaan; ia juga perlu mempertimbangkan batas token, blok memori, dan kapasitas perangkat.

Bedanya dengan Dynamic Batching Biasa

Istilahnya mirip, tetapi tujuan penjadwalannya dapat berbeda:

• Static batching: permintaan dikelompokkan di awal dan umumnya berjalan bersama sampai batch selesai. Polanya mudah dipahami, tetapi perbedaan panjang keluaran dapat membuat sebagian slot tidak terpakai.
• Dynamic batching: server menggabungkan permintaan yang datang dalam jendela waktu tertentu. Pendekatan ini umum untuk inferensi model yang memproses setiap permintaan secara independen, misalnya klasifikasi atau pengenalan gambar.
• Continuous batching: khususnya pada generasi token, anggota batch dapat berubah di antara langkah generasi. Permintaan yang selesai keluar dan permintaan baru masuk selama permintaan lain tetap berjalan.

Perbedaan implementasi bergantung pada mesin inferensi. Dokumentasi Hugging Face Transformers menjelaskan penjadwalan ulang batch pada setiap langkah generasi, sedangkan dokumentasi NVIDIA Triton Inference Server membahas batching dinamis dan dukungan penjadwalan bertahap untuk skenario inferensi tertentu.

Manfaat yang Bisa Diperoleh

Manfaat utama continuous batching adalah meningkatkan pemanfaatan GPU dan throughput—jumlah pekerjaan atau token yang dapat diselesaikan dalam satuan waktu—ketika permintaan datang secara bersamaan. Server juga tidak perlu menunggu satu batch besar selesai sepenuhnya sebelum mengisi slot yang kosong. Pada trafik yang bervariasi, ini dapat membantu menjaga perangkat tetap sibuk.

Meski begitu, throughput tinggi tidak otomatis berarti setiap pengguna mendapat respons lebih cepat. Antrean yang panjang, prompt yang besar, keluaran yang panjang, atau tekanan memori dapat meningkatkan waktu tunggu. Sasaran implementasi yang baik adalah menyeimbangkan kapasitas total dengan pengalaman tiap permintaan.

Risiko dan Hal yang Perlu Diperhatikan

• Tekanan memori: banyak permintaan aktif dan konteks panjang dapat menghabiskan KV cache. Tetapkan batas panjang input dan output yang realistis.
• Keadilan antrean: permintaan besar berpotensi mengonsumsi sumber daya lebih lama. Terapkan batas antrean, prioritas yang jelas, atau pemisahan kelas layanan bila diperlukan.
• Latensi ekor: rata-rata yang baik dapat menyembunyikan permintaan lambat. Pantau persentil tinggi, bukan hanya angka rata-rata.
• Pembatalan dan timeout: ketika pengguna menutup koneksi, server sebaiknya menghentikan pekerjaan yang tidak lagi dibutuhkan agar kapasitas tidak terbuang.
• Perbedaan perangkat lunak: dukungan, parameter, dan perilaku scheduler berbeda antar-mesin inferensi serta versi. Ikuti dokumentasi versi yang benar-benar dipakai.

Kesimpulan

Continuous batching dapat meningkatkan pemanfaatan perangkat keras dengan memasukkan dan mengeluarkan permintaan secara dinamis, tetapi hasilnya bergantung pada panjang prompt, panjang keluaran, konkurensi, dan scheduler. Bandingkan dengan baseline yang representatif dan pantau latensi, throughput, memori, serta pembatalan agar peningkatan kapasitas tidak merugikan pengalaman pengguna.