Eski LLM Altyapısını Bir AI Gateway Mimarisine Taşıma

Hafta sonu prototipi olarak geliştirilen bir yapay zekâ destek asistanı (copilot) genelde basit bir mimariyle başlar: tek bir model, tek bir sağlayıcı ve .env dosyasında tanımlı tek bir API anahtarı. Ancak bu yapı canlı üretime (production) geçtiğinde ciddi zafiyetler doğurur: Sağlayıcının kesintisi doğrudan sizin kesintiniz haline gelir, yeniden deneme (retry) mantığı uygulama koduna yüklenir, harcamalar ay sonu faturasına kadar belirsiz kalır ve araç kullanımı (tool-use) derme çatma yöntemlerle entegre edilir.

Bu çalışma; söz konusu kırılgan yapıyı Go ile yazılmış, 23'ten fazla sağlayıcıyı OpenAI uyumlu tek bir arayüz altında toplayan açık kaynaklı bir kurumsal AI Gateway (Bifrost) arkasına taşımanın adımlarını ve test sonuçlarını ortaya koymaktadır.

Eski Altyapının Ölçümü ve Kesinti Analizi

Bir destek asistanının trafik profili genellikle sık yinelenen SSS soruları ile anlık sorgulardan oluşur. 60 istekten oluşan bir test kümesinde (8 farklı sorunun beşer kez tekrarlandığı 40 SSS + 20 tekil sorgu; 200 ms simüle sağlayıcı gecikmesi):

Doğrudan Sağlayıcı Testi (Run 1): 60 başarılı, 0 başarısız istek, 9.335 faturalandırılan token ve ~201 ms ortalama gecikme kaydedildi.
Sağlayıcı Çökme Testi (Run 2): Testin ortasında sağlayıcı devre dışı kaldığında 34 başarılı ve 26 başarısız istek oluştu; yani isteklerin %43'ü doğrudan çöktü.

Uygulama doğrudan tek bir sağlayıcının API'siyle konuştuğundan, arıza anında farklı sağlayıcılara yönelme kabiliyetine sahip değildir. Ayrıca paylaşılan tek anahtar tüm ekipler için ortak bir kota tavanı oluşturur, anahtar iptal edildiğinde tüm sistem durur, harcamaların ekip bazlı takibi yapılamaz ve tekrarlayan sorgularda maliyet düşürmek için karmaşık önbellekleme (caching, hash, TTL) mantıklarının uygulama içine manuel yazılması gerekir.

Adım Adım Gateway Geçişi

Bu riskleri ortadan kaldırmak için geri alınabilir 3 temel adım izlenir:

Gateway'i Uygulamanın Yanına Dağıtın: docker run -p 8080:8080 maximhq/bifrost komutuyla gateway ayağa kaldırılır. Tek bir JSON yapılandırma dosyasıyla mevcut sağlayıcı ve anahtarlar sisteme bağlanır. Uygulama koduna dokunulmadan gateway yan servis (sidecar) veya Go SDK ile gömülü olarak çalıştırılabilir.
Düşük Riskli Bir İstemciyi Yönlendirin: OpenAI uyumlu uç nokta sayesinde kod tabanında köklü değişiklik yapılmaz; yalnızca istemcinin hedef adresi api.openai.com yerine localhost:8080 olarak güncellenir. Böylece tüm trafik kontrol edilebilir bir ara katmandan akar.
Yedek (Fallback) Sağlayıcı Ekleyin: İkinci bir sağlayıcı (anthropic) tanımlanarak istek gövdesine fallbacks: ["anthropic/support-chat"] zinciri eklenir. Birincil sağlayıcı aktifken istek doğrudan işlenir (is_fallback: false), arıza anında ise trafik kesintisiz biçimde yedek sağlayıcıya aktarılır.

Yazılım Geliştirme Açısından Çıkarımlar

Bu mimari dönüşüm, LLM entegrasyonlarının uygulama mantığından soyutlanmasının önemini gösterir. Bir AI Gateway; yüksek erişilebilirlik (fault tolerance), merkezi kimlik denetimi ve sağlayıcı bağımsızlığını (vendor lock-in engelleme) tek bir katmanda çözerek dayanıklı bir üretim ortamı sağlar.

Orijinal kaynağa buradan ulaşabilirsiniz.

Bu konuyu derinlemesine öğrenmek isterseniz: Helicone: API Gateway Tabanlı Monitoring modülüne göz atın.