any-llm - çeşitli LLM sağlayıcıları için tek bir arayüz

 (github.com/mozilla-ai)
7 puan yazan xguru 2025-07-25 | 3 yorum | WhatsApp'ta paylaş
  • Mozilla AI ekibi tarafından geliştirilen, 20'den fazla LLM sağlayıcısını tek bir fonksiyonla kullanabilen bir Python kütüphanesi
    • OpenAI, Anthropic, Google, Mistral, AWS Bedrock vb. modeller arasında geçiş yaparken yalnızca provider_id/model_id değiştirmek yeterli
  • Resmî sağlayıcı SDK'larını öncelikli olarak kullanarak uyumluluk sorunlarını en aza indiriyor; ayrıca proxy/gateway sunucusunu ayrı kurmaya gerek olmadan pip ile kurup hemen kullanılabiliyor
  • Geliştirici dostu yapısıyla eksiksiz IDE type hint desteği, sezgisel istisna yönetimi, özel istisnalar, dokümantasyon ve hızlı başlangıç kılavuzu sunuyor
  • Hafif bir yönlendirici ile framework bağımsız çalışıyor ve ayrı proxy/gateway sunucusu gerektirmiyor (yalnızca API Key ile hemen kullanılabiliyor)
  • Mevcut çözümlerin sorunlarını giderirken aktif olarak bakım alıyor: Mozilla'nın any-agent gibi gerçek ürünlerinde kullanılıyor
    • LiteLLM: Resmî SDK yerine doğrudan uygulama → uyumluluk/hata riski taşıyor
    • AISuite: Modüler bir yapı sunuyor ancak yönetim ve type hint tarafı zayıf
    • Framework bağımlı çözümler: Proje bazında yeniden parçalanmaya yol açıyor
    • Yalnızca proxy odaklı çözümler: Ayrı sunucu gerektiriyor, karmaşıklığı artırıyor

İlgili belgeler

İlgili okumalar

3 yorum

 
kaydash 2025-07-26

Her LLM sağlayıcısı için anahtarı ayrı ayrı yönetmek gerekecek gibi görünüyor.
 
GN⁺ 2025-07-25
Hacker News görüşleri
  • LiteLLM’in resmi SDK yerine doğrudan sağlayıcı arayüzünü uygulamasının başlı başına bir sorun olduğunu düşünmüyorum
    Metin API’lerinde büyük bir uyumluluk sorunu yaşamadım ve farklı API’leri standartlaştırmak için arayüzü kendin uygulamanın gerekli olduğunu anlıyorum
    Belirli bir yönlendirici oluşturmak için bu süreç şart
    • LiteLLM’de gerçekten hafif (lite) bir taraf yokmuş gibi geliyor
      Deneysel olarak kütüphane şeklinde kullandım ama sonunda Simon’un llm aracına geçtim. Simon’a teşekkürler
    • Metin tamamlama gibi standart kullanımlarda iki yaklaşım da iyi çalışıyor
      Farklar daha çok streaming davranışı, timeout yönetimi ve yeni özelliklerin eklenmesi gibi uç durumlarda ortaya çıkıyor
      Biz de API normalizasyonu için arayüzleri yeniden oluşturuyoruz; SDK kullanıp kullanmamak sadece katmanı nerede ayırdığınızla ilgili
      SDK benimsemek daha çok bakım tercihinden kaynaklanıyor, LiteLLM yaklaşımındaki temel bir kusurdan değil
    • Resmi SDK’larda da bağımlılık sorunları çıkabiliyor
      Together’ın SDK’sı bir ara 60 MB’lık Apache Arrow bağımlılığı içeriyordu, bunu doğrudan yamalayıp opsiyonel hale getirdim
      Bağımlılık sürümlerini zorla sabitlerse kendi projemle çakışabiliyor
      Çok fazla bağımlılık çeken bir kütüphane yerine yalnızca OpenAPI/REST kullanmanın daha iyi olduğunu düşünüyorum
    • LiteLLM de genel olarak epey saha tecrübesi kazanmış durumda
      Sadece resmi SDK kullanmak tüm uyumluluk sorunlarını çözmüyor; any_llm de sonuçta resmi SDK’larla doğrudan uyumluluğu korumak zorunda
      Hangi yaklaşımın daha üstün olduğunu net biçimde söylemek zor
    • Ben kişisel olarak Litellm’i bir yapay zeka gateway’i olarak kullanıyorum
      Kullanıcı açısından proxy’nin resmi SDK kullanıp kullanmaması gerçek kullanımda fark yaratmıyor
      Proxy geliştiricisi için avantajları olabilir
      Örneğin yakın zamanda Litellm’in Deepseek Reasoning işleme tarafında bir sorunu vardı ve hem senkron hem streaming yanıtlarında reasoning bölümü eksik gelmişti
  • Blog yazısında LiteLLM’in çok sayıda LLM sağlayıcısını desteklediği için popüler olduğu söyleniyor, ama aynı zamanda “resmi SDK’ları kullanmayıp doğrudan uygulama yaptığı için uyumluluk sorunlarına yol açabilir” diye eleştiriliyor
    Benim deneyimimde LiteLLM pratikte oldukça sağlam çalışıyor
    Sağlayıcılar API değişikliği olduğunda bunu önceden açıkça bildiriyor ve LiteLLM bu yüzden sorun çıkarmadı
    LLM’lerle ilgili olumsuz varsayımsal dezavantajlar yalnızca bu yazıda geçiyor
    Proxy/gateway çözümü olarak OpenRouter ve Portkey’den de bahsedilmiş, ama gerçekte OpenRouter’da kullanıcıların kendilerinin sunucu kurmasına gerek yok; doğrudan endpoint’e API çağrısı yapabiliyorsunuz
    Bu yazı OpenRouter’ı yanlış biçimde self-hosted proxy olarak algılamış
    Ayrıca AISuite, Andrew NG’nin ürünü; blogda “Aralık 2024’ten beri bakımsız” denmiş ama gerçekte sadece release tag’leri yok, küçük topluluk projelerinde etiketleme çoğu zaman yapılmıyor
    Bu tür şeyleri gerçekleri doğrulamadan blogda yayımlamak sorunlu geldi
    Mozilla markası olmasa dolandırıcılık ya da kötü amaçlı yazılım sanabilirdim
    İsmi de Anything-LLM’e fazla benzediği için ayrıca kafa karıştırıyor
  • Yeni any-llm projesi umut verici görünüyor
    Şimdiye kadar LiteLLM kullandım, ama iç uygulamasına bakınca çok karmaşık ve sorunlu olduğunu gördüm
    Örneğin son birkaç aydır Ollama girdisinin Structured Output özelliği tamamen bozuk halde bırakılmıştı ve dokümantasyon da hiç düzenli değildi
  • Proje havalı görünüyor, ilgimi çekti
    Muhtemelen çoğu SDK Python tabanlı olduğu için Python seçilmiş
    Ama yorumlayıcı olmadan birden çok dile taşınabilir bir yapıda olsaydı gerçekten yenilikçi olurdu diye düşünüyorum
    • Asıl soru bu. Birçok araç sistem düzeyi bir problemi (diller arası model çalıştırma) uygulama katmanında (Python kütüphanesi) çözmeye çalışıyor
      Gerçekten evrensel bir çözüm üretmek için modelin runtime’ını ve dili tamamen ayırmak gerekir; bu çok daha zor ama büyük bir ilerleme olur
    • JS/TS için Vercel AISDK, C++ için ClickHouse ai-sdk-cpp, Flutter/ReactNative/Kotlin için Cactus var; yani bu amaca benzer şekilde birden fazla dilde kullanılabilen SDK’lar zaten mevcut
    • Biz bir SDK değil, doğrudan servis olarak bir gateway yaptık. Referans: Portkey-AI Gateway projesi
  • Bunun mevcut SimonW’nin llm projesinden hangi yönleriyle ayrıştığını merak ediyorum
    • SimonW’nin projesi esas olarak OpenAI ve uyumlu modelleri destekliyor; örneğin Amazon Bedrock gibi modelleri kullanmak için *ek bir gateway/proxy* dağıtmanız gerekiyor
      Mozilla tarafındaki proje (LiteLLM dahil) zaten çok sayıda arayüzü desteklediği için birden fazla modeli hemen kullanabilme avantajına sahip
      Ayrı bir proxy/gateway sunucusu olmadan doğrudan pek çok LLM Provider’a bağlanabiliyorsunuz. LiteLLM ile kıyas konusunda deneyimim az, o yüzden emin değilim
  • Ben de Python için LLM soyutlama katmanı niteliğinde açık kaynak bir proje geliştiriyorum
    Araştırma işimde buna ihtiyaç duyduğum için yapmaya başladım
    Mevcut projelerden fikir alıp bunu daha genel amaçlı kullanım için geliştirdim
    https://github.com/proxai/proxai
    https://proxai.co/
  • Zamanlama gerçekten ilginç
    Ben de yakın zamanda benzer bir LLM soyutlama katmanı yayımladım
    pip install ile kolayca kullanılabiliyor ve Langchain uyumluluğuna odaklandığı için mevcut sistemlere kolayca takılabiliyor
    Üstelik rate limit aşıldığında sanal sağlayıcı üzerinden otomatik failover da yapabiliyor
  • Son dönemde LLM gateway/proxy katmanı olarak LiteLLM, OpenRouter, Arch, any-llm gibi pek çok seçenek çıkıyor. Bu gidişle hepimizin yeni bir problem bulması gerekebilir
    • LiteLLM’in biraz karmaşık olduğunu düşünüyorum. Kişisel projelerde Docker container olarak basitçe kullanmak için uygun olabilir ama gerçek üretim kullanımı açısından tatmin edici değil
    • Model sağlayıcılarının %80’i OpenAI uyumlu endpoint desteklediği halde, çok çeşitli çözümler ortaya çıkıyor
    • Portkey’i de anmak isterim. JS ve açık kaynak olarak kullanılabiliyor
    • Biz model yönlendirmeyi akademik araştırma ve PDF chatbot alanına uyguluyoruz. Görüş duymak isterim
  • Bence bu tür çözümler için mutlaka bir Docker image olmalı. Görünüşe göre Docker’dan bahsedilmemiş; çünkü pip ya da Python sürüm çakışmalarından kaçınmak istiyorum
  • Ben de geliştirme ortamında hâlâ Litellm Proxy’yi Docker ile kullanıyorum
    Usage/Logs özelliği gerçek LLM kullanımını görünür kılıyor ve Cache özelliği de tekrarlanan testlerde maliyeti düşürmede çok yardımcı oluyor
 
egirlasm 2025-07-26

Güzel yazı, teşekkürler. Ben de tam bugün 27. kez refactoring yapıyordum.
C++ ile başlayıp, sonra JavaScript'e geçip, şimdi de yine Rust'a...