LiteLLM, yerel ve bulut LLM endpoint'lerini tek bir self-hosted gateway arkasında birleştiriyor

Sorun: endpoint yayılımı

dev.to'da yayımlanan bir anlatıma göre, homelab yapay zeka kurulumları zamanla birbiriyle uyumsuz inference servisleri biriktiriyor: qwen2.5-coder:14b ve deepseek-r1:14b gibi modelleri sunan 11434 portundaki Ollama, uzman GGUF modelleri için 8080 portundaki bir llama.cpp sunucusu, denemeler için 7860 portunda Text Generation WebUI ve OpenAI, Anthropic ile Groq'un bulut API'leri. Her biri kendi endpoint'ini, kimlik bilgilerini ve SDK'sını beraberinde getiriyor.

Yazar sonuçları şöyle sıralıyor: her uygulama her sağlayıcı için koşullu mantıkla dolu hale geliyor, kimlik bilgileri ve endpoint'ler çoğalıyor, fallback olmadığı için ölmüş bir Ollama instance'ı uygulamaları çökertiyor, yük instance'lar arasında dağıtılamıyor, kullanım elle kaydedilmek zorunda kalıyor ve hiçbir şey upstream API'leri kötüye kullanıma karşı korumuyor.

Her şeyin önünde tek bir proxy

LiteLLM çözüm olarak sunuluyor: 4000 portunda OpenAI uyumlu bir API açan tek bir proxy. Uygulamalar mevcut OpenAI SDK'larını tek bir URL'ye yöneltiyor ve her model adını gerçekte neyin serve edeceğine yapılandırma karar veriyor — gpt-4o-mini gibi görünen bir istek, operatörün seçimine bağlı olarak yerel donanıma ya da ücretli bir API'ye yönlendirilebiliyor.

Yazıya göre gateway; token sayımı ve maliyet tahmini, model başına veya global hız limitleri, üstel geri çekilme ve jitter içeren yeniden denemeler, özdeş instance'lar arasında load balancing ve bir sağlayıcı başarısız olduğunda otomatik fallback ekliyor.

Sağlayıcılar ve yönlendirme stratejileri

Anlatım, desteklenen sağlayıcıları yerel olanlar — ollama, llama_cpp, vllm ve Hugging Face'in Text Generation Inference'u bunlar arasında — ve OpenAI, Anthropic, Groq, Cohere, Mistral, Azure OpenAI ile Amazon Bedrock dahil uzak olanlar olarak ikiye ayırıyor.

Üç yönlendirme deseni tanımlanıyor:

• Basit liste: modeller biri yanıt verene kadar sırayla deneniyor. Örnek önce Ollama'nın qwen2.5-coder:14b'sini, sonra deepseek-r1:14b'yi, ardından OpenAI'nin gpt-4o-mini'sini deniyor.
• Load balancing: tek bir ad altında kayıtlı özdeş dağıtımlar gelen istekleri paylaşıyor, her biri dakika başına istek sınırına sahip. Örnek, yükü her biri 30 rpm ile sınırlı üç Ollama instance'ına yayıyor.
• Yazarın waterfall routing dediği fallback zincirleri: kademeler hızlı bir yerel modelden daha büyük bir yerel modele, ardından gpt-3.5-turbo gibi ucuz bir uzak seçeneğe ve son olarak gpt-4o gibi premium bir seçime doğru yükseliyor. Her kademe dakika başına token bütçesi taşıyor, bu da pahalı kademeleri rasyonel tutuyor.

Dağıtım seçenekleri

Proxy'yi çalıştırmanın üç yolu ele alınıyor. Docker önerilen yol; config dizinini mount eden ve API anahtarlarını environment variable olarak geçen bir docker run komutu ya da compose dosyası şeklinde. Doğrudan pip install ise geliştirme ve hata ayıklama için uygun. TrueNAS SCALE gibi Kubernetes ana makineleri içinse bir Helm chart, LiteLLM'i ayrı bir namespace'e kuruyor ve servisi 4000 portunda açıyor.

Neden önemli

Bu desen homelab'ın çok ötesine genellenebilir. Birden fazla LLM endpoint'ine dokunan her ekip — yerel bir inference makinesi artı birkaç sağlayıcı — anahtarlar, SDK'lar ve hata modlarından oluşan aynı yayılımla karşılaşır. LiteLLM standart çözümleri tek bir self-hosted süreçte topluyor: istemciler için istikrarlı, OpenAI biçiminde bir sözleşme, sağlayıcı failover'ı, yük dağıtımı ve ölçümleme. Ayrıca lock-in'i de yumuşatıyor, çünkü sanal bir adın arkasındaki modeli değiştirmek uygulama yeniden yazımı yerine bir yapılandırma değişikliğine dönüşüyor ve kullanım büyüdükçe yerleşik hız ve token bütçeleri daha değerli hale geliyor.