LLM İzleme Araçları Neden Artık Yapay Zekâ Ağ Geçitleri Oluşturuyor?

2026’da LangSmith, Langfuse, Opik ve Braintrust, model sağlayıcılarının önüne birer ağ geçidi ekledi. Bunun başlıca nedeni denetim: izleme aracı bir model çağrısını yalnızca kaydedebilirken ağ geçidi bu çağrıyı engelleyebilir.

Farklı İşler Yapan İki Araç

Son iki yıldır birçok ekip, büyük dil modeli (LLM) uygulamalarını iki ayrı araçla çalıştırdı. Uygulama ile model sağlayıcıları arasına bir ağ geçidi yerleştirildi. Bu araç, sağlayıcı API anahtarlarını tutuyor, sağlayıcı API’leri arasında dönüşüm yapıyor ve başarısız çağrıları yeniden deniyordu. Açık kaynaklı bir vekil sunucu olan LiteLLM, bu iş için yaygın bir tercih hâline geldi. Uygulamanın yanında ise LangSmith veya Langfuse gibi bir izleme aracı bulunuyordu. Bu araç, mühendislerin bir aracının neler yaptığını görebilmesi için her model çağrısını, araç çağrısını ve bilgi getirme adımını kaydediyordu.

Bu ayrım mantıklıydı; çünkü ağ geçidinin hızlı olması ve tüm sağlayıcıların API’lerini desteklemesi gerekirken izleme aracının iyi bir arayüze, büyük veri yüklerini depolama olanağına ve uygulama kodunu sarmalayan bir SDK’ya ihtiyacı var. Langfuse, tüm çağrıları vekil sunucu üzerinden Langfuse’a yönlendiren bir LiteLLM Proxy entegrasyonuyla iki araçlı kurulumu hâlâ belgeliyor. İzleme aracı sağlayıcıları 2026’da ağ geçidini kendileri geliştirmeye başladı.

Altı Ayda Dört Lansman

LangChain, LangSmith LLM Ağ Geçidi‘ni Mayıs 2026’da kapalı beta olarak duyurdu ve 30 Temmuz’da herkese açık beta sürümünü kullanıma açtı. O tarihten bu yana ürünü LangSmith’in kendi bulutunu kullanma dağıtımlarının da bir parçası hâline getirdi. Braintrust, önceki yapay zekâ vekil sunucusunu kullanımdan kaldırdı ve kullanıcıları, genel kullanıma sunulana kadar önizleme aşamasında ücretsiz olacak yeni bir ağ geçidine yönlendirdi. Comet, OpenAI biçimindeki istekleri kabul eden bir beta uç noktası olarak Opik LLM Ağ Geçidi‘ni yayımladı. Langfuse, 4 Kasım’da hem Langfuse Cloud’da hem de kendi sunucularında barındırılan dağıtımlarda Yapay Zekâ Ağ Geçidi’ni herkese açık beta olarak kullanıma açtı. Ağ geçidinin lisansı MIT’tir ve Rust ile yazılmıştır.

MLflow, izleme aracı olarak değil makine öğrenimi yaşam döngüsü aracı olarak ortaya çıkmış olsa da bütçe uyarıları ve sınırları sunan bir yapay zekâ ağ geçidine daha uzun süredir sahip.

Ağ geçitleri yıllardır kullanılıyor ve birini çalıştırmanın riskleri iyi biliniyor. Yeni ağ geçitlerini, iş modeli model çağrılarını kaydetmek olan şirketler geliştiriyor; bu şirketler artık her çağrının önce kendi sistemlerinden geçmesini istiyor.

Bütçe İçin İstek Yoluna Neden İhtiyaç Var?

İzleme aracı, sağlayıcı yanıt verdikten ve tokenların ücreti ödendikten sonra model çağrısını kaydeder. Bu kayıt harcama grafiği oluşturmak için yeterlidir, ancak izleme aracı harcamayı durduramaz. Bir ekibin bütçesini uygulamak, bir modeli engellemek veya istemdeki bir gizli bilgiyi kaldırmak için isteğin sağlayıcıya ulaşmadan önce denetlenmesi gerekir. Bunu yalnızca istek yolundaki bileşen yapabilir.

LangChain bu görüşü lansman yazısında dile getiriyor. Yazıda, ekiplerin ayrı bir ağ geçidini, bir güvenlik önlemleri ürününü ve bir gözlemlenebilirlik aracını bir arada kullandığı anlatılıyor; sorunları önlemenin, istek katmanında politikaları uygulamaktan geçtiği belirtiliyor. LangChain’in ağ geçidi, bütçe sınırını aşacak bir isteği sağlayıcıya iletmek yerine HTTP 402 durum koduyla yanıtlıyor.

Her Çağrıyı Kaydeden Tek Bir Giriş Noktası

İkinci neden kapsama alanı. Bir SDK yalnızca birinin araçlarla izlenebilir hâle getirdiği kod yollarını kaydeder. Bir aracının başarısızlıkları genellikle bu yolların dışında fark edilmez. Dizüstü bilgisayarda çalışan bir betik, not defteri ya da kopyalanmış bir API anahtarı kullanan kodlama ajanı hiçbir iz bırakmaz. Sağlayıcı anahtarlarını tutan bir ağ geçidi her çağrıyı görür; çünkü sağlayıcıya ulaşmanın başka bir yolu yoktur.

Langfuse ağ geçidini bu fikir üzerine kuruyor. Ağ geçidi belgelerine göre her ağ geçidi anahtarı bir kullanıcıya veya hizmet hesabına aittir ve ekip ya da maliyet merkezi gibi üst veriler içerebilir. Sağlayıcı kimlik bilgilerini yalnızca ağ geçidi tutar; yöneticiler de her kimlik bilgisinin hangi modelleri çağırabileceğini onaylar. LangSmith, Claude Code, Codex ve Gemini CLI’ı ağ geçidi üzerinden yönlendirmeye ilişkin kurulum sayfaları yayımlıyor. Bu ajanlar, herhangi bir uygulamanın izleme kodunun dışında, geliştiricinin makinesinden model çağrıları yapıyor.

İzleme Aracının Ağ Geçidi Ne Sağlıyor?

İzleme aracı sağlayıcıları bunun tersini de savunuyor: tek başına çalışan bir ağ geçidi yeterli değil. Langfuse’un lansman yazısında, bağımsız bir ağ geçidinin yalnızca tokenları ve maliyeti sayabileceği, kendi ağ geçitlerinin ise her çağrıyı kapsamlı bir izlemenin parçası hâline getirdiği belirtiliyor. Langfuse’un ağ geçidi, W3C traceparent başlığını kabul ediyor; böylece bu ağ geçidinden geçen bir çağrı, uygulamanın daha önce başlattığı izlemeye katılıyor. Varsayılan olarak istem ve yanıt içeriğini değil, kullanımı ve maliyeti kaydediyor.

Ağ geçidini izleme aracına entegre etmenin en güçlü teknik gerekçesi bu. Bağımsız bir ağ geçidi, tamamlanmış çağrılardan oluşan düz bir liste görür. İzleme aracı ise SDK’sı sayesinde aracının araç çağrılarını ve bilgi getirme adımlarını zaten kaydeder; ayrıca her ağ geçidi çağrısını bu yapının içine yerleştirebilir.

Bunun, satıcıların kendilerinin dile getirmediği ticari bir boyutu da var. Ağ geçidini kim işletiyorsa sağlayıcı anahtarları da harcama raporu da onun elindedir; finans ve platform ekiplerinin incelediği de bu harcama raporudur. Bu durum, ağ geçidinin iz kaydı görüntüleyicisinden daha zor değiştirilmesine yol açar. LangSmith ve Langfuse bu konumu şimdiden farklı şekillerde değerlendiriyor: LangSmith, müşterilerin kendi sağlayıcı anahtarlarını kullanmadan Kimi gibi barındırılan modelleri çağırmasına imkân veren Gateway Credits satıyor. Langfuse’un SSS bölümünde ise tokenları yeniden satmadığı belirtiliyor.

Beta Aşamasındaki Ağ Geçitleri Henüz Neleri Yapamıyor?

Bu ağ geçitleri henüz yeni ve satıcılar kendi eksiklerini de belgeliyor. Langfuse’un ağ geçidi şu anda yalnızca OpenAI ve Anthropic’i destekliyor; Amazon Bedrock, Google Vertex AI ve Google AI Studio ise yol haritasında yer alıyor. Sağlayıcılar arasında yedek geçiş ve ekip, kullanıcı veya anahtar başına kesin harcama limitleri planlanmış olsa da henüz sunulmadı. Şimdilik ağ geçidi, harcama panosu ve uyarılar sağlıyor. Belgelerinde hız sınırlarından veya yanıt önbelleğe almadan söz edilmiyor.

Langfuse ağ geçidi, API biçimleri arasında dönüşüm yapmıyor; bu nedenle bir OpenAI istemcisi yalnızca OpenAI modellerini çağırabiliyor. Kendi sunucusunda barındırılan sürüm yalnızca sağlayıcıların resmî URL’lerini çağırıyor; dolayısıyla şimdilik Azure OpenAI, Bedrock veya kurum içi bir proxy kullanılamıyor. Comet, Opik ağ geçidini geliştirme ve test amacıyla tasarlanmış olarak tanımlıyor. Braintrust, ağ geçidi için henüz fiyatlandırma açıklamadı.

LangSmith’in ağ geçidi şimdiden diğerlerinden daha fazlasını yapıyor. Belgelerinde yedek geçişler, harcama limitleri, hız sınırları ve veri politikaları mevcut özellikler olarak listeleniyor. Ayrıca OpenAI Chat Completions, OpenAI Responses ve Anthropic Messages biçimlerini kabul ediyor. Yedek geçişler ve hız sınırları mayıs ayında gelecekte yapılacak işler arasında listelenmişti; beta sürecinde kullanıma sunuldular. Ürünün tamamı hâlâ beta olarak etiketleniyor.

Yük testi, farklı türde bir eksikliği ortaya koyuyor. Langfuse ağ geçidi, LiteLLM ve AcruxCore ile kendi sunucusunda barındırılan bir kıyaslama testi, Langfuse ağ geçidinin çağrı başına LiteLLM’den daha az gecikme eklediğini gösterdi. Ancak varsayılan Docker ayarlarıyla, aynı anda açılan 1.000 akışın 739’unda başarısız oldu; çünkü süreci, Docker’ın varsayılan 1.024 açık dosya sınırını koruyordu. Langfuse’un Compose dosyasına eklenen tek bir satır sorunu çözdü.

Bu beta sürümleriyle karşılaştırıldığında, yıllardır bağımsız bir ağ geçidi olarak hizmet veren LiteLLM 100’den fazla sağlayıcıyı destekliyor ve sanal anahtarlar, harcama takibi, güvenlik önlemleri, yük dengeleme ve yönetici panosu gibi özellikleri zaten içeriyor. LiteLLM ayrıca istek yolunu Python’dan Rust’a taşımaya hazırlanıyor. Rust AI Gateway beta aşamasında ve LiteLLM ekibi, Anthropic tarzı /v1/messages isteklerinin 1 Aralık’a kadar uçtan uca Rust’ta çalışmasını, gecikmenin de yaklaşık 20 kat azalmasını bekliyor. MLflow ve AcruxCore gibi bazı açık kaynaklı platformlar, ağ geçidini ve izlemeyi tek bir üründe zaten sunuyor.

Bunları Ayrı Tutmanın Gerekçeleri

Ağ geçidini izleme aracına entegre etmenin maliyetleri var; bunların en önemlisi iki bileşenin birbirine bağımlı hâle gelmesi. Ağ geçidi ayrı olduğunda ekipler, bir günlük kaydı geri çağırımını değiştirerek izleme sağlayıcısını değiştirebilir. İzleme aracı aynı zamanda ağ geçidiyse her hizmetin temel URL’si, anahtarları ve model tanımlayıcıları da değişir. Örneğin Langfuse, model tanımlayıcılarını kimlik bilgisi:model biçiminde yazar.

İzleme aracı aynı zamanda çalışma zamanı bağımlılığı hâline gelir. İzleme arka ucu devre dışı kalırsa ekip iz kayıtlarını kaybeder. Ağ geçidi devre dışı kalırsa model çağrıları başarısız olur. Ağ geçidini işleten bir izleme sağlayıcısının artık kritik altyapıdan beklenen çalışma süresi düzeyini sağlaması gerekir.

Güvenlik sağlayıcıları da istek yolunda aynı konumda olmak istiyor. Palo Alto Networks, bağımsız bir ağ geçidi olan Portkey’i Mayıs 2026’da bünyesine kattı ve Prisma AIRS platformunun yapay zekâ ağ geçidi hâline getirdi. Bir güvenlik ekibi, ağ geçidini gözlemlenebilirlik aracının içinde tutmak yerine kendi denetimi altında bulundurmayı tercih edebilir. Mart ayında yaşanan LiteLLM’nin tedarik zinciri ihlali de gösterdiği gibi, ağ geçitleri saldırganların hedefi hâline geldi.

Ekipler Nasıl Seçim Yapabilir?

Ekipler, model çağrısından önce gerçekleşmesi gerekenleri listeleyerek işe başlayabilir. Yalnızca görünürlüğe ihtiyaç duyuyorlarsa istek yolunun yanında çalışan bir izleme aracı yeterlidir ve çalışma zamanında ek bir bağımlılık oluşturmaz. Bütçelere, anahtar politikalarına veya model onayına da ihtiyaç duyuyorlarsa bir tür ağ geçidine ihtiyaçları vardır.

Sıradaki ölçüt, sağlayıcı kapsamıdır. Ekip, Azure OpenAI ve Bedrock dâhil üretimde kullandığı tüm sağlayıcıları ve API biçimlerini listelemeli, ardından bu listeyi her ağ geçidinin yol haritasıyla değil, mevcut destek kapsamıyla karşılaştırmalıdır.

LiteLLM’yi hâlihazırda kullanan ekiplerin, beta aşamasındaki bir ağ geçidi ihtiyaç duydukları ve LiteLLM’de olmayan bir özelliği sunana kadar geçiş yapmaları için pek neden yok. Bir izleme aracının ağ geçidinin sağladığı temel avantaj, ağ geçidi çağrısını ajan iz kaydının içine yerleştirmesidir; bu avantajın geçiş yapmaya değmesi gerekir. Yeni bir sistem kuran ekipler, tek bir satıcı her iki bileşeni de sağlasa bile ağ geçidini ayrı bir katman olarak tutabilir. Temel URL’yi ve anahtarları tek bir yapılandırma modülünde tutmak, ileride yapılacak geçişi kod değişikliği yerine yapılandırma değişikliği hâline getirir.

Bu ağ geçitlerinin çoğu beta veya önizleme olarak etiketlendiğinden, eksiklerin listesi hızla kısalacak. Yanıt bekleyen soru, tipik bir şirkette istek yolunun kimin sorumluluğunda olacağı: gözlemlenebilirlik ekibinin mi, bağımsız bir ağ geçidini işleten platform ekibinin mi, yoksa güvenlik ekibinin mi? Bu yıl LangSmith ve Langfuse kendi ağ geçitlerini geliştirdi, Palo Alto Networks ise bir ağ geçidi satın aldı; yine de birçok teknoloji yığınında istek yolu hâlâ LiteLLM üzerinden ilerliyor.