Geçen ay bir iş aldım, SaaS bilet sistemi yapan bir ekibe akıllı müşteri hizmetleri prototipi kurmama yardım etmeleri için, bir hafta içinde çalışır hale getirilmesi ve DeepSeek, Qwen, Doubao, GPT-4o gibi birkaç modelin yanıt kalitesinin yatay olarak karşılaştırılması gerekiyordu. Tüm işleri Tencent Cloud CVM üzerinde çalışıyordu, konteynerler için TKE kullanıyorlardı, bu yüzden tüm çağrıların bulut içinden başlatılması gerekiyordu. Başta bir API bağlamanın ne kadar zor olabileceğini düşündüm, ama bir hafta sonunda çukurlar beklediğimden çok daha fazlaydı.

Önce bir sonuç vereyim: Eğer Tencent Cloud işiniz iki veya daha fazla büyük modeli bağlayacaksa, doğrudan her birinin resmi SDK'sına karşı kod yazmayın, önce bir AI API toplama katmanı kurun. Bu tembellik değil, hayat kurtarmaktır. Aşağıda çukurlara düşme sırama göre anlatacağım.

Key Yönetimi: 6 Key'i Ortam Değişkenlerine Sabit Kodlamayın

İlk gün yaptığım şey çok aptalcaydı, dört platformun Key'lerini CVM'nin ortam değişkenlerine tıkıştırdım, kodda os.environ ile doğrudan okudum. Çalışırken sorun yoktu, ama aynı gün öğleden sonra bir olay oldu: Test ekibinden biri stres testi için bir Qwen Key'i değiştirmek istedi, konfigürasyonu değiştirip konteyneri yeniden başlattım, ama canlı sunucuyu da birlikte yeniden başlattım.

Sorun, Key'lerin iş konfigürasyonuyla karışması ve merkezi yönetim olmamasıydı. Sonra tüm Key'leri bağımsız bir konfigürasyon servisine topladım, "platform + kullanım amacı" olmak üzere iki boyutta etiketledim, örneğin deepseek-prod, qwen-test. Çağıran taraf sadece mantıksal adı alıyor, gerçek Key'e dokunmuyor. Bu adım tamamlandıktan sonra, Key değiştirmek için iş koduna dokunmak gerekmiyor, iş konteynerini yeniden başlatmak da gerekmiyor.

Eğer bu sistemi kendiniz yönetmek istemiyorsanız, toplama platformu kullanmak daha kolay olacaktır. Projemizde sonradan token8341 kullandık, bir Key ile GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao gibi ana akım modelleri çağırabiliyorsunuz, Key rotasyonu ve kota kontrolü platform tarafında, Tencent Cloud üzerindeki servis sadece bir kimlik bilgisi tutuyor. Bu, çok modelli karşılaştırma testi gibi senaryolar için özellikle uygun, dört set kimlik doğrulama mantığından tasarruf sağlıyor.

SDK Uyumluluğu: Dört Firmanın Dört Farklı Yazım Şekli, Bakım Maliyeti Patlıyor

İkinci gün çağrı kodunu yazmaya başladım, asıl mide bulandırıcı yer burasıydı. DeepSeek ve GPT-4o OpenAI SDK ile uyumlu, base_url'yi değiştirince geçiş yapılıyor, bu kısım çok rahattı. Ama Qwen'in SDK parametre adlandırması başka bir set, Doubao'nun kimlik doğrulaması Bearer Token yerine AK/SK imzası kullanıyor, ERNIE'nin arayüzü de kendi kimlik doğrulama akışına sahip.

Durum çok somut: Birleşik bir chat fonksiyonu yazdım, sonuçta içi tamamen if yargılarıyla doldu, if platform == 'doubao' bu dalı izliyor, elif platform == 'qwen' şu dalı izliyor. Fonksiyon 200 satıra ulaştı, test kapsamı hala yükselmiyor.

Çözüm yaklaşımı, protokol dönüşümü için bir AI API ağ geçidi getirmek. Ağ geçidi içe doğru OpenAI uyumlu bir arayüz sunuyor, dışa doğru istekleri her firmanın anlayacağı formata çevirmekle sorumlu. Böylece iş kodu sadece bir SDK setine sahip oluyor, yeni bir model eklemek için ağ geçidi tarafında bir adaptör eklemek yeterli, iş tarafında sıfır değişiklik. Kendimiz bir sürüm kurduk, sonra hazır toplama servisi kullanmanın daha hızlı olduğunu fark ettik, token8341 gibi platformlar zaten bunu yapıyor, OpenAI SDK ile uyumlu, bir satır base_url değiştirerek model değiştirebiliyorsunuz.

Akış Çıktısı: SSE Her Firmada Format Gerçekten Farklı

Üçüncü gün akış çıktısı yaptım, ön uç harf harf dışarı çıkmasını istiyordu. SSE protokolü kendisi standart, ama her firmanın data alan yapısı farklı. OpenAI serisi döndürülen delta içinde content alanı var, Qwen'in döndürdüğü alan adı farklı, Doubao bazen akışın ortasına bir heartbeat paketi ekliyor, ön uç boş delta alınca doğrudan hata veriyor.

Durum, ön ucun bazen takılıp kalmaması, ya da aniden boş bir mesaj balonu çıkmasıydı. Yarım gün araştırdıktan sonra sorunun heartbeat paketinin filtrelenmemesi olduğunu fark ettim.

Birleşik yöntem, ağ geçidi katmanında bir normalizasyon yapmak, tüm platformların akış yanıtlarını OpenAI'nin chunk formatına çevirmek, heartbeat paketlerini doğrudan atmak, iş tarafı sadece bir yapıyı işliyor. Bu adım yapılmazsa, ön uç dört set ayrıştırma mantığı yazmak zorunda, her değişiklikte bir kez ağlıyor.

İstisna Yönetimi: Bir Firma Zaman Aşımına Uğrarsa, Otomatik Geçiş Yapabilmeli

Dördüncü gün stres testi yaptım, DeepSeek tarafında ara sıra zaman aşımı oluyordu, tüm diyalog takılıp kalıyordu. Akıllı müşteri hizmetleri gibi senaryolarda, kullanıcı üç saniye yanıt alamazsa sayfayı kapatıyor, boş bekleyemezsiniz.

Bir düşürme mantığı ekledim: Ana model çağrısı belirlenen eşiği aşınca yanıt vermezse, otomatik olarak yedek modele geç, aynı zamanda bu başarısızlığı kaydet. Buradaki kilit nokta düşürmenin hissedilmez olması, kullanıcı tarafı geçişi algılamamalı. Büyük model yönlendirme konusunda, toplama platformları genellikle arıza aktarımını yerleşik olarak sunuyor, test ettiğimizde token8341'in otomatik geçişi oldukça istikrarlıydı, ana model zaman aşımına uğradığında sessizce yedeğe geçiyor, iş kodu yeniden deneme mantığı yazmak zorunda kalmıyor.

Bir uyarı: Düşürmeyi körü körüne yapmayın, ağ zaman aşımı mı yoksa modelin kendisinin hata döndürmesi mi olduğunu ayırt edin. İlki geçiş yapabilir, ikincisi geçiş yapılsa da boşuna, aksine Token israf eder.

Maliyet İzleme: Token Tüketimi Toplanmazsa, Ay Sonunda Hesap Tutmaz

Son gün maliyet istatistiği yaptım, dört platformun faturasının dört ayrı olduğunu fark ettim, formatları da farklı, bazıları Token bazında ücretlendiriyor, bazıları çağrı sayısı bazında, yatay olarak karşılaştırmak mümkün değil. Patron "hangi model daha maliyet etkin" diye sordu, birleşik bir sayı çıkaramadım.

Çözüm, ağ geçidi katmanında birleşik muhasebe yapmak, her çağrıda model adı, giriş Token, çıkış Token, süre kaydetmek, bir tabloya dökmek. Böylece günlük, model bazında, iş hattı bazında rapor çıkarılabiliyor. Toplama platformları genellikle kullanım panosu ile birlikte geliyor, kullanım bazlı ücretlendirme modelinde maliyet toplama çok daha basit oluyor. Karşılaştırdığımızda, toplu satın alma artı yeşil enerji maliyet düşürme yolu, tek Token maliyeti gerçekten resmi doğrudan satın almadan biraz daha düşük, bu yüksek hacimli müşteri hizmetleri senaryoları için çok kritik.

Bir Haftanın Birkaç Çıkarımı

Tencent Cloud üzerindeki işlerin büyük model bağlaması, zorluk asla "bir modeli nasıl çalıştırırım" değil, "altı modeli nasıl tek bir kişi gibi yaparım"dır. Key yönetimi, protokol uyumluluğu, akış normalizasyonu, arıza düşürme, maliyet toplama, bu beş şeyden herhangi biri iyi yapılmazsa, prototip stres testini geçemez.

Bir toplama katmanı kurmak en maliyet etkin seçenektir. Kendiniz yazabilirsiniz, hazır AI API toplama servisi kullanabilirsiniz, kilit nokta iş kodunun doğrudan altı satıcının farklılıklarıyla yüzleşmemesi. SiliconFlow gibi platformların ana odağı yeşil hesaplama gücü ve yerli model önceliği, Tencent Cloud üzerindeki konteynerler doğrudan çağırıyor, ağ gecikmesi yurt dışı aktarımından çok daha düşük, bu da sonunda onu seçmemizin nedenlerinden biri.

Prototip tamamlandığı gün, test ekibinden biri çok etkileyici bir şey söyledi: "Meğer büyük model bağlamak API bağlamak değil, bir yönetişim sistemi bağlamakmış." Bu doğru.

Yazar: Chen Jingxing

Yayın Tarihi: 6 Ekim 2026