Token ve Faturalandırma: Tahmin, Okuma, Bütçe ve Örnekler

Token nedir ve nasıl hesaplanır

Token, modelin metin işleme için kullandığı en küçük birimdir; ne harf ne de kelimedir, aradaki "parçacıklardır". Bunu su sayacındaki kadran olarak düşünün: ne kadar çok kullanırsanız kadran o kadar hızlı ilerler. Faturalandırma iki kısımdan oluşur:

Çıktı birim fiyatının girdi fiyatının dört katı olduğunu unutmayın; bu nedenle modelin "az konuşmasını" sağlamanız, size "az bağlam göndermenize" göre genellikle daha ucuzdur. Ancak sohbet senaryolarında girdi geçmiş nedeniyle şişer, bu yüzden iki ucu da yönetmelisiniz. Ödeme yöntemi abonelik değil ön ödemeli bakiyedir; bakiye süresi dolmaz. Yeni hesaplara $0.50 deneme kredisi verilir, 7 gün geçerlidir.

Kafa karıştırıcı bir detay: Çıktı tokenları, modelin gerçekten ürettiği miktardır, ayarladığınız max_tokens değeri değildir. max_tokens yalnızca bir üst sınırdır; model 200 kelimeyle yanıt verirse, yalnızca o 200 kelimeye karşılık gelen tokenlar için ödersiniz. Ancak bütçe öngörüsü yaparken en kötü durumu hesaplamak için üst sınırı kullanmalısınız, böylece beklenmedik uzun çıktılar sizi şaşırtmaz.

Ön tahmin: Çince ve İngilizce nasıl tahmin edilir

İstek gönderilmeden önce yalnızca tahmin yapılabilir. Aşağıdakiler yaklaşık değerlerdir, içeriğe göre değişkenlik gösterebilir:

Tahminin doğru kullanımı "büyüklük"判断 yapmaktır: Bu metin yaklaşık 10.000 mi yoksa 100.000 mi token? 100.000 bağlam penceresini doldurur mu? Bir çağrı yaklaşık kaç para eder? Hassas sonuç için usage alanını okuyun. İyi bir alışkanlık, her iş senaryosu için onlarca örneklem çalıştırıp usage ortalamasını almaktır; bu ortalama deneyim değeriniz yerine kullanılmalıdır.

Tahmin ile ölçümü birleştiren bir örnek verelim. Diyelim ki yaklaşık 2000 karakterlik Çin müşteri geri bildirimlerini işleyeceksiniz. Karakter başına 1.3 token varsayarak tek bir istek yaklaşık 2600 token tutar. Talimatlarınız 200 token ise girdi yaklaşık 2800 olur. İlk olarak 30 isteği çalıştırıp usage ortalamasını okuyun. Ortalama ölçüm 2500 ise, katsayınızı yaklaşık 1.15 olarak düzeltin. Sonraki toplu işlemlerde bütçeyi düzeltilmiş katsayıya göre hesaplayın; hata payı çok daha düşük olur. Bu ölçüm değeri yalnızca yöntemi göstermek içindir; verileriniz kendi değerlerine sahip olacaktır.

Usage okuma: Gerçek sayaç okuması

Her başarılı response usage alanı içerir; bu alan prompt_tokens, completion_tokens ve total_tokens değerlerini içerir. Streaming (akış) yanıtları için ek parametre gerekmez; son bloğa otomatik olarak usage içeren bir blok eklenir. Aşağıdaki kod her iki okuma yöntemini ve okumaların dolar cinsinden dönüşümünü gösterir:

复制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}")

Streaming sırasında dikkat edin: Yalnızca son bloktaki usage değerini doldur, önceki bloklarda boştur. Bu nedenle if chunk.usage ile kontrol etmek yeterlidir. Her okumayı günlük veya veritabanına kaydedin; ay sonunda fatura kesme, anormallik tespiti ve kullanıcı başına maliyet hesaplama için bu kayıtlara ihtiyacınız olacaktır.

Geliştirilmesi gereken bir alışkanlık daha: Her iş özelliğine etiket verin ve faturalandırma sırasında birlikte kaydedin. "Özet", "Müşteri Hizmetleri", "Çeviri" gibi özellikleri ayrı ayrı takip edin. Ay sonunda faturaya bakarak hangi özelliğin en çok para harcadığını görün; Prompt'u mu optimize etmeli, geçmişi mi kısaltmalı yoksa max_tokens'i mi düşürmeli karar verin. Etiket yoksa yalnızca toplam sayı vardır ve optimizasyon yapmak zordur.

Üç örnek (varsayımlar belirtilmiştir)

Örnek 1: Müşteri hizmetleri soru-cevap

Varsayım: Her istekte 800 token girdi (system ve bilgi parçaları dahil) ve 200 token çıktı; günde 10.000 istek.

Tek seferlik maliyet: Girdi 800 × 0,25 ÷ 1.000.000 = $0,0002, çıktı 200 × 1,00 ÷ 1.000.000 = $0,0002, toplam $0,0004. Günlük $4,00, 30 günlük $120. Bu hızla $0,50'lik deneme kredisi yaklaşık 1250 çağrıyı karşılayabilir.

Örnek 2: Uzun metin özetleme

Varsayım: Her makale için 20.000 token girdi, 600 token özet çıktı; toplam 500 makale.

Tek makale: Girdi 20.000 × 0,25 ÷ 1.000.000 = $0,005, çıktı 600 × 1,00 ÷ 1.000.000 = $0,0006, toplam $0,0056. 500 makale için toplam $2,80. Görüldüğü gibi uzun girdi ve kısa çıktı gerektiren görevler oldukça ucuzdur.

Örnek 3: Çoklu sohbet ve geçmiş kırpma

Varsayım: system 100 token; her turda kullanıcı girdisi 60 token, yanıt 150 token; bir sohbet 20 tur.

Tüm geçmişi dahil etme çözümünde girdi: 20 × (100 + 60) + 210 × (0 + 1 + … + 19) = 3.200 + 39.900 = 43.100. Kırpma çözümünde ilk üç tur sırasıyla 160, 370 ve 580 token iken, 4. ile 20. turlar arasında her tur 790 token olup toplam 14.540 token eder. Maliyetler yaklaşık olarak yarı yarıya fark yaratır ve tur sayısı arttıkça bu fark daha da büyür, çünkü tüm geçmişi dahil etme çözümünde girdi miktarı turların karesiyle orantılı olarak artar.

Bu üç örnekten çıkarılacak temel formül şudur: Maliyet büyük ölçüde "istek sayısı × her istekteki girdi/çıktı miktarı" ile belirlenir. Her istekteki girdi miktarını etkileyen en önemli faktör geçmiş ve eklenen materyallerdir. Müşteri hizmetleri senaryosunda bilgi parçalarının uzunluğunu kısaltmak, sohbet senaryosunda geçmişi kırpma ve özet senaryosunda parçalı paralel istekler göndermek aynı mantığa dayanır: Gereksiz token'lar için para ödemeyin. Vurgulamak gerekir ki, bu örneklerdeki sayılar yukarıda belirtilen varsayımlardan elde edilmiştir; gerçek verileriniz için lütfen usage (kullanım) verilerine bakın.

Tersine bir hesaplama yapalım: Aylık bütçeniz $30 ise, sohbet ürününüzün 20 turlu kaç sohbeti karşılayabileceğini hesaplayın. Örnek 3'teki "sadece son 3 tur" çözümüyle, sohbet başına yaklaşık $0,0066 tutarında maliyet oluşur. $30 ÷ 0,0066 yaklaşık 4545 sohbet demektir. Aynı bütçeyle tüm geçmişi dahil etme çözümünü kullansaydınız, sohbet başına $0,0138 tutarında maliyet oluşur ve bu bütçe yaklaşık 2174 sohbet için yeterdi. İşte geçmiş kırpmanın sağladığı somut fark budur.

Bütçe kontrolü: Programınıza bütçe kilidini takın

Tahmin sadece bir öngörüdür; asıl sigorta kilittir. Aşağıda dolar cinsinden günlük bütçe sınıfı örneği verilmiştir: İstek öncesi "kötü durum" varsayımıyla tahmin yapın (çıkış max_tokens değerine ulaşır), istek sonrası gerçek usage ile hesaplayın.

复制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)                        # 请求后

Program içindeki kilitlere ek olarak, yapılandırma düzeyinde üç yöntem daha mevcuttur:

1. max_tokens değerini görevinize göre ayarlayın, her zaman maksimuma çekmeyin; varsayılan değer 2048, maksimum 32.000'dir;
2. Sohbet geçmişine uzunluk sınırı koyun; chatbot geliştirme bölümündeki uygulamaya bakın;
3. Hesabınıza yalnızca kullanmayı planladığınız tutarı yükleyin, bittiğinde tekrar yükleyin. Ön ödemeli model zaten doğal bir üst sınır oluşturur.

Birim fiyat ve bakiye kuralları Fiyat sayfası'na göre geçerlidir; API detayları Parametre detayları'da yer alır.

Son olarak bir kontrol listesi hazırladık: Öncesi, tahmin büyüklüğü, max_tokens ayarı, geçmiş uzunluk kontrolü; Sırası, akış çıktısında son bloğun usage değerine dikkat; Sonrası, hesap tutma, işleve göre sınıflandırma ve bütçe karşılaştırması. Bu üç adımı tamamladığınızda hesap netleşir.