AI Gateway Devre Dışı Kalma Süresini Ölçmek: Üretim Verileriyle 30 Günlük Test

Yapay zeka destekli uygulamaların performansı, sadece model kalitesine değil, aynı zamanda API geçitlerinin güvenilirliğine de bağlıdır. Nexus Labs’ta geliştirilen ajan platformu, günlük 2,4 milyon LLM isteğini yönetiyor ve bu taleplerin yarısı OpenAI’ye yönlendiriliyor. Nisan ayındaki 4 saatlik bir kesinti sırasında, ev yapımı yeniden deneme mantığı nedeniyle yalnızca 38 dakikalık kayıp yaşandı — ancak bu bile yeterli değildi.

Bu deneyimden yola çıkarak ekip, üç farklı AI geçidinin performansını 30 gün boyunca üretim trafiğiyle ölçmeye karar verdi. Bifrost, LiteLLM ve Portkey’in karşılaştırmalı testlerinde, başarısızlık anında devreye alma süreleri ve ek gecikme oranları ortaya çıktı. Sonuçlar, altyapı tasarımının ne kadar kritik olduğunu bir kez daha gözler önüne serdi.

Üretimde Başarısızlık Anında Devreye Alma Neden Önemli?

Çoğu AI geçidi, başarısızlık senaryolarında performansını ölçmek yerine sadece soğuk başlangıç performansına odaklanır. Oysa gerçek dünya senaryolarında, bir sağlayıcıdan 429 (çok fazla istek) veya 503 (hizmet kesintisi) yanıtı alındığında ne kadar hızlı bir şekilde yedek bir sağlayıcıya geçilebildiği kritiktir. Ek olarak, normal koşullarda bile geçidin eklediği gecikme (p99) ne kadar düşük olmalıdır?

Nexus Labs’ın 9 kişilik mühendislik ekibi, bu soruları yanıtlamak için iki haftalık bir enstrümantasyon süreci yürüttü. Testlerde kullanılan üç geçit (Bifrost, LiteLLM, Portkey), aynı donanım (c6i.4xlarge, 2 düğüm, NLB arkasında), aynı kimlik bilgileri ve gerçek üretim trafiğinden alınan örneklemelerle karşılaştırıldı. Her geçit için OpenAI ana sağlayıcı, Anthropic yedek sağlayıcı ve Bedrock üçüncül sağlayıcı olarak ayarlandı.

Test Kurulumu ve Yapılandırma

Üç farklı AI geçidi, aynı üretim trafiğine maruz bırakıldı. Bu trafik, aracı hizmetinden doğrudan geçitlere yönlendirildi ve her geçit için hata durumlarında otomatik olarak yedek sağlayıcılara geçiş yapacak şekilde yapılandırıldı. Örneğin, Bifrost’un yapılandırması aşağıdaki gibiydi:

providers:
  openai:
    keys:
      - value: env.OPENAI_API_KEY
    weight: 1.0
  anthropic:
    keys:
      - value: env.ANTHROPIC_API_KEY
    weight: 1.0
  bedrock:
    keys:
      - value: env.AWS_BEDROCK_KEY
    weight: 1.0

fallbacks:
  - provider: openai
    model: gpt-4o
    fallback_to:
      - provider: anthropic
        model: claude-sonnet-4
      - provider: bedrock
        model: anthropic.claude-sonnet-4

Benzer yapılandırmalar LiteLLM ve Portkey için de gerçekleştirildi. Farklı YAML formatları kullanılmış olsa da, mantık aynıydı: birincil sağlayıcı başarısız olduğunda otomatik olarak ikincil sağlayıcıya geçiş yapılması.

Ölçüm Sonuçları: Hangisi Daha İyisi?

720 saatlik sürekli trafik testinin ardından elde edilen sonuçlar, geçitlerin performansı hakkında önemli ipuçları verdi. Aşağıdaki tabloda, her geçidin eklediği gecikme ve başarısızlık anında devreye alma süreleri karşılaştırılmaktadır:

| Geçit | p50 Gecikme Eklemesi | p99 Gecikme Eklemesi | Devre Dışı Kalma Süresi (Sağlayıcı Kapalı) | 1.000 İstek/Sn Bellek Kullanımı | |--------------|----------------------|----------------------|-------------------------------------------|-------------------------------| | Bifrost | 3 ms | 11 ms | 180 ms (bir yeniden deneme + geçiş) | 412 MB | | LiteLLM | 8 ms | 41 ms | 620 ms | 890 MB | | Portkey | 6 ms | 29 ms | 340 ms | 650 MB |

Bifrost’un Go tabanlı olması, LiteLLM’in Python/FastAPI tabanlı olması, performans farklılıklarının önemli bir kısmını açıklıyor. Ancak Bifrost’un başarısızlık zincirini senkron olarak değerlendirmesi ve yeniden kuyruğa alma gerektirmemesi, ikinci yeniden deneme aşamasında kritik bir avantaj sağlıyor. Portkey’in kendi kendine barındırılan versiyonu, yönetilen hizmetine kıyasla bazı özelliklerde geride kaldı. LiteLLM’in en büyük avantajı ise özel maliyet takibi geri çağırmaları için sunduğu esneklik oldu.

Bifrost’un Üç Ana Kullanım Alanı

Nexus Labs ekibi, Bifrost’u aşağıdaki üç temel senaryoda kullandı:

• Yedek sağlayıcıya geçiş: OpenAI’den 429 yanıtı alındığında, isteğin doğrudan Anthropic’e yönlendirilmesi. Bu işlem, ajan kodunda hiçbir değişiklik gerektirmiyor.
• Anlamsal önbellekleme: Özellikle değerlendirme araçları için kullanılan bu özellik, 18.000 prompt’un gece boyunca yeni model versiyonlarına karşı denenmesine olanak tanıyor. %73 oranında önbellekleme vuruşu sağlayarak, gece başına yaklaşık 13.000 isteğin ücretlendirilmemesini sağlıyor.
• Prometheus metriği entegrasyonu: Bifrost, Prometheus’a doğal olarak entegre oluyor ve beş dakikalık bir kurulum süreciyle birlikte kullanıma hazır metrikler sunuyor. Standart paneller yetersiz olsa da, metriklerin kendisi oldukça faydalı.

Kullanılmayan Özellikler ve Sınırlamalar

Ekip, MCP geçidi, yönetişim ve tek oturum açma (SSO) gibi bazı özellikleri kullanmadı. Bunun nedeni, yetkilendirme katmanının doğrudan geçit üzerinde değil, onun önünde yer almasıydı. Özel eklenti arayüzü ilgi çekici olsa da, henüz ihtiyaç duyulmadı.

Bifrost’un genç bir proje olması nedeniyle, desteklenen sağlayıcı listesi oldukça geniş (23+) olmasına rağmen, nadir kullanılan bir sağlayıcıya ihtiyaç duyulması durumunda belgelerin kontrol edilmesi gerekiyor. Eklenti arayüzü basit olsa da, elle eklenmesi gereken özellikler için ek çalışma gerektiriyor.

Web arayüzü, ilk kurulum için kullanışlı olsa da, karmaşık yönetişim senaryoları için uygun değil. Yapılandırmaların YAML dosyaları olarak saklanması ve Git ile versiyonlanması öneriliyor.

LiteLLM’in zengin topluluk entegrasyonları ve geri çağırmaları nedeniyle, eğer ekip zaten LiteLLM kullanıyorsa geçiş maliyeti oldukça yüksek olabilir. Portkey ise kendi kendine barındırmak istemeyenler için iyi bir yönetilen hizmet seçeneği sunuyor. En doğru kararı vermek için, ekip tarafından sürdürülebilecek altyapıya odaklanılması gerekiyor.

Son bir uyarı: Yukarıdaki sayılar, Nexus Labs’ın spesifik trafik yapısına dayanıyor. Farklı bir trafik dağılımına sahip olanlar için sonuçlar değişebilir. Karar vermeden önce kendi testlerinizi gerçekleştirmeniz önem taşıyor.

Geleceğe Bakış: Altyapıyı Önemsemek

Yapay zeka modelleri hızla gelişirken, onların güvenilir bir şekilde yönlendirilmesi ve yönetilmesi de aynı derecede önem taşıyor. Nexus Labs’ın deneyimi, modellerin kolay kısım olduğunu, ancak onların arkasında yer alan altyapının — özellikle de başarısızlık anında devreye alma sürelerinin — asıl zorluk olduğunu gösteriyor. Geliştiricilerin, sadece model performansına değil, aynı zamanda API geçitlerinin güvenilirliğine de yatırım yapmaları gerekiyor.