ओपन-वेट लार्ज लैंग्वेज मॉडल्स (Open-weight large language models) ने इंजीनियरिंग टीमों के AI इंफ्रास्ट्रक्चर के बारे में सोचने के तरीके को बदल दिया है। क्लोज्ड APIs के विपरीत, जहाँ प्रोवाइडर हार्डवेयर, मॉडल वेट्स और रिलीज़ शेड्यूल को नियंत्रित करता है, ओपन-वेट मॉडल्स वे निर्णय आपको सौंप देते हैं। आप चुनते हैं कि मॉडल कहाँ रहेगा, उसे कैसे ट्यून किया जाएगा, और आप कब—या यदि कभी—एक नए चेकपॉइंट पर अपडेट करेंगे। स्वामित्व का वह स्तर शक्तिशाली है, लेकिन इसका मतलब यह भी है कि इंटीग्रेशन का काम पूरी तरह से आपकी ज़िम्मेदारी है।

यदि आप OpenAI के GPT-4 या Anthropic के Claude जैसे मैनेज्ड API से आ रहे हैं, तो अच्छी खबर यह है कि कई ओपन-वेट होस्टिंग प्रोवाइडर्स और इन्फरेंस इंजन (inference engines) अब एक ही भाषा बोलते हैं: HTTP POST, JSON payloads, और bearer token authentication। इसकी कार्यप्रणाली परिचित लगती है, लेकिन विवरण अधिक महत्वपूर्ण हो जाते हैं क्योंकि विश्वसनीयता, लागत नियंत्रण और व्यवहार को आकार देने के लिए आप जिम्मेदार हैं, प्रोवाइडर नहीं।

API कॉल की बुनियादी बातें

मूल रूप से, इंटीग्रेशन एक POST रिक्वेस्ट है। आप Authorization हेडर में एक स्टैंडर्ड bearer token के साथ ऑथेंटिकेट करते हैं। बॉडी एक JSON ऑब्जेक्ट है, और इसका सबसे महत्वपूर्ण फ़ील्ड messages एरे (array) है। वह एरे परिचित चैट फॉर्मेट का पालन करता है: सिस्टम, यूजर और असिस्टेंट रोल्स का बारी-बारी से आना।

व्यवहार में एक न्यूनतम रिक्वेस्ट स्ट्रक्चर ऐसा दिखता है:

  • Authorization हेडर को Bearer <your-token> पर सेट करें।
  • कम से कम एक model आइडेंटिफायर और एक messages लिस्ट वाला JSON पेलोड भेजें।
  • यदि आप डिटरमिनिस्टिक (deterministic) या क्रिएटिव कंट्रोल चाहते हैं, तो max_tokens और temperature शामिल करें।

रिस्पॉन्स एक choices एरे और एक usage ऑब्जेक्ट के साथ वापस आता है। उस usage ब्लॉक को नज़रअंदाज़ न करें। इसमें prompt_tokens, completion_tokens, और टोटल (total) शामिल होते हैं। यदि आप सेल्फ-होस्टिंग कर रहे हैं, तो यह आपके लिए संकेत है कि क्या कोई विशेष यूजर इंटरेक्शन महंगा है। यदि आप किसी थर्ड-पार्टी इन्फरेंस प्रोवाइडर को भुगतान कर रहे हैं, तो यह आपका बिलिंग डेटा है। किसी भी स्थिति में, पहले दिन से ही इसे लॉग करें।

स्ट्रीमिंग और आपको इसका उपयोग क्यों करना चाहिए

टेक्स्ट का एक छोटा सा हिस्सा दिखने से पहले तीन सेकंड तक लोडिंग स्पिनर को देखते रहना किसी को पसंद नहीं है। स्ट्रीमिंग इसे ठीक करती है। मॉडल के पूरे कंप्लीशन (completion) को खत्म करने का इंतज़ार करने के बजाय, सर्वर टोकन जेनरेट होते ही उन्हें उत्सर्जित (emit) करता है। आपका क्लाइंट Server-Sent Events या chunked HTTP रिस्पॉन्स प्राप्त करता है और शब्द आते ही उन्हें रेंडर कर सकता है।

अपने JSON पेलोड में stream: true फ्लैग सेट करके स्ट्रीमिंग सक्षम करें। क्लाइंट साइड पर, आप आमतौर पर स्ट्रीम को लाइन दर लाइन पार्स करेंगे, और data: प्रीफिक्स पर नज़र रखेंगे। यदि स्ट्रीम के बीच में कनेक्शन टूट जाता है, तो रीकनेक्ट करने या नॉन-स्ट्रीमिंग रिट्राय (non-streaming retry) पर वापस जाने के लिए तैयार रहें। आपके चैट ऐप की महसूस होने वाली लेटेंसी (latency) नाटकीय रूप से कम हो जाती है, और उपयोगकर्ताओं को ऐसा महसूस होता है कि सिस्टम उनके साथ सोच रहा है, न कि उनकी रिक्वेस्ट को बैच-प्रोसेस कर रहा है।

रियल-वर्ल्ड वर्कफ़्लो के लिए फंक्शन कॉलिंग

एक मॉडल जो केवल प्लेन टेक्स्ट लौटाता है वह उपयोगी है, लेकिन एक मॉडल जो टूल्स को इनवोक (invoke) कर सकता है वह कहीं अधिक उपयोगी है। फंक्शन कॉलिंग आपको उपलब्ध ऑपरेशन्स—जैसे, search_orders या update_profile—का वर्णन करने वाला एक JSON स्कीमा परिभाषित करने की अनुमति देता है, और मॉडल तय करता है कि उनका उपयोग कब करना है। यूजर से फॉलो-अप सवाल पूछने के बजाय, यह बातचीत से निकाले गए आर्गुमेंट्स के साथ एक स्ट्रक्चर्ड फंक्शन कॉल उत्सर्जित करता है।

उदाहरण के लिए, यदि कोई यूजर पूछता है, "मेरा पिछला ऑर्डर क्या था?" तो आपका स्कीमा limit पैरामीटर के साथ एक get_recent_orders फंक्शन को परिभाषित कर सकता है। मॉडल एक टूल कॉल लौटाता है, आपका बैकएंड आपके डेटाबेस के खिलाफ क्वेरी चलाता है, और आप परिणाम को फंक्शन रिस्पॉन्स मैसेज के रूप में मॉडल में वापस फीड करते हैं। फिर मॉडल एक नेचुरल-लैंग्वेज उत्तर तैयार करता है।

इसे लागू करने के लिए:

  • अपने पेलोड में एक tools या functions एरे प्रदान करें।
  • प्रत्येक टूल को name, description, और parameters स्कीमा के साथ परिभाषित करें।
  • टूल-कॉल फिनिश रीज़न (finish reason) या इसी तरह के संकेत के लिए रिस्पॉन्स का निरीक्षण करें।
  • अपने बैकएंड में सख्त वैलिडेशन के साथ फंक्शन को निष्पादित करें। कभी भी अनसैनेटाइज्ड (unsanitized) रॉ मॉडल आउटपुट पर भरोसा न करें कि वे आपके डेटाबेस तक पहुँचें।
  • फंक्शन के परिणाम को मैसेज हिस्ट्री में जोड़ें और एक फॉलो-अप रिक्वेस्ट भेजें ताकि मॉडल अंतिम उत्तर दे सके।

यह पैटर्न जेनरेटिव टेक्स्ट और डिटरमिनिस्टिक सिस्टम के बीच के अंतर को पाटता है। आपका AI बिना हर ब्रांच को हार्ड-कोड किए कैलेंडर पढ़ सकता है, API क्वेरी कर सकता है, या वेबहुक (webhooks) ट्रिगर कर सकता है।

प्रोडक्शन के लिए हार्डनिंग

प्रोडक्शन में ओपन-वेट मॉडल्स चलाना आपको किसी भी डिस्ट्रिब्यूटेड सिस्टम की तरह ही फेलियर मोड (failure modes) के संपर्क में लाता है, साथ ही कुछ अद्वितीय मोड भी। मॉडल इन्फरेंस कंप्यूट-इंटेंसिव होता है, और एंडपॉइंट्स लोड के तहत चरमरा सकते हैं। अपने एप्लिकेशन को स्थिर रखने का तरीका यहाँ दिया गया है।

एरर्स और रिट्राइज़

  • 429 Too Many Requests: यह एक रेट-लिमिट (rate-limit) संकेत है। इसमें 'jitter' के साथ 'exponential backoff' लागू करें। एक छोटे विलंब (delay) से शुरुआत करें, बार-बार 429 आने पर इसे दोगुना करते जाएँ, और इसे कुछ सेकंड तक ही सीमित रखें ताकि आप सर्वर पर अत्यधिक दबाव न डालें।
  • 5xx Server Errors: ये आमतौर पर क्षणिक (transient) होते हैं, विशेष रूप से यदि आप GPU वर्कर्स के एक पूल को रूट कर रहे हैं। इन्हें फिर से प्रयास (retry) करें, लेकिन प्रयासों की संख्या पर एक सख्त सीमा लगाएँ—तीन एक सामान्य डिफ़ॉल्ट है।
  • 4xx Client Errors: इन्हें बिना सोचे-समझे फिर से प्रयास न करें। 400 का अर्थ है कि आपका पेलोड (payload) गलत है, 401 का अर्थ है कि आपका टोकन गलत है, और 404 का अर्थ है कि उस एंडपॉइंट पर मॉडल आईडी मौजूद नहीं है। लूप चलाने के बजाय अनुरोध (request) को ठीक करें।

टाइमआउट और हैंगिंग प्रोसेस (Timeouts and Hanging Processes)

इन्फरेंस (Inference) में देरी हो सकती है जब कतारें (queues) बन जाती हैं या जब कोई वर्कर जनरेशन के बीच में क्रैश हो जाता है। हमेशा एक रिक्वेस्ट टाइमआउट सेट करें। यदि आपके HTTP क्लाइंट का डिफ़ॉल्ट 'infinity' है, तो इसे बदल दें। मानक कंपलीशन (completions) के लिए 30 से 60 सेकंड एक उचित शुरुआती बिंदु है, और हेल्थ चेक के लिए इससे कम। यदि टाइमआउट होता है, तो इसे विफलता (failure) मानें, इसे लॉग करें, और तय करें कि उपयोगकर्ता को एक सौम्य त्रुटि (graceful error) दिखानी है या किसी फॉलबैक मॉडल (fallback model) पर फिर से प्रयास करना है।

बजट नियंत्रण (Budget Control)

टोकन की संख्या सीधे पैसे या GPU घंटों में बदल जाती है। प्रत्येक अनुरोध के लिए प्रॉम्प्ट और कंपलीशन दोनों टोकन को लॉग करें। उन्हें प्रति उपयोगकर्ता, प्रति फीचर और प्रति मॉडल वर्ज़न ट्रैक करें। ओपन-वेट मॉडल आपको चेकपॉइंट्स बदलने की अनुमति देते हैं, लेकिन प्रत्येक चेकपॉइंट का अपना लागत प्रोफाइल और कॉन्टेक्स्ट-विंडो (context-window) आकार होता है। लॉग के बिना, आपको पता नहीं चलेगा कि आपके उत्पाद का कौन सा हिस्सा कंप्यूट (compute) खर्च कर रहा है।

सिस्टम मैसेज के साथ व्यवहार को आकार देना (Behavior Shaping with System Messages)

सिस्टम मैसेज आपके नियंत्रण की पहली पंक्ति है। इसका उपयोग टोन सेट करने, बाधाओं को लागू करने और एक स्थिर संदर्भ (static context) डालने के लिए करें जिसका हर उपयोगकर्ता बातचीत को सम्मान करना चाहिए। चूंकि ओपन-वेट मॉडल अपने फाइन-ट्यूनिंग और सिस्टम प्रॉम्प्ट के आधार पर अलग-अलग व्यवहार करते हैं, इसलिए इस फ़ील्ड को एक वेरिएबल की तरह मानें जिसका आप A/B टेस्ट कर सकें। एक अस्पष्ट सिस्टम प्रॉम्प्ट अस्पष्ट उत्तर देता है। एक सटीक प्रॉम्प्ट मॉडल को सही रास्ते पर रखता है—उदाहरण के लिए, असिस्टेंट को यह बताना कि वह केवल बिलिंग और रिटर्न संभालता है, और बाकी सब कुछ विनम्रता से मना कर दे।

इन्फ्रास्ट्रक्चर की स्वतंत्रता और डेटा संप्रभुता (Infrastructure Freedom and Data Sovereignty)

ओपन-वेट मॉडल का एक शांत लाभ कस्टडी (custody) है। आपके प्रॉम्प्ट और कंपलीशन को आपके वातावरण से बाहर जाने की आवश्यकता नहीं है। यदि आप मॉडल को ऑन-प्रिमाइसेस (on-premises) या वर्चुअल प्राइवेट क्लाउड के अंदर चलाते हैं, तो आप तीसरे पक्ष के डेटा प्रोसेसिंग समझौतों को समाप्त कर देते हैं और ट्रेनिंग-डेटा विवादों के जोखिम को कम कर देते हैं। यह स्वास्थ्य सेवा, वित्त और किसी भी ऐसे डोमेन के लिए महत्वपूर्ण है जहाँ डेटा लीक होना एक अनुपालन (compliance) संबंधी घटना है।

भले ही आप एक बाहरी इन्फरेंस होस्ट का उपयोग करते हैं, ओपन वेट्स आपको पोर्टेबिलिटी देते हैं। यदि होस्ट अपनी कीमतें या शर्तें बदलता है, तो आप उन्हीं मॉडल फाइलों को किसी अन्य प्रदाता पर ले जा सकते हैं या उन्हें इन-हाउस ला सकते हैं। आप किसी एक API तक सीमित नहीं हैं क्योंकि केवल एक ही कंपनी के पास वेट्स (weights) होते हैं।

एक व्यावहारिक शुरुआती बिंदु (A Practical Starting Point)

यदि आप आज ही इंटीग्रेशन कर रहे हैं, तो एक एकल मॉडल और एक एकल एंडपॉइंट के साथ शुरुआत करें। अपने HTTP क्लाइंट को एक छोटे एब्स्ट्रैक्शन लेयर (abstraction layer) में लपेटें जो ऑथेंटिकेशन, रिट्राइज़ और टोकन लॉगिंग को संभालता है। इसके बाद स्ट्रीमिंग जोड़ें, क्योंकि इसका उपयोगकर्ता अनुभव पर तुरंत प्रभाव पड़ता है। फिर एक उच्च-मूल्य वाले वर्कफ़्लो के लिए एक फ़ंक्शन कॉल पेश करें—जैसे स्टेटस लुकअप, कंटेंट मॉडरेशन, या फॉर्म भरना। रोलआउट को व्यापक बनाने से पहले एक सप्ताह तक लेटेंसी (latency), एरर रेट और टोकन खर्च की निगरानी करें।

ओपन-वेट मॉडल को पूरी तरह से प्रबंधित (fully managed) API की तुलना में अधिक सेटअप की आवश्यकता होती है, लेकिन वे पारदर्शिता, लचीलेपन और नियंत्रण के साथ उस प्रयास का प्रतिफल देते हैं। इंटीग्रेशन को सावधानी से बनाएं, सब कुछ इंस्ट्रूमेंट करें, और आपके पास एक ऐसा AI लेयर होगा जो ठीक उसी तरह व्यवहार करेगा जैसा आपके एप्लिकेशन को चाहिए।

स्रोत और आगे पढ़ने के लिए (Sources and further reading)