Birden fazla yapay zeka API anahtarını yönetmek neden sizi yavaşlatıyor?

Beş sağlayıcı panosu. Üç set API anahtarı. İki rotasyon takvimi. Çoklu sağlayıcıya dayalı yapay zeka çalışmalarındaki sürtünme bütçede bir kalem olarak görünmez — her şeyi sevk etmenin ne kadar sürdüğünde ve kurulum maliyeti değmez diye denemekten vazgeçtiklerinizde görünür.

Sabah 9 ritüeli

Dizüstünü aç. Kahve. E-postayı kontrol et. OpenAI panosunu aç, dünkü harcamaya bak, varsa uyarılara tıkla. Anthropic konsolunu aç, kredi bakiyesini kontrol et, geçen haftaki organizasyon yöneticisi davetinin işleme alınıp alınmadığını kontrol et. Google AI Studio’yu aç, gece boyunca çalıştırdığın ajan testinin rate-limit kullanımına bak. Yan projelerin varsa Replicate ya da Fireworks’ü de aç. Şimdi 1Password’e bak ve kimlik bilgilerinin Cuma’dan beri yenilenmediğini doğrula.

Burası, yapay zeka üzerinde çalışan çoğu geliştiricinin konuşmadığı sabahın bir kısmı. İşe başlamadan önceki iş. Kimsenin bunu tasarlamadığı için günün içine sızan, 8–15 dakikalık pano-üstü kontrol — sağlayıcı kayıtları birikerek, alışkanlık olana kadar şekillendi. Aslında yapmayı planladığın işe başlamadan önce, hesaplayamadığın ve geri alamayacağın bir verimlilik vergisini çoktan ödemiş oluyorsun.

Kimsenin tam olarak itiraf etmediği şey: Çoklu sağlayıcı üzerinde çalışan çoğu geliştirici, fark etmeden bu rutini gününe yerleştirdi. “Sadece işleri takip etmek” gibi geliyor. Oysa gerçekte her iş gününe yayılan ve üretkenlik literatürünün on yıllardır gönderim hızını öldürdüğünü belirttiği türden bir bağlam değiştirme maliyeti.

Yavaşlama soyut değil. Üç somut şekilde ortaya çıkıyor: basit değişikliklerin ne kadar süre aldığı, taahhüt etmeden önce kaç modeli gerçekten değerlendirdiğin ve kurulum maliyeti uğruna denemeye değmez gördüğün için vazgeçtiklerin. Bunların hiçbiri bütçede bir kalem olarak görünmüyor. Hepsi gerçek ve çok sağlayıcılı yığınlar işleten çoğu ekip, bu maliyetleri bir büyüklük mertebesiyle eksik tahmin ediyor.

Verimlilik vergisi gerçekte nerede saklanıyor

Bir geliştiriciye “çoklu sağlayıcılı yapay zeka yığınında API anahtarlarını yönetmek seni yavaşlatıyor mu?” diye sorarsan, dürüst cevap genellikle “pek değil” olur. Her bir sürtünme küçük — burada 30 saniyelik bir oturum açma, orada 90 saniyelik bir bağlam değişimi, haftada bir kez beş dakikalık kimlik bilgisi araması. Bunların hiçbiri haftanı yiyen şey gibi hissettirmez. Işıkları açık tutmak gibi gelir.

İşte bu yüzden maliyeti görmek zordur. Yeterince küçük parçalara bölünerek ödenir, yeterince çok temas noktasına dağıldığı için hiçbiri göze batmaz ve o kadar sık yinelenir ki sürtünmeyi fark etmeyi bırakırsın. Verimlilik araştırmaları buna “dikkat tortusu” der — bir bağlamdan diğerine geçtiğinde odağının önceki bağlama yapışık kalan parçası. Maliyet panolar değil. Biriken dikkat tortusu.

Günlük dört sürtünme noktası

Maliyetin biriktiği dört belirli temas noktası var. Her biri küçük. Dördü birden, çalışma gününün anlamlı bir dilimi.

• Yeni projeye başlarken kimlik bilgisi arama. Yeni bir müşteri projesi ya da yeni bir özellik dalı açarsın. İlk ihtiyacın, bu çalışmanın çağıracağı sağlayıcıya ait doğru API anahtarıdır. Bu, gizli yönetici aracını açmak, doğru girdiyi bulmak, doğru anahtarı doğru yapılandırma dosyasına kopyalamak ve doğru ortamı (dev / staging / prod) kullandığını iki kez kontrol etmek demektir. Çoklu sağlayıcı yığınında, proje başına sağlayıcı başına bir kez olmak üzere bu işlem birden fazla kez gerçekleşir. Sürtünme olay başına küçüktür ve bir yılın projeleri boyunca birikir.
• Hata ayıklarken pano gezintisi. Bir istek başarısız olur. Oran sınırı mıydı? Bir model kullanım dışı mı kaldı? Kimlik doğrulama sorunu mu? İçerik politikası reddi mi? Bunu bulmak, ilgili sağlayıcının panosuna gitmeyi, istek günlüğünü bulmayı ve hatayı sağlayıcının kendine özgü formatında okumayı gerektirir. Her sağlayıcı bunu farklı düzenler. OpenAI’nin günlükleri Anthropic’inkilerden, onlar da Google’ınkilerden farklı yüzeye çıkar. Bir gün içinde üçüncü kez farklı bir pano düzenine geçtiğinde bağlam değiştirme maliyetini fark edersin.
• Sağlayıcılar arasında rate-limit yorumlama. Her sağlayıcı oran sınırlarını farklı birimlerle ifade eder. OpenAI tokens-per-minute ve requests-per-minute kullanır. Anthropic, ayrı eşikler olarak input tokens per minute ve output tokens per minute kullanır. Google, requests-per-minute ve tokens-per-day kullanır. Bir sınıra takıldığında, hata ayıklama yolun baktığın sağlayıcıya bağlıdır — uygulaman gereken zihinsel model sağlayıcıya özeldir. Bu, olay müdahalesinde en çok acıtan sürtünme noktasıdır; yavaş davranmaya tahammülün yoktur.
• API referanslarını okurken dokümantasyon değiştirme. İki sağlayıcıda araç kullanımını uyguluyorsun. OpenAI dokümanları araç kullanımını belirli bir şemaya sahip fonksiyonlar olarak yapılandırır. Anthropic dokümanları bunu kendi şemalarıyla tool_use blokları olarak yapılandırır. İkisini de okumak, sekmeler arasında geçiş yapmak, kavramları iki format arasında zihninde çevirmek — odağı parçalayan bilişsel yük tam olarak budur. Yarım saatlik doküman-sekme gezintisi on dakika gibi gelir; gerçek zaman kaybı 45 dakikaya daha yakındır.

Bunların hiçbiri tek başına felaket değildir. Felaket olan, planladığın işin üzerine her gün, günde birkaç kez gerçekleşmeleridir. Sevk hızındaki maliyet, bu küçük kesintilerin toplamıdır; yılda bu işi yaptığın çalışma günlerinin sayısıyla çarpılır.

Her kurulumda bir saatin işinin gerçekte nasıl göründüğü

Bunu görmenin en net yolu, aynı bir saatlik işi iki farklı kurulumda karşılaştırmaktır: üç sağlayıcı entegrasyonunun ayrı ayrı yönetildiği bir kurulum ve tek kimlik bilgisi arkasında OpenAI ile uyumlu tek bir uç nokta. Görev aynı, geliştirici aynı, sonuç aynı — oraya ulaşmak için harcanan emek farklı.

Görev: birincil üretim için Claude Sonnet 4.6 kullanan, Claude rate-limit’e takılırsa GPT-5.5’e geri dönen ve yanıtta yapılandırılmış çıkarım için Gemini 3.1 Pro kullanan yeni bir özellik uygulamak. Sağlayıcılar arası iş akışı — 2026’da rutinleşen türden.

Manşet bulgu 40 dakikalık fark değil. Manşet, çoklu sağlayıcılı kurulumun seni bir saatte üç kez bağlam değiştirmeye zorlaması — ve bu bağlam değiştirme maliyetinin hiçbir zaman çizelgede görünmemesine rağmen Cuma’ya kadar sevk ettiklerinin sayısında gerçek olması. Tek uç noktalı kurulum seni tek bir zihinsel modelde tutar: tek SDK, tek hata yüzeyi, tek dizi konvansiyon. Tasarruf edilen 40 dakikanın bir kısmı kelimenin tam anlamıyla zamandır. Kalanı, aynı anda üç sağlayıcının tuhaflıklarını akılda tutmak zorunda kalmadığında birikmeyen dikkat tortusudur.

Ortaya çıkan desen: Çoklu sağlayıcılı bir yığında, basit çapraz model özellikler, birleşik uç nokta kurulumuna göre ~3–4 kat daha uzun sürer. Oran, basit ve karmaşık görevlerin tamamında geçerlidir. Sebep ham zorluk değil — her adımda üç sağlayıcının konvansiyonları arasında gidip gelmenin bilişsel yüküdür.

Günlük ritüel kısaldığında ne değişir

Maliyet artışlarla gelir. Maliyeti kaldırdığında fayda da artışlarla gelir — ama bu kez artışlar ters yönde bileşiklenir. Günde 30 dakikasını parçalı bağlam değiştirmeye geri alan bir geliştirici, haftada yaklaşık iki buçuk çalışma saatini geri kazanır. Bir yılda bu, yaklaşık üç tam çalışma haftası verimlilik demektir. Ancak geri kazanılan zaman tek fayda değildir ve muhtemelen en önemlisi de değildir. Pratikte üç ikincil etki daha fazla önem taşır.

Deney daha çok yaparsın, çünkü denemek ucuzlar

Çoklu sağlayıcı kurulumunda, yeni bir modeli denemek entegrasyon seremonisine girmek demektir: hesabın yoksa sağlayıcıya kaydol, kimlik bilgisini ekle, yeni ise SDK’yı kur, sarmalayıcıyı yaz, dağıtıma al. Çoğu geliştirici için “bu yeni modeli denemeye değer mi?” eşiği yarım gün çabasındadır. Bu eşiği aşmayanlar denenmez.

Tek uç noktalı kurulumda, yeni bir modeli denemek bir yapılandırma değişikliğidir. Kodda model parametresini değiştir, dağıtıma al, değerlendirme paketini çalıştır, karşılaştır. Eşik yarım günden on dakikaya düşer. Agregatör uç noktalar üzerinde çalışan ekipler, aynı iş yükü için doğrudan çoklu sağlayıcı entegrasyonlarıyla çalışan ekiplere kıyasla 3–5 kat daha fazla model seçeneğini test eder — ve sonunda seçtikleri daha uygun modeller bu daha geniş keşfi yansıtır. Deney daha çok yaparsın, çünkü denemek ucuzlamıştır.

Yeni bir model çıktığında daha hızlı hareket edersin

2026’da bu, bir yıl öncesine göre daha da önemlidir. Yeni sınır modelleri her birkaç haftada bir yayınlanır. Bazen, zaten önceki en iyi seçenekle sevk ettiğin bir iş yükünde fiyat-kalite sınırını anlamlı şekilde değiştirirler. Doğrudan çoklu sağlayıcı kurulumunda, yeni modeli değerlendirmek yeni sağlayıcıyı kurmak (ya da mevcut sağlayıcı entegrasyonuna yeni modeli eklemek ya da SDK değişiklikleri boyunca yeni modeli geçirmek) demektir. Adil bir karşılaştırmayı elde edene kadar iki hafta geçer ve erken hareket edenin avantajı kaybolur.

Tek uç noktalı kurulumda, yeni model genellikle kamuya açık yayından sonraki saatler içinde agregatörün kataloğunda görünür. Test etmek, bir model parametresi değişikliğidir. Karşılaştırma gün bitmeden vardır. Bu yıl boyunca bileşiklenir — agregatör uç noktalarda çalışan ekipler, daha iyi bir uyum ortaya çıktığında geçişin maliyeti belirleyici olmadığından, iş yükleri için doğru modeli daha sık işletir.

Zamanın üzerinde yeniden tasarruf sahibi olursun

Çoklu sağlayıcı rutininin ifade edilmesi en zor maliyeti, ortadan kalktığında geliştiricilerin en güçlü hissettiği şeydir. Her gün 8–15 dakikalık pano kontrolü, kimlik bilgisi araması ve sağlayıcılar arası bağlam değişimi yalnızca zaman değildir — aslında yapmak istediğin işle hiç ilgisi olmayan bakım işidir. Bu zaman ortadan kalktığında, sabah farklı başlar. Dizüstünü açarsın ve yaptığın ilk şey inşa etmektir. Günü nasıl başlattığın üzerindeki yeniden kazanılmış tasarruf, tasarruf edilen dakikaların kendisinden daha önemlidir ve değişimi yapan geliştiricilerin tutarlı şekilde en çok önemsediklerini söyledikleri şey budur.

İlk gün alışkanlık değişimi

Şu anda çoklu sağlayıcı kurulumunda çalışıyorsan ve yukarıdaki maliyetler tanıdık geliyorsa, geçiş çoğunlukla hangi iş yüklerini önce taşıyacağına kalır. Değişimin gerçekte nasıl geliştiğine dair bazı pratik çerçeveler:

1. Taşınacak ilk iş yükü, mevcut olan değil, yeni bir özelliktir. Henüz inşa etmeye başlamadığın bir özellik seç, tek uç noktalı kuruluma yönlendir ve bu iş akışıyla sevk et. Geçiş maliyeti olmayan bir şeyde yeni deseni öğrenmiş olursun — yeniden inşa edilecek mevcut entegrasyon yok, riske atılacak üretim trafiği yok. Özellik sevk edildiğinde, iş akışı değişiminin sana uyup uymadığını bilirsin.
2. İkinci hamle, prototipleme ortamındır. İş yüküne karşı yeni modelleri test etmek için kullandığın şey — değerlendirme düzeneği, istem yineleme defterin, A/B karşılaştırma betiğin — bunu sonraki adımda tek uç noktalı kuruluma taşı. Deney faydasının ilk ortaya çıktığı yer burasıdır ve eşikteki düşüşün “entegrasyona yarım gün”den “yapılandırma değişimi”ne indiği yer de burasıdır. İlk hafta içinde daha fazla model denemeye başlayacaksın.
3. Mevcut üretim iş yükleri en son taşınır ve hepsinin taşınması gerekmez. Doğrudan sağlayıcı erişimiyle çalışan mevcut tek model üretim iş yükün varsa — stabil, yüksek hacimli ve müzakere edilmiş kurumsal fiyatlandırmadan faydalanıyorsa — bu iş yükünün olduğu yerde kalması daha iyi olabilir. Agregatör deseni, uyduğu iş yükleri için bir araçtır; diğerleri oldukları yerde kalabilir. Karma kurulumlar çalıştıran çoğu takım, agregatörün çoklu model ve deney işlerini üstlendiğini, tek model üretim yollarında ise doğrudan sağlayıcı erişimini kullandıklarını görür.
4. Pano alışkanlığı kırılması yaklaşık iki hafta sürer. Yeni kurulumun ilk bir iki haftasında OpenAI’nin panosunu hâlâ açacaksın — alışkanlık, ihtiyaç değil. Üçüncü haftaya gelindiğinde kas hafızası değişmiş olur ve sabah rutini, çapraz pano kontrolü yerine işle başlar. Geri kazanılan zaman ilk günden tam olmaz; yeni alışkanlık yerleştikçe birikir.

Bu seni nereye bırakır

Çoklu sağlayıcılı yapay zeka, her sağlayıcının kötü olduğu için bir problem değil. Her sağlayıcı iyi. Problem, üçünü dördünü aynı anda çalıştırdığında ortaya çıkar — bağlam değiştirme maliyeti, kimlik bilgisi yüzeyi, dokümantasyon çapraz referanslaması, pano parçalanması. Bunların hiçbiri tek başına felaket değildir. Felaket olan, planladığın işin üzerine her gün, günde birkaç kez gerçekleşmeleridir.

Pratik bir sonraki adım: Kendini bir hafta zamanla. Her sağlayıcı panosunu açtığında, sağlayıcı dokümanları arasında geçiş yaptığında ya da bir kimlik bilgisi aradığında not al. Haftanın sonunda dakikaları topla. Çoklu sağlayıcı yığınları işleten geliştiricilerin çoğu toplamın onları şaşırttığını görür — tek uç noktalı kurulumla kıyaslama kendini anlatır. Eşlik eden yazı, 500 Model, Tek Uç Nokta: Bu, Yığınınız İçin Gerçekte Ne Anlama Geliyor, aynı kararın mimari tarafını ele alır; bu yazı, bununla yaşamayı nasıl hissettirdiğine dairdir.

Çoklu sağlayıcılı yapay zekanın maliyeti, API harcamasında değil, parçalanmış dikkatte ödenir. İyileşme geldiğinde, üç yerde görünür: sabahında geri kazanılan zaman, daha önce atlayacağın ama denediğin modeller ve güne nasıl başladığın üzerinde yeniden kazanılan tasarruf. Bunların hiçbiri bütçede görünmez. Üçü de gerçektir ve değişimi yapan geliştiriciler, bunları tutarlı şekilde kelimenin tam anlamıyla tasarruf edilen saatlerin üstünde sıralar.