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 दस्तावेज़ प्रोसेस कर सकता है |
| प्रॉम्प्ट कैशिंग | लागत घटाने के लिए प्रॉम्प्ट कैशिंग का समर्थन करता है |
| रीज़निंग | विस्तारित थिंकिंग / चेन-ऑफ-थॉट क्षमताएँ |
| Embeddings | जवाब देने के बजाय टेक्स्ट को वेक्टर में बदलता है — सिमेंटिक ID इसी से रिज़ॉल्व होते हैं। एम्बेडिंग मॉडल अपना अलग परिवार हैं, अपने वेक्टर साइज़ के साथ, और एनरिचमेंट पिकर में कभी नहीं दिखते |
मॉडल का नाम देना वैकल्पिक है। संवर्धन, स्कीमा जनरेशन और सैंपल जनरेशन सभी auto स्वीकार करते हैं — और छोड़े गए मॉडल को auto ही मानते हैं — जिसे सर्वर पर, हर कार्य के लिए, जॉब शुरू होने के क्षण हल किया जाता है। रन बताता है कि उसने कौन-सा मॉडल चुना, इसलिए स्वचालित का मतलब कभी अपारदर्शी नहीं होता।
स्वामी Settings → Organization → Defaults के अंतर्गत प्रति कार्य एक पसंदीदा मॉडल तय कर सकते हैं। यदि मौजूदा कार्य के लिए कोई सेट है, तो वही चुना जाता है।
पिन न होने पर, चुनाव उस मॉडल का होता है जिसका आपके स्कोरिंग-सोर्स बेंचमार्क में ब्लेंडेड स्कोर सबसे अच्छा है — यानी आपकी अपनी स्कीमाओं पर क्वालिटी, स्पीड और लागत के आपके अपने माप। अगर कोई स्कोरिंग सोर्स ही न हो, तो अनुमान लगाने के बजाय रिक्वेस्ट अस्वीकार कर दी जाती है।
वेब सर्च चालू करने पर, या ऐसा दस्तावेज़ अटैच करने पर जिसे ज्यों का त्यों भेजना ज़रूरी है, उम्मीदवार सिर्फ़ उन्हीं मॉडलों तक सीमित हो जाते हैं जो वाकई यह कर सकते हैं — और अगर कोई भी योग्य न हो, तो चुपचाप डाउनग्रेड होने के बजाय आपको स्पष्ट एरर मिलता है।
किसी मॉडल को निष्क्रिय किए बिना एक ही कार्य से भी रोका जा सकता है: जो मॉडल एनरिचमेंट अच्छा करता है पर स्कीमा खराब बनाता है, उसे केवल स्कीमा और सैंपल जनरेशन पिकर से छिपाया जा सकता है — या तो आपके संगठन के लिए, या एडमिनिस्ट्रेटर द्वारा वैश्विक रूप से। बाकी हर जगह वह पूरी तरह उपलब्ध रहता है — नीचे दिए गए निष्क्रियकरण की तुलना में एक नरम उपाय।
बाहरी रजिस्ट्री से सिंक करके मॉडल प्राइसिंग को अप-टू-डेट रखें। सिंक प्रक्रिया नए मॉडल, मूल्य परिवर्तन, और हटाए गए मॉडल को स्वचालित रूप से पहचान लेती है।
डिफ़ॉल्ट मूल्य निर्धारण स्रोत। GitHub पर LiteLLM की समुदाय-द्वारा-अनुरक्षित रजिस्ट्री से वास्तविक API मॉडल नाम, मूल्य निर्धारण, संदर्भ लंबाई, और क्षमताएँ प्राप्त करता है।
लगभग 30 provider को कवर करता है। इसमें डिस्प्ले नाम, benchmark या जनरेशन स्पीड शामिल नहीं है।
pricepertoken.com से एक वैकल्पिक स्रोत। इसमें प्रदर्शन नाम, benchmark (coding और math स्कोर), और generation गति (टोकन प्रति सेकंड) शामिल हैं।
लगभग 20 provider को कवर करता है। LiteLLM की तुलना में अधिक समृद्ध मेटाडेटा प्रदान करता है।
GLM मॉडल आइडेंटिफायर्स के लिए एक आधिकारिक प्रमाणित कैटलॉग, जिसमें प्राइसिंग सीधे Z.AI डॉक्यूमेंटेशन से पार्स की गई है और कैपेबिलिटी गैप्स वहीं रिसर्च किए गए हैं।
पहले LiteLLM और PricePerToken से इम्पोर्ट की गई Z.AI एंट्रीज़ को रिप्लेस करता है।
एक न्यूनतम हेल्थ चेक prompt चलाकर सक्रिय रूप से जाँचें कि models पहुँच योग्य हैं या नहीं। इससे enrichment के दौरान उपयोगकर्ताओं को त्रुटियाँ मिलने से पहले ही खराब models पकड़ में आ जाते हैं।
हेल्थ चेक सभी मॉडलों, किसी विशिष्ट प्रोवाइडर के मॉडलों, या एकल मॉडल पर चलाए जा सकते हैं। परिणाम SSE के माध्यम से रियल टाइम में स्ट्रीम होते हैं और प्रोग्रेस बार पास/फेल गिनती दिखाता है।
जब कोई संवर्धन कॉल “model not found” त्रुटि के साथ विफल होती है, तो बार-बार विफलताओं को रोकने के लिए मॉडल स्वतः निष्क्रिय कर दिया जाता है। यह सामान्य संवर्धन ऑपरेशन के दौरान रीयल टाइम में होता है।
| निष्क्रियकरण का कारण | किसके द्वारा सेट | ऑटो-पुनःसक्रिय? |
|---|---|---|
| मॉडल नहीं मिला | संवर्धन त्रुटियाँ या हेल्थ चेक | हाँ (pricing sync या validation द्वारा) |
| सिंक हटाया गया | मूल्य सिंक (model गायब हो गया) | हाँ (यदि model रजिस्ट्री में फिर से दिखे) |
| मैन्युअल | UI में एडमिन टॉगल | नहीं (केवल मैन्युअल पुनः-सक्रियण) |
संगठन स्वतंत्र बिलिंग और उपयोग ट्रैकिंग के लिए अपनी स्वयं की LLM प्रोवाइडर API कुंजियाँ कॉन्फ़िगर कर सकते हैं। सिस्टम LRU चयन के साथ दो-स्तरीय कुंजी रिज़ॉल्यूशन का उपयोग करता है:
API Keys पेज में कॉन्फ़िगर की गई प्रति-organization कीज़। LRU रोटेशन के साथ प्रति provider अनेक कीज़ का समर्थन करता है। Fernet से एन्क्रिप्टेड।
एडमिनिस्ट्रेटर द्वारा प्रबंधित सिस्टम-व्यापी कुंजियाँ। सभी ऑर्गनाइज़ेशन में साझा। यह LRU रोटेशन के साथ प्रति प्रोवाइडर कई कुंजियों का भी समर्थन करता है।
हर एनरिचमेंट यह रिकॉर्ड करता है कि कौन-सी की इस्तेमाल हुई, ताकि आप प्रति की लागत ट्रैक कर सकें। कीज़ में हेल्थ चेक सपोर्ट और उपयोग काउंटर शामिल हैं। किसी पूल में, सबसे पुराने last-used टाइमस्टैम्प वाली इनेबल्ड की अगली बार चुनी जाती है; कोई की रोटेशन से तभी बाहर होती है जब आप उसे खुद डिसेबल करें, इसलिए किसी प्रोवाइडर एरर से कोई की चुपचाप सेवा से नहीं हटती। कीज़ मैनेज करना सीखने के लिए API Keys गाइड देखें।
बैकअप या किसी अन्य इंस्टेंस में ट्रांसफर के लिए अपने संपूर्ण प्रोवाइडर और मॉडल कॉन्फ़िगरेशन को JSON के रूप में एक्सपोर्ट करें। इम्पोर्ट हमेशा एक upsert होता है: मौजूदा प्रोवाइडर और मॉडल नाम से मैच किए जाते हैं और यथास्थान अपडेट किए जाते हैं, जबकि नए जोड़े जाते हैं — कुछ भी नहीं हटाया जाता।
एक्सपोर्ट में प्रोवाइडर सेटिंग्स, मॉडल कॉन्फ़िगरेशन, प्राइसिंग, क्षमताएँ, और कैननिकल मॉडल स्पेक्स शामिल होते हैं — लेकिन API keys कभी नहीं, जो अलग से स्टोर की जाती हैं। इम्पोर्ट करने के बाद, API keys अलग से कॉन्फ़िगर करें। सिस्टम एडमिन पूरे ग्लोबल कैटलॉग का बैकअप लेते हैं; संगठन के मालिक केवल अपने ही संगठन के प्रोवाइडर और मॉडल एक्सपोर्ट और इम्पोर्ट करते हैं — शेयर्ड ग्लोबल कैटलॉग को इम्पोर्ट के ज़रिए न बनाया जा सकता है और न ही एडिट किया जा सकता है।