Apa Itu Kalkulator Harga per Kueri? Panduan Biaya API LLM

Kalkulator harga per kueri adalah alat yang memperkirakan biaya API satu panggilan ke model bahasa besar (LLM). Anda memasukkan jumlah token masukan (prompt, konteks, dan dokumen yang diambil), jumlah token keluaran yang diharapkan (respons model), dan model yang dituju. Kalkulator mengalikan masing-masing dengan tarif per token yang dipublikasikan penyedia dan mengembalikan biaya per kueri, plus proyeksi total bulanan berdasarkan volume panggilan yang Anda harapkan.

Tujuan utamanya adalah membuat biaya AI bisa diprediksi. Tanpa kalkulator, mudah meremehkan seberapa cepat biaya token menumpuk pada skala besar. Kueri seharga $0,012 terasa tidak berarti, tetapi dengan 10.000 panggilan per hari itu berarti $120 per hari, atau $3.600 per bulan, dari satu endpoint API saja. Kalkulator harga per kueri menunjukkan hal ini sebelum Anda melakukan deploy, bukan sesudahnya.

Apa yang ditampilkan kalkulator harga per kueri

• Biaya per kueri - nilai persis satu panggilan API dengan jumlah token dan model yang Anda tentukan.
• Proyeksi harian dan bulanan - menerapkan biaya per kueri pada volume panggilan yang diharapkan.
• Rincian masukan dan keluaran - menunjukkan berapa bagian biaya dari prompt dan berapa dari respons, karena token keluaran lebih mahal.
• Perbandingan model - sebagian kalkulator memungkinkan membandingkan biaya kueri yang sama pada beberapa model sekaligus.

Penyedia LLM menagih per token, yaitu satuan teks yang kira-kira setara 0,75 kata dalam bahasa Inggris (atau sekitar 4 karakter). Harga dinyatakan per juta token ($/M), terpisah untuk masukan dan keluaran. Token masukan mencakup semua yang Anda kirim: prompt sistem, riwayat percakapan, pesan pengguna, potongan dokumen hasil pengambilan dari saluran RAG, serta skema fungsi atau alat. Token keluaran adalah respons yang dihasilkan model.

Token masukan dan keluaran dihargai terpisah. Token keluaran 3-5 kali lebih mahal daripada token masukan karena pembuatan teks lebih berat secara komputasi dibandingkan pemrosesan konteks.

Mengapa token keluaran lebih mahal

Saat inferensi, memproses token masukan hanya butuh satu lintasan maju melalui model. Menghasilkan token keluaran membutuhkan loop autoregresif: model membuat satu token setiap kali, dan tiap langkah bergantung pada langkah sebelumnya. Proses berurutan ini jauh lebih berat di GPU per token, sehingga penyedia mengenakan premi besar untuk keluaran. Pada harga GPT-4o, masukan berbiaya $2,50/M dan keluaran $10,00/M - kelipatan 4. Ini punya implikasi praktis langsung: respons panjang dan bertele-tele jauh lebih mahal dibandingkan respons ringkas.

Bagaimana jumlah token dipetakan ke panjang prompt nyata

• Prompt pendek + jawaban pendek (mis. "Klasifikasikan teks ini"): total ~50-200 token.
• Pesan sistem + kueri pengguna dengan konteks: ~500-2.000 token masukan, 100-500 token keluaran.
• Kueri RAG dengan potongan dokumen: ~2.000-8.000 token masukan, 300-1.000 token keluaran.
• Alur agen dengan hasil alat dan riwayat: ~8.000-32.000 token masukan per panggilan.
• Pembuatan panjang (artikel, kode): ~1.000-4.000 token masukan, 1.000-4.000 token keluaran.

Memperkirakan biaya kueri secara akurat menuntut tiga angka: rata-rata jumlah token masukan per panggilan, rata-rata jumlah token keluaran per panggilan, dan volume panggilan harian Anda. Dua yang pertama paling baik diukur secara empiris dengan penghitung token dari penyedia atau kolom `usage` pada respons API - bukan diperkirakan dari jumlah kata.

Langkah 1 - Ukur pemakaian token nyata saat pengembangan

Setiap respons API LLM menyertakan objek `usage` dengan `prompt_tokens`, `completion_tokens`, dan `total_tokens`. Catat data ini selama pengembangan pada sampel representatif 50-100 kueri nyata. Hitung rata-rata dan persentil ke-95 untuk masukan maupun keluaran. Untuk perencanaan biaya, gunakan persentil ke-95 masukan dan rata-rata keluaran: ini memperhitungkan konteks besar yang tidak biasa tanpa melebih-lebihkan panggilan tipikal.

Langkah 2 - Perkirakan volume bulanan

Untuk aplikasi produksi, perkirakan pengguna aktif harian × rata-rata kueri per sesi × panggilan API per kueri. Chatbot dengan 1.000 pengguna harian, 5 pesan per sesi, dan 1 panggilan API per pesan menghasilkan 5.000 panggilan per hari. Kalikan biaya per panggilan dengan volume harian, lalu dengan 30 untuk proyeksi bulanan. Sisakan margin 30-50 % untuk lonjakan trafik dan iterasi rekayasa prompt.

Langkah 3 - Bandingkan antar tingkat model

Jalankan jumlah token yang sama pada beberapa tingkat model untuk mengidentifikasi di mana syarat kualitas memungkinkan model lebih murah. Banyak tugas - klasifikasi, ekstraksi entitas, peringkasan sederhana, jawaban FAQ - mencapai kualitas memadai dengan model yang lebih kecil dan murah. Menyisakan model terdepan (kelas GPT-4, kelas Claude 3.5 Sonnet) hanya untuk sebagian tugas yang benar-benar membutuhkannya dan mengarahkan tugas sederhana ke model lebih murah biasanya adalah penghematan paling berdampak.

Harga model sering berubah - penyedia menurunkannya secara signifikan seiring persaingan yang makin ketat. Tabel di bawah menunjukkan kisaran harga yang representatif pada pertengahan 2026 untuk menggambarkan struktur biayanya. Selalu verifikasi harga terkini di halaman harga resmi tiap penyedia sebelum menyusun proyeksi biaya produksi.

Perbedaan biaya antara tingkat termurah dan termahal mencapai dua orde besaran. Aplikasi dengan 10.000 kueri per hari memakai model kelas o1 berbiaya sekitar $60-240 per hari; aplikasi yang sama dengan GPT-4o Mini berbiaya $1,50-20 per hari. Keputusan perutean berdasarkan kompleksitas tugas - memakai pengklasifikasi kueri untuk mengarahkan tiap panggilan ke tingkat model yang sesuai - dapat menekan total pengeluaran API hingga 60-80 % pada saluran dengan kompleksitas tugas campuran.

Ukuran jendela konteks versus biaya

Jendela konteks yang lebih besar memungkinkan lebih banyak informasi per kueri, tetapi makin banyak token dalam prompt berarti biaya masukan makin tinggi. Jendela konteks 100.000 token baru layak dipakai jika konteks tambahan itu benar-benar meningkatkan kualitas respons untuk tugas tersebut. Pada sebagian besar aplikasi retrieval-augmented generation (RAG), 2.000-4.000 token konteks hasil pengambilan menghasilkan respons hampir sebaik 20.000 token dengan biaya masukan 5-10 kali lebih rendah. Selalu ukur kualitas versus panjang konteks sebelum menetapkan prompt besar di produksi.

Optimasi biaya kueri punya dua pengungkit: mengurangi token per kueri dan menurunkan harga per token. Strategi berikut menyentuh keduanya dan disusun kasar menurut tingkat usaha penerapannya, dari paling rendah ke paling tinggi.

• Kompres data masukan sebelum disisipkan - konversi payload JSON, CSV, atau YAML ke format TOON sebelum dimasukkan ke prompt. Konverter JSON ke TOON mengurangi jumlah token 30-60 % tanpa kehilangan informasi.
• Pakai model termurah yang memenuhi syarat kualitas - uji setiap jenis tugas pada tingkat model lebih kecil sebelum menganggap butuh model terdepan. Banyak tugas ekstraksi, klasifikasi, dan peringkasan berjalan baik di GPT-4o Mini atau Gemini Flash.
• Pendekkan dan rapikan prompt sistem - audit prompt sistem Anda untuk instruksi berulang, contoh format yang panjang, dan catatan berulang. Setiap token yang dihapus menghemat uang di setiap panggilan API.
• Batasi panjang keluaran dengan max_tokens - minta model menjawab ringkas dan tetapkan plafon max_tokens yang tegas. Token keluaran 3-5 kali token masukan, jadi menekan respons bertele-tele langsung memangkas bagian tagihan yang paling mahal.
• Aktifkan cache prompt - gunakan cache bawaan penyedia untuk prompt sistem statis dan contoh few-shot. Token yang di-cache berbiaya 50-90 % lebih murah daripada yang tidak di-cache pada OpenAI dan Anthropic.
• Cache respons kueri umum - untuk kueri deterministik atau hampir deterministik, simpan respons LLM dan sajikan untuk masukan identik yang berulang tanpa melakukan panggilan API.

Kompresi token: jalur tercepat menuju penghematan

Untuk aplikasi yang mengirim data terstruktur ke LLM - katalog produk, data pengguna, ekspor analitik, respons API - kompresi token masukan menawarkan penghematan tercepat dan paling konsisten. Mengonversi payload JSON 2.000 token ke format TOON menyusutkannya menjadi sekitar 800-1.400 token. Pada tarif $3,00/M token masukan dan 50.000 kueri harian, satu perubahan itu menghemat $0,09-0,18 per hari: sekitar $33-66 per bulan tanpa dampak pada kualitas. Untuk data CSV, Konverter CSV ke TOON mencapai penghematan token 40-60 % pada kumpulan data tabular, dan Konverter YAML ke TOON menangani konfigurasi dan data terstruktur dalam format YAML.

Bagi pengembang perorangan dan proyek kecil, biaya token jarang signifikan: $5-20 per bulan untuk eksperimen dan pengembangan. Masalah muncul ketika sebuah fitur menskalakan ke volume produksi, ketika rancangan prompt menyertakan payload konteks besar, atau ketika satu saluran merangkai beberapa panggilan API per interaksi pengguna. Inilah skenario tempat perhitungan harga per kueri menjadi krusial.

Saluran agen dan bertahap

Alur agen yang merangkai beberapa panggilan LLM - perencanaan, penggunaan alat, refleksi, peringkasan - bisa mengakumulasi 10.000-100.000 token dalam satu permintaan pengguna yang tampak sebagai satu interaksi. Setiap hasil panggilan alat dan giliran percakapan disisipkan ulang sebagai konteks untuk panggilan berikutnya, sehingga jumlah token tumbuh kuadratik seiring jumlah langkah. Untuk saluran seperti ini, memperkirakan biaya per permintaan pengguna menuntut mengalikan biaya per kueri dengan rata-rata jumlah panggilan LLM per eksekusi.

Aplikasi RAG dengan potongan dokumen besar

Saluran retrieval-augmented generation menyisipkan potongan dokumen hasil pengambilan ke setiap prompt. Jika strategi pemotongan menghasilkan potongan besar (1.000-4.000 token masing-masing) dan mengambil tiga sampai lima potongan per kueri, jumlah token masukan bisa mencapai 5.000-20.000 per panggilan bahkan sebelum pertanyaan pengguna dimasukkan. Mengompres potongan hasil pengambilan dengan format seperti TOON - atau memangkas ukurannya di saluran embedding - langsung menurunkan biaya per kueri tanpa mengubah kualitas pengambilan. Untuk latar belakang tentang posisi validasi keluaran terstruktur dalam saluran seperti ini, panduan Guardrails AI membahas lapisan validasi yang berada setelah pengambilan.