Menghitung biaya token LLM per request

Panduan production: Menghitung biaya token LLM per request. Panduan ini memuat artefak deterministik, batas kegagalan, kontrol rollout, dan sumber terverifikasi.

Keputusan lebih dahulu

Menghitung biaya token LLM per request adalah kontrak production yang eksplisit, bukan perubahan terpisah. Tetapkan sukses, gagal terminal, dan rollback sebelum memindahkan traffic; artefak memisahkan bukti dari asumsi.

Mulai dari usage_source, buktikan input dengan kasus deterministik, dan jadikan settlement sebagai release gate.

Artefak yang dapat digunakan ulang

Satu baris hanya lolos bila buktinya berasal dari request, jendela pengujian, atau versi konfigurasi yang sama.

Checkpoint	Bukti yang disimpan	Syarat lulus
usage_source	provider_usage_or_named_normalization_rule	Owner, sumber, tanggal, dan batas tercatat.
input	uncached_input_tokens_after_category_separation	Nilai dipertahankan dan dibandingkan tepat di batas wire.
cache	cache_read_and_cache_write_token_categories	Nilai dipertahankan dan dibandingkan tepat di batas wire.
output	visible_and_reasoning_output_under_the_owned_price_rule	Nilai dipertahankan dan dibandingkan tepat di batas wire.
formula	versioned_coefficients_in_currency_per_one_million_tokens	Owner, sumber, tanggal, dan batas tercatat.
settlement	reserve->actual_usage->idempotent_final_charge/refund	Reserve, observasi, dan nilai final cocok di ledger persisten.

Contoh terhitung

Contoh memakai data sintetis dan deterministik. Ganti dengan nilai workload yang ditinjau; jangan masukkan secret atau data pelanggan.

input_tokens = 1200
cache_read_tokens = 800
cache_write_tokens = 0
output_tokens = 300

cost = (input_tokens * input_rate
      + cache_read_tokens * cache_read_rate
      + cache_write_tokens * cache_write_rate
      + output_tokens * output_rate) / 1_000_000

round_at = owned_currency_or_quota_boundary

Prosedur implementasi

1. Bekukan request, response, konfigurasi, dan baseline observasi.
2. Jalankan kasus positif deterministik dan simpan hasil lengkap.
3. Jalankan kasus negatif atau batas pasangannya.
4. Hubungkan semua attempt ke satu request ID logis dan catat waktu, status akhir, serta usage tanpa konten sensitif.
5. Rollout hanya ke kohort terbatas dengan kondisi berhenti.
6. Baca ulang state persisten dan perilaku publik; rollback bila invariant gagal.

Mode kegagalan

Kegagalan berikut membatalkan hasil meski HTTP luar tampak berhasil:

• Harga atau kontrak volatil tidak diperiksa ulang.
• Tanpa reserve atomik, request bersamaan melewati limit.
• Satu field praktis dibaca sementara output bertipe, tool, penolakan, atau hasil parsial hilang.
• Biaya bersama dialokasikan sehingga total tidak dapat direkonsiliasi.

Batas Modelflare

Modelflare memusatkan routing kompatibel OpenAI, key, group, usage, dan penanganan gagal, tetapi rute terkonfigurasi bukan bukti semua kemampuan provider. Verifikasi model dan channel lewat protokol native, pertahankan nol eksplisit, dan gunakan settlement persisten sebagai kebenaran billing.

Gunakan panduan induk untuk batas keputusan dan dokumentasi untuk konfigurasi client terkini.

Checklist sebelum publikasi

• Jawab pertanyaan utama sebelum latar belakang.
• Tetapkan owner untuk setiap field, state, metric, dan formula.
• Gunakan identifier sintetis saja.
• Pertahankan struktur, kode, batas, dan peringatan di semua bahasa.
• Periksa ulang kontrak, dukungan, dan harga pada T-1; pindahkan tanggal jika fakta berubah.
• Sebelum waktunya, keluarkan dari public API, rute, dan sitemap.

Sumber dan tanggal verifikasi

Sumber diperiksa pada 2026-08-07 dan tidak membuktikan rute yang belum diuji.

• OpenAI: API pricing
• OpenAI: Prompt caching