Ana içeriğe geç

LLM Sağlayıcılar ve Modeller

Genel Bakış​

LLM Sağlayıcı Bağlantısı, harici bir LLM hizmetine (OpenAI, Anthropic, Azure vb.) kurulan güvenli, şifreli bir bağlantıdır. Her bağlantı, sağlayıcı türü, API kimlik bilgileri ve dağıtım meta verilerini içerir.

Proje kapsamı

Ekran iki yerden açılır ve Bağlantı (Connections) ekranlarıyla aynı kapsam kuralını izler:

  • Proje menüsü (AI Gateway → Modeller): yalnız aktif projede oluşturulan kayıtları listeler.
  • Admin menüsü (AI Yönetimi → Modeller): tümünü listeler — paylaşılan kayıtlar ve bütün projelerin kayıtları.

Kapsam yalnız listeler için geçerlidir. LLM Gateway politikasında sağlayıcı seçmek gibi seçim listeleri, projenin kendi kayıtlarının yanında paylaşılan kayıtları da sunmaya devam eder; Apinizer'ın diğer bağlantı seçimleriyle birebir aynı davranış.

Sayfa Yapısı​

AI Gateway → Modeller ekranı yalnız sağlayıcıları listeler. Ayrı bir model sayfası yoktur: bir model yalnız kendi sağlayıcısının içinde düzenlenir (bkz. Modeller). Arama kutusu sağlayıcıyı adından ve ayrıca sağlayıcının model adlarından biriyle de bulur.

Sağlayıcı Tipini Seçme​

Yeni'ye tıkladığınızda açılan Sağlayıcı seçin penceresi, sağlayıcı tiplerini kutucuklar olarak Yönetilen bulut ve Self-hosted olmak üzere iki grupta listeler; arama kutusuyla filtreleyebilirsiniz. Yalnız karar veren iki sağlayıcı bir rozetle işaretlidir: TypeSafe Jev için Karar modeli, TEI Classifier (Self-Hosted) için Koruma sınıflandırıcısı. Uç nokta ve kimlik doğrulama şeması seçtiğiniz tiple birlikte gelir. Wire protokolü ve istek yolları da tipin kendisine aittir; siz değiştirmedikçe tipin değerleri geçerlidir. Bağlantının kendi formu bu değerlerin herhangi birini değiştirmenize izin verir.

Aradığınız sağlayıcı listede yoksa pencerenin altındaki Listede yok mu? → Özel sağlayıcı kutucuğuna geçin.

Özel Sağlayıcı​

Özel sağlayıcı kutucuğu listede olmayan her sağlayıcıyı kapsar. Sağlayıcı tipi Diğer olarak kaydedilir ve tipten gelen bir varsayılan yoktur; form Bearer token kimlik doğrulaması, Authorization başlığı ve /chat/completions sohbet tamamlama yoluyla açılır, gerisini siz doldurursunuz. Dağıtım tipi formda seçilmez; otomatik olarak Diğer ayarlanır:

  • Adapter ailesi — sağlayıcının gerçekte konuştuğu wire protokolünü seçersiniz: OpenAI-uyumlu, Anthropic, Gemini, Bedrock, vLLM, TYPESAFE ya da TEI. TYPESAFE ve TEI yalnız karar veren sağlayıcılar içindir; bkz. Karar Veren Sağlayıcılar. Formu kaydetmek için bu alanın seçili olması zorunludur: boş bırakılan bir adapter ailesinde istekler sessizce OpenAI-uyumlu formata düşer, bu yüzden form bu alanı baştan zorunlu tutar.
  • Uç Nokta URL ve diğer istek yolları (embedding, Responses, transkripsiyon, seslendirme, görsel üretim) — kendiniz girersiniz; yalnızca o trafiği gerçekten bu sağlayıcı üzerinden yönlendirecekseniz doldurmanız gerekir.

Gelişmiş bölümü özel bir sağlayıcıda her zaman açık gelir ve hiçbir alan gizlenmez — Apinizer bu sağlayıcıyı tanımadığı için hangi uçları sunduğunu yalnızca siz bilirsiniz; kullanmadığınız yolları boş bırakabilirsiniz.

Bir özel sağlayıcı bağlantısı Dışa/İçe Aktarma Sihirbazı'nda ve APIops'ta diğer sağlayıcı bağlantılarıyla aynı LLM Provider tipiyle taşınır; sağlayıcının modelleri de bu tipin içinde taşınır — bkz. API Referansı: LLM Providers.

Sağlayıcı Türleri​

Apinizer AI Gateway aşağıdaki sağlayıcıları destekler. Kod kolonu sağlayıcı tipinin kodudur — APIops'ta bu değerle karşılaşırsınız. 2026.09.1 sürümüyle dokuz yeni bulut sağlayıcı ekledi (Google AI Studio ve tabloda xAI'den NVIDIA NIM'e kadar uzanan satırlar) — hepsi OpenAI-uyumlu tel formatı konuşur, bu yüzden yeni bir adaptör ailesi gerekmedi:

SağlayıcıKodDağıtım (varsayılan)Notlar
OpenAIopenaiBulutGPT-4o, GPT-4 Turbo, GPT-3.5, vb.
AnthropicanthropicBulutClaude modelleri
Azure OpenAIazure-openaiBulutAzure'da barındırılan OpenAI modelleri
Google Vertex AIvertexBulutPaLM 2, Gemini
Google AI Studiogoogle-ai-studioBulutDoğrudan Gemini API yüzeyi — Vertex'ten ayrı, GCP projesi ya da OAuth2 gerektirmez
AWS BedrockbedrockBulutClaude, Llama, Mistral, Titan, Nova
CoherecohereBulutCommand modelleri
MistralmistralBulutMistral/Mixtral modelleri
DeepSeekdeepseekBulutDeepSeek-V3/R1
GroqgroqBulutLPU donanımıyla hızlı çıkarım
Moonshot (Kimi)moonshotBulutKimi modelleri
Zhipu (GLM)zhipuBulutGLM modelleri
Qwen (DashScope)qwen-dashscopeBulutAlibaba Qwen modelleri
xAIxaiBulutGrok modelleri
Together AItogetherBulutAçık ağırlıklı model agregatörü
Fireworks AIfireworksBulutAçık ağırlıklı model çıkarımı
CerebrascerebrasBulutCerebras Inference
Hugging FacehuggingfaceBulutInference Providers router
OpenRouteropenrouterBulutÇoklu sağlayıcı agregatörü — model kimlikleri vendor/model biçimindedir
PerplexityperplexityBulutPerplexity Router API
NVIDIA NIMnvidia-nimBulutNVIDIA barındırmalı yüzey
Voyage AIvoyageBulutYalnızca embedding sağlayıcısı
vLLMvllmŞirket içiŞirket içi çıkarım motoru
OllamaollamaŞirket içiYerel LLM çıkarımı
TypeSafe JevtypesafeBulutYalnız karar veren model. Sohbet için kullanılamaz; bkz. Karar Veren Sağlayıcılar
TEI Classifier (Self-Hosted)teiŞirket içiYalnız karar veren koruma sınıflandırıcısı. Sohbet için kullanılamaz; bkz. Karar Veren Sağlayıcılar
Özel OpenAI-Uyumlucustom-openai-compatŞirket içiOpenAI-uyumlu herhangi bir uç nokta

Karar Veren Sağlayıcılar​

Apinizer bir sağlayıcıyı sohbet için değil, karar vermek için de kullanabilir. Karar veren model Apinizer adına bir karar verir. İki yerde kullanılır:

  • AI yönlendirmesinin LLM sınıflandırıcısı: rota etiketini seçer. Bkz. Yönlendirme ve Failover.
  • Koruma politikalarının LLM hakemi: İstem Koruması, Konu-Dışı Koruması, Veri Sızıntısı Koruması, Kişisel Veri Maskeleme ve Dayanaklılık Koruması. Bkz. Gelişmiş Korumalar.

İki sağlayıcı tipi yalnız karar verir:

SağlayıcıRozetSınıflandırıcıHakemNe yapar
TypeSafe JevKarar modeliEvetEvetYapısal bir yanıt döndürür: bir seçenek veya evet/hayır olasılığı. Metin üretmez.
TEI Classifier (Self-Hosted)Koruma sınıflandırıcısıHayırEvetKüçük bir sınıflandırıcı modeldir. Sabit etiketlere puan verir.

TypeSafe Jev

  • Uç nokta https://api.typesafe.ai/v1. Kimlik doğrulama Authorization başlığındaki Bearer anahtarıdır. Hazır model jev-latest.
  • Apinizer karar çağrısını POST {uç nokta}/systemone ile yapar.
  • Bağlantıyı Test Et, modelleri GET /v1/models ile listeler.

TEI Classifier (Self-Hosted)

  • Hugging Face Text Embeddings Inference üzerinde çalışır ve sabit etiketlere puan veren bir sınıflandırıcı modeli sunar. Hazır modeller meta-llama/Prompt-Guard-86M ve protectai/deberta-v3-base-prompt-injection-v2. İkisi de en çok 512 girdi token'ı alır.
  • meta-llama/Prompt-Guard-86M kapılı bir modeldir. Hugging Face bu modeli kapılı tutar. TEI sunucusu modeli indirmek için bir Hugging Face token'ı ve kabul edilmiş Llama lisansı ister. Bunlar yoksa açık modeli kullanın: protectai/deberta-v3-base-prompt-injection-v2 (Apache-2.0 lisansı, etiketler SAFE ve INJECTION). Tehlikeli etiketler alanına INJECTION girin. Bkz. Karar Veren Modeller ve Küçük Ollama Modelleri.
  • Varsayılan uç nokta http://localhost:8080. Kimlik doğrulama yoktur.
  • Apinizer karar çağrısını POST {uç nokta}/predict ile yapar.
  • Bağlantıyı Test Et ve Sağlayıcıdan keşfet, GET /info ucunu okur. Model kimliğini, en uzun girdi uzunluğunu ve etiketleri alır.

Sağlayıcı formu bu iki tipte bir bilgi notu gösterir. Sohbet çıkarımı testi bu sağlayıcılar için sunulmaz.

Yalnız karar veren sağlayıcılar yönlendirme hedefi olamaz

TypeSafe Jev ve TEI sohbet yanıtı üretmez. Bunları yönlendirme hedefi, havuz üyesi, failover hedefi veya embedding sağlayıcısı olarak kullanamazsınız. Bu listelerde görünmezler. Böyle bir sağlayıcıya başvuran kayıt reddedilir.

Kimlik bilgisi AI gateway'de olmalıdır

Karar çağrısı sağlayıcıda saklı kimlik bilgisini kullanır. Kimlik bilgisi kaynağını AI gateway sağlar olarak ayarlayın. İstemci sağlar seçili bir sağlayıcı için karar çağrısında istemci anahtarı yoktur. Sağlayıcı 401 veya 403 ile yanıt verir.

Sohbet modelleri de karar verebilir. OpenAI uyumlu sohbet sağlayıcıları (OpenAI, Azure OpenAI, DeepSeek, Moonshot (Kimi), Zhipu, Mistral, Groq, Ollama, vLLM, xAI, Google AI Studio OpenAI uç noktası, Together, Fireworks, Cerebras, Hugging Face, OpenRouter, Perplexity ve NVIDIA NIM), Anthropic ve Adapter ailesi OPENAI_COMPATIBLE veya VLLM olan özel sağlayıcılar karar verebilir. AWS Bedrock, Google Vertex AI, Cohere, yerel Gemini wire formatı, yalnız embedding sağlayıcıları ve adapter ailesi olmayan özel sağlayıcılar karar veremez.

Dağıtım Türü​

Her bağlantının bir dağıtım türü etiketi vardır:

  • Bulut — LLM sağlayıcı tarafından yönetilir (yukarıdaki tablodaki "Bulut" satırları)
  • Şirket içi — LLM altyapınızda çalışır (vLLM, Ollama, TEI, özel OpenAI-uyumlu uç nokta)
  • Diğer — Özel sağlayıcı. Apinizer özel bir sağlayıcının nerede çalıştığını bilemez, bu yüzden tahmin etmez

Dağıtım türü, bağlantıyı oluştururken sağlayıcı türüne göre otomatik doldurulur. Oluşturma ve düzenleme formunda Dağıtım Türü alanı yoktur. Sağlayıcı detay ekranı değeri gösterir.

Dağıtım türü yalnızca raporlama etiketidir. Yapay zeka kullanım raporlarındaki Bulut / Şirket içi / Diğer kırılımını belirler; isteklerin yönlendirilmesini hiçbir zaman değiştirmez. Bu değişiklikten önce kaydedilen özel sağlayıcılar kayıtlı değerlerini korur.

Kimlik Bilgileri​

Tüm API anahtarları ve sırlar şifreli olarak saklanır ve hiçbir zaman günlüğe yazılmaz.

Kimlik Bilgisini Kim Tutar: Gateway mi, İstemci mi​

Her bağlantı, bir isteğe giden sağlayıcı kimlik bilgisini kimin sağladığı sorusunu baştan yanıtlar:

Kimlik Bilgisi KaynağıDavranış
AI gateway sağlar (varsayılan)Apinizer anahtarı saklar ve her isteği bu anahtarla imzalar — bu ayar eklenmeden önce her bağlantının davrandığı gibi.
İstemci sağlarApinizer hiçbir kimlik bilgisi saklamaz. Her isteğin sağlayıcının kendi header'ını zaten taşıması gerekir; gateway bu header'ı olduğu gibi iletir, saklı bir değer eklemez. Bütçe, maliyet ve hız sınırları yine çağrıyı yapan Apinizer tüketicisine bağlı kalır — yalnızca sağlayıcıya giden anahtar istemciye aittir.

İstemci sağlar seçeneği, sağlayıcının ham anahtarının Apinizer içinde hiç saklanmasını istemeyen kurulumlar içindir — anahtarı her istekte çağıran (ya da önündeki bir proxy) sağlar. Hiçbir şey saklanmadığı için Bağlantıyı Test Et, yalnızca o tek deneme için geçici bir kimlik bilgisi ister ve bu değer hiçbir zaman kaydedilmez.

Anahtar Nereden Gider: Header mı, Query Parametresi mi​

API-anahtarı ailesindeki kimlik doğrulama biçimleri için (Bearer token, adlandırılmış bir header'daki API anahtarı ya da özel bir header — aşağıdaki Kimlik Bilgisi Tipi Etiketi bölümüne bakın) ikinci bir ayar, anahtarın giden istekte nereye yerleştirileceğini belirler:

API Anahtarı KonumuBiçimNotlar
Header (varsayılan)<header adı>: <önek><anahtar>Ana akım her sağlayıcı.
Query parametresi?<parametre adı>=<anahtar>URL'nin sonuna eklenir — Gemini'nin native ucu ?key= kabul eder. Bir header alternatifi varsa tercih edilmemelidir, çünkü URL'ye konan bir anahtar erişim günlüklerine düşebilir.

Basic auth, AWS Signature V4 ve Google servis hesabı (OAuth2) akışlarının her biri kendi sabit taşıma biçimine sahiptir ve bu ayardan etkilenmez.

Anahtar Öneki​

Anahtar değerinin önüne telde eklenen metindir. Boş bırakıldığında kimlik bilgisi tipinin kendi varsayılan önekine düşer (Bearer token için Bearer , ham bir API anahtarı için hiçbir şey). Öneksiz ham anahtar isteyen bir sağlayıcı için (Anthropic'in x-api-key biçimi gibi) alanı bilerek boş değere ayarlayın; Authorization: Token <anahtar> bekleyen bir sağlayıcı için ise Token gibi bir değer girin.

İstemcinin Saklı Anahtarı Geçersiz Kılmasına İzin Verme​

Gateway'in tuttuğu bir bağlantıda, İstemcilerin kendi anahtarıyla geçersiz kılmasına izin ver ayarı tek bir isteğin saklı kimlik bilgisini atlamasına izin verir: gelen istek zaten bağlantının kendi kimlik doğrulama header'ını taşıyorsa, saklı anahtar yerine bu değer iletilir — Kong'un allow_override dediği aynı örüntü. Kapalı bırakıldığında (varsayılan), gelen isteğin üzerindeki böyle bir header, çağrı imzalanmadan önce düşürülür; böylece istemci yalnızca header adını tahmin ederek saklı anahtarı asla sızdıramaz.

Kimlik Bilgisi Tipi Etiketi​

Formda gösterilen Kimlik Bilgisi Tipi (Bearer token, header içinde API anahtarı, query parametresi olarak API anahtarı, Basic — kullanıcı adı + parola, AWS Signature V4, Google servis hesabı, ya da kimlik doğrulama yok) ayrı, saklanan bir alan değildir — altta yatan Kimlik Doğrulama Şeması ile, API-anahtarı biçimleri için yukarıdaki API Anahtarı Konumu ayarından türetilen bir etikettir:

Ekranda gösterilen Kimlik Bilgisi TipiAltta yatan Kimlik Doğrulama ŞemasıAPI Anahtarı Konumu
Bearer tokenBEARER—
Header içinde API anahtarıAPI_KEY_HEADER ya da CUSTOMHeader
Query parametresi olarak API anahtarıAPI_KEY_HEADER ya da CUSTOMQuery
Basic — kullanıcı adı + parolaBASIC—
AWS Signature V4AWS_SIGV4—
Google servis hesabı (JSON)OAUTH2—
Kimlik doğrulama yokNONE—

API_KEY_HEADER ve CUSTOM, ekranda aynı "API anahtarı" kimlik bilgisi tipini paylaşır — ikisi de bir anahtarı header ya da query parametresi olarak gönderir; aralarındaki tek fark, header adı ve önekin sağlayıcı tipinin varsayılanlarından mı yoksa sizin girdiğiniz değerlerden mi geldiğidir.

Yanıt Normalizasyonu​

Sağlayıcı ne olursa olsun (OpenAI-uyumlu veya native format), Apinizer AI Gateway sohbet isteklerinin yanıtlarını OpenAI canonical formatına normalize eder. Bu sayede istemci tarafında sağlayıcıya özel bir ayrıştırma mantığı yazmanıza gerek kalmaz — aynı istemci kodu OpenAI, Anthropic, Vertex veya Bedrock bağlantısı arkasında da değişmeden çalışır.

AWS Bedrock sohbet akışı (streaming) henüz desteklenmiyor

Bedrock'un InvokeModelWithResponseStream API'si, worker'ın ayrıştırmadığı ikili (binary) bir olay-akışı (event-stream) çerçevelemesi kullanır. Bedrock bağlantısına yönlendirilen bir akış (streaming) sohbet isteği, AWS'ye hiçbir çağrı yapılmadan bir yapılandırma hatasıyla reddedilir — hiçbir şey denenmez, hiçbir maliyet oluşmaz. Bu bacak için streaming: false ayarlayın veya akış trafiğini başka bir sağlayıcı üzerinden yönlendirin. Akışsız (unary) Bedrock sohbet istekleri bundan etkilenmez.

Sağlayıcı Uyumluluk Matrisi​

Her bağlantı türü her uç noktayı desteklemez ve her sağlayıcının isteği/yanıtı kendi ham (native) formatına tam çevrilmez — bir kısmı, sağlayıcı zaten (ya da beklenildiği üzere) OpenAI formatını konuştuğu için isteği olduğu gibi iletir (pass-through); daha küçük bir grup ise gerçekten çevrilir.

SağlayıcıChat completionsSohbet akışı (streaming)EmbeddingSes / görsel (STT, TTS, görsel üretim)
OpenAI, Azure OpenAI, Özel OpenAI-Uyumlu, vLLM, Ollama✅✅✅✅
Mistral, Zhipu (GLM), Qwen (DashScope), Together AI, Google AI Studio✅✅✅❌
DeepSeek, Groq, Moonshot (Kimi), xAI, Fireworks AI, Cerebras, Hugging Face, OpenRouter, Perplexity, NVIDIA NIM✅✅❌ (yalnız sohbet — birinci-taraf embedding uç noktası yok)❌
Cohere✅✅❌ (henüz yok — özel bir adapter gerekir)❌
Voyage AI— (yalnız embedding sağlayıcısı)—✅❌
TypeSafe Jev, TEI— (yalnız karar veren sağlayıcı; bkz. Karar Veren Sağlayıcılar)—❌❌
Anthropic✅ (native çeviri)✅ (native çeviri)❌ (embedding uç noktası hiç yok — bunun yerine bir Voyage AI bağlantısı kurun, aşağıdaki Hazır Şablonlar bölümüne bakın)❌
Google Vertex AI (Gemini)✅ (native çeviri)✅ (native çeviri, SSE)❌ (henüz yok)❌
AWS Bedrock — Anthropic modelleri✅ (native çeviri)❌ (yukarıdaki uyarıya bakın)❌ (henüz yok)❌
AWS Bedrock — Titan, Llama, Mistral, Nova✅ (OpenAI biçimli gövde olduğu gibi iletilir; bu aileler için native çeviri henüz yok)❌❌ (henüz yok)❌

Embedding veya Ses/Görsel sütununda ❌ görmek, Apinizer'ın isteği sağlayıcıya ulaşmadan reddettiği anlamına gelir — hiçbir şey denenmez, hiçbir maliyet oluşmaz.

Native Çeviri ile Pass-Through Arasındaki Fark​

Yalnızca üç bağlantı türü isteği/yanıtı gerçekten kendi şemasına çevirir: Anthropic, Google Vertex AI (Gemini) ve — yönlendirilen model bir Anthropic-on-Bedrock modeliyse — AWS Bedrock (model kimliği anthropic. içeren her model; us.anthropic.* gibi bölgeler-arası inference profilleri dahil). Diğer tüm sağlayıcılar — Bedrock'un Titan/Llama/Mistral/Nova modelleri ve Cohere dahil — istemcinin OpenAI biçimli isteğini değiştirmeden iletir.

Native çevirisi yapılan bu üç sağlayıcı için bazı OpenAI istek alanlarının karşılığı yoktur ve sessizce düşürülür (worker'da WARN olarak loglanır, istemciye hiçbir zaman yansımaz):

OpenAI alanıAnthropicGoogle Vertex AI (Gemini)
modelgövdede kalırgövdede yok — URL path'inde taşınır
System / developer mesajıüst-seviye system alanına eşlenirsystemInstruction'a eşlenir
max_tokens / max_completion_tokenszorunlu — istemci göndermezse modelin maksimum çıktı değerine, o da yoksa 4096'ya düşeristeğe bağlı — yalnızca istemci gönderdiyse ayarlanır
tools[].functiontools[].input_schema'ya eşlenirfunctionDeclarations'a eşlenir
tool_choice: "none"düşürülür (araç tanımları da düşürülür)mode: "NONE"'a eşlenir (araç tanımları korunur)
temperatureistemci 1.0'dan yüksek gönderirse 1.0'a sabitlenir (clamp)olduğu gibi iletilir (0–2 aralığı)
stopstop_sequences'a eşlenirstopSequences'a eşlenir (yalnız ilk 5 eleman)
usermetadata.user_id'ye eşlenirdüşürülür
n, presence_penalty, frequency_penalty, logit_bias, logprobs, seed, response_format, parallel_tool_callsdüşürülürdüşürülür
Metin-dışı mesaj içeriği (görsel, ses, …)düşürülür — bugün yalnız metin destekleniyordüşürülür — bugün yalnız metin destekleniyor

Kullanım (usage) muhasebesi de aileye göre farklıdır: Anthropic'in istemciye yansıyan prompt_tokens'ı, önbelleklenmiş token'ları taze girdi token'larının üstüne ekler; Gemini'nin promptTokenCount'u ise önbelleklenmiş token'ları zaten içinde barındırır. Apinizer bu farkı dahili olarak muhasebeleştirir, böylece hangi ailenin isteği karşıladığından bağımsız olarak maliyet takibi ve kotalar doğru kalır — bkz. Raporlar ve Analitik ve Token Rate Limit Politikası.

Bir proxy farklı aileler arasında failover yaptığında — örneğin Anthropic birincil + OpenAI veya Gemini yedek — her bacağın isteği her zaman orijinal istemci isteğinizden yeniden kurulur; bir önceki bacağın zaten çevrilmiş native gövdesinden değil. Bkz. Failover Zinciri.

Modeller​

Bir modelin tek sahibi sağlayıcısıdır. Ayrı bir model kataloğu ya da model sayfası yoktur. Modeller sağlayıcı sayfasındaki Modeller kartında listelenir. Kartın Yapılandır düğmesi listeyi bir çekmecede açar. Bir modeli düzenlemek için satırın sonundaki "⋯" menüsünden Düzenle'yi seçin; model sağdan açılan panelde düzenlenir. Panelde Modeli Kaydet'e, ardından çekmecedeki Kaydet'e basıp açılan pencereyi Onayla ile onaylayın. Bu adımlar tamamlanana kadar değişiklikler kalıcı olmaz.

Model Alanları​

AlanAçıklama
Model IDSağlayıcının model kimliği (örn. gpt-4o). Bir sağlayıcıda aynı model kimliği yalnız bir kez bulunur.
Görünen AdEkranlarda gösterilen okunabilir ad.
Bağlam Penceresi, Maks. Çıktı TokenModelin kapasitesi. Yönlendirme bağlam penceresini uygular: istek modelin bağlam penceresine sığmazsa AI proxy'nin Yönlendirme sekmesindeki Context window taşması kartı belirler. Bağlam penceresi değeri olmayan model kontrol edilmez. Bkz. Context Window Taşması.
Model Tipi (modalite)Modelin desteklediği istek türü: sohbet tamamlama, gömme (embedding), ses-metin, metin-ses, görsel üretim. Boş bırakılabilir.
YeteneklerModelin yetenekleri.
Fiyatlarİsteğe bağlı liste fiyatları: Girdi $/1M, Çıktı $/1M, Önbellek $/1M; görsel başına, ses dakikası başına ve TTS karakteri başına fiyat.
DurumModelin Aktif ya da Pasif olması. Aşağıya bakın.
Erişim Kontrolü (ACL)Modeli çağırabilecek tüketiciler, uygulamalar ve organizasyonlar. Aşağıya bakın.

Her modelin fiyat ve modalite bilgisi kendi sağlayıcısının içindedir. Modeller hazır bir listeden gelmez ve kayıtta otomatik tamamlanmaz. Modelleri siz eklersiniz; fiyat ve modaliteyi elle girersiniz. Fiyatı değiştirdiğinizde yeni istekler güncel değeri hemen kullanır. Geçmiş kayıtlar kendi maliyetiyle kalır.

Neden model tipi önemli?

Model tipi boş kalan bir model, AI Gateway → LLM Gateway listesindeki Model tipi filtresinde hiçbir değerde görünmez. Token kavramı olmayan modellerde (görsel üretim, ses) maliyet 0 USD olarak hesaplanır. Filtrenin Belirtilmemiş seçeneği sağlayıcı bazında değerlendirilir: bir sağlayıcıda sınıflandırılmış, diğerinde boş bırakılmış bir model kimliği yalnızca boş olduğu sağlayıcı için belirtilmemiş sayılır.

Model Durumu: Etkinleştir ve Devre Dışı Bırak​

Satırın "⋯" menüsündeki Devre Dışı Bırak ile pasif yapılan bir model gateway'de çağrılamaz. Gateway modeli HTTP 403 ile reddeder ve model GET /v1/models yanıtında görünmez. Durum her model için ayrıdır. Gateway'in kendi çağrıları da duruma uyar: pasif bir modeli rota sınıflandırıcısı, koruma politikasının LLM hakemi ve embedding çağrıları kullanmaz. Rota sınıflandırıcısı çağrı yapmaz ve hiçbir sınıflandırıcı rotası eşleşmez. LLM hakemi bir değerlendirme hatası verir; sonucu politikanın hata kipi belirler. Embedding çağrısı, istek sağlayıcıya ulaşmadan reddedilir. 2026.10.0 sürümüne yükseltmeden sonra mevcut tüm modeller aktif gelir. Modeli yeniden açmak için Etkinleştir'i seçin; değişiklik sağlayıcıyı kaydedip onayladığınızda uygulanır. Listede olmayan modelleri reddetmek için Yalnız Listelenen Modeller anahtarını kullanın.

Erişim Kontrolü (ACL)​

Model panelindeki Erişim Kontrolü kartı, modeli kimlerin çağırabileceğini belirler. Karta tüketici, uygulama ve organizasyon ekleyebilirsiniz. ACL açık olduğunda yalnız listedeki özneler modeli çağırabilir.

Sağlayıcıyı düzenleyebilen kişi modelin ACL'sini de düzenleyebilir. Admin sağlayıcılarını adminler, proje sağlayıcılarını proje düzenler.

Yalnız Listelenen Modeller​

Yalnız listelenen modeller anahtarı, Modeller kartının Yapılandır düğmesiyle açılan çekmecenin en üstündedir. Varsayılan olarak kapalıdır.

  • Kapalı: Gateway, sağlayıcının listesinde olmayan bir model kimliğini olduğu gibi sağlayıcıya gönderir. Yalnız listedeki modellerin fiyatı ve erişim kontrolü vardır. LLM Gateway İstemcinin modelini kullan seçeneğini kullanıyorsa model kimliği ayrıca düz bir ad olmalıdır; bkz. Sağlayıcının Listesinde Olmayan Modeller.
  • Açık: Gateway, listede olmayan bir model kimliğini reddeder. İstemci HTTP 403 alır. Listedeki bir modelin etiketli hali listelenmiş sayılır (örneğin listede llama3 varsa llama3:8b). Model kimliği olmayan istek bundan etkilenmez.

Ret her yolda geçerlidir:

  • Yönlendirme. Ana sağlayıcı ve yedek (failover) adımları buna dahildir. Modeli listelemeyen yedek adım atlanır.
  • GET /v1/models listesi. Liste yalnız listedeki modelleri gösterir.
  • Token hız limitinin daha ucuz modele düşürme adımı. Düşürme adımı listede olmayan bir model seçmez.
  • Rota sınıflandırıcısı, LLM hakemi ve gateway'in gömme (embedding) çağrıları.

Bu anahtarı açık olan sağlayıcıda en az bir model olmalıdır. Liste boşsa Apinizer kaydı reddeder.

İstemci, mevcut POLICY_ROUTING_AI_MODEL_ACCESS_DENIED hata mesajını alır. Mesaj metnini hata mesajları ekranından değiştirebilirsiniz. Gateway günlüğü, modelin LLM sağlayıcısı tarafından listelenmediğini ve sağlayıcının yalnız listelenen modellere izin verdiğini yazar.

Karar veren modelleri listeye ekleyin

Anahtar açıkken, bu sağlayıcıda rota sınıflandırıcısı, LLM hakemi ve gömme ayarlarının kullandığı modeller de listede olmalıdır. Listede olmayan bir modelin çağrısını gateway reddeder. Bkz. Karar Veren Modeller ve Küçük Ollama Modelleri.

Yalnız listelenen modeller anahtarı açıkken bir sağlayıcıyı kaydettiğinizde, Apinizer sağlayıcıdan listesinde olmayan bir model istenen yerleri tarar. Tarama şu yerleri kapsar:

  • LLM Gateway yönlendirmesi: ana model, model havuzu, yedek (failover) adımı, koşullu rotalar, sınıflandırıcı ve semantik önbellek gömme (embedding) modeli.
  • Politikaların gömme modelleri.
  • LLM hakemi guardrail'leri.
  • Token hız limitinin daha ucuz modele düşürme adımı.
  • Bilgi tabanları.

Tarama API proxy'leri, proxy gruplarını, politika gruplarını ve global politikaları kapsar. Apinizer kaydı engellemez. Ekran, her yeri ve o yerin listede olmayan model kimliklerini gösteren bir uyarı verir. Örnek: API Proxy: chat (gpt-4o-mini). Gateway, siz modelleri listeye ekleyene veya ayarları değiştirene kadar bu çağrıları reddeder.

Apinizer, değişken olarak yazılmış model kimliğini (${...}) denetlemez. Proxy gruplarında veya global politikalarda tanımlı Limit Planı bütçelerini ve token bütçelerini de denetlemez, çünkü bunlar bir sağlayıcı belirtmez. Uyarı yalnız Manager ekranında görünür. APIops ile yapılan kayıt uyarıyı döndürmez.

Model Ekleme​

Model ekle sağdan bir panel açar. Panelde iki sekme vardır:

  • Sağlayıcıdan keşfet — sağlayıcının kendi model listesini (/models) çeker. Bkz. Model Keşfi.
  • Elle ekle — model kimliğini yazarsınız. Sağlayıcının listelemediği modeller (ince ayarlı modeller, özel dağıtımlar) için kullanın.

Model Keşfi​

"Model keşfi" iki ayrı şeyi anlatır; hangisinden söz edildiğine dikkat edin.

İstemci tarafı keşif — GET /v1/models​

Bir proxy'nin sohbet trafiğinde kullandığı bağlantılar, GET /v1/models uçuyla OpenAI'nin model listeleme sözleşmesinde de keşfedilebilir. İstemci elle model adı sabitlemek yerine client.models.list() (OpenAI SDK), LangChain veya LiteLLM gibi araçlarla otomatik keşif yapabilir. Liste yalnızca o proxy'nin yönlendirmesinde gerçekten servis edilen ve açık modelleri döner. Detaylar için bkz. AI Gateway Genel Bakış → Model Keşfi.

Yönetim tarafı keşif — Sağlayıcıdan keşfet​

Model ekle panelinin Sağlayıcıdan keşfet sekmesi, sağlayıcının canlı model listesini çeker ve seçerek eklemenizi sağlar. Model adlarını sağlayıcının dokümantasyonundan elle kopyalamanız gerekmez; yazım hatasından doğan "model bulunamadı" hataları da böylece önlenir.

Keşif Modeller çekmecesinin içinde çalıştığı için AI geliştirmeyi yönetme yetkisi gerektirir. Keşif başarısız olduğunda panel nedeni de gösterir: sağlayıcı keşif ucunu sunmuyor (HTTP 404), sağlayıcı isteği reddetti (HTTP durum kodu), ortam bulunamadı ya da seçilen ortamdaki worker yanıt vermedi.

Nasıl çalışır:

  1. Sayfanın üstündeki açılır menüden bir ortam seçin — Bağlantıyı Test Et ile aynı seçim kullanılır. Sağlayıcının /models ucunu seçilen ortamın worker'ı çağırır. Kurumsal kurulumlarda sağlayıcıya çoğu zaman yalnızca Worker ağı eriştiği için bu seçim önemlidir.
  2. Sağlayıcıdan keşfet sekmesini açın. İstek, Bağlantıyı Test Et ile aynı adrese ve aynı kimlik doğrulama başlıklarıyla gider; tek farkı yanıt içeriğinin okunmasıdır.
  3. Modeller listelenir. Sağlayıcıda zaten kayıtlı olanlar Zaten ekli etiketiyle işaretlenir ve seçilemez; geri kalanlar Yeni görünür.
  4. Eklemek istediklerinizi işaretleyip Seçilenleri Ekle deyin. Modeller model listesine eklenir — kaydedilmez. Kalıcı olması için Yapılandır çekmecesinde Kaydet'e basıp onaylamanız gerekir.

Panel ayrıca kayıp modelleri de bildirir: sağlayıcıda kayıtlı olduğu hâlde sağlayıcının canlı listesinde artık görünmeyenler. Bunlar genellikle emekliye ayrılmış modellerdir ve yönlendirmede seçili kalırlarsa istek çalışma zamanında hata alır. Apinizer bunları otomatik silmez — sağlayıcı geçici bir arıza yüzünden eksik liste dönmüş olabilir ve sessiz silme çalışan bir yönlendirmeyi bozardı; kararı siz verirsiniz.

not

Keşif yalnızca model kimliği, görünen ad, bağlam penceresi ve azami çıktı belirteci alanlarını getirir. Fiyat, modalite ve yetenek alanları gelmez — sağlayıcılar bu değerleri birbirinden farklı birimlerde döndürdüğü için otomatik alınmaları hatalı maliyet raporlamasına yol açardı. Bu alanları, satırın "⋯" menüsündeki Düzenle ile açılan model panelinde elle doldurun.

uyarı

Sağlayıcı bir model listeleme ucu sunmuyorsa (bazı şirket-içi kurulumlar) keşif HTTP 404 ile "bu sağlayıcı model keşfini desteklemiyor" sonucunu döner. Bu bir bağlantı hatası değildir — modelleri Elle ekle sekmesiyle girin. AWS Bedrock ve Google Vertex AI bağlantıları, Bağlantıyı Test Et'te olduğu gibi keşfi de henüz desteklemez.

Model Silme​

Bir modeli sağlayıcıdan silmek, yalnızca model kullanımda değilse mümkündür. Model kullanımdaysa silme reddedilir ve hata mesajı kullanıldığı yeri adıyla listeler. Kontrol şu yerleri kapsar:

  • API Proxy'lerin yönlendirmesi: birincil hedef, failover hedefleri, koşullu rotalar ve sınıflandırıcı
  • Semantic cache ve RAG embedding ayarları
  • Global AI politikaları
  • Politika grupları
  • Proxy grupları
  • Bilgi tabanları

Modeli silmek için önce bu referansları kaldırın ya da başka bir modele yönlendirin. Bir sağlayıcıda "en az bir model" kuralı yoktur.

Modellerin Maliyet Takibine Katkısı​

Modelin birim fiyatları yalnızca raporlama için değil, gateway'in çalışma zamanı kararları için de kullanılır:

  • Maliyet takibi — her isteğin USD maliyeti, kullanılan token sayısı × modelin birim fiyatı ile hesaplanır (Raporlar ve Analitik).
  • Bütçe ve limit uygulaması — USD limitleri modelin fiyatına göre hesaplanır (Limit Planları, Token Rate Limit Politikası).
  • Maliyet-duyarlı yönlendirme — birden fazla eşit-öncelikli hedef tanımlıysa, en düşük maliyetli model fiyatlara bakılarak seçilebilir (Yönlendirme ve Failover).
Fiyatsız model 0 sayılır

Fiyat girmek isteğe bağlıdır. Fiyatı olmayan bir model maliyet raporlarında 0 sayılır. Bu yüzden USD limiti böyle bir modeli ölçmez. Fiyatsız bir modelde USD limitini kaydetmek reddedilmez.

Model Kimliğini Değiştirme​

API proxy'lerin, politikaların veya limitlerin kullandığı bir modelin Model ID değerini değiştirebilirsiniz. Modele işaret eden adlar onunla birlikte taşınır.

  1. Sağlayıcıyı açın, Modeller kartında Yapılandır'a tıklayın ve model satırının "⋯" menüsünden Düzenle'yi seçin.
  2. Model ID değerini değiştirin ve Modeli Kaydet'e tıklayın.
  3. Yapılandır çekmecesinde Kaydet'e tıklayın.

Model kullanımdaysa bir uyarı değişikliğin neyi taşıdığını listeler. Devam etmek için onaylayın. Onayladığınızda Apinizer şu adımları sırayla yapar:

  1. Yeni modeli sağlayıcıya ekler ve sağlayıcıyı yükler. Bu andan itibaren gateway'ler iki kimliği de kabul eder.
  2. Referansları yeni kimliğe taşır: API proxy'lerin AI yönlendirmesi, API proxy'lerdeki politikalar, politika grupları, global politikalar, proxy grupları, bilgi tabanları ve limit planlarının kuralları.
  3. Çalışmakta olanları yeniden yükler. Yüklenmemiş değişikliği olan proxy veya grup yüklenmez.
  4. Eski modeli çağırabilecek hiçbir şey kalmadıysa eski modeli kaldırır.

Uyarı ayrıca şunları listeler:

  • Yüklenmemiş değişikliği olan yerler.
  • model metnini eski kimlikle karşılaştıran koşullar.
  • Bilgi tabanları.
  • Limit planları: çalışan limit penceresi yeniden başlayabilir.
  • Modeli hedefleyen limit atamaları. Bunlar taşınmaz. Atamaları sonlandırın ve yeni model için yenilerini oluşturun.
  • Model kimliğini, bir ortamda bu modeli gösterebilen bir değişkenden (${...}, #{...}) alan yerler. Bunlar değişmez. Bir değer bu modeli gerektirdikçe eski model kalır. Değişkenin her ortamdaki değerini kontrol edin.

Eski Modelin Korunduğu Durumlar​

Apinizer aşağıdaki durumlarda eski modeli korur ve nedeni bir uyarıda adıyla belirtir:

  • Bir API proxy veya proxy grubunun yüklenmemiş değişikliği var. Sahibi yükleyene kadar eski kimlikle çalışır. Yüklemeden sonra değişikliği yineleyin.
  • Bir limit ataması modeli hedefler. Atamanın hedefi değişemez. Atamayı sonlandırın ve yeni model için bir atama oluşturun.
  • Başka bir sağlayıcının girdisinin kendi modeli yoktur. Girdi kimliğini taşınacak bir hedeften alır. Girdiyi elle değiştirin.
  • Bir değişkenin değeri eski modeli gerektiriyor. Sağlayıcıdaki bir yer model kimliğini bir değişkenden alır. Apinizer değişkeni her ortamda çözer ve değeri olmayan ortamı atlar. Eski model iki durumda kalır: en az bir ortamda değer eski modele ulaşır ve eski model kaldırılınca hiçbir modele ulaşmaz, ya da hiçbir ortam bir değer bilmez. İstek değeri #{...} bilinmeyen sayılır. Apinizer yeri adıyla belirtir. Değişkenin değerini her ortamda kontrol edin, sonra eski modeli listeden silin.
  • Eski modeli gerektirmeyen değişken değişikliği durdurmaz. Başka bir modeli gösteren değişken durdurmaz. Yeni modele ulaşan temel adlı bir değişken, örneğin w değeri ile w:new modeli, de durdurmaz. Apinizer değişken kullanan referansları yeniden yazmaz. Apinizer sonuçta değişken değerlerini yazdırmaz.
  • Bir yükleme başarısız oldu. Proxy, grup veya sağlayıcı eski kimlikle çalışır. Yeniden yükleyin.

Nedeni çözdükten sonra aynı değişikliği yineleyin. Yineleme güvenlidir ve kalan işi bitirir.

Diğer Kurallar​

  • Tek kayıtta iki model. Bir modelin, kimliği de değişen başka bir modelin kimliğini aldığı kayıt reddedilir, örneğin iki modelin kimlik değiştirmesi. Modelleri tek tek değiştirin.
  • Zaten var olan yeni kimlik. Yeni kimlik sağlayıcıda zaten bir modelse, o modelin erişim listesi eski modelin erişim listesiyle aynı olmalıdır. Kapalı bir erişim listesi boş sayılır. Listeler farklıysa Apinizer hiçbir şey yazmaz. Erişim listelerini aynı yapın ya da yeni bir model kimliği kullanın.
  • Ortamlar. Erişilebilir gateway'i olmayan ve modeli çalıştırmayan bir ortam değişikliği durdurmaz. Ortam Deployment Sonuçları ekranında başarısız görünür.
  • İzinler. Değişikliğin dokunduğu her varlık için izniniz olmalıdır. Bu izin varlığı düzenlemeyi, çalışmakta olan proxy ve grupları yüklemeyi, limit planlarını ve atamalarını yönetmeyi kapsar. Bir varlık için izniniz yoksa Apinizer hiçbir şey yazmaz ve varlıkları adıyla belirtir.
  • İstemcinin model metnindeki koşullar. Apinizer bunları değiştirmez. Eski kimliği göndermeye devam eden istemci koşullarına uymaya devam eder ve yeni kimliğe ulaşır. İsterseniz koşulları güncelleyin.
  • Bilgi tabanları. Değişiklik, bilgi tabanının adını verdiği model kimliğini günceller. Kayıtlı vektörler yeniden hesaplanmaz. Embedding modelinin kendisi değişiyorsa bilgi tabanını yeniden indeksleyin.

Aynı değişikliği Yönetim API'si ile de yapabilirsiniz. Bkz. Change a Model ID of an LLM Provider.

Karar Veren Modeller ve Küçük Ollama Modelleri​

AI yönlendirmesinin sınıflandırıcısında ve koruma politikalarının LLM hakeminde kullanabileceğiniz modeller aşağıdadır. Bu modeller hazır gelmez. Model kimliklerini sağlayıcının Modeller bölümüne ekleyin:

SağlayıcıModelNot
TypeSafe Jevjev-latestYalnız karar veren model. Bağlam penceresi ve fiyat yayımlanmadığından boştur. İsterseniz model panelinden doldurabilirsiniz. Bkz. Karar Veren Sağlayıcılar.
TEI Classifier (Self-Hosted)meta-llama/Prompt-Guard-86MYalnız karar veren koruma sınıflandırıcısı. En çok 512 girdi token'ı alır. Kapılı model: aşağıdaki nota bakın.
TEI Classifier (Self-Hosted)protectai/deberta-v3-base-prompt-injection-v2 (DeBERTa v3 Prompt Injection v2 (TEI))Yalnız karar veren koruma sınıflandırıcısı. Etiketler SAFE ve INJECTION. En çok 512 girdi token'ı alır. Apache-2.0 lisanslıdır.
Ollamaqwen2.5:1.5b-instruct, llama3.2:3b, granite3.3:2b, llama-guard3:1bHer istekten önce çalışacak kadar hızlı küçük yerel modeller. Standart model davranışıyla kullanın.
Ollamaqwen3:8bReasoning yeteneği olan model. Reasoning model davranışıyla kullanın veya düşünmeyi kapatarak Standart davranışta tutun.
Prompt Guard 86M kapılı bir modeldir

Hugging Face meta-llama/Prompt-Guard-86M modelini kapılı tutar. TEI sunucusu modeli indirmek için bir Hugging Face token'ı ve kabul edilmiş Llama lisansı ister. Bunlar yoksa protectai/deberta-v3-base-prompt-injection-v2 modelini kullanın. Bu model açıktır. LLM hakemi olarak kullanırken tehlikeli etiketi INJECTION yapın.

Model Listesi ve Kimlik Doğrulama Paneli​

Sağlayıcı sayfasındaki Modeller kartı her modeli tipi, bağlam penceresi, girdi ve çıktı fiyatı, erişim kontrolü durumu ve durumuyla gösterir. Kartın Yapılandır düğmesi listeyi değiştirebileceğiniz bir çekmece açar. Modeller tablo hücrelerinde değil, sağdan açılan bir panelde eklenir ve düzenlenir:

  • Ekle iki sekmeli model ekleme panelini açar. Uç Nokta URL doldurulana kadar pasif kalır. Satır sonundaki "⋯" menüsünde Düzenle (o satırın değerleriyle dolu Modeli Düzenle panelini açar), Etkinleştir ya da Devre Dışı Bırak (bkz. Model Durumu) ve modeli kaldıran Sil bulunur.
  • Panelde model kimliği (Model ID, Görünen Ad), Model Tipi, kapasite (Bağlam Penceresi, Maks. Çıktı Token), Maliyet yönetimi altındaki fiyat alanları ve Erişim Kontrolü kartı bulunur. Fiyatı olmayan model Maliyet yönetimi başlığında fiyat yok rozeti gösterir.
  • Modeli Kaydet paneldeki değerleri listeye yazar. Değişiklikler Yapılandır çekmecesinde Kaydet'e basıp açılan pencereyi onaylayana kadar kalıcı olmaz (bkz. Sağlayıcı Sayfası).

Sağlayıcının kimlik bilgileri ayrı bir panelde değildir. Bağlantı kartının Kimlik Doğrulama kısmında kimlik bilgisi tipi, API anahtarı veya gizli anahtar ve diğer kimlik bilgisi alanları bulunur (bkz. Kimlik Bilgileri). Bunları kartın Yapılandır düğmesiyle değiştirirsiniz; Kaydet kalıcı yapar.

Hazır Şablonlar​

Kurulumla birlikte beş hazır sağlayıcı şablonu gelir: OpenAI Provider, Voyage AI Provider, DeepSeek Provider, Moonshot (Kimi) Provider ve Zhipu (GLM) Provider. Bunlar uç nokta adresi ve varsayılan model bilgisi doldurulmuş, ancak API anahtarı boş iskeletlerdir. Kuruluma ait oldukları için admin menüsündeki listede görünürler — proje modundaki liste yalnız projenin kendi bağlantılarını gösterir.

Kullanım şekli şablonu klonlayıp kendi API anahtarınızı girmektir; şablonun kendisi kurulum tarafından yönetilir ve yükseltmelerde tazelenebilir.

not

Bu şablonların varsayılan modeli embedding üretimine dönüktür (örneğin OpenAI şablonunda text-embedding-3-small) çünkü RAG ve semantik önbellek için en sık ihtiyaç duyulan başlangıç budur. Şablon yalnız embedding'e kilitli değildir — klonladıktan sonra varsayılan modeli değiştirerek aynı sağlayıcıyı sohbet/tamamlama için de kullanabilirsiniz.

Bağlantı Oluşturma​

Bağlantılar Sayfasına Gidin

Apinizer arayüzünde AI Gateway → Modeller sayfasına gidin. Liste bir tablodur: Sağlayıcı (ad ve uç nokta), Tip, Modeller (aktif model sayısı / tüm modeller), Sağlık (Sağlıklı / Erişilemiyor / Bilinmiyor), Durum (Aktif ya da Pasif) ve admin menüsünde Proje sütunları bulunur. Arama kutusu (model adını da eşler) ile sağlayıcı tipi ve durum filtreleri listeyi daraltır; silgi düğmesi filtreleri temizler. Sağlayıcı sayfasını açmak için satıra tıklayın. Satırın "⋯" menüsünde Görüntüle, Kopyala, Dışa Aktar ve Sil bulunur.

Yeni'ye Tıklayın

Sağlayıcı formunu açmak için Yeni düğmesine tıklayın. Üst çubuktaki Veriyi Aktar düğmesi, daha önce dışa aktardığınız bir sağlayıcıyı içe aktarır.

Sağlayıcı Türünü Seçin

Açılan Sağlayıcı seçin penceresinden sağlayıcıyı seçin — bkz. Sağlayıcı Tipini Seçme. Listede yoksa Özel Sağlayıcı'yı kullanın.

Dağıtım türü otomatik doldurulur:

  • Sağlayıcı vLLM, Ollama, TEI ya da Özel OpenAI-Uyumlu ise → Şirket içi olarak ayarlanır
  • Özel Sağlayıcı'yı seçerseniz → Diğer olarak ayarlanır
  • Diğer tüm sağlayıcılarda (OpenAI, Anthropic, Azure, Vertex, Bedrock ve tüm yeni bulut sağlayıcılar dahil) → Bulut olarak ayarlanır
Kimlik Bilgilerini Girin

Bağlantı bölümünün Kimlik Doğrulama kısmında kimlik bilgisini kimin sağladığını ve kimlik bilgisi tipini seçin (bkz. Kimlik Bilgileri). API anahtarını veya gizliliği oraya yapıştırın. Apinizer kimlik bilgilerini şifreler ve hiçbir zaman günlüğe kaydolmaz.

Örnekler:

  • OpenAI: sk-... anahtarınızı yapıştırın
  • Anthropic: sk-ant-... anahtarınızı yapıştırın
  • Azure: Uç nokta URL'si ve anahtarı yapıştırın
  • vLLM/Ollama: Temel URL'yi yapıştırın (örn. http://localhost:8000)
Bağlantıyı Test Edin (isteğe bağlı ama önerilir)

Sayfanın üstündeki Bağlantıyı Test Et düğmesine tıklayın. Uç Nokta URL doldurulur doldurulmaz düğme aktif olur. Açılan Bağlantıyı test et çekmecesinde iki test vardır: Erişilebilirlik ve Çıkarım.

Testin geçeceği ortamı sayfanın üstündeki ya da çekmecedeki açılır menüden seçin. Ortam seçiliyse test, Yönetim Konsolu'ndan değil, seçtiğiniz ortama dağıtılmış Worker üzerinden çalışır; böylece bağlantının canlıda kullanacağı gerçek ağ yolunu (firewall kuralları, egress kısıtlamaları, proxy'ler) test eder ve uç nokta veya kimlik bilgilerindeki ${env.X} değişkenlerini gerçek bir istekteki gibi çözümler. Ortam seçilmediyse isteği Manager'ın kendisi gönderir ve ${env.X} değişkenleri çözülmez.

  • Erişilebilirlik, kaydettiğiniz kimlik bilgileriyle sağlayıcının model listesi uç noktasına tek bir istek gönderir; 2xx yanıt başarı sayılır. Adresin erişilebilir olduğunu, TLS'in çalıştığını ve kimlik bilgisinin kabul edildiğini gösterir; isteklerin doğru biçimde kurulduğunu göstermez.
  • Çıkarım, açık modellerden birine örnek bir istemle gerçek bir sohbet çağrısı gönderir; zaman aşımını ve azami çıktı boyutunu ayarlayabilirsiniz. Adapter ailesini, sohbet yolunu ve model kimliğini birlikte doğrulamak için kullanın. Çağrıyı akış olarak da deneyebilirsiniz. Sonuç, modelin kabul edilip edilmediğini, token kullanımının okunup okunmadığını ve maliyetin hesaplanıp hesaplanmadığını gösterir.
not

AWS Bedrock ve Google Vertex AI bağlantıları henüz Bağlantıyı Test Et özelliğini desteklemiyor — bu sağlayıcıların imzalama şemaları (AWS SigV4, Google OAuth2) test kontrolüne henüz entegre edilmedi. Bu bağlantıları test etmeden kaydedebilirsiniz; bu durum sohbet veya embedding trafiğini etkilemez, yalnızca kayıt-öncesi test ve Raporlar ve Analitik sayfasındaki periyodik durum göstergesini etkiler.

Kaydet

Kaydet ve Yükle'ye tıklayın. Bağlantı şifreli olarak depolanır ve değişiklik yüklenir. Kimlik bilgileri hiçbir zaman loglarda veya dışarı aktarımlarında görünmez.

LLM Sağlayıcı formu — Genel Bilgiler, Bağlantı, Modeller ve Gelişmiş

Etkin Uç Yolları​

Bir bağlantıyı sağlayıcı tipi seçerek oluşturduğunuzda, tipin wire protokolü ve uç yolları (örn. sohbet tamamlama /chat/completions ya da /messages, embedding /embeddings, transkripsiyon /audio/transcriptions, seslendirme /audio/speech, görsel üretim /images/generations, Responses /responses — hangisinin kullanılacağı seçtiğiniz wire protokole göre değişir) bağlantıya kopyalanır. Bağlantı formunun Gelişmiş bölümündeki Yolları düzenle düğmesiyle bu değerleri görüp gerektiğinde yalnızca bu bağlantı için değiştirebilirsiniz — değişiklik sağlayıcı tipine yazılmaz.

Uç Nokta URL alanına yalnızca temel adresi girersiniz (örn. https://api.openai.com/v1) — istek tipine göre yukarıdaki uç yollarından biri bu temel adresin sonuna otomatik olarak eklenir; uç yolunun kendisini bu alana ayrıca yazmanız gerekmez.

Sağlayıcı tipinin yolları sabittir: bir yolu tip için kalıcı biçimde değiştiremezsiniz, yalnızca kendi bağlantınızdaki kopyayı düzenleyebilirsiniz. Wire protokolü ve yollar, siz ayarlamadıkça tipin kendi değerleridir.

Listede görünmeyen bir yol, tipin o modalite için bir şey söylemediği anlamına gelir; o durumda sağlayıcı tipinin varsayılanı uygulanır. Kurulumdan önce oluşturulmuş eski bağlantılarda bölüm hiç görünmez ve davranış değişmemiştir.

Uç Nokta URL'e gömülü sorgu dizesi

Uç Nokta URL alanına bir sorgu dizesi eklerseniz (örn. ?resource=xyz), bu sorgu dizesi nihai istek adresinde uç yolundan sonraya taşınır (örn. https://host/chat/completions?resource=xyz) — aradan geçip adresi bozmaz.

Yollarda değişken kullanma​

Uç yolları, uç adresinin (endpoint) kendisiyle aynı değişken çözümlemesini destekler: ortam değişkeni için ${env.degiskenAdi}, bağlam değişkeni için #{degiskenAdi}. Çözümleme istek anında yapılır, kayıt anında değil — yani bir kez /api/${env.apiSurum}/chat yazarsınız ve aynı tanım geliştirme ortamında v1, üretimde v2 yoluna çıkabilir.

Nihai adres endpoint + yol biçiminde kurulur ve iki parça da çözümlemeden geçer. Değişken tanımlı değilse metin olduğu gibi bırakılır (istek hata vermez, yalnızca beklenen yola gitmez) — bu, uç adresiyle birebir aynı davranıştır.

API Versiyonu Alanı​

API Versiyonu alanı sağlayıcı tipine göre farklı amaçlarla kullanılır:

  • Anthropic bağlantılarında bu değer istek URL'ine hiç eklenmez; bunun yerine her istekte anthropic-version başlığı olarak gönderilir.
  • Azure OpenAI bağlantılarında hem Bağlantıyı Test Et sorgusunda (/models?api-version=...) hem de gerçek sohbet/embedding istek adresinin sonuna eklenen ?api-version=... sorgu parametresinde kullanılır. Nihai adreste zaten bir api-version parametresi varsa (örn. Uç Nokta URL'e elle eklenmişse) ikinci kez eklenmez.
  • Diğer sağlayıcı tiplerinde bu alanın gerçek istek URL'ine bir etkisi yoktur.
  • AWS Bedrock ve Google Vertex AI'da adres tamamen sağlayıcıya özel kodla hesaplandığı için bu birleşim geçerli değildir.

Birleştirilmiş Adres Önizlemesi​

Etkin Uç Yolları bölümünün altında, sohbet tamamlama ve embedding için gerçekte çağrılacak tam adresi salt-okunur olarak gösteren bir önizleme bulunur — Uç Nokta URL ile çözümlenen uç yolunun birleşimidir ve bir çağrının gerçekte gönderileceği adrestir. ${env.X} biçimindeki ortam değişkenleri burada ham gösterilir, çözümlenmez.

not

AWS Bedrock ve Google Vertex AI bağlantılarında bu önizleme yerine, adresin bu sağlayıcılarda tamamen sağlayıcıya özel kodla (AWS SigV4 imzalama / Google OAuth2 + proje ve bölge bilgisi) hesaplandığını belirten bir bilgi notu görünür — basit bir uç nokta + yol birleşimiyle önizlenemez.

Bağlantıları Yönlendirmede Kullanma​

Oluşturulduktan sonra, bir sağlayıcı bağlantısı API Proxy yönlendirmesi için kullanılabilir. Bir API proxy'si oluşturduğunuzda, modelleri atayıp hangi bağlantıyı kullanacağınızı seçersiniz:

# Örnek: "gpt-4o" isteklerini OpenAI bağlantısına yönlendir
Proxy: "sohbet-apim"
Modeller:
- ad: "gpt-4o"
sağlayıcı: "OpenAI" # kaydedilmiş bağlantıya referans
- ad: "gpt-4-turbo"
sağlayıcı: "OpenAI"
- ad: "claude-3-sonnet"
sağlayıcı: "Anthropic" # farklı bağlantı

LLM sağlayıcı bağlantıları APIops REST API ile de yönetilebilir; bkz. API Referansı: LLM Providers.

Bağlantıları İzleme​

  • Dağıtım Başına Kullanım — Rapor → Metrikler (AI görünümü) ekranının Kullanım Raporları tab'ındaki Dağıtım Türüne Göre bölümünde bulut ve şirket içi bağlantılar tarafından tüketilen token sayısını görün
  • Maliyet Atfı — Her bağlantı trafik kayıtlarında dağıtım türünü günlüğe kaydeder ve doğru maliyet tahsisi sağlar
  • Yük Devretme ve Yük Dengeleme — Aynı sağlayıcıya yapılan çoklu bağlantılar gereksizlik için yapılandırılabilir (gelişmiş)

Sağlayıcı Sayfası​

Bir sağlayıcıyı açtığınızda sayfasında dört kart görürsünüz: Genel Bilgiler, Bağlantı, Modeller ve Gelişmiş. AI geliştirmeyi yönetebilen kullanıcılar her kartta bir Yapılandır düğmesi görür; düğme kartın bölümünü bir çekmecede açar. Çekmecedeki Kaydet, sağlayıcının nerede kullanıldığını (LLM Gateway'ler, API proxy'ler, proxy grupları, politika grupları ve global politikalar) ve ulaştığı gateway'leri listeleyen bir pencere açar; Onayla değişikliği tek adımda kaydeder ve yükler. Sağlayıcı pasifse pencere, değişikliklerin kaydedildiğini ve sağlayıcının pasif kaldığını söyler.

Sayfanın üstündeki ortam seçici ve Bağlantıyı Test Et düğmesi yukarıda anlatılan bağlantı testini çalıştırır. "⋯" menüsü şunları içerir:

GrupÖğe
DurumEtkinleştir ya da Devre Dışı Bırak
AktarımDışa Aktar
EtkiKullanıldığı yerler
GeçmişDenetim ve Geri Yükleme (yalnız görüntüleme yetkisi olanlar Denetim görür)
En alttaSağlayıcıyı Sil

Etkinleştir ve Devre Dışı Bırak​

Bir sağlayıcı Aktif ya da Pasif'tir; liste bunu Durum sütununda gösterir. Yeni sağlayıcı aktiftir.

  • Etkinleştir sağlayıcıyı gateway'lere gönderir. Onu kullanan LLM Gateway'ler ve politikalar ona yeniden istek gönderebilir.
  • Devre Dışı Bırak sağlayıcıyı tüm gateway'lerden hemen kaldırır. Ona yönlenen istekler hata alır ya da yedek sağlayıcıya gider. Ayarları ve modelleri kalır; Etkinleştir geri getirir. Onay için sağlayıcının adını yazarsınız.

Onaylamadan önce pencere, sağlayıcıyı kullanan her yeri ve oradaki değişikliği, ayrıca değişikliğin ulaştığı gateway'leri listeler. Şu an yürürlükte olmayan yerler (örneğin deploy edilmemiş bir LLM Gateway) işaretlenir, çünkü onlar için bir şey değişmez.

Bağlantı Silme​

Kullanımda olan bir LLM sağlayıcı bağlantısı silinemez. Silme isteği, bağlantıya işaret eden bir referans varsa reddedilir ve hata mesajı referansın nerede olduğunu adıyla listeler.

Bunun nedeni, sağlayıcının başvuru-tipli bir varlık olmasıdır: proxy ya da politika belgesine kopyalanmaz, çalışma anında kimliğiyle çözülür. Guard olmasaydı silme işlemi geride kırık referanslar bırakır ve canlı geçit bir sonraki istekte hata verirdi.

Kontrol dört yerde birden yapılır — API Proxy, Proxy Grubu, Politika Grubu ve bağımsız (global) politikalar — ve şu referans yollarını kapsar:

  • API Proxy'nin AI yönlendirmesi: birincil sağlayıcı, yük devretme zinciri, koşullu rotalar, birincil havuz ve semantik gömme sağlayıcısı
  • Semantic Cache ve RAG Injection politikalarının gömme (embedding) sağlayıcısı
  • Prompt Guard ve Topic Guard politikalarının dış guardrail sağlayıcısı

Bir sağlayıcıdaki tek bir modeli silme kuralları için bkz. Model Silme.

Bağlantıyı silmek için önce bu referansları kaldırın ya da başka bir sağlayıcıya yönlendirin. Aynı kural APIops üzerinden yapılan silme için de geçerlidir: DELETE /apiops/projects/{projectName}/llm-providers/{providerName}/ çağrısı kullanımda olan bir bağlantıda 400 Bad Request döner.

Sağlayıcı sayfasındaki "⋯" menüsünün Kullanıldığı yerler öğesi, sağlayıcının adını taşıyan LLM Gateway'leri, API proxy'leri ve diğer kayıtları listeler; silmeden önce neyin silmeyi engellediğini görebilirsiniz.

Sorun Giderme​

Bağlantı Testi Başarısız Oldu

  • Testi bir ortamın Worker'ı üzerinden çalıştırmak için ortam seçin. Ortam seçilmezse isteği Manager gönderir ve ${env.X} değişkenleri çözülmez
  • API anahtarının veya uç nokta URL'sinin doğru olduğunu doğrulayın
  • Kimlik bilgilerinin gerekli izinlere sahip olduğunu kontrol edin
  • Sağlayıcı hizmetinin seçilen ortamın ağından erişilebildiğinden emin olun (yalnızca Yönetim Konsolu'ndan değil)
  • AWS Bedrock ve Google Vertex AI bağlantıları henüz Bağlantıyı Test Et özelliğini desteklemiyor — test etmeden kaydedin

Kimlik Bilgileri Kaydedilmiyor

  • Yönetici izinlerine sahip olduğunuzdan emin olun
  • Tarayıcı önbelleğini temizleyin ve tekrar deneyin

Sonraki Adımlar​