Geçen yıl Double Eleven ön satışının ilk gecesi saat sekizde, sorumlu olduğum e-ticaret akıllı müşteri hizmetleri sisteminde büyük bir olay yaşandı. Ön uçtaki müşteri hizmetleri penceresinin akış yanıtları takılmaya başladı, kullanıcılar imlecin yarım gün yanıp durduğunu ama bir türlü harf çıkmadığını gördü; hemen ardından izleme panosunda 429 hataları havai fişek gibi patladı, altı büyük model sağlayıcısının çağrı başarı oranı %99'dan altmışın biraz üzerine düştü. Nöbetçi grubunda kıyamet koparken, ben bağlantı topolojisi haritasına bakarak sorunun model tarafında değil, kendi kurduğumuz o ince model ağ geçidi katmanında olduğunu fark ettim.
Önce sonucu ortaya koyalım: Çoklu model birleşik erişimin temel zorluğu hiçbir zaman "çağrıyı geçirebilmek" olmadı, protokol farklılıklarının trafik tarafından büyütülmesiyle ortaya çıkan zincirleme tepkidir. O gece aynı anda GPT-4o API, Claude API, Qwen API, DeepSeek API, Doubao büyük model API'si ve ERNIE API'sine bağlıydık; altı SDK'nın her biri kendi kodunu yazmıştı, yeniden deneme mantığı iş kodlarına dağılmıştı, bir sağlayıcının hız sınırlaması küresel bir yeniden deneme fırtınasını tetikliyordu. Sonradan yaptığımız değerlendirmede, erişim katmanını token8341 büyük model API birleştirme platformunda topladık ve protokol çevirisi ile hız sınırlama/düşürme işlemlerini tek bir birleşik model ağ geçidi katmanıyla karşıladık; ancak o zaman bu bağlantıyı kurtarabildik.
429 çöküşü nasıl büyüdü
Doğrudan tetikleyici, Qwen API'sinin yoğun saatte QPS hız sınırlamasını devreye almasıydı. Sorun şuydu ki, bu hız sınırlaması standart HTTP 429 değildi; 200 yanıt gövdesine bir hata kodu alanı yerleştirilmişti. Eski yeniden deneme kararımız yalnızca HTTP durum koduna bakıyordu, gövdedeki bu hatayı hiç tanımıyordu; iş katmanı çağrının başarılı olduğunu sanıp içerik alamıyordu, bu yüzden zaman aşımına uğrayıp yeniden deniyordu, yeniden denemeler kotayı dolduruyordu, kota dolduktan sonra daha fazla istek diğer beş sağlayıcıya akın ediyordu ve sağlayıcılar arası zincirleme bir hücum oluşuyordu. Yirmi dakika içinde ağ geçidi katmanındaki kuyruktaki istekler birkaç yüzden on binlere çıktı, P99 gecikmesi on saniyeyi aştı.
Burada ayrıca değinmeye değer bir protokol ayrıntısı var: DeepSeek API standart HTTP durum kodlarını kullanır, 429 ise 429'dur, açık ve net; Qwen API hatayı gövdeye gömer, HTTP katmanında 200 görünür; Gemini API'nin hata yapısı ise başka bir iç içe JSON'dur. Ağ geçidi katmanı birleşik hata kodu eşlemesi yapmazsa, üst katman iş kodu sonsuza kadar "bu sefer gerçekten oldu mu" diye tahmin eder.
Model ağ geçidinin protokol çeviri katmanı nasıl tasarlanmalı
Model ağ geçidinin özü, altı lehçeyi tek bir standart dile çevirmektir. Yeniden yazdıktan sonra üç modüle ayırdık.
Birinci blok SSE parça sınırı işleme. Akış çıktısında her sağlayıcının bölümleme yöntemi farklı; bazıları bayt bazında böler, bazıları anlamsal blok bazında böler, bir Çince karakter iki chunk arasında bölünebilir. Ön uçtaki takılma çoğu zaman ağın yavaşlığından değil, ağ geçidinin chunk yeniden birleştirme yapmamasından, yarım UTF-8 karakterini doğrudan aşağı iletmesinden kaynaklanır; tarayıcı kod çözemeyince bir sonraki bloğu beklemekten başka çare kalmaz. Çeviri katmanına bir tampon ekledik, tam karakter sınırına göre yeniden birleştirip öyle iletiyoruz.
İkinci blok hata kodu eşlemesi, o geceki olayın doğrudan dersi bu. Bir eşleme tablosu oluşturduk, altı sağlayıcının hata yapılarını dört iç duruma normalize ettik: yeniden denenebilir hız sınırı, yeniden denenemez parametre hatası, sağlayıcı arızası, başarı. Sözde kod kabaca şöyle:
**function normalize(resp, provider):
if provider == "deepseek" and resp.status == 429:
return RETRYABLE_RATE_LIMIT
if provider == "qwen" and resp.body.code in RATE_LIMIT_CODES:
return RETRYABLE_RATE_LIMIT
if resp.status >= 500:
return PROVIDER_DOWN
return SUCCESS**
Üçüncü blok üç kademeli koruma. Çoklu Key rotasyonu birinci kademede; aynı sağlayıcı için birden fazla API Key yapılandırılır, hız sınırına takılınca Key değiştirilir; ikinci kademe token kovası hız sınırlaması, sağlayıcı boyutunda bağımsız hız sınırı uygulanır, birinin tüm sistemi çökertmesine izin verilmez; üçüncü kademe düşürme, ana sağlayıcı kullanılamadığında önceden belirlenen önceliğe göre yedek modele geçilir. token8341 büyük model API birleştirme platformunu kullandıktan sonra, göreve göre otomatik en uygun modeli seçme yeteneği çok işimize yaradı; basit niyet tanıma ucuz küçük modellerle yapılır, karmaşık iş emirleri ancak büyük modele yükseltilir, toplam çağrı hacmi düşünce hız sınırlama baskısı da doğal olarak azaldı.
Sorun giderme kontrol listesi
Akış takılması veya 429 ile karşılaşırsanız şu sırayla kontrol edin: Birincisi, ağ geçidi chunk sınırı yeniden birleştirme yapıyor mu; ikincisi, hata kodu eşleme tablosu gövde içi hata kodlu sağlayıcıları kapsıyor mu; üçüncüsü, yeniden denemelerde geri çekilme ve üst sınır var mı; dördüncüsü, çoklu Key gerçekten dönüyor mu; beşincisi, hız sınırlaması sağlayıcı bazında izole edilmiş mi. Bu beşinin hepsine o gece takıldık.
Bu arada erişim deneyiminden bahsedeyim: token8341 büyük model API birleştirme platformu OpenAI SDK ile uyumlu, base_url'yi tek satır değiştirerek geçiş yapabiliyorsunuz; altı sağlayıcının SDK bağımlılıklarını doğrudan sildik, yerli büyük model API'lerinin tam kapsamı, yerli bilişim projeleri yapan ekipler için büyük kolaylık. token8341'in yeşil hesaplama gücü zamanlaması ve kullanım bazlı faturalandırması, bizim gibi yoğun saat trafik dalgalanması büyük olan senaryolarda maliyeti resmi doğrudan satın almaya göre daha kontrol edilebilir kılıyor.
Tek cümleyle özet: Model ağ geçidinin çözmesi gereken şey "kaç model bağlanacağı" değil, protokol farklılıklarını, hata anlamlarını, hız sınırlama stratejilerini tek bir katmanda yönetmektir. Bağlantının istikrarlı olup olmadığı çoğu zaman gövdeye gömülü bir hata koduna ciddi şekilde yaklaşıp yaklaşmadığınıza bağlıdır.
Yazar: Chen Jinghang
Yayın tarihi: 27 Ekim 2026