Önce sonuç: Model ağ geçidi "birkaç API daha bağlamak" kadar basit değil; kendi başına arızalara dayanması gereken bir altyapı katmanıdır. İki yıl önce çevrimiçi konsültasyon yapan bir platform için AI entegrasyonu yapıyorduk, akıllı müşteri hizmetleri tek bir model API'si üzerinde çalışıyordu. Bir Salı gecesi saat iki civarında, üst akış 504 döndürmeye başladı; SDK varsayılan olarak üç kez yeniden deneme ve üstel geri çekilme yapıyordu, ancak iş tarafı aynı anda binlerce oturumu eşzamanlı işliyordu, yeniden deneme hacmi anında normal isteklerin birkaç katına çıktı. İş parçacığı havuzu doldu, sağlık kontrolleri bile zaman aşımına uğradı, tüm çağrı zinciri domino taşları gibi çöktü. Sonradan yapılan incelemede sorun modelin kendisinde değil, tüm yumurtaları tek sepete koymamızda ve hiçbir ağ geçidi katmanı güvencesinin olmamasındaydı.
Model ağ geçidi tam olarak neyi çözmeli
Parçalara ayırdığımızda, ağ geçidi katmanının dört şeyi üstlenmesi gerekir. Çoklu model yönlendirme temeldir; aynı "müşteri hizmetleri soru-cevap" görevi, niyete göre ucuz yerli modellere dağıtılabilir, karmaşık akıl yürütme gerektiğinde üst düzey modellere yönlendirilebilir. Hız sınırlama ve devre kesme hayat kurtarır; tek bir Key patlamadan önce proaktif olarak kesilmelidir. Protokol çevirisi en çok hafife alınan kısımdır; her SDK'nın istek gövdesi, yanıt gövdesi ve hata yapısı farklıdır. Maliyet atfı ise hesabın kapanıp kapanmayacağıyla ilgilidir; hangi iş hattının, hangi kiracının ne kadar token yaktığı kişi bazında ayrıştırılabilmelidir.
Projemizde token8341'in model ağ geçidiyle göreve göre otomatik en iyi model seçimi pratiği yaptık, OpenAI SDK ile uyumludur, base_url'yi tek satır değiştirerek geçiş yapılabilir. Bu özellik mevcut sistemler için özellikle dostudur; koddaki onlarca çağrı noktasını baştan değiştirmeye gerek yoktur. SiliconFlow'un bu katmanda yaptığı şey, özünde AI API birleştirme karmaşıklığını ağ geçidinin içine toplamaktır.
SSE akış çıktısının protokol tuzakları
Akış çıktısı tuzakların ağırlıklı olduğu bölgedir. Görünüşte herkes SSE kullanıyor, ama gerçekte farklar az değil. Parçalama stratejisinde bazı sağlayıcılar token bazında böler, bazıları cümle bazında böler, hatta bir parçaya birden fazla veri bloğu sıkıştıranlar var. Bitiş işareti daha da karışık; OpenAI tarzı data: [DONE] kullanır, bazı sağlayıcılar ise doğrudan akışı keser ve işaret vermez. Hata kodları da birleşik değil; zaman aşımı 429 olabilir, 503 olabilir, hatta 200 yanıtı içinde bir hata nesnesi taşıyan bir yanıt olabilir.
Ağ geçidi katmanının normalleştirme yapması gerekir: hepsini standart SSE formatına dönüştürmek, bitiş işaretini tamamlamak, her sağlayıcının hata kodlarını tek bir iç hata numaralandırmasına eşlemek. Böylece üst katman işi yalnızca tek bir akışı işlemek zorunda kalır. Kulağa kirli iş gibi geliyor, ama bu katman yapılmazsa her iş ekibi aynı tuzaklara tekrar tekrar düşer.
Hız sınırı yanlış kişiyi vurmayacak şekilde nasıl yapılandırılır
Token kovası düzgün hızı kontrol etmek için uygundur; kova kapasitesi ani artış toleransını, doldurma hızı ise uzun vadeli ortalamayı belirler. Kayan pencere istatistiksel hız sınırlama için uygundur, örneğin "dakikada N kezden fazla olmamak". Gerçek üretimde ikisini de kullandık: girişte kayan pencere ile kaba taneli koruma, tek Key boyutunda token kovası ile ince kontrol.
Çoklu Key rotasyonu bir diğer anahtardır. Aynı sağlayıcıdan birden fazla Key alınır, ağ geçidi ağırlıklı olarak sırayla döndürür; bir Key hız sınırına takılırsa geçici olarak çıkarılır, soğuma süresinden sonra geri alınır. Böylece tek Key'in kota sınırı doğrudan işin tavanı haline gelmez. Dikkat edilmesi gereken nokta: rotasyon mutlaka devre kesme ile birlikte çalışmalıdır, aksi halde bozuk bir Key tekrar tekrar seçilir.
Düşürme ve çoklu aktif: RPO ve RTO nasıl belirlenir
Birincil model zaman aşımına uğradıktan sonra otomatik olarak yedek modele geçilmelidir, bu işlem hızlı olmalıdır. İçeride RTO'yu "arızanın tespitinden trafiğin yönlendirilmesine" kadar geçen süre olarak tanımladık, hedef saniye düzeyine indirmektir; RPO ise oturum durumu içindir, ideal durum sıfır kayıptır, ancak akış senaryosunda zaten gönderilmiş içerik geri alınamaz, yalnızca sonraki isteklerin kesilmemesi garanti edilebilir. Yedek model seçiminde yetenek hizalaması dikkate alınmalıdır; birincil model uzun metin akıl yürütmesi yaparken yedek model yalnızca kısa soru-cevap yapabiliyorsa, geçiş yapmak sakat bir düşürmeye eşdeğerdir.
Tuzaklardan kaçınma uyarısı: yeniden deneme mantığını iş koduna yazmayın. SDK'nın kendi yeniden denemesi ağ geçidi katmanının dışındadır, arıza durumunda ağ geçidinin devre kesme stratejisiyle çakışır. Yeniden deneme ağ geçidinde birleştirilmelidir; iş tarafı yalnızca başarı veya nihai başarısızlığı alır.
Tek cümleyle özetlersek, model ağ geçidinin değeri çoklu model birleşik erişim, hız sınırlama, protokol normalleştirme ve düşürme gibi kirli işleri merkezi olarak halletmek, iş kodunu temiz tutmaktır. Daha geniş bakışla, eğer AI API ağ geçidi seçimi yapıyorsanız, tek satır base_url değişikliğiyle entegre olup olmadığına ve arıza durumundaki geçiş stratejisinin yapılandırılabilir olup olmadığına odaklanın.
Yazar: Chen Jinghang
Yayın tarihi: 4 Ekim 2026