Geçen ay İstanbul’da bir ekip toplantısındaydım. Aynı cümleyi iki kez duydum: “Model iyi çalışıyor ama fatura biraz can sıkıyor.” İşin aslı şu — LLM uygulamalarında sorun çoğu zaman gecikme değil, sessizce büyüyen maliyet. Klasik izleme araçları bunu pek umursamıyor. CPU, RAM, hata oranı… hepsi yerli yerinde görünüyor. Sonra ay sonu geliyor ve tablo değişiyor, bir anda herkes birbirine bakıyor.
Bi saniye — Bu yazıda, LLM maliyetini neden geleneksel APM araçlarının kaçırdığını ve OpenTelemetry’nin GenAI semantik kurallarıyla bu kör noktayı nasıl kapattığını kendi gözümden anlatacağım. Açık konuşayım — bu konu sadece “kaç token gitti?” meselesi değil; mimari karar, bütçe disiplini. Biraz da operasyon zekâsı işi.
Asıl problem: faturayı aylık görmek
Küçük bir startup’ta bunu çok net hissedersiniz. Trafik azdır. Ama kullanıcı başına çıkan maliyet dalgalanır — bazen 1 sentlik istek gelir, bazen zincirleme çağrılar yüzünden aynı oturum 5 dolara kadar sıçrar, kimse fark etmez, ay kapanır, şok başlar. 2024 sonbaharında Kadıköy’de görüştüğüm bir ürün ekibi tam da bunu yaşıyordu: staging ortamında her şey pırıl pırıl, üretimde ise birkaç uzun konuşma zinciri bütçeyi kemiriyordu.
Geleneksel APM burada şaşırmıyor bile. Çünkü onun derdi başka. Latency, error rate, throughput bakar — bunlar önemli tabii, kimse inkâr etmiyor, ama finansal resmi vermez. İki istek de üç saniye sürüyorsa APM için ikisi aynı sınıfta görünür. Oysa biri 0,002 dolar olabilirken diğeri 0,40 dolara çıkabiliyor. Aradaki fark küçük değil. Bayağı can yakıcı.
Evet, doğru duydunuz.
Benim editör masasında ilk dikkatimi çeken şey de buydu zaten — LLM dünyasında “performans” tek başına yeterli değil. Ürünün hızlı olması güzel, evet. Ama hızın yanında ne kadar yediği de önemli. Evdeki elektrik sayacı gibi düşünün; ışık yanıyor diye sorun yok sanırsınız ama klima da sürekli çalışıyorsa ay sonunda şok olursunuz. Tam da öyle.
Neden klasik izleme yetmiyor?
Üç büyük kör nokta var. Her biri tek başına bile baş ağrıtır. İlki token tüketiminin SDK çağrılarının içine gömülü olması — yani response içindeki usage bilgisini alıp ayrıca kaydetmezseniz veri yok sayılıyor gibi davranıyor, sistem sizi uyarmıyor, siz de habersiz kalıyorsunuz. İkincisi zincirlenmiş çağrılar: tek bir kullanıcı isteği bazen sekiz farklı model çağrısı doğuruyor. Üçüncüsü ise model fiyatlarının uçurum gibi değişmesi. Daha fazla bilgi için Ajanlar Artık İş Yapıyor: API Kullanan Görev Motoru yazımıza bakabilirsiniz. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
Mesela GPT-5 ailesinin alt modelleri arasında ciddi fark var. Nano ile tam sürüm arasındaki mesafe öyle böyle değil — resmen ayrı liglerdesiniz. Üstelik reasoning modellerinde işler daha da garipleşiyor,. Görünmeyen “thinking token” denen iç tüketim kalemleri de faturalandırılıyor olabilir. Dışarıdan bakınca kısa cevap verilmiş gibi duruyor — Ama içeride epey emek harcanmış oluyor.
LLM maliyeti çoğu zaman sonuçta değil, süreçte saklanıyor. Tek tek istekleri izlemek yetmiyor; toplam konuşma akışını görmek gerekiyor.
Bir şey dikkatimi çekti: Bir de şu var: bazı ekipler maliyeti yalnızca altyapı faturası sanıyor. Halbuki burada altyapıdan çok kullanım ekonomisi konuşuyoruz. Kurumsal projelerde bunu daha sert hissediyorsunuz — on binlerce kullanıcı küçük sapmaları büyütüyor, sonra bir bakıyorsunuz bütçe planı kâğıt üstünde kalmış. Bu konuyla ilgili PQPM: Farklı Diller İçin Tek Bir Süreç Yöneticisi yazımıza da göz atmanızı tavsiye ederim.
Zincirli çağrılar neden pahalıya patlıyor?
Düşünün ki bir ajan sistemi kurdunuz. Tek soru için önce niyet tespiti yapılıyor, sonra arama yapılıyor, ardından özet çıkarılıyor, en sonda da cevap düzeltiliyor — her adım ayrı API çağrısı demek, bu yapı güzel görünüyor, esnek, modüler falan, ama izlemeyi bilmiyorsanız resmen kara kutu. Daha fazla bilgi için Gemini’nin Yeni Defter Hamlesi: Notlar Karışmasın yazımıza bakabilirsiniz. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Bunu geçen yıl Ankara’daki bir demo ortamında test ettim. Akış kâğıt üzerinde harika çalışıyordu. Ama gerçek kullanıcıda sohbet uzadıkça model seçimi değişti ve maliyet beklentinin iki katına çıktı (ciddiyim). Kimse ilk hafta fark etmedi. Çünkü latency grafikleri normaldi!
| Durum | APM’de Görünürlük | Maliyet Riski | Ne Eksik? |
|---|---|---|---|
| Kısa tek seferlik sorgu | İyi | Düşük | Token detayı |
| Zincirli agent akışı | Kısmen iyi | Orta-Yüksek | Ana işlem altında toplama |
| Uzun sohbet geçmişi olan oturum | Aynı görünür | Çok yüksek olabilir | Kullanıcı bazlı kırılım |
| Reasoning modeli kullanımı | Aynı görünür | Çok yüksek olabilir | Thinking token görünürlüğü |
OpenTelemetry burada ne yapıyor?
Lafı gevelemeden söyleyeyim: OpenTelemetry’nin GenAI semantik konvansiyonları bu işin omurgasını veriyor. Genelde gözden kaçan nokta şu — sistem zaten telemetry topluyorsa neden ekstra iş çıkaralım? Çünkü burada ekstra iş yok aslında; doğru alanları doğru yere koyuyorsunuz, o kadar (kendi tecrübem)
gen_ai.request.model
gen_ai.response.model
gen_ai.prompt_tokens
gen_ai.completion_tokens
gen_ai.total_tokens
# Bazı uygulamalarda bunlar otomatik span attribute olarak düşer.
# Sonra metrik tarafında maliyete çevrilir.
Bunun güzelliği şu: aynı observability yığınını kullanmaya devam ediyorsunuz. OpenTelemetry Collector, Prometheus ya da Grafana — ne kullanıyorsanız oraya akıtabilirsiniz. Yani yeni bir ada kurmak zorunda değilsiniz — Sadece mevcut şehre düzgün yollar açıyorsunuz.
Bir dakika — bununla bitmedi.
Peki maliyet hesabını nasıl yaparsınız?
Teslim edilen token sayısını model fiyatıyla çarpmanız yeterli gibi duruyor. Ama pratikte biraz daha nüans var. Input ve output token ayrı fiyatlanabiliyor. Bazı modellerde cache hit etkisi olabiliyor. Bazılarında ise internal reasoning tüketimi ayrıca hesaplanıyor. Yani formül basit görünür ama veri tarafı temiz olmazsa sonuç çarpılır. Garantili.
# Basit yaklaşım
total_cost = (input_tokens / 1_000_000) * input_price + \
(output_tokens / 1_000_000) * output_price
# Uygulamada buna şunlar eklenebilir:
# — model versiyonu
# — bölgesel fiyat farkları
# — retry sayısı
# — tool call zinciri
# — cache etkisi
Küçük ekip ile kurumsal yapı aynı mı düşünmeli?
Cevap kısa: hayır. Küçük startup’larda mesele çoğunlukla “beklenmedik sıçramayı erken görmek” oluyor. Enterprise tarafta ise konu doğrudan finans yönetişimine dönüşüyor — aynı teknik araç seti kullanılabilir ama alarm eşiği bambaşka olmalı, bunu atlamamak lazım. Hani ne farkı var diyorsunuz, değil mi? Mesela küçük ekip günlük uyarıyla idare ederken kurumsal tarafta departman bazlı sınırlar gerekiyor.
- Küçük ekip: request başına maliyet takibi yeterli olabilir. — bunu es geçmeyin
- Büyüyen ürün: kullanıcı segmenti bazlı analiz şart hale gelir. — ciddi fark yaratıyor
- Kurumsal yapı: proje/ekip/model/senaryo kırılımı ister istemez devreye girer.
- Ajan yoğun sistemler: chain-level attribution, yani ana operasyon altında toplama yapılmalı.
Neyse uzatmayayım — benzer senaryoyu kendi side project’imde de yaşadım. Berlin’den çalışan bir arkadaşımın önerisiyle GPT yerine mini sınıfa geçtik, performans yüzde yüz kusursuz olmadı tabii,. Aylık fatura neredeyse yarıya indi. İşte bu yüzden gözlemleme işi lüks değil; bildiğin güvenlik kemeri gibi.
Bir başka ders de şu oldu. Model seçimlerini feature flag arkasına almak hayat kurtarıyor — kullanıcıların yüzde beşinde yeni modeli denersiniz, geri kalanında eski yol devam eder, böylece hem kıyas yaparsınız hem bütçeyi yakmazsınız. Çok basit görünüyor. Ama sahada işe yarayan numara genelde budur; süslü paneller değil.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
