LLM ağ geçidi nasıl çalışır? Mühendislik ekipleri için pratik bir rehber

LLM ağ geçidi, uygulamalarınız ile onun üzerinden bağlandığınız model sağlayıcıları arasında yer alır ve kimlik bilgilerini yönetmeniz ve kullanımı takip etmeniz için size tek bir merkez sunar.

Bir mühendis Eylül 2026'da Reddit'teki r/LLMDevs'e şöyle yazdı: “Şu anda ortalık b*k gibi.”

“Herkesin Claude, OpenAI, AWS Bedrock ve kullandığımız diğer tüm çıkarım sağlayıcıları için kendine ait anahtarları var.”

BigGo'nun llm-proxy-tk hakkındaki haberi, hafif bir FastAPI ağ geçidi olan bu aracın kurulumunu LLM'leri “kurumsal musluk suyuna” dönüştürmeye benzetiyor; ağ geçidi de binanın ana vanası işlevini görüyor.

Ancak tesisata bu kadar güvenmeden önce, ne kurduğunuza bir göz atalım.

LLM ağ geçidi nedir?

LLM ağ geçidi, model çağrıları için bir ters proxy'dir. Uygulamalarınız istekleri doğrudan OpenAI, Anthropic, Google veya kullandığınız diğer LLM sağlayıcılarına göndermek yerine ona gönderir. Ağ geçidi bu istekleri iletir ve bu sırada kurallarınızı uygular.

Her LLM sağlayıcısının kendi API'si vardır: Her birinin kendine özgü bir istek yapısı, kimlik doğrulama yöntemi ve hata döndürme biçimi bulunur. Ayrıca her birinin ayrı hız sınırları ve hata modları vardır. Önlerinde ortak bir katman yoksa, bir sağlayıcıyı çağıran her uygulama her şeyi kendisi yapar ve bunu her biri biraz farklı şekilde yapar.

Musluk suyu benzetmesinin bir sınırı var ama sizi şu noktaya kadar götürüyor: Sağlayıcıların tesisatı yalnızca bir kez, ağ geçidinde döşenir. Bundan sonra her uygulama kendi sayaçlı bağlantısına sahip olur; böylece kimin neyi kullandığını görebilir ve diğerlerine dokunmadan herhangi bir hattı tek başına kapatabilirsiniz.

LLM, yapay zeka, MCP ve API ağ geçitleri: Aralarındaki fark nedir?

LLM ağ geçidi nasıl çalışır?

Uygulamanızdan modele giden ve geri dönen tek bir isteği takip edelim.

1. İstek ağ geçidine ulaşır: Uygulamanız, ağ geçidinin uç noktasına çoğunlukla OpenAI uyumlu biçimde, sıradan görünümlü bir sohbet isteği gönderir. Uygulamanın bakış açısından bu, modele ulaşmak için çağırdığı adrestir.
2. Ağ geçidi kimin istekte bulunduğunu ve neye yetkisi olduğunu kontrol eder: İsteği iletmeden önce kimlik bilgilerini doğrular. Bu çoğu zaman bir ekibe veya ürüne verilmiş sanal bir anahtardır. Girdi koruma mekanizmaları eklediyseniz istemler, hassas veri içerip içermedikleri veya modelin talimatlarını geçersiz kılma girişimi barındırıp barındırmadıkları açısından da taranabilir.
3. Ağ geçidi yanıtın elinde olup olmadığını kontrol eder: Önbelleğe alma etkinse, uygun ve eşleşen bir istek, sağlayıcıya yeniden çağrı yapılmadan kayıtlı bir yanıtla karşılanabilir. Bazı ağ geçitleri, birebir aynı olanlar yerine yeterince benzer kabul edilen istekleri arayan anlamsal önbelleğe alma da sunar. Bu, SSS tarzı trafiğe uygun düşebilir.
4. Ağ geçidi isteğin nereye gideceğini seçer: İstek belirli bir modeli ya da bir takma adı belirtebilir. Ağ geçidi, yapılandırmanızda eşleşen rotayı arar. Ayrıca bir yedek rota da yapılandırabilirsiniz. A sağlayıcısı zaman aşımına uğrarsa ağ geçidi B sağlayıcısını deneyebilir.
5. Ağ geçidi çağrıyı hazırlar ve yanıtı döndürür: Ağ geçidi, isteğinizi seçilen sağlayıcının biçimine dönüştürür ve giden çağrı için kimlik doğrulamasını gerçekleştirir. Yanıt alınır alınmaz uygulamanızın gerektirdiği biçime dönüştürülür.
6. Ağ geçidi olanları kaydeder: Günlük kaydı etkinleştirildiğinde ağ geçidi; çağrıyı kimin yaptığı, hangi modelin yanıtladığı, token sayıları, gecikme süresi ve maliyet gibi ayrıntıları kaydeder. Girişte bahsettiğimiz Reddit'teki mühendisin elinde olmayan kayıt tam olarak budur.

Bir ağ geçidini üretime almadan önce bilmeniz gereken 4 şey

Yukarıdaki bölümde anlatılan her şey, ağ geçidinin kendi üzerinden yönlendirilen her isteği görmesi sayesinde mümkün. Satış argümanı da bu. Ancak bu aynı zamanda planlamanız gereken saldırı yüzeyinin ve tedarikçi bağımlılığının da bir tanımı.

Ağ geçidi artık yapay zeka yığınınızın en değerli bileşeni

Ağ geçidi erişimi merkezileştirir. Dolayısıyla pek çok kimlik bilgisini de tek bir hizmetin erişimine açar. Microsoft'un güvenlik ekibinin listesine göre bir LiteLLM dağıtımı şunları barındırabilir veya alabilir: sağlayıcı API anahtarları, kendi ana anahtarı, sanal anahtar kayıtları, veritabanı bağlantı dizeleri, yönlendirme ayarları ve kiracı politikaları.

Ekim 2026'da Check Point Research, LiteLLM'de yüksek riskli iki güvenlik açığını kamuoyuyla paylaştı:

• CVE-2026-35029, salt okunur kullanıcılar dahil kimliği doğrulanmış kullanıcıların yönetim işlevlerine erişmesine ve örneği ele geçirmesine olanak tanıyordu.
• CVE-2026-59823, kullanıcıların istekleri kendi denetimlerindeki bir sunucuya yönlendirmesine ve sağlayıcı anahtarlarını ele geçirmesine olanak tanıyordu.

Her iki açık da 1.83.9 sürümünde giderildi. Ağ geçidini kullanan bir uygulama, ağ geçidinin ayarlarını değiştirememelidir.

Koruma mekanizmalarınızın bir hata politikasına ihtiyacı var

Pillar Security'nin 4 Ekim 2026 tarihli incelemesi, LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management ve Apigee dahil başlıca ağ geçitlerindeki üçüncü taraf koruma mekanizması entegrasyonlarını belgeliyor. (Pillar koruma mekanizması sattığı için önerilerini okurken bunu aklınızda bulundurun.)

Kanca (hook), istek yolunda genellikle istem modele gitmeden önce veya yanıt geri döndükten sonra yer alan ve ağ geçidinin içeriği bir karar için harici bir tarama aracına iletebildiği noktadır. Engelleyici bir denetim, trafiğin devam etmesine izin vermeden önce bu kararı bekler. Portkey'in belgeleri bunlara before_request_hooks ve after_request_hooks adını veriyor; TrueFoundry ise dört kanca çalıştırıyor ve MCP araç çağrılarından önce ve sonra da denetimler ekliyor.

Şimdi kontrol etmeniz gereken iki şey var:

• Tarama aracının kendisi başarısız olursa ne olur? Bir isteği engellediğinizde denetlenmemiş trafiği durdurursunuz ancak uygulamanızı kesintiye uğratabilirsiniz. İsteğin geçmesine izin verirseniz uygulamanız o denetim olmadan çalışmaya devam edebilir. Hata günlüğü, denetimin yapılmadığını size sonradan gösterir; bu faydalıdır ama denetimi gerçekten çalıştırmış olmakla aynı şey değildir.
• Tarama aracını değiştirebilir misiniz? Başka bir sağlayıcı desteklenmiyorsa uygulamanızı güncellemeniz veya bağlanmak için başka bir proxy kullanmanız gerekebilir.

TrueFoundry'nin MCP kancaları, ağ geçidinin erişimini model isteklerinden araç çağrılarına kadar genişletiyor. Ancak ağ geçidi yalnızca kendisinden geçen trafiği inceleyebilir. Bir geliştiricinin makinesinde komut çalıştıran bir kodlama ajanı bu görüş alanının dışında kalabilir.

Perplexity'nin açık kaynaklı Numbat aracı tam da bu tarafta çalışıyor. Numbat, desteklenen ajanlara yerel kancalar aracılığıyla bağlanır ve kabuk komutları veya dosya yazma işlemleri gibi planlanan eylemleri çalışmadan önce inceleyebilir. Engelleme özelliği isteğe bağlıdır ve varsayılan olarak kapalıdır. Ağ geçidi, kendisi üzerinden yönlendirilen model trafiğini görür. Numbat ise ajanın yanıtla ne yaptığına dair görünürlük ekler.

Ağ geçidinin denetiminin nerede bittiğini bilmeniz gerekir

Forkast News, ağ geçidine farklı yönlerden yaklaşan üç ayrı gelişim çizgisi tanımlıyor:

• LLM odaklı ağ geçitleri: LiteLLM ve Portkey işe model çağrılarıyla, yani sağlayıcılar arasında çeviri yapmak, istekleri yönlendirmek ve token'ları takip etmekle başladı. Şimdi araç çağrıları için de denetimler ekliyorlar.
• API yönetim platformları: Kong, Google'ın Apigee'si ve Azure API Management işe kimlik doğrulama, izinler ve trafik yönetimiyle başladı; ardından modeller ve yapay zekaya özgü kurallar için destek ekledi.
• Ajanlara özgü altyapı: Örneğin agentgateway, MCP ve A2A üzerinden olanlar da dahil olmak üzere modellerle, araçlarla ve diğer ajanlarla iletişim kuran ajanlar etrafında tasarlandı.

Seçimi belirleyen soru, neyi yönlendirdiğinizdir:

• Yalnızca model çağrıları mı? LLM öncelikli bir ağ geçidi iyi bir başlangıç noktasıdır.
• Halihazırda API kurallarıyla dolu bir kurumda model çağrıları mı? Elinizdeki platformla başlayın.
• Modelleri çağıran araçları çağıran ajanlar mı? Bu bağlantıların da kapsandığından emin olun.

Ortak bir arıza noktası oluşturursunuz

Diyelim ki destek sohbet botunuz OpenAI'ı, araştırma aracınız ise Anthropic'i kullanıyor ve ikisi de aynı ağ geçidi üzerinden bağlanıyor. Ancak bu ağ geçidi çalışmayı durdurursa, OpenAI ve Anthropic normal şekilde çalışıyor olsa bile her iki araç da modellerine erişimini kaybeder.

Bu gerçekten yaşandı. Cloudflare'in 12 Haziran 2025'teki kesintisi sırasında AI Gateway'in hata oranı %97'ye ulaştı. Ağ geçidi, ayarlar için Cloudflare'in Workers KV depolama hizmetine bağlıydı ve bu hizmet arıza veriyordu.

Ağ geçidini kendiniz çalıştırıyorsanız, biri arızalanırsa devreye girebilecek ikinci bir kopyayı da çalışır durumda tutun. Ağ geçidinizi başka biri barındırıyorsa, arızalar sırasında hizmeti nasıl ayakta tuttuklarını ve kurtarma sürecinde isteklerinize ne olduğunu sorun.

LLM ağ geçitlerinde aranması gereken temel özellikler

Ağ geçidine herkesin kimlik bilgilerine erişim vereceksiniz; dolayısıyla karşılığında ne sunduğu konusunda talepkâr olmalısınız.

• Birden çok sağlayıcının önünde tek bir API: Kodunuz tek bir biçim kullanır (genellikle OpenAI uyumlu bir biçim) ve ağ geçidi çeviriyi yapar. LLM sağlayıcıları da bu konuda bir adım atıyor. Örneğin Perplexity'nin Agent API'si OpenAI'ın Responses API arayüzünü destekler; böylece ekipler mevcut OpenAI istemci kitaplıklarını yeniden kullanabilir.
• Kurallara bağlı sanal anahtarlar: Her ekip veya ürün; izin verilen modelleri, istek sınırlarını ve harcamayı belirleyen kurallara sahip kendi anahtarını alır.
• Yönlendirme ve yedekleme: Ağ geçidi, istekleri maliyeti, hızı veya belirli bir sağlayıcıyı ön planda tutabilecek ayarlarınıza göre modellere gönderir. Bir çağrı başarısız olursa başka bir seçeneği deneyebilir. Perplexity'nin Agent API'si, farklı sağlayıcılara ait modeller dahil en fazla beş modeli tercih ettiğiniz sırayla listelemenize olanak tanır.
• Önbelleğe alma: Kayıtlı bir yanıt sizi ek bir sağlayıcı çağrısından kurtarabilir. Bazı ağ geçitleri birebir aynı istekleri eşleştirir; diğerleri benzer anlamdaki istekleri de eşleştirebilir. Önbelleğe alınan yanıtların kullanıcıya veya ekibe göre ayrılıp ayrılamadığını ve kişiselleştirilmiş ya da zamana duyarlı yanıtlar için önbelleğe almayı kapatıp kapatamayacağınızı kontrol edin.
• Akış ve tutarlı hatalar: Yanıtlar oluşturuldukça gelir ve sağlayıcı hataları, uygulamanızın işleyebileceği bir biçime çevrilir. Yapay zeka koruma mekanizmaları eklediğinizde ne olduğunu kontrol edin.
• Günlük kaydı ve maliyet ataması: Ağ geçidi, çağrıyı kimin yaptığını, hangi modelin yanıtladığını, kaç token kullanıldığını, ne kadar sürdüğünü ve tahmini maliyetini kaydeder. Günlüklerin istemleri ve yanıtları içerip içermediğini ve ne kadar süre saklandığını kontrol edin.
• Koruma mekanizması kancaları: Bunlar, istek yolunda ağ geçidinin içeriği bir karar için harici bir tarama aracına gönderebildiği noktalardır. Genellikle bir model isteğinden önce veya yanıtından sonra yer alırlar. Tarama aracı başarısız olduğunda isteklerin durup durmadığını veya devam edip etmediğini ve farklı bir tarama aracı bağlayıp bağlayamayacağınızı kontrol edin.
• Kilitleyebileceğiniz bir yönetici arayüzü: Ağ geçidi, sağlayıcı kimlik bilgilerine ve herkesin kullandığı kurallara erişimi yönetir. Yönetici erişimini uygulama trafiğinden ayrı olarak kısıtlayabildiğinizi ve salt okunur kullanıcıların ayarları değiştiremediğini doğrulayın. Ana vananın bir kilide ihtiyacı var.

LLM ağ geçidinizi oluşturmak için hangi araçları kullanabilirsiniz?

Özellik listeleri piyasa genelinde birbiriyle örtüşüyor. Dahili model erişimiyle ilgili bir Reddit konusunda konuyu açan kullanıcı şunu sordu: Hangi ağ geçidi, yalnızca onunla ilgilenecek bir mühendis gerektirmez?

Bize göre doğru soru bu ve işin ne kadarını üstlenmeye istekli olduğunuza bağlı olarak dört cevabı var.

Kendiniz yazın

En basit haliyle bir ağ geçidi kısa bir iş listesini üstlenir: İstekleri kabul etmek, çağıranın anahtarını kontrol etmek, sağlayıcı kimlik bilgisini eklemek, çağrıyı iletmek ve sonucu kaydetmek. Ancak farklı sağlayıcı biçimlerini desteklemek ek iş getirir. Tüm sistemi çalışır durumda tutmak da öyle.

Halihazırda Envoy çalıştırıyorsanız, harici işleme (external processing) filtresi, istekleri ve yanıtları inceleyip değiştiren bir hizmeti bağlamanıza olanak tanır. Yine de o hizmeti sizin oluşturup çalıştırmanız gerekir.

Bir ağ geçidinin maliyetleri düşürüp düşürmediğine dair bir r/LLMDevs konusunda u/QuanTradin, her çağrıda token'ları ve önbellek isabeti işaretini kaydetmenin, birebir aynı istemler için tam ücret ödeyen iki işi bulmalarına yardımcı olduğunu söyledi.

“...bunu düzeltmek, herhangi bir yönlendirme katmanının sağlayabileceğinden daha değerliydi.”

Bu, aktarılan bir deneyim ve başlamak için iyi bir nokta. Karmaşık yönlendirme yöntemleri geliştirmeden önce neye para ödediğinizi öğrenin.

Açık kaynaklı bir ağ geçidini kendiniz barındırın

LiteLLM burada yaygın bir tercih: OpenAI uyumludur, çok çeşitli sağlayıcıları destekler ve geniş bir topluluğa sahiptir. Bifrost, istek başına düşük ek yük için geliştirilmiş bir alternatiftir. Gözlemlenebilirlik özellik listenizin başında geliyorsa Helicone'a göz atmaya değer.

LiteLLM'in de her ürün gibi bazı ekipler için sınırları var. Kendi çözümünüzü geliştirmeye alternatifler üzerine bir r/aiagents konusunda u/Own_Bar_920, LiteLLM'in yönlendirmeyi sorunsuz hallettiğini ancak ekipler arası istem sürümleme ve model değiştirirken sürekli değerlendirmeler konusunda yetersiz kaldığını, bunun da kendilerini ayrı bir araca yönelttiğini söyledi.

Bunlar temel ağ geçidi yönlendirmesinin ötesine geçiyor ve asıl mesele de bu: Ana ihtiyaç yönlendirmeyse LiteLLM onlar için işini gördü.

Bazı özellikleri kullandığınız sürüme bağlı olan hazır bir özellik listesi elde edersiniz ve ağ geçidini kendi ağınızın içinde tutarsınız. Öte yandan yama yönetimi de sizin sorumluluğunuzdadır; daha önce bahsettiğimiz Check Point açıklamaları bunu somut biçimde gösterdi. Ağ geçidinin kullanılabilirliği de sizin sorumluluğunuzdadır; bunu da tek arıza noktası bölümü ortaya koydu.

Ancak bundan sorumlu olacak birini bütçenize dahil edin. Dahili erişim için ağ geçitleri üzerine bir r/LLMDevs konusundaki endişelerden biri bakımdı. u/Informal-Writer9685, “bakımı için ayrı bir mühendis gerektirmeyen” bir şey istiyordu ve LiteLLM'in bildirilen yükseltme kararsızlığının kendi ölçeklerinde gerçek bir sorun mu, yoksa yalnızca üretim ortamına özgü bir endişe mi olduğunu sordu.

Yönetilen bir ağ geçidi kullanın

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter ve Portkey'in barındırılan ağ geçidi hizmeti sizin yerinize çalıştırır. Uyumlu bir uygulamada ilk isteği göndermek, URL'yi değiştirip bir API anahtarı eklemekten pek de fazlasını gerektirmeyebilir.

Buradaki ödünleşim, artık her istemin sağlayıcıya ulaşmadan önce üçüncü bir taraftan geçmesidir. Bu, uyumluluk belgeleriniz için bir veri işleyen daha demektir ve ağ geçidinin kendi kesintisi bir tedarikçi olayıdır; düzeltmek size düşmez.

Örneğin 17 ve 19 Şubat 2026'da, bir önbellek bağımlılığının arızalanmasının ardından OpenRouter sırasıyla 38 ve 35 dakika süren kesintiler yaşadı. Bazı müşteriler “User not found” hataları aldı ve tamamen geçerli API anahtarlarında hata ayıklamaya zaman harcadı. Arıza, ağ geçidinin altyapısındaydı.

Ancak OpenRouter'ın hakkını vermek gerekirse, şirket ayrıntılı bir olay sonrası analiz yayımladı ve bir önbellek arızasının veritabanını aşırı yüklemesini önlemek için korumalar ekledi. OpenRouter gibi yönetilen bir ağ geçidi erişimi kolaylaştırabilir ancak u/QuanTradin'in r/LLMDevs'te belirttiği gibi faturaları birleştirmek harcamayı otomatik olarak azaltmaz.

Mevcut API ağ geçidinizi genişletin

Hizmetlerinizin önünde halihazırda Kong, Apigee veya Azure API Management varsa her birinin yapay zekaya özgü yetenekleri bulunur: Kong AI Gateway, Apigee'nin yapay zeka ağ geçidi politikaları ve Azure API Management'ın yapay zeka ağ geçidi. Mevcut kimlik doğrulama, ağ kuralları ve operasyon prosedürlerinizin üzerine inşa edebilir, model denetimlerini eklentiler veya politikalar aracılığıyla ekleyebilirsiniz.

Bu, büyük bir şirkette kurumsal dirence en az takılan yol olabilir. Yapay zeka özellikleri, bağımsız ağ geçitlerindekilere göre daha yeni. Kullanmayı planladığınız eklenti veya politikaların tamamıyla token tabanlı hız sınırlamayı ve akışı test ettiğinizden emin olun.

Yani elbette ana vanayı, o her şeye kadir ağ geçidini kurun. Yine de girişteki mühendisin haklılık payı var. Bir şirketin modellere erişimi, doğru anahtarı tesadüfen çekmecesinde bulunduran kişiye bağlı olmamalı.

Ağ geçidi bu sorunu anahtarları merkezi denetim altına alarak çözer; ancak bu da çekmeceyi açık bırakmanın riskini epey artırır. Çekmecenin kime ait olduğunu bilmeniz gerekir.

LLM ağ geçidiyle ilgili sık sorulan sorular

LLM ağ geçidi ücretsiz mi?

Kategoriyi kastediyorsanız bazı LLM ağ geçitlerinin ücretsiz sürümleri var.

LLM ağ geçitleri, ücretsiz açık kaynaklı yazılımlardan ayda yaklaşık 50 dolardan başlayan ücretli planlara kadar uzanır; kurumsal dağıtımlar için ise özel fiyatlandırma sunulur. Bazıları ise bunun yerine yüzde üzerinden ücret alır; örneğin OpenRouter’ın Standard planı, kredi satın alımlarına %5,5 ekler.

En iyi LLM ağ geçidi hangisi?

Hangi işi üstlenmeye hazırsınız?

• Kendi sunucunuzda barındırmak ve yapılandırmayı kontrol etmek istiyorsanız Bifrost’a veya Helicone’a göz atın.
• Hizmeti başkasının çalıştırmasını isteyen ekipler için OpenRouter veya Vercel AI Gateway gibi yönetilen bir seçenek uygundur.
• Zaten Kong veya Azure API Management kullanıyorsanız önce bunların yapay zekâ özelliklerini inceleyin.

Kısa listenizdeki seçenekleri, bir sağlayıcı hata verdiğinde ne olduğu da dâhil olmak üzere kendi isteklerinizle test edin.

AWS’nin bir LLM ağ geçidi var mı?

Evet. Amazon Bedrock AgentCore Gateway, AWS’nin “çıkarım hedefleri” (inference targets) adını verdiği yapılar aracılığıyla model çağrılarını destekler. Bunlar, uygulamaların tek bir uç nokta üzerinden Amazon Bedrock, OpenAI ve Anthropic gibi sağlayıcılara ulaşmasını sağlar; sağlayıcı kimlik bilgilerini ve yönlendirmeyi ise ağ geçidi üstlenir.