Geçen ay, kendi yan ürünümün AI destekli operasyonel pipeline’larında beklemediğim bir maliyet artışı gördüm. Bir önceki dönem 120 USD olan AI API faturam, optimizasyon yapmadığım birkaç yeni özellik yüzünden 480 USD’ye fırlamıştı. Bu artış, “Tokenpocalypse” dediğimiz, token tüketiminin kontrolsüzce artması ve maliyetleri şişirmesi durumunun somut bir örneğiydi. AI projelerinde, özellikle üretim ortamında çalışan uygulamalarda, token maliyetlerini proaktif olarak yönetmek artık lüks değil, zorunluluk haline geldi. Bu yazıda, kendi uygulamalarımda ve bir müşteri projesinde edindiğim tecrübelerle, AI faturalarını düşürmek için uyguladığım yedi pratik yöntemi detaylıca anlatacağım.
Prompt Engineering ile Token Tüketimini Nasıl Azaltırız?
AI modellerine gönderdiğimiz her kelime, hatta her karakter bir maliyet unsuru. Bu yüzden prompt’ları mümkün olduğunca kısa, net ve hedefe yönelik yazmak, token tüketimini doğrudan etkileyen en temel adımdır. Bir üretim ERP’sinde operatör ekranları için kullandığım bir AI destekli üretim planlama modülünde, ilk başta çok uzun ve açıklayıcı prompt’lar kullanmıştım. Ancak sonrasında prompt’ları optimize ederek %30’a yakın bir token tasarrufu sağladım.
Prompt’ları Kısaltma ve Yapılandırma Stratejileri Nelerdir?
Prompt’ları kısaltırken, modelin ihtiyacı olan kritik bilgiyi kaybetmemek esastır. Modelin çıktı formatını ve beklentilerinizi net bir şekilde belirtmek, gereksiz “düşünme” adımlarını ve dolayısıyla tokenleri azaltır. Örneğin, modelden JSON çıktısı bekliyorsak, bunu açıkça belirtmeliyiz.
Bir örnek üzerinden gidelim: ilk başta bir metni özetlemek için şöyle bir prompt kullanıyordum:
"Merhaba, lütfen aşağıdaki metni okur musun? Bu metin oldukça uzun, bu yüzden benim için 3-4 cümlelik kısa bir özetini çıkarabilir misin? Özetin ana fikirleri içermesi önemli. Teşekkürler."Bu prompt, gereksiz konuşma ve kibarlık içeriyor. Token maliyetlerini düşürmek için bunu şöyle optimize ettim:
"Aşağıdaki metni 3-4 cümleyle özetle. Ana fikirleri vurgula.
Metin: [Buraya metin gelecek]"Bu basit değişiklik bile, metnin uzunluğuna bağlı olarak %10-15 arası token tasarrufu sağlayabiliyor. Gerçek dünyada, büyük metin yığınlarında bu oranlar ciddi maliyet farkları yaratır. Kendi sistemimde yaptığım bir analizde, 1000 kelimelik bir metin için ilk prompt 150 token tüketirken, optimize edilmiş prompt sadece 120 token tüketti. Bu, ayda 10.000 çağrı yapan bir sistemde 300.000 tokenlik bir fark demek.
Daha Küçük ve Uzmanlaşmış Modeller Ne Zaman Kullanılmalı?
Her iş için en büyük ve en yetenekli AI modelini kullanmak, bir Ferrari ile bakkala gitmeye benzer. Çoğu zaman daha küçük, daha hızlı ve daha uygun maliyetli modeller, belirli görevler için fazlasıyla yeterli olur. Özellikle sınıflandırma, basit metin üretimi veya veri çıkarma gibi görevlerde, daha küçük modellerin performansları büyük modellere çok yakındır, hatta bazen daha iyi olabilirler.
Model Seçiminde Maliyet ve Yetenek Dengesi Nasıl Kurulur?
Benim deneyimime göre, model seçimi bir trade-off meselesidir. Genel amaçlı büyük modeller (GPT-4, Gemini Advanced) pahalı ve yavaştır, ancak karmaşık ve yaratıcı görevlerde üstündürler. Daha küçük modeller (Gemini Flash, Llama 3 8B) ise daha ucuz ve hızlıdır, ancak belirli yeteneklerde sınırlı olabilirler. Bir üretim ERP’sinde, AI ile operatör ekranlarına özel iş talimatları üretirken ilk başta büyük bir model kullanıyorduk. Ancak daha sonra sadece talimatların standart formatta olup olmadığını kontrol etmek için daha küçük bir modelin yeterli olduğunu gördüm.
Kendi finansal hesaplayıcılarımın backend’inde, kullanıcı girdilerini kategorize etmek için başlangıçta GPT-3.5 kullanıyordum. Dakikada ortalama 50 istek aldığım bir senaryoda, bu bana aylık yaklaşık 60 USD maliyet yaratıyordu. Daha sonra aynı görevi daha uygun fiyatlı bir açık kaynak modelin fine-tune edilmiş 7B versiyonuyla yapabileceğimi fark ettim. Bu modeli kendi sunucumda çalıştırdığımda, GPU maliyeti hariç API çağrı başına maliyet neredeyse sıfıra düştü. Bir başka örnekte, bir müşteri projesinde, basit evet/hayır soruları için GPT-4 yerine Gemini Flash’e geçiş yaparak API çağrı maliyetlerini %75 azalttık. Bu, saniyede onlarca isteğin olduğu sistemlerde ciddi bir fark yaratıyor.
Caching ve Deduplication ile Gereksiz API Çağrılarını Nasıl Önleriz?
AI API çağrıları pahalıdır ve her seferinde aynı soruyu sormak, gereksiz yere para harcamak demektir. Benim deneyimime göre, AI faturasını düşürmenin en etkili yollarından biri, daha önce sorulmuş soruların cevaplarını önbelleğe almak (caching) ve birbirine benzeyen istekleri tekilleştirmektir (deduplication). Özellikle aynı veya çok benzer prompt’ların tekrar tekrar gönderildiği senaryolarda bu yöntem hayat kurtarıcı olabilir.
AI Yanıtlarını Önbelleğe Alma ve Tekilleştirme Yaklaşımları
Birçok AI uygulaması, aynı veya çok benzer girdilerle tekrar tekrar çağrılır. Örneğin, bir ürün açıklamasını özetleme işlevini düşünün. Eğer aynı ürün açıklamasını birden fazla kullanıcı özetlemek isterse, her seferinde AI API’sine gitmek yerine, ilk isteğin sonucunu önbelleğe alıp sonraki isteklere servis edebiliriz. Kendi Android spam uygulamamda, belirli metin kalıplarını sınıflandırmak için AI kullanıyorum. Aynı spam metni defalarca gelirse, her seferinde AI’ye sormak yerine, daha önce sınıflandırılmış metinleri bir Redis cache’inde tutuyorum.
Basit bir caching mekanizması için Redis veya Memcached kullanabiliriz. Anahtar olarak prompt’un hash’ini (örneğin SHA256) kullanıp, değer olarak AI’dan dönen yanıtı saklayabiliriz.
import hashlib
import json
import redis
# pip install redis
# Redis bağlantısı
r = redis.Redis(host='localhost', port=6379, db=0)
def get_ai_response_with_cache(prompt_text, ai_model_func):
prompt_hash = hashlib.sha256(prompt_text.encode('utf-8')).hexdigest()
cached_response = r.get(prompt_hash)
if cached_response:
print("Cache'ten servis edildi.")
return json.loads(cached_response)
print("AI API'sine istek gönderiliyor...")
ai_response = ai_model_func(prompt_text) # Gerçek AI API çağrısı
r.set(prompt_hash, json.dumps(ai_response), ex=3600) # 1 saat cache
return ai_response
# Örnek AI modeli fonksiyonu (gerçekte API çağrısı yapacak)
def mock_ai_call(text):
# Bu kısım gerçek AI API çağrısı ile değişecek
return {"summary": f"Bu metin hakkında bir özet: {text[:50]}..."}
# Kullanım
prompt1 = "Bana dünyanın en yüksek dağını anlat."
response1 = get_ai_response_with_cache(prompt1, mock_ai_call)
print(response1)
prompt2 = "Bana dünyanın en yüksek dağını anlat." # Aynı prompt
response2 = get_ai_response_with_cache(prompt2, mock_ai_call)
print(response2)Bu kod parçası, aynı prompt için ikinci çağrıda AI API’sine gitmek yerine, Redis’ten yanıtı alarak token maliyetinden kaçınır. Benim bir müşteri projesinde, 28 Nisan’da bu yöntemi devreye aldıktan sonra, günlük 15.000 olan AI çağrı sayısını 8.000’e kadar düşürdük. Bu da aylık faturada yaklaşık 200 USD’lik bir tasarruf demekti.
Retrieval-Augmented Generation (RAG) ile Bağlamı Akıllıca Yönetmek
Büyük dil modellerinin (LLM) en büyük maliyet kalemlerinden biri, bağlam penceresi (context window) içinde tutulan token sayısıdır. Bir üretim ERP’sinde karmaşık ürün ağaçları veya tedarik zinciri entegrasyonu hakkında sorular sorulduğunda, tüm ilgili belgeleri doğrudan prompt’a eklemek token maliyetlerini fırlatır. Retrieval-Augmented Generation (RAG) mimarisi, bu sorunu çözmek için harika bir yaklaşımdır.
RAG Nasıl Çalışır ve Token Tüketimini Nasıl Azaltır?
RAG, temel olarak, bir kullanıcı sorusuna yanıt vermeden önce ilgili bilgileri bir bilgi tabanından (dokümanlar, veritabanları vb.) alır ve yalnızca bu ilgili bilgiyi LLM’ye bağlam olarak sunar. Bu, LLM’nin tüm bir doküman havuzunu ‘okumak’ zorunda kalmasının önüne geçer. Örneğin, bir kullanıcının “X ürününün montaj talimatları nelerdir?” sorusuna yanıt verirken, RAG sadece X ürününün montaj talimatlarını içeren belgeyi alır ve LLM’ye gönderir, tüm ürün el kitaplarını değil.
graph TD; A["Kullanıcı Sorgusu"] --> B["Vektör Veritabanı Sorgusu"]; B --> C["İlgili Doküman Parçacıkları (Chunks)"]; C --> D["LLM (Sorgu + İlgili Parçacıklar)"]; D --> E["LLM Yanıtı"]; style A fill:#f9f,stroke:#333,stroke-width:2px; style B fill:#bbf,stroke:#333,stroke-width:2px; style C fill:#ccf,stroke:#333,stroke-width:2px; style D fill:#fcf,stroke:#333,stroke-width:2px; style E fill:#f9f,stroke:#333,stroke-width:2px;
Bu diyagram, RAG’nin temel akışını gösteriyor. Anahtar nokta, LLM’ye gönderilen bağlamın ne kadar küçük ve hedefe yönelik olduğudur. Kendi veri platformumda, kullanıcıların anonim Türkiye verileri hakkında sorular sormasına izin veren bir AI arayüzü geliştirdim. İlk başta tüm veri sözlüğünü ve metodolojileri LLM’ye gönderiyordum, bu da her sorgu için binlerce token demekti. RAG’i entegre ettikten sonra, kullanıcı sorusuna göre sadece ilgili veri setlerinin meta verilerini ve açıklamalarını LLM’ye göndererek, ortalama token tüketimini %60 oranında azalttım. Bu, LLM’nin sadece 500-1000 tokenlik bir bağlamla çalışmasını sağladı, oysa daha önce 3000-5000 token gerekiyordu.
Multi-Agent Sistemlerinde Akış Optimizasyonu Nasıl Yapılır?
AI uygulamaları daha karmaşık hale geldikçe, tek bir LLM çağrısı yerine birden fazla AI “ajanının” iş birliği yaptığı multi-agent sistemler kullanmaya başladım. Örneğin, bir üretim ERP’sinde AI ile üretim planlama yaparken, bir ajan hammaddeleri kontrol ediyor, diğeri üretim kapasitesini inceliyor ve son bir ajan nihai planı oluşturuyor. Bu tür sistemlerde, her ajanın her zaman bir LLM’ye danışması maliyetleri hızla artırabilir. Akış optimizasyonu, bu gereksiz çağrıları önlemek için kritik öneme sahiptir.
Agent Pattern’lerini Akıllıca Kullanarak Maliyetleri Düşürmek
Multi-agent sistemlerdeki en büyük zorluklardan biri, ajanların birbirleriyle etkileşimi sırasında oluşan token tüketimidir. Benim yaklaşımım, her ajanın bir LLM çağrısı yapmadan önce “kendi başına” çözebileceği durumları belirlemek ve bu durumlarda kural tabanlı sistemlere veya yerel fonksiyonlara öncelik vermektir. Agent’lar arası iletişimi de minimumda tutmak önemlidir.
Bir müşteri projesinde, tedarik zinciri entegrasyonu için bir multi-agent sistemi kurmuştuk. İlk iterasyonda, her ajan (stok kontrol, tedarikçi iletişim, lojistik) neredeyse her adımda bir LLM çağrısı yapıyordu. Bu, günde ortalama 2.000 USD’lik bir AI faturası demekti. Akışı optimize ederek, yani ajanların belirli kurallar dahilinde (örneğin, stok belirli bir seviyenin altındaysa tedarikçiye sorma, sadece otomatik sipariş oluşturma) direkt aksiyon almasını sağlayarak, LLM çağrılarının %70’ini elimine ettik. Örneğin, basit bir stok sorgusunu LLM yerine doğrudan PostgreSQL veritabanından çekmek, anlık bir token tasarrufu sağlar. Bu, agent’ların karar ağaçlarına veya basit if-else mantığına sahip olması gerektiği anlamına geliyor.
# Basit bir agent mantığı örneği
def inventory_agent(item_id, current_stock, llm_client):
if current_stock < 100:
# LLM'ye sormadan direkt aksiyon al
print(f"[{item_id}] Stok düşük ({current_stock}). Otomatik sipariş oluşturuluyor...")
# sipariş oluşturma fonksiyonunu çağır
return "Sipariş oluşturuldu."
else:
# Daha karmaşık bir karar için LLM'ye danış
prompt = f"Ürün {item_id} için mevcut stok {current_stock}. Üretim planını optimize etmek için ne yapmalıyım?"
llm_response = llm_client.generate_text(prompt)
return llm_response
# Gerçek LLM client'ı yerine bir mock
class MockLLMClient:
def generate_text(self, prompt):
return f"LLM'den yanıt: '{prompt[:50]}...'"
# Kullanım
llm = MockLLMClient()
print(inventory_agent("PROD-001", 50, llm)) # Stok düşük, LLM'ye gitmez
print(inventory_agent("PROD-002", 150, llm)) # Stok yeterli, LLM'ye giderBu örnekte, stok düşükse LLM çağrısı yapılmadan direkt karar alınır, böylece gereksiz token tüketimi önlenir.
Girdi/Çıktı Formatlamasında Verimliliği Artırmak
AI modelleriyle çalışırken, gönderdiğimiz girdinin (prompt) ve aldığımız çıktının formatı, doğrudan token maliyetlerini etkiler. Özellikle büyük veri setleri veya karmaşık yapılarla çalışırken, formatlama hataları veya verimsizlikler, gereksiz token tüketimine yol açabilir. Ben, kendi projelerimde bu konuda ciddi optimizasyonlar yaparak maliyetleri düşürdüm.
Verimli Girdi ve Çıktı Formatları Kullanarak Token Tasarrufu
Bir üretim ERP’sinde, AI’dan gelen üretim planlarını veya iSCSI tedarik zinciri entegrasyonu verilerini işlerken, ilk başta çıktıyı XML formatında alıyorduk. XML’in etiket yapısı, aynı veriyi JSON’a göre çok daha fazla tokenle ifade ediyordu. JSON’a geçiş yaptığımızda, çıktı token sayısında %20’ye varan bir azalma gördüm. Aynı şekilde, girdi olarak gönderdiğimiz veriyi de mümkün olduğunca sade tutmak, gereksiz boşluklar, yorumlar veya formatlama karakterlerinden kaçınmak önemlidir.
Bir senaryo düşünelim: Bir ürünün özelliklerini AI’ya gönderip bir açıklama oluşturmasını istiyoruz.
Verimsiz XML Girdi:
<product>
<id>12345</id>
<name>Akıllı Termos Bardak</name>
<features>
<feature>Çift Katmanlı Yalıtım</feature>
<feature>Sıcaklığı 12 Saat Korur</feature>
<feature>500ml Kapasite</feature>
</features>
<!-- Bu ürün günlük kullanım için idealdir -->
</product>Bu XML girdisi, modelin tokenizer’ına göre oldukça fazla token tüketir.
Optimize Edilmiş JSON Girdi:
{
"id": "12345",
"name": "Akıllı Termos Bardak",
"features": ["Çift Katmanlı Yalıtım", "Sıcaklığı 12 Saat Korur", "500ml Kapasite"]
}Bu JSON girdisi, aynı bilgiyi çok daha az token ile ifade eder. Kendi gözlemimde, 1000 kelimelik bir metin için XML çıktısı ortalama 1200-1300 token tüketirken, aynı bilginin JSON’a dönüştürülmüş hali 900-1000 token civarında kalabiliyor. Bu da %25’e varan bir tasarruf demektir. Ayrıca, modelden sadece gerekli alanları döndürmesini istemek de önemlidir; örneğin, {"summary": "..."} yerine {"summary": "...", "sentiment": "positive", "keywords": ["a", "b"]} gibi ek bilgiler istemek, her zaman daha fazla token tüketimine yol açar. Gerekmediği sürece istemeyin.
Çoklu Sağlayıcı Fallback ve Akıllı Yönlendirme Stratejileri
AI model sağlayıcıları arasında fiyatlar, performans ve yetenekler büyük farklılıklar gösterebilir. Sadece tek bir sağlayıcıya bağlı kalmak, hem maliyet açısından esnekliği sınırlar hem de kesinti durumlarında risk yaratır. Benim kendi yan ürünlerimdeki ve bir müşteri projesindeki deneyimime göre, çoklu sağlayıcı stratejisi ve akıllı yönlendirme, maliyetleri optimize etmenin ve sistem dayanıklılığını artırmanın önemli bir yoludur.
Fiyat ve Performansa Göre Akıllı Yönlendirme Nasıl Yapılır?
Çoklu sağlayıcı stratejisinde temel fikir, farklı AI sağlayıcılarını (Gemini Flash, Groq, Cerebras, OpenRouter gibi) bir araya getirmek ve gelen isteğin türüne, aciliyetine veya maliyet hedefine göre en uygun sağlayıcıya yönlendirmektir. Örneğin, hızlı ve ucuz bir yanıt gerektiren basit bir sınıflandırma görevi için Groq veya Cerebras’ın daha ucuz modellerine yönelebilirken, karmaşık ve yaratıcı bir metin üretimi için Gemini Advanced gibi daha yetenekli ama pahalı bir modele gitmek daha mantıklı olabilir.
graph TD;
A["Kullanıcı İsteği"] --> B{"İstek Tipi?"};
B -- "Basit & Hızlı" --> C["Sağlayıcı A (Groq/Cerebras)"];
B -- "Karmaşık & Yaratıcı" --> D["Sağlayıcı B (Gemini Advanced)"];
B -- "Varsayılan / Düşük Maliyet" --> E["Sağlayıcı C (OpenRouter/Gemini Flash)"];
C --> F["Yanıt"];
D --> F;
E --> F;
style A fill:#f9f,stroke:#333,stroke-width:2px;
style B fill:#bbf,stroke:#333,stroke-width:2px;
style C fill:#ccf,stroke:#333,stroke-width:2px;
style D fill:#ddf,stroke:#333,stroke-width:2px;
style E fill:#eef,stroke:#333,stroke-width:2px;
style F fill:#f9f,stroke:#333,stroke-width:2px;
Bu ak