Maliyet ve Gecikme Raporu

Her çağrı arka planda 4 sağlayıcıdan geçer — ses tanıma, yapay zeka beyni, ses üretimi, telefon hattı — ve her birinin ayrı bir maliyeti, ayrı bir gecikmesi vardır. Bu rapor o dört bileşeni tek tek açar: hangi çağrı ne kadara mal oldu, hangi adım aramayı yavaşlattı. Haziran 2026’da yapılan bir optimizasyon turunda bu ölçümler sayesinde yapay zeka cevap süresi (p95) 3,80 saniyeden 975 ms’ye indi — yaklaşık 4 kat. Ölçmediğin gecikmeyi iyileştiremezsin; bu rapor tam olarak onu ölçer.

Neden hem maliyet hem gecikme aynı raporda?

Çünkü ikisi aynı madalyonun iki yüzü. Daha hızlı bir sağlayıcı (örn. hızlı bir TTS modeli) genelde biraz daha pahalıdır; daha ucuz bir model genelde biraz daha yavaştır. Bu raporu okurken asıl soru “en ucuzu mu kullanıyorum” değil, “doğru dengede miyim” olmalı — çünkü müşterin telefonda 2 saniye sessizlik yaşarsa, kazandığın birkaç kuruş cent’in hiçbir önemi kalmaz.

Bir çağrı arka planda şu hattı izler:

Karşı taraf konuşur
        ↓
STT — Deepgram: sesi yazıya çevirir            ⏱ latency.stt        💵 cost.stt
        ↓
LLM — GPT/Gemini/Claude: cevabı üretir         ⏱ latency.llm_ttft   💵 cost.llm_input + cost.llm_output
        ↓
TTS — ElevenLabs / Cartesia: yazıyı sese çevirir  ⏱ latency.tts      💵 cost.tts
        ↓
SIP — NetGSM: sesi telefon hattına taşır                              💵 cost.sip
        ↓
Karşı taraf duyar

STT (Speech-to-Text) = ses tanıma, LLM (Large Language Model) = cevabı kuran yapay zeka, TTS (Text-to-Speech) = metni sese çeviren motor, SIP = çağrının telefon şebekesine çıktığı hat. Dört harf, dört ayrı fatura kalemi.

Gecikme neden bu kadar önemli?

İnsan konuşmasında doğal bir tempo vardır — biri konuşmayı bitirdiğinde diğeri yarım saniye içinde tepki verir. Yapay zeka asistanı bu pencereyi kaçırırsa “düşünüyor” hissi verir; 800 ms’yi aşarsa çoğu kişi “hattı mı kaybettik” diye tekrar konuşmaya başlar — üstüne konuşma (barge-in), asistanın cevabını yarıda kesme ve genel bir “botla konuşuyorum” izlenimi doğar. Panelin çağrı detayında gecikme kutucukları bu yüzden renk kodludur:

Bu eşikler STT, LLM ve TTS’in her biri için ayrı ayrı geçerlidir — üçü art arda geldiği için toplam gecikme bu üçünün toplamına yakındır.

p50 / p95 / p99 ne anlama gelir?

Ortalama (avg) tek başına yanıltıcıdır — birkaç çok hızlı çağrı, birkaç çok yavaş çağrıyı gizleyebilir. Bu yüzden rapor yüzdelik dilim (percentile) kullanır:

Bir müşteri asistanı “yavaş” olarak hatırlıyorsa genelde ortalamayı değil, en kötü aramasını (p95/p99 bölgesi) hatırlıyordur. Optimizasyon yaparken önce p95’e bak.

Gerçek bir örnek: Purvisor’ın kendi altyapısında yapılan bir tur sonunda ölçülen değerler — LLM p95 3,80 saniyeden 975 ms’ye (gpt-4o-mini, önbelleğe uygun sabit prompt + son 12 mesaja kırpılmış geçmiş), STT p50 ~150 ms (Deepgram, AB bölgesi sunucusu), TTS ~175 ms (ElevenLabs Turbo v2.5). Sonuç: tur başına toplam gecikme p50 ~1,1 saniye / p95 ~1,45 saniye — sesli bir asistan için doğal sayılan bölge. Bu rakamlar o ana özgü bir ölçümdür, kullandığın modele/sağlayıcıya göre kendi hesabında farklı çıkar; önemli olan yöntem: p95’i düzenli izlemek.

Maliyet nereden geliyor?

Her çağrı bittiğinde, sesli asistan dört bileşenin maliyetini ayrı ayrı backend’e bildirir. Referans (örnek) birim fiyatlar, kullanılan sağlayıcıya göre değişir:

Purvisor birden çok sağlayıcı arasında otomatik geçiş yapabildiği (çok-sağlayıcılı LLM, TTS yedekleme) için gerçek maliyet, o çağrıda fiilen hangi sağlayıcı kullanıldığına göre hesaplanır — yukarıdaki tablo bir referans noktasıdır, garanti bir fiyat listesi değil.

Rapordaki alanlar

Seçtiğin dönem (varsayılan 7 gün, istersen daha uzun bir aralık) için panel şu alanları gösterir:

{
  "period": { "days": 7, "since": "2026-07-06T00:00:00.000Z" },
  "cost": {
    "total": 12.4831,
    "breakdown": { "stt": 3.21, "llm_input": 1.84, "llm_output": 2.05, "tts": 4.66, "sip": 0.71 },
    "avgPerCall": 0.0623,
    "callCount": 200,
    "daily": { "2026-07-12": 1.98, "2026-07-11": 2.14 },
    "todayRealtime": 0.87
  },
  "latency": {
    "aggregated": {
      "stt": { "p50": 150, "p95": 240, "p99": 310, "avg": 162, "sampleCount": 180 },
      "llm_ttft": { "p50": 975, "p95": 1420, "p99": 1900, "avg": 1050, "sampleCount": 180 },
      "tts": { "p50": 175, "p95": 260, "p99": 340, "avg": 190, "sampleCount": 180 }
    },
    "realtime": { "stt": 150, "llm_ttft": 980, "tts": 178 }
  }
}

(Sayılar gösterim amaçlıdır; kendi hesabında farklı çıkar.)

📸 [Ekran görüntüsü: Raporlar → Maliyet ve Gecikme sayfası — dönem seçici, toplam maliyet kartı, bileşen kırılımı grafiği, gecikme p50/p95 kutucukları]

Tek bir çağrıda maliyet dağılımı

Herhangi bir çağrının detayını açtığında, o çağrıya özel dağılım renkli bir çubukla görünür: mavi = STT, mor = LLM, turuncu = TTS, yeşil = SIP. Yüzdeler toplam maliyete göre hesaplanır.

📸 [Ekran görüntüsü: Çağrı detayı — STT/LLM/TTS/SIP renkli dağılım çubuğu + gecikme kutucukları]

İyi uygulamalar

• Ortalamaya değil p95’e bak. Ortalama iyi görünse de p95 yüksekse, müşterilerinin bir kısmı gerçekten yavaş bir deneyim yaşıyordur.
• Maliyet artışında önce LLM ve TTS’e bak. İkisi genelde en büyük iki kalemdir; uzun prompt’lar LLM girişini, uzun asistan cevapları TTS karakterini şişirir. (Bkz. Prompt Yazma Rehberi)
• Kısa dönemleri (7 gün) düzenli kontrol et — ani bir maliyet veya gecikme sıçramasını haftalar sonra değil, gün içinde yakala.
• Ani p95 sıçraması genelde bir sağlayıcı kaynaklıdır (Deepgram/LLM/TTS tarafında geçici yavaşlama) — coincide eden bir kesinti olup olmadığını kontrol et.

Sorun giderme

İlgili