any-llm - कई LLM providers के लिए एकल इंटरफ़ेस

 (github.com/mozilla-ai)
7 पॉइंट द्वारा xguru 2025-07-25 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Mozilla AI टीम द्वारा बनाई गई Python लाइब्रेरी, जो 20 से अधिक LLM providers को एक ही फ़ंक्शन से इस्तेमाल करने देती है
    • OpenAI, Anthropic, Google, Mistral, AWS Bedrock आदि के बीच मॉडल बदलते समय सिर्फ provider_id/model_id बदलना होता है
  • आधिकारिक provider SDKs को प्राथमिकता देकर compatibility समस्याओं को न्यूनतम करती है, और अलग से proxy/gateway server इंस्टॉल करने की ज़रूरत नहीं होती, इसलिए pip install के बाद तुरंत उपयोग किया जा सकता है
  • developer-friendly तरीके से पूर्ण IDE type hints, सहज exception handling, custom exceptions, documentation और quick guide प्रदान करती है
  • हल्का router होने के कारण यह framework-agnostic है, और अलग proxy/gateway server की ज़रूरत नहीं (सिर्फ API Key हो तो तुरंत उपयोग)
  • मौजूदा solutions की समस्याओं को हल करते हुए, सक्रिय maintenance जारी है : Mozilla के any-agent जैसे वास्तविक products में उपयोग हो रहा है
    • LiteLLM: आधिकारिक SDK के बजाय direct implementation → compatibility/bug की आशंका
    • AISuite: modular structure है, लेकिन management और typing कमज़ोर
    • framework-dependent: हर project में फिर से fragmentation
    • proxy-only: अलग server की ज़रूरत, complexity बढ़ती है

संबंधित दस्तावेज़

संबंधित पढ़ाई

3 टिप्पणियां

 
kaydash 2025-07-26

हर LLM provider के लिए key अलग से मैनेज करनी पड़ेगी।
 
GN⁺ 2025-07-25
Hacker News टिप्पणियाँ
  • मुझे नहीं लगता कि LiteLLM का आधिकारिक SDK की बजाय provider interface को सीधे implement करना अपने-आप में कोई समस्या है
    text API में मैंने कोई बड़ा compatibility issue अनुभव नहीं किया, और अलग-अलग API को standardize करने के लिए अपना interface implement करना पड़े, यह समझ में आता है
    किसी खास router को बनाने के लिए यह प्रक्रिया ज़रूरी है
    • LiteLLM में वास्तव में lite जैसा कुछ नहीं लगता
      मैंने इसे प्रयोग के तौर पर library की तरह इस्तेमाल किया था, लेकिन आखिर में Simon का llm पर चला गया। Simon को धन्यवाद
    • text completion जैसे standard use में दोनों तरीके अच्छी तरह काम करते हैं
      फर्क ज़्यादा edge cases में दिखता है, जैसे streaming behavior, timeout handling, और नए features की शुरुआत
      हम भी API normalization के लिए interfaces दोबारा बना रहे हैं, इसलिए SDK का इस्तेमाल करना या न करना असल में इस बात का फर्क है कि layer कहाँ बाँटी जाए
      SDK अपनाना ज़्यादातर maintenance preference का मामला है, LiteLLM के approach में किसी बुनियादी खामी की वजह से नहीं
    • आधिकारिक SDK में भी dependency issues हो सकते हैं
      Together के SDK में Apache Arrow जैसी 60MB की dependency शामिल थी, और मैंने उसे खुद patch करके optional बनाया
      अगर dependency versions को ज़बरदस्ती pin कर दिया जाए, तो वह मेरे project से टकराव पैदा कर सकता है
      बहुत सारी dependencies खींचने वाली library की बजाय सिर्फ OpenAPI/REST इस्तेमाल करना बेहतर लगता है
    • LiteLLM ने भी कुल मिलाकर काफ़ी real-world battle testing देखी है
      सिर्फ आधिकारिक SDK इस्तेमाल करने से सारे compatibility issues हल नहीं हो जाते, और any_llm को भी आखिरकार आधिकारिक SDK के साथ compatibility बनाए रखने का काम करना पड़ेगा
      साफ़-साफ़ कहना मुश्किल है कि कौन-सा तरीका बेहतर है
    • मैं व्यक्तिगत रूप से Litellm को AI gateway की तरह इस्तेमाल कर रहा हूँ
      user के नज़रिए से proxy में आधिकारिक SDK इस्तेमाल हो या नहीं, real-world usage में कोई फर्क नहीं पड़ता
      proxy developers के लिए कुछ फायदे हो सकते हैं
      उदाहरण के लिए, हाल ही में Litellm में Deepseek Reasoning handling को लेकर issue था, और sync/streaming दोनों responses में reasoning हिस्सा गायब हो गया था
  • blog post में कहा गया कि LiteLLM कई LLM providers के support की वजह से लोकप्रिय है, लेकिन साथ ही इसकी आलोचना यह कहकर की गई कि यह “आधिकारिक SDK इस्तेमाल नहीं करता और खुद implementation करके compatibility issues पैदा कर सकता है”
    मेरे अनुभव में LiteLLM वास्तव में बहुत robust तरीके से काम करता है
    providers आमतौर पर API changes के समय पहले से अच्छी सूचना देते हैं, और LiteLLM मेरे लिए इस वजह से कभी समस्या नहीं बना
    LLM से जुड़ी नकारात्मक काल्पनिक कमियाँ मुझे सिर्फ इसी लेख में दिखीं
    proxy/gateway solution के रूप में OpenRouter और Portkey का भी ज़िक्र हुआ, लेकिन वास्तव में OpenRouter में user को खुद server खड़ा करने की ज़रूरत नहीं होती, बस endpoint पर सीधे API call करनी होती है
    इस लेख में OpenRouter को self-hosted proxy समझने की गलती की गई
    और AISuite, Andrew NG का बनाया हुआ product है, लेकिन blog में लिखा गया कि यह “दिसंबर 2024 के बाद से unmaintained” है; जबकि असल में release tags नहीं होने का मतलब यह भी हो सकता है कि छोटे community projects में tagging नियमित न हो
    बिना fact-checking के ऐसी बातें blog में डालना मुझे समस्या लगता है
    अगर Mozilla brand न होता, तो मैं इसे scam या malware समझ बैठता
    नाम भी Anything-LLM से बहुत मिलता-जुलता है, इसलिए भ्रम होता है
  • नया any-llm project दिलचस्प लग रहा है
    अब तक मैं LiteLLM इस्तेमाल करता रहा हूँ, लेकिन इसकी अंदरूनी implementation देखने पर यह काफ़ी जटिल और समस्याग्रस्त लगी
    उदाहरण के लिए, पिछले कुछ महीनों से Ollama entry का Structured Output पूरी तरह टूटा हुआ पड़ा था, और documentation भी बिल्कुल व्यवस्थित नहीं थी
  • project काफ़ी बढ़िया दिख रहा है, इसलिए दिलचस्प है
    Python चुनने की वजह शायद यह है कि ज़्यादातर SDK Python-based हैं
    लेकिन अगर यह interpreter के बिना कई भाषाओं में portable होता, तो सच में revolutionary होता
    • यही मुख्य सवाल है। बहुत से tools system-level problem (cross-language model execution) को application layer (Python library) में हल करने की कोशिश करते हैं
      सचमुच universal solution बनाने के लिए model runtime और language को पूरी तरह अलग करना होगा, और यह कहीं ज़्यादा कठिन समस्या है, लेकिन बड़ा कदम भी
    • JS/TS के लिए Vercel AISDK है, C++ के लिए ClickHouse ai-sdk-cpp, और Flutter/ReactNative/Kotlin के लिए Cactus जैसे SDK पहले से मौजूद हैं। इनका उद्देश्य इस project से मिलता-जुलता है
    • हमने SDK नहीं, बल्कि service-style gateway खुद बनाया है। संदर्भ: Portkey-AI Gateway project
  • मैं जानना चाहता हूँ कि मौजूदा SimonW के llm project से इसका अंतर क्या है
    • SimonW का project मुख्य रूप से OpenAI और compatible models को support करता है, और उदाहरण के लिए Amazon Bedrock जैसे models इस्तेमाल करने के लिए *अतिरिक्त gateway/proxy* खुद deploy करना पड़ता है
      Mozilla वाला project (LiteLLM सहित) पहले से कई interfaces support करता है, इसलिए इसकी ताकत यह है कि तुरंत कई models इस्तेमाल किए जा सकते हैं
      अलग proxy/gateway server के बिना सीधे कई LLM providers से connect किया जा सकता है। LiteLLM से तुलना पर मैं ज़्यादा नहीं कह सकता क्योंकि मेरा अनुभव कम है
  • मैं भी Python के लिए LLM abstraction layer open source project बना रहा हूँ
    अपने research role की ज़रूरत के कारण मैंने इसे विकसित करना शुरू किया
    मौजूदा projects से ideas लेकर इसे ज़्यादा general-purpose use के लिए बनाया
    https://github.com/proxai/proxai
    https://proxai.co/
  • सच में timing अजीब तरह से दिलचस्प लग रही है
    मैंने भी हाल ही में ऐसा ही LLM abstraction layer launch किया है
    इसे pip install से आसानी से इस्तेमाल किया जा सकता है, और Langchain compatibility पर ध्यान देकर बनाया गया है ताकि मौजूदा systems में आसानी से replace किया जा सके
    साथ ही rate limit exceed होने पर virtual providers के ज़रिए automatic failover भी संभव है
  • आजकल LLM gateway/proxy layer के लिए LiteLLM, OpenRouter, Arch, any-llm जैसे कई विकल्प उभर रहे हैं। इस बिंदु पर लगता है कि शायद हम सबको मिलकर कोई नई समस्या ढूँढनी चाहिए
    • मुझे लगता है LiteLLM थोड़ा जटिल है। personal project में Docker container के रूप में casually इस्तेमाल करने के लिए ठीक हो सकता है, लेकिन असल production use के लिए संतोषजनक नहीं
    • जबकि 80% model providers OpenAI-compatible endpoint support करते हैं, फिर भी इतनी अलग-अलग solutions आ रही हैं
    • मैं Portkey का भी ज़िक्र करना चाहूँगा। इसे JS और open source रूप में इस्तेमाल किया जा सकता है
    • हम model routing को academic research और PDF chatbot क्षेत्र में लागू कर रहे हैं। इस पर राय जानना चाहूँगा
  • मुझे लगता है ऐसी solutions के लिए Docker image ज़रूरी है। शायद Docker का ज़िक्र नहीं किया गया, लेकिन मैं pip या Python version conflicts से बचना चाहता हूँ
  • मैं development environment में भी Litellm Proxy को लगातार Docker के साथ इस्तेमाल कर रहा हूँ
    Usage/Logs feature वास्तविक LLM usage को visualise करता है, और Cache feature बार-बार testing के दौरान लागत कम करने में बहुत मदद करता है
 
egirlasm 2025-07-26

अच्छा लेख है, धन्यवाद। संयोग से मैं भी आज 27वीं बार refactoring कर रहा था।
पहले C++ में कर रहा था, फिर javascript में, और अब फिर से rust में...