Model karşılaştırmaları · 2026-09-25

Ember-1 bağlam, cache ve kullanım maliyeti

Ember-1'in 1.048.576 tokenlık bağlam penceresi, otomatik prompt cache'i ve üç fiyat kalemi: önbelleksiz girdi, cache okuma ve çıktı. Cache'in nasıl tetiklendiğini, bir isteğin maliyetinin nasıl hesaplandığını ve akışta kullanımın ne zaman geldiğini anlatır.

Uzun bir istemin sabit önekinin cache'ten okunduğunu, yalnızca yeni kısmın tam fiyatla ücretlendirildiğini ve iki durumun maliyetini yan yana gösteren hesap tablosu.

Kısa cevap

Ember-1'in bağlam penceresi 1.048.576 tokendir ve bunun altında ayrı bir çıktı tavanı yoktur. Maliyet üç kalemden oluşur: önbelleksiz girdi 1 milyon token başına 3 dolar, cache'ten okunan girdi 0,30 dolar, çıktı 15 dolar. Tekrarlanan istem önekleri otomatik olarak cache'lenir; bunun için ayrı bir anahtar göndermek gerekmez.

Bu satır 6 Ekim 2026'ya kadar sunulur. Halefi moonshot/kimi-k3 aynı fiyatları ve aynı bağlam penceresini taşır, bu yüzden aşağıdaki hesaplar geçişten sonra da geçerlidir.

Fiyat kalemleri

Katalogdaki fiyatlar sağlayıcının fiyatlarıdır; platform marjı model fiyatlarına eklenmez, yalnızca kredi yüklemede uygulanır. Düşünme tokenları çıktı kaleminde yer alır.

Ember-1 fiyatları (1M token başına, kontrol 26 Eylül 2026)
KalemFiyatNeyi kapsar
Önbelleksiz girdi3,00 $İstemin cache'ten okunmayan kısmı
Cache okuma0,30 $Önceki bir istekle aynı olan önek
Çıktı15,00 $Görünür yanıt ve düşünme tokenları

Cache nasıl devreye girer

Cache, istemin başından itibaren önceki bir istekle birebir aynı olan kısmı için çalışır. Bu yüzden sıralama önemlidir: sistem talimatı, uzun bir belge ve araç tanımları gibi değişmeyen parçalar başa, her istekte değişen soru sona konur. Başa eklenen bir zaman damgası ya da istek numarası, sonrasındaki her şeyin cache'ten okunmasını engeller.

Cache'ten okunan token sayısı yanıttaki usage alanında cached_tokens olarak görünür. Cache her istekte garanti değildir; aynı önekle gelen istekler arasında uzun bir süre geçtiğinde ya da önek değiştiğinde tam fiyat ödenir. Gerçek oran bu alan izlenerek görülür.

Çok turlu sohbetlerde de aynı ilke geçerlidir. Her yeni turda önceki mesajlar değişmeden baştan gönderildiği için konuşma geçmişi büyük ölçüde cache'ten okunabilir ve tam fiyat çoğunlukla yalnızca son tura ödenir. Geçmişi kısaltmak ya da özetlemek ise öneki değiştirir; bundan sonraki ilk istek cache'ten daha az yararlanır.

Örnek hesap

100.000 tokenlık bir istem düşünelim: 90.000 token önceki istekle aynı ve cache'ten okunuyor, 10.000 token yeni. Model 2.000 tokenlık bir çıktı üretiyor. Tablo bu isteği cache'li ve cache'siz olarak karşılaştırıyor; sayılar örnektir.

Cache'li istekte maliyetin en büyük iki kalemi yeni girdi ile çıktıdır. Düşünme açıkken çıktıya düşünme tokenları da eklendiği için, uzun belgeli işlerde bile çıktı kalemi toplamın önemli bir kısmını oluşturabilir. Aynı belgeye günde 50 soru sorulduğunda, bu örnekte cache'in sağladığı fark günde yaklaşık 12 dolardır.

100.000 tokenlık istem, 2.000 token çıktı (örnek hesap)
KalemCache'liCache'siz
Cache okuma90.000 token: 0,027 $Yok
Önbelleksiz girdi10.000 token: 0,030 $100.000 token: 0,300 $
Çıktı2.000 token: 0,030 $2.000 token: 0,030 $
Toplam0,087 $0,330 $

Maliyeti yanıttan hesaplamak

Akışta kullanım bilgisi yalnızca son çerçevede, [DONE] işaretinden hemen önce gelir; stream_options gönderilsin ya da gönderilmesin bu çerçeve bulunur. Bu yüzden bir isteğin kesin maliyeti yanıt tamamlandığında bilinir. Aşağıdaki örnek istemi cache'e uygun sırayla kuruyor ve maliyeti son çerçevedeki kullanımdan hesaplıyor.

Cache'e uygun istem düzeni ve kullanımdan maliyet

PRICE_PER_M = {"input": 3.00, "cache_read": 0.30, "output": 15.00}

def cost_usd(usage: dict) -> float:
    cached = (usage.get("prompt_tokens_details") or {}).get("cached_tokens") or 0
    fresh = usage["prompt_tokens"] - cached
    return (fresh * PRICE_PER_M["input"] + cached * PRICE_PER_M["cache_read"]
            + usage["completion_tokens"] * PRICE_PER_M["output"]) / 1_000_000

# Sabit parcalar once, degisen soru en sonda: onek istekler arasinda ayni kalir.
messages = [
    {"role": "system", "content": SYSTEM_PROMPT},
    {"role": "user", "content": LONG_DOCUMENT},
    {"role": "user", "content": question},
]

stream = client.chat.completions.create(model="fireworks/ember-1", messages=messages, stream=True)
usage = None
for chunk in stream:
    if chunk.usage:
        usage = chunk.usage.model_dump()   # yalnizca son cercevede gelir
    # ... yanit parcalari burada islenir

print(round(cost_usd(usage), 6))

Cache oranını izlemek

Cache'in gerçekten çalışıp çalışmadığı, her istekte cached_tokens değerinin prompt_tokens değerine oranına bakılarak görülür. Aynı belge üzerinde soru soran bir akışta bu oranın yüksek olması beklenir; düşükse önek istekten isteğe değişiyordur. En sık sebepler istemin başına eklenen tarih ve saat, kullanıcıya özel bilgilerin sistem talimatına yazılması ve araç tanımlarının sırasının değişmesidir.

Günlük maliyeti üç kaleme ayırarak izlemek, hangi kalemin büyüdüğünü gösterir. Önbelleksiz girdinin artması önekteki bir değişikliğe, çıktının artması daha uzun yanıtlara ya da düşünme izlerine işaret eder.

Uzun bağlamı kullanmak

1 milyon tokenlık bir pencere, her şeyin tek isteğe konması gerektiği anlamına gelmez. Sistem talimatı, konuşma geçmişi, araç sonuçları, yeni girdi ve üretilecek çıktı aynı pencereyi paylaşır. Uzun bir belge üzerinde çok sayıda soru soruluyorsa, belgeyi sabit önekte tutup soruları sona eklemek cache sayesinde hem maliyeti hem bekleme süresini düşürür.

Ayrı bir çıktı tavanı olmadığı için max_tokens değeri pencerenin kalanına kadar verilebilir; ama çıktı en pahalı kalemdir. Görevin gerektirdiği uzunlukta bir sınır koymak, beklenmedik uzunlukta bir yanıtın maliyeti büyütmesini önler.

Sık sorulan sorular

Cache için prompt_cache_key göndermem gerekir mi?

Hayır. Ember-1'de tekrarlanan önekler otomatik olarak cache'lenir. Cache'ten okunan token sayısı usage alanında cached_tokens olarak görünür.

Ember-1'in çıktı tavanı var mı?

Bağlam penceresinin altında ayrı bir çıktı tavanı yoktur. İstem ve çıktı birlikte 1.048.576 tokenı aşamaz; max_tokens görevin ihtiyacına göre sınırlanır.

Akışta maliyet ne zaman belli olur?

Kullanım bilgisi son çerçevede, [DONE] işaretinden önce gelir. Kesin maliyet yanıt tamamlandığında hesaplanır.

Kimi K3'e geçince maliyet değişir mi?

Fiyatlar ve bağlam aynıdır. Değişebilecek olan token sayısıdır: moonshot/kimi-k3'ün aynı görevde daha uzun bir düşünme izi üretmesi çıktı kalemini artırabilir.

Cache'ten okunan tokenlar iki kez mi ücretlendirilir?

Hayır. cached_tokens, prompt_tokens'ın bir parçasıdır. Cache'ten okunan kısım 0,30 dolardan, geri kalanı 3 dolardan ücretlendirilir; aynı token iki kalemde birden sayılmaz.

İlgili yazılar