Geçen hafta bir iş aldım: SaaS talep yönetim sistemi geliştiren bir ekibe akıllı müşteri hizmetleri prototipi kurmak. Bir hafta içinde çalışır hale getirilmesi ve GPT-4o, DeepSeek-V3, Qwen-Max, Doubao olmak üzere dört modelin yanıt kalitesinin yatay olarak karşılaştırılması gerekiyordu. Kulağa zor gelmiyor, ama gerçekten işe koyulunca anlaşılıyor ki çoklu model birleşik entegrasyon meselesinde tüm tuzaklar detaylarda gizli. Bu yazıda süreci kayda geçiriyorum, benzer çoklu model karşılaştırması yapacak meslektaşlara zaman kazandırsın.
Key Yönetimi: 5 platform 5 ayrı arka uç, önce hesabı netleştirin
Başlangıçtaki en büyük sıkıntı kod yazmak değil, Key yönetimiydi. Dört model dört platformdan geliyordu, yedek bir tane daha eklenince beş arka uç, beş konsol oldu. Her birinin Key formatı, kota görüntüleme yöntemi, hız sınırlama kuralları farklıydı. Bazı platformlar Key'i doğrudan açık metin olarak gösteriyor, bazıları önce alt hesap oluşturup sonra atama yapmanızı istiyor. Prototip aşamasında hız öncelikli olduğu için tüm Key'leri tek bir .env dosyasına doldurdum. Ertesi gün test hacmi artınca bir platformun Key'i hız sınırına takıldı ve hata mesajından hangi platformun sorunu olduğu anlaşılmıyordu.
Sonradan bir katman yapılandırma eşlemesi kullanmaya geçtim: her platformun Key'ini bir takma ad ve kullanım etiketiyle eşleştirdim, loglarda sadece takma adı yazdırdım. Daha da pratik bir yol, AI API toplama platformu üzerinden gitmek: tek Key tüm modelleri yönetiyor. Karşılaştırma sırasında token8341'i denedik; model ağ geçidi birkaç yerli büyük modelin kimlik doğrulamasını tek noktada topluyor, model değiştirmek için sadece yapılandırmadaki model adını değiştirmek yeterli, Key'e dokunmaya gerek yok. Prototip aşaması için dört ayrı kimlik doğrulama mantığını yönetmemek, bir haftalık sürenin yetmesi için şart.
SDK Uyumluluğu: Her platformun arayüzü farklı görünüyor
SDK kurulum adımı, sabrın yarısını tüketmeye yetiyor. OpenAI SDK ekosistemi en olgunu, birçok üretici uyumlu olduğunu iddia ediyor ama gerçekten entegre edince parametre adlarının uyuşmadığı ortaya çıkıyor. Örneğin bazı platformlarda temperature "temperature" olarak geçiyor, bazıları top_p ile karıştırıyor, hatta max_tokens'ı max_output_tokens olarak değiştirenler var. Akış (streaming) anahtarı da standart değil: bazıları stream=True kullanıyor, bazıları ayrıca stream_options göndermenizi istiyor.
Benim yaklaşımım bir adaptör katmanı soyutlamak oldu: dışarıya yalnızca birleşik bir çağrı fonksiyonu sunuyor, içeride üreticiye göre dallanıyor. Böylece iş kodu farklılıkları algılamıyor. Bu katmanı kendiniz yazmak istemiyorsanız, OpenAI SDK ile uyumlu çözümler epey iş kolaylaştırıyor; base_url'i tek satır değiştirerek model değiştirebiliyorsunuz, çoklu model birleşik entegrasyonun karmaşıklığı doğrudan kod katmanından yapılandırma katmanına taşınıyor. Prototip doğrulama aşamasında bu ödün vermeye değer.
Akış Çıktısı: SSE protokolünün her platformdaki uygulaması farklı
Akıllı müşteri hizmetlerinde akış şart, yoksa kullanıcı üç saniye bekleyip ancak yazıyı görür, deneyim anında çöker. Sorun şu ki SSE protokolünün uygulama detayları platformdan platforma değişiyor. Bazı platformlar her chunk'ta tam event yapısı gönderiyor, bazıları sadece data alanını gönderiyor; bitiş işareti bazılarında [DONE], bazılarında finish_reason alanının set edilmesi; hatta bazıları arada heartbeat paketi ekliyor, ön uç bunu içerik sanıp yanlış yorumlayabiliyor.
Başta OpenAI formatına göre bir ayrıştırıcı yazdım, ikinci platforma bağlanınca çöp veri geldi. Çözüm, birleşik bir SSE ayrıştırma ara katmanı yazmak oldu: her platformun chunk'ını aynı olay yapısına normalize ediyor, ön uç yalnızca bunu tanıyor. Yaşadığım tuzak şuydu: dokümanda yazan "tam uyumlu" ifadesine güvenmeyin, mutlaka gerçek dönen veriyi paket yakalayarak inceleyin; doküman ile uygulama sıklıkla birbirini tutmuyor.
İstisna Yönetimi: Biri zaman aşımına uğrarsa otomatik nasıl değiştirilir
Karşılaştırma testleri çalışmaya başladıktan sonra en can sıkıcısı tek bir platformun zaman aşımına uğramasıydı. Bir stres testi sırasında Qwen-Max tarafındaki yanıt aniden yavaşladı, tüm müşteri hizmetleri zinciri kilitlendi, ön uç sürekli dönüp durdu. Prototip aşamasında düşürme (fallback) mekanizması yoktu, biri çökünce hepsi çöküyordu.
Sonradan bir model yönlendirme katmanı ekledim: her isteğe zaman aşımı eşiği koydum, zaman aşımında otomatik olarak yedek modele geçiyor ve geçiş logu tutuluyor. Burada dikkat edilmesi gereken nokta şu: geçiş körü körüne yeniden deneme olmamalı, ağ zaman aşımı mı yoksa içerik denetimi engellemesi mi olduğunu ayırt etmek gerekiyor; ilkinde geçilebilir, ikincisinde geçmek boşuna. Büyük model yönlendirmenin değeri tam burada: kullanılabilirliği tek noktadan çok noktaya taşımak. Projemizde SiliconFlow'un zamanlamasıyla benzer bir doğrulama yaptık, görev tipine göre otomatik model seçimi ve zaman aşımı düşürme zinciri oldukça stabil çalıştı.
Maliyet İzleme: Token tüketimi nasıl toplanır
Bir haftanın sonunda en beklenmedik gider Token oldu. Dört model paralel test çalıştırıyordu, günlük çağrı hacmi büyük değildi ama toplama yapılmadığı için ay sonu mutabakatında bir platformun tüketiminin tahminin üç katı olduğu görüldü. Nedeni şu: akış çıktısı altında birçok platformun döndürdüğü usage alanı boş geliyor, karakter bazında tahmin etmek gerekiyor ve bu tahmin tutmuyor.
Benim yöntemim, ağ geçidi katmanında birleşik muhasebe tutmak oldu: her çağrıda model adı, giriş/çıkış Token'ı, süre, düşürme yapılıp yapılmadığı kaydediliyor ve tek bir tabloya yazılıyor. Kullanım bazlı fiyatlandırma modelinde bu hesabı kendiniz net yapmalısınız, tamamen platformun arka ucuna güvenemezsiniz. API fiyat karşılaştırmasında da dikkat edilmeli: etiket fiyatı düşük bir modelin çıkış Token'ı fiyatlandırma kuralı karmaşıksa gerçek maliyet daha yüksek çıkabilir.
Tek cümleyle özet: çoklu model karşılaştırma prototipinin özü tek bir modeli çalıştırmak değil, entegrasyon, akış, düşürme ve muhasebe olmak üzere dört işi birleşik bir katman haline getirmektir. Model ağ geçidi seçimi hakkında daha derin bilgi için API toplama ile ilgili kaynaklara göz atabilirsiniz.
Yazar: Zhou Mingzhe
Yayın tarihi: 6 Ekim 2026