Biaya LLM: Pilih Model per Tugas dan Batasi Anggaran

Biaya LLM—model bahasa yang menghasilkan jawaban AI—perlu dihitung per pekerjaan, bukan hanya dari tagihan bulanan. Pilih model sesuai tugasnya, uji kualitas hasil, lalu batasi anggaran dan waktu tunggu. Model lebih murah bisa menghemat tugas tertentu, tetapi kesesuaiannya harus dibuktikan dengan contoh data bisnis Anda.

Batas biaya perlu menjadi bagian rancangan sistem sebelum permintaan pertama dikirim. Tim perlu menentukan pilihan model, batas penggunaan, dan perilaku aplikasi ketika anggaran habis.

Pemilihan model per tugas, bukan bawaan begitu saja

Satu giliran percakapan dapat memerlukan beberapa panggilan LLM dengan tugas berbeda. Pilih model untuk setiap jenis pekerjaan, lalu uji apakah hasilnya memenuhi kebutuhan:

• Penilaian dan pemberian skor — 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 masukan pendek, mengembalikan keluaran kecil yang terbatas: label, angka tingkat keyakinan, ya/tidak. Model lebih murah layak diuji untuk tugas sempit ini, tetapi klasifikasi dan penilaian sumber tetap bisa salah. Bandingkan hasilnya dengan kasus berlabel, terutama keputusan yang berisiko.
• Pelengkapan dan ekstraksi data — menarik kolom terstruktur dari teks tidak terstruktur, menyusun rencana riset singkat — sama-sama terbatas cakupannya. Model murah, prompt ketat, temperature rendah — setelan variasi keluaran — dapat menjadi awal pengujian. Temperature rendah tidak menjamin hasil benar.
• Generasi jawaban akhir — respons yang benar-benar dibaca pengguna — adalah tempat model terkuat dipakai. Di sinilah kualitas keluaran benar-benar terlihat.

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

Pada sistem tersebut, pemisahan tugas bervolume tinggi ke model yang lebih murah membantu menekan biaya per giliran. Hasil ini perlu diuji untuk setiap tugas. Ukur kesalahan pada tahap penilaian dan jawaban akhir setelah model diganti.

Batas biaya harian, bukan hanya batas per permintaan

Pembatasan laju permintaan (rate limiting) menghentikan penyalahgunaan dari satu klien yang membombardir endpoint sistem. Itu tidak menghentikan lalu lintas permintaan 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 pembatas laju permintaan.

Versi praktisnya menimbang kuota menurut ukuran permintaan: prompt panjang memakai lebih banyak unit. Namun, kuota pekerjaan berbeda dari plafon biaya. Cadangkan perkiraan biaya uang, batasi token keluaran, lalu cocokkan pemakaian sebenarnya setelah panggilan selesai. Membatasi unit yang dicatat untuk permintaan besar tidak membatasi tagihan penyedia.

Ketika pengguna atau seluruh sistem mencapai batas harian, hentikan panggilan berbayar sesuai kebijakan. Aplikasi dapat memberi jawaban berbasis aturan atau pesan bahwa kapasitas sedang penuh. Jelaskan keterbatasannya agar pengguna tidak menganggap hasil pengganti setara dengan analisis lengkap.

Batas waktu per giliran melindungi anggaran dari satu panggilan yang lambat

Plafon harian mengendalikan total pengeluaran. Batas waktu per giliran mengendalikan berapa besar biaya waktu — dan secara tidak langsung biaya uang — dari satu percakapan. Tetapkan batas waktu berdasarkan durasi yang berlalu untuk seluruh giliran, dan batasi setiap panggilan model di dalamnya sesuai sisa waktu yang ada.

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

Batas jumlah putaran dan waktu juga membatasi agen yang berulang kali memakai alat lalu memanggil model kembali. Tanpa batas tersebut, satu pertanyaan sulit dapat menghabiskan banyak panggilan tanpa menghasilkan jawaban yang layak.

Ukur biaya per pertanyaan terjawab, bukan hanya total pengeluaran

Total pengeluaran bulanan belum memberi rincian 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 anggaran dan mendapat penolakan yang jujur.

Rincian biaya menunjukkan apakah pembagian model benar-benar berjalan. Tim dapat mendeteksi tugas yang masih memakai model mahal meskipun konfigurasi mengarahkannya ke jalur lain.

Mengapa 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. Namun hitungannya tidak sesederhana "beberapa sen." Sistem agentic bisa melakukan lima, sepuluh, atau lebih panggilan model dalam satu giliran pengguna: mencari, menilai, menilai ulang, menyusun, dan memverifikasi.

Biaya per pertanyaan mengikuti jumlah panggilan internal, bukan hanya jumlah pertanyaan pengguna. Pilih model menurut tugas, tetapkan anggaran harian, dan batasi waktu setiap giliran. Ukur kualitas serta biaya bersama agar fitur tetap berguna saat penggunaan bertambah.

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