AI gateway nedir?

Bir AI gateway, uygulamalarınızla fiilen çağırdığınız model sağlayıcıları arasında duran bir servistir — OpenAI, Anthropic, Gemini, yerel bir Ollama sunucusu ya da chat completions tarzı bir API konuşan (ya da konuşacak şekilde uyarlanabilen) başka herhangi bir şey. Her uygulamanın kendi sağlayıcı kimlik bilgilerini tutup o sağlayıcıya özgü istek ve yanıt biçimini işlemesi yerine, uygulama tek bir gateway’e, tek bir API üzerinden konuşur ve gerisini gateway halleder.

Çözdüğü problem

Gateway’i devre dışı bırakın, “retrieval’lı olarak üç model sağlayıcısını çağır” teoride değil pratikte genelde şöyle görünür. Üç SDK ayrı ayrı entegre edilir, her birinin geliştiricinin sağlayıcı başına bir kez öğrenmesi gereken kendi istek ve yanıt biçimi vardır. Üç API anahtarı, o sağlayıcıyı çağıran servisin sırlarını nerede tutuyorsa oraya dağılır — burada bir ortam değişkeni, orada bir secrets manager kaydı — hepsini tek elde tutan bir yer yoktur, birini rotate etmek onu gömmüş her servisin deploy edilmesini gerektirir. Bir modeli başka biriyle değiştirmek, ya da tek bir özellik için daha ucuz bir modeli denemek, çağrının yapıldığı her yerde model adını değiştirip o sağlayıcının istek biçimine göre ayarlama yapmak anlamına gelir — tek bir yerde değil.

Bir retrieval adımı varsa, genelde ihtiyacı olan her çağrı noktasına eklenir ve paylaşılan bir implementasyon olmadığı için her seferinde biraz farklı inşa edilir. Ve biri “destek botunun geçen ay ne kadar harcadığını, aynı API anahtarını paylaşan iç araçtan ayrı olarak” sorduğunda, dürüst cevap genelde kimsenin bilmediğidir — sağlayıcının kendi fatura panosu toplamda ne harcandığını bilir, bir organizasyonun hangi uygulamasının harcadığını değil.

Bir gateway’in var oluş nedeni, bunların her birini entegrasyon başına tekrarlanan bir karar olmaktan çıkarıp altyapının bir özelliğine dönüştürmektir: kimlik bilgilerinin yaşadığı ve rotate edildiği tek bir yer, hangi sağlayıcı cevap verirse versin her uygulamanın karşı kodlandığı tek bir şema, bir modelin onu çağıran kodu değiştirmeden değiştirilebildiği tek bir yer, ve sonradan tahmin etmek yerine “kim ne harcadı” sorusuna cevap verecek kadar detayla her isteğin loglandığı tek bir yer.

Bir gateway tipik olarak neler ekler

Bu kalıp farklı isimlerle karşımıza çıkar — LLM gateway, model proxy, AI router — ama tekrar eden parçalar aynıdır:

• Tek bir API yüzeyi. Uygulamalar sağlayıcı başına değil, gateway’in garanti ettiği bir şemaya karşı bir kez entegre olur.
• Merkezi kimlik bilgileri. Sağlayıcı API anahtarları, bir modeli çağıran her serviste dağınık durmak yerine gateway’de yaşar.
• Yönlendirme ve çeviri. İstek tek bir şemaya göre gelir ve arkasında gerçekte yapılandırılmış olan sağlayıcıya uyarlanır — tool/function call’lar gibi düzgün eşleşmeyen parçalar dahil.
• Kontrol. Rate limit, harcama bütçesi, audit log ve erişim kontrolü her entegrasyonda yeniden yazılmak yerine tek bir yerde uygulanır.

Her gateway bu dördünü de yapmaz. Bazıları yalnızca yönlendirme yapar; bazıları caching ekler; bazıları observability ekleyip orada durur.

Bir gateway’in olmadığı şeyler

“AI gateway” terimi kapsamayacağı kadar gevşek kullanılıyor; bu yüzden terimin neyi dışarıda bıraktığını söylemek, neyi içerdiği kadar değerli.

Bir reverse proxy, ilettiği isteğin içinde ne olduğundan habersiz şekilde byte’ları bir adresten diğerine iletir. Birini bir model sağlayıcısının önüne koyun, arkasındaki her uygulama yine o sağlayıcının tam şemasını konuşmak zorundadır, yine o sağlayıcı için kendi kimlik bilgilerine ihtiyaç duyar, ve proxy’nin bir isteğin çalışmasına izin verilip verilmeyeceği konusunda hiçbir fikri yoktur — uygulama başına bütçe yok, client kodunu değiştirmeden model değiştirme yok, bunların hiçbiri paket yönlendirmekten bedava gelmez. Bir gateway ise habersizliğin tam tersini yapar: isteği özellikle çevirebilmek için parse eder ve isteğin herhangi bir yere iletilmeden önce devam edip etmeyeceğine karar verir.

Bir SDK wrapper — birkaç sağlayıcıyı tek bir fonksiyon çağrısının arkasında sunan client tarafı bir kütüphane — şema problemini altyapı tarafından değil, çağıran uygulamanın tarafından çözer. Onu import eden her uygulama yine her sağlayıcının kimlik bilgisini kendisi tutar, kendi sırlarını nerede saklıyorsa orada, ve aynı process’i paylaşmayan uygulamalar arasında bir rate limit ya da bütçeyi uygulayacak paylaşılan bir yer yoktur — her import kendi kopyasıdır, ne kadar harcandığına dair kendi görüşüyle. Bir gateway, tam olarak bir SDK wrapper’ın onu import eden her uygulamaya dağıttığı şeyi merkezileştirir.

Bir model router — birkaç aday arasından bir istek için en iyi ya da en ucuz modeli seçen şey — gerçek ama farklı bir problemi çözer: kimlik bilgilerinin nerede yaşadığı ya da bir isteğe yolda ne olduğu değil, hangi modelin cevap vereceği. Routing mantığı bir gateway’in üzerine oturabilir, ya da daha dar bir aracın tüm işi bu olabilir; hiç routing mantığı olmayan, her uygulama için tek bir sabit bağlantısı olan bir gateway bile “AI gateway” teriminin genelde işaret ettiği şema çevirme, kimlik bilgisi merkezileştirme ve bütçe uygulama işini yapıyor demektir. Örneğin Ragmux, bir project’i sağlayıcılar arası yalnızca bir operatörün adlandırılmış bir route üzerinde listelediği target’lar arasında ağırlığa ve önceliğe göre routing yapar, bir hata olduğunda sıradaki target’a fallback uygular — adaylar arasından en iyi ya da en ucuz modeli kendiliğinden seçmez; hangi adayların var olacağı operatörün açık kararıdır.

Bir isteğe fiilen ne olur

Markadan sıyırın, bir AI gateway’den geçen bir istek — hangi gateway olursa olsun — aynı birkaç aşamadan geçer:

1. Çağıranı doğrula ve neye izinli olduğunu çözümle. İstekteki anahtar, Ragmux’ta bir project olan uygulama seviyesinde bir kimliğe eşlenir — bu kimliğin kendi model connection’ı, kendi bütçeleri ve varsa bağlı olduğu document store vardır.
2. Pahalı bir şey yapmadan önce limitleri kontrol et. Rate limit ve token bütçeleri, istek daha ileri gitmeden önce bu kimliğe karşı kontrol edilir. Ragmux’un kendi dokümanları bunun retrieval çalışmadan önce olduğunu açıkça belirtir, tam olarak throttle edilmiş bir isteğin reddedilmeden önce yine de bir embedding çağrısına mal olmaması için.
3. Gateway bunu yapıyorsa isteği zenginleştir. Retrieval’ı yerleşik olarak taşıyan bir gateway bu aşamada sorguyu embed eder, bir document store’da arar ve eşleşen parçaları herhangi bir sağlayıcıya gönderilmeden önce enjekte eder.
4. Sağlayıcının kendi şemasına çevir. Alan adları, gerekli parametreler (Anthropic max_tokens gerektirirken OpenAI gerektirmez), tool/function call biçimleri ve streaming formatları sağlayıcıya göre farklılaşır; “tek şema girer, hangi sağlayıcı olursa olsun çıkar” ifadesini iddia olmaktan çıkarıp gerçek yapan adım budur.
5. İsteği ilet ve yanıtı çağıranın beklediği şemaya normalize ederek geri aktar — sağlayıcıya özgü bir streaming formatını, çağıranın SDK’sının zaten okumayı bildiği tek biçime geri çevirmek dahil.
6. Ne olduğunu kaydet. Kullanılan token’lar, gecikme, yanıtın stream edilip edilmediği, retrieval’ın çalışıp çalışmadığı ve ne bulduğu, ve — gateway maliyet tahmini yapıyorsa — o tek isteğin ne kadara mal olduğu, hepsi 1. adımda çözümlenen kimliğe atfedilir.

Bu altı adımdan hiçbiri, atlanması sessizce bir şeyi bozacağı anlamında opsiyonel değil; yalnızca 1, 4 ve 5. adımları yapan bir gateway de meşru, daha dar kapsamlı bir gateway türüdür — yukarıdaki “Bir gateway tipik olarak neler ekler” bölümüne bakın — sadece diğerlerinin yaptığı bütçe uygulama ya da retrieval işini yapmıyor demektir.

Retrieval nereye oturuyor

Gateway’lerin daha dar bir kesimi — Ragmux da bunlardan biri — retrieval-augmented generation’ı (RAG) uygulamanın önce ayrı bir sistemi çağırması gereken bir şey olarak değil, istek akışının bir parçası olarak ele alır. Bir project bir document store’a bağlanabilir; o project için bir istek geldiğinde, gateway sorguyu embed eder, store’da arar ve eşleşen parçaları sağlayıcıya gitmeden önce system prompt’una enjekte eder. Çağıran uygulama ayrı bir retrieval adımını orkestre etmez — tek bir istek gönderir ve kendisine verilen belgelere zaten dayandırılmış bir cevap alır.

Bu kolaylık bedavaya gelmiyor. Retrieval’ı gateway’e koymak, gateway’i artık belgelerin ve embedding’lerinin yaşadığı yere bağımlı kılmak demek — Ragmux için bu, diğer her şeyle aynı PostgreSQL veritabanı, yani ayakta tutulacak ikinci bir sistem yok, ama routing-only bir gateway’in hiç ihtiyaç duymayacağı işletilmesi gereken bir veritabanı var. Ayrıca embedding modelini bir store için kalıcı bir seçime dönüştürür: Ragmux, bir document store’un embedding connection’ını ilk chunk’ları oluşturulduğu anda sabitler ve o connection’ı sonradan düzenleme girişimini tamamen reddeder. Reprocessing, bir store’un mevcut belgelerini aynı connection ile yeniden embed eder — değişen bir chunk_size’ın işlenmesini sağlayan budur, embedding modeli değiştirmenin yolu değil; farklı birine geçmek yeni bir store, yeniden yüklenmiş belgeler ve eskisini kullanan her project’in yeniye yönlendirilmesi demektir. Veritabanı bağımlılığı ya da bu taahhüt olmadan routing isteyen bir ekip, daha dar, retrieval içermeyen bir gateway’e yönelmeli — bu takasın birkaç proje üzerinden nasıl göründüğü için Self-hosted AI gateway comparison sayfasına bakın.

Ragmux özelde nedir

Ragmux, yukarıdakilerin ikisini birden aynı anda olan, tek parça, self-hosted bir Go binary’sidir:

• /v1/chat/completions, /v1/models ve /v1/embeddings’i OpenAI uyumlu şemada sunar — chat endpoint’inde hem JSON hem SSE streaming — ayrıca /v1/retrieve ve /v1/rerank’i sunar, ve Anthropic ile Gemini isteklerini ve stream’lerini bu şemaya ve geri çevirir, tool call’lar dahil, böylece resmi OpenAI SDK’ları değişmeden çalışır.
• Bir project’i bir document store’a bağlayabilir: PDF, DOCX, HTML, Markdown ve düz metin parse edilir, chunk’lanır, pgvector ile embed edilip indekslenir, sonra o project her çağrıldığında vector similarity ve Postgres full-text ranking’in hibrit bir kombinasyonuyla aranır.
• İkisini de yapmak için ihtiyaç duyduğu her şey — kullanıcılar, model connection’lar, project’ler, belgeler ve vektör embedding’leri, istek logu — tek bir PostgreSQL veritabanında yaşar. Yanında çalıştırılacak ayrı bir vektör veritabanı, cache ya da queue yoktur.
• Sağlayıcı kimlik bilgileri AES-256-GCM ile durağan halde şifrelenir ve gateway’den asla çıkmaz; her project’in anahtarı, rate limit’leri, token bütçeleri ve erişimi isteğe ulaşmadan önce uygulanır, her login ve yönetim eylemi bir audit log’a kaydedilir.

Ragmux’un olmadığı şey: bir model. Kendisi eğitim yapmaz ya da inference barındırmaz — zaten hesabınız ya da yerel sunucularınız olan sağlayıcılara istekleri yönlendirir ve dayandırır, custom_openai provider type üzerinden kendi vLLM, LM Studio ya da LiteLLM kurulumunuz dahil.

Kendi gateway’inizi çalıştırmanın yanlış seçim olduğu durumlar

Bunların hiçbiri işletmesi bedava değil, ve self-hosted bir gateway her kurulum için doğru cevap değildir. Muhtemelen yanlış seçimdir, eğer:

• Tam olarak bir uygulama tam olarak bir sağlayıcıyı çağırıyorsa. Tek bir servis ve tek bir modelle, bir gateway aslında hiç dağılmamış kimlik bilgilerini merkezileştirir ve çağıran koddan asla değişmeyecek bir şemayı çevirir — sağlayıcının kendi SDK’sı bu işi zaten yapıyordur, çalıştırılacak ekstra bir şey olmadan.
• Onu ayakta tutmayı gerçekten kimse üstlenmiyorsa. Bir gateway, kendi uptime’ı olan bir servistir; Ragmux özelde, yedeklenen bir PostgreSQL veritabanı ve güvende tutulan bir SECRET_KEY ister — mevcut bir uygulamaya bırakılan bir config dosyasından çok daha gerçek bir operasyonel yüzey. Bir yan projeyi tek başına gönderen bir ekip, bu yüzeyin henüz üstlenmeye değmediğine makul şekilde karar verebilir.
• Sağlayıcı zaten bir gateway’in ekleyeceği her şeyi veriyorsa. Bazı sağlayıcılar kendi harcama kontrollerini, çoklu model erişimini ve kullanım panolarını doğrudan sunar; gateway eklemenin tüm sebebi bunlardan biriyse ve sağlayıcı bunu zaten karşılıyorsa, gateway zaten çözülmüş bir problemi çözüyor demektir.

Bunlardan herhangi biri değiştiği anda durum güçlenmeye başlar: ikinci bir uygulama, ikinci bir sağlayıcı, ya da “bu gerçekte project bazında ne kadara mal oldu” sorusuna cevap verme ihtiyacı — her biri ya kendi elle yazılmış kimlik bilgisi yönetimini ve maliyet takibini alır, ya da bir kez merkezileştirilir. İkinci seçeneğin pratikte nasıl göründüğü için Proje başına LLM maliyet takibi sayfasına bakın.