Tagihan LLM punya pola yang khas. Bulan pertama beberapa puluh dolar dan semua orang senang. Bulan keempat angkanya sepuluh kali lipat, dan tidak ada yang bisa menjelaskan kenapa.
Penyebabnya hampir tidak pernah lonjakan jumlah pengguna. Hampir selalu, penyebabnya adalah konteks yang diam-diam membengkak.
Anda membayar per token, dan token dihitung dua arah: yang masuk dan yang keluar. Token keluar biasanya jauh lebih mahal per satuan — sering beberapa kali lipat.
Tapi tagihan besar jarang datang dari jawaban yang panjang. Ia datang dari token masuk, karena token masuk punya kebiasaan bertambah tanpa ada yang memutuskan menambahnya.
Perhatikan bagaimana ini terjadi. Anda mulai dengan prompt sistem sepanjang 200 token. Lalu seseorang menambahkan lima contoh untuk memperbaiki kualitas — sekarang 900. Lalu fitur riwayat percakapan masuk, dan setiap permintaan membawa sepuluh pesan sebelumnya. Lalu pencarian dokumen ditambahkan, menyuntikkan lima potongan teks panjang setiap kali.
Tidak ada satu pun keputusan itu yang salah. Tapi permintaan yang dulu 200 token kini 8.000 — dan Anda membayar seluruh 8.000 itu setiap kali, termasuk untuk pertanyaan yang jawabannya satu kata.
Sebelum mengoptimasi apa pun, catat tiga angka untuk setiap permintaan: jumlah token masuk, jumlah token keluar, dan jenis permintaannya.
Simpan ke tabel biasa. Tidak perlu perkakas khusus.
Setelah seminggu, urutkan berdasarkan total token dikali jumlah panggilan. Yang hampir selalu muncul: satu atau dua jenis permintaan menyumbang sebagian besar biaya, dan biasanya bukan yang Anda duga. Tanpa data ini, Anda akan menghabiskan waktu mengoptimasi jalur yang dipanggil sepuluh kali sehari sementara jalur yang dipanggil sepuluh ribu kali dibiarkan.
Ini penghematan terbesar dengan usaha paling kecil, dan paling sering terlewat.
Sebagian besar penyedia menawarkan mekanisme cache untuk bagian prompt yang berulang. Kalau prompt sistem dan contoh-contoh Anda sama persis di setiap permintaan, bagian itu bisa dihitung dengan tarif yang jauh lebih murah.
Syaratnya satu, dan syarat inilah yang sering merusaknya: bagian yang di-cache harus identik dan berada di awal. Menyisipkan tanggal hari ini atau nama pengguna di dalam prompt sistem membatalkan cache untuk setiap permintaan.
Susun prompt Anda dengan urutan tetap: bagian statis dulu, bagian dinamis belakangan. Perubahan struktur sepele ini sering memangkas tagihan secara signifikan tanpa mengubah satu pun keluaran.
Banyak sistem memakai satu model untuk segalanya, biasanya yang terbesar, karena itu yang dipilih saat prototipe dan tidak pernah ditinjau ulang.
Padahal beban kerja Anda hampir pasti bercampur. Mengklasifikasikan maksud pertanyaan, mengekstrak tanggal dari teks, memutuskan apakah pesan perlu eskalasi — semua itu tugas yang model kecil kerjakan sama baiknya dengan harga jauh lebih rendah.
Pendekatan yang praktis: kirim ke model kecil dulu, dan naikkan ke model besar hanya kalau model kecil menandai dirinya tidak yakin, atau kalau hasilnya gagal validasi.
Untuk mengetahui berapa besar yang bisa dihemat, jalankan keduanya berdampingan selama beberapa hari dan bandingkan hasilnya pada permintaan nyata. Ini pekerjaan setengah hari yang sering mengubah struktur biaya secara permanen.
Sistem berbasis pencarian dokumen cenderung mengirim terlalu banyak. Mengambil sepuluh potongan teks terasa lebih aman daripada tiga.
Uji asumsi itu. Turunkan jumlahnya, ukur kualitas jawabannya dengan kumpulan pertanyaan yang sama. Sering kali tiga potongan yang relevan mengalahkan sepuluh potongan yang sebagian besar tidak nyambung — bukan hanya lebih murah, tapi lebih akurat, karena konteks yang tidak relevan justru mengaburkan jawaban.
Hal yang sama berlaku untuk riwayat percakapan. Sepuluh pesan terakhir jarang diperlukan. Rangkum yang lama, kirim yang baru.
Tetapkan batas maksimum token keluar, dan tetapkan yang masuk akal — bukan angka besar “untuk berjaga-jaga”.
Kalau jawaban yang Anda harapkan adalah satu kalimat, batas 4.000 token bukan jaring pengaman, melainkan undangan. Model akan mengisi ruang yang Anda beri.
Untuk keluaran terstruktur, minta format yang ringkas. JSON dengan nama kunci pendek lebih murah daripada prosa yang menjelaskan hal yang sama.
Optimasi biaya punya batas yang sehat.
Kalau menurunkan ke model kecil membuat tim Anda menghabiskan waktu memperbaiki keluaran yang salah, Anda tidak menghemat apa pun — Anda memindahkan biaya dari tagihan API ke gaji, di mana ia lebih mahal dan lebih sulit dilihat.
Kalau sebuah alur berhubungan langsung dengan pendapatan, pakai model terbaik dan berhenti memikirkannya. Hemat di tempat lain.
Dan kalau Anda masih mencari tahu apakah fitur ini berguna sama sekali, jangan optimasi dulu. Optimasi prematur pada sesuatu yang mungkin akan dibuang adalah pemborosan waktu yang jauh lebih mahal daripada tagihannya.
Pasang pencatatan token lebih dulu. Jalankan seminggu. Susun ulang prompt agar cache bisa bekerja. Turunkan jalur yang paling sering dipanggil ke model lebih kecil dan ukur kualitasnya. Baru setelah itu, sentuh jumlah potongan dokumen dan batas keluaran.
Empat langkah pertama biasanya sudah cukup. Yang kelima adalah penyempurnaan.
Tarif, nama model, dan mekanisme caching berbeda antar penyedia dan berubah cukup sering. Prinsip di atas berlaku umum, tapi angka dan nama fitur sebaiknya Anda periksa langsung di dokumentasi penyedia yang Anda pakai sebelum mengambil keputusan.
