LLM Gateway, Router ve Inference Provider: Mimari Sınır

Bir LLM gateway (ağ geçidi), router (yönlendirici) ve inference provider (çıkarım sağlayıcı), model sunum yığınındaki üç farklı katmandır ve bunları birbirine karıştırmak, ekiplerin AI ürünleri tasarlarken yaptığı en yaygın hatadır. Gateway, uygulamanıza en yakın konumda bulunur ve kimlik doğrulama, normalleştirme ve gözlemlenebilirlik işlemlerini yönetir; router, belirli bir isteği hangi modelin veya sağlayıcının karşılayacağına karar verir; inference provider ise ağırlıkları fiilen çalıştıran ve token'ları döndüren varlıktır.

Bu sınırın yanlış belirlenmesi, kırılgan entegrasyonlara yol açar: ekipler tek bir sağlayıcının SDK'sını kodlarına sabitler, ancak aylar sonra bir yedek model eklemenin veya Claude Sonnet 5, GPT-5.5 ve DeepSeek V4 Flash arasında maliyet karşılaştırması yapmanın, istek yönetimi kodlarının büyük bölümlerini yeniden yazmak anlamına geldiğini fark ederler. Bu makale, üç katmanı birbirinden ayırıyor, sorumlulukların nerede olduğunu gösteriyor ve her kategorideki satıcıları değerlendirmek için bir karar çerçevesi sunuyor.

Önemli Çıkarımlar

• Bir inference provider, model ağırlıklarını çalıştırır ve bir API sunar (OpenAI, Anthropic, Google, DeepSeek veya vLLM gibi kendi kendine barındırılan bir motor); bir router, istek başına sağlayıcılar veya modeller arasında seçim yapar; bir gateway ise her ikisi genelinde kimlik doğrulama, biçimlendirme, günlük kaydı ve hata durumunda yedeklemeyi (failover) birleştiren, uygulamaya dönük katmandır.
• Yönlendirme mantığı (maliyet tabanlı, gecikme tabanlı veya yetenek tabanlı seçim), bağımsız bir servis olarak veya bir gateway içindeki bir özellik olarak bulunabilir; gateway'in kendisiyle aynı şey değildir.
• Bir inference provider'ı kendi kendine barındırmak, API tabanlı bir sağlayıcı kullanmak ve çoklu sağlayıcı destekli bir gateway kullanmak birbirini dışlayan seçenekler değildir; üretim sistemleri genellikle model ve iş yüküne bağlı olarak üçünü de birleştirir.
• Satıcıları, hangi katmanda faaliyet gösterdiklerini sorarak değerlendirin; çünkü "router" olarak pazarlanan bir ürün sadece barındırmadığı OpenAI uyumlu uç noktalar arasında yönlendirme yapabilirken, bir "gateway" henüz ihtiyacınız olmayan yönetişim özellikleriyle birlikte yönlendirme paketliyor olabilir.

Bir Inference Provider Gerçekte Ne Yapar?

Inference provider, model ağırlıklarına, GPU'lara (veya eşdeğer hızlandırıcılara) ve düşük seviyeli sunum motoruna sahip olan katmandır. Buna Anthropic (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5), OpenAI (GPT-5.5), Google (Gemini 3.5 Flash), Zhipu (GLM-5.2) ve DeepSeek (DeepSeek V4 Pro, DeepSeek V4 Flash) gibi ticari API sağlayıcılarının yanı sıra Qwen3.7 Plus, MiniMax M3 veya Kimi K2.7 Code gibi açık ağırlıklı modellerin kendi kendine barındırılan dağıtımları dahildir.

Kendi kendine barındırma yapıyorsanız, inference provider katmanı kendi çalıştırdığınız yazılımdır. vLLM'in sunum belgeleri, LLM iş yüklerini ölçekli bir şekilde sunmak için sürekli toplu işleme (continuous batching) ve bellek açısından verimli dikkat (attention) yönetimi etrafında oluşturulmuş, kendi kendine barındırılan bir model dağıtımının doğrudan altında yer alan bir çıkarım motorunu tanımlar. vLLM (veya benzeri bir motor) çalıştırmak, maliyet ve veri yerelliği üzerinde kontrol karşılığında GPU kapasite planlaması, ölçeklendirme ve çalışma süresinden sorumlu olan o model için inference provider olmanızı sağlar.

Ticari bir API kullanıyorsanız, sağlayıcının altyapısı ve hız sınırları sizin kısıtlamanız haline gelir. Her sağlayıcının kendi kimlik doğrulama şeması, istek ve yanıt şeması, hata kodları ve hız sınırı davranışı vardır. Bu, model kalitesinin, bağlam penceresinin ve ham gecikmenin fiilen belirlendiği katmandır. Hiçbir router veya gateway, bir inference provider'ın yeteneklerini değiştiremez; sadece ona nasıl ulaşacağınızı değiştirirler.

Bir Router Ne Yapar?

Router, gelen bir istek için bir hedef, model veya sağlayıcı seçen karar mantığıdır. Yönlendirme birkaç eksende gerçekleşebilir: maliyet (basit sorguları DeepSeek V4 Flash veya Gemini 3.5 Flash gibi ucuz bir modele gönderin, Claude Opus 4.8'i karmaşık olanlar için ayırın), gecikme (belirli bir model için o an en hızlı yanıt veren sağlayıcıyı tercih edin) veya kullanılabilirlik (birincisi bozulursa ikinci bir sağlayıcıya geçiş yapın).

OpenRouter'ın model yönlendirme hakkındaki herkese açık açıklaması, bu modeli model düzeyinde tanımlar: açık ağırlıklı bir model için gelen istekler, aynı ağırlıkları barındıran birden fazla sağlayıcı arasında yönlendirilebilir, böylece tek bir mantıksal model çağrısı birkaç arka uçtan herhangi biri tarafından karşılanabilir. OpenRouter'ın sağlayıcı seçimi belgeleri, sıralama tercihlerini ifade etmek ve belirli sağlayıcıları değerlendirme dışı bırakmak için parametreleri daha ayrıntılı açıklar; bu, bir çağırıcının yönlendirme niyetini tamamen platforma bırakmak yerine açıkça ifade etme mekanizmasıdır.

Önemli mimari nokta, yönlendirmenin bir ürün kategorisi değil, bir politika olduğudur. Temel yönlendirmeyi uygulama kodunuzda kendiniz uygulayabilir (görev türüne göre basit bir if/else veya hata durumunda yeniden deneme döngüsü), özel bir yönlendirme katmanı olarak satın alabilir veya daha geniş bir gateway içinde paketlenmiş olarak alabilirsiniz. Yönlendirme yeteneğini, hangi sinyalleri (fiyat, gecikme, hata oranı, model yeteneği) kullandığını ve bu sinyallerin yapılandırılabilir mi yoksa sabit mi olduğunu sorarak değerlendirin.

Bir Gateway Ne Yapar?

Gateway, uygulama kodunuzun fiilen konuştuğu katmandır. Görevi, isteği nihayetinde hangi inference provider'ın karşıladığına bakılmaksızın tutarlı bir arayüz sunmaktır. Bir gateway genellikle şunları içerir:

• Sağlayıcılar arasında birleşik bir istek ve yanıt şeması; böylece GPT-5.5'ten Claude Sonnet 5'e geçmek, ayrıştırma (parsing) mantığınızı yeniden yazmayı gerektirmez.
• Kimlik doğrulama ve anahtar yönetimi; böylece sağlayıcı kimlik bilgileri uygulama koduna dağılmaz.
• Kullanılan her model ve sağlayıcı genelinde günlük kaydı, kullanım takibi ve maliyet ilişkilendirme.
• Bir sağlayıcı yavaş olduğunda, hız sınırına takıldığında veya hata döndürdüğünde hata durumunda yedekleme ve yeniden deneme davranışı.
• İsteğe bağlı olarak, tüm ürün yerine birkaç özellikten biri olarak yönlendirme mantığı.

TokenLab'in model araştırma sayfası, sınır modelleri (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5, GPT-5.5, GLM-5.2, Gemini 3.5 Flash), kodlama odaklı modeller (Claude Sonnet 5, Kimi K2.7 Code, DeepSeek V4 Pro, DeepSeek V4 Flash) ve düşük maliyetli yönlendirme adayları (DeepSeek V4 Flash, GLM-5.2, Laguna XS 2.1, Hy3, Qwen3.7 Plus, MiniMax M3) dahil olmak üzere sağlayıcılar genelindeki mevcut modelleri kataloglar; bu, bir gateway kullanıcısının neye yönlendirme yapacağına karar verirken ihtiyaç duyduğu referans türüdür. Birleştirme probleminin kendisi hakkında daha kapsamlı bir inceleme için TokenLab'in 2026'da neden birleşik bir AI API gateway'i önemlidir hakkındaki yazısına bakın.

Mimari Sınır, Somut Olarak

Sınırı görmenin en kolay yolu, tek bir isteği her üç katmanda da izlemektir.

1. Uygulamanız, bir görev türü veya model tercihi belirterek gateway uç noktasına bir sohbet tamamlama isteği gönderir.
2. Gateway isteğin kimliğini doğrular, onu her aday sağlayıcının beklediği şemaya normalleştirir ve yönlendirme mantığına devreder.
3. Router, yapılandırılmış politikasını (maliyet tavanı, gecikme hedefi veya açık sağlayıcı sırası) değerlendirir ve bir hedef seçer; örneğin Anthropic'in API'si aracılığıyla Claude Sonnet 5 veya vLLM aracılığıyla sunulan kendi kendine barındırılan bir DeepSeek V4 Pro örneği.
4. Inference provider modeli çalıştırır ve token'ları döndürür.
5. Gateway, yanıtı tutarlı bir şekle geri normalleştirir ve gözlemlenebilirlik katmanınız için sonucu (gecikme, maliyet, kullanılan sağlayıcı, başarı veya başarısızlık) günlüğe kaydeder.

Her katman bağımsız olarak başarısız olabilir. Bir sağlayıcı kesintisi bir çıkarım katmanı sorunudur; kötü bir yönlendirme kararı (küçük bir bağlam penceresine sahip bir modele uzun bağlamlı istekler göndermek) bir router katmanı sorunudur; ayrıştırıcınızı bozan tutarsız bir yanıt şeması bir gateway katmanı sorunudur. Hangi katmanın belirli bir hatayı ürettiğini anlamak, hata ayıklamayı yönetilebilir kılar. TokenLab'in AI API'leri için güvenilirlik altyapısı hakkındaki parçası, bu katmanlar genelinde hata izolasyonunu daha derinlemesine ele almaktadır.

Karar Kontrol Listesi

Bir gateway'e, router'a, doğrudan sağlayıcı entegrasyonuna veya bunların bir kombinasyonuna ihtiyacınız olup olmadığını değerlendirirken bu kontrol listesini kullanın.

Soru	Evet ise	Hayır ise
Bugün birden fazla model veya sağlayıcı çağırıyor musunuz veya 12 ay içinde bekliyor musunuz?	Sağlayıcı başına doğrudan SDK çağrıları yerine bir gateway veya router katmanına ihtiyacınız var.	Doğrudan sağlayıcı SDK entegrasyonu kısa vadede yeterli olabilir.
Bir sağlayıcı bozulduğunda veya hız sınırına takıldığında otomatik yedeklemeye ihtiyacınız var mı?	Sağlık kontrolleri ve yedekleme sıralaması olan router düzeyinde mantığa ihtiyacınız var.	Uygulama kodundaki manuel yeniden denemeler başlangıçta kabul edilebilir olabilir.
Sağlayıcılar genelinde model başına maliyet ve kullanım görünürlüğüne tek bir yerden ihtiyacınız var mı?	Gateway düzeyinde günlük kaydına ve ilişkilendirmeye ihtiyacınız var.	Sağlayıcıya özgü paneller şimdilik ihtiyaçlarınızı karşılayabilir.
Herhangi bir açık ağırlıklı modeli (GLM-5.2, DeepSeek V4 Pro, Qwen3.7 Plus, Kimi K2.7 Code) kendi kendine mi barındırıyorsunuz?	Aynı zamanda bir inference provider katmanı işletiyorsunuz ve vLLM gibi sunum altyapısına ihtiyacınız var.	Tamamen ticari API sağlayıcılarına güvenebilirsiniz.
Görev türüne göre yönlendirme yapmanız gerekiyor mu (sınıflandırma için ucuz model, akıl yürütme için sınır modeli)?	Sadece yedekleme değil, açık router politikasına ihtiyacınız var.	Tek bir varsayılan model yeterli olabilir.

İstek Şekli Örneği

Aşağıdaki örnek, hem birincil model tercihini hem de yedek listesini ifade eden, OpenRouter'ın sağlayıcı seçimi belgelerinin yönlendirme tercihlerini ifade etme şekliyle tutarlı bir model olan gateway tarzı bir isteğin genel şeklini göstermektedir. Alan adlarını açıklayıcı olarak kabul edin; gönderim yapmadan önce seçtiğiniz gateway'in mevcut API referansına göre tam parametreleri doğrulayın.

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer <api_key>

{
  "model": "claude-sonnet-5",
  "fallback_models": ["gpt-5.5", "deepseek-v4-flash"],
  "routing_policy": {
    "strategy": "cost_then_latency",
    "max_cost_per_1k_tokens": 0.01
  },
  "messages": [
    {"role": "user", "content": "Summarize the attached incident report."}
  ]
}

Bu şekilde, gateway istek normalleştirme ve yanıt sözleşmesine sahiptir, router routing_policy ve fallback_models yorumlamasına sahiptir ve nihayetinde seçilen sağlayıcı fiilen tamamlama işlemini oluşturmaya sahiptir. Üretimde herhangi bir belirli alan adına güvenmeden önce tam istek ve yanıt şemasını güncel belgelere göre onaylayın.

Sınırlamalar

OpenRouter ve vLLM'den gelen herkese açık belgeler, evrensel garantileri değil, genel yönlendirme ve sunum mekanizmalarını tanımlar. Tam gecikme, fiyatlandırma ve yedekleme davranışı sağlayıcıya göre değişir ve zamanla değişir, bu nedenle mevcut sayıları bu makale yerine doğrudan sağlayıcı belgelerine göre doğrulayın. vLLM ile kendi kendine barındırma, operasyonel sorumluluğu (kapasite planlaması, ölçeklendirme, yamalama) ekibinize kaydırır; altyapı işini ortadan kaldırmaz, yerini değiştirir. Hiçbir yönlendirme politikası, uzun bağlamlı akıl yürütme gerektiren bir görevi buna uygun olmayan bir modele göndermek gibi temelden yanlış bir model seçimini telafi edemez; router yapılandırması, model yeteneğini iş yükünüze göre değerlendirmenin yerini tutmaz, bu yüzden TokenLab'in model araştırması gibi güncel bir model referansını korumak önemlidir.

SSS

Gateway, router ile aynı şey midir? Hayır. Router, bir model veya sağlayıcı seçmek için karar mantığıdır; gateway, kimlik doğrulama, normalleştirme ve günlük kaydı ile birlikte yönlendirmeyi olası bir özellik olarak içeren daha geniş uygulamaya dönük katmandır.

Kendi inference provider'ım olup yine de bir gateway kullanabilir miyim? Evet. vLLM gibi bir motor aracılığıyla sunulan kendi kendine barındırılan modeller, gateway özel veya OpenAI uyumlu uç noktaları desteklediği sürece ticari API sağlayıcılarıyla aynı gateway'in arkasında durabilir.

İlk günden itibaren üç katmana da ihtiyacım var mı? Mutlaka değil. Tek sağlayıcılı doğrudan entegrasyon, erken bir prototip için makuldür. Yedekleme, çoklu model maliyet kontrolü veya sağlayıcı karşılaştırmasına ihtiyaç duyduğunuz anda, yönlendirmeli bir gateway'i tanıtmak mühendislik maliyetine değer hale gelir.

Hangi katmanı önce benimseyeceğinizi değerlendiriyorsanız, TokenLab'in model araştırma sayfasındaki mevcut model seçeneklerini inceleyin ve tek bir entegrasyona önceden bağlanmak yerine yönlendirme ve sağlayıcıları kademeli olarak eklemenize olanak tanıyan bir gateway kurulumuyla Başlayın.