Çoklu Sağlayıcı Yapay Zeka Mimarisinde Kota Fail-Over Disiplini

Üretim bir AI içerik pipeline’ı çalıştırıyorum: günde 4-8 yazı, çoklu kategori, otomatik yayın. İlk altı ay tek sağlayıcı (Gemini) ile gayet sorunsuzdu. Sonra bir sabah pipeline durdu. Sağlayıcı çökmüş değildi. Sadece bana cevap vermiyordu.

Bu yazı, o sabahki paniği yedi farklı saha hatasıyla birleştirip nasıl bir fail-over disiplinine dönüştüğümü anlatıyor. Sağlayıcı seçimi, zincir dizilimi, kota izleme, kalite kabul kriterleri ve “sessiz çürüme” kavramı üzerinde duracağım.

Tek sağlayıcı: en sinsi single point of failure

Mimari kararlarda en zor şey, “çalıştığı sürece sorun olmayan” şeyleri risk olarak görmektir. AI sağlayıcı seçimi tam olarak buydu benim için: Gemini ücretsiz katmanı altı ay boyunca aksamadı. Aksamadığı için ben de fail-over kurmadım.

Sonra şu sabah geldi: pipeline 09:00’da başladı, ilk üç istek 200 döndü. Dördüncüde 429. Beşincide 429. Bir saat sonra hâlâ 429. Sağlayıcının status sayfası “operasyonel” diyordu — çünkü gerçekten öyleydi. Sadece benim hesabımın o günkü payı tükenmişti.

Burada sahada öğrenilen iki gerçek var:

• Free tier kotaları görünmez tükenir. Sağlayıcının panelinde “günde 1.500 istek” yazıyor olabilir, ama o sayı global trafik yoğunluğuna göre dinamik kısılabilir. Sabah 09:30’da 429 alıyorsanız, sebep sizin değil; o saatte tüm dünyada kontenjan dolduğu için kuyruğun arkasına atıldınız demektir.
• Çökme ile servis vermeyi reddetme aynı şey değildir. Status sayfaları yalnızca birinciyi gösterir. İkinci, sizin uptime metriğinizde bir delik açar ama hiçbir sayfada görünmez.

Fail-over zincirini nasıl dizmeli?

Pipeline’ı çoklu sağlayıcıya geçirme kararı verdikten sonra ilk yaptığım yanlış, sıralamayı maliyete göre yapmaktı: en ucuz olan önce, pahalı olan en sonda. Mantıklı görünüyordu. Yanlıştı.

Sahada şunu öğrendim: birbirine yakın altyapılı sağlayıcılar aynı anda düşer. Aynı GPU üreticisini kullanan iki inference şirketinin kotalarını aynı saatte tüketmek hiç de istisnai değil. Yani fail-over değil, sadece geciktirilmiş arıza yaşıyordum.

Şu anki zincirimde sıralama tamamen risk korelasyonu üzerine kurulu:

1. Gemini (Google): birincil. Maliyet/kalite oranı en iyi olduğu için.
2. Groq: Google ekosisteminden bağımsız, kendi LPU silikonunda inference yapıyor. Aynı saatte 429 alma olasılığı düşük.
3. Cerebras: Yine ayrışık donanım (wafer-scale chip), farklı veri merkezleri, farklı kontenjan politikası.
4. OpenRouter: Broker. Yukarıdakilerin hiçbiri çalışmazsa, OpenRouter farklı modellere yönlendiriyor — son çare.

Üçü de aynı dakikada düşerse, OpenRouter genelde başka bir backend (Anthropic, Mistral, vs.) üzerinden cevap verebiliyor. Mükemmel garanti değil ama olasılık çarpımı oldukça düşük.

Kotayı sağlayıcının değil, kendinizin izleyin

Çoklu sağlayıcıya geçtikten sonraki üçüncü ay, başka bir tuzağa düştüm: pipeline çalışıyor görünüyordu ama çıktı kalitesi düşmüştü. Sebep şuydu: Gemini limitlerine ulaşılınca Groq’a düşüyordu — fakat Groq’taki modelim daha küçük parametreli olduğu için yazılar daha sığ çıkıyordu. Pipeline başarılıydı, içerik zayıftı.

Bu olaya kendi terimimle “sessiz çürüme” diyorum. Sistemin metriği yeşildir, kullanıcı deneyimi çürür. Çözüm üç katmanlı:

• Provider telemetrisi: her isteğin önüne sağlayıcı/model/token/latency/başarı kaydeden bir middleware ekledim. Sağlayıcının kendi konsolu artık ikincil; ben kendi sayaçlarımı izliyorum.
• Günlük bütçe sınırı: Cerebras’ta günde 1.000 üretim, Groq’ta 600 — gibi limitler. Bunlar sağlayıcının limiti değil benim limitim. Aşılınca pipeline otomatik bir sonraki sağlayıcıya geçer.
• Kalite skoru: her çıktıya basit bir skor (kelime sayısı, başlık sayısı, JSON şemasına uyum, halüsinasyon kelime tespiti). Skor eşik altındaysa zincire devam edilir; eşik üstündeyse kabul edilir.

Bu üçünün birlikte çalışması, sessiz çürümeyi 24 saat içinde yakalamamı sağladı. Önceden iki haftalık bir körlük yaşıyorduk.

Prompt’larınızı model agnostic değil, “minimum garantili çıktı” odaklı yazın

Eski yaklaşımım “bir prompt yaz, her modelde aynı çıktıyı al” idi. Yanlış. Her modelin tonu, uzunluk eğilimi, halüsinasyon yüzeyi farklı. Bunu kabul edip prompt yapısını değiştirdim:

Eski:

"Aşağıdaki konu hakkında 1500 kelimelik bir yazı yaz."

Yeni:

"Aşağıdaki konu hakkında bir yazı üret. Şu şartlar bağlayıcıdır:
 - JSON şeması: { "title": string, "sections": [{"h2": string, "body": string}, ...] }
 - En az 5 section, her section en az 200 kelime
 - 'Yapay zeka kullandım' veya benzeri meta cümleler yasak
 - Sonuç JSON'unun dışına hiçbir şey yazma"

İkinci yaklaşım hangi modeli kullanırsam kullanayım iskelet aynı kalıyor. Kalite hâlâ değişiyor ama kabul edilebilir taban hattı garanti edilmiş oluyor. Çıktıyı şemaya karşı doğrulayan validator katmanı şemaya uymayan üretimi reddedip zincire devam ettiriyor.

Retry stratejisi: hızlı geçiş mi, sabırlı bekleme mi?

Sağlayıcı 429 döndüğünde iki yol var: hemen bir sonraki sağlayıcıya geç, ya da exponential backoff ile aynı sağlayıcıyı dene. İlk içgüdüm “hemen geç” idi — pipeline hızlı çalışsın. Yanlıştı.

Çünkü 429’ların büyük çoğunluğu anlık tepe yoğunluğu kaynaklı. 30-60 saniye beklemek, çoğu durumda kotanın resetlenmesine yetiyor. Hemen geçmek demek, hem ana sağlayıcının ekonomisinden faydalanmamak hem de fail-over hedefini gereksiz yere ısıtmak demek.

Şu anki strateji:

• 429 → 30 sn bekle → tekrar dene (max 2 deneme)
• 500/503 → 0 sn beklemeden bir sonraki sağlayıcıya geç (gerçek arıza)
• 401/403 → fail-over yok, doğrudan alarm (auth sorunu, çözüm operasyonel)
• Diğer hatalar → 10 sn bekle → bir sonraki sağlayıcı

Bu ayrımı yapmak, fail-over’ın yanlış kullanılmasını engelliyor. Auth sorununda fail-over zincirini ısıtmak hiçbir şeyi çözmez; ben uyanıp credential’ı düzeltmeliyim.

Maliyet izleme: panelden değil, kendi telemetrinizden

İlk yıl sağlayıcının kendi konsolundan maliyet takip ediyordum. Ay sonu sürpriz oluyordu. Şimdi her isteğin maliyetini kendi tablomda hesaplıyorum: model, input tokens, output tokens, sağlayıcının fiyat çarpanı.

Bu sayede:

• Gün ortası “bu hafta hangi sağlayıcı en pahalı oldu” sorgusu çalıştırabiliyorum.
• Sağlayıcının faturasındaki anomalileri (örneğin sayım hatası) hemen yakalıyorum.
• Bütçe trendini erken görüyorum, “ay sonu sürprizi” diye bir şey kalmıyor.

Tutulan veri minimum:

provider, model, request_id, ts, input_tokens, output_tokens,
latency_ms, http_status, cost_estimate_usd, quality_score

Bunlar günlük dosyaya yazılıyor, haftalık aggregate alıp dashboarda dökülüyor. Pahalı bir altyapı değil, tek bir tablo ve bir kaç sorgu.

Sessiz çürümeyi yakalama: kalite skoru zorunlu

Yukarıda bahsettim ama altını çizmek istiyorum: çoklu sağlayıcı mimarisinin en önemli bileşeni kalite skoru. Yoksa fail-over’a düştükçe yavaş yavaş kötüleyen bir sistem elde edersiniz.

Kalite skoru karmaşık olmak zorunda değil. Benim baktığım birkaç sinyal:

• Toplam kelime sayısı hedefin %80’inin altında mı?
• Markdown başlık sayısı 3’ten az mı?
• JSON şemasına uyum tam mı?
• “yapay zeka”, “asistan olarak”, “bir AI olarak” gibi meta cümleler var mı?
• Aynı paragraf iki kere mi geçiyor (duplicate detection)?

Bu beş kontrol bile sistemin sessizce çürümesini yakalamaya yetiyor. Kalite skoru eşiğin altındaysa, çıktı kabul edilmez, zincirde bir sonraki sağlayıcı denenir. Eğer tüm sağlayıcılar eşiğin altında kalırsa, o iş kuyruğa atılır — manuel inceleme.

Alarmlar: ne zaman insan uyandırmalı?

Çoklu sağlayıcı mimarisi en güzel yanı, çoğu hatayı sessizce çözer. Kötü yanı: gerçekten insan müdahalesi gerektiren durumlarda da sessiz kalma riski. Bu yüzden alarm tanımı kritik:

• Zincirdeki tüm sağlayıcılar fail oldu (son N denemede): PagerDuty/Telegram bildirim.
• Aynı sağlayıcı 1 saatten uzun süre fail veriyorsa: günlük bildirim, acil değil ama dikkat.
• Günlük bütçe %80’i geçildi: uyarı bildirim.
• Kalite skoru ortalaması 7 gün düşüş trendinde: haftalık rapor.

Yani her hata için değil, sadece otomasyonun çözemeyeceği desen için alarm. Aksi takdirde alarm yorgunluğu sistemi öldürür.

Pratikteki ölçümler — bir yılın sonu

Çoklu sağlayıcıya geçtikten sonra üretim metriklerim:

• Tek sağlayıcı dönemi: %93.4 başarı oranı, 12 günde 1 outage (~6 saatlik blackout).
• Çoklu sağlayıcı dönemi: %99.7 başarı oranı, 4 ay boyunca 0 blackout.
• Yıllık ek maliyet: ~%18 artış (çünkü ucuz olmayan sağlayıcılara düşülen istekler).
• Kalite skoru ortalaması: öncekinden ~%5 düşüş — fakat sıfır outage karşılığında kabul edilebilir.

Bu sayıların önemli kısmı şu: maliyetimi bilerek artırdım ve uptime’ımı bilerek aldım. Tek sağlayıcıda yaşadığım her outage’ın iş sonuçlarına etkisi (yayınlanamayan içerik, kullanıcı bekleyişi, gecikmiş SEO sinyalleri) hesaba katıldığında, %18 fazla harcama oldukça ucuz bir sigorta oldu.

Sık karıştırılan sorular

Yedek sağlayıcıyı sadece arıza anında mı çağırmalı? Bazı sağlayıcılar uzun süre çağrılmazsa “soğuk” kalır; ilk istek geç dönebilir. Ben haftada en az bir kez yedek zincirin tamamını dolaşan bir health check çalıştırıyorum. Hem servis hâlâ canlı mı doğrulanıyor, hem de soğuk başlangıç riskini erken tespit ediyorum.

Her sağlayıcının kendi prompt formatı varsa ne yapmalı? Bunu adapter katmanıyla soyutladım. Sistem dahili bir generic prompt nesnesi kullanıyor; her sağlayıcı için bir küçük adapter onu API-spesifik formata çeviriyor. Aynısı yanıt için tersi yönde işliyor. Bu sayede prompt’u tek yerde değiştirmek bütün zincire yansıyor.

Yedek sağlayıcı maliyeti birincil’den çoksa ne yapmalı? Bütçe sınırı koyun. Benim Cerebras günlük 1.000 üretim sınırı bu yüzden var — fail-over’a düşen pipeline’ın maliyetini öngörülebilir tutmak için. Bütçe aşılırsa ya pipeline durur ya da daha ucuz bir alternatife yönlendirilir.

Sonuç

Çoklu sağlayıcı yapay zeka mimarisi, “tek sağlayıcı çökerse alternatife geç” cümlesinin çok ötesinde bir disiplin. Risk korelasyonu düşük sağlayıcı seçimi, kotanın görünmez tükenmesini izleyen telemetri, sessiz çürümeyi yakalayan kalite skoru ve doğru retry stratejisi olmadan, fail-over sadece geciktirilmiş bir arızadır.

Üretimde AI üzerinde çalışan herkes için pratik öneri: bugün hâlâ tek sağlayıcıyla çalışıyorsanız, ikinci sağlayıcıyı en azından gölge modunda ekleyin — paralel çağırıp çıktıları karşılaştırın, ama yayınlamayın. İki ay sonra fail-over zincirine geçmek için gerekli tüm veriye sahip olursunuz, ayrıca rahat bir uykuya da.