Cara Pengembang Game Memperkirakan Biaya Dialog AI yang Panjang

1. Tentukan unit yang Anda perkirakan

Pilihlah unit yang jelas terlebih dahulu: misalnya, biaya inferensi model per sesi dialog, per pemain aktif harian (active player-day), atau per 1.000 sesi. Untuk perkiraan berbasis sesi, tentukan kapan sesi dimulai dan berakhir. Aturan praktisnya bisa berupa "dari permintaan dialog pertama hingga 30 menit tanpa permintaan berikutnya," tetapi waktu habis (timeout) tersebut merupakan keputusan pengukuran, bukan standar universal. Catatlah batasan ini agar pengembang lain dapat mereproduksi perkiraan tersebut.

Hitung permintaan model, bukan hanya pesan pemain. Satu interaksi dapat memicu beberapa panggilan—misalnya, sebuah respons yang diikuti oleh panggilan penanganan alat (tool-handling) terpisah—dan percobaan ulang (retry) dapat menambah jumlah tersebut. Jika game menggunakan suara, input gambar, temu kembali informasi (retrieval), atau alat (tools), simpan komponen tersebut dalam bidang biaya terpisah serta catat token model terkaitnya. Harga dari penyedia dapat mencakup biaya alat atau tarif khusus modalitas selain biaya token teks biasa; OpenAI, misalnya, mencantumkan biaya alat terpisah dan menyatakan bahwa token model yang digunakan untuk alat bawaan ditagih sesuai tarif model yang dipilih (OpenAI API pricing).

2. Ukur token aktual per permintaan

Untuk setiap panggilan, catat penyedia, pengidentifikasi model, stempel waktu (timestamp), pengidentifikasi sesi, tujuan permintaan, jumlah token input, jumlah token output, serta rincian token dengan cache atau token penalaran (reasoning tokens) yang dilaporkan. Tangkap juga percobaan ulang, kesalahan, panggilan alat, dan apakah panggilan berhasil diselesaikan. Hindari menyimpan konten dialog kecuali diperlukan untuk tujuan produk yang memiliki justifikasi terpisah; total token dan metadata operasional biasanya sudah cukup untuk perkiraan biaya.

Gunakan penggunaan yang dilaporkan oleh penyedia dari panggilan yang selesai sebagai pengukuran utama. Penghitungan awal (preflight counting) sangat membantu untuk menguji penyusunan prompt, tetapi hasilnya mungkin tidak sesuai dengan rincian tagihan akhir. OpenAI mendokumentasikan bahwa output yang dilaporkan mencakup token di luar teks yang terlihat, seperti beberapa token pemformatan dan struktur alat, serta menyarankan untuk tidak memperkirakan output hanya dari apa yang dilihat pemain (OpenAI token-counting guide). Dokumentasi Gemini dari Google juga membedakan jumlah token prompt, cached-content, candidate-output, dan thinking dalam metadata penggunaannya (Gemini token guide).

Bangun sampel representatif yang mencakup pemain baru, pemain lama, percakapan pendek maupun panjang, serta konfigurasi prompt dan alat versi produksi. Pertahankan sesi sebagai unit pengambilan sampel: dialog sebanyak 40 giliran harus tetap menjadi satu observasi dengan akumulasi biayanya, bukan diperlakukan sebagai 40 sesi pemain yang independen. Selama tahap prototipe, sekumpulan percakapan berskrip yang tetap dapat membantu membandingkan perubahan prompt; setelah peluncuran, sesi yang teramati di dunia nyata harus menjadi dasar prakiraan.

3. Perhitungkan pertumbuhan riwayat dan penggunaan kembali konteks

Dalam banyak sistem dialog, setiap permintaan menyertakan giliran pengguna saat ini ditambah sebagian atau seluruh riwayat percakapan. Jika riwayat terus-menerus dikirim ulang, token input dapat bertambah di setiap giliran meskipun pesan dari pemain tergolong singkat. Ukur payload permintaan aktual yang dikirim ke model; jangan mengalikan ukuran prompt satu giliran dengan jumlah giliran kecuali implementasinya memang mengirimkan jumlah yang sama persis setiap kali.

Penyimpanan cache (caching) mengubah tarif yang dikenakan pada input berulang yang memenuhi syarat; hal ini tidak berarti seluruh dialog menjadi gratis atau sesi yang persisten menjamin terjadinya cache hit. OpenAI mendeskripsikan prompt caching sebagai penggunaan kembali awalan (prefix) prompt yang tidak berubah dan menegaskan bahwa input baru tetap harus diproses. Diagnostik cache miliknya dapat membantu mengukur cache read dan cache miss (OpenAI prompt-caching guide). Anthropic juga membedakan antara penulisan cache (cache write) dan pembacaan cache (cache read), serta memublikasikan tarif dan durasi cache yang terpisah (Anthropic pricing and prompt caching).

Dalam telemetri Anda, pisahkan token input tanpa cache, token input dengan cache, dan token penulisan cache saat dilaporkan oleh penyedia. Catat rasio cache hit dibagi dengan permintaan yang memenuhi syarat, serta proporsi token input yang benar-benar ditagih sebagai cache. Keduanya menjawab hal yang berbeda: tingkat hit yang tinggi di seluruh permintaan tetap dapat menghasilkan proporsi token ter-cache yang rendah jika awalan berulangnya berukuran kecil. Kelayakan cache, ukuran minimum, masa kedaluwarsa, stabilitas awalan prompt, dan dukungan model bergantung pada masing-masing penyedia; hitung hanya penghematan yang dikonfirmasi oleh data penggunaan.

4. Terapkan tarif dengan perhitungan yang transparan

Untuk model dengan harga per satu juta token, hitung setiap sesi sebagai berikut:

biaya sesi = (input tanpa cache × tarif input + input dengan cache × tarif input dengan cache + penulisan cache × tarif penulisan cache + output × tarif output) ÷ 1.000.000 + biaya lain yang berlaku

Gunakan tarif untuk model, endpoint, modalitas, wilayah, dan tingkat layanan (tier) yang tepat sesuai konfigurasi yang diterapkan. Periksa kembali tarif tersebut secara mandiri di halaman harga penyedia sesaat sebelum menyusun anggaran; tarif dan katalog model dapat berubah sewaktu-waktu. Sertakan biaya penyimpanan jika cache menagih biaya untuk token yang disimpan dan durasinya. Sebagai contoh, harga resmi Gemini mencantumkan kategori token untuk penggunaan berbayar dan harga per jam penyimpanan untuk konfigurasi context caching tertentu, sementara dokumentasi penagihannya mengidentifikasi input, output, token dengan cache, dan durasi penyimpanan cache sebagai faktor yang dapat ditagih (Gemini pricing; Gemini billing).

Perhitungan yang terperinci membuat asumsi menjadi transparan. Sebagai ilustrasi semata, anggaplah panggilan terukur yang dialokasikan untuk satu sesi berisi 18.000 token input tanpa cache, 12.000 token input dengan cache, dan 6.000 token output. Menggunakan tarif tingkat berbayar Gemini 3.8 Flash yang dipublikasikan untuk penggunaan hingga 31 Desember 2026—$0,75 per juta token input, $0,075 per juta token dengan cache, dan $3,75 per juta token output—memberikan hasil $0,0135 + $0,0009 + $0,0225, atau $0,0369 sebelum biaya penyimpanan cache atau biaya lain yang berlaku. Contoh ini mengasumsikan token dengan cache yang tercantum ditagih dengan tarif cache dan tidak mencakup biaya pembuatan cache awal di luar total terukur. Tarif ini terikat waktu dan harus diperiksa kembali saat memperkirakan periode mendatang (Gemini pricing).

5. Gunakan distribusi panjang sesi

Jangan mengalikan satu sesi "tipikal" yang dipilih sembarangan dengan total pemain lalu menyebutnya sebagai prakiraan. Kelompokkan sesi yang diamati berdasarkan jumlah giliran atau rentang panjang lainnya yang relevan, hitung biaya rata-rata di setiap rentang, lalu beri bobot pada setiap rentang berdasarkan pangsa sesinya. Cantumkan nilai median dan persentil atas bersama nilai rata-rata (mean): rata-rata memperkirakan total penggunaan saat dikalikan dengan volume sesi, sedangkan persentil membantu menggambarkan biaya yang mungkin timbul dari sesi yang lebih singkat atau yang luar biasa panjang.

Misalnya, jika sebuah sampel memiliki banyak sesi pendek dan sejumlah kecil sesi yang sangat panjang, laporkan proporsi sesi di setiap rentang dan biaya masing-masing rentang tersebut. Prakiraan untuk 10.000 sesi kemudian dapat dihitung sebagai jumlah dari (sesi dalam rentang × biaya rata-rata dalam rentang), alih-alih mengasumsikan setiap sesi menyerupai median keseluruhan. Jika penggunaan berbeda secara signifikan menurut mode game, bahasa, platform, atau pemain baru vs pemain lama, stratifikasi kelompok-kelompok tersebut sebelum menggabungkannya. Pilihan untuk melakukan segmentasi adalah keputusan analisis; jelaskan mengapa setiap segmen dapat mengubah penggunaan token atau perilaku permintaan.

6. Dokumentasikan ketidakpastian dan perbarui perkiraan secara berkala

Simpan catatan asumsi yang ringkas berisi tanggal sampel, aturan batasan sesi, model dan endpoint, versi prompt, jumlah sesi yang diamati, definisi cache hit, tanggal pengambilan halaman harga, biaya yang disertakan, dan komponen yang dikecualikan. Tampilkan skenario rendah, menengah, dan tinggi dengan mengubah variabel input yang dapat diamati—misalnya, variasi panjang sesi, ukuran output, atau rasio cache hit terukur—alih-alih menerapkan batas aman (buffer) tanpa penjelasan. Perlakukan setiap proyeksi perilaku di luar sesi yang diamati sebagai skenario eksplisit, bukan fakta terukur.

Perkiraan hanya akan seakurat instrumentasi dan kategori tagihan yang ada. Perkiraan bisa saja melewatkan panggilan yang dialihkan di luar pencatat log (logger), percobaan ulang, kategori token dengan cache yang tidak ditampilkan oleh API, token penalaran di sisi model, durasi penyimpanan, pemrosesan media, atau biaya penyedia di luar tarif token. Rekonsiliasikan sampel penggunaan dengan laporan penagihan penyedia jika tersedia, selidiki selisih yang signifikan, dan jalankan kembali perhitungan setelah mengubah model, prompt, perilaku caching, atau fitur yang ditampilkan ke pemain. Hasil akhirnya adalah perkiraan biaya operasional yang terdokumentasi untuk beban kerja yang diamati, bukan jaminan bahwa sesi atau faktur di masa mendatang akan sama persis.

Lanjutkan topik ini