Ana içeriğe geç

AI Gateway Genel Bakış

Apinizer AI Gateway Nedir?​

Apinizer AI Gateway, uygulamalarınız ile birden fazla büyük dil modeli (LLM) sağlayıcısı arasında konumlanmış, OpenAI-uyumlu bir proxy ve gateway'dir. Her sağlayıcıya ayrı bağlantı yönetmek yerine, Apinizer'a bir kez bağlanıp istemci kodunuzda değişiklik yapmadan istekleri herhangi bir desteklenen LLM'ye yönlendirebilirsiniz.

bilgi

LLM, token, embedding gibi temel yapay zeka kavramlarına buradan girmiyoruz — bunlar için Yapay Zeka Temel Kavramları sayfasına bakabilirsiniz. Bu sayfa, Apinizer'ın AI Gateway modülünün ne yaptığına odaklanır.

Temel faydalar:

  • Tek uç nokta — Python OpenAI SDK ile uyumlu, yapılandırılabilir base_url üzerinden entegrasyon
  • Çoklu sağlayıcı desteği ve yanıt normalizasyonu — OpenAI-uyumlu hizmetlerin yanı sıra native formatlı Anthropic, Google Vertex (Gemini) ve AWS Bedrock sağlayıcılarına da bağlanırsınız; tüm sağlayıcı yanıtları OpenAI canonical formatına normalize edilir
  • Gerçek akış (streaming) — Sunucu Tarafından Gönderilen Olaylar (SSE) ile chunk başına iletim
  • Yerleşik kontroller — İstem koruması, kişisel veri (PII) maskeleme, semantik önbellekleme, Limit Planları ve token limitleri ve maliyet takibi
  • Kurumsal görünürlük — Kullanıcı, ekip, model ve dağıtım türüne (bulut vs. şirket içi) göre ayrıntılı kullanım raporları
Streaming ayarı ve istemcinin stream alanı

Her LLM Gateway'in Yönlendirme sekmesinde kendine ait bir Streaming (SSE) anahtarı ve bir İstemci "stream" alanı ayarı bulunur. Bkz. İstemci "stream" Alanı.

  • İstemcinin değerini kullan: istek gövdesindeki stream değeri belirler. stream: true yukarıda anlatıldığı gibi sunucu tarafından gönderilen olaylarla (SSE) iletilir, stream: false tek seferlik yanıt döner. stream alanı olmayan istek Streaming (SSE) anahtarını izler. Yeni LLM Gateway'ler bu seçenekle başlar.
  • Proxy ayarıyla üzerine yaz: her istekte anahtar belirler. Anahtar kapalıyken gateway, istemci istek gövdesinde stream: true gönderse bile isteği tekil (non-streaming) bir yanıt olarak işler — sağlayıcıya iletmeden önce bu alanı false olarak değiştirir (ve stream_options alanını kaldırır). Böylece token sayıları ve maliyet, istemcinin ne gönderdiğinden bağımsız olarak Trafik raporunda doğru görünür. Daha önce oluşturulmuş ve kayıtlı değeri olmayan LLM Gateway'ler bu şekilde çalışır.

LLM Gateway'de yalnızca tek seferlik yanıtta çalışan bir politika varsa istemci streaming'i açamaz.

Streaming açıkken istemciye gönderilen yanıt akışı, proxy'nin log ayarlarında yanıt gövdesi loglaması açıksa Trafik kaydında yer tutucu yerine gerçek olay akışı olarak görünür (gövde boyutu sınırı dahilinde; sınır aşılırsa kayıt <<Streaming Body Truncated>> işaretiyle biter). Kayıt, akış tamamlandığında tek bir trafik kaydı olarak yazılır. Bellek planlaması için kural: her açık akış worker belleğinde en fazla gövde sınırı kadar yer tutar (eşzamanlı akış × gövde sınırı); uzun yanıtların yaygın olduğu ortamlarda kaydedilecek gövdeyi connector'ın Kısmi boyut ayarıyla küçük tutun. Ayrıntı: Trafik Log Ayarları.

Desteklenen LLM Sağlayıcıları​

  • Bulut: OpenAI, Anthropic (Claude), Azure OpenAI, Google Vertex AI, AWS Bedrock ve Mistral, DeepSeek, Groq, xAI gibi OpenAI-uyumlu birçok bulut sağlayıcı
  • Şirket içi: vLLM, Ollama
  • Özel: OpenAI-uyumlu herhangi bir API uç noktası

Her sağlayıcı, şifreli API kimlik bilgileri ve dağıtım meta verileri içeren bir bağlantı aracılığıyla yapılandırılır.

bilgi

Sağlayıcı bağlantısı oluşturma ve dağıtım türü ayarları için LLM Sağlayıcılar ve Modeller sayfasına bakın.

İstek ve Yanıt Formatı

Sohbet istekleri için istemci tarafında OpenAI formatı kullanılır. Sağlayıcı yanıtları OpenAI canonical formatına normalize edilir; böylece mevcut OpenAI istemci kodunuz, hangi sağlayıcıya yönlendirildiğinden bağımsız olarak çalışır.

Anthropic Messages API konuşan bir istemci, örneğin Claude Code, aynı API Proxy'yi kullanabilir. Apinizer bu istemcinin isteklerini çeviri yapmadan iletir. Bkz. Anthropic Messages İstemcileri.

Nasıl Çalışır?​

İstek Akışı​

Her istek aşağıdaki aşamalardan geçer:

  1. Alım — İstek OpenAI formatı JSON olarak doğrulanır ve ayrıştırılır
  2. Korumalar (isteğe bağlı) — Kişisel veri maskeleme, istem denetimi, veri sızıntısı koruması; bkz. Gelişmiş Korumalar
  3. Yönlendirme — Model kimliğine göre sağlayıcı bağlantısı ve model (ve varsa yedek hedefler) seçilir; bkz. Yönlendirme ve Failover
  4. Semantik Önbellek (isteğe bağlı) — Benzer istekler önbelleğe alınmış yanıtları yeniden kullanır
  5. Hız Sınırlaması — Çağıran başına Limit Planları ve LLM Gateway'in Token Rate Limit politikası (dakika, saat, gün, ay başına veya USD bütçe); bkz. Limit Planları ve Token Rate Limit Politikası
  6. Çıkarım — İstek LLM sağlayıcısına iletilir
  7. Yanıt — Kullanım metrikleri ile chunk başına geri akışı yapılır

Semantik önbellek araması ve Token Rate Limit politikası, yönlendirme modeli belirledikten sonra çalışır. Gateway'in gerçekten çağıracağı modeli kullanırlar.

OpenAI SDK Entegrasyonu​

Apinizer AI Gateway'i Python OpenAI SDK veya uyumlu herhangi bir istemci ile kullanın:

from openai import OpenAI

client = OpenAI(
api_key="tuketici-anahtariniz",
base_url="https://<gateway-access-url>/<relative-path>/v1"
)

response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "Merhaba"}],
stream=True
)

for chunk in response:
print(chunk.choices[0].delta.content, end="")

İstemci tarafı kod değişikliği gerekmez — sadece base_url'yi LLM Gateway'inizin Yönlendirme sekmesindeki Uç Noktalar panelinden aldığınız adrese (sonuna /v1 ekleyerek), api_key'i ise Tüketici anahtarınıza işaret edin. Uçtan uca ilk kurulum için AI Gateway Hızlı Başlangıç sayfasına bakın.

Model Keşfi: GET /v1/models​

Gateway, OpenAI'nin model listeleme ucunu (GET /v1/models) uyumlu şekilde sunar — OpenAI Python SDK'sında client.models.list(), LangChain ve LiteLLM gibi OpenAI-uyumlu araçlar model adını elle sabitlemek yerine bu uçtan otomatik keşfedebilir:

models = client.models.list()
for model in models:
print(model.id)

Yanıt gövdesi:

{
"object": "list",
"data": [
{ "id": "gpt-4o", "object": "model", "created": 0, "owned_by": "openai", "max_model_len": 128000 },
{ "id": "claude-3-5-sonnet", "object": "model", "created": 0, "owned_by": "anthropic" }
]
}
created her zaman 0'dır

Apinizer modellerde bir oluşturma zaman damgası tutmaz; OpenAI SDK'ları bu alanı ayrıştırır ama anlam yüklemez. Fiyatlandırma ve yetenek (capability) bilgileri bilerek dönülmez — keşif ucu bir bilgi ifşası yüzeyi değildir.

max_model_len modelin Bağlam Penceresi değeridir

LLM sağlayıcısında modelin Bağlam Penceresi değeri sıfırdan büyükse model kaydında max_model_len alanı döner. İstemci bu değerle isteğinin boyutunu belirleyebilir. Değeri olmayan veya değeri sıfır olan modelde max_model_len alanı yer almaz. Yukarıdaki örnekte claude-3-5-sonnet modelinin Bağlam Penceresi değeri yoktur.

Liste bu proxy'nin servis yüzeyidir, sağlayıcının tüm model listesi DEĞİL​

Dönen liste, o LLM sağlayıcısının tüm model listesi değildir — yalnızca bu LLM Gateway'in aiRouting yapılandırmasında (birincil model + birincil havuz + koşullu yönlendirme + failover zinciri, bkz. Yönlendirme ve Failover) tanımlı, gerçekten servis edilebilir modellerin birleşimidir. İstemci "model" alanı istemcinin modelini kullanacak şekilde ayarlıysa liste, birincil olabilen sağlayıcıların tüm modellerini de içerir; çünkü istemci bunların herhangi birini çağırabilir. Ardından üç eleme kuralı sırayla uygulanır:

  1. Aday modelin bağlı olduğu sağlayıcı bağlantısı deploy edilmemiş veya pasif ise düşürülür.
  2. Modelin Açık anahtarı kapalıysa düşürülür — çalışma anında zaten 403 hatası alacak bir model listede reklam edilmez.
  3. Modelin erişim listesi çağıranı içermiyorsa düşürülür. Bu yüzden aynı LLM Gateway iki çağırana farklı liste döndürebilir.

Hiçbir model hayatta kalmazsa bu bir hata değildir: {"object":"list","data":[]} ile HTTP 200 döner.

Bu uç yalnız listeleme yapar; OpenAI'nin tekil model getirme ucu (GET /v1/models/{model_id}, SDK'da client.models.retrieve(...)) kapsam dışıdır ve eşleşmez.

Kimlik doğrulama ve normal politika zinciri aynen işler​

Keşif ucu bir .well-known benzeri kimlik-doğrulama-muaf yol değildir — proxy'nin normal politika zinciri (auth politikaları dahil) bu istekte de aynen çalışır ve blockAnonymousRequests açık bir proxy'de kimliksiz bir keşif isteği de 401 alır.

Upstream çağrısı yok → ölçüm de yok

Keşif isteği hiçbir sağlayıcıya çıkmaz; bu yüzden token/maliyet ölçümü tetiklenmez. Trafik raporunda bu istek görünür, ama kullanım ve maliyet sütunları boş kalır. Uç yalnız GET kabul eder — başka bir HTTP metoduyla çağrılırsa 405 döner.

LLM Gateway ile Klasik API Proxy Farkı​

Bir LLM Gateway, Apinizer'da aynı ApiProxy varlığıdır — aynı oluşturma/deploy/undeploy akışından, aynı ortam yönetiminden ve aynı proxy listesinden geçer, aynı uçlarla yönetilir. Fark, isteğin backend'e nasıl yönlendirildiğindedir:

  • Klasik API proxy → routing nesnesi (adres listesi, circuit breaker, mTLS, proxy sunucu, NTLM vb.)
  • LLM Gateway → aiRouting nesnesi (LLM sağlayıcı bağlantısı, model, birincil havuz, koşullu yönlendirme, failover zinciri) — bkz. Yönlendirme ve Failover

LLM Gateway çalışma zamanı klasik routing nesnesini hiç okumaz; bu nedenle routing'e bağlı ayarlar bir LLM Gateway üzerinde anlamsızdır.

Davranış Değişikliği

Aşağıdaki 12 ayar ucu (PATCH .../apiProxies/{apiProxyName}/settings/<X>/), bir LLM Gateway'e (ya da MCP veya A2A Gateway'e) uygulandığında artık HTTP 400 döner. Önceden bu uçlar HTTP 200 dönüyordu ama hiçbir etkisi olmuyordu (sessiz no-op) — bu davranış artık açıkça reddediliyor:

circuit-breaker · proxy-server · mtls · ntlm · connection · error-handling · custom-message · grpc · websocket · addresses · routing-status · metadata

LLM Gateway'de mTLS, proxy sunucu ve circuit breaker gibi ayarlar aiRouting üzerinden yapılır — doğru yol PUT .../apiProxies/{apiProxyName}/ai-routing/'dir. metadata ucunun 400 kontrolü koşulludur: yalnızca gövdede fixSoapApiPortType alanı gönderildiğinde tetiklenir (bu alan yalnızca klasik routing'e özgüdür) — düz bir metadata güncellemesi LLM Gateway'de sorunsuz çalışmaya devam eder.

Proxy tipinden bağımsız 11 ayar ucu — CORS, önbellek, idempotency, XML/JSON hata şablonu, forwarded-ip-header, spec-access-type, client-route, keys, bakım modu, iz kaydı (trace), trafik log — LLM Gateway'de de çalışmaya devam eder, dokunulmadı.

Detaylar için bkz. API Referansı: API Proxy Settings.

LLM Gateway Listesinde Gelişmiş Arama​

AI Gateway → LLM Gateway listesindeki Gelişmiş Arama panelinde, klasik proxy alanlarına (ad, açıklama, adres, kategori, ortam, durum) ek olarak yalnız LLM Gateway'lerde görünen üç alan bulunur:

  • AI modeli veya LLM sağlayıcısına göre ara — Serbest metin. Proxy'nin hedefindeki model kimliğiyle ya da LLM sağlayıcısının adı veya tipiyle eşleşir. Örneğin openai yazmak, OpenAI tipindeki sağlayıcılara giden tüm proxy'leri getirir; gpt-4o yazmak o modeli kullananları getirir.
  • Model tipi — Sağlayıcıdaki modelin modalite değeri (Metin (Sohbet), Görüntü, Ses, Gömme, Yeniden Sıralama, Çok Modlu, Görsel Üretim). Seçilen tipteki modelleri kullanan proxy'ler listelenir. Listenin sonundaki Belirtilmemiş seçeneği, model tipi hiç doldurulmamış modelleri kullanan proxy'leri getirir — "Modelleri Keşfet" ya da elle "Model Ekle" ile eklenmiş, henüz sınıflandırılmamış modeller buraya düşer. Değerlendirme sağlayıcı bazındadır — bir bağlantıda sınıflandırılmış, diğerinde boş bırakılmış bir model kimliği yalnız ikincisi için belirtilmemiş sayılır — ve LLM sağlayıcısı silinmiş ya da kapsamınız dışında kalan proxy'ler de burada listelenir; modelleri artık sınıflandırılamaz. Bu proxy'ler diğer hiçbir tip değerinde görünmez; sınıflandırılmamış kayıtları bulmanın yolu bu seçenektir.
  • LLM Sağlayıcı — Projenizde tanımlı ya da yönetici tarafından paylaşılmış sağlayıcılar arasından seçim.

Arama, proxy'nin tüm yönlendirme hedeflerini tarar: tekil birincil hedef, birincil havuz (primary pool), koşullu yönlendirme varyantları ve sağlayıcı failover zinciri. Bu nedenle bir proxy, aranan sağlayıcıyı yalnızca failover zincirinde kullanıyor olsa bile sonuçta görünür.

Alanlar birlikte kullanıldığında

Farklı alanlar VE ile birleşir ve eşleşmeler aynı yönlendirme hedefinde olmalıdır. "Sağlayıcı = OpenAI" ve "Model tipi = Görsel Üretim" birlikte seçildiğinde, bir OpenAI sağlayıcısında görsel üretim modeli çalıştıran proxy'ler listelenir; OpenAI'ı birincil hedefte kullanıp görsel üretim modelini yalnızca failover zincirinde (başka bir sağlayıcıda) kullanan bir proxy listelenmez. Havuz ve koşullu yönlendirme girdilerinde model alanı boş bırakılmışsa birincil model miras alınır ve eşleştirme bu miras alınmış çift üzerinden yapılır.

Belirtilmemiş çıkan bir modeli sınıflandırma

Bir model Belirtilmemiş olarak listeleniyorsa, AI Gateway → Modeller ekranında ilgili sağlayıcıyı açıp modelin panelindeki Model Tipi alanından elle seçebilirsiniz (bkz. LLM Sağlayıcılar ve Modeller). Apinizer bir modele otomatik tip atamaz, çünkü yanlış sınıflandırma model tipi doğrulamasını ve maliyet hesabını bozar.

Filtre veritabanı sorgusuna uygulandığı için sayfa sayısı ve toplam kayıt adedi de daralan sonuca göre doğru hesaplanır. Seçtiğiniz sağlayıcı silinmişse ya da erişiminiz olmayan bir projeye aitse arama boş sonuç döner.

Temel Kavramlar​

Dağıtım Türü

Her sağlayıcı bağlantısının Bulut (sağlayıcı barındırır), Şirket içi (kendi altyapınızda çalışır) veya Diğer (özel sağlayıcılar) olarak işaretlenen bir dağıtım türü vardır; maliyet atfı ve kapasite planlamasında kullanılır.

Limit Planları ve Maliyet

Limit Planlarıyla çağıran başına, Token Rate Limit politikasıyla LLM Gateway başına (dakika/saat/gün/ay veya USD bütçe) kullanımı ve harcamayı sınırlarsınız.

Raporlar ve Analitik

Kullanımı kişi, ekip, model, sağlayıcı ve dağıtım türüne göre; maliyeti isteğe bağlı çoklu para birimiyle izlersiniz.

Sonraki Adımlar​