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.) salt okunurdur; özel (custom) tanımlar bu ekranda yeni oluşturulamaz, yalnızca Dışa/İçe Aktarma Sihirbazı ("Provider Definition" tipi) ile içe aktararak ya da APIops REST API ile eklenir. Ekranda özel tanımlar için 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.
Sağlayıcı Türleri
Apinizer AI Gateway aşağıdaki sağlayıcıları destekler:
| Sağlayıcı | Tür | Dağıtım (varsayılan) | Notlar |
|---|---|---|---|
| OpenAI | OPENAI | Bulut | GPT-4, GPT-4 Turbo, GPT-3.5, vb. |
| Anthropic | ANTHROPIC | Bulut | Claude modelleri |
| Azure OpenAI | AZURE | Bulut | Azure'da barındırılan OpenAI modelleri |
| Google Vertex AI | VERTEX | Bulut | PaLM 2, Gemini |
| AWS Bedrock | BEDROCK | Bulut | Claude, Llama, Mistral |
| 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 (OpenAI, Anthropic, Azure, Vertex, Bedrock)
- Şirket içi — LLM altyapınızda çalışır (vLLM, Ollama, özel 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) | ✅ | ✅ | ✅ | ❌ |
| DeepSeek, Groq, Moonshot (Kimi) | ✅ | ✅ | ❌ (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.
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 (OpenAI, Anthropic, Azure, vLLM, Ollama vb.).
Dağıtım türü otomatik doldurulur:
- Sağlayıcı OpenAI, Anthropic, Azure, Vertex veya Bedrock ise → Bulut olarak ayarlanır
- Sağlayıcı vLLM, Ollama veya Özel ise → Şirket içi 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.
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ış