Biaya API AI: token dan grup model

Pelacakan biaya API AI paling berguna jika setiap potongan saldo dapat dihubungkan ke satu permintaan, satu model, satu grup model, dan satu unit kerja yang terukur. Total bulanan menunjukkan bahwa pengeluaran berubah; catatan per permintaan menjelaskan penyebabnya.

Modelflare menggabungkan harga model, penggunaan terukur, kebijakan grup, dan log permintaan agar pengguna tidak perlu memperkirakan biaya hanya dari teks yang terlihat.

Empat lapisan biaya permintaan

1. Harga model

Setiap model memiliki dasar harga sendiri. Banyak model teks menggunakan token input dan output dengan tarif berbeda; API gambar, audio, reranking, atau lainnya dapat memakai unit ukur yang berbeda. Beberapa fitur juga menggunakan aturan harga lanjutan berversi yang tidak dapat dinyatakan sebagai satu tarif token datar.

Gunakan Model & Harga untuk kontrak model dan format API terkini, bukan menyalin harga ke dalam kode aplikasi.

2. Penggunaan permintaan yang terukur

Gateway mencatat penggunaan yang dikembalikan atau dihitung untuk permintaan yang selesai. Pada model teks berbasis token, input dan output disimpan terpisah karena tarifnya dapat berbeda.

Teks streaming yang terlihat di terminal bukan acuan biaya yang andal. Item alat, penalaran, input cache, token yang dinormalisasi, atau kolom penggunaan khusus penyedia dapat ikut dihitung meskipun tidak ditampilkan sebagai teks asisten biasa.

3. Pengali grup model

Grup perutean terpilih dapat menerapkan pengali penjualan pada biaya penggunaan dasar. Sebagai contoh, rasio grup 0.9 menerapkan 90% dari biaya dasar model pada permintaan tersebut.

Pengali berlaku untuk penggunaan. Nilai tersebut tidak mengubah jumlah kredit yang ditambahkan ke dompet saat isi ulang.

4. Catatan akhir permintaan

Log penggunaan menghubungkan jumlah terhitung dengan model, grup, status, token, waktu, dan metadata operasional aman lainnya. Permintaan gagal atau dibatalkan dapat mengikuti jalur penyelesaian berbeda, sehingga hasil yang tersimpan lebih tepercaya daripada perkiraan di sisi klien.

Hal yang perlu dibandingkan di log penggunaan

Saat pengeluaran berubah, bandingkan:

• Model: apakah trafik pindah ke model dengan harga input, output, atau fitur yang berbeda?
• Grup: apakah grup utama atau cadangan menggunakan pengali berbeda?
• Protokol: apakah perpindahan antara Chat Completions dan Responses mengubah bentuk penggunaan?
• Ukuran input: apakah prompt, konteks hasil pencarian, berkas, atau hasil alat membesar?
• Ukuran output: apakah batas respons atau putaran agen menghasilkan lebih banyak output?
• Status dan percobaan ulang: apakah kegagalan menyebabkan percobaan tambahan yang selesai?
• Waktu: apakah generasi yang lebih lama menghasilkan output lebih banyak atau hanya menunggu?

Pisahkan beban kerja dengan ID permintaan yang stabil atau kunci khusus aplikasi; jangan membandingkan trafik akun yang tidak berkaitan.

Tetapkan batas biaya yang praktis

Pisahkan kunci berdasarkan beban kerja

Gunakan kunci berbeda untuk produksi, pengembangan, otomatisasi, dan alat pribadi. Setiap kunci dapat memiliki nama, masa berlaku, kebijakan grup, serta kuota terbatas atau tanpa batas.

Pilih grup dengan sengaja

Jangan memilih hanya dari label. Periksa ketersediaan model saat ini, pengali, syarat akses, RPM, dan kebijakan cadangan. Grup utama yang lebih murah dengan cadangan yang sesuai bisa lebih dapat diprediksi daripada pilihan implisit yang sulit dijelaskan.

Kurangi input sebelum membatasi output

Prompt sistem panjang, riwayat percakapan berulang, dokumen hasil pencarian, dan hasil alat sering mendominasi penggunaan input. Hapus konteks yang tidak lagi memengaruhi jawaban dan hindari mengirim ulang data yang sama jika klien dapat merujuk atau menyimpannya dalam cache dengan aman.

Tinjau putaran agen

Satu tindakan pengguna dapat menghasilkan beberapa permintaan model. Lacak setiap putaran alat dan percobaan ulang; jawaban akhir yang terlihat tidak selalu sama dengan satu panggilan API.

Mengapa perkiraan klien dapat berbeda

Tokenizer lokal atau hitungan karakter berguna untuk perencanaan, tetapi dapat berbeda dari penggunaan tertagih karena:

• penyedia menormalisasi atau menghitung konten secara berbeda;
• cache, penalaran, gambar, audio, dan alat dapat memiliki tarif terpisah;
• penyelesaian menggunakan model dan grup yang benar-benar terpilih;
• kegagalan dan pengembalian dana bergantung pada siklus permintaan nyata;
• harga dapat berubah sementara permintaan lama mempertahankan hasil tercatat.

Untuk pemeriksaan keuangan, cocokkan catatan penggunaan dan dompet yang tersimpan. Jangan menghitung kembali saldo akun dari satu kolom tampilan.

Proses peninjauan yang dapat diulang

1. Filter log penggunaan ke satu kunci API dan rentang waktu.
2. Kelompokkan permintaan berdasarkan model dan grup terpilih.
3. Bandingkan input, output, status, dan biaya per permintaan.
4. Periksa pencilan berupa percobaan ulang, konteks panjang, putaran alat, atau perpindahan cadangan.
5. Konfirmasi harga dan kebijakan grup saat ini sebelum mengubah perutean.
6. Tetapkan kuota kunci terbatas jika beban kerja memerlukan batas pengeluaran keras.
7. Periksa kembali metrik yang sama setelah perubahan.

Kontrol biaya dimulai dari atribusi. Selama model, grup, penggunaan, dan hasil permintaan tetap terhubung, tim dapat mengoptimalkan sumber pengeluaran yang sebenarnya alih-alih menebak dari total agregat.