अनदेखी संस्करण संबंधी समस्याएं एआई अनुमान प्रदर्शन को प्रभावित कर रही हैं
<पी> मॉडल वापस नहीं आया। आपने कोई बग नहीं भेजा. प्लेटफ़ॉर्म ने इसे बदल दिया। <पी> आपका उत्पादन एआई एप्लिकेशन कुछ ऐसी चीज़ों पर निर्भर करता है, जिन्हें अधिकांश टीमों को एहसास नहीं होता है कि उन्होंने नियंत्रण सौंप दिया है:उनके समापन बिंदु के पीछे मॉडल का व्यवहार। वास्तविकता यह है कि एक मॉडल कोई निश्चित कलाकृति नहीं है। यह एक गतिशील लक्ष्य है. प्रतिस्पर्धी बने रहने के लिए, प्लेटफ़ॉर्म लगातार वज़न अपडेट करते हैं, परिमाणीकरण स्तर बदलते हैं, अनुमान इंजनों को अपग्रेड करते हैं, हार्डवेयर में ट्रैफ़िक को फिर से रूट करते हैं, और कभी-कभी मॉडल को पूरी तरह से बदल देते हैं - समापन बिंदु नाम को बदले बिना। <पी> जब ऐसा होता है, तो आपका एप्लिकेशन इसके साथ बदल जाता है। आउटपुट शिफ्ट. संकेत काम करना बंद कर देते हैं. सावधानी से किया गया व्यवहार ख़राब हो जाता है। और आप आमतौर पर चैंजलॉग से पता नहीं लगाते हैं:आप किसी उपयोगकर्ता से पता लगाते हैं। <पी> यह आधुनिक एआई बुनियादी ढांचे का छिपा हुआ जोखिम है:आप एक ऐसी प्रणाली के शीर्ष पर निर्माण कर रहे हैं जो किसी भी समय आपके नीचे बदल सकती है, इस बात की कोई गारंटी नहीं है कि कल "वही मॉडल" वही मॉडल होगा जिसे आपने आज परीक्षण किया है। यह आलेख बताता है कि व्यवहार में यह कैसा दिखता है, ऐसा क्यों होता है, और लगभग किसी भी मंच ने इसे अच्छी तरह से क्यों हल नहीं किया है - और टीमें इससे निपटने के लिए क्या कर रही हैं। <पी> जिस मॉडल के साथ आपने भेजा है वह वह मॉडल नहीं है जिसे आप चला रहे हैं। मुख्य बातें
- "मॉडल संस्करण" डिज़ाइन द्वारा अधूरा है:जो एकल मॉडल जैसा दिखता है वह वास्तव में चलने वाले हिस्सों का ढेर है - वजन, अनुमान इंजन, हार्डवेयर, रूटिंग और रेलिंग - जिनमें से सभी एंडपॉइंट नाम बदले बिना स्वतंत्र रूप से बदल सकते हैं।
- मूक परिवर्तन वास्तविक उत्पादन जोखिम पैदा करते हैं:ये अपडेट पुनरुत्पादन क्षमता को तोड़ देते हैं, शीघ्र ट्यूनिंग को अमान्य कर देते हैं, और ऐसे प्रतिगमन पेश करते हैं जिनका टीमें अक्सर उपयोगकर्ताओं के प्रभावित होने के बाद ही पता लगाती हैं - प्लेटफ़ॉर्म दृश्यता या निगरानी के माध्यम से नहीं।
- अंतर तकनीकी नहीं है - यह पारदर्शिता और स्वामित्व है:प्लेटफ़ॉर्म पहले से ही इन परिवर्तनों को आंतरिक रूप से ट्रैक करते हैं लेकिन उन्हें उजागर नहीं करते हैं; जैसे-जैसे एआई उत्पादन-महत्वपूर्ण हो जाता है, पूर्ण-स्टैक संस्करण, चेंजलॉग और प्रतिलिपि प्रस्तुत करने योग्य गारंटी प्लेटफ़ॉर्म चयन में प्रमुख मानदंड बन जाएंगे।
संस्करण समस्या का आकार
<पी> 
वास्तव में "समान मॉडल" का क्या मतलब है
<पी> एक मॉडल समापन बिंदु एक भी अपरिवर्तनीय कलाकृति नहीं है। यह इसका एक विन्यास है: - अंतर्निहित मॉडल वजन (जो स्वयं मूल से परिमाणित, छंटाई या आसुत किया गया हो सकता है)
- उन्हें चलाने वाला अनुमान इंजन (चाहे वह vLLM, TensorRT-LLM, SGLang, या मालिकाना इंजन हो - प्रत्येक थोड़ा अलग आउटपुट उत्पन्न करता है)
- GPU जनरेशन और मेमोरी लेआउट
- टोकनाइज़र संस्करण और कोई भी लागू चैट टेम्पलेट
- सिस्टम प्रॉम्प्ट प्लेटफ़ॉर्म वह इंजेक्ट कर सकता है जो आपने कभी नहीं देखा
- मॉडल के सामने बैठी सुरक्षा, संयम, या रेलिंग परत
- रूटिंग लॉजिक जो तय करता है कि कौन सी प्रतिकृति या क्षेत्र आपके अनुरोध को संभालेगा
<पी> इनमें से कोई भी मॉडल का नाम बदले बिना बदल सकता है। समझने वाली बात यह है कि उनमें से अधिकांश उत्पादन अनुप्रयोग के पूरे जीवनकाल में नियमित रूप से बदलते रहते हैं। एआई उत्पादों के विकास के लिए यह परिवर्तन आवश्यक है क्योंकि अंतर्निहित तकनीक, आमतौर पर प्रत्येक परिवर्तन के साथ बेहतर होती है। यह वृद्धिशील परिवर्तन एआई सॉफ्टवेयर उद्योग का एक मुख्य हिस्सा है। मूक परिवर्तन की तीन श्रेणियां
<पी> पहली श्रेणी स्पष्ट संस्करण अपडेट है जहां प्लेटफ़ॉर्म बदलता है जो एंडपॉइंट बिंदुओं को महत्व देता है। उदाहरण के लिए, "GPT-4" समय के साथ कई अलग-अलग मॉडल रहे हैं, और क्लाउड एंडपॉइंट नियमित रूप से अपडेट होते रहते हैं। होस्ट किए गए प्लेटफ़ॉर्म पर ओपन-सोर्स मॉडल एंडपॉइंट अक्सर अपस्ट्रीम रिलीज़ को स्वचालित रूप से ट्रैक करते हैं। <पी> दूसरी श्रेणी बुनियादी ढांचे-स्तर के बदलावों की है जहां वजन वही रहता है लेकिन सर्विंग स्टैक में कुछ बदलाव होता है। इसके कुछ उदाहरणों में शामिल हैं: - अनुमान इंजन अपग्रेड हो जाते हैं
- लागत कारणों से परिमाणीकरण स्तर बदलता है
- रूटिंग निर्णय अलग-अलग तैनाती के बीच ट्रैफ़िक को स्थानांतरित करते हैं जिन्हें समकक्ष माना जाता था लेकिन ऐसा नहीं है।
<पी> तीसरी श्रेणी प्लेटफ़ॉर्म-स्तरीय परिवर्धन से व्यवहारिक परिवर्तन है:नई मॉडरेशन परतें, परिवर्तित सिस्टम संकेत, जोड़े गए सुरक्षा फ़िल्टर, या संशोधित चैट टेम्पलेट। इन परिदृश्यों में, मॉडल एक ही है, लेकिन मॉडल को क्या प्राप्त होता है और उपयोगकर्ता को क्या प्राप्त होता है, वे भिन्न होते हैं। प्रत्येक श्रेणी वास्तव में मॉडल व्यवहार को कैसे प्रभावित करती है
मूक प्रतिगमन समस्या
<पी> साइलेंट रिग्रेशन मॉडल आउटपुट गुणवत्ता में गिरावट है, जो सर्विंग स्टैक में कहीं बदलाव के कारण होता है, जिसकी कभी घोषणा नहीं की गई, कभी दस्तावेजीकरण नहीं किया गया, और कभी भी संस्करण बम्प से बंधा नहीं हुआ। समापन बिंदु पर मॉडल का नाम वही है. एपीआई अनुबंध वही है. आपके द्वारा भेजा गया अनुरोध पिछले महीने भेजे गए अनुरोध के समान बाइट है। लेकिन प्रतिक्रिया की गुणवत्ता में गिरावट आई है - कभी-कभी सूक्ष्म रूप से, कभी-कभी तीव्र रूप से - और प्लेटफ़ॉर्म की सार्वजनिक सतह पर कुछ भी आपको यह नहीं बताता कि ऐसा क्यों है। <पी> तंत्र लगभग हमेशा पहले से तीन परिवर्तन श्रेणियों में से एक है:वजन चुपचाप अद्यतन किया गया था, बुनियादी ढांचे में कुछ स्थानांतरित किया गया था, या एक प्लेटफ़ॉर्म-स्तरीय परत (एक नया रेलिंग, एक संशोधित सिस्टम प्रॉम्प्ट, एक कड़ा मॉडरेशन फ़िल्टर) जोड़ा या बदला गया था। बाहर से, तीनों एक जैसे दिखते हैं - आपके आउटपुट खराब हो गए और प्लेटफ़ॉर्म ने आपको नहीं बताया। अंदर से, वे अलग-अलग समाधानों के साथ अलग-अलग मूल कारण हैं, और प्लेटफ़ॉर्म के सहयोग के बिना आपके पास उन्हें अलग करने का कोई तरीका नहीं है। <पी> जो चीज़ साइलेंट रिग्रेशन को सामान्य मॉडल ड्रिफ्ट से अलग बनाती है, वह है सूचना की विषमता। प्लेटफ़ॉर्म जानता है कि क्या बदला है। आप नहीं और क्योंकि आपकी निगरानी लगभग निश्चित रूप से एक सुनहरे डेटासेट पर आउटपुट गुणवत्ता के बजाय अपटाइम, विलंबता और त्रुटि दर को माप रही है, आपके स्वामित्व वाले किसी भी डैशबोर्ड पर दिखाई देने से पहले प्रतिगमन आपके उपयोगकर्ताओं तक फैल जाता है। जब तक आप पुष्टि करते हैं कि प्रतिगमन वास्तविक है, इसे अपने कोड के बजाय मॉडल से अलग करें, और एक समर्थन टिकट खोलें, प्लेटफ़ॉर्म आमतौर पर पहले से ही अगले मौन परिवर्तन पर आगे बढ़ चुका है। आप आधी जानकारी के साथ एक गतिशील लक्ष्य को डीबग करना समाप्त कर देते हैं, जबकि आपके उपयोगकर्ता किसी अपस्ट्रीम में लिए गए निर्णय की लागत को वहन करते हैं जिसके बारे में आपको कभी नहीं बताया गया था। <पी> यह इस अनुभाग की चार समस्याओं में से सबसे खराब है क्योंकि यह एकमात्र ऐसी समस्या है जहां प्लेटफ़ॉर्म ऐसी जानकारी रखता है जो समस्या को तुरंत हल कर देगी और इसे साझा नहीं करने का विकल्प चुनता है। पुनरुत्पादन विफलता, त्वरित ऋण, और मूल्यांकन-से-उत्पाद बहाव ऐसे सभी लक्षण हैं जिनका टीमें कम से कम स्वयं निदान कर सकती हैं। साइलेंट रिग्रेशन वह है जहां आपको जिस डायग्नोस्टिक टूल की आवश्यकता होती है वह एपीआई के दूसरी तरफ होता है। पुनरुत्पादन समस्या
<पी> जबकि जीपीटी मॉडल, एक लोकप्रिय एआई परिनियोजन प्रकार के एक उत्कृष्ट उदाहरण के रूप में, स्वभाव से संभाव्य हैं, फिर भी आप एक ही संकेत के साथ एक ही मॉडल का उपयोग करते समय समान उत्तर प्राप्त करने की उम्मीद कर सकते हैं। लेकिन, जब पहले वर्णित कोई भी परिवर्तन होता है, तो आपको कल प्राप्त आउटपुट आज पुन:प्रस्तुत नहीं किया जा सकता है। यह पुनरुत्पादन समस्या की जड़ है:कोई मॉडल कैसे व्यवहार करेगा इसकी कोई भी अपेक्षा इनमें से किसी भी परिवर्तन से अमान्य हो सकती है। <पी> स्वचालित मूल्यांकन करने वाले या मॉडल संस्करणों की एक-दूसरे से तुलना करने वाले अनुप्रयोगों के लिए, यह मौलिक धारणा को तोड़ता है कि समान इनपुट समान बीज दिए जाने पर समान (या संभाव्य मॉडल के मामले में समान) आउटपुट उत्पन्न करते हैं। जब अंतर्निहित स्टैक आपके नीचे स्थानांतरित हो रहा हो तो तापमान शून्य वास्तव में आपको नियतिवाद नहीं देता है। त्वरित इंजीनियरिंग ऋण समस्या <पी> टीमें अक्सर एक विशिष्ट मॉडल की विशिष्टताओं के लिए संकेतों को ट्यून करने और उन्हें अपने उपयोगकर्ताओं की आवश्यकताओं को बेहतर ढंग से पूरा करने के लिए अनुकूलित करने में कई सप्ताह बिताती हैं। जब उस मॉडल को चुपचाप बदल दिया जाता है या अद्यतन किया जाता है, तो वह सारा ट्यूनिंग कार्य आंशिक ऋण में बदल जाता है। जब संकेत जो एक मॉडल के विफलता मोड को संभालने के लिए सावधानीपूर्वक बनाए गए थे, अब थोड़ा अलग विफलता मोड के साथ थोड़ा अलग मॉडल का सामना करते हैं, तो आपके उपयोगकर्ताओं का अंतिम व्यवहार बदल जाता है। ईवल-टू-प्रोडक्शन ड्रिफ्ट समस्या
<पी> यहां एक और सामान्य परिदृश्य है:आप अपने परीक्षण सेट के विरुद्ध एक मॉडल संस्करण का मूल्यांकन करते हैं, और बाद में इसे उत्पादन के लिए भेजते हैं। लेकिन उत्पादन समापन बिंदु अब आपके द्वारा मूल्यांकन किए गए मॉडल का उपयोग नहीं कर रहा है, भले ही समापन बिंदु पर नाम समान हो। एक बार फिर, इसका अंतिम उत्पाद के व्यवहार पर उल्लेखनीय प्रभाव पड़ सकता है। प्लेटफ़ॉर्म वास्तव में क्या करते हैं
<पी> यह अनुभाग बताता है कि सार्वजनिक दस्तावेज़ीकरण और अवलोकन योग्य व्यवहार के आधार पर प्रमुख अनुमान प्लेटफ़ॉर्म किस प्रकार संस्करण को संभालते हैं। OpenAI-शैली संस्करण
<पी> OpenAI स्नैपशॉट को स्पष्ट रूप से पिन करता है (gpt-4-0613, gpt-4o-2024-08-06) और आपको उन्हें लक्षित करने देता है। उपनामित समापनबिंदु (gpt-4, gpt-4o) वर्तमान डिफ़ॉल्ट जो भी है, उस पर इंगित करते हैं, जो समय के साथ बदलता है। जो टीमें स्नैपशॉट को पिन करना नहीं जानती हैं उन्हें वर्तमान संस्करण मिलता है, और उपनाम उनके अंतर्गत स्थानांतरित हो सकता है। <पी> हालाँकि, OpenAI विभिन्न कारणों से अपने मॉडल बदलता है। इसका एक उदाहरण चाटुकारिता घटना है। GPT-4o कथित तौर पर 'अत्यधिक चापलूसी करने वाला या स्वीकार्य था - जिसे अक्सर चाटुकारिता के रूप में वर्णित किया जाता है,' और OpenAI ने अंततः मॉडल (स्रोत) को अस्वीकृत करने से पहले रोलआउट सुधारों की एक श्रृंखला जारी की। मॉडल के अंततः अपमान ने और अधिक लहरें पैदा कर दीं क्योंकि लोगों ने मॉडल के नुकसान पर शोक व्यक्त किया। <पी> साइकोफैंसी घटना को जो शिक्षाप्रद बनाता है, वह स्वयं व्यक्तित्व परिवर्तन नहीं है - यह वह है जो समापन बिंदु अनुबंध के बारे में बताता है। चाटुकारिता रोलआउट से पहले, उसके दौरान और बाद में gpt-4o को कॉल करने वाली टीमें एक ही समापन बिंदु नाम लेकिन सार्थक रूप से अलग-अलग मॉडल पर काम कर रही थीं। पूर्व-चाटुकारिता संस्करण के विरुद्ध ट्यून किए गए एक ग्राहक सहायता बॉट को अपने उत्पादन जीवनकाल के दौरान एक गर्म, अधिक अनुकूल मॉडल का सामना करना पड़ा होगा, फिर ओपनएआई ने पाठ्यक्रम को सही करने पर एक तीसरे व्यवहार प्रोफ़ाइल का सामना किया, और एक चौथाई जब मॉडल को अंततः हटा दिया गया था। इनमें से किसी भी बदलाव के लिए ग्राहक की ओर से कोड परिवर्तन की आवश्यकता नहीं थी। उनमें से किसी ने भी समापन बिंदु स्ट्रिंग पर संस्करण बम्प ट्रिगर नहीं किया। एक ही दो-पंक्ति एपीआई कॉल ने महीनों के दौरान चार अलग-अलग व्यवहार व्यवस्थाएं तैयार कीं, और अधिकांश टीमों को एकमात्र संकेत यह मिला कि उनके उपयोगकर्ता उन्हें बता रहे थे कि उत्पाद अलग लगा। ओपनएआई का दृष्टिकोण अन्य की तुलना में बेहतर है क्योंकि यह आपको पुराने मॉडल संस्करणों का उपयोग करने का विकल्प देता है, जब तक ओपनएआई अभी भी उन्हें सेवा दे रहा है। लेकिन, यह अभी भी ध्यान देने योग्य है कि चयन मैन्युअल है और उन लोगों के लिए ऐसा करना मुश्किल होगा जो यह जानने के लिए शोध नहीं करते हैं कि मॉडल को पुराने संस्करणों में कैसे बदला जाए। एंथ्रोपिक का दृष्टिकोण
<पी> एंथ्रोपिक दिनांकित मॉडल पहचानकर्ताओं (क्लाउड-ओपस-4-5-20251101 शैली) का उपयोग करता है। पिन लगाने का काम करता है. लेकिन प्लेटफ़ॉर्म-स्तरीय सिस्टम प्रॉम्प्ट इंजेक्शन और सुरक्षा परत मॉडल संस्करण से स्वतंत्र रूप से विकसित होती है, इसलिए अलग-अलग दिनों में एक ही पिन किए गए मॉडल के लिए दो अनुरोध अलग-अलग व्यवहार कर सकते हैं क्योंकि मॉडल के आसपास क्या हो रहा है, उसमें नहीं। यह पारदर्शिता से एक कदम दूर है, लेकिन मुख्य मॉडल का चयन OpenAI के समान ही है। <पी> एंथ्रोपिक से मूक प्रतिगमन का एक उदाहरण हाल ही में एक उल्लेखनीय जीथब अंक में हुआ, जहां एक प्रमुख एआई डेवलपर ने अपने जटिल इंजीनियरिंग कार्य में क्लाउड ओपस मॉडल के स्पष्ट "नर्फिंग" को बताया। उन्होंने बताया कि क्लाउड ने निर्देशों को अनदेखा करना शुरू कर दिया था, यह दावा करते हुए कि "सरल सुधार" गलत हैं, अनुरोधित गतिविधियों के विपरीत काम कर रहे थे, और उन्होंने दावा किया कि मॉडल ने निर्देशों के विपरीत पूरा किया। यह सब उपयोग किये जा रहे मॉडल में किसी कथित बदलाव के बिना। इस मौन परिवर्तन का क्लाउड के डेवलपर्स द्वारा उसी सूत्र में खंडन किया गया था, लेकिन इस बात पर व्यापक सहमति है कि टिप्पणी पर प्रतिक्रिया के आधार पर अन्य उपयोगकर्ताओं से बदलाव हुआ था। <पी> 'समान मॉडल' हमेशा से एक मार्केटिंग अमूर्त रहा है। होस्टेड ओपन-सोर्स मॉडल
<पी> ओपन-सोर्स मॉडल (बेसटेन, फायरवर्क्स, टुगेदर, डिजिटलओशन, नेबियस टोकन फैक्ट्री, मोडल) होस्ट करने वाले प्लेटफ़ॉर्म अक्सर अंतर्निहित मॉडल के बाद एंडपॉइंट का नाम देते हैं, जैसे कि "llama-3.1-70b-instruct", बिना यह उजागर किए कि कौन सा विशिष्ट परिमाणीकरण, कौन सा अनुमान इंजन संस्करण, या कौन सा परिनियोजन कॉन्फ़िगरेशन वास्तव में अनुरोध को पूरा कर रहा है। यह एक बड़ी समस्या हो सकती है, क्योंकि मॉडल का प्रदर्शन एक ही नाम होने पर अलग-अलग प्लेटफॉर्म पर अलग-अलग होगा। उनमें से किसी के भी अपडेट आमतौर पर मॉडल संस्करण में बदलाव के रूप में सूचित नहीं किए जाते हैं। जब ओपन-सोर्स होस्टिंग प्रदाताओं की बात आती है, तो सर्वर रहित अनुमान परिदृश्यों में अंतर्निहित मॉडल परिनियोजन में किसी भी बदलाव के बारे में शोध करने का दायित्व उपयोगकर्ता पर होता है। कस्टम परिनियोजन में, चीजें थोड़ी भिन्न होती हैं। कस्टम परिनियोजन
<पी> जब आप अपना खुद का मॉडल मॉडल या बेसटेन जैसे प्लेटफॉर्म पर तैनात करते हैं, तो वर्जनिंग स्टोरी आपके पास होती है। यह आपके डाउनस्ट्रीम उत्पादों के लिए पुनरुत्पादन, उत्पादन पर नियंत्रण और मॉडल परिवर्तनों के प्रबंधन के लिए सबसे साफ स्थिति है, लेकिन इसका मतलब है कि मॉडल जीवनचक्र के प्रबंधन का परिचालन बोझ स्वयं उठाना। स्केलिंग करते समय इस ट्रेडऑफ़ पर विचार करना महत्वपूर्ण है, क्योंकि परिवर्तनों को प्रबंधित करने के लिए डेवलपर को समय की आवश्यकता होती है। टीमें इसके बारे में क्या कर रही हैं
<पी> नीचे दिए गए अनुभाग टीमों द्वारा अपनाए गए सामान्य समाधानों को कवर करते हैं। उनमें से कोई भी पूरी तरह से समस्या का समाधान नहीं करता है, लेकिन वे प्रत्येक सही दिशा में कदम उठाते हैं। जब संभव हो तो स्नैपशॉट पिन करना <पी> जब प्लेटफ़ॉर्म दिनांकित स्नैपशॉट प्रदर्शित करता है, तो उन्हें पिन करना टेबल स्टेक होता है। लेकिन हर प्लेटफ़ॉर्म उन्हें उजागर नहीं करता है, और पिन किए गए स्नैपशॉट अंततः बहिष्कृत हो जाते हैं। अपने AI उत्पादों के लिए अपने मॉडल को होस्ट करने के लिए कौन सा प्लेटफ़ॉर्म सावधानी से चुनते समय इस पर विचार करें, अन्यथा आप ऐसी स्थिति में पहुँच सकते हैं जहाँ आपका मॉडल बिना किसी बैकअप योजना के चला गया है। गोल्डन डेटासेट रिग्रेशन परीक्षण
<पी> गोल्डन डेटासेट रिग्रेशन परीक्षण वह जगह है जहां आप एक शेड्यूल पर उत्पादन समापन बिंदुओं के माध्यम से इनपुट का एक निश्चित सेट चलाते हैं और आउटपुट को ज्ञात-अच्छी आधार रेखा के विरुद्ध भिन्न करते हैं। यह प्रक्रिया आपको गुणवत्ता प्रतिगमन और अन्य महत्वपूर्ण मॉडल व्यवहार परिवर्तनों को आसानी से पकड़ने की अनुमति देती है, लेकिन इसे बनाए रखना महंगा है, और केवल उन पैटर्न को कवर कर सकता है जिन्हें आपने निरीक्षण करने के बारे में सोचा था। नियमित गोल्डन डेटासेट रिग्रेशन परीक्षण से उस भयावह खबर को रोका जा सकता है कि किसी ग्राहक को आपके उत्पाद के व्यवहार में बदलाव का पता आपसे पहले ही चल गया था। आउटपुट सैंपलिंग और लॉगिंग
<पी> यह बाद के विश्लेषण के लिए उत्पादन अनुरोधों और प्रतिक्रियाओं का नमूना प्रतिशत लॉग करने की प्रक्रिया है। यह आपको तथ्य के बाद बहाव का पता लगाने देता है, लेकिन फिर भी नमूनाकरण, भंडारण और विश्लेषण के बुनियादी ढांचे को स्वयं बनाने की आवश्यकता होती है। छाया परिनियोजन
<पी> आप वर्तमान उत्पादन समापन बिंदु और एक उम्मीदवार नए समापन बिंदु के विरुद्ध एक ही अनुरोध चला सकते हैं, और आउटपुट की तुलना करके देख सकते हैं कि यह मॉडल व्यवहार को कैसे प्रभावित करता है। यह आपके द्वारा किए जा रहे परिवर्तनों के मूल्यांकन के लिए उत्कृष्ट रूप से काम करता है; यह आपके अंतर्गत प्लेटफ़ॉर्म द्वारा किए गए परिवर्तनों में सहायता नहीं करता है। मॉडल को स्वयं-होस्ट करना
<पी> अंतिम नियंत्रण कदम:अपने नियंत्रण वाले बुनियादी ढांचे पर मॉडल को स्वयं चलाएं। यह आपको आपके द्वारा उपयोग किए जा रहे वजन, अनुमान इंजन, परिमाणीकरण और आउटपुट को प्रभावित करने वाली किसी भी चीज़ पर पूर्ण नियंत्रण रखने की अनुमति देता है। यह मॉडल होस्टिंग के परिचालन बोझ के लिए संस्करण समस्या का व्यापार करता है, यही कारण है कि अधिकांश टीमें ऐसा नहीं करती हैं। संस्करण की वास्तव में लागत क्या है
अवलोकन कर
<पी> प्रत्येक टीम जो आउटपुट गुणवत्ता की परवाह करती है, वह अपने स्वयं के मूल्यांकन बुनियादी ढांचे का निर्माण कर रही है क्योंकि प्लेटफ़ॉर्म इसे प्रदान नहीं करते हैं। यह पूरे उद्योग में दोहराए जाने वाला कार्य है - शीघ्र प्रतिगमन ढाँचे, आउटपुट भिन्न उपकरण, गुणवत्ता निगरानी प्रणाली इत्यादि, सभी एप्लिकेशन टीमों द्वारा बनाए जा रहे हैं जो अपने वास्तविक उत्पाद का निर्माण करना चाहते हैं। विश्वास कर <पी> जब आपका एआई फीचर टूट जाता है क्योंकि मॉडल आपके नीचे स्थानांतरित हो जाता है, तो उपयोगकर्ताओं को "एआई अविश्वसनीय है" और "प्लेटफ़ॉर्म ने चुपचाप मॉडल को अपडेट कर दिया है" के बीच अंतर नहीं पता चलता है। आपका उत्पाद अपस्ट्रीम में लिए गए निर्णयों की प्रतिष्ठित लागत को अवशोषित करता है। माइग्रेशन टैक्स
<पी> प्लेटफ़ॉर्म स्विच करने पर विचार करने वाली टीमों को न केवल एपीआई अंतर, बल्कि विभिन्न प्लेटफ़ॉर्म पर समान-नामित मॉडल के बीच व्यवहारिक अंतर को भी ध्यान में रखना होगा। फायरवर्क्स पर "लामा 3.1 70बी" आवश्यक रूप से टुगेदर पर "लामा 3.1 70बी" के समान नहीं है - वे एक अलग परिमाणीकरण हो सकते हैं, एक अलग अनुमान इंजन का उपयोग कर सकते हैं, या एक पूरी तरह से अलग रेलिंग स्टैक हो सकते हैं। स्पष्टता की कमी के कारण व्यापक परीक्षण के बिना प्रदाताओं के बीच स्विच करना मुश्किल हो जाता है। क्या बेहतर लगेगा
<पी> 2026 में एक गंभीर अनुमान मंच को मॉडल व्यवहार को उसी तरह व्यवहार करना चाहिए जिस तरह क्लाउड प्रदाता अपटाइम को मानते हैं:एक संविदात्मक सतह के रूप में, ब्लैक बॉक्स के रूप में नहीं। <पी> वर्तमान स्थिति कोई तकनीकी सीमा नहीं है - यह एक प्रकटीकरण अंतर है। वज़न, इंजन, परिमाणीकरण स्तर और रूटिंग निर्णयों को ट्रैक करने के लिए बुनियादी ढाँचा पहले से ही मौजूद है; प्लेटफ़ॉर्म इसे उजागर नहीं करते। <पी> व्यवहार में ऐसा ही दिखता है। - <पी> पूर्ण संस्करण पहचानकर्ताआज के मॉडल नाम कभी-कभी वजन की पहचान करते हैं। उन्हें पूर्ण सर्विंग कॉन्फ़िगरेशन की पहचान करनी चाहिए. एक पूर्ण संस्करण स्ट्रिंग वह सब कुछ कैप्चर करती है जो समापन बिंदु से बाहर आने वाली चीजों को बदल सकती है:वजन (मात्राकरण स्तर के साथ), अनुमान इंजन और संस्करण, हार्डवेयर पीढ़ी, टोकननाइज़र संस्करण, चैट टेम्पलेट, और कोई प्लेटफ़ॉर्म-इंजेक्टेड सिस्टम प्रॉम्प्ट या रेलिंग परत। llama-3.1-70b-instruct.fp8.vllm-0.6.3.h100.tmpl-v2.guardrail-v4 जैसा कुछ बदसूरत लेकिन ईमानदार है। टीमें किसी भी घटक को पिन कर सकती हैं जिस पर वे निर्भर हैं और दूसरों के बदलने पर सूचनाएं प्राप्त कर सकती हैं।
- <पी> जब वे मॉडल भार अपडेट करते हैं तो संपूर्ण स्टैकप्लेटफ़ॉर्म के लिए चेंजलॉग फ़ीड रिलीज़ नोट्स प्रकाशित करते हैं। जब वे वीएलएलएम को अपग्रेड करते हैं, लागत कारणों से परिमाणीकरण बदलते हैं, या क्षेत्रों के बीच ट्रैफ़िक को फिर से रूट करते हैं, तो वे शायद ही कभी कुछ प्रकाशित करते हैं। एक उचित चेंजलॉग फ़ीड - आदर्श रूप से मशीन-पठनीय - टाइमस्टैम्प और प्रभावित समापन बिंदुओं के साथ सर्विंग स्टैक की प्रत्येक परत को कवर करेगी। टीमों को एक विशिष्ट पिन किए गए कॉन्फ़िगरेशन के लिए परिवर्तनों की सदस्यता लेने में सक्षम होना चाहिए और रोलआउट से पहले अलर्ट प्राप्त करना चाहिए, उपयोगकर्ता की शिकायत के बाद नहीं।
- <पी> बताए गए प्रतिधारण के साथ पुनरुत्पादन की गारंटी देता है। पिन किए गए स्नैपशॉट का कुछ मतलब होना चाहिए। प्लेटफ़ॉर्म को एक निर्दिष्ट अवधारण विंडो के लिए प्रतिबद्ध होना चाहिए - मान लीजिए, 12 या 24 महीने - जिसके दौरान एक पिन किया गया कॉन्फ़िगरेशन शून्य तापमान पर समान इनपुट के लिए बाइट-समान आउटपुट लौटाएगा, न कि केवल वज़न के लिए, पूर्ण स्टैक के लिए। जब वह विंडो समाप्त हो जाती है, तो टीमों को अग्रिम सूचना और माइग्रेशन पथ मिलता है। इस प्रकार डेटाबेस और ऑपरेटिंग सिस्टम वर्जनिंग को संभालते हैं। ऐसा कोई कारण नहीं है कि अनुमान भिन्न हो।
- <पी> प्लेटफ़ॉर्म-प्रदत्त प्रतिगमन परीक्षण प्रत्येक गंभीर टीम अलगाव में समान मूल्यांकन बुनियादी ढांचे का निर्माण कर रही है। प्लेटफ़ॉर्म को इसे प्रथम श्रेणी की सुविधा के रूप में प्रदान करना चाहिए:एक सुनहरा डेटासेट पंजीकृत करें, इसे अपने पिन किए गए एंडपॉइंट के विरुद्ध शेड्यूल पर चलाएं, और जब आउटपुट आपके द्वारा निर्धारित सीमा से परे चला जाए तो सतर्क हो जाएं। स्नैपशॉट के बीच अंतर परीक्षण के लिए बोनस अंक, ताकि टीमें यह मूल्यांकन कर सकें कि उन्हें मजबूर होने से पहले माइग्रेट करना है या नहीं।
- <पी> क्या बदलता है और कब बदलता है, इसके बारे में ईमानदार दस्तावेज़ीकरण इस सूची में सबसे कठिन आइटम है, क्योंकि इसके लिए प्लेटफ़ॉर्म को यह स्वीकार करने की आवश्यकता होती है कि "समान मॉडल" हमेशा एक विपणन अमूर्त रहा है। दस्तावेज़ीकरण में प्रत्येक परत का नाम होना चाहिए जो मॉडल संस्करण से स्वतंत्र रूप से बदल सकती है, प्रत्येक को बदलने पर प्लेटफ़ॉर्म की नीति बताएं, और वर्णन करें कि ग्राहकों को कैसे सूचित किया जाएगा। टीमें तब सूचित निर्णय ले सकती हैं कि कौन सा प्लेटफ़ॉर्म उनकी जोखिम सहनशीलता से मेल खाता है।
खरीदार की चेकलिस्ट
<पी> यदि आप आज किसी अनुमान मंच का मूल्यांकन कर रहे हैं, तो हस्ताक्षर करने से पहले विक्रेता से ये प्रश्न पूछें: - "क्या मैं एक विशिष्ट मॉडल स्नैपशॉट पिन कर सकता हूं, और वह स्नैपशॉट कितने समय तक उपलब्ध होने की गारंटी है?"
- "क्या मेरे द्वारा पिन किया गया संस्करण स्ट्रिंग अनुमान इंजन, परिमाणीकरण और हार्डवेयर - या केवल वज़न को कवर करता है?"
- “जब सर्विंग स्टैक की कोई भी परत बदलती है तो आपकी अधिसूचना नीति क्या है?”
- "क्या आप सिस्टम प्रॉम्प्ट, रेलिंग, या मॉडरेशन परतें इंजेक्ट करते हैं जिन्हें मैं नहीं देख सकता? क्या मैं बाहर निकलने का विकल्प चुन सकता हूँ?"
- "यदि मैं एक ही अनुरोध को एक महीने के अंतराल पर शून्य तापमान पर दो बार चलाता हूं, तो आप आउटपुट पहचान के बारे में क्या गारंटी देते हैं?"
- "क्या आप प्रतिगमन परीक्षण टूलींग प्रदान करते हैं, या क्या मैं इसे स्वयं बनाता हूं?"
- "जब पिन किया गया स्नैपशॉट अप्रचलित हो जाता है, तो मुझे कितना नोटिस मिलता है और माइग्रेशन पथ क्या है?"
<पी> यदि कोई प्लेटफ़ॉर्म इनमें से अधिकांश का स्पष्ट रूप से उत्तर नहीं दे सकता है, तो यही उत्तर है। आप ऐसे बुनियादी ढांचे का निर्माण कर रहे हैं जो आपके नीचे बदल सकता है, और आप ही इसे अपने उपयोगकर्ताओं को समझाएंगे। व्यावसायिक वास्तविकता
<पी> उपरोक्त में से कोई भी तकनीकी रूप से कठिन नहीं है। जो चीज़ इसे कठिन बनाती है वह है व्यावसायिक:प्लेटफ़ॉर्म को चुपचाप चीजों को बदलने के लचीलेपन से लाभ होता है, और ग्राहकों ने ऐतिहासिक रूप से इसे स्वीकार कर लिया है क्योंकि विकल्प, स्व-होस्टिंग, परिचालन रूप से महंगा है। यह व्यापार बदतर दिखने लगा है क्योंकि एआई सुविधाएँ डेमो से उन उत्पादों में बदल रही हैं जिन पर लोग निर्भर हैं। जो प्लेटफ़ॉर्म इसे पहले हल करेंगे वे बाज़ार के उस क्षेत्र को जीतेंगे जो वास्तव में विश्वसनीयता की परवाह करता है। जो लोग ऐसा नहीं करेंगे वे अपने उपयोगकर्ताओं से पता लगाने वाली टीमों को साइलेंट रिग्रेशन भेजते रहेंगे। समापन विचार
<पी> उद्योग ने पारंपरिक सॉफ्टवेयर से उधार ली गई धारणा पर एआई बुनियादी ढांचे का निर्माण किया:एक नामित आर्टिफैक्ट एक स्थिर आर्टिफैक्ट है। वह धारणा सही नहीं है। वज़न, इंजन, रूटिंग और रेलिंग सभी समापन बिंदु पर नाम से स्वतंत्र रूप से बदलते हैं, और "मॉडल संस्करण" का क्या अर्थ है और यह वास्तव में क्या गारंटी देता है, इसके बीच का अंतर वह है जहां उत्पादन एआई चुपचाप टूट जाता है। <पी> यहां भविष्यवाणी है:अगले 18 महीनों के भीतर, साइलेंट वर्जनिंग एक खरीद मुद्दा बन जाएगा, न कि केवल एक इंजीनियरिंग मुद्दा। अनुमान क्षमता खरीदने वाली टीमें उपरोक्त चेकलिस्ट में प्रश्न पूछना शुरू कर रही हैं, और जो प्लेटफ़ॉर्म उनका उत्तर दे सकते हैं वे सौदे जीतना शुरू कर देंगे, दूसरों को पता भी नहीं चलेगा कि वे हार गए हैं। "पुनरुत्पादन एसएलए," "स्टैक-स्तरीय चेंजलॉग," और "स्नैपशॉट रिटेंशन विंडो" को इंजीनियरिंग इच्छा सूची से उद्यम अनुबंधों में स्थानांतरित होते देखने की उम्मीद है। पूर्ण-स्टैक संस्करण स्ट्रिंग को उत्पाद सुविधा के रूप में प्रकाशित करने वाला पहला प्लेटफ़ॉर्म - दस्तावेज़ों में गहराई से फ़ुटनोट नहीं - बाकी सभी के लिए ग्राहकों की अपेक्षाओं को रीसेट कर देगा। <पी> आज अनुमान के आधार पर निर्माण कर रही टीमों के लिए, व्यावहारिक प्रश्न यह नहीं है कि मौन परिवर्तन आपके उत्पाद को प्रभावित करेगा या नहीं। यह। सवाल यह है कि क्या आप अपनी निगरानी से, अपने स्वयं के प्रतिगमन परीक्षणों से, या सोमवार की सुबह उपयोगकर्ता की शिकायत से पता लगाते हैं। यह उन तीनों में से कौन सा है यह लगभग पूरी तरह से आपके द्वारा लिए गए निर्णयों पर निर्भर करता है, अगले साइलेंट अपडेट आने से पहले। <पी> जिस मॉडल के साथ आपने शिप किया है वह वह मॉडल नहीं है जिसे आप चला रहे हैं। तदनुसार निर्माण करें. <पी> DigitalOcean आपके AI उत्पादों को बड़े पैमाने पर बनाने में आपकी मदद कर सकता है। <पी> 
यह कार्य क्रिएटिव कॉमन्स एट्रिब्यूशन-नॉन-कमर्शियल- के तहत लाइसेंस प्राप्त है शेयरअलाइक 4.0 अंतर्राष्ट्रीय लाइसेंस।
