Menghitung biaya AI: token, cache, batch, dan biaya review

Tagihan model turun, tetapi waktu editor memperbaiki hasil naik. Apakah biaya AI benar-benar membaik? Jawabannya membutuhkan penyebut yang tepat. Biaya per permintaan tidak sama dengan biaya per pekerjaan selesai, apalagi biaya per hasil yang diterima.

Artikel ini menyusun ledger biaya untuk pipeline editorial, lalu membahas cache dan batch berdasarkan dokumentasi resmi. Angka harga di contoh adalah unit simulasi, bukan tarif layanan. Contoh perhitungan dapat dijalankan lokal tanpa kunci API.

Definisikan satu pekerjaan dari awal sampai selesai

Satu pekerjaan dapat memanggil pencarian, model ekstraksi, model penulisan, dan validator. Retry menambah panggilan, sedangkan review menambah waktu manusia. Beri seluruh rangkaian sebuah job_id agar biaya tidak terpecah menjadi potongan yang sulit direkonsiliasi.

Catat token menurut kategori tagihan yang dilaporkan provider. Jangan menjumlahkan total input dan cached input seolah keduanya selalu kategori terpisah; pada beberapa envelope, cached input adalah bagian dari total. Adapter harus menerjemahkannya menjadi kategori yang tidak tumpang tindih.

Gunakan estimasi untuk perencanaan dan penggunaan aktual untuk rekonsiliasi. Simpan versi daftar harga yang dipakai, mata uang, serta waktu berlaku agar laporan bulan berikutnya dapat dijelaskan.

Cache menyimpan pekerjaan prefix, bukan keputusan bisnis

Dokumentasi prompt caching menjelaskan pencocokan prefix dan batas lookup yang memenuhi syarat. Materi bersama yang stabil dapat ditempatkan lebih awal, tetapi prefix bersama belum otomatis berarti cache hit: model, breakpoint, mode cache, dan pengaturan yang relevan ikut menentukan reuse.

Pada dokumentasi saat diperiksa, model GPT-5.6 dan setelahnya memiliki aturan caching yang perlu dibaca khusus, termasuk breakpoint eksplisit untuk batas materi yang ingin dipakai ulang. Jangan menyalin asumsi perilaku model lama ke model baru tanpa memeriksa panduannya.

Pisahkan cache prompt dari cache hasil. Cache prompt masih menghasilkan jawaban baru. Cache hasil aplikasi mengembalikan keputusan lama, sehingga perlu invalidasi berdasarkan sumber, revisi instruksi, identitas, dan izin akses. Menghemat token tidak membenarkan menampilkan hasil usang.

Ledger lokal dengan kategori yang tidak tumpang tindih

Contoh berikut menghitung biaya model setelah adapter memisahkan penggunaan. Harga diberikan per satu juta token dalam unit simulasi:

from decimal import Decimal


def model_cost(usage, rates):
    required = {"uncached_input", "cache_read", "cache_write", "output"}
    if set(usage) != required or set(rates) != required:
        raise ValueError("Kategori penggunaan dan tarif tidak cocok")
    total = Decimal("0")
    for key in required:
        tokens = usage[key]
        price = Decimal(str(rates[key]))
        if type(tokens) is not int or tokens < 0 or not price.is_finite() or price < 0:
            raise ValueError("Token dan tarif harus nonnegatif")
        total += Decimal(tokens) * price / Decimal(1_000_000)
    return total


usage = {"uncached_input": 1000, "cache_read": 4000,
         "cache_write": 0, "output": 500}
rates = {"uncached_input": "1", "cache_read": "0.2",
         "cache_write": "1.3", "output": "4"}
print(model_cost(usage, rates))

Hasilnya 0,0038 unit simulasi. Fungsi ini hanya menghitung empat kategori model; biaya tool, infrastruktur, dan review masih harus ditambahkan. Beberapa layanan mempunyai struktur tagihan berbeda, sehingga adapter serta kategori perlu diubah sesuai kontrak aktual.

Untuk menilai cache, hitung biaya write dan read, bukan hanya persentase hit. Prefix yang hanya dipakai sekali mungkin menambah biaya. Ukur pola reuse pada beban nyata sebelum menyimpulkan cache menguntungkan.

Batch cocok untuk pekerjaan yang bisa menunggu

Panduan Batch API menjelaskan pemrosesan asinkron melalui berkas JSONL dan identitas custom_id untuk mencocokkan hasil. Kegunaan editorial dapat berupa evaluasi berkala atau pengayaan arsip, ketika hasil tidak dibutuhkan saat pengguna sedang menunggu.

Jangan mencocokkan hasil berdasarkan urutan baris. Bangun pemetaan custom_id → pekerjaan, lalu rekonsiliasi sukses, error, dan hasil yang belum tersedia. Duplikasi ID pada input harus ditolak sebelum mengirim batch.

Pisahkan tenggat bisnis dari batas layanan. Bila tugas harus selesai sebelum rapat satu jam lagi, jalur dengan jendela penyelesaian lebih panjang belum tentu cocok. Siapkan penanganan batch kedaluwarsa dan retry hanya untuk item yang perlu diulang.

Ukur biaya per hasil yang diterima

Gunakan rumus kerja berikut:

biaya_total = model + tool + infrastruktur + review + penanganan_gagal
biaya_per_hasil_diterima = biaya_total / hasil_yang_lolos_review

Jika 100 tugas menelan 120 unit dan hanya 60 hasil dipakai, rasionya 2 unit per hasil. Bila konfigurasi lain menelan 150 unit tetapi menghasilkan 90 keluaran diterima, rasionya sekitar 1,67. Angka ini sintetis dan tidak menganggap kualitas semua tugas setara.

Laporkan kelompok tugas secara terpisah. Ringkasan satu halaman tidak adil dibandingkan dengan analisis laporan panjang. Catat pula jumlah pekerjaan yang belum selesai agar laporan tidak menampilkan biaya yang sudah terjadi tanpa menyebut hasil yang masih menunggu.

Pengendalian anggaran perlu bekerja sebelum panggilan

Terapkan batas per pekerjaan dan per periode pada gateway. Reservasi anggaran sebaiknya atomik agar dua permintaan serentak tidak melewati batas yang sama. Setelah hasil diterima, rekonsiliasi estimasi dengan penggunaan aktual dan tangani reservasi yang kedaluwarsa.

Bila anggaran habis, aplikasi dapat mengantrekan pekerjaan atau meminta pengguna mempersempit tugas. Mengganti model secara diam-diam dapat mengubah kualitas dan kebijakan data. Rancang keputusan itu melalui routing dan SLO, lalu nilai penghematannya bersama hasil evaluasi kualitas.