← Blog · Engineering · 10 min read
Tagihan LLM bisa meledak diam-diam. Pelajari teknik nyata untuk memangkas biaya token 40-70% tanpa mengorbankan kualitas pengalaman pengguna.
A 30-minute scoping call. We listen, ask three questions, tell you if we can help.
Book a callTagihan dari penyedia LLM jarang meledak dalam satu malam. Ia merangkak naik. Bulan pertama setelah peluncuran fitur AI, biayanya terasa wajar—beberapa juta Rupiah, masih di bawah radar finance. Tiga bulan kemudian, ketika trafik naik dan tim menambahkan satu-dua fitur baru, angka di dashboard penyedia tiba-tiba menyentuh ratusan juta per bulan, dan tidak ada yang bisa menjelaskan persis ke mana uang itu pergi. Inilah pola yang berulang di banyak perusahaan Indonesia yang baru pertama kali menjalankan produk berbasis LLM di skala produksi.
Masalahnya bukan harga per token yang mahal—harga itu terus turun. Masalahnya adalah produk LLM punya struktur biaya yang asing bagi tim engineering yang terbiasa berpikir dalam logika server: biaya tidak proporsional dengan jumlah request, melainkan dengan panjang konteks, jumlah pemanggilan model per task, dan pilihan model yang sering diambil tanpa pertimbangan. Artikel ini membongkar di mana biaya LLM benar-benar bersembunyi dan memberikan teknik konkret untuk memangkasnya 40-70% tanpa menurunkan kualitas yang dirasakan pengguna.
Sebelum mengoptimasi, Anda harus tahu apa yang sedang dibayar. Biaya LLM API dihitung dari token—baik input (prompt) maupun output (jawaban model)—dan token input biasanya jauh lebih banyak daripada yang disadari tim. Sebuah aplikasi RAG yang menyuntikkan 8.000 token konteks ke setiap query, padahal pengguna hanya mengetik pertanyaan 20 token, membayar 99% biayanya untuk konteks, bukan pertanyaan.
Ada beberapa sumber biaya yang konsisten muncul sebagai pemboros utama:
Konteks yang terlalu gemuk. System prompt panjang, few-shot example yang diulang di setiap request, dan dokumen retrieval yang dijejalkan tanpa filter.
Model overkill. Memakai model paling besar dan mahal untuk tugas sederhana seperti klasifikasi intent atau ekstraksi tanggal, padahal model kecil mengerjakannya sama baik dengan biaya sepersepuluh.
Pemanggilan berantai. Pola agentic yang memanggil model 5-10 kali untuk satu task, di mana setiap langkah membawa seluruh riwayat percakapan sebagai input.
Retry dan timeout yang tak terkontrol. Request gagal yang diulang otomatis, kadang berlipat karena bug, diam-diam menggandakan biaya.
Sebelum Anda menulis satu baris kode optimasi, ukur dulu: berapa token input rata-rata per request, model apa yang dipakai, dan endpoint mana yang paling sering dipanggil. Optimasi tanpa data hanya menebak.
Langkah pertama yang non-negotiable adalah observability biaya. Setiap pemanggilan LLM harus tercatat: model, jumlah token input dan output, latensi, fitur asal request, dan estimasi biaya dalam Rupiah. Tanpa ini, Anda buta. Dengan ini, biasanya Anda akan menemukan bahwa 20% endpoint memakan 80% biaya, dan optimasi bisa fokus tajam.
Teknik pertama yang harus Anda terapkan, karena rasio usaha-terhadap-hasilnya paling tinggi, adalah prompt caching. Mayoritas aplikasi LLM mengirim bagian awal prompt yang identik berulang kali—system prompt, instruksi format, few-shot example, bahkan basis pengetahuan statis. Penyedia LLM modern memungkinkan bagian yang berulang ini di-cache di sisi mereka, sehingga token yang sudah di-cache dibayar dengan tarif jauh lebih murah (sering hanya sepersepuluh dari harga normal) pada pemanggilan berikutnya.
Kuncinya adalah menyusun prompt dengan urutan yang benar: letakkan semua yang statis dan panjang di depan (system prompt, instruksi, contoh, dokumen referensi yang jarang berubah), dan yang dinamis di belakang (pertanyaan pengguna, konteks spesifik request ini). Cache bekerja berdasarkan prefiks—begitu ada perbedaan satu karakter pun di tengah, cache untuk semua yang setelahnya gugur.
Untuk aplikasi chatbot atau copilot dengan system prompt yang besar dan stabil, prompt caching saja sering memangkas 30-50% biaya input. Ini perubahan struktural di prompt, bukan penurunan kualitas—pengguna tidak merasakan apa pun selain respons yang sedikit lebih cepat.
Kesalahan paling mahal dan paling umum adalah memakai satu model besar untuk semua tugas. Sebagian besar pekerjaan dalam aplikasi LLM sebenarnya sederhana: mengklasifikasikan apakah pertanyaan tentang tagihan atau teknis, mengekstraksi nomor invoice dari teks, memutuskan apakah sebuah query butuh retrieval atau tidak. Tugas-tugas ini bisa dikerjakan model kecil dan murah dengan akurasi yang setara.
Strateginya disebut model routing atau cascade:
Klasifikasi murah di depan. Pakai model kecil untuk menilai kompleksitas atau kategori request, lalu arahkan ke model yang sesuai.
Eskalasi bertahap. Coba dengan model murah dulu; jika confidence rendah atau output gagal validasi, baru naikkan ke model lebih mahal. Mayoritas request selesai di tingkat murah.
Pisahkan tugas internal dari tugas yang dilihat pengguna. Langkah-langkah perantara (merangkum, mengekstrak, memilih) hampir selalu bisa pakai model kecil; hanya jawaban final yang menghadap pengguna yang mungkin butuh model besar.
Di praktik, perusahaan yang menerapkan routing dengan disiplin sering memindahkan 60-80% volume request ke model murah, dan ini saja bisa menurunkan biaya total separuh tanpa pengguna menyadari perbedaan kualitas, karena tugas yang dialihkan memang tidak menuntut kapabilitas model besar.
Asumsi keliru yang mahal adalah "semakin banyak konteks, semakin baik jawabannya". Dalam praktik, menjejalkan 20 dokumen retrieval ke prompt sering justru menurunkan kualitas—model tersesat di tengah konteks panjang (fenomena *lost in the middle*)—sekaligus melipatgandakan biaya. Konteks yang ramping dan relevan hampir selalu mengalahkan konteks yang gemuk dan berisik.
Beberapa teknik kompresi konteks yang efektif:
Reranking sebelum injeksi. Ambil 20 kandidat dari vector search, tapi pakai reranker untuk memilih hanya 3-5 yang paling relevan sebelum dimasukkan ke prompt. Lebih murah dan lebih akurat sekaligus.
Ringkasan riwayat percakapan. Pada chat panjang, jangan kirim seluruh transkrip setiap giliran. Ringkas percakapan lama menjadi satu paragraf padat, lalu kirim hanya ringkasan plus beberapa giliran terakhir secara utuh.
Buang yang tidak terpakai. System prompt sering menumpuk instruksi warisan yang tidak lagi relevan. Audit dan pangkas—setiap token yang dikirim, dibayar.
Di banyak aplikasi, pengguna menanyakan hal yang serupa berulang kali. "Bagaimana cara reset password?", "Berapa biaya admin transfer antarbank?", "Jam operasional cabang?"—pertanyaan-pertanyaan ini muncul ratusan kali sehari dengan variasi kalimat. Memanggil LLM untuk setiap variasi adalah pemborosan.
Semantic cache menyimpan pasangan pertanyaan-jawaban berdasarkan kemiripan makna, bukan kecocokan teks persis. Ketika pertanyaan baru masuk, sistem mengecek apakah ada pertanyaan serupa secara semantik yang sudah pernah dijawab; jika kemiripannya di atas ambang tertentu, jawaban tersimpan langsung dikembalikan tanpa memanggil LLM sama sekali. Untuk produk customer service dengan distribusi pertanyaan yang terkonsentrasi, semantic cache bisa menangani 20-40% trafik dengan biaya nyaris nol dan latensi sangat rendah.
Hati-hati pada dua hal: pertama, jangan cache jawaban yang bergantung konteks pengguna (saldo, status pesanan, data personal)—cache hanya cocok untuk pengetahuan umum dan statis. Kedua, set ambang kemiripan dengan ketat dan beri masa kedaluwarsa, agar jawaban usang tidak dilayani saat informasi berubah.
Tidak semua pekerjaan LLM perlu jawaban instan. Banyak tugas—mengklasifikasikan ribuan tiket support semalaman, memperkaya katalog produk, menganalisis sentimen ulasan—bersifat batch dan tidak menghadap pengguna secara real-time. Untuk beban kerja seperti ini, penyedia LLM umumnya menawarkan batch API dengan diskon signifikan (sering sekitar 50%) sebagai imbalan atas jawaban yang diproses dalam jendela waktu (misalnya beberapa jam), bukan seketika.
Memisahkan beban kerja Anda menjadi dua jalur—real-time untuk interaksi pengguna, batch untuk pemrosesan latar belakang—memungkinkan Anda menangkap diskon ini tanpa kompromi pada pengalaman pengguna. Banyak tim tidak melakukan ini hanya karena tidak pernah memetakan mana request yang benar-benar butuh instan.
Optimasi menurunkan biaya rata-rata; guardrail mencegah bencana. Anda butuh batas keras agar satu bug, satu serangan, atau satu lonjakan trafik tak terduga tidak menghasilkan tagihan delapan digit dalam semalam.
Hard budget cap per fitur dan per pengguna. Tetapkan plafon biaya harian; saat tercapai, sistem turun ke mode degradasi (jawaban template, antrean, atau penolakan halus) alih-alih terus memanggil model.
Batasi panjang output. Set max_tokens yang masuk akal. Model yang dibiarkan "ngobrol" panjang membayar mahal untuk verbositas yang tak diminta.
Deteksi loop dan retry liar. Pasang circuit breaker pada pola agentic agar tidak ada task yang memanggil model puluhan kali karena gagal konvergen.
Alert anomali biaya. Notifikasi otomatis saat biaya per jam melampaui baseline historis—Anda ingin tahu dalam menit, bukan saat invoice akhir bulan tiba.
Bagi tim Indonesia yang menganggarkan dalam Rupiah dengan persetujuan finance yang ketat, budget cap bukan sekadar praktik baik—ia adalah syarat agar produk AI bisa dijalankan di produksi tanpa membuat CFO gelisah setiap akhir bulan.
Teknik-teknik di atas bekerja paling baik ketika tertanam dalam budaya, bukan hanya kode. Di organisasi yang matang, biaya LLM diperlakukan sebagai metrik produk yang diawasi setara dengan latensi dan tingkat error—bukan kejutan yang baru dibahas saat invoice tiba. Pendekatan ini dikenal sebagai FinOps untuk AI, dan intinya adalah menjadikan biaya sebagai tanggung jawab bersama antara engineering, product, dan finance.
Beberapa praktik yang membuat biaya AI dapat dikelola sebagai disiplin organisasi:
Unit economics yang jelas. Hitung biaya per pengguna aktif, per percakapan, atau per dokumen yang diproses dalam Rupiah. Angka per request lebih bermakna bagi pengambil keputusan daripada total tagihan bulanan yang abstrak.
Atribusi biaya per fitur dan per tim. Ketika setiap fitur AI tahu berapa biaya yang ditimbulkannya, keputusan untuk mengoptimasi atau bahkan mematikan fitur bernilai rendah menjadi jauh lebih mudah dan berdasar data.
Review biaya berkala. Jadikan tinjauan biaya LLM bagian dari ritme operasional reguler, sehingga tren naik tertangkap saat masih kecil, bukan setelah membengkak.
Hubungkan biaya ke nilai. Biaya tinggi tidak selalu buruk jika fitur menghasilkan pendapatan atau penghematan yang lebih besar. Yang berbahaya adalah biaya tinggi pada fitur yang tidak terbukti memberi nilai.
Pergeseran pola pikir ini—dari "biaya adalah masalah infrastruktur" menjadi "biaya adalah properti produk"—adalah yang membedakan tim yang biayanya terkendali dari tim yang terus dikejutkan tagihan. Ketika seorang engineer menulis fitur baru dan secara naluriah bertanya "berapa token yang ini konsumsi per request", separuh pertempuran sudah dimenangkan.
Satu peringatan penting: optimasi biaya juga punya biaya, yaitu waktu engineering dan kompleksitas tambahan. Tidak semua penghematan layak dikejar. Jika sebuah fitur menghabiskan beberapa juta Rupiah per bulan dan menghemat puluhan jam kerja yang bernilai jauh lebih besar, mengeluarkan dua minggu engineering untuk memangkasnya 20% mungkin bukan prioritas terbaik.
Aturan praktis yang sehat: fokuskan upaya optimasi pada endpoint yang memakan porsi biaya terbesar dan tumbuh paling cepat. Optimasi prematur pada fitur kecil hanya menambah kompleksitas tanpa imbalan berarti. Observability biaya yang Anda pasang di langkah pertama justru berguna di sini—ia memberi tahu di mana penghematan benar-benar penting dan di mana ia hanya gangguan. Biaya yang terkendali bukan berarti biaya yang serendah mungkin, melainkan biaya yang Anda pahami, awasi, dan kendalikan secara sadar.
Jika Anda mulai dari nol, jangan terapkan semua sekaligus. Urutkan berdasarkan rasio dampak-terhadap-usaha:
1. Pasang observability biaya dulu—Anda tidak bisa mengoptimasi yang tidak Anda ukur. 2. Terapkan prompt caching dengan menyusun ulang struktur prompt. Cepat, dampak besar. 3. Audit pemilihan model dan terapkan routing untuk memindahkan tugas sederhana ke model murah. 4. Pangkas konteks dengan reranking dan ringkasan riwayat. 5. Tambahkan semantic cache untuk pertanyaan berulang. 6. Pasang budget cap dan alert sebagai jaring pengaman.
Dengan tiga langkah pertama saja, sebagian besar tim sudah melihat penurunan biaya 40-50%. Sisanya menambah penghematan sekaligus memperkuat ketahanan sistem.
Mengendalikan biaya LLM bukan tugas yang selesai setelah satu sprint—ia adalah disiplin berkelanjutan yang harus tertanam dalam cara tim Anda membangun dan memantau produk AI. Setiap fitur baru menambah jalur biaya baru, dan tanpa observability serta guardrail yang tepat, penghematan yang Anda raih hari ini akan tergerus oleh pertumbuhan esok hari.
Di Sainskerta Solusi Nusantara, kami membantu tim engineering Indonesia membangun arsitektur LLM yang efisien sejak fase desain—mulai dari strategi caching, routing model, hingga observability biaya yang memberi visibilitas penuh dalam Rupiah. Jika tagihan LLM Anda mulai terasa tak terkendali, atau Anda ingin merancang produk AI yang hemat sejak awal, jadwalkan sesi konsultasi dengan tim kami melalui halaman Kontak. Kami akan mengaudit pola biaya Anda dan menyusun peta penghematan yang konkret dan terukur.
