जवाब देने से पहले बड़ा संदर्भ पढ़ने वाले एआई अनुप्रयोग के लिए इनपुट प्रोसेसिंग में लगने वाला समय, जनरेशन की गति जितना ही महत्त्वपूर्ण हो सकता है। इसलिए पूरे अनुरोध को अनुकूलित करने से यह बदल सकता है कि कौन-सा सर्विंग विन्यास बेहतर अनुभव देता है।
हमारे Kimi K3 अध्ययन में ProsGrow ने उसी AMD हार्डवेयर पर अपने मौजूदा ATOM विन्यास की तुलना में पूरे अनुरोध की आउटपुट दर 50.1% बढ़ाई। यह परिणाम सर्विंग स्टैक के बदलावों से आया; मूल मॉडल चेकपॉइंट समान था और अनुरोधों के आकार नियंत्रित थे। प्रयोगात्मक विन्यास रनटाइम के कुछ हिस्सों की संख्यात्मक परिशुद्धता बदलता है; व्यापक गुणवत्ता सत्यापन अभी आवश्यक है।
नतीजा: पूरे जवाब के लिए कम इंतज़ार
22 सितंबर के हमारे मापनों में आठ AMD MI325X GPU पर Kimi K3 इस्तेमाल हुआ। हर अनुरोध में ठीक 8,192 इनपुट टोकन थे और उसने 256 आउटपुट टोकन जनरेट किए। एक समय में एक अनुरोध चलाया गया।
| मापदंड | स्थानीय ATOM आधारभूत विन्यास | ProsGrow का प्रयोगात्मक विन्यास | बदलाव |
|---|---|---|---|
| पूरे अनुरोध के समय की मध्यिका | 9.57 सेकंड | 6.37 सेकंड | 33.4% कम |
| पूरे अनुरोध की आउटपुट दर | 26.76 टोकन/सेकंड | 40.17 टोकन/सेकंड | 50.1% अधिक |
पूरे अनुरोध की आउटपुट दर, आउटपुट टोकन को पूरा जवाब मिलने के समय से भाग देकर निकाली जाती है। इस समय में इनपुट प्रोसेसिंग और डेटा ट्रांसफ़र भी शामिल हैं। ये पूरे सिस्टम के मापन हैं, प्रति GPU दरें नहीं। दोनों प्रतिशत एक ही सुधार को अलग नज़रिए से बताते हैं; इन्हें जोड़ना नहीं चाहिए।
निजी एआई टीमों के लिए यह प्रमाण है कि हार्डवेयर विनिर्देशों के साथ सर्विंग विन्यास का भी मूल्यांकन होना चाहिए। तय आकार के जवाब के लिए कम इंतज़ार उन अनुप्रयोगों में महत्त्वपूर्ण हो सकता है जो बड़े इनपुट संदर्भ के साथ संक्षिप्त जनरेटेड आउटपुट देते हैं।
4.41× का परिणाम जो कार्यभार का महत्त्व दिखाता है
हमने प्रयोगात्मक विन्यास की तुलना Microsoft के Tutel रनटाइम के आसपास बने एक स्थानीय एडाप्टर से भी की। इसमें होस्ट, मूल चेकपॉइंट, अनुरोध परीक्षण डेटा और क्लाइंट समान थे।
8K इनपुट और 256 आउटपुट टोकन वाले कार्यभार में Tutel एडाप्टर ने पूरे अनुरोध के लिए 9.10 आउटपुट टोकन/सेकंड दिए, जबकि ट्यून किए गए ATOM ने 40.17 दिए: यानी पूरे अनुरोध की दर 4.41×। अनुरोध के समय की मध्यिका एडाप्टर के लिए 28.13 सेकंड और ट्यून किए गए ATOM के लिए 6.37 सेकंड थी।
डिकोडिंग शुरू होने के बाद Tutel अब भी टोकन तेज़ी से जनरेट करता था: 78.33 बनाम 47.67 टोकन/सेकंड। उसने हमारे छोटे, 512 इनपुट टोकन वाले अनुरोध भी जल्दी पूरे किए। परीक्षण किए गए एडाप्टर में लंबे प्रॉम्प्ट की प्रोसेसिंग में अधिक समय लगने से 8K इनपुट पर नतीजा बदल गया।
व्यावसायिक सीख स्पष्ट और सीमित है: सर्विंग विन्यास आपके अनुप्रयोग के वास्तविक अनुरोधों की लंबाई और जवाबों के आकार के अनुसार चुनें। यह स्थानीय रनटाइम तुलना है, यह सामान्य दावा नहीं कि कोई एक रनटाइम सभी कार्यभारों में तेज़ है।
सुधार कहाँ से आया
ProsGrow ने जाँचा कि इनपुट प्रोसेसिंग और जनरेशन के दौरान सर्विंग स्टैक AMD हार्डवेयर का उपयोग कैसे करता है, फिर बदलावों को मिलाकर एक रनटाइम विन्यास जाँचा। यह काम ATOM और AMD AITER इकोसिस्टम पर आधारित था।
यह तरीका अनुकूलन को पूरे अनुरोध से जोड़ता है। साथ ही संख्यात्मक परिशुद्धता और गुणवत्ता के बीच समझौते को स्पष्ट करता है: एक ही मूल चेकपॉइंट का उपयोग करने का अर्थ यह नहीं कि अलग सर्विंग विन्यास बिल्कुल समान संख्यात्मक गणनाएँ करते हैं। इस तुलना में रनटाइम और कैश की संख्यात्मक परिशुद्धता संबंधी नीतियाँ अलग हैं।
हमने क्या सत्यापित किया
हर विन्यास में प्रत्येक इनपुट लंबाई पर दो वार्मअप अनुरोध और पाँच मापे गए अनुरोध थे। अनुमानित डिकोडिंग बंद थी। टोकन की संख्या और समय सत्यापित करने के लिए सहेजे गए प्रतिक्रिया स्ट्रीम की जाँच की गई। तीनों विन्यास अंकगणित और संदर्भ से चिह्न याद करके बताने वाली जाँचों में सफल रहे।
ये कार्यात्मक जाँच मॉडल की उत्तर-शुद्धता समान होना साबित नहीं करतीं। प्रयोगात्मक विन्यास वैकल्पिक रहा; उसने सामान्य सेवा की जगह नहीं ली। ये विकास के दौरान मिले मापन हैं, जिनमें विश्वास-अंतराल या प्रोडक्शन सेवा-स्तर की गारंटी नहीं है।
निजी Kimi होस्टिंग पर विचार कर रही टीमों के लिए अगला कदम प्रतिनिधि प्रॉम्प्ट, प्रतिक्रिया लंबाई, समवर्ती स्तर और कार्य-गुणवत्ता के मानदंडों के साथ मूल्यांकन करना है। ProsGrow इन आवश्यकताओं को मापे गए तैनाती विन्यास से जोड़ने में मदद कर सकता है।
निजी इन्फरेंस पायलट पर चर्चा के लिए contact@prosgrow.ai पर ईमेल करें।