LiteLLM ve OpenRouter: Maliyet, Kontrol ve Arıza Toleransı

LLM gateway seçerken asıl mesele LiteLLM ile OpenRouter’ın OpenAI uyumlu API konuşup konuşmadığı değil, yönlendirme katmanını kimin işleteceğidir. Ekibiniz hâlihazırda üretim ortamında bir gateway altyapısı çalıştırmıyorsa OpenRouter daha az eforla başlamak için güçlü bir seçenektir. LiteLLM ise özel ağ yapılandırması, kurum içi politikalar veya yüksek ve sürekli kullanım için daha fazla kontrolün operasyon yükünü karşılayacağı durumlarda anlam kazanır.

Karar, API formatından çok işletim modeliyle ilgili

LiteLLM, Python SDK olarak ya da kendi altyapınızda barındırılan bir proxy şeklinde çalışabilen açık kaynaklı bir yazılımdır. OpenRouter ise yönetilen bir API ve model kataloğudur: Gateway’i OpenRouter işletir, farklı sağlayıcılara erişimi tek yerde toplar ve model kullanımı için size tek bir hesap sunar.

Her iki ürün de OpenAI uyumlu bir arayüz sağlayabilir; ancak sorumlulukları farklı taraflara dağıtırlar:

Bu fark, iki ürünü birlikte kullanmayı da mümkün kılar: LiteLLM kurum içi politika ve maliyet muhasebesi katmanını sağlayabilir, OpenRouter ise seçilen modellere erişimi üstlenebilir.

İlk hangi kısıtın canınızı yakacağına göre seçim yapın

Doğru seçim, ekibinizin pazarlık konusu yapamayacağı ilk gereksinime bağlıdır.

Token faturasından mühendislik maliyetine kadar hesabı çıkarın

LiteLLM ve OpenRouter farklı katmanlar için ücretlendirir. OpenRouter, çıkarım ücretlendirmesini temel model fiyatları üzerinden aktarır; çıkarım için ek ücret koymaz, ancak kredi satın alırken %5,5 ücret alır. LiteLLM’in açık kaynaklı proxy’sinde token başına gateway ücreti yoktur; buna karşılık altyapıyı işletmek için gereken sistem ve insan kaynağının maliyetini siz üstlenirsiniz.

Ücret koşulları için güncel kaynak OpenRouter fiyatlandırma sayfasıdır. Bu ücret, kredi satın alımıyla ilişkilidir; her modelin token fiyatına doğrudan eklenen basit bir %5 zam değildir.

OpenRouter ücretinin daha ucuz kalabildiği durumlar

Bir ekip aylık çıkarım faturasını karşılayacak kadar OpenRouter kredisi satın alırsa:

• Aylık $500 kullanımda %5,5 kredi satın alma ücreti $27.50 olur.
• $20,000 seviyesinde aynı oran $1,100 eder.
• $50,000 seviyesinde ücret $2,750 olur.

Bu rakamlar, LiteLLM’in barındırma, dağıtım, yama uygulama, alarm, yedekleme ve mühendislik zamanı sonrasında geride bırakması gereken maliyeti gösterir. Aylık $500 seviyesinde, hâlihazırda gateway işletmeyen bir ekip için özel ağ bağlantısı zorunlu değilse OpenRouter genellikle daha düşük operasyon yükü sunar. $20,000 seviyesinde ise platform sorumluluğunu üstlenen bir ekip LiteLLM’i ciddi biçimde maliyetlendirmelidir.

LiteLLM’in sıfır gateway ücretinin gerçekten avantajlı olduğu durumlar

LiteLLM, sabit işletim maliyeti platform ekibinizin mevcut bütçesi tarafından zaten karşılanıyorsa veya kaçınılan yüzdelik ücret proxy’yi çalıştırmanın ek maliyetini aşıyorsa finansal açıdan cazip hâle gelir.

Resmî Docker hızlı başlangıç kılavuzu, basit ve veritabanı kullanmayan proxy ile veritabanı destekli dağıtımı birbirinden ayırır. Compose akışında model, anahtar ve harcama log’ları için PostgreSQL kullanılır. Veritabanı olmadan sanal anahtarlar, harcama takibi ve etkin bütçe denetimi kullanılamaz; yapılandırılmış bir max_budget güvenilir bir kesin sınır oluşturmaz.

Redis de üretim için ayrı bir eşik getirir. LiteLLM’in Redis gereksinimleri, proxy birden fazla worker veya replica ile çalıştığında paylaşılan Redis durumunu önerir. Bu olmadan hız limitleri, bütçeler, bekleme süreleri, önbellek girdileri ve yönlendirme gözlemleri worker’lar arasında bölünür. Tek worker’lı bir test ucuzdur; yatay ölçeklenen üretim gateway’i ise çok daha büyük bir sistemdir.

Yalnızca token fiyatına bakmak yerine şu karşılaştırmayı kullanın:

LiteLLM total cost = provider bills + infrastructure + operations + security ownership
OpenRouter total cost = provider inference + credit-purchase fee

Evrensel bir başabaş noktası yoktur. Hesaba katılması gereken veriler aylık çıkarım harcaması, barındırma, mühendislik saatleri, nöbetçi destek kapsamı ve uyumluluk için ödenen ek bedeldir.

İşletmeniz gereken kontrol düzlemini karşılaştırın

LiteLLM platform ekibine daha fazla kontrol verir; ancak sağlayıcı erişimini sizin için oluşturmaz. OpenRouter model keşfi ve birleşik faturalandırma açısından daha basittir, fakat barındırılan katalog doğrudan sağlayıcı ilişkisine sahip olmakla aynı şey değildir.

Güvenilirlikte iki ürünün farkı belirginleşiyor

Her iki ürün de yeniden deneme veya failover yapabilir; ancak farklı sahiplik modelleriyle çalışırlar. OpenRouter sağlayıcı havuzunu yönetir. LiteLLM’de havuzu siz tanımlarsınız ve sistemi güvenilirlik altyapınızın bir parçası olarak işletmeniz gerekir.

OpenRouter’ın sağlayıcı yönlendirme belgelerine göre varsayılan davranış, fiyatı ve sağlayıcılardaki son kesintileri dikkate alarak uygun sağlayıcılar arasında yük dengelemesi yapar. Sağlayıcı sırası isteyebilir, fallback’leri etkinleştirebilir veya devre dışı bırakabilir, belirli parametreleri zorunlu tutabilir, veri politikasıyla filtreleme yapabilir ya da fiyat, throughput veya gecikmeye göre sıralama seçebilirsiniz. Model fallback kılavuzu, sıralı bir models listesini açıklar; faturalandırma, isteğe nihai olarak hizmet veren model üzerinden yapılır.

LiteLLM’in yönlendirme belgeleri; ağırlıklı veya karıştırılmış seçim, kullanım farkındalıklı yönlendirme, gecikme bazlı yönlendirme, en az meşgul yönlendirme, maliyet bazlı yönlendirme ve özel yönlendirme stratejilerini belgeler. Ayrıca dağıtım öncelikleri, bekleme süreleri, yeniden denemeler ve fallback grupları da desteklenir. Bu kontroller daha programlanabilir olsa da doğru çalışmaları yapılandırmanıza, sağlık kontrollerinize, paylaşılan duruma ve olay müdahalesine bağlıdır.

Agent gecikmesi, önbellekleme ve sağlayıcı farklılıkları

Uzun bir streaming yanıtında tek bir ek ağ geçişi önemli olmayabilir. Ancak bir agent onlarca kısa model çağrısı yaptığında durum değişir; gateway, ağ ve yeniden deneme gecikmeleri turlar boyunca birikir. Self-hosted LiteLLM proxy’si uygulamanın yakınına yerleştirilebilirken OpenRouter, seçilen sağlayıcıya gitmeden önce yönetilen bir servis katmanı ekler. Her iki sağlayıcının genel belgeleri de bölgeniz, modeliniz, streaming modunuz ve eşzamanlılık seviyeniz için yapılacak gerçek bir testin yerini tutmaz.

Yönlendirme, önbellek ekonomisini değiştirebilir. OpenRouter aynı model için farklı sağlayıcı endpoint’leri arasında seçim yapabilir; LiteLLM ise istekleri yapılandırılmış dağıtımlar arasında paylaştırabilir. Bir iş akışı sağlayıcı tarafındaki prompt önbelleklemesine dayanıyorsa rota değişikliği önbellek yerelliğini ve token maliyetini etkileyebilir. Önbellek davranışını iş yükü testinin bir parçası olarak değerlendirin.

Ortak bir model slug’ı da davranışın birebir aynı olacağını garanti etmez. Sağlayıcı uygulamaları bağlam sınırları, tool-call desteği, gecikme, quantization, önbellekleme ve sağlayıcıya özel parametreler açısından farklılaşabilir. OpenRouter, require_parameters gibi sağlayıcı filtreleri sunarken LiteLLM, sağlayıcı çağrılarını ortak bir arayüzde normalize eder. Agent’ınızın kullandığı kesin tool şemalarını ve model parametrelerini test edin.

Tasarlanması gereken arıza senaryoları

OpenRouter altyapı kesintilerini tedarikçi bağımlılığına dönüştürür. LiteLLM ise bu kesintileri platform ekibinizin inceleyebileceği ve değiştirebileceği olaylara dönüştürür.

Gözlemlenebilirlik ve gizlilik farklı sınırlar üzerinden çalışır

“Self-hosted” ile “özel” aynı anlama gelmez; “yönetilen” de her prompt’un log’landığı anlamına gelmez. Önemli olan hangi katmanın içeriği, hangisinin metadatayı sakladığı ve isteğin hangi sağlayıcılara ulaştığıdır.

OpenRouter’ın Zero Data Retention belgeleri, ZDR’nin hesap genelinde, model grubuna göre, guardrail üzerinden veya istek bazında uygulanabileceğini belirtir. Veri saklamayan endpoint’lerle, model eğitimi yapmayan ancak veriyi geçici olarak saklayabilen sağlayıcıları birbirinden ayırır. ZDR çıkarım yönlendirmesi için geçerlidir; etkinleştirilen araçlar ve eklentiler ayrıca incelenmelidir.

LiteLLM gateway’in ağı, veritabanı, kimlik doğrulaması ve log’ları üzerinde size daha fazla kontrol verir; ancak sorumluluk da size aittir. Proxy’yi güvenceye alın, yazılımı güncel tutun, yönetim rotalarını kısıtlayın, sağlayıcı anahtarlarını koruyun ve her üst akış sağlayıcısının veri saklama ve model eğitimi koşullarını doğrulayın.

Hibrit model çoğu zaman en pratik cevap

Sabit bir kurum içi endpoint’e ve yönetişime ihtiyaç duyuyor, ancak her model veya sağlayıcı için doğrudan hesap açmak istemiyorsanız LiteLLM’i OpenRouter’ın önünde kullanın. Hassas veya öngörülebilir trafiği onaylanmış sağlayıcılara doğrudan yönlendirin; keşif amaçlı ya da kataloğa bağlı trafiği OpenRouter üzerinden geçirin.

Sadeleştirilmiş bir yapılandırma örneği şöyle görünebilir:

model_list:
  - model_name: direct-claude
    litellm_params:
      model: anthropic/claude-sonnet-latest
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: catalogue-model
    litellm_params:
      model: openrouter/<provider>/<model>
      api_base: https://openrouter.ai/api/v1
      api_key: os.environ/OPENROUTER_API_KEY

Bu yapı LiteLLM’e kurum içi anahtarları, bütçeleri, etiketleri ve log’ları uygulayabileceği bir katman kazandırır. Ancak OpenRouter rotasından geçen isteklerde OpenRouter ücretini, barındırılan veri geçişini veya sağlayıcı politikası sınırını ortadan kaldırmaz. Ayrıca bir ağ geçişi ve bir arıza alanı daha ekler; bu nedenle her isteği otomatik olarak iki katmandan birden geçirmeyin.

Mantıklı bir dağılım şöyle olabilir:

1. Hassas veriler, sabit üretim modelleri veya üzerinde anlaşmaya varılmış sağlayıcı sözleşmeleri için doğrudan sağlayıcı rotaları.
2. Model keşfi, daha az kullanılan sağlayıcılar ve yönetilen sağlayıcı fallback’i için OpenRouter rotaları.
3. Uygulama anahtarları, ekipler, bütçeler ve kurum içi maliyet dağılımı için LiteLLM kontrolleri.
4. Doğrudan sağlayıcı ve OpenRouter trafiği için ayrı panolar ve alarmlar.

Geçiş maliyeti: Neler değişir, neler değişmez?

OpenAI uyumlu bir istemciyi iki gateway arasında taşımak küçük bir iş olabilir. Üretim iş yükünü taşımak ise yalnızca base URL’ini değiştirmekten ibaret değildir.

from openai import OpenAI
import os

client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

OpenRouter genellikle https://openrouter.ai/api/v1 kullanır (API referansı); LiteLLM proxy’si ise çoğunlukla http://localhost:4000 gibi özel bir endpoint sunar (proxy hızlı başlangıcı). Buna rağmen model ID’leri, sağlayıcı önekleri, kimlik doğrulama ve isteğe bağlı parametreler farklılık gösterebilir.

Üretim trafiğini değiştirmeden önce şunları test edin:

1. Streaming ve timeout davranışı.
2. Kullandığınız kesin JSON şemalarıyla tool çağrıları.
3. Yapılandırılmış çıktılar ve katı JSON işleme.
4. Reasoning, önbellekleme ve sağlayıcıya özel parametreler.
5. Birincil model 429, 5xx veya doğrulama hatası döndürdüğünde fallback davranışı.
6. Maliyet dağılımı; çünkü faturalandırma olayı uygulama isteğinden farklı bir katmanda gerçekleşebilir.

API uyumluluğu ilk entegrasyonu kolaylaştırır. Ancak aynı çıktıyı, gecikmeyi, sağlayıcı seçimini veya faturalandırma semantiğini garanti etmez.

Ekiplerin seçim öncesinde sorduğu sorular

LiteLLM ve OpenRouter birlikte kullanılabilir mi?

Evet. LiteLLM, OpenRouter’ı üst akış rotası olarak kullanabilir; böylece kurum içi anahtarlar, bütçeler, log’lama veya politikalar LiteLLM tarafından yönetilirken seçilen model erişimini ve sağlayıcı yönlendirmesini OpenRouter sağlar. Birleşik akış ek bir ağ geçişi getirir; bu trafikte OpenRouter ücreti ve barındırılan veri sınırı geçerliliğini korur.

Üretim API’si için hangisi daha ucuz?

Gateway altyapısını hâlihazırda işletmeyen küçük bir ekip için OpenRouter genellikle operasyon yükü açısından daha ucuz seçenektir. Ekibiniz gereken altyapıyı zaten işletiyor ve yüzdelik gateway ücretlerinden kaçınmak istiyorsa yüksek kullanım seviyelerinde LiteLLM daha ucuz olabilir; yalnızca token maliyetini değil, toplam maliyeti karşılaştırın.

LiteLLM, OpenRouter’ın tüm kataloğuna erişim sağlar mı?

Kendi başına sağlamaz. LiteLLM, proxy hızlı başlangıç kılavuzunda 100+ LLM ve geniş bir sağlayıcı setini desteklediğini belirtir; ancak yalnızca yapılandırdığınız sağlayıcılara ve kimlik bilgilerine erişebilir. OpenRouter’ı üst akış olarak eklemek erişilebilen kataloğu genişletebilir; fakat bu istekler OpenRouter’ın model ve sağlayıcı erişilebilirliği kurallarına tabi olur.

Gizlilik ve uyumluluk için hangisi daha iyi?

Self-hosted LiteLLM, gateway’in dağıtımı, log’ları, kimlik bilgileri ve ağ sınırı üzerinde size daha fazla kontrol verir. OpenRouter içerik log’lama kontrolleri, sağlayıcı politikası filtreleri, ZDR yönlendirmesi ve Enterprise kapsamında AB/ABD bölgesel seçenekleri sunar; ancak istek akışının bir parçası olmaya devam eder. Seçim yapmadan önce kesin sağlayıcıyı ve sözleşmesel gereksinimi doğrulayın.

İşletebileceğiniz sınırı seçin: yüzdelik ücreti gerçek gateway işletim maliyetinizle karşılaştırın, hangi isteklerin barındırılan bir aracıdan geçebileceğini sınıflandırın ve uygulamanızın ihtiyaç duyduğu yönlendirme ile tool-call davranışına karşı bir arıza testi çalıştırın. LiteLLM’in veritabanı, Redis, güncellemeler ve nöbetçi sahipliğini üstlenemiyorsanız OpenRouter daha dürüst bir varsayılandır. Bu platform yetkinliğine zaten sahipseniz LiteLLM veya hibrit bir rota, kontrolü geri kazandırabilir ve tekrarlanan gateway ücretlerini azaltabilir.

OpenRouter yerine kullanılabilecek daha geniş seçenekler için OpenRouter alternatives yazısına bakabilirsiniz; bu karşılaştırma bilerek daha dar tutuldu ve LiteLLM’in işletim modeli kararına odaklandı.