Mengendalikan Biaya LLM: Routing per Tugas, Batasi per Hari

Mengendalikan Biaya LLM: Routing per Tugas, Batasi per Hari

Tagihan LLM pertama mengajarkan pelajaran yang sama ke kebanyakan tim: biaya token terasa gratis per request, lalu jadi pos biaya terbesar dalam satu kuartal. Bukan satu fitur mahal yang biasanya jadi penyebabnya. Ini sistem yang diam-diam mengirim setiap request — sepele atau tidak — ke model kelas atas yang sama, karena itu default bawaan SDK dan tidak ada yang meninjaunya ulang setelah rilis.

Mengendalikan biaya di sistem LLM bukan masalah finance yang diselesaikan belakangan. Itu keputusan arsitektur yang diambil sebelum request pertama dikirim.

Routing per tugas, bukan default begitu saja

Tidak semua panggilan LLM di dalam sistem butuh model yang sama. Bayangkan seperti klinik: keluhan ringan cukup ditangani perawat, kasus rumit baru naik ke dokter spesialis. Sistem produksi juga begitu — beberapa jenis panggilan per giliran pengguna, tiap jenis punya kebutuhan berbeda:

• Judging dan scoring — apakah potongan teks ini relevan, apakah kutipan ini benar-benar ada di sumber, apakah klasifikasi ini masih valid — adalah tugas sempit dan terstruktur. Model membaca input pendek, mengembalikan output kecil yang terbatas: label, angka confidence, ya/tidak. Model cepat dan murah menangani ini dengan andal. Tugasnya tidak butuh penalaran luas yang jadi alasan model flagship dihargai mahal.
• Enrichment dan extraction — menarik field terstruktur dari teks tidak terstruktur, menyusun rencana riset singkat — sama-sama terbatas cakupannya. Model murah, prompt ketat, temperature rendah — setelan seberapa liar model boleh berimprovisasi — sudah cukup.
• Generasi jawaban akhir — respons yang benar-benar dibaca pengguna — adalah tempat model terkuat dipakai. Di sinilah kualitas output benar-benar terlihat.

Di asisten klasifikasi regulasi yang saya bangun, langkah relevance-judging yang mengecek apakah kode yang diusulkan memang cocok untuk sebuah bisnis berjalan di model terpisah yang lebih murah dibanding model yang menyusun penjelasan akhir. Judge ini dipanggil berkali-kali per giliran — sekali per kandidat, kadang puluhan kali per percakapan — sementara jawaban akhir dipanggil sekali.

Merutekan panggilan bervolume tinggi dan bertugas sempit ke model murah, lalu menyisakan model mahal hanya untuk langkah generasi yang memang membutuhkannya, memangkas drastis biaya efektif per giliran. Kualitas jawaban tidak turun, karena tugas judging memang dari awal tidak pernah butuh penalaran level flagship.

Batas biaya harian, bukan cuma batas per request

Rate limiting per request menghentikan penyalahgunaan dari satu klien yang membombardir endpoint sistem. Itu tidak menghentikan traffic normal dan sah dalam sehari diam-diam melampaui apa yang sudah dianggarkan. Batas biaya harian — plafon keras berapa banyak panggilan model berbayar yang boleh dilakukan sistem per hari, diberlakukan per pengguna maupun secara global — adalah pengaman yang tidak bisa diberikan rate limiter.

Versi praktisnya menimbang plafon berdasarkan ukuran request, bukan menghitung setiap request sama rata. Prompt yang lebih panjang memakai "unit" lebih banyak dibanding yang pendek. Kontribusi tiap request tetap dibatasi, supaya sejumlah kecil request berukuran besar tidak bisa diam-diam menghabiskan seluruh budget hari itu.

Begitu seorang pengguna atau sistem secara keseluruhan menyentuh plafon, sistem turun kelas dengan tertib: jatuh ke jawaban non-LLM atau pesan "sedang penuh kapasitas" yang jujur. Bukan error begitu saja, dan bukan terus mengeluarkan biaya melewati batas yang sudah ditetapkan.

Deadline per giliran melindungi budget dari satu panggilan yang lambat

Plafon harian mengendalikan total pengeluaran. Deadline per giliran mengendalikan berapa besar biaya waktu — dan secara tidak langsung biaya uang — dari satu percakapan. Tetapkan deadline wall-clock (waktu nyata yang dirasakan pengguna) untuk seluruh giliran, dan batasi setiap panggilan model di dalamnya sesuai sisa waktu yang ada.

Ketika deadline tercapai, jangan lakukan satu panggilan lagi dengan harapan selesai tepat waktu. Berhenti, dan langsung kembalikan fallback-nya. Panggilan model yang lambat dan tetap melewati deadline lebih buruk daripada tidak memanggil sama sekali — biayanya sudah keluar untuk respons yang tidak sempat dipakai penggunanya.

Ini juga melindungi dari satu kegagalan spesifik: agentic loop yang terus memanggil tool dan mem-prompt ulang model, giliran demi giliran. Tanpa batas ronde yang keras dan deadline, query yang sulit bisa berputar jadi selusin panggilan mahal yang mengejar jawaban yang memang tidak akan pernah selesai dengan bersih. Deadline memaksa berhenti secara jujur sebagai gantinya.

Ukur biaya per pertanyaan terjawab, bukan cuma total pengeluaran

Total pengeluaran bulanan nyaris tidak memberi tahu apa pun yang bisa ditindaklanjuti. Yang Anda butuhkan adalah biaya per pertanyaan terjawab, dipecah berdasarkan jalur mana yang menjawabnya: berapa giliran yang ditangani model mahal, berapa oleh model murah, berapa yang jatuh ke jawaban non-LLM deterministik, berapa yang kena plafon budget dan mendapat penolakan yang jujur.

Rincian itu memberi tahu Anda apakah routing Anda benar-benar berjalan, atau semuanya diam-diam tetap lewat jalur mahal terlepas dari apa yang Anda konfigurasikan.

Kenapa satu-model-untuk-semuanya menghabiskan uang

Naluri untuk merutekan semuanya lewat model terbaik Anda memang bisa dipahami: tidak ada yang mau jadi orang yang mengirim jawaban lebih buruk demi menghemat beberapa sen. Tapi hitungannya tidak sesederhana "beberapa sen." Sistem agentic bisa melakukan lima, sepuluh, atau lebih panggilan model dalam satu giliran pengguna: search, judge, judge lagi, compose, verify.

Kalau setiap panggilan itu memakai harga model kelas atas Anda, biaya per pertanyaan pengguna berlipat sesuai jumlah panggilan internal, bukan sesuai jumlah pertanyaan yang diajukan. Rutekan sesuai kebutuhan tugasnya. Batasi berapa yang Anda mau keluarkan per hari. Pasang jam di setiap giliran. Itulah bedanya fitur LLM yang bisa scale dengan yang dicabut begitu ada orang membaca invoice-nya.

Untuk kerja retrieval yang memasok panggilan model ini, lihat RAG dijelaskan untuk sistem bisnis, dan untuk bagaimana disiplin budget ini berkaitan dengan kepercayaan jawaban, lihat guardrail melawan halusinasi.