Tagihan LLM API Meledak, Bagaimana? Delapan Cara Hemat Token yang Terbukti Efektif

Pukul dua dini hari, seorang developer independen menerima surel pemberitahuan pemakaian dari Anthropic. Sebuah fungsi kecil yang ia tayangkan minggu lalu—otomatis meringkas PDF yang diunggah pengguna—menghabiskan empat ratus tiga puluh dolar dalam tujuh hari ini. Angka yang ia perkirakan adalah tiga puluh.

Di mana masalahnya? Setiap kali memanggil ia menjejalkan seluruh dokumen ke dalam prompt, sementara pengguna suka menanyakan lima-enam pertanyaan beruntun atas dokumen yang sama. Dua puluh ribu token yang sama, dikirim berulang enam kali.

Logika biaya model API sangat berbeda dari sumber daya cloud. Anda tak bisa "mematikan mesin", karena tiap panggilan adalah peristiwa mandiri; Anda juga sulit "menurunkan spesifikasi", karena mengganti model kecil bisa langsung menghancurkan pengalaman produk. Tulisan ini merangkum cara yang benar-benar efektif, dan yang benar-benar sudah saya atau tim di sekitar saya validasi.

Satu, Ukur Dulu, Baru Optimalkan

Ini terdengar seperti omong kosong, tetapi sembilan dari sepuluh tim saat mulai berhemat sama sekali tak tahu uangnya habis di fungsi mana.

Minimal Anda harus mencatat tiga hal: jumlah token masukan tiap panggilan, jumlah token keluaran, dan nama fungsi terkait. Dengan tiga kolom ini, Anda baru bisa menghitung angka yang bisa ditindaklanjuti seperti "biaya rata-rata tiap panggilan fungsi peringkasan". Memakai alat observabilitas seperti Helicone atau Langfuse bisa menghemat kerja menulis sendiri.

Saya melihat terlalu banyak tim langsung lompat ke optimasi, akhirnya menghabiskan tiga hari mengoptimalkan sebuah fungsi yang hanya menyumbang 4% total biaya.

Dua, Cache Prompt Adalah Jurus dengan Imbal Hasil Tertinggi

Inilah fungsi yang paling diremehkan saat ini. Vendor model utama sama-sama menyediakan suatu bentuk cache prompt—ketika permintaan Anda punya prefiks bersama yang panjang (prompt sistem, isi dokumen, contoh), panggilan sesudah yang pertama bisa memakai ulangnya dengan harga diskon besar.

Kembali ke kasus pembuka: jika ia menaruh isi PDF pada prefiks tetap prompt dan mengaktifkan cache, biaya tanya jawab lanjutan atas dokumen yang sama bisa turun satu orde besaran. Ini perubahan struktural, bukan menghemat sedikit-sedikit.

Catatan praktisnya: cache punya masa berlaku, dan menuntut prefiks yang sama persis. Taruh hal yang berubah-ubah (pertanyaan pengguna, cap waktu, ID acak) di bagian paling akhir prompt; urutan ini menentukan cache bisa cocok atau tidak.

Tiga, Penjenjangan Model: Tak Semua Hal Butuh Model Andalan

Pemborosan umum adalah semua tugas menghantam model termahal yang sama. Sebenarnya sebagian besar kerja bisa dibagi tiga jenjang:

• Klasifikasi, ekstraksi, konversi format: model kecil sudah lebih dari cukup, biayanya mungkin hanya seperdua puluh model andalan
• Tanya jawab umum, peringkasan, penulisan ulang: mutu model menengah sudah sangat mendekati, dan bedanya tak terasa bagi kebanyakan pengguna
• Penalaran rumit, pembuatan kode, perencanaan banyak langkah: baru di sinilah pantas memakai model andalan

Caranya, tambahkan satu logika routing di lapis aplikasi, mengarahkan sesuai jenis tugas. Layanan seperti OpenRouter memungkinkan Anda beralih antarmodel dengan satu set kunci API, dan implementasinya tak akan terlalu menyakitkan.

Empat, Rampingkan Prompt

Banyak prompt sistem tim menumpuk seiring waktu—di sini ditambah satu aturan, di sana ditambal satu pengecualian, setengah tahun kemudian jadi monster dua ribu token, dan tiap panggilan harus membayar biaya ini.

Cara praktisnya: cetak prompt sistem lalu telaah butir demi butir, tanyakan tiap butir "apakah keluaran memburuk jika ini dihapus". Saya pernah melakukannya, memangkas 40% isinya, dan mutu keluaran tak berbeda secara terukur. Contoh few-shot (few-shot examples) terutama patut diperiksa; sering kali tiga contoh dan delapan contoh efeknya mirip.

Lima, Panjang Keluaran Harus Dikendalikan Aktif

Token masukan biasanya lebih murah dari keluaran, tetapi biaya keluaran mudah lepas kendali—model suka bicara banyak. Setel batas max_tokens, dan minta secara eksplisit format serta panjang keluaran dalam prompt ("jawab dengan tiga poin, tiap poin tak lebih dari tiga puluh kata"); efek dua jurus ini digabungkan lebih besar dari perkiraan.

Pengingat khusus untuk model penalaran: proses berpikirnya juga dihitung token, dan kerap beberapa kali lebih panjang dari jawaban akhir. Memakai model penalaran untuk tugas sederhana adalah salah satu kesalahan termahal yang pernah saya lihat.

Enam, Pemrosesan Batch Bisa Separuh Harga

Jika tugas Anda tak butuh respons real-time—misalnya memproses sekumpulan dokumen tiap hari, menghasilkan laporan, klasifikasi batch—vendor utama sama-sama menyediakan API batch, dengan harga biasanya separuh panggilan real-time, dengan konsekuensi waktu tunggu memanjang hingga beberapa jam.

Jurus ini cocok untuk lebih banyak skenario daripada yang dikira kebanyakan orang. Tanyakan pada diri sendiri: apakah fungsi ini benar-benar butuh balasan dalam tiga detik? Atau pengguna bisa menerima "besok pagi baru jadi"?

Tujuh, Tambahkan Satu Lapis Cache Semantik

Selain cache prompt yang disediakan vendor, Anda juga bisa membuat cache semantik di lapis aplikasi sendiri: vektorkan pertanyaan, dan jika pertanyaan baru cukup mirip dengan pertanyaan lampau, langsung kembalikan jawaban sebelumnya.

Ini terutama efektif di skenario seperti layanan pelanggan, FAQ, dan tanya jawab produk, karena pertanyaan pengguna sangat sering berulang. Kekurangannya harus memelihara basis data vektor, dan ambang kemiripan yang disetel terlalu longgar akan mengembalikan jawaban yang salah, sehingga perlu penyetelan cermat.

Delapan, Setel Batas Keras, Bukan Sekadar Peringatan

Masalah peringatan adalah ia mengandaikan ada yang mengawasi. Loop lepas kendali pukul tiga dini hari tak akan menunggu Anda bangun.

Perlindungan paling efektif adalah menyetel batas keras di lapis aplikasi: batas jumlah panggilan harian per pengguna, batas token per permintaan, dan batas pengeluaran per jam secara keseluruhan; jika melampaui langsung ditolak. Ini memengaruhi pengalaman sedikit pengguna berat, tetapi dibanding tagihan meledak, biaya ini sangat sepadan.

Tiga Jebakan yang Sering Dialami Tim di Indonesia

Jebakan pertama: intuisi menghitung token untuk teks non-Latin bisa keliru. Efisiensi token aksara tertentu lebih buruk dari bahasa Inggris; isi yang sama versinya bisa bertambah tiga hingga lima puluh persen token. Jika produk Anda melayani pengguna banyak bahasa sekaligus, struktur biayanya akan berbeda jelas, jadi saat memperkirakan hitung terpisah.

Jebakan kedua: melupakan kurs dan biaya administrasi. Model API semuanya dalam dolar AS, ditambah biaya administrasi valuta asing kartu kredit (biasanya 1,5%) dan selisih kurs, biaya nyatanya lebih tinggi dari angka di tagihan. Saat menyusun anggaran ingat kalikan dengan satu koefisien.

Jebakan ketiga: lingkungan uji tak diberi batas. Saya melihat lebih dari sekali, lingkungan produksi dijaga sangat ketat, tetapi lingkungan pengembangan tanpa batasan apa pun, akhirnya sebuah skrip uji berjalan dalam loop dan menghabiskan angka lima digit. Pemakaian lingkungan pengembangan juga harus dikelola.

Untuk memahami pengelolaan biaya sumber daya cloud itu sendiri, bisa lihat Mengapa Tagihan Cloud di Era AI Lepas Kendali; logika keduanya berbeda tetapi perlu dikelola bersama.

Ringkasan dan Ulasan TheAI Academy

Soal hemat token ada satu hal yang sangat berlawanan intuisi: cara paling efektif biasanya bukan mengganti model murah, melainkan "jangan mengirim hal yang sama berulang-ulang".

Cache, batch, kendali panjang keluaran—tak satu pun dari tiga jurus ini mengorbankan mutu, semuanya menghapus pemborosan murni. Sementara mengganti model kecil meski harga satuannya murah, bisa karena mutu keluaran menurun membuat pengguna bertanya ulang tiga kali, sehingga biaya total malah lebih mahal.

Ulasan: hapus dulu pemborosan, baru pertimbangkan penurunan jenjang. Urutan yang terbalik akan membuat Anda menukar pengalaman produk yang lebih buruk dengan tagihan yang lebih mahal.

Saran konkret bagi developer di Indonesia: minggu ini lengkapi dulu pencatatan pemakaian (tiga kolom masukan, keluaran, nama fungsi sudah cukup), jalankan seminggu lalu lihat datanya. Anda kira-kira akan menemukan delapan puluh persen biaya terpusat di satu-dua fungsi, dan satu-dua fungsi itu biasanya punya ruang optimasi yang sangat jelas. Mulai dari situ, sepuluh kali lebih efektif daripada optimasi menyeluruh.

Alat terkait bisa ditemukan di alat developer AI, dan Anda juga bisa lihat template prompt untuk belajar menulis prompt yang lebih ringkas.