Oyun Geliştiricileri Uzun Yapay Zeka Diyaloglarının Maliyetini Nasıl Tahmin Edebilir?

1. Tahmin ettiğiniz birimi tanımlayın

Öncelikle net bir birim seçin: örneğin diyalog oturumu başına, aktif oyuncu-gün başına veya 1.000 oturum başına model çıkarım maliyeti. Bir oturum tahmini için oturumun ne zaman başlayıp ne zaman bittiğini tanımlayın. Pratik bir kural "ilk diyalog isteğinden istek gelmeden geçen 30 dakikaya kadar" olabilir; ancak bu zaman aşımı evrensel bir standart değil, bir ölçüm tercihidir. Başka bir geliştiricinin tahmini yeniden üretebilmesi için bunu kaydedin.

Yalnızca oyuncu mesajlarını değil, model isteklerini sayın. Tek bir etkileşim birden fazla çağrıyı tetikleyebilir—örneğin, bir yanıtın ardından ayrı bir araç işleme (tool-handling) çağrısı gelebilir—ve yeniden denemeler (retries) daha fazlasını ekleyebilir. Oyun ses, görsel girdi, bilgi getirme (retrieval) veya araçlar kullanıyorsa, ilişkili model token'larını kaydetmenin yanı sıra bunları ayrı maliyet alanlarında tutun. Sağlayıcı fiyatlandırması, normal metin token ücretlerine ek olarak araç ücretlerini veya modaliteye özgü tarifeleri içerebilir; örneğin OpenAI, ayrı araç ücretleri listeler ve yerleşik araçlar için kullanılan model token'larının seçilen modelin tarifeleri üzerinden faturalandırıldığını belirtir (OpenAI API pricing).

2. İstek başına gerçek token'ları ölçün

Her çağrı için sağlayıcıyı, model tanımlayıcısını, zaman damgasını, oturum tanımlayıcısını, istek amacını, girdi token sayısını, çıktı token sayısını ve bildirilen tüm önbelleğe alınmış token veya akıl yürütme (reasoning) token dökümlerini günlüğe kaydedin (log). Yeniden denemeleri, hataları, araç çağrılarını ve çağrının tamamlanıp tamamlanmadığını yakalayın. Ayrı olarak gerekçelendirilmiş bir ürün amacı için gerekmediği sürece diyalog içeriğini depolamaktan kaçının; token toplamları ve operasyonel meta veriler genellikle bir maliyet tahmini için yeterlidir.

Birincil ölçüm olarak tamamlanan çağrılardan sağlayıcı tarafından bildirilen kullanımı esas alın. Gönderim öncesi sayım (preflight counting) prompt yapısını test etmek için yararlıdır, ancak nihai faturalandırma alanlarıyla eşleşmeyebilir. OpenAI, bildirilen çıktının bazı biçimlendirme ve araç yapısı token'ları gibi görünür metnin ötesindeki token'ları da içerdiğini belgeler ve çıktıyı yalnızca bir oyuncunun gördüklerine dayanarak tahmin etmemeyi önerir (OpenAI token-counting guide). Google'ın Gemini belgeleri de benzer şekilde kullanım meta verilerinde prompt, önbelleğe alınmış içerik, aday çıktı ve düşünme (thinking) token sayılarını ayrıştırır (Gemini token guide).

Yeni oyuncuları, geri dönen oyuncuları, kısa ve uzun konuşmaları, prodüksiyon prompt'unu ve araç yapılandırmasını içeren temsili bir örneklem oluşturun. Oturumları örnekleme birimi olarak tutun: 40 turluk bir diyalog, 40 bağımsız oyuncu oturumu olarak ele alınmak yerine, birikmiş maliyetiyle birlikte tek bir gözlem olarak kalmalıdır. Prototip aşamasında, sabit bir senaryolu konuşma seti prompt değişikliklerini karşılaştırmaya yardımcı olur; lansmandan sonra ise tahmini yönlendiren gözlemlenen oturumlar olmalıdır.

3. Geçmişin büyümesini ve bağlamın yeniden kullanımını hesaba katın

Birçok diyalog sisteminde her istek, mevcut kullanıcı turunun yanı sıra konuşma geçmişinin bir kısmını veya tamamını içerir. Geçmiş tekrar tekrar gönderiliyorsa, her bir oyuncu mesajı kısa olsa bile girdi token'ları her turda büyüyebilir. Modele gönderilen gerçek istek yükünü (payload) ölçün; uygulama gerçekten her seferinde aynı miktarı göndermiyorsa tek turluk prompt boyutunu tur sayısıyla çarpmayın.

Önbelleğe alma (caching), uygun durumdaki tekrarlanan girdiye uygulanan tarifeyi değiştirir; bu, tüm diyaloğun ücretsiz hale geldiği veya kalıcı bir oturumun önbellek isabetini (cache hit) garanti ettiği anlamına gelmez. OpenAI, prompt önbelleğe almayı değiştirilmemiş bir prompt önekini yeniden kullanmak olarak tanımlar ve yeni girdinin yine de işlenmesi gerektiğini belirtir. Önbellek tanılamaları, önbellek okumalarını ve ıskalamalarını ölçmeye yardımcı olabilir (OpenAI prompt-caching guide). Anthropic de benzer şekilde önbellek yazmalarını önbellek okumalarından ayırır ve ayrı tarifeler ile önbellek süreleri yayınlar (Anthropic pricing and prompt caching).

Telemetrinizde, sağlayıcı bildirdiğinde önbelleğe alınmamış girdi token'larını, önbelleğe alınmış girdi token'larını ve önbelleğe yazma token'larını ayrıştırın. Önbellek isabetlerinin uygun isteklere oranını ve fiilen önbelleğe alınmış olarak faturalandırılan girdi token'larının payını kaydedin. Bunlar farklı soruları yanıtlar: istekler genelinde yüksek bir isabet oranı, tekrarlanan önek küçükse toplam token'ların mütevazı bir kısmının önbelleğe alındığı anlamına gelebilir. Önbelleğe uygunluk, minimum boyutlar, sona erme süreleri, prompt öneki kararlılığı ve model desteği sağlayıcıya özgüdür; yalnızca kullanım verileriyle doğrulanan tasarrufları hesaba katın.

4. Ücretleri şeffaf bir hesaplama ile uygulayın

Milyon token başına fiyatlandırılan bir model için her oturumu şu şekilde hesaplayın:

oturum maliyeti = (önbelleğe alınmamış girdi × girdi tarifesi + önbelleğe alınmış girdi × önbelleğe alınmış girdi tarifesi + önbellek yazmaları × önbellek yazma tarifesi + çıktı × çıktı tarifesi) ÷ 1.000.000 + geçerli diğer ücretler

Dağıtılan yapılandırmadaki tam model, uç nokta (endpoint), modalite, bölge ve hizmet katmanına ait tarifeleri kullanın. Bir bütçe hazırlamadan hemen önce bunları sağlayıcının fiyatlandırma sayfasından bağımsız olarak kontrol edin; tarifeler ve model katalogları değişebilir. Bir önbelleğin depolanan token'lar ve süre için fatura kestiği durumlarda depolama ücretlerini de dahil edin. Örneğin Gemini'ın yayınlanan fiyatlandırması, ücretli kullanım için token kategorilerini ve belirli bağlam önbelleğe alma (context-caching) yapılandırmaları için depolama-saat fiyatlandırmasını listelerken, faturalandırma belgeleri girdi, çıktı, önbelleğe alınmış token'lar ve önbellek depolama süresini faturalandırılabilir faktörler olarak tanımlar (Gemini pricing; Gemini billing).

İşlenmiş somut bir hesaplama, varsayımları görünür kılar. Tamamen örnekleme amacıyla, tek bir oturuma atanan ölçülen çağrıların 18.000 önbelleğe alınmamış girdi token'ı, 12.000 önbelleğe alınmış girdi token'ı ve 6.000 çıktı token'ı içerdiğini varsayalım. 31 Aralık 2026'ya kadar geçerli olmak üzere yayınlanan Gemini 3.8 Flash ücretli katman tarifelerini uyguladığımızda—milyon girdi token'ı başına 0,75 $, milyon önbelleğe alınmış token başına 0,075 $ ve milyon çıktı token'ı başına 3,75 $—geçerli olabilecek önbellek depolama veya diğer ücretlerden önce 0,0135 $ + 0,0009 $ + 0,0225 $, yani 0,0369 $ sonucunu verir. Bu örnek, listelenen önbelleğe alınmış token'ların önbellek tarifesinden faturalandırıldığını varsayar ve ölçülen toplamların dışındaki herhangi bir ilk önbellek oluşturma maliyetini içermez. Tarifeler süreye bağlıdır ve daha sonraki bir dönem tahmin edilirken tekrar kontrol edilmelidir (Gemini pricing).

5. Oturum uzunluklarının dağılımını kullanın

Özenle seçilmiş tek bir "tipik" oturumu toplam oyuncu sayısıyla çarpıp buna tahmin demeyin. Gözlemlenen oturumları tur sayısına veya başka bir kullanışlı uzunluk aralığına göre gruplandırın, her aralıktaki ortalama maliyeti hesaplayın, ardından her aralığı oturumlar içindeki payına göre ağırlıklandırın. Ortalamanın yanında medyanı ve üst yüzdelik dilimleri (percentile) de tutun: ortalama, oturum hacmiyle çarpıldığında toplam kullanımı tahmin ederken; yüzdelik dilimler daha kısa veya alışılmadık derecede uzun bir oturumun ne kadara mal olabileceğini açıklamaya yardımcı olur.

Örneğin, bir örneklem çok sayıda kısa oturuma ve az sayıda çok uzun oturuma sahipse, hem her aralıktaki oturumların payını hem de her aralığın maliyetini bildirin. 10.000 oturumluk bir tahmin, her oturumun genel medyana benzediğini varsaymak yerine, aralıktaki oturumlar × aralıktaki ortalama maliyet toplamı olarak hesaplanabilir. Kullanım; oyun modu, dil, platform veya yeni ve geri dönen oyuncular arasında önemli ölçüde farklılık gösteriyorsa, bunları birleştirmeden önce tabakalara ayırın (stratify). Segmentlere ayırma tercihi bir analiz kararıdır; her segmentin token kullanımını veya istek davranışını neden değiştirebileceğini açıklayın.

6. Belirsizliği belgeleyin ve tahmini güncelleyin

Örneklem tarihlerini, oturum sınırı kuralını, modelleri ve uç noktaları, prompt sürümünü, gözlemlenen oturum sayılarını, önbellek isabeti tanımını, fiyat sayfasının kontrol tarihini, dahil edilen ücretleri ve hariç tutulan bileşenleri içeren derli toplu bir varsayımlar kaydı tutun. Açıklanamayan bir tampon payı uygulamak yerine, gözlemlenebilir girdileri değiştirerek—örneğin oturum uzunluğu dağılımı, çıktı boyutu veya ölçülen önbellek isabet payı—düşük, orta ve yüksek bir senaryo sunun. Gözlemlenen oturumların ötesindeki öngörülen her türlü davranışı ölçülmüş bir gerçek olarak değil, açık bir senaryo olarak ele alın.

Tahmin, yalnızca enstrümantasyonu ve faturalandırılabilir kategorileri kadar eksiksizdir. Günlük kaydı tutucunun (logger) dışına yönlendirilen çağrıları, yeniden denemeleri, API'nin sunmadığı önbelleğe alınmış token kategorilerini, model tarafındaki akıl yürütme token'larını, depolama süresini, medya işlemeyi veya token ücretlerinin ötesindeki sağlayıcı masraflarını gözden kaçırabilir. Uygun olduğunda örneklenen kullanımı sağlayıcı faturalandırma raporlarıyla mutabık kılın, önemli farkları araştırın ve modelleri, prompt'ları, önbelleğe alma davranışını veya oyuncuya dönük özellikleri değiştirdikten sonra hesaplamayı yeniden çalıştırın. Elde edilen sonuç, gözlemlenen iş yükü için belgelenmiş bir işletim maliyeti tahminidir; gelecekteki oturumların veya faturaların bununla eşleşeceğine dair bir vaat değildir.

Bu konuyu keşfetmeye devam et