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.
Sayfa Yapısı
LLM Sağlayıcılar ekranı üç 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.
- Tanımlar — sağlayıcı tiplerinin kataloğunu listeler: ad, kod, varsayılan uç nokta bilgileri ve hazır/özel rozeti kolonlarıyla. Kurulumla gelen hazır tanımlar (OpenAI, Anthropic, Azure vb.) da düzenlenebilir: uç nokta ya da varsayılan kimlik doğrulama şemasını değiştirip kaydedebilirsiniz. Yaptığınız düzenleme kalıcıdır — hiçbir sürüm yükseltmesi onu geri ezmez. Kurulumla gelen katalog yalnızca tohumlama yapar: bir tanım ilk kez oluşturulurken yazılır ve bir daha yazılmaz. Dolayısıyla değiştirdiğiniz görünen ad, varsayılan uç nokta, varsayılan API sürümü, varsayılan kimlik doğrulama şeması, varsayılan kimlik doğrulama header adı, ikon URL'i ve dokümantasyon linki bütün gelecek sürümlerde bıraktığınız gibi kalır. Bir hazır tanımı sağlayıcının genel adresi yerine kendi gateway'inize yönlendirmeyi güvenli kılan da budur.
Silme, düzenlemeden farklı davranır. Olağan bir sürüm yükseltmesi sildiğiniz tanımı silinmiş bırakır; fakat Apinizer zaman zaman bir LLM katalog tazeleme migration'ı yayınlar — sağlayıcı ekosistemi hızla değiştiği için hazır katalog belirli aralıklarla yeniden yayımlanır (en son APNZ-6550) — ve tazeleme eksik olanı tohumladığı için, sildiğiniz bir hazır tanım kurulum varsayılanlarıyla geri gelir. Kurulumla gelen bir sağlayıcıyı tümüyle devre dışı bırakmak istiyorsanız tanımını silmek yerine onu kullanan bağlantıları kaldırın ya da pasifleştirin. Kopyala, hazır tanımı ve onun bir varyantını yan yana tutmak istediğinizde hâlâ doğru yoldur: tanımı kopyalayıp kopyayı düzenleyin — kopya özel (custom) bir tanımdır. Özel (custom) bir tanım, bu tab'ın kendi formundan doğrudan oluşturulabildiği gibi, Dışa/İçe Aktarma Sihirbazı ("Provider Definition" tipi) ile içe aktararak ya da APIops REST API ile de eklenebilir. Ekranda özel tanımlar için oluşturma, düzenleme, detay görüntüleme, dışa aktarma ve silme aksiyonları kullanılabilir. Bir Provider Definition paketi içe aktarıldığında, sihirbazın tamamlanma ekranındaki kısayol sizi doğrudan bu tab'a getirir. 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.
Özel Sağlayıcı Tanımı Ekleme
Tanıma bir Ad ve bir Kod verin — kod, bir bağlantının sağlayıcı tipinin karşılık geldiği değerdir ve tanım kaydedildikten sonra değiştirilemez. Görünen ad, ikon URL'i ve bir dokümantasyon linki isteğe bağlıdır.
İsteğe bağlı olarak varsayılan uç nokta, varsayılan API sürümü, varsayılan kimlik doğrulama şeması ve varsayılan kimlik doğrulama header adını doldurun — biri bu sağlayıcıyı seçtiğinde, tıpkı hazır tanımlarda olduğu gibi bu değerler yeni bir bağlantı formunu önceden doldurur; bağlantının kendi formu yine de kullanıcının bu değerlerin herhangi birini değiştirmesine izin verir.
Sağlayıcının gerçekte konuştuğu Wire Protocol'ü (tel protokolü) seçin — desteklenen beş aileden biri: OpenAI-uyumlu, Anthropic, Gemini, Bedrock ya da vLLM. Bu, serbest metin değil kısıtlı bir seçimdir: yalnızca Apinizer'ın gerçek bir adaptörü olan bir wire protocol seçilebilir ve bu alan zorunludur. Chat Completion Path de (örn. wire protocol'e göre /chat/completions ya da /messages) zorunludur. Sağlayıcının bir embedding uç noktası varsa Supports Embedding'i açın — bunu açmak Embedding Path alanını da zorunlu kılar, çünkü embedding desteği iddia edip ona ulaşacak bir yol tanımlamayan bir sağlayıcı, istek anında hiçbir şeye çözümlenmez. Supports Responses ve daha aşağıdaki transkripsiyon/konuşma/görsel yolları isteğe bağlıdır; yalnızca o trafiği gerçekten bu sağlayıcı üzerinden yönlendirecekseniz doldurun.
Kaydet'e tıklayın. Tanım, bir sonraki LLM Sağlayıcı bağlantısı oluşturulduğunda sağlayıcı-tipi açılır listesinde kullanılabilir hale gelir.
Hazır bir sağlayıcının aksine, özel bir kod Apinizer'ın kendi bilinen sağlayıcı-tipi listesine karşı çözümlenmez — dolayısıyla onun için arkada eksik bir yolu tamamlayacak bir yedek katman yoktur. Gerçekten özel bir sağlayıcıda wire protocol veya chat yolunu boş bırakmak, çalışma anında hiçbir şeye çözümlenirdi; form bunu sonradan sessizce başarısız olmak yerine baştan zorunlu kılar.
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 — Tanımlar tab'ında ve 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).
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.
- Açılan pencerede 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.
Pencere 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), Desteklenen Modeller tablosunda 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: Desteklenen Modeller tablosundaki Model Tipi sütunu boş bırakılabilen bir seçim kutusudur. 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.
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 listede 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.
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ı formunu açmak için Ekle düğmesine tıklayın.
Açılır menüden sağlayıcıyı seçin — yukarıdaki Sağlayıcı Türleri tablosundaki herhangi biri.
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
API anahtarını veya gizliliği 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ı bir sağlayıcı tanımına bağladığınızda, tanımdaki 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ünde bu değerleri salt-okunur olarak görürsünüz:
isteğin ger çekte hangi yola gideceğini gösterirler.
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.
Neden salt-okunur: kaynakları katalogdur. Bir yolu değiştirmek istiyorsanız Sağlayıcı Tanımı ekranını kullanın; oradaki değişiklik, o tanıma bundan sonra bağlanan bağlantılara kopyalanır — hâlihazırda bağlı olanlar kendi kopyalarını korur (bir tanım düzenlemesi çalışan bir bağlantının davranışını sessizce değiştirmez).
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ış