LLM providers और models का प्रबंधन करें, बाहरी रजिस्ट्री से models सिंक करें, हेल्थ चेक चलाएँ, और स्वतंत्र बिलिंग के लिए प्रति-organization API keys कॉन्फ़िगर करें।
Entity Enricher LLM प्रोवाइडर्स की एक विस्तृत श्रृंखला का समर्थन करता है। प्रत्येक प्रोवाइडर के पास अलग-अलग मूल्य निर्धारण, क्षमताओं, और कॉन्फ़िगरेशन वाले कई मॉडल हो सकते हैं।
कई टीमें LLM ट्रैफ़िक को किसी कॉर्पोरेट AI गेटवे, किसी क्षेत्रीय एंडपॉइंट, या किसी ऐसे provider के माध्यम से रूट करती हैं जो बिल्ट-इन नहीं है — उदाहरण के लिए एक एंटरप्राइज़ LiteLLM प्रॉक्सी, Cloudflare AI Gateway, या Alibaba DashScope (Qwen मॉडल के लिए)। आप इन्हें एक कस्टम base URL के साथ अपने खुद के Standard (OpenAI-compatible) provider के रूप में जोड़ते हैं।
acme-openai-gw)। openai या anthropic जैसे बिल्ट-इन नाम आरक्षित हैं। https://gateway.example.com/v1। यह फ़ील्ड किसी भी ऐसे प्रोवाइडर के लिए आवश्यक है जिसके लिए Entity Enricher के पास कोई बिल्ट-इन क्लाइंट नहीं है। https:// URL होने चाहिए। SSRF को रोकने के लिए लूपबैक और निजी रेंज (localhost, 10.x, 192.168.x) अस्वीकार कर दी जाती हैं — एक सेल्फ-होस्टेड सर्वर इंटरनेट पर पहुँच योग्य होना चाहिए। स्थानीय Ollama के लिए, इसके बजाय समर्पित Ollama टनल का उपयोग करें।/v1 प्रोटोकॉल (चैट कंप्लीशन, /models) बोलना चाहिए। {endpoint}/models की जाँच करता है।हर provider में एक प्रति key अधिकतम समवर्ती कॉल सेटिंग होती है (उसका rate-limit ओवरराइड)। यह सीमित करती है कि एक single API key समानांतर में कितनी LLM कॉल चलाती है — key का उपयोग करने वाले हर फ़्लो को कवर करते हुए: multi-expertise enrichment फ़ैन-आउट, classification, arbitration, और schema / सैंपल जनरेशन।
यह आपके प्लान की अधिकतम समवर्ती जॉब सीमा से अलग है, जो यह सीमित करती है कि आपका पूरा संगठन सभी प्रोवाइडरों में एक साथ कितने एनरिचमेंट जॉब चलाता है।
हर model अपनी क्षमताओं को ट्रैक करता है, जो model चयनकर्ता में आइकन के रूप में दिखाई जाती हैं:
| क्षमता | विवरण |
|---|---|
| विज़न | इमेज और विज़ुअल इनपुट प्रोसेस कर सकता है |
| टूल कॉल | फ़ंक्शन कॉलिंग / टूल उपयोग का समर्थन करता है |
| ऑडियो इनपुट | ऑडियो इनपुट प्रोसेस कर सकता है |
| PDF इनपुट | PDF दस्तावेज़ प्रोसेस कर सकता है |
| प्रॉम्प्ट कैशिंग | लागत घटाने के लिए प्रॉम्प्ट कैशिंग का समर्थन करता है |
| रीज़निंग | विस्तारित थिंकिंग / चेन-ऑफ-थॉट क्षमताएँ |
बाहरी रजिस्ट्री से सिंक करके मॉडल प्राइसिंग को अप-टू-डेट रखें। सिंक प्रक्रिया नए मॉडल, मूल्य परिवर्तन, और हटाए गए मॉडल को स्वचालित रूप से पहचान लेती है।
डिफ़ॉल्ट मूल्य निर्धारण स्रोत। GitHub पर LiteLLM की समुदाय-द्वारा-अनुरक्षित रजिस्ट्री से वास्तविक API मॉडल नाम, मूल्य निर्धारण, संदर्भ लंबाई, और क्षमताएँ प्राप्त करता है।
लगभग 30 provider को कवर करता है। इसमें डिस्प्ले नाम, benchmark या जनरेशन स्पीड शामिल नहीं है।
pricepertoken.com से एक वैकल्पिक स्रोत। इसमें प्रदर्शन नाम, benchmark (coding और math स्कोर), और generation गति (टोकन प्रति सेकंड) शामिल हैं।
लगभग 20 provider को कवर करता है। LiteLLM की तुलना में अधिक समृद्ध मेटाडेटा प्रदान करता है।
एक न्यूनतम हेल्थ चेक prompt चलाकर सक्रिय रूप से जाँचें कि models पहुँच योग्य हैं या नहीं। इससे enrichment के दौरान उपयोगकर्ताओं को त्रुटियाँ मिलने से पहले ही खराब models पकड़ में आ जाते हैं।
हेल्थ चेक सभी मॉडलों, किसी विशिष्ट प्रोवाइडर के मॉडलों, या एकल मॉडल पर चलाए जा सकते हैं। परिणाम SSE के माध्यम से रियल टाइम में स्ट्रीम होते हैं और प्रोग्रेस बार पास/फेल गिनती दिखाता है।
जब कोई संवर्धन कॉल “model not found” त्रुटि के साथ विफल होती है, तो बार-बार विफलताओं को रोकने के लिए मॉडल स्वतः निष्क्रिय कर दिया जाता है। यह सामान्य संवर्धन ऑपरेशन के दौरान रीयल टाइम में होता है।
| निष्क्रियकरण का कारण | किसके द्वारा सेट | ऑटो-पुनःसक्रिय? |
|---|---|---|
| मॉडल नहीं मिला | संवर्धन त्रुटियाँ या हेल्थ चेक | हाँ (pricing sync या validation द्वारा) |
| सिंक हटाया गया | मूल्य सिंक (model गायब हो गया) | हाँ (यदि model रजिस्ट्री में फिर से दिखे) |
| मैन्युअल | UI में एडमिन टॉगल | नहीं (केवल मैन्युअल पुनः-सक्रियण) |
संगठन स्वतंत्र बिलिंग और उपयोग ट्रैकिंग के लिए अपनी स्वयं की LLM प्रोवाइडर API कुंजियाँ कॉन्फ़िगर कर सकते हैं। सिस्टम LRU चयन के साथ दो-स्तरीय कुंजी रिज़ॉल्यूशन का उपयोग करता है:
API Keys पेज में कॉन्फ़िगर की गई प्रति-organization कीज़। LRU रोटेशन के साथ प्रति provider अनेक कीज़ का समर्थन करता है। Fernet से एन्क्रिप्टेड।
एडमिनिस्ट्रेटर द्वारा प्रबंधित सिस्टम-व्यापी कुंजियाँ। सभी ऑर्गनाइज़ेशन में साझा। यह LRU रोटेशन के साथ प्रति प्रोवाइडर कई कुंजियों का भी समर्थन करता है।
हर enrichment यह रिकॉर्ड करता है कि कौन-सी key इस्तेमाल हुई, ताकि आप प्रति key लागत ट्रैक कर सकें। Keys में हेल्थ चेक सपोर्ट, उपयोग काउंटर शामिल होते हैं, और स्थायी विफलताओं (अमान्य key, भुगतान आवश्यक) पर वे स्वतः अक्षम हो जाती हैं। Rate-limited keys को अस्थायी रूप से रोक दिया जाता है जबकि पूल की अन्य keys उपयोग की जाती हैं। Keys प्रबंधित करना API Keys गाइड में सीखें।
बैकअप या किसी अन्य इंस्टेंस में ट्रांसफर के लिए अपने संपूर्ण प्रोवाइडर और मॉडल कॉन्फ़िगरेशन को JSON के रूप में एक्सपोर्ट करें। इम्पोर्ट हमेशा एक upsert होता है: मौजूदा प्रोवाइडर और मॉडल नाम से मैच किए जाते हैं और यथास्थान अपडेट किए जाते हैं, जबकि नए जोड़े जाते हैं — कुछ भी नहीं हटाया जाता।
एक्सपोर्ट में प्रोवाइडर सेटिंग्स, मॉडल कॉन्फ़िगरेशन, प्राइसिंग, क्षमताएँ, और कैननिकल मॉडल स्पेक्स शामिल होते हैं — लेकिन API keys कभी नहीं, जो अलग से स्टोर की जाती हैं। इम्पोर्ट करने के बाद, API keys अलग से कॉन्फ़िगर करें। सिस्टम एडमिन पूरे ग्लोबल कैटलॉग का बैकअप लेते हैं; संगठन के मालिक केवल अपने ही संगठन के प्रोवाइडर और मॉडल एक्सपोर्ट और इम्पोर्ट करते हैं — शेयर्ड ग्लोबल कैटलॉग को इम्पोर्ट के ज़रिए न बनाया जा सकता है और न ही एडिट किया जा सकता है।