जिस टीम ने प्रोडक्शन-ग्रेड इन्फरेंस सर्विस बनाई, उसने 48 घंटों तक DigitalOcean Inference पर छह लैंग्वेज मॉडल्स का परीक्षण किया। $0.20 प्रति माह वाला "tiny" मॉडल महंगे विकल्पों से बेहतर निकला। यह उनके droplets की 8 GB मेमोरी सीमा के भीतर रहा और उन क्रैश से बच गया जिन्होंने 70 B वेरिएंट को डाउन कर दिया था, जिससे बहुत कम लागत में उपयोगी लेटेंसी और सटीकता मिली।
यह परीक्षण क्यों महत्वपूर्ण है
जो एंटरप्राइज़ लार्ज लैंग्वेज मॉडल्स (LLMs) को API के रूप में उपलब्ध कराते हैं, वे अक्सर यह मान लेते हैं कि बड़े और महंगे मॉडल सबसे अच्छा अनुभव सुनिश्चित करते हैं। वास्तविकता में, प्रोडक्शन एनवायरनमेंट को मेमोरी, कॉनकरेंसी और अपटाइम गारंटी के बीच तालमेल बिठाना पड़ता है। एक मॉडल जो कागज़ पर अच्छा दिखता है, वह तब समस्या बन सकता है जब वह आउट-ऑफ-मेमोरी (OOM) किल्स को ट्रिगर करता है या कोल्ड स्टार्ट के दौरान सर्विस को रोक देता है। यह व्यावहारिक प्रयोग दिखाता है कि मामूली हार्डवेयर पर एक सस्ता मॉडल ही एकमात्र व्यवहार्य विकल्प हो सकता है।
छह दावेदार
| मॉडल | मासिक लागत | औसत लेटेंसी | सटीकता* | RAM उपयोग / क्रैश |
|---|---|---|---|---|
| mistral-tiny | $0.20 | 120 ms | 88 % | 1.2 GB |
| mistral-small | $0.80 | 180 ms | 91 % | 2.4 GB |
| mistral-medium | $2.50 | 250 ms | 93 % | 4.1 GB |
| mistral-large | $5.00 | 300 ms | 94 % | 6.8 GB |
| llama-70b | $8.00 | 450 ms | 95 % | CRASH |
| mixtral-8x7b | $10.00 | 500 ms | 96 % | CRASH |
*सटीकता टीम के आंतरिक बेंचमार्क सूट पर मॉडल्स के प्रदर्शन को दर्शाती है।
"tiny" मॉडल की लागत प्रति माह एक डॉलर के एक चौथाई से भी कम थी और यह 8 GB मेमोरी सीमा के भीतर ही रहा। दो सबसे बड़े मॉडल्स—llama-70b और mixtral-8x7b—ने उस सीमा को पार कर दिया और बार-बार होस्ट को क्रैश कर दिया, जिससे उच्च सटीकता स्कोर के बावजूद वे अनुपयोगी हो गए।
वे समस्याएँ जिन्होंने बड़े मॉडल्स को विफल कर दिया
- हार्ड-कोडेड एंडपॉइंट्स – मूल आर्किटेक्चर हर रिक्वेस्ट को एक ही मॉडल पर भेजता था। जब वह मॉडल विफल होता, तो पूरी API डाउन हो जाती थी।
- मेमोरी कैप की कमी – बड़े मॉडल्स ने उपलब्ध सारा RAM खा लिया, जिससे बिना किसी चेतावनी के OOM किल्स होने लगे।
- कोल्ड-स्टार्ट लेटेंसी – एक नए मॉडल पर पहली बार की जाने वाली रिक्वेस्ट में कई सेकंड लग जाते थे, जिससे रिस्पॉन्सिवनेस प्रभावित होती थी।
- अनबाउंडेड कॉनकरेंसी – एक साथ आने वाली रिक्वेस्ट की बाढ़ ने मेमोरी और CPU को संतृप्त (saturate) कर दिया, जिससे सिस्टम फेलियर होने लगे।
यदि सर्विस वास्तविक लोड के तहत ऑनलाइन नहीं रह सकती, तो कच्चे परफॉरमेंस नंबरों का कोई मतलब नहीं रह जाता।
डायनेमिक राउटिंग समाधान
इंजीनियरों ने तीन सिद्धांतों के आधार पर रिक्वेस्ट पाथ को फिर से लिखा:
- रनटाइम मॉडल चयन – राउटर एक स्टैटिक एंडपॉइंट का उपयोग करने के बजाय प्रत्येक रिक्वेस्ट के लिए एक मॉडल चुनता है।
- हार्डवेयर जागरूकता – प्रत्येक रिक्वेस्ट को एक मेमोरी बजट मिलता है; राउटर केवल उन्हीं मॉडल्स को डिस्पैच करता है जो शेष RAM के भीतर फिट बैठते हैं।
- फॉलबैक चेन – यदि चुना गया मॉडल विफल हो जाता है या टाइम आउट हो जाता है, तो राउटर स्वचालित रूप से अगले सबसे अच्छे मॉडल के साथ पुनः प्रयास करता है।
संशोधित आर्किटेक्चर चार ठोस सुरक्षा उपाय जोड़ता है:
- बाउंडेड कॉनकरेंसी – एक सेमाफोर (semaphore) समानांतर इन्फरेंस को सीमित करता है, जिससे मेमोरी की कमी को रोका जा सके।
- फेल-फास्ट टाइमआउट्स – प्रत्येक रिक्वेस्ट के लिए सख्त टाइमर लगाए गए हैं जो धीमे मॉडल्स को पूरे प्रोसेस को ब्लॉक करने से पहले ही रोक देते हैं।
- मेमोरी बफ़र्स – सिस्टम droplet के RAM पर 20% हेडरूम सुरक्षित रखता है, जिससे OS ओवरहेड और स्पाइक्स के लिए जगह सुनिश्चित होती है।
- प्री-वार्मिंग – स्टार्टअप के समय प्रत्येक मॉडल पर डमी रिक्वेस्ट भेजी जाती हैं, जिससे शुरुआती कोल्ड-स्टार्ट पेनल्टी खत्म हो जाती है।
इन उपायों ने एक नाजुक पाइपलाइन को एक लचीली सर्विस में बदल दिया जो सटीकता से बहुत अधिक समझौता किए बिना मामूली 8 GB वाले droplets पर ट्रैफिक को संभाल सकती है।
आगे क्या देखें
- हार्डवेयर स्केलिंग – जैसे-जैसे क्लाउड प्रोवाइडर्स कम कीमतों पर बड़े मेमोरी वाले droplets पेश करेंगे, बड़े मॉडल्स के लिए ब्रेक-ईवन पॉइंट बदल सकता है।
- मॉडल कंप्रेशन – क्वांटाइजेशन (Quantization) या नॉलेज डिस्टिलेशन (knowledge distillation) उच्च-सटीकता वाले मॉडल्स के RAM फुटप्रिंट को कम कर सकते हैं, जिससे उन्हें छोटे मशीनों पर चलाना संभव हो सकेगा।
- एडेप्टिव राउटिंग – भविष्य के राउटर वास्तविक समय में यह सीख सकते हैं कि किसी दिए गए क्वेरी के लिए कौन सा मॉडल सबसे अच्छा ट्रेड-ऑफ प्रदान करता है, जिससे सटीकता-लागत संतुलन और अधिक स्वचालित हो जाएगा।
निष्कर्ष सरल है: प्रोडक्शन में, दबाव में जीवित रहने वाला मॉडल उस मॉडल से अधिक मूल्य प्रदान करता है जो कागज़ पर सबसे अच्छा दिखता है। केवल हेडलाइन सटीकता के आधार पर नहीं, बल्कि अपनी डिप्लॉयमेंट बाधाओं के आधार पर मॉडल चुनें।
