LLM Sağlayıcıları ve Bağlantılar
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.
Bağlantıların kimlik bilgileri Apinizer'ın genel kimlik bilgisi sistemi üzerinden yönetilir; detaylar için Kimlik Bilgileri sayfasına bakın.
Ekran iki yerden açılır ve üç tab'ın (Sağlayıcılar, Model Kataloğu, Tanımlar) tamamı Bağlantı (Connections) ekranlarıyla aynı kapsam kuralını izler:
- Proje menüsü (AI Gateway → LLM Sağlayıcılar): her tab yalnız aktif projede oluşturulan kayıtları listeler.
- Admin menüsü: tümünü listeler — hazır/paylaşılan kayıtlar ve bütün projelerin kayıtları.
Kapsam yalnız listeler için geçerlidir. Seçim listeleri — AI Proxy politikasında sağlayıcı seçmek, sağlayıcı formunda katalog girdisi seçmek, Katalogdan Klonla — projenin kendi kayıtlarının yanında paylaşılan/hazır kayıtları da sunmaya devam eder; Apinizer'ın diğer bağlantı seçimleriyle birebir aynı davranış.
Sayfa Yapısı
LLM Sağlayıcılar ekranı iki tab'dan oluşur:
- Sağlayıcılar — bu sayfanın konusu olan, kimlik bilgileriyle yapılandırılmış bağlantı listesi.
- Model Kataloğu — sağlayıcılara ait modelleri ve birim fiyatları listeler; bkz. Model Kataloğu ve Fiyatlandırma.
Sağlayıcı tiplerinin kataloğu (ad, kod, varsayılan uç nokta bilgileri, varsayılan kimlik doğrulama şeması) artık ürünle gelen, salt-okunur bir seed veridir: ayrı bir tab'da görüntülenmez ve üzerinde oluşturma, düzenleme ya da silme aksiyonu yoktur. Bir bağlantı oluştururken bu katalogdan seçim yaparsınız (bkz. Sağlayıcı Tipini Seçme); katalogda karşılığı olmayan bir sağlayıcı için Özel Sağlayıcı'yı kullanırsınız. Kavramın detayı için Model Kataloğu ve Fiyatlandırma sayfasındaki Sağlayıcı Tipi Kataloğu bölümüne bakın.
Sağlayıcı Tipini Seçme
LLM Sağlayıcı Ekle'ye tıkladığınızda açılan Sağlayıcı seçin penceresi, sağlayıcıları Yönetilen bulut ve Self-hosted olarak iki grupta listeler; arama kutusuyla filtreleyebilirsiniz. Listeden bir satır seçtiğinizde o satırın uç noktası, kimlik doğrulama şeması ve istek yolları bağlantı formuna kopyalanır — bağlantının kendi formu yine de 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ı seçeneğine geçin.
Özel Sağlayıcı
Özel sağlayıcıda sağlayıcı tipi Diğer olarak kaydedilir ve katalogdan gelen bir varsayılan yoktur; form Bearer token kimlik doğrulaması, Authorization başlığı, Bulut dağıtım tipi ve /chat/completions sohbet tamamlama yoluyla açılır, gerisini siz doldurursunuz:
- Adapter ailesi — sağlayıcının gerçekte konuştuğu tel protokolü seçersiniz: OpenAI-uyumlu, Anthropic, Gemini, Bedrock ya da vLLM. 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 — bkz. API Referansı: LLM Providers. Sağlayıcı tipi kataloğunun kendisi (hazır sağlayıcı tanımları) artık ayrı bir dışa/içe aktarma tipine sahip değildir; ürünle birlikte gelir ve kurulum başına sabittir.
Sağlayıcı Türleri
Apinizer AI Gateway aşağıdaki sağlayıcıları destekler. Kod kolonu, Sağlayıcı Tipi Kataloğu'ndaki code alanının değeridir — APIops'ta bu değerle karşılaşırsınız. 2026.09.1'deki LLM katalog tazelemesi (APNZ-6550) 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ı | Kod | Dağıtım (varsayılan) | Notlar |
|---|---|---|---|
| OpenAI | openai | Bulut | GPT-4o, GPT-4 Turbo, GPT-3.5, vb. |
| Anthropic | anthropic | Bulut | Claude modelleri |
| Azure OpenAI | azure-openai | Bulut | Azure'da barındırılan OpenAI modelleri |
| Google Vertex AI | vertex | Bulut | PaLM 2, Gemini |
| Google AI Studio | google-ai-studio | Bulut | Doğrudan Gemini API yüzeyi — Vertex'ten ayrı, GCP projesi ya da OAuth2 gerektirmez |
| AWS Bedrock | bedrock | Bulut | Claude, Llama, Mistral, Titan, Nova |
| Cohere | cohere | Bulut | Command modelleri |
| Mistral | mistral | Bulut | Mistral/Mixtral modelleri |
| DeepSeek | deepseek | Bulut | DeepSeek-V3/R1 |
| Groq | groq | Bulut | LPU donanımıyla hızlı çıkarım |
| Moonshot (Kimi) | moonshot | Bulut | Kimi modelleri |
| Zhipu (GLM) | zhipu | Bulut | GLM modelleri |
| Qwen (DashScope) | qwen-dashscope | Bulut | Alibaba Qwen modelleri |
| xAI | xai | Bulut | Grok modelleri |
| Together AI | together | Bulut | Açık ağırlıklı model agregatörü |
| Fireworks AI | fireworks | Bulut | Açık ağırlıklı model çıkarımı |
| Cerebras | cerebras | Bulut | Cerebras Inference |
| Hugging Face | huggingface | Bulut | Inference Providers router |
| OpenRouter | openrouter | Bulut | Çoklu sağlayıcı agregatörü — model kimlikleri vendor/model biçimindedir |
| Perplexity | perplexity | Bulut | Perplexity Router API |
| NVIDIA NIM | nvidia-nim | Bulut | NVIDIA barındırmalı yüzey |
| Voyage AI | voyage | Bulut | Yalnızca embedding sağlayıcısı |
| vLLM | vllm | Şirket içi | Şirket içi çıkarım motoru |
| Ollama | ollama | Şirket içi | Yerel LLM çıkarımı |
| Özel OpenAI-Uyumlu | custom-openai-compat | Şirket içi | OpenAI-uyumlu herhangi bir uç nokta |
Dağıtım Türü
Her bağlantı, LLM'nin bulutta mı yoksa şirket içinde mi çalışıp çalışmadığını bildirir:
- 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, özel OpenAI-uyumlu uç nokta)
Dağıtım türü sağlayıcı türüne göre otomatik doldurulur, ancak gerekirse geçersiz kılabilirsiniz (örneğin, bulut sağlayıcıda barındırılan özel bir vLLM örneğini kullanıyorsanız).
Kimlik Bilgileri
Tüm API anahtarları ve sırlar şifreli olarak saklanır ve hiçbir zaman günlüğe yazılmaz. Bağlantılar, API Proxy erişimini güvence altına almak için kullanılan sistemle aynı kimlik bilgisi sistemi üzerinden yönetilir.
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ğlar | Apinizer 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 kimlik bilgisine 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ı Konumu | Biçim | Notlar |
|---|---|---|
| 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 Tipi | Altta yatan Kimlik Doğrulama Şeması | API Anahtarı Konumu |
|---|---|---|
| Bearer token | BEARER | — |
| Header içinde API anahtarı | API_KEY_HEADER ya da CUSTOM | Header |
| Query parametresi olarak API anahtarı | API_KEY_HEADER ya da CUSTOM | Query |
| Basic — kullanıcı adı + parola | BASIC | — |
| AWS Signature V4 | AWS_SIGV4 | — |
| Google servis hesabı (JSON) | OAUTH2 | — |
| Kimlik doğrulama yok | NONE | — |
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 katalogun 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 yanıtları her zaman 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.
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 completions | Sohbet akışı (streaming) | Embedding | Ses / 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ı) | — | ✅ | ❌ |
| 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ı | Anthropic | Google Vertex AI (Gemini) |
|---|---|---|
model | gövdede kalır | gövdede yok — URL path'inde taşınır |
| System / developer mesajı | üst-seviye system alanına eşlenir | systemInstruction'a eşlenir |
max_tokens / max_completion_tokens | zorunlu — istemci göndermezse model kataloğunun maksimum çıktı değerine, o da yoksa 4096'ya düşer | isteğe bağlı — yalnızca istemci gönderdiyse ayarlanır |
tools[].function | tools[].input_schema'ya eşlenir | functionDeclarations'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) |
temperature | istemci 1.0'dan yüksek gönderirse 1.0'a sabitlenir (clamp) | olduğu gibi iletilir (0–2 aralığı) |
stop | stop_sequences'a eşlenir | stopSequences'a eşlenir (yalnız ilk 5 eleman) |
user | metadata.user_id'ye eşlenir | düşürülür |
n, presence_penalty, frequency_penalty, logit_bias, logprobs, seed, response_format, parallel_tool_calls | düşürülür | düşürülür |
| Metin-dışı mesaj içeriği (görsel, ses, …) | düşürülür — bugün yalnız metin destekleniyor | düşü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 Kotaları.
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.
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 — istemci tarafı 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 modelleri döner, katalogun tamamını değil. Detaylar için bkz. AI Gateway Genel Bakış → Model Keşfi.
Yönetim tarafı keşif — Modelleri Keşfet düğmesi
Bağlantı formundaki Modeller bölümünde yer alan Modelleri Keşfet düğmesi, 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 kopyalamaya gerek kalmaz; yazım hatasından doğan "model bulunamadı" hataları da böylece önlenir.
Aynı düğme bağlantının görüntüleme ekranındaki Modeller bölümünde de bulunur; orada sonuç salt okunur gösterilir (seçim ve ekleme yoktur). Görüntüleme yetkisi (AI Development → View) keşif için yeterlidir; keşfedilen bir modeli bağlantıya eklemek için sonuç penceresindeki Düzenleme Formunu Aç düğmesiyle forma geçin. Keşif başarısız olduğunda pencere 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:
- Formun üstündeki açılır menüden bir ortam seçin — Bağlantıyı Test Et ile aynı seçim kullanılır. Kurumsal kurulumlarda sağlayıcıya çoğu zaman yalnızca Worker ağı eriştiği için bu seçim önemlidir.
- Modelleri Keşfet düğmesine bası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.
- Sağdan açılan panelde modeller listelenir. Bağlantıda zaten kayıtlı olanlar
Zaten eklietiketiyle işaretlenir ve seçilemez; geri kalanlarYenigörünür. - Eklemek istediklerinizi işaretleyip Seçilenleri Ekle deyin. Modeller form üzerindeki tabloya eklenir — kaydedilmez. Kalıcı olması için bağlantıyı Kaydet ile kaydetmeniz gerekir.
Panel ayrıca kayıp modelleri de bildirir: bağlantı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.
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 için üç yol vardır: kaydettiğinizde model kataloğundan otomatik tamamlanmalarını beklemek (aşağıya bakın), satırın düzenle (kalem) aksiyonuyla açılan model paneli üzerinden elle doldurmak ya da Katalogdan Klonla ile katalog değerlerini getirmek.
Model tipi ve fiyatların katalogdan otomatik doldurulması
Bağlantıyı Kaydet dediğinizde Apinizer, Desteklenen Modeller tablosundaki her satırın boş kalan model tipi (modality) ve fiyat alanlarını ürünle gelen model kataloğundan tamamlamayı dener. Eşleştirme sağlayıcı + model kimliği üzerinden yapılır; yalnızca model kimliğine bakılmaz, çünkü gpt-4o gibi kimlikler sağlayıcılar arasında ortaktır ve bir sağlayıcının fiyatı diğerinin bağlantısına sızardı.
Bu tamamlama üç kuralla çalışır:
- Yalnızca boş alanlar dolar. Elle girdiğiniz ya da keşiften gelen bir değer asla ezilmez.
- Katalogda karşılığı olmayan özel modeller olduğu gibi kalır. Apinizer bunlara varsayılan bir tip atamaz: yanlış sınıflandırma, model tipi doğrulamasını ve maliyet hesabını sessizce bozardı. Bu modeller AI Proxy listesinde Belirtilmemiş filtresiyle bulunur; bu filtre sağlayıcı bazında değerlendirilir: bir bağlantıda sınıflandırılmış, diğerinde boş bırakılmış bir model kimliği yalnızca boş olduğu bağlantı için belirtilmemiş sayılır.
- Kapsam korunur. Yalnızca ürünle gelen, yönetici tarafından paylaşılmış ya da kendi projenize ait katalog kayıtları kullanılır. Aynı model kimliğini birden fazla kayıt tanımlıyorsa en özgül olanı kazanır — önce kendi projenizin kaydı, sonra yöneticinin paylaştığı kayıt, en son ürünle gelen kayıt — böylece sonuç, kayıtların hangi sırayla okunduğuna bağlı kalmaz.
Hâlihazırda var olan bağlantılar bir kez otomatik doldurulur: 2026.09.2 yükseltmesinde aynı tamamlama, kayıtlı tüm LLM bağlantıları için bir kez çalışır; her sağlayıcıyı açıp yeniden kaydetmeniz gerekmez. Yukarıdaki üç kural aynen geçerlidir ve tekrar çalıştırılması hiçbir şeyi değiştirmez.
Alanı her zaman elle de düzenleyebilirsiniz: satırın kalem simgesiyle model panelini açın ve Model Tipi alanını seçin; alan boş bırakılabilir. Tabloda zaten var olan bir modeli Katalogdan Klonla penceresinden yeniden seçerseniz yeni bir satır açılmaz; mevcut satırın yalnızca boş alanları katalogdan doldurulur.
Model tipi boş kalan bir model, AI Development → AI Proxies listesindeki Model tipi filtresinde hiçbir değerde görünmez ve token kavramı olmayan modellerde (görsel üretim, ses) maliyet 0 USD olarak hesaplanır. Bu yüzden fiyatı bilinmeyen bir model kullanıldığında ağ geçidi günlüklerine model başına bir kez uyarı düşer.
Model Listesini Yönetme
Sağlayıcının düzenleme sayfasında Modeller tablosunun kendisi salt okunurdur — modeller tablo hücrelerinde değil, sağdan açılan bir panelde eklenir ve düzenlenir:
- Model Ekle boş bir model paneli açar; satır sonundaki kalem simgesi aynı paneli o satırın değerleriyle dolu açar.
- Panelde model kimliği (Model ID, Görünen Ad), kapasite (Bağlam Penceresi, Azami Çıktı Token), liste fiyatlandırması (Girdi / Çıktı / Önbellek $/1M) ve iki anahtar bulunur: Gateway'de izinli (kapatıldığında model tüm tüketiciler için engellenir) ve Kullanımdan kaldırıldı (modeli emekliliğe işaretler; mevcut çağrılar geçmeye devam eder).
- Modeli Kaydet paneldeki değerleri tabloya yazar; düzenleme modunda Sil düğmesi satırı kaldırır. Her iki durumda da değişiklikler sayfadaki Kaydet ve Yayınla düğmesine basılana kadar kalıcı olmaz.
- Katalogdan Klonla penceresi zaten eklenmiş satırları artık gizlemez; bunları Ekli işaretiyle listeler. Hem klonlama hem keşif panelleri sağdan açılır ve arama kutusuyla filtrelenebilir.
Salt okunur görüntüleme sayfası aynı tabloyu N izinli sayacı ve İzinli/Engelli ile Aktif/Kullanımdan kaldırıldı durum rozetleriyle gösterir — değişiklik için Sağlayıcıyı Düzenle kullanılır.
Benzer şekilde, düzenleme sayfasındaki Kimlik Doğrulama ve Limitler bölümü de salt okunur bir özettir; Yapılandır düğmesi kimlik doğrulama şeması, API anahtarı/gizli anahtarı, kimlik doğrulama başlığı adı, organizasyon kimliği, sağlayıcı RPM/TPM limitleri ve soğuk başlatma yeniden deneme seçeneğini içeren sağ paneli açar. Paneldeki Kaydet değerleri forma uygular; kalıcılık yine Kaydet ve Yayınla iledir.
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 Model Ekle ile elle 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.
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.
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
Apinizer arayüzünde AI Gateway → LLM Sağlayıcılar sayfasının Sağlayıcılar tab'ına gidin. Sağlayıcı kartları araç çubuğundaki arama kutusu ile sağlayıcı tipi ve durum (Aktif/Pasif) filtreleriyle daraltılabilir; her kart sağlayıcının sağlık durumunu (Sağlıklı / Erişilemiyor / Bilinmiyor), uç noktasını, tipini, durumunu ve izinli model sayısını gösterir.
Sağlayıcı formunu açmak için Ekle düğmesine tıklayın.
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 ya da Özel OpenAI-Uyumlu ise → Şirket içi 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 Doğrulama ve Limitler bölümündeki Yapılandır düğmesine basın — kimlik bilgileri açılan sağ panelde düzenlenir (bkz. Model Listesini Yönetme). 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)
Bulut sağlayıcınızda şirket içi bir örnek varsa (veya tam tersi), Dağıtım Türü açılır menüsünü Bulut veya Şirket içi olarak değiştirin.
Formun üstündeki açılır menüden test edilecek ortamı seçin — ortam seçilmeden Bağlantıyı Test Et düğmesi pasif kalır.
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.
Apinizer, 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.
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'e tıklayın. Bağlantı şifreli olarak depolanır. Kimlik bilgileri hiçbir zaman loglarda veya dışarı aktarımlarında görünmez.
Etkin Uç Yolları
Bir bağlantıyı katalogdan bir sağlayıcı seçerek oluşturduğunuzda, o satırın 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 kataloğa 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ı tipi kataloğu artık salt-okunurdur: bir yolu kalıcı biçimde değiştiremezsiniz, yalnızca kendi bağlantınızdaki kopyayı düzenleyebilirsiniz. Katalogdan yeni bir bağlantı oluşturduğunuzda o bağlantı yine katalogdaki güncel değerle başlar; hâlihazırda var olan bağlantılar kendi kopyalarını korur.
Listede görünmeyen bir yol, katalogun 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 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 katalogda 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-versionbaş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 birapi-versionparametresi 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.
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 — Analitik sayfası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ş)
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ı
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.
Bağlantı kaydının detay ekranındaki Kullanan API Proxy'ler paneli, silme öncesi hangi proxy'lerin bu bağlantıya bağlı olduğunu gösterir.
Sorun Giderme
Bağlantı Testi Başarısız Oldu
- Önce bir ortam seçin — ortam seçilmeden Bağlantıyı Test Et düğmesi pasiftir; test her zaman seçilen ortamın Worker'ı üzerinden çalışır, Yönetim Konsolu üzerinden değil
- 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
Yanlış Dağıtım Türü Seçildi
- Bağlantıyı düzenleyin ve Dağıtım Türü'nü doğru değere değiştirin
- Dağıtım türü değişiklikleri geriye dönük uygulanır (ileri yönelik loglar güncellenmiş türü gösterecektir)
Sonraki Adımlar
Sağlayıcıya ait modelleri ve birim fiyatları görün
Birincil ve yedek hedefleri tanımlayın
Sağlayıcı başına veya model başına kullanım sınırlarını ayarlayın
Bağlantı kullanımını ve maliyetini görüntüleyin
AI Gateway modülüne genel bakış