एक AI वर्कफ़्लो को अपने वास्तविक टूल्स और समवर्तीता के लिए संसाधन चाहिए, और ऐसी अनुमतियाँ जो मॉडल के बाहर भी लागू रहें। रिमोट अनुमान और लोकल अनुमान अलग-अलग CPU, मेमोरी, स्टोरेज और GPU निर्णयों की ओर ले जाते हैं।
मशीन चुनने से पहले काम का नाम तय करें
एक AI वर्कर एक मॉडल को ऐसे सॉफ़्टवेयर के साथ जोड़ता है जो कार्य प्राप्त करता है, संदर्भ जुटाता है और टूल्स को कॉल करता है। एक शेड्यूल किया गया दस्तावेज़ वर्गीकरणकर्ता, एक आंतरिक खोज सहायक और एक ब्राउज़र-चालित वर्कफ़्लो की परिचालन आवश्यकताएँ अलग-अलग होती हैं। इनपुट, अपेक्षित आउटपुट, जिन सिस्टमों से यह संपर्क कर सकता है और वह बिंदु लिख लें जहाँ कोई व्यक्ति किसी परिणामकारी कार्रवाई को मंज़ूरी देता है। यह छोटा विनिर्देश आपको होस्ट के बारे में एजेंट लेबल से अधिक बताता है।
एक दोहराए जाने योग्य काम और एक संकीर्ण खाते से शुरू करें। जो वर्कर प्रतिक्रिया का मसौदा तैयार करता है, उसे उस वर्कर से कम अधिकार चाहिए जो उसे भेजता है। इन चरणों को एप्लिकेशन में अलग रखें। सर्वर को स्वीकृत वर्कफ़्लो का समर्थन करना चाहिए, बिना हर उत्पन्न निर्देश को एक निष्पादन योग्य ऑपरेशन बनाए। पूर्णता का अर्थ एक सत्यापित परिणाम या एक स्पष्ट विफलता स्थिति है, न कि अनिश्चित काल तक चलने वाला लूप।
रिमोट मॉडल को लोकल मॉडल से अलग रखें
जब मॉडल किसी बाहरी API के पीछे चलता है, तो VPS मुख्य रूप से कतार, एप्लिकेशन, टूल्स और स्थायी स्थिति को होस्ट करता है। इसकी मेमोरी मांग उन प्रक्रियाओं से आती है, जिनमें कोई भी ब्राउज़र या दस्तावेज़ पार्सर शामिल है। इस मशीन पर एक GPU कहीं और चल रहे मॉडल को तेज़ नहीं करता। रिकॉर्ड करें कि कौन-सी सामग्री API सीमा पार करती है और उस प्रदाता का मूल्यांकन वर्कर के स्थान से स्वतंत्र रूप से करें।
लोकल अनुमान बजट में मॉडल स्टोरेज, मॉडल मेमोरी और रनटाइम संगतता जोड़ता है। Ollama जैसे अनुमान टूल्स CPU या GPU प्लेसमेंट और समवर्ती अनुरोधों के बारे में जानकारी देते हैं। चुने गए मॉडल, संदर्भ लंबाई और समवर्तीता का एक साथ परीक्षण करें। बड़ा संदर्भ या अधिक समवर्ती काम मेमोरी मांग बढ़ा सकते हैं; अकेले मॉडल फ़ाइल का आकार एक अपूर्ण आकार-निर्धारण विधि है। GPU कॉन्फ़िगरेशन चुनने से पहले रनटाइम के समर्थित हार्डवेयर की जाँच करें।
| वर्कर पैटर्न | मुख्य संसाधन प्रश्न | समीक्षा की जाने वाली सीमा |
|---|---|---|
| रिमोट मॉडल API | एप्लिकेशन और टूल मेमोरी | मॉडल प्रदाता को भेजी गई सामग्री |
| लोकल मॉडल | मॉडल, संदर्भ और कार्यशील मेमोरी | रनटाइम और डिवाइस संगतता |
| ब्राउज़र वर्कफ़्लो | शिखर ब्राउज़र प्रक्रियाएँ और अस्थायी फ़ाइलें | वेब सामग्री और अनुमत कार्रवाइयाँ |
एक प्रतिनिधि कतार को मापें
सामान्य और असामान्य रूप से बड़े इनपुट वाले कार्यों का एक छोटा सेट तैयार करें। शिखर मेमोरी, बीता प्रसंस्करण समय, अस्थायी स्टोरेज और बाहरी कॉलों की संख्या मापें। विफलता के मामले भी शामिल करें: एक अनुपलब्ध API, एक विकृत दस्तावेज़ और एक टूल टाइमआउट। ये माप आपके सॉफ़्टवेयर के लिए एक योजना अभ्यास हैं, किसी SwissOctet योजना के लिए बेंचमार्क या प्रदर्शन वादा नहीं।
सक्रिय कार्यों की अधिकतम संख्या और अधिकतम निष्पादन समय निर्धारित करें। जो काम सुरक्षित रूप से शुरू नहीं हो सकता उसे कतार में डालें और अधिभार को पूर्वानुमेय तरीके से अस्वीकार करें। हर विफलता को तुरंत पुनः प्रयास करने से सर्वर का दबाव और API खर्च दोनों कई गुना बढ़ सकते हैं। एक सीमित पुनः प्रयास नीति और एक पहचानकर्ता का उपयोग करें जो एक ही पूर्ण कार्रवाई को दो बार लागू होने से रोके। काम सक्रिय रहने के दौरान ऑपरेटिंग सिस्टम, निगरानी और रखरखाव के लिए क्षमता आरक्षित रखें।
टूल्स को वर्कर की महत्वाकांक्षा से कम अधिकार दें
मॉडल को दिए गए दस्तावेज़ों और वेब पेजों में ऐसे निर्देश हो सकते हैं जो उसे भटकाने के लिए हों। प्राप्त सामग्री को इनपुट मानें, परिचालन अनुमति का स्रोत नहीं। प्रॉम्प्ट इंजेक्शन पर OWASP का मार्गदर्शन नियंत्रण की कई परतों की सिफारिश करता है, जिनमें प्रतिबंधित टूल्स और संवेदनशील कार्रवाइयों के आसपास जाँच शामिल है। अनुमतियाँ टूल के कार्यान्वयन और ऑपरेटिंग वातावरण में रखें, जहाँ मॉडल उन्हें किसी प्रतिक्रिया के माध्यम से फिर से नहीं लिख सकता।
अलग-अलग कामों के लिए अलग-अलग क्रेडेंशियल उपयोग करें, जिनकी पहुँच केवल उन्हीं रिकॉर्ड या निर्देशिकाओं तक हो जिनकी उन्हें आवश्यकता है। मॉडल-जनित शेल कमांड की तुलना में संरचित पैरामीटर को प्राथमिकता दें। फ़ाइल गंतव्यों और बाहरी लक्ष्यों को सत्यापित करें। संदेश भेजने, परिवर्तन प्रकाशित करने या महत्वपूर्ण रिकॉर्ड संशोधित करने के लिए एक जानबूझकर स्वीकृति सीमा आवश्यक रखें। एक केवल-पढ़ने वाले शोध वर्कर और एक उत्पादन प्रशासक को कभी भी समान क्रेडेंशियल विरासत में नहीं मिलने चाहिए, केवल इसलिए कि दोनों एक ही होस्ट पर चलते हैं।
संसाधन नियंत्रण और रिकवरी को स्पष्ट रखें
कंटेनर निर्भरताओं और प्रक्रिया सीमाओं को व्यवस्थित कर सकते हैं, लेकिन उन्हें जानबूझकर कॉन्फ़िगर करना आवश्यक है। Docker दस्तावेज़ करता है कि कंटेनरों पर डिफ़ॉल्ट रूप से कोई संसाधन सीमा नहीं होती। उपयुक्त मेमोरी और CPU सीमाएँ निर्धारित करें, जहाँ समर्थित हो वहाँ एक गैर-विशेषाधिकार प्राप्त प्रक्रिया का उपयोग करें और केवल आवश्यक डेटा माउंट करें। मॉडल एंडपॉइंट और प्रशासन इंटरफ़ेस को प्रतिबंधित रखें, न कि केवल प्रारंभिक परीक्षण को सुविधाजनक बनाने के लिए उन्हें उजागर करें।
कार्य स्थिति को अस्थायी कार्यशील फ़ाइलों से अलग रखें। पुनः आरंभ के बाद पूर्ण किए गए काम को पहचानने के लिए पर्याप्त जानकारी रिकॉर्ड करें, बिना हर प्रॉम्प्ट को हमेशा के लिए संग्रहीत किए। क्रेडेंशियल को लॉग और उत्पन्न आर्टिफ़ैक्ट से सुरक्षित रखें। इनपुट, आउटपुट और नैदानिक डेटा के लिए प्रतिधारण परिभाषित करें। एक रिकवरी परीक्षण में वर्कर को पुनः आरंभ करना चाहिए और सत्यापित करना चाहिए कि अधूरे काम सुरक्षित रूप से फिर से शुरू होते हैं, पूर्ण किए गए काम पूर्ण ही रहते हैं और विफलताएँ ऑपरेटर को दिखाई देती रहती हैं।
पहली तैनाती को एक स्वीकृति परीक्षण बनाएं
व्यापक पहुँच देने से पहले संकीर्ण वर्कफ़्लो को सिंथेटिक या स्वीकृत नमूना डेटा के साथ चलाएँ। उपयोगी आउटपुट, अनुमतियाँ, कतार व्यवहार और विफल निर्भरता से रिकवरी की जाँच करें। पूरी प्रक्रिया का निरीक्षण करें, जिसमें ब्राउज़र की चाइल्ड प्रक्रियाएँ और डेटा डाउनलोड शामिल हैं। यदि मॉडल लोकल है, तो परीक्षण में एक कोल्ड स्टार्ट और समवर्ती अनुरोधों की इच्छित संख्या शामिल करें।
सामान्य वर्करों के लिए Vector या Pulse को विनिर्देश की संक्षिप्त सूची के रूप में उपयोग करें, और Tensor की तुलना केवल तब करें जब अनुमान रनटाइम को उपयुक्त GPU संसाधनों की आवश्यकता हो। वास्तविक ऑर्डर से पहले संगतता और उपलब्धता की पुष्टि करें। वर्कर की अनुमतियाँ तभी बढ़ाएँ जब उसका व्यवहार समीक्षा योग्य हो। लक्ष्य एक ऐसी सेवा है जिसका स्पष्ट परिचालन परिदृश्य, एक मापनीय संसाधन बजट और काम को रोकने और पुनर्प्राप्त करने का सीधा तरीका हो।
आपकी व्यावहारिक चेकलिस्ट।
- एक काम और उसकी स्वीकृति सीमा का वर्णन करें।
- रिमोट API प्रसंस्करण को लोकल अनुमान से अलग रखें।
- टूल्स, ब्राउज़र और शिखर समवर्तीता को मापें।
- समय, संसाधन और अनुमति सीमाएँ लागू करें।
- पूर्ण किए गए कार्यों को दोहराए बिना पुनः आरंभ का परीक्षण करें।
महत्वपूर्ण विवरण।
क्या हर AI वर्कर को GPU चाहिए?+
नहीं। रिमोट मॉडल API को कॉल करने वाले वर्कर को आमतौर पर ऑर्केस्ट्रेशन और टूल्स के लिए संसाधन चाहिए। लोकल अनुमान की हार्डवेयर और रनटाइम आवश्यकताएँ अलग होती हैं।
क्या कंटेनर एक स्वायत्त वर्कफ़्लो को सुरक्षित बनाता है?+
नहीं। इसकी अनुमतियाँ, माउंट, नेटवर्क पहुँच और संसाधन सीमाएँ कॉन्फ़िगर करें, और मॉडल के बाहर परिणामकारी टूल कार्रवाइयों की जाँच करें।
क्या वर्कर को स्विट्ज़रलैंड में होस्ट करने से हर प्रॉम्प्ट वहीं रहता है?+
नहीं। रिमोट मॉडल API और अन्य एकीकरण सामग्री को कहीं और संसाधित कर सकते हैं। उन निर्भरताओं का स्पष्ट रूप से मानचित्रण करें।
स्रोत पर जाएं।
ये संदर्भ इस गाइड में तकनीकी अवधारणाओं का समर्थन करते हैं। उत्पादन प्रणाली बदलने से पहले वर्तमान दस्तावेज़ का पालन करें।
- Docker: संसाधन बाधाएँ docs.docker.com
- OWASP: LLM प्रॉम्प्ट इंजेक्शन रोकथाम cheatsheetseries.owasp.org
- Ollama: रनटाइम और समवर्तीता FAQ docs.ollama.com
SwissOctet द्वारा संपादकीय मार्गदर्शन। उदाहरण केवल दृष्टांत हैं। सेवा विशिष्टताएं, उपलब्ध विकल्प और संविदात्मक शर्तें अलग से सत्यापित की जानी चाहिए।