Gateway temelleri · 2026-09-22
LLM gateway failover mimarisi: yüksek erişilebilirlik nasıl kurulur
Bir gateway'in, kendi upstream'inde tekil bir kaynağa bağımlı modellerde isteği yedek bir upstream'e nasıl yönlendirebildiğini, hangi hataların yeniden denemeye uygun olduğunu ve idempotency riskini anlatır.
Failover neden tek başına model geçişinden farklıdır
AI gateway ile LLM gateway farkı yazısında ele alınan temel ayrım, bir gateway'in birden çok sağlayıcıyı tek bir arayüzden erişilebilir kılmasıdır. Failover bunun otomatik bir sonucu değildir; kendi hattında tekil bir kaynağa bağımlı olan (örneğin kendi barındırdığınız bir sunucu veya tek bir üçüncü taraf rotası) belirli modeller için, birincil upstream bir hata (zaman aşımı, 5xx, kapasite hatası) döndürdüğünde isteğin önceden tanımlı bir yedek upstream'e yönlendirilmesi anlamına gelir. Yedek katman çoğu zaman aynı modeli sunan başka bir sunucudur; ancak bu garanti değildir. LLMTR'deki bazı satırlarda yedek katman, aynı sınıftan farklı bir modeldir: istekte yazdığınız model kimliği aynı kalır, ama yanıt o an yedekteki modelden gelebilir.
Bunu manuel bir yeniden deneme mantığından ayıran şey, kararın istemci tarafında değil gateway tarafında verilmesidir; istemci kodunuz hangi upstream'in o anda kullanılabilir olduğunu bilmek zorunda kalmaz. Bu davranış her modelde veya her gateway'de garanti değildir — kendi vendor tarafında zaten yedekli çalışan bir sağlayıcı API'sine bağlı bir model için gateway katmanında ayrıca bir failover zinciri olması gerekmez.
Hangi hatalar yeniden denemeye uygun, hangileri değil
Zaman aşımı ve geçici kapasite hataları (5xx) genellikle yeniden denemeye uygundur; aynı istek farklı bir sağlayıcıda başarılı olabilir. Buna karşılık geçersiz bir istek biçimi (400) veya yetkilendirme hatası (401/403) sağlayıcı değiştirilerek çözülmez; bu tür hatalarda failover denemek yalnızca gecikmeyi artırır ve gerçek sorunu gizler.
Bu ayrım, bir gateway'in hata sınıflandırmasını doğru yapmasını gerektirir; her hatayı aynı şekilde yeniden deneyen bir sistem, kalıcı bir hatayı geçiciymiş gibi ele alarak gereksiz maliyet ve gecikme üretir.
- Zaman aşımı ve 5xx: genellikle yeniden denemeye ve failover'a uygun.
- 400/401/403: sağlayıcı değiştirerek çözülmez, failover denemek gecikmeyi artırır.
- Doğru hata sınıflandırması olmadan failover gereksiz maliyet üretir.
Idempotency: aynı isteğin iki kez çalışma riski
Bir istek birincil sağlayıcıda kısmen işlenip sonra zaman aşımına uğradıysa, failover ile ikinci bir sağlayıcıya gönderilen aynı istek, ilk sağlayıcının aslında yanıtı üretmiş ama size ulaştıramamış olması ihtimaliyle iki kez ücretlendirilme riskini taşır. Yan etkisi olan bir işlem (örneğin bir aracın gerçek dünyada bir eylem tetiklemesi) için failover'ı, yalnızca yanıtın kesin olarak alınmadığından emin olunduğunda tetiklemek gerekir.
Sık sorulan sorular
Failover her hata türünde devreye girmeli mi?
Hayır. Yalnızca geçici olduğu düşünülen hatalarda (zaman aşımı, 5xx) failover mantıklıdır. Kalıcı hatalarda (geçersiz istek, yetkilendirme) sağlayıcı değiştirmek sorunu çözmez, yalnızca gecikmeyi artırır.
Failover kullanmak model tutarlılığını etkiler mi?
Edebilir. İstekte yazdığınız model kimliği değişmez, ama yedek katman her zaman aynı model değildir; bazı satırlarda yedek, farklı bir modeldir ve yanıt ondan gelir. Bu durumda yetenekler, tokenizasyon, üslup ve çıktı biçimi değişebilir. Yedek aynı model olsa bile farklı sunucu yazılımı küçük biçim farkları üretebilir. Kesin tutarlılık gereken akışlarda çıktıyı kendi tarafınızda şemayla doğrulayın ve bu akışları yedekli bir zincire bağımlı olmayan bir modelle çalıştırmayı değerlendirin.