Mengendalikan Biaya API Model Bahasa: Caching, Pemilihan Model, dan Anggaran Token

Produk yang membangun fitur di atas API model bahasa sering terkejut melihat tagihan bulan kedua. Penyebabnya jarang harga per token yang tiba-tiba naik, melainkan pola pemakaian yang tidak pernah diukur sejak awal.

Memahami dari mana biaya sebenarnya datang

Biaya dihitung dari token masukan dan token keluaran, dengan tarif keluaran umumnya beberapa kali lipat lebih mahal. Namun pada banyak aplikasi, justru token masukan yang mendominasi tagihan.

Alasannya terletak pada pola percakapan. Setiap giliran mengirim ulang seluruh riwayat sebelumnya, sehingga percakapan sepuluh giliran mengirim pesan pertama sebanyak sepuluh kali. Instruksi sistem yang panjang ikut terkirim pada setiap permintaan, dan biayanya berlipat sebanyak jumlah permintaan.

Caching prompt dan syarat pemanfaatannya

Sebagian besar penyedia kini menawarkan caching untuk bagian awal prompt yang berulang, dengan tarif jauh lebih murah untuk bagian yang tercache. Penghematannya besar, tetapi hanya berlaku jika awalan prompt benar-benar identik byte demi byte.

Konsekuensi perancangannya konkret: tempatkan bagian yang stabil — instruksi sistem, contoh, dokumen referensi — di awal, dan bagian yang berubah di akhir. Menyisipkan stempel waktu atau nama pengguna di awal prompt akan membatalkan seluruh cache tanpa disadari.

Tidak semua tugas memerlukan model terbesar

Penghematan terbesar biasanya datang dari pemilihan model yang tepat per tugas. Klasifikasi, ekstraksi medan terstruktur, dan pemeriksaan format berjalan baik pada model kecil dengan biaya sepersekian.

Pola bertingkat bekerja baik dalam praktik: jalankan model kecil lebih dulu, dan naikkan ke model besar hanya ketika model kecil menyatakan ketidakpastian atau hasilnya gagal validasi. Sebagian besar permintaan selesai di tingkat pertama.

Memangkas konteks dengan sengaja

Mengirim seluruh riwayat percakapan adalah jalan termudah sekaligus termahal. Alternatifnya adalah menyimpan ringkasan bergulir: pertahankan beberapa giliran terakhir secara utuh, dan gantikan yang lebih lama dengan ringkasan singkat.

Batasi juga panjang keluaran secara eksplisit. Model yang tidak diberi batas cenderung menjawab panjang, dan setiap token keluaran dihitung dengan tarif tertinggi.

Mengukur per fitur, bukan per bulan

Tagihan bulanan tidak memberi tahu apa pun yang dapat ditindaklanjuti. Catat jumlah token dan biaya pada setiap panggilan, disertai penanda fitur yang memicunya.

Hampir selalu ditemukan bahwa satu atau dua fitur menghabiskan sebagian besar anggaran, dan kerap fitur tersebut bukan yang paling bernilai bagi pengguna. Angka itulah yang mengubah pengendalian biaya dari tebakan menjadi keputusan.