AI इन्फ्रेंस प्रदर्शन को प्रभावित करने वाले अनदेखे वर्जनिंग मुद्दे

मॉडल रिग्रेस नहीं हुआ। आपने बग शिप नहीं किया। प्लेटफ़ॉर्म ने इसे बदल दिया।

आपके प्रोडक्शन AI एप्लिकेशन किसी ऐसी चीज़ पर निर्भर करते हैं जिसे अधिकांश टीमें नहीं समझतीं कि उन्होंने नियंत्रण सौंप दिया है: उनके एंडपॉइंट के पीछे मॉडल का व्यवहार। वास्तविकता यह है कि एक मॉडल एक निश्चित कलाकृति नहीं है। यह एक चलता हुआ लक्ष्य है। प्रतिस्पर्धी बने रहने के लिए, प्लेटफ़ॉर्म लगातार वज़न अपडेट करते हैं, क्वांटाइज़ेशन लेवल स्वैप करते हैं, इन्फ्रेंस इंजन अपग्रेड करते हैं, हार्डवेयर पर ट्रैफिक रीरूट करते हैं, और कभी-कभी एंडपॉइंट नाम बदले बिना पूरी तरह से मॉडल को बदल देते हैं।

जब ऐसा होता है, तो आपका एप्लिकेशन इसके साथ बदल जाता है। आउटपुट शिफ्ट होते हैं। प्रॉम्प्ट काम करना बंद कर देते हैं। सावधानीपूर्वक ट्यून किया गया व्यवहार खराब हो जाता है। और आप आमतौर पर चेंजलॉग से नहीं पता लगाते: आप एक उपयोगकर्ता से पता लगाते हैं।

यह आधुनिक AI इन्फ्रास्ट्रक्चर का छिपा हुआ जोखिम है: आप एक ऐसे सिस्टम के ऊपर निर्माण कर रहे हैं जो किसी भी समय आपके नीचे बदल सकता है, इस बात की कोई गारंटी नहीं कि "वही मॉडल" कल वही मॉडल है जिसे आपने आज टेस्ट किया था। यह लेख पता लगाता है कि यह व्यवहार में कैसा दिखता है, यह क्यों होता है, और लगभग कोई प्लेटफ़ॉर्म इसे अच्छी तरह से हल क्यों नहीं करता - और टीमें इससे निपटने के लिए क्या कर रही हैं।

जिस मॉडल के साथ आपने शिप किया वह वह मॉडल नहीं है जिसे आप चला रहे हैं।

मुख्य बातें

• "मॉडल वर्जनिंग" डिज़ाइन द्वारा अधूरा है: जो एक सिंगल मॉडल जैसा दिखता है वह वास्तव में मूविंग पार्ट्स का एक स्टैक है - वज़न, इन्फ्रेंस इंजन, हार्डवेयर, रूटिंग, और गार्डरेल्स - जो सभी एंडपॉइंट नाम बदले बिना स्वतंत्र रूप से बदल सकते हैं।
• साइलेंट बदलाव वास्तविक प्रोडक्शन जोखिम पैदा करते हैं: ये अपडेट पुनरुत्पादन को तोड़ते हैं, प्रॉम्प्ट ट्यूनिंग को अमान्य करते हैं, और रिग्रेशन पेश करते हैं जिन्हें टीमें अक्सर प्लेटफ़ॉर्म विजिबिलिटी या मॉनिटरिंग के माध्यम से नहीं, बल्कि उपयोगकर्ताओं के प्रभावित होने के बाद ही पता लगाती हैं।
• गैप तकनीकी नहीं है - यह पारदर्शिता और स्वामित्व है: प्लेटफ़ॉर्म आंतरिक रूप से इन परिवर्तनों को ट्रैक करते हैं लेकिन उन्हें उजागर नहीं करते; जैसे-जैसे AI प्रोडक्शन-क्रिटिकल बनता है, फुल-स्टैक वर्जनिंग, चेंजलॉग, और पुनरुत्पादन गारंटी प्लेटफ़ॉर्म चयन में प्रमुख मानदंड बन जाएंगे।

वर्जनिंग समस्या का आकार

"वही मॉडल" वास्तव में क्या मायने रखता है

एक मॉडल एंडपॉइंट एक सिंगल अपरिवर्तनीय कलाकृति नहीं है। यह इसका कॉन्फ़िगरेशन है:

• अंतर्निहित मॉडल वज़न (जो स्वयं मूल से क्वांटाइज़्ड, प्रूनड, या डिस्टिल्ड हो सकते हैं)
• उन्हें चलाने वाला इन्फ्रेंस इंजन (चाहे वह vLLM, TensorRT-LLM, SGLang, या मालिकाना इंजन हो - प्रत्येक थोड़ा अलग आउटपुट उत्पन्न करता है)
• GPU पीढ़ी और मेमोरी लेआउट
• टोकनाइज़र वर्जन और कोई भी लागू चैट टेम्पलेट
• सिस्टम प्रॉम्प्ट जो प्लेटफ़ॉर्म इंजेक्ट कर सकता है जिसे आप कभी नहीं देखते
• मॉडल के सामने बैठी सुरक्षा, मॉडरेशन, या गार्डरेल लेयर
• रूटिंग लॉजिक जो तय करता है कि कौन सा रेप्लिका या क्षेत्र आपके अनुरोध को संभालता है

इनमें से कोई भी एंडपॉइंट नाम बदले बिना बदल सकता है। जो बात समझना महत्वपूर्ण है वह यह है कि उनमें से अधिकांश नियमित रूप से, प्रोडक्शन एप्लिकेशन के जीवनकाल में बदलते हैं। यह परिवर्तन AI उत्पादों के विकास के लिए आवश्यक है क्योंकि अंतर्निहित तकनीक आमतौर पर प्रत्येक परिवर्तन के साथ सुधरती है। यह वृद्धिशील परिवर्तन AI सॉफ्टवेयर उद्योग का एक मुख्य हिस्सा है।

साइलेंट परिवर्तन की तीन श्रेणियां

पहली श्रेणी स्पष्ट वर्जन अपडेट है जहां प्लेटफ़ॉर्म बदलता है कि एंडपॉइंट किन वज़न की ओर इशारा करता है। "GPT-4" समय के साथ कई अलग-अलग मॉडल रहा है, उदाहरण के लिए, और क्लॉड एंडपॉइंट नियमित रूप से अपडेट होते हैं। होस्टेड प्लेटफ़ॉर्म पर ओपन-सोर्स मॉडल एंडपॉइंट अक्सर अपस्ट्रीम रिलीज़ को स्वचालित रूप से ट्रैक करते हैं।

दूसरी श्रेणी इन्फ्रास्ट्रक्चर-स्तरीय परिवर्तन है जहां वज़न समान रहते हैं लेकिन सर्विंग स्टैक में कुछ शिफ्ट होता है। इसके कुछ उदाहरणों में शामिल हैं जब:

• इन्फ्रेंस इंजन अपग्रेड हो जाते हैं
• लागत कारणों से क्वांटाइज़ेशन लेवल बदलते हैं
• रूटिंग निर्णय अलग-अलग डिप्लॉयमेंट के बीच ट्रैफिक शिफ्ट करते हैं जो समकक्ष माने जाते थे लेकिन नहीं हैं।

तीसरी श्रेणी प्लेटफ़ॉर्म-स्तरीय परिवर्धन से व्यवहारिक परिवर्तन है: नई मॉडरेशन लेयर, बदले हुए सिस्टम प्रॉम्प्ट, जोड़े गए सेफ्टी फिल्टर, या संशोधित चैट टेम्पलेट। इन परिदृश्यों में, मॉडल वही है, लेकिन मॉडल को क्या प्राप्त होता है और उपयोगकर्ता को क्या प्राप्त होता है वह अलग है।

प्रत्येक श्रेणी वास्तव में मॉडल व्यवहार को कैसे प्रभावित करती है

साइलेंट रिग्रेशन समस्या

साइलेंट रिग्रेशन सर्विंग स्टैक में कहीं परिवर्तन के कारण मॉडल आउटपुट गुणवत्ता का गिरावट है जिसे कभी घोषित नहीं किया गया, कभी दस्तावेज़ नहीं किया गया, और कभी वर्जन बंप से नहीं जोड़ा गया। एंडपॉइंट पर मॉडल नाम वही है। API कॉन्ट्रैक्ट वही है। आपके द्वारा भेजा गया अनुरोध बाइट-पहचान है जो आपने पिछले महीने भेजा था। लेकिन प्रतिक्रिया गुणवत्ता गिर गई है - कभी सूक्ष्मता से, कभी तेजी से - और प्लेटफ़ॉर्म की सार्वजनिक सतह पर कुछ भी आपको नहीं बताता कि क्यों।

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

साइलेंट रिग्रेशन को सामान्य मॉडल ड्रिफ्ट से अलग बनाता है सूचना की विषमता। प्लेटफ़ॉर्म जानता है कि क्या बदला। आप नहीं जानते। और क्योंकि आपकी मॉनिटरिंग लगभग निश्चित रूप से अपटाइम, लेटेंसी, और एरर रेट माप रही है न कि गोल्डन डेटासेट पर आउटपुट गुणवत्ता, रिग्रेशन आपके किसी भी डैशबोर्ड पर दिखने से पहले आपके उपयोगकर्ताओं तक फैल जाता है। जब तक आप पुष्टि करते हैं कि रिग्रेशन वास्तविक है, इसे अपने कोड के बजाय मॉडल से अलग करते हैं, और सपोर्ट टिकट खोलते हैं, प्लेटफ़ॉर्म आमतौर पर पहले ही अगले साइलेंट परिवर्तन पर चला गया होता है। आप आधी जानकारी के साथ एक चलते हुए लक्ष्य को डीबग करते हैं, जबकि आपके उपयोगकर्ता उस निर्णय की कीमत चुकाते हैं जो कहीं अपस्ट्रीम किया गया था जिसके बारे में आपको कभी नहीं बताया गया।

यह इस खंड की चार समस्याओं में सबसे खराब है क्योंकि यह एकमात्र ऐसी समस्या है जहां प्लेटफ़ॉर्म के पास वह जानकारी है जो समस्या को तुरंत हल कर देगी और वह इसे साझा नहीं करना चुनता। पुनरुत्पादन विफलताएं, प्रॉम्प्ट डेट, और eval-to-prod ड्रिफ्ट सभी लक्षण हैं जिन्हें टीमें कम से कम स्वयं निदान कर सकती हैं। साइलेंट रिग्रेशन वह है जहां आपको जिस नैदानिक उपकरण की आवश्यकता है वह API के दूसरी तरफ है।

पुनरुत्पादन समस्या

जबकि GPT मॉडल, AI डिप्लॉयमेंट के एक लोकप्रिय प्रकार के उत्कृष्ट उदाहरण के रूप में, स्वभाव से प्रोबेबिलिस्टिक हैं, आप अभी भी समान मॉडल के साथ समान प्रॉम्प्ट का उपयोग करके समान उत्तर प्राप्त करने की उम्मीद कर सकते हैं। लेकिन, जब पहले वर्णित कोई भी परिवर्तन होता है, तो कल मिला आउटपुट आज पुनरुत्पादन योग्य नहीं हो सकता। यह पुनरुत्पादन समस्या का सार है: मॉडल के व्यवहार की कोई भी अपेक्षा इनमें से किसी भी परिवर्तन से अमान्य हो सकती है।

स्वचालित मूल्यांकन या मॉडल संस्करणों की तुलना करने वाले एप्लिकेशन के लिए, यह मूल धारणा को तोड़ता है कि समान इनपुट समान (या समान, प्रोबेबिलिस्टिक मॉडल के मामले में) आउटपुट उत्पन्न करते हैं समान सीड दिए जाने पर। तापमान शून्य वास्तव में आपको डिटरमिनिज्म नहीं देता जब अंतर्निहित स्टैक आपके नीचे शिफ्ट हो रहा हो।

प्रॉम्प्ट इंजीनियरिंग डेट समस्या

टीमें अक्सर किसी विशिष्ट मॉडल की विचित्रताओं के लिए प्रॉम्प्ट ट्यून करने और उन्हें अपने उपयोगकर्ताओं की आवश्यकताओं को बेहतर ढंग से पूरा करने के लिए अनुकूलित करने में सप्ताह बिताती हैं। जब उस मॉडल को चुपचाप स्वैप या अपडेट किया जाता है, तो वह सारा ट्यूनिंग कार्य आंशिक डेट में बदल जाता है। जब सावधानीपूर्वक निर्मित प्रॉम्प्ट जो एक मॉडल के विफलता मोड को संभालने के लिए बनाए गए थे, अब थोड़े अलग मॉडल का सामना करते हैं जिनके थोड़े अलग विफलता मोड होते हैं, तो आपके उपयोगकर्ताओं का सामना करने वाला अंतिम व्यवहार बदल जाता है।

Eval-to-प्रोडक्शन ड्रिफ्ट समस्या

यहां एक और सामान्य परिदृश्य है: आप अपने टेस्ट सेट के खिलाफ एक मॉडल वर्जन का मूल्यांकन करते हैं, और बाद में इसे प्रोडक्शन में शिप करते हैं। लेकिन प्रोडक्शन एंडपॉइंट अब उस मॉडल का उपयोग नहीं कर रहा है जिसका आपने मूल्यांकन किया था, भले ही एंडपॉइंट पर नाम वही हो। एक बार फिर, यह अंतिम उत्पाद के व्यवहार पर उल्लेखनीय प्रभाव डाल सकता है।

प्लेटफ़ॉर्म वास्तव में क्या करते हैं

यह खंड सार्वजनिक दस्तावेज़ीकरण और अवलोकन योग्य व्यवहार के आधार पर प्रमुख इन्फ्रेंस प्लेटफ़ॉर्म द्वारा वर्जनिंग को कैसे संभाला जाता है, इसके बारे में बताता है।

OpenAI-शैली वर्जनिंग

OpenAI स्पष्ट रूप से स्नैपशॉट पिन करता है (gpt-4-0613, gpt-4o-2024-08-06) और आपको उन्हें टार्गेट करने देता है। एलियास्ड एंडपॉइंट्स (gpt-4, gpt-4o) जो भी वर्तमान डिफ़ॉल्ट है उस पर इशारा करते हैं, जो समय के साथ बदलता है। जो टीमें स्नैपशॉट पिन करना नहीं जानतीं उन्हें जो भी वर्तमान वर्जन है वह मिलता है, और एलियास उनके नीचे शिफ्ट हो सकता है।

OpenAI विभिन्न कारणों से अपने मॉडल बदलता है। इसका एक उदाहरण साइकोफैंसी इंसिडेंट है। GPT-4o कथित तौर पर 'अत्यधिक चापलूसी या सहमतिपूर्ण था - जिसे अक्सर साइकोफैंटिक के रूप में वर्णित किया जाता है,' और OpenAI ने अंततः मॉडल को डिप्रिकेट करने से पहले सुधारों की एक श्रृंखला जारी की (स्रोत)। मॉडल का अंतिम डिप्रिकेशन अधिक चर्चा का विषय बना क्योंकि लोगों ने मॉडल के नुकसान पर शोक व्यक्त किया।

जो साइकोफैंसी इंसिडेंट को निर्देशात्मक बनाता है वह व्यक्तित्व बदलाव नहीं है - यह वह है जो इसने एंडपॉइंट कॉन्ट्रैक्ट के बारे में प्रकट किया। साइकोफैंसी रोलआउट से पहले, दौरान, और बाद में gpt-4o को कॉल करने वाली टीमें उसी एंडपॉइंट नाम को हिट कर रही थीं लेकिन सार्थक रूप से अलग मॉडल। साइकोफैंसी-पूर्व वर्जन के खिलाफ ट्यून किया गया एक ग्राहक सहायता बॉट अपने प्रोडक्शन जीवनकाल के बीच में एक गर्म, अधिक सहमतिपूर्ण मॉडल का सामना करेगा, फिर जब OpenAI ने सुधार किया तो तीसरे व्यवहार प्रोफाइल का सामना करेगा, और चौथा जब मॉडल अंततः डिप्रिकेट हो गया। उनमें से किसी भी संक्रमण के लिए ग्राहक की ओर से कोड परिवर्तन की आवश्यकता नहीं थी। उनमें से किसी ने भी एंडपॉइंट स्ट्रिंग पर वर्जन बंप ट्रिगर नहीं किया। वही दो-लाइन API कॉल महीनों के दौरान चार अलग-अलग व्यवहार शासनों का उत्पादन करता था, और अधिकांश टीमों को मिला एकमात्र संकेत उनके उपयोगकर्ता बता रहे थे कि उत्पाद अलग महसूस होता है। OpenAI का दृष्टिकोण अधिकांश से बेहतर है क्योंकि यह आपको पुराने मॉडल संस्करणों का उपयोग करने का विकल्प देता है, जब तक OpenAI अभी भी उनकी सेवा कर रहा है। लेकिन, यह ध्यान देने योग्य है कि चयन मैन्युअल है और उन लोगों के लिए करना मुश्किल होगा जो पुराने संस्करणों में मॉडल बदलने का तरीका जानने के लिए शोध नहीं करते।

Anthropic का दृष्टिकोण

Anthropic डेटेड मॉडल पहचानकर्ताओं (claude-opus-4-5-20251101 शैली) का उपयोग करता है। पिनिंग काम करती है। लेकिन प्लेटफ़ॉर्म-स्तरीय सिस्टम प्रॉम्प्ट इंजेक्शन और सेफ्टी लेयर मॉडल वर्जन से स्वतंत्र रूप से विकसित होते हैं, इसलिए एक ही पिन किए गए मॉडल पर दो अलग-अलग दिनों में दो अनुरोध अलग-अलग व्यवहार कर सकते हैं क्योंकि मॉडल के आसपास क्या हो रहा है, उसमें नहीं। यह पारदर्शिता में एक कदम है, लेकिन कोर मॉडल चयन OpenAI के समान रहता है।

Anthropic से साइलेंट रिग्रेशन का एक उदाहरण हाल ही में एक उल्लेखनीय GitHub इश्यू में हुआ, जहां एक प्रमुख AI डेवलपर ने क्लॉड ओपस मॉडल के उनके जटिल इंजीनियरिंग कार्य में स्पष्ट "नर्फिंग" को कहा। उन्होंने रिपोर्ट किया कि क्लॉड ने निर्देशों को अनदेखा करना शुरू कर दिया, "सबसे सरल सुधार" का दावा किया जो गलत हैं, अनुरोधित गतिविधियों के विपरीत कार्य किया, और उन्होंने दावा किया कि मॉडल निर्देशों के विरुद्ध पूर्णता करता है। यह सब रिपोर्ट किए गए मॉडल में बदलाव के बिना। इस साइलेंट परिवर्तन का उसी थ्रेड में क्लॉड के डेवलपर्स द्वारा खंडन किया गया था, लेकिन अन्य उपयोगकर्ताओं की प्रतिक्रियाओं के आधार पर व्यापक सहमति है कि परिवर्तन हुआ था।

'वही मॉडल' हमेशा एक मार्केटिंग अमूर्तता रहा है।

होस्टेड ओपन-सोर्स मॉडल

ओपन-सोर्स मॉडल होस्ट करने वाले प्लेटफ़ॉर्म (Baseten, Fireworks, Together, DigitalOcean, Nebius Token Factory, Modal) अक्सर एंडपॉइंट को अंतर्निहित मॉडल के नाम पर रखते हैं, जैसे "llama-3.1-70b-instruct", बिना यह उजागर किए कि कौन सा विशिष्ट क्वांटाइज़ेशन, कौन सा इन्फ्रेंस इंजन वर्जन, या कौन सा डिप्लॉयमेंट कॉन्फ़िगरेशन वास्तव में अनुरोध की सेवा कर रहा है। यह एक बड़ी समस्या हो सकती है, क्योंकि मॉडल का प्रदर्शन प्लेटफ़ॉर्म से प्लेटफ़ॉर्म पर भिन्न होगा जबकि वे वही नाम रखते हैं। उनमें से किसी के अपडेट को आमतौर पर मॉडल वर्जन परिवर्तनों के रूप में संप्रेषित नहीं किया जाता है। जब ओपन-सोर्स होस्टिंग प्रोवाइडर्स की बात आती है, तो सर्वरलेस इन्फ्रेंस परिदृश्यों में अंतर्निहित मॉडल डिप्लॉयमेंट में किसी भी परिवर्तन के बारे में शोध करने का दायित्व उपयोगकर्ता पर होता है। कस्टम डिप्लॉयमेंट में, चीजें थोड़ी अलग हैं।

कस्टम डिप्लॉयमेंट

जब आप Modal या Baseten जैसे प्लेटफ़ॉर्म पर अपना मॉडल डिप्लॉय करते हैं, तो आप वर्जनिंग की कहानी के मालिक होते हैं। यह पुनरुत्पादन, प्रोडक्शन पर नियंत्रण, और आपके डाउनस्ट्रीम उत्पादों के लिए मॉडल परिवर्तनों के प्रबंधन के लिए सबसे साफ स्थिति है, लेकिन इसका मतलब मॉडल जीवनचक्र को स्वयं प्रबंधित करने का ऑपरेशनल बोझ उठाना है। स्केल करते समय इस ट्रेडऑफ पर विचार करना महत्वपूर्ण है, क्योंकि परिवर्तनों को प्रबंधित करने के लिए आवश्यक डेवलपर समय आसमान छूता है।

टीमें इसके बारे में क्या कर रही हैं

नीचे दिए गए खंड सामान्य वर्कअराउंड को कवर करते हैं जिन्हें टीमों ने अपनाया है। उनमें से कोई भी पूरी तरह से समस्या हल नहीं करता, लेकिन वे प्रत्येक सही दिशा में कदम प्रदान करते हैं।

जब संभव हो स्नैपशॉट पिनिंग

जब प्लेटफ़ॉर्म डेटेड स्नैपशॉट उजागर करता है, तो उन्हें पिन करना टेबल स्टेक्स है। लेकिन हर प्लेटफ़ॉर्म उन्हें उजागर नहीं करता, और पिन किए गए स्नैपशॉट अंततः डिप्रिकेट हो जाते हैं। अपने AI उत्पादों के लिए अपना मॉडल होस्ट करने के लिए कौन सा प्लेटफ़ॉर्म चुनना है, इस पर सावधानी से विचार करें, या आप ऐसी स्थिति में समाप्त हो सकते हैं जहां आपका मॉडल बैकअप योजना के बिना चला गया है।

गोल्डन डेटासेट रिग्रेशन टेस्टिंग

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

आउटपुट सैंपलिंग और लॉगिंग

यह प्रोडक्शन अनुरोधों और प्रतिक्रियाओं के नमूना प्रतिशत को लॉग करने की प्रक्रिया है ताकि बाद में विश्लेषण किया जा सके। यह आपको तथ्य के बाद ड्रिफ्ट का पता लगाने देता है, लेकिन फिर भी आपको सैंपलिंग, स्टोरेज, और विश्लेषण इन्फ्रास्ट्रक्चर स्वयं बनाने की आवश्यकता होती है।

शैडो डिप्लॉयमेंट

आप वर्तमान प्रोडक्शन एंडपॉइंट और एक उम्मीदवार नए एंडपॉइंट के खिलाफ एक ही अनुरोध को एक साथ चला सकते हैं, और आउटपुट की तुलना करके देख सकते हैं कि यह मॉडल व्यवहार को कैसे प्रभावित करता है। यह उन परिवर्तनों का मूल्यांकन करने के लिए उत्कृष्ट काम करता है जो आप बना रहे हैं; यह उन परिवर्तनों में मदद नहीं करता जो प्लेटफ़ॉर्म आपके नीचे करता है।

मॉडल को सेल्फ-होस्ट करना

अंतिम कंट्रोल चाल: अपने नियंत्रण वाले इन्फ्रास्ट्रक्चर पर मॉडल स्वयं चलाएं। यह आपको उपयोग किए जा रहे वज़न, इन्फ्रेंस इंजन, क्वांटाइज़ेशन, और किसी भी अन्य चीज़ पर पूर्ण नियंत्रण रखने की अनुमति देता है जो आउटपुट को प्रभावित कर सकती है। यह वर्जनिंग समस्या को मॉडल होस्टिंग के ऑपरेशनल बोझ के लिए ट्रेड करता है, यही कारण है कि अधिकांश टीमें ऐसा नहीं करतीं।

वर्जनिंग वास्तव में क्या खर्च करता है

ऑब्जर्वेबिलिटी टैक्स

हर टीम जो आउटपुट गुणवत्ता की परवाह करती है, अपना मूल्यांकन इन्फ्रास्ट्रक्चर बना रही है क्योंकि प्लेटफ़ॉर्म इसे प्रदान नहीं करते। यह उद्योग में डुप्लिकेट कार्य हो रहा है - प्रॉम्प्ट रिग्रेशन फ्रेमवर्क, आउटपुट डिफिंग टूल, गुणवत्ता मॉनिटरिंग सिस्टम, आदि, सभी एप्लिकेशन टीमों द्वारा बनाए जा रहे हैं जो अपना वास्तविक उत्पाद बनाने में व्यस्त रहना पसंद करेंगे।

ट्रस्ट टैक्स

जब आपकी AI सुविधा टूटती है क्योंकि मॉडल आपके नीचे शिफ्ट हो गया, उपयोगकर्ता "AI अविश्वसनीय है" और "प्लेटफ़ॉर्म ने चुपचाप मॉडल अपडेट किया" के बीच अंतर नहीं जानते। आपका उत्पाद अपस्ट्रीम किए गए निर्णयों की प्रतिष्ठा लागत को अवशोषित करता है।

माइग्रेशन टैक्स

प्लेटफ़ॉर्म स्विच करने पर विचार कर रही टीमों को न केवल API अंतरों के लिए बल्कि अलग-अलग प्लेटफ़ॉर्म पर समान नाम वाले मॉडलों के बीच व्यवहारिक अंतरों के लिए जिम्मेदार होना पड़ता है। फायरवर्क्स पर "Llama 3.1 70B" जरूरी नहीं कि टुगेदर पर "Llama 3.1 70B" के समान हो - वे अलग क्वांटाइज़ेशन हो सकते हैं, अलग इन्फ्रेंस इंजन का उपयोग कर सकते हैं, या पूरी तरह से अलग गार्डरेल स्टैक हो सकते हैं। इस स्पष्टता की कमी के कारण व्यापक परीक्षण के बिना प्रदाताओं के बीच स्विच करना मुश्किल होता है।

बेहतर कैसा दिखेगा

2026 में एक गंभीर इन्फ्रेंस प्लेटफ़ॉर्म को मॉडल व्यवहार को उसी तरह से ट्रीट करना चाहिए जैसे क्लाउड प्रोवाइडर अपटाइम को ट्रीट करते हैं: एक कॉन्ट्रैक्चुअल सतह के रूप में, ब्लैक बॉक्स के रूप में नहीं।

वर्तमान स्थिति तकनीकी सीमा नहीं है - यह एक प्रकटीकरण अंतर है। वज़न, इंजन, क्वांटाइज़ेशन लेवल, और रूटिंग निर्णयों को ट्रैक करने के लिए इन्फ्रास्ट्रक्चर पहले से मौजूद है; प्लेटफ़ॉर्म बस इसे उजागर नहीं करते।

यह व्यवहार में कैसा दिखता है:

1. पूर्ण वर्जन पहचानकर्ता आज के मॉडल नाम वज़न की पहचान करते हैं, कभी-कभी। उन्हें पूर्ण सर्विंग कॉन्फ़िगरेशन की पहचान करनी चाहिए। एक पूर्ण वर्जन स्ट्रिंग उन सभी चीज़ों को कैप्चर करती है जो एंडपॉइंट से निकलने वाले को बदल सकती हैं: वज़न (क्वांटाइज़ेशन लेवल के साथ), इन्फ्रेंस इंजन और वर्जन, हार्डवेयर पीढ़ी, टोकनाइज़र वर्जन, चैट टेम्पलेट, और कोई भी प्लेटफ़ॉर्म-इंजेक्टेड सिस्टम प्रॉम्प्ट या गार्डरेल लेयर। कुछ ऐसा जैसे llama-3.1-70b-instruct.fp8.vllm-0.6.3.h100.tmpl-v2.guardrail-v4 बदसूरत लेकिन ईमानदार है। टीमें किसी भी घटक को पिन कर सकती हैं जिस पर वे निर्भर करते हैं और जब अन्य बदलते हैं तो सूचनाएं प्राप्त कर सकती हैं।

2. पूरे स्टैक के लिए चेंजलॉग फीड प्लेटफ़ॉर्म रिलीज़ नोट्स प्रकाशित करते हैं जब वे मॉडल वज़न अपडेट करते हैं। वे शायद ही कभी कुछ प्रकाशित करते हैं जब वे vLLM अपग्रेड करते हैं, लागत कारणों से क्वांटाइज़ेशन बदलते हैं, या क्षेत्रों के बीच ट्रैफिक रीरूट करते हैं। एक उचित चेंजलॉग फीड - आदर्श रूप से मशीन-पठनीय - सर्विंग स्टैक की हर लेयर को कवर करेगा, टाइमस्टैम्प और प्रभावित एंडपॉइंट के साथ। टीमें रोलआउट से पहले, उपयोगकर्ता शिकायत के बाद नहीं, एक विशिष्ट पिन कॉन्फ़िगरेशन के लिए परिवर्तनों की सदस्यता लेने और अलर्ट प्राप्त करने में सक्षम होनी चाहिए।

3. घोषित प्रतिधारण के साथ पुनरुत्पादन गारंटी एक पिन किया गया स्नैपशॉट कुछ मायने रखना चाहिए। प्लेटफ़ॉर्म को एक घोषित प्रतिधारण विंडो के लिए प्रतिबद्ध होना चाहिए - मान लें, 12 या 24 महीने - जिसके दौरान एक पिन कॉन्फ़िगरेशन तापमान शून्य पर समान इनपुट के लिए बाइट-पहचान आउटपुट लौटाएगा, पूरे स्टैक के लिए, केवल वज़न के लिए नहीं। जब वह विंडो समाप्त होती है, तो टीमों को अग्रिम सूचना और माइग्रेशन पथ मिलता है। डेटाबेस और ऑपरेटिंग सिस्टम इसी तरह वर्जनिंग को संभालते हैं। कोई कारण नहीं कि इन्फ्रेंस अलग होना चाहिए।

4. प्लेटफ़ॉर्म-प्रदत्त रिग्रेशन टेस्टिंग हर गंभीर टीम अलगाव में वही मूल्यांकन इन्फ्रास्ट्रक्चर बना रही है। प्लेटफ़ॉर्म को इसे प्रथम श्रेणी की सुविधा के रूप में प्रदान करना चाहिए: एक गोल्डन डेटासेट रजिस्टर करें, इसे अपने पिन किए गए एंडपॉइंट के खिलाफ शेड्यूल पर चलाएं, और अलर्ट प्राप्त करें जब आउटपुट आपके द्वारा निर्धारित सीमा से आगे ड्रिफ्ट करते हैं। स्नैपशॉट के बीच डिफरेंशियल टेस्टिंग के लिए बोनस अंक, ताकि टीमें मजबूर होने से पहले मूल्यांकन कर सकें कि माइग्रेट करना है या नहीं।

5. इस बारे में ईमानदार दस्तावेज़ीकरण कि क्या बदलता है और कब इस सूची में सबसे कठिन आइटम, क्योंकि इसके लिए प्लेटफ़ॉर्म को यह स्वीकार करने की आवश्यकता है कि "वही मॉडल" हमेशा एक मार्केटिंग अमूर्तता रहा है। दस्तावेज़ीकरण को हर लेयर का नाम देना चाहिए जो मॉडल वर्जन से स्वतंत्र रूप से बदल सकती है, प्रत्येक को बदलने पर प्लेटफ़ॉर्म की नीति बतानी चाहिए, और वर्णन करना चाहिए कि ग्राहकों को कैसे सूचित किया जाएगा। टीमें तब इस बारे में सूचित निर्णय ले सकती हैं कि कौन से प्लेटफ़ॉर्म उनकी जोखिम सहनशीलता से मेल खाते हैं।

खरीदार की चेकलिस्ट

यदि आप आज इन्फ्रेंस प्लेटफ़ॉर्म का मूल्यांकन कर रहे हैं, तो साइन करने से पहले विक्रेता से ये प्रश्न पूछें:

• "क्या मैं एक विशिष्ट मॉडल स्नैपशॉट पिन कर सकता हूं, और वह स्नैपशॉट कितने समय तक उपलब्ध रहने की गारंटी है?"
• "क्या मैं जो वर्जन स्ट्रिंग पिन करता हूं वह इन्फ्रेंस इंजन, क्वांटाइज़ेशन, और हार्डवेयर को कवर करती है - या केवल वज़न?"
• "सर्विंग स्टैक की किसी भी लेयर के बदलने पर आपकी सूचना नीति क्या है?"
• "क्या आप सिस्टम प्रॉम्प्ट, गार्डरेल्स, या मॉडरेशन लेयर इंजेक्ट करते हैं जिन्हें मैं नहीं देख सकता? क्या मैं ऑप्ट आउट कर सकता हूं?"
• "यदि मैं एक महीने के अंतर पर तापमान शून्य पर एक ही अनुरोध दो बार चलाता हूं, तो आप आउटपुट पहचान के बारे में क्या गारंटी देते हैं?"
• "क्या आप रिग्रेशन टेस्टिंग टूलिंग प्रदान करते हैं, या मैं इसे स्वयं बनाऊं?"
• "जब एक पिन किया गया स्नैपशॉट डिप्रिकेट होता है, तो मुझे कितना नोटिस मिलता है और माइग्रेशन पथ क्या है?"

यदि कोई प्लेटफ़ॉर्म इनमें से अधिकांश का स्पष्ट रूप से उत्तर नहीं दे सकता, तो वह उत्तर है। आप ऐसे इन्फ्रास्ट्रक्चर पर निर्माण कर रहे हैं जो आपके नीचे बदल सकता है, और आप ही अपने उपयोगकर्ताओं को इसे समझाएंगे।

व्यावसायिक वास्तविकता

उपरोक्त में से कुछ भी तकनीकी रूप से कठिन नहीं है। जो इसे कठिन बनाता है वह व्यावसायिक है: प्लेटफ़ॉर्म चुपचाप चीजों को बदलने के लचीलेपन से लाभान्वित होते हैं, और ग्राहकों ने ऐतिहासिक रूप से इसे स्वीकार किया है क्योंकि विकल्प, सेल्फ-होस्टिंग, ऑपरेशनली महंगा है। वह ट्रेड AI सुविधाओं के डेमो से उन उत्पादों में जाने के कारण खराब दिखने लगा है जिन पर लोग निर्भर करते हैं। जो प्लेटफ़ॉर्म इसे पहले हल करते हैं, वे उस बाजार खंड को जीतेंगे जो वास्तव में विश्वसनीयता की परवाह करता है। जो नहीं करते वे उन टीमों को साइलेंट रिग्रेशन शिप करते रहेंगे जो अपने उपयोगकर्ताओं से पता लगाती हैं।

समापन विचार

उद्योग ने AI इन्फ्रास्ट्रक्चर को पारंपरिक सॉफ्टवेयर से उधार ली गई एक धारणा पर बनाया: कि एक नामित कलाकृति एक स्थिर कलाकृति है। वह धारणा मान्य नहीं है। वज़न, इंजन, रूटिंग, और गार्डरेल्स सभी एंडपॉइंट पर नाम से स्वतंत्र रूप से बदलते हैं, और "मॉडल वर्जन" का तात्पर्य और जो यह वास्तव में गारंटी देता है के बीच का अंतर वह जगह है जहां प्रोडक्शन AI चुपचाप टूटता है।

यहां भविष्यवाणी है: अगले 18 महीनों के भीतर, साइलेंट वर्जनिंग एक खरीद मुद्दा बन जाएगा, न कि केवल इंजीनियरिंग। जो टीमें इन्फ्रेंस क्षमता खरीद रही हैं वे ऊपर की चेकलिस्ट में प्रश्न पूछना शुरू कर रही हैं, और जो प्लेटफ़ॉर्म उनका उत्तर दे सकते हैं वे उन डील्स को जीतना शुरू कर देंगे जिन्हें अन्य यह भी नहीं जानते कि वे हार गए हैं। "पुनरुत्पादन SLAs," "स्टैक-लेवल चेंजलॉग," और "स्नैपशॉट प्रतिधारण विंडोज" को इंजीनियरिंग विशलिस्ट से एंटरप्राइज कॉन्ट्रैक्ट में जाते हुए देखने की उम्मीद है। पहला प्लेटफ़ॉर्म जो फुल-स्टैक वर्जन स्ट्रिंग को प्रोडक्ट फीचर के रूप में प्रकाशित करेगा - डॉक्स में गहरे फुटनोट के रूप में नहीं - बाकी सभी के लिए ग्राहक अपेक्षाओं को रीसेट करेगा।

आज इन्फ्रेंस के शीर्ष पर निर्माण करने वाली टीमों के लिए, व्यावहारिक प्रश्न यह नहीं है कि साइलेंट परिवर्तन आपके उत्पाद को प्रभावित करेगा या नहीं। यह होगा। प्रश्न यह है कि क्या आप अपने मॉनिटरिंग से, अपने स्वयं के रिग्रेशन टेस्ट से, या सोमवार की सुबह उपयोगकर्ता शिकायत से पता लगाते हैं। उन तीन में से कौन सा है यह लगभग पूरी तरह से उन निर्णयों पर निर्भर करता है जो आप अभी करते हैं, अगले साइलेंट अपडेट के आने से पहले।

जिस मॉडल के साथ आपने शिप किया वह वह मॉडल नहीं है जिसे आप चला रहे हैं। तदनुसार निर्माण करें।

डिजिटलओशन आपके AI उत्पादों को स्केल पर बनाने में मदद कर सकता है।

यह कार्य क्रिएटिव कॉमन्स एट्रिब्यूशन-नॉनकमर्शियल-शेयरअलाइक 4.0 इंटरनेशनल लाइसेंस के तहत लाइसेंस प्राप्त है।