Optimalkan Pemrosesan Batch pada API AI Serverless

Jika pekerjaan AI Anda tidak memerlukan jawaban instan, pemrosesan batch sering kali menjadi jalur yang lebih baik. Saya akan memakainya untuk memangkas biaya API sekitar 50%, menjauhkan pekerjaan latar belakang dari lalu lintas langsung, dan memproses beban kerja teks, gambar, audio, atau video berskala besar tanpa menjejalkan semuanya ke dalam satu fungsi serverless.

Berikut versi ringkasnya:

• Saya akan memakai antrean, worker tanpa status, dan penyimpanan objek alih-alih satu fungsi yang berjalan panjang.

• Saya akan mulai dengan 100 sampai 500 item per batch untuk banyak pekerjaan LLM, lalu mengecilkan ukuran batch untuk pekerjaan yang berat media.

• Saya akan membatasi konkurensi dalam fungsi sekitar 5 sampai 10 request per worker dan memantau token per menit, bukan sekadar jumlah request.

• Saya akan menambahkan checkpoint setiap 10 sampai 50 item, 3 sampai 5 retry, exponential backoff, dan sebuah dead-letter queue.

• Saya akan membuat setiap item bersifat idempoten dengan kunci stabil seperti job_id:item_id dan memakai jalur output yang deterministik.

• Saya akan melacak item per menit, durasi batch, tingkat retry, tingkat error, dan biaya per batch dalam USD.

• Saya akan menguji pekerjaan baru dengan pilot 10 sampai 50 item sebelum menskalakannya.

Ide utamanya sederhana: pipeline AI batch bekerja paling baik ketika saya merancangnya dengan mengutamakan batasan lebih dulu. Timeout serverless, batas memori, batas payload, dan throttling dari penyedia semuanya membentuk ukuran batch, fan-out, retry, dan pola penyimpanan.

Untuk alur kerja multi-model, saya juga akan menjaga lapisan API tetap sederhana. Layanan terpadu seperti APIMart bisa membantu ketika satu pipeline perlu merutekan ke 500+ model untuk tugas teks, gambar, dan video tanpa logika vendor terpisah di setiap worker.

Yang paling penting bukan kecepatan mentah. Melainkan throughput, keamanan retry, dan kendali biaya per proses.

Serverless AI Inference: Scalable, Cost-Efficient Model Serving Explained | Uplatz

Cara Merancang Pipeline Batch Serverless yang Skalabel

Batasan-batasan itu mendorong Anda ke arah penyiapan berbasis antrean.

Komponen Inti Pipeline dan Aliran Data

Pipeline batch yang skalabel memiliki empat bagian: sebuah producer, sebuah message queue yang tahan lama, sebuah worker pool, dan sebuah penyimpanan hasil.

Berikut alur dasarnya: producer mengunggah payload besar ke penyimpanan objek, lalu menaruh pekerjaan ringan pada antrean. Worker menarik pekerjaan itu, mengambil payload, memanggil API AI, menyimpan hasil, dan baru setelah itu mengonfirmasi pesan. Langkah terakhir itu penting. Jika sebuah worker macet di tengah pekerjaan, pesan yang belum dikonfirmasi muncul kembali sehingga worker lain dapat mencoba ulang ^[6][7].

Jika suatu pekerjaan terlalu besar untuk selesai dalam batas timeout fungsi, pecah dataset menjadi batch yang lebih kecil dan sebarkan pekerjaan ke worker paralel melalui orchestrator berumur panjang.

Setelah alur dasar itu berjalan, langkah berikutnya adalah merutekan pekerjaan berdasarkan modalitas dan runtime.

Kapan Memisahkan Alur Kerja Berdasarkan Modalitas

Gunakan antrean terpisah ketika ukuran payload atau waktu pemrosesan berubah secara berarti. Tidak setiap tugas AI harus berada di worker pool yang sama. Klasifikasi teks mungkin memakan beberapa detik per item. Pekerjaan media berat bisa berjalan selama beberapa menit. Taruh keduanya dalam satu pool, dan perilaku timeout cepat menjadi berantakan ^[4][7].

Pendekatan yang lebih baik adalah memisahkan antrean berdasarkan runtime dan ukuran payload, bukan hanya berdasarkan jenis file. Rutekan pekerjaan berdasarkan jenis event. Misalnya, kirim PDF, gambar, audio, dan video ke antrean serta worker pool terpisah dengan filter event. Itu menjaga retry tetap terisolasi dan mencegah satu beban kerja menyumbat yang lain ^[8].

Memakai APIMart sebagai Lapisan API AI Terpadu

Ketika satu pipeline menangani tugas teks, gambar, dan video, mengelola integrasi vendor terpisah bisa berubah menjadi mimpi buruk pemeliharaan ^[2][6]. APIMart memberi Anda satu API untuk lebih dari 500 model AI, termasuk model bahasa seperti GPT-5 dan Claude, model gambar, serta model video seperti Sora dan Kling V3.

Itu berarti fungsi worker dapat tetap tanpa status dan konsisten di berbagai jenis pekerjaan. Ini juga membantu ketika tahap-tahap berbeda dalam pipeline membutuhkan model berbeda, karena autentikasi, rate limit, dan logika retry semuanya berada di balik satu titik integrasi.

Cara Memilih Ukuran Batch dan Model Paralelisme yang Tepat

Setelah arsitektur pipeline Anda siap, keputusan berikutnya sederhana secara teori tetapi mudah keliru dalam praktik: berapa banyak pekerjaan yang harus ditangani setiap worker dalam satu waktu, dan berapa banyak request yang harus berjalan paralel?

Jika batch terlalu kecil, Anda memboroskan komputasi untuk overhead. Jika terlalu besar, kegagalan menjadi mahal karena retry terjadi terlambat dan mengulang terlalu banyak pekerjaan. Titik ideal biasanya muncul dari menyeimbangkan runtime, penggunaan memori, dan biaya retry.

Menyeimbangkan Ukuran Batch dengan Runtime, Memori, dan Retry

Untuk sebagian besar beban kerja LLM, 100–500 item per batch adalah rentang awal yang solid. Cukup besar untuk menyebarkan overhead orkestrasi ke lebih banyak pekerjaan, tetapi masih cukup kecil sehingga kegagalan tidak memaksa Anda menjalankan ulang bagian yang sangat besar.

Retry membuat ini mudah dibayangkan. Jika sebuah worker macet menjelang akhir batch yang besar, Anda mungkin harus mengulang semua pekerjaan itu. Karena itu, membuat checkpoint setiap 10–50 penyelesaian membantu, agar sebuah kemacetan hanya mengulang sebagian kecil pekerjaan ^[2][11].

Pekerjaan yang berat media biasanya membutuhkan batch lebih kecil daripada pekerjaan teks saja karena setiap respons lebih besar ^[1].

Gunakan Dynamic Batching untuk Beban Kerja yang Tidak Merata

Ukuran batch tetap terdengar rapi di atas kertas. Dalam produksi, sering kali berantakan.

Lalu lintas berubah. Proses massal semalaman mungkin mendorong ribuan item per menit, sementara lalu lintas siang hari mungkin datang perlahan. Satu ukuran batch tetap tidak akan menangani kedua kasus dengan baik.

Dynamic batching mengatasinya dengan mengirim sebuah batch ketika salah satu dari ini terjadi:

• Batch mencapai ukuran yang ditetapkan

• Jendela tunggu yang ditetapkan berakhir

Penyiapan yang umum adalah sebuah ukuran batch maksimum ditambah sebuah waktu tunggu maksimum, seperti 5 detik ^[9][1]. Selama periode sibuk, batas ukuran tercapai berulang kali, yang menjaga throughput tetap tinggi. Selama periode lebih lambat, pengatur waktu bekerja sehingga item tidak sekadar menganggur di antrean.

Anda juga bisa mengemas beberapa item ke dalam satu prompt untuk menyebarkan overhead system-prompt ke lebih banyak pekerjaan ^[10].

Jalankan Panggilan API Secara Bersamaan di Dalam Setiap Fungsi

Setelah ukuran batch ditetapkan, langkah berikutnya adalah mengendalikan panggilan paralel di dalam setiap fungsi.

Sebagian besar penundaan biasanya berasal dari menunggu respons jaringan, bukan dari komputasi lokal. Jadi konkurensi async sering kali paling cocok. Kirim beberapa request sekaligus, lalu biarkan event loop menangani penantian.

Bagian pentingnya adalah batasnya. Gunakan semaphore untuk menjaga konkurensi dalam fungsi tetap terbatas. Kumpulan 5–10 request bersamaan adalah titik awal yang masuk akal ^[9][11]. Dorong jauh lebih tinggi dan Anda mungkin menabrak rate limit penyedia.

Dengan API LLM, batas utama sering kali adalah token per menit, bukan jumlah request mentah. Jadi lacak penggunaan token pada jendela 60 detik bergulir dan lakukan throttling sebelum penyedia melakukannya untuk Anda ^[10]. Pengaman itu penting karena satu worker jika tidak bisa menghabiskan memori atau memicu throttling untuk seluruh pipeline.

Gunakan penyiapan paling sederhana yang mencapai target throughput Anda tanpa meledakkan biaya retry.

Cara Menjaga Alur Kerja Batch Tetap Andal dan Teramati dalam Skala Besar

Mendapatkan ukuran batch dan konkurensi yang tepat baru setengah pekerjaan. Seiring volume tumbuh, bagian yang lebih sulit adalah menjaga pekerjaan tetap aman saat terjadi kegagalan dan mendeteksi masalah dengan cepat.

Tangani Kegagalan Sebagian Tanpa Memproses Ulang Semuanya

Satu catatan buruk tidak boleh mematikan seluruh batch. Jika satu input rusak atau satu request kehabisan waktu, kegagalan itu harus tetap terkurung.

Dalam praktik, logika pemrosesan setiap item membutuhkan penanganan error tersendiri. Tulis checkpoint atomik setelah setiap potongan, lalu lanjutkan dari checkpoint terakhir alih-alih memulai dari awal. Jika sebuah item masih gagal setelah 3 sampai 5 retry, kirimkan ke dead-letter queue (DLQ) untuk peninjauan manual alih-alih mencoba ulang selamanya. Gunakan exponential backoff sebelum setiap percobaan retry - misalnya, tunggu 1 detik, lalu 2 detik, lalu 4 detik - untuk menghindari menggempur endpoint API yang dibatasi rate ^[12][1][13].

Setelah pemulihan aman, lacak seberapa sering itu terjadi dan berapa biayanya.

Buat Setiap Pekerjaan Batch Bersifat Idempoten

Retry hanya aman ketika proses yang diulang menghasilkan hasil yang sama.

Itu bahkan lebih penting pada platform serverless, di mana error sementara sering memicu retry otomatis. Tanpa idempotensi, retry itu bisa menyebabkan penulisan ganda atau efek samping berulang lainnya.

Solusinya sederhana: bangun kunci idempotensi yang stabil seperti job_id:item_id alih-alih memakai timestamp runtime ^[14][15]. Lalu gunakan upsert agar memproses ulang sebuah item mengganti catatan yang ada alih-alih membuat catatan kedua. Untuk penyimpanan berbasis file seperti S3, pakai jalur output deterministik yang terikat pada parameter item pekerjaan sehingga proses ulang menimpa output yang sama alih-alih membuat duplikat ^[2][13].

Anda juga sebaiknya menetapkan queue visibility timeout Anda ke setidaknya 3x perkiraan waktu pemrosesan p99. Itu mencegah worker kedua mengambil pekerjaan yang masih berjalan di worker pertama ^[2][13].

Lacak Throughput, Latensi, dan Biaya Per Batch

Anda membutuhkan metrik yang menunjukkan apakah batching masih masuk akal di bawah beban. Di tingkat batch, lacak:

• Item yang diproses per menit

• Durasi batch rata-rata

• Jumlah retry per item

• Tingkat error

• Biaya per batch dalam USD, berdasarkan total token input dan output ^[12][1][2]

Setel peringatan jika tingkat keberhasilan turun di bawah 95% ^[1].

Coba ulang hanya item yang gagal. Gunakan skip-and-log hanya untuk pekerjaan pengayaan yang tidak kritis.

Cara Menekan Biaya dan Meningkatkan Performa untuk Beban Kerja Produksi

Identifikasi Pendorong Biaya Utama

Sebelum menekan biaya, Anda perlu melihat ke mana uang mengalir.

Dalam pipeline batch AI serverless, penggunaan token API AI biasanya menjadi pengeluaran terbesar. Mode batch membantu di dua sisi: menekan pengeluaran token dan menurunkan overhead request. Dalam praktik, API batch menawarkan biaya token sekitar 50% lebih rendah daripada panggilan sinkron ^[5][18].

Setelah token, durasi komputasi serverless sering menjadi pendorong besar berikutnya, terutama untuk pekerjaan video dan gambar yang ditagih berdasarkan runtime GPU ^[17]. Penyimpanan dan transfer data juga bisa menyelinap naik pada Anda. Jika Anda memindahkan file besar antarwilayah, biaya itu menumpuk cepat. Dan dalam alur kerja berisiko tinggi, peninjauan manusia untuk output berkeyakinan rendah bisa berubah menjadi pusat biaya besar tersendiri ^[16].

Pola biaya juga berubah menurut modalitas. Beban kerja teks berbasis token, jadi biasanya lebih mudah diprediksi. Pembuatan video bekerja berbeda: Anda ditagih per detik output, yang berarti panjang klip berpengaruh langsung pada pengeluaran. Klip 10 detik jelas lebih mahal daripada klip 5 detik. Itulah mengapa penyetelan eksekusi sangat penting di sini.

Setel Memori, Timeout, Ukuran Paket, dan Pola Penulisan

Banyak penghematan terbaik berasal dari penyetelan eksekusi biasa, bukan trik mewah.

Setel timeout klien ke 60 detik atau lebih. Alirkan input dan output JSONL alih-alih memuat batch besar ke memori sekaligus. Perubahan itu saja dapat mengurangi tekanan memori dan membuat pekerjaan batch tidak mudah rapuh. Gunakan kuantisasi hanya ketika VRAM menjadi penghambat ^[5][18].

Ini adalah penyesuaian kecil, tetapi bisa memangkas pemborosan tanpa mengubah pekerjaan itu sendiri.

Setelah penggunaan memori dan I/O dalam kondisi cukup baik, tuas besar berikutnya adalah pemilihan model.

Sesuaikan Pilihan Model dan Strategi Batch dengan Tujuan Bisnis

Tuas biaya terbesar adalah memilih model yang tepat untuk pekerjaan.

Model garis depan seperti GPT-5 atau Claude Opus masuk akal untuk penalaran kompleks. Tetapi untuk klasifikasi atau ekstraksi, mereka bisa berlebihan. Model yang lebih ringan sering kali sudah cukup. Dalam banyak pipeline, memakai model yang lebih ringan untuk sekitar 80% tugas dan menyimpan model yang lebih berat untuk 20% sisanya dapat memangkas biaya rata-rata sebesar 70% hingga 90% ^[18][19].

Pembagian sederhana sering kali bekerja baik:

• Gunakan model yang lebih ringan untuk ekstraksi dan klasifikasi

• Cadangkan model yang lebih berat untuk penalaran

• Skalakan ukuran batch berdasarkan kompleksitas tugas

Jika Anda perlu merutekan jenis pekerjaan berbeda ke model berbeda, APIMart memberi Anda satu API di lebih dari 500 model.

Sebelum menskalakan, jalankan pilot 10 sampai 50 item untuk mengukur biaya per item. Itu memberi Anda gambaran bersih tentang perkiraan biaya setiap pekerjaan sebelum volume meningkat.

Kesimpulan: Cara Paling Sederhana Meningkatkan Alur Kerja AI Batch

Setelah pipeline, ukuran batch, pemeriksaan keandalan, dan pengaman biaya Anda ditetapkan, penskalaan menjadi jauh lebih sederhana. Paralelisme fan-out, batch berukuran tepat, dan penanganan retry yang ketat adalah tuas utama yang mengubah pekerjaan lambat dan berurutan menjadi sesuatu yang bisa Anda jalankan di produksi.

Jaga kegagalan tetap terkurung. Buat retry idempoten. Rekonsiliasi hasil yang diharapkan dengan output aktual. Itulah bagian yang menjaga sistem agar tidak melenceng ketika sesuatu rusak. Setelah itu, biaya biasanya menjadi batas berikutnya.

Lacak pengeluaran dalam USD per proses batch agar Anda bisa mengaitkan biaya kembali ke setiap pekerjaan dan menemukan outlier yang mahal ^[2]. Mulai beban kerja baru dengan pilot 10 sampai 50 item, verifikasi biaya per item Anda, lalu skalakan setelah perhitungannya masuk akal ^[1][3].

Untuk sebagian besar tugas, model yang lebih kecil sebaiknya melakukan pekerjaan berat. Simpan model yang lebih besar untuk pekerjaan pembuatan yang lebih kompleks. Dan jika satu pipeline batch berjalan di beberapa modalitas dan jenis model, satu lapisan seperti APIMart dapat menjaga perutean tetap sederhana melalui satu API. Kombinasi itulah yang membuat alur kerja AI batch lebih dapat diprediksi pada skala produksi.

FAQ

Kapan saya sebaiknya memakai pemrosesan batch alih-alih panggilan AI real-time?

Gunakan pemrosesan batch untuk pekerjaan yang tidak berada di jalur kritis pengguna dan bisa menunggu dari beberapa menit hingga beberapa jam.

Ini cocok untuk pekerjaan offline seperti:

• pengayaan data berskala besar

• analisis dokumen

• pembuatan indeks vektor

• pelaporan terjadwal

Gunakan endpoint real-time hanya ketika seseorang aktif menunggu di sisi lain, seperti pada obrolan interaktif atau tanya jawab langsung.

Bagaimana cara memilih ukuran batch yang tepat untuk beban kerja saya?

Untuk batching di tingkat aplikasi, mulai dengan 50 sampai 100 item. Dalam banyak kasus, titik idealnya berada di antara 100 dan 500. Jika Anda memakai API batch native penyedia, Anda bisa jauh lebih besar - kadang hingga 50.000 request dalam satu batch.

Tujuannya adalah menemukan ukuran batch yang memberi Anda trade-off yang baik antara efisiensi dan isolasi kegagalan. Anda ingin cukup kecil agar retry tidak terlalu mahal, tetapi cukup besar untuk memangkas overhead orkestrasi.

Untuk inferensi dinamis, setel ukuran batch berdasarkan batas VRAM dan target latensi Anda.

Bagaimana cara mencegah pemrosesan ganda selama retry?

Buat pipeline Anda idempoten agar memproses item yang sama lagi menghasilkan hasil yang sama setiap kali.

Gunakan kunci idempotensi yang stabil dan tidak berubah. Sebelum menjalankan pekerjaan apa pun, periksa apakah kunci itu sudah diklaim atau diproses. Lalu gunakan upsert ditambah batasan unik untuk mencegah penulisan ganda.

Menjaga registri ID dokumen yang telah diproses juga membantu. Itu memberi Anda cara sederhana untuk melewati item yang sudah selesai selama retry atau melanjutkan proses.