Token dan biaya API LLM besar: estimasi, pembacaan, anggaran, dan contoh kasus

Apa itu token dan cara menghitung biayanya

Token adalah unit pengukuran terkecil yang diproses model untuk teks, bukan karakter maupun kata, melainkan "fragmen" di antaranya. Bayangkan ini sebagai skala pada meteran air: semakin banyak digunakan, semakin cepat skala bergerak. Biaya dibagi menjadi dua bagian:

Perhatikan bahwa harga output empat kali lipat input, sehingga membuat model "berbicara lebih sedikit" sering lebih hemat daripada Anda "mengirim konteks lebih sedikit". Namun, dalam skenario percakapan, input akan membengkak karena akumulasi riwayat, jadi kedua sisi harus dikelola. Metode pembayaran adalah saldo prabayar, bukan langganan, dan saldo tidak akan kedaluwarsa. Akun baru mendapatkan saldo uji coba gratis $0,50 yang berlaku selama 7 hari.

Catatan penting: token output adalah jumlah yang benar-benar dihasilkan model, bukan nilai max_tokens yang Anda atur. max_tokens hanya batas atas; jika model selesai dalam 200 token, Anda hanya membayar untuk 200 token tersebut. Namun, saat membuat anggaran, hitung berdasarkan batas atas untuk mengantisipasi skenario terburuk agar tidak kaget oleh output panjang yang jarang terjadi.

Estimasi awal: cara mengestimasi token bahasa Mandarin dan Inggris

Sebelum mengirim permintaan, hanya bisa memperkirakan. Di bawah ini adalah nilai perkiraan, yang dapat bervariasi tergantung konten:

Penggunaan estimasi yang benar adalah untuk "penentuan orde besaran": apakah artikel ini sekitar 10.000 atau 100.000 token, apakah akan melebihi jendela konteks 100.000, dan berapa biaya per panggilan. Untuk presisi, baca usage. Kebiasaan baik adalah melakukan sampling puluhan kali untuk setiap skenario bisnis, menghitung rata-rata usage, dan menggunakannya sebagai pengganti nilai pengalaman.

Sebagai contoh yang menggabungkan estimasi dan pengujian nyata. Misalkan Anda memproses sekumpulan umpan balik pelanggan bahasa Mandarin sekitar 2000 karakter. Dengan estimasi 1,3 token per karakter, satu permintaan sekitar 2600 token. Ditambahkan instruksi Anda 200 token, total input sekitar 2800. Pilih 30 permintaan untuk dijalankan, baca usage untuk rata-rata. Jika rata-rata pengujian nyata adalah 2500, sesuaikan koefisien Anda menjadi sekitar 1,15. Anggaran untuk seluruh batch kemudian dihitung berdasarkan koefisien yang disesuaikan, sehingga kesalahan menjadi jauh lebih kecil. Angka pengujian nyata ini hanya asumsi untuk mendemonstrasikan metode; data Anda akan memiliki nilai sendiri.

Membaca usage: "pembacaan meter" yang sebenarnya

Setiap respons sukses menyertakan usage yang berisi prompt_tokens, completion_tokens, dan total_tokens. Respons streaming tidak memerlukan parameter tambahan; blok data berisi usage akan ditambahkan secara otomatis di akhir. Kode di bawah mendemonstrasikan kedua cara membaca ini dan mengonversi nilai ke dolar:

复制import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apidamoxing.com/v1", api_key=os.environ["API_KEY"])
PRICE_IN, PRICE_OUT = 0.25, 1.00     # 美元 / 百万 token

def cost(u):
    return (u.prompt_tokens * PRICE_IN + u.completion_tokens * PRICE_OUT) / 1_000_000

# 非流式：usage 在响应对象上
r = client.chat.completions.create(
    model="uncensored", max_tokens=200,
    messages=[{"role": "user", "content": "用三句话解释什么是通货膨胀。"}],
)
print(r.usage.prompt_tokens, r.usage.completion_tokens, f"${cost(r.usage):.6f}")

# 流式：最后一个数据块带 usage，其余块的 usage 为空
usage_last = None
stream = client.chat.completions.create(
    model="uncensored", max_tokens=200, stream=True,
    messages=[{"role": "user", "content": "再用三句话解释什么是通货紧缩。"}],
)
for chunk in stream:
    if chunk.usage:
        usage_last = chunk.usage
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
print()
if usage_last:
    print(usage_last.prompt_tokens, usage_last.completion_tokens, f"${cost(usage_last):.6f}")

Perhatian saat streaming: hanya blok terakhir yang memiliki usage; blok sebelumnya kosong. Gunakan if chunk.usage untuk pengecekan. Simpan setiap pembacaan ke log atau database. Catatan ini menjadi kunci untuk rekonsiliasi akhir bulan, deteksi anomali, dan perhitungan biaya per pengguna.

Kebiasaan lain yang layak dikembangkan: beri label setiap fungsi bisnis dan catat bersama saat pembukuan. Misalnya, catat "ringkasan", "layanan pelanggan", "terjemahan" secara terpisah. Saat rekonsiliasi akhir bulan, Anda dapat melihat fungsi mana yang paling mahal, apakah perlu mengoptimalkan prompt, memotong riwayat, atau menurunkan max_tokens. Tanpa label, hanya ada total tunggal, sehingga sulit untuk melakukan optimasi.

Tiga contoh kasus (asumsi dituliskan di atas)

Contoh kasus 1: Tanya jawab layanan pelanggan

Asumsi: Setiap permintaan input 800 token (termasuk system dan cuplikan pengetahuan), output 200 token; 10.000 kali per hari.

Biaya per panggilan: 800 × 0,25 ÷ 1.000.000 = $0,0002; output 200 × 1,00 ÷ 1.000.000 = $0,0002; total $0,0004. $4,00 per hari, $120 per 30 hari. Dengan kecepatan ini, saldo uji coba $0,50 dapat mendukung sekitar 1250 panggilan seperti ini.

Contoh kasus 2: Ringkasan artikel panjang

Asumsi: Setiap artikel input 20.000 token, output ringkasan 600 token; total 500 artikel.

Per artikel: 20.000 × 0,25 ÷ 1.000.000 = $0,005, ditambah 600 × 1,00 ÷ 1.000.000 = $0,0006, total $0,0056. 500 artikel total $2,80. Terlihat bahwa tugas dengan input panjang dan output pendek sangat murah.

Contoh kasus 3: Obrolan multi-giliran dan pemangkasan riwayat

Asumsi: system 100 token; setiap giliran input pengguna 60 token, balasan 150 token; satu percakapan 20 giliran.

Input skema riwayat lengkap adalah: 20 × (100 + 60) + 210 × (0 + 1 + … + 19) = 3.200 + 39.900 = 43.100. Skema pemangkasan tiga giliran pertama masing-masing 160, 370, 580, giliran ke-4 hingga ke-20 masing-masing 790, total 14.540. Biaya berbeda sekitar setengahnya, dan semakin banyak giliran, semakin besar perbedaannya, karena input skema riwayat lengkap tumbuh secara kuadratik seiring jumlah giliran.

Dari tiga contoh ini dapat disimpulkan rumus pengalaman: biaya terutama ditentukan oleh "jumlah permintaan × jumlah input dan output per permintaan", dan dalam jumlah input per permintaan, riwayat dan materi tambahan adalah bagian yang paling bisa dioptimalkan. Mengurangi panjang cuplikan pengetahuan dalam skenario layanan pelanggan, memangkas riwayat dalam skenario obrolan, dan mempartisi secara paralel dalam skenario ringkasan, semuanya mengikuti prinsip yang sama: jangan membayar token yang tidak perlu. Perlu ditekankan bahwa angka dalam tiga contoh kasus ini sepenuhnya berasal dari asumsi yang dituliskan di atas; data aktual Anda harus mengacu pada usage.

Mari kita lakukan perhitungan mundur: jika anggaran bulanan Anda $30, berapa banyak sesi percakapan 20 putaran yang dapat didukung? Berdasarkan skenario "hanya 3 putaran terakhir" dari contoh 3, biaya per sesi sekitar $0,0066. Dengan $30, Anda dapat menjalankan sekitar 4545 sesi. Dengan skenario "riwayat lengkap", biaya per sesi $0,0138, sehingga hanya cukup untuk sekitar 2174 sesi. Inilah perbedaan nyata dari pemangkasan riwayat.

Pengendalian anggaran: Pasang gerbang pada program Anda

Estimasi hanyalah prediksi, gerbang adalah asuransi. Di bawah ini adalah kelas anggaran harian berbasis dolar: sebelum permintaan, prakiraan "kasus terburuk" (output menggunakan penuh max_tokens), setelah permintaan, pencatatan biaya berdasarkan usage aktual.

复制class Budget:
    """按美元计的日预算。超出时拒绝新请求。"""
    def __init__(self, daily_usd):
        self.limit = daily_usd
        self.spent = 0.0

    def check(self, est_prompt_tokens, max_tokens):
        # 最坏情况：输出用满 max_tokens
        worst = (est_prompt_tokens * 0.25 + max_tokens * 1.00) / 1_000_000
        if self.spent + worst > self.limit:
            raise RuntimeError(f"预算不足：已用 ${self.spent:.4f}，本次最坏 ${worst:.4f}，上限 ${self.limit}")

    def record(self, usage):
        self.spent += (usage.prompt_tokens * 0.25 + usage.completion_tokens * 1.00) / 1_000_000

budget = Budget(daily_usd=5.0)
budget.check(est_prompt_tokens=1200, max_tokens=500)   # 请求前
# ……发请求……
# budget.record(response.usage)                        # 请求后

Selain gerbang dalam program, ada tiga cara pada tingkat konfigurasi:

1. Atur max_tokens sesuai tugas, jangan selalu ditarik ke batas atas, default 2048, maksimum 32.000;
2. Atur batas panjang riwayat percakapan, lihat cara di Membuat bot obrolan;
3. Di akun, hanya isi saldo sesuai jumlah yang Anda rencanakan untuk digunakan, isi ulang setelah habis, mode prabayar secara alami merupakan batas atas yang keras.

Harga satuan dan aturan saldo mengacu pada Halaman harga, detail antarmuka ada di Penjelasan parameter.

Pada akhirnya dirangkum menjadi daftar periksa: sebelum memulai, estimasi besaran, atur max_tokens, periksa panjang riwayat; saat berjalan, perhatikan usage blok terakhir saat output streaming; setelah selesai, catat biaya dan klasifikasikan berdasarkan fungsi, bandingkan dengan anggaran. Setelah tiga langkah ini selesai, akun menjadi jelas.