GPU पर तेज़ एम्बेडिंग
खोज और कंप्यूटर से लेकर हमारे API प्लेटफ़ॉर्म तक, Perplexity के सभी कार्यों के लिए तेज़ और सटीक खोज महत्वपूर्ण है। पर्दे के पीछे, भारी काम एम्बेडिंग और रैंकिंग मॉडल द्वारा किया जाता है, जो हमारे सिस्टम को किसी दिए गए क्वेरी के लिए सबसे प्रासंगिक परिणामों की पहचान करने में मदद करते हैं। हम अत्याधुनिक स्थिति प्राप्त करते हैं
खोज और कंप्यूटर से लेकर हमारे API प्लेटफ़ॉर्म तक, Perplexity के सभी कार्यों के लिए तेज़ और सटीक खोज महत्वपूर्ण है। पर्दे के पीछे, भारी काम एम्बेडिंग और रैंकिंग मॉडल द्वारा किया जाता है, जो हमारे सिस्टम को किसी दिए गए क्वेरी के लिए सबसे प्रासंगिक परिणामों की पहचान करने में मदद करते हैं। हम pplx-embed जैसे अपने स्वयं के मॉडल को प्रशिक्षित और सेवा करके अत्याधुनिक गुणवत्ता और विलंबता प्राप्त करते हैं।
यह लेख इस विशेष श्रेणी के मॉडलों के लिए Perplexity के सर्विसिंग बुनियादी ढांचे का एक अंतर-दृश्य प्रस्तुत करता है। हम AI-नेटिव खोज की इनफेरेंस आवश्यकताओं को कुशलतापूर्वक संबोधित करने के लिए अपनी तकनीकों पर चर्चा करते हैं, जो हमारे exabyte-scale search index को संचालित करते हुए मॉडलों की त्वरित प्रोटोटाइप और मूल्यांकन को सक्षम बनाती हैं। ये तकनीकें सामूहिक रूप से खोज की गुणवत्ता और दक्षता के पारेतो सीमा का विस्तार करती हैं, जिससे हम कम से कम लागत और विलंबता पर सर्वोत्तम संभव परिणामों के साथ एजेंटों और उपयोगकर्ताओं की सेवा करने में सक्षम होते हैं।
खोज के लिए एम्बेडिंग
एक विशिष्ट खोज सेटअप में, अनुक्रमित दस्तावेजों को एम्बेडिंग मॉडल का उपयोग करके एक उच्च-आयामी वेक्टर स्पेस में मैप किया जाता है और एक वेक्टर डेटाबेस में संग्रहीत किया जाता है। उसी मॉडल का उपयोग करके एक क्वेरी को एम्बेड करके, क्वेरी के सबसे करीब के वैक्टर को ढूंढकर समान दस्तावेजों का पता लगाया जा सकता है। इससे इनफेरेंस इंजन के लिए सेवा देने के लिए दो अलग-अलग ट्रैफ़िक पैटर्न उत्पन्न होते हैं:
- बैच एम्बेडिंग: डेटाबेस का निर्माण, विस्तार या री-इंडेक्सिंग करते समय, लागत को कम करने के लिए थ्रूपुट को अधिकतम करते हुए, थोक दस्तावेजों को वेक्टर स्पेस में एम्बेड किया जाना चाहिए।
वेक्टर खोज के बाद, थ्रूपुट और विलंबता के बीच संतुलन बनाते हुए दस्तावेजों के बड़े बैचों को स्कोर किया जाना चाहिए।
- ऑनलाइन एम्बेडिंग: डेटाबेस से क्वेरी करते समय, लुकअप के लिए एक छोटी क्वेरी एम्बेड की जानी चाहिए, जिससे विलंबता कम से कम हो।
हमने उपयोग के मामलों में यथासंभव अधिक से अधिक सामान्य घटकों का लाभ उठाने के लिए अपना इनफेरेंस बुनियादी ढांचा तैयार किया है। चूंकि हम आम तौर पर एम्बेडिंग तैयार करने के लिए छोटे Transformer मॉडल का उपयोग करते हैं, इसलिए हम कार्यान्वयन के अधिकांश हिस्से को अपने LLM इनफेरेंस कोड के साथ साझा करते हैं: बैच एम्बेडिंग कंप्यूट-बाउंड प्रीफिल के समान हैं, जबकि ऑनलाइन एम्बेडिंग, जो अक्सर कुछ टोकन पर चलते हैं, कम्प्यूटेशनल रूप से मेमोरी-बाउंड डिकोड के समान हैं। इसलिए हम एम्बेडिंग मॉडल की सेवा के लिए अपने अनुकूलित प्रीफिल और डिकोड कर्नेल का पुन: उपयोग करते हैं। परिणामस्वरूप, ऑनलाइन एम्बेडिंग वर्कलोड के लिए कम विलंबता को संरक्षित करते हुए, हम न्यूनतम अतिरिक्त इंजीनियरिंग कार्य के साथ बड़े पैमाने पर बैच इनफेरेंस थ्रूपुट प्राप्त कर सकते हैं।
Tulips, Roses, और कुछ Ivy
हम आंतरिक रूप से और हमारे API प्लेटफ़ॉर्म के माध्यम से बाहरी रूप से मानकीकृत API के माध्यम से इनफेरेंस को उजागर करते हैं। पर्दे के पीछे, एम्बेडिंग अनुरोध के प्रसंस्करण में कई सेवाएँ शामिल हैं:
- Ivy एक Rust HTTP गेटवे है जिसे Perplexity सेवाएँ कॉल करती हैं।
यह JSON पार्सिंग, टोकनाइजेशन, इनपुट टेम्पलेटिंग और बैच विभाजन जैसे अनुरोधों के लिए CPU-पक्ष के काम को संभालता है, अनुरोधों को डाउनस्ट्रीम सर्वर के लिए एक कस्टम gRPC प्रोटोकॉल में अनुवादित करता है। यह पृथक्करण हमें भारी इनफेरेंस इंस्टेंस को छुए बिना टोकनाइजेशन और इनपुट फ़ॉर्मेटिंग के आसपास कुछ मापदंडों को कॉन्फ़िगर करने की अनुमति देता है।
- Tulip इनफेरेंस सर्वर इंटरफ़ेस है।
यह Rust, tokio, और `tonic` के साथ कार्यान्वित एक gRPC सर्वर है। Tulip gRPC इनफेरेंस अनुरोध प्राप्त करता है, शेड्यूलिंग और बैचिंग को संभालता है। फिर यह बैचों को ROSE इंजन को भेजता है, और ग्राहकों को पूर्ण प्रतिक्रियाएँ लौटाता है।
- **ROSE** (Runtime-Optimized Serving Engine) मॉडल इनफेरेंस लागू करता है।
यह मुख्य रूप से Python में परिभाषित है, जो मॉडल की एक विस्तृत श्रृंखला के लिए कर्नेल, लेयर और परिभाषाएँ प्रदान करता है। ROSE मॉडलों के माध्यम से फॉरवर्ड पास लागू करता है, और एम्बेडिंग के लिए विशेष CUDA ग्राफ़ प्रबंधन भी प्रदान करता है। यह step() फ़ंक्शन के माध्यम से Tulip से जुड़ा हुआ है, जो एक बैच लेता है और एक्सेलेरेटर पर इसके द्वारा किए जाने वाले कंप्यूटेशन का संदर्भ लौटाता है।
कर्नेल से परे ध्यान देना
Transformer-आधारित मॉडल और अंतर्निहित Hopper/Blackwell आर्किटेक्चर दोनों परिपक्व प्रौद्योगिकियाँ हैं, इसलिए GPU पक्ष पर एम्बेडिंग इनफेरेंस विभिन्न इनफेरेंस इंजनों में काफी हद तक इष्टतम कार्यान्वयन पर केंद्रित हो गया है। फिर भी, हमने रनटाइमर और हार्नेस में सुधार के लिए अतिरिक्त अवसर खोजे जो मॉडलों को एंड-टू-एंड रूप से क्लाइंट के सामने लाते हैं। विशेष रूप से, हमने पाया कि हम CUDA ग्राफ़ को सावधानीपूर्वक प्रबंधित करके और नेटिव Rust इंजन में GPU-पक्ष के परिणाम को अतुल्यकालिक रूप से ट्रैक करने के लिए LazyTensor एब्स्ट्रक्शन बनाकर विलंबता में सुधार कर सकते हैं। हमने इन सुविधाओं को Tulip में लागू किया, ताकि यह ROSE के मॉडल कार्यान्वयन के साथ प्रभावी ढंग से इंटरफेस कर सके।
Tulip
हमने Tulip को हमारे मॉडल सर्विसिंग पर यथासंभव हल्के वजन का इंटरफ़ेस बनाने के लिए डिज़ाइन किया है। यह टोकियो अतुल्यकालिक कार्यों में आने वाले अनुरोधों को संभालता है, अनुरोधों के एक पूल को बनाए रखता है जिसे यह ट्रैक करता है और एक्सेलेरेटर को प्रेषित करने के लिए बैचों को शेड्यूल करता है। Tulip में शेड्यूलिंग तंत्र बहुत सरल है: अनुरोध तब जमा होते हैं जब Tulip काम भेज रहा होता है या परिणामों की प्रतीक्षा कर रहा होता है। संचित अनुरोधों में से, मॉडल के माध्यम से चलाए जाने के लिए पहले आओ, पहले पाओ के आधार पर अनुक्रम चुने जाते हैं।
सरल शेड्यूलिंग तंत्र मॉडल प्रदर्शन पर एक अवलोकन से प्रेरित है। छोटे एम्बेडिंग मॉडल के लिए, जिन अनुक्रम लंबाई पर हम सेवा देते हैं, हमने देखा कि सघन लेयर की रैखिक लागत अटेंशन की द्विघात लागत पर हावी है। इस प्रकार, विलंबता ज्यादातर टोकन की संख्या के समानुपाती होती है, अनुक्रमों की संख्या के नहीं। परिणामस्वरूप, एक बार जब कोई बैच GPU को संतृप्त करने के लिए पर्याप्त बड़ा हो जाता है, जो कि एक अरब से कम पैरामीटर वाले मॉडल पर लगभग 512 टोकन है, तो इसमें अधिक अनुक्रमों को पैक करने से दक्षता में सुधार नहीं होता है।
मॉडल के साथ प्रभावी ढंग से इंटरफ़ेस करने के लिए, Tulip GPU और CPU के काम को ओवरलैप करने और उपलब्ध संसाधनों का पूरी तरह से उपयोग करने के लिए CUDA ग्राफ़ और लेज़ी परिणाम ट्रैकिंग पर निर्भर करता है।
CUDA ग्राफ़ प्रबंधन
किसी मॉडल के फॉरवर्ड पास को चलाने में CPU-पक्ष और GPU-पक्ष दोनों का काम शामिल होता है। CPU उचित मापदंडों के साथ बैचों को शेड्यूल करने और कर्नेल लॉन्च करने के लिए ज़िम्मेदार है, जबकि GPU प्रासंगिक मैट्रिक्स गुणा, अटेंशन, नॉर्म या सक्रियण कर्नेल को निष्पादित करता है। प्रशिक्षण और रीइंडेक्सिंग जैसे उच्च-थ्रूपुट वर्कलोड के लिए, CPU-पक्ष के ओवरहेड नगण्य हैं क्योंकि बैच आकार और GPU-पक्ष की विलंबता दोनों बड़ी हैं। हालाँकि, छोटे बैच आकारों पर, CPU-पक्ष का काम GPU-पक्ष के काम से अधिक हो सकता है।
ओवरहेड को कम करने के लिए, स्वतंत्र कर्नेल लॉन्च करने के बजाय, CUDA ड्राइवर के लिए एक सिंगल कॉल के साथ फॉरवर्ड पास के सभी कर्नेल को लॉन्च करने के लिए आवश्यक मेटाडेटा को कैप्चर करने के लिए एक CUDA ग्राफ़ बनाया जा सकता है। यह उन कॉन्फ़िगरेशन के लिए महंगे Python और PyTorch कोड को फिर से चलाने की आवश्यकता को समाप्त करता है जिनके लिए CUDA ग्राफ़ कैप्चर किए जा सकते हैं।
प्रत्येक मॉडल में, हम एक इन्फ्लेक्शन पॉइंट को ट्रैक करते हैं, यह निर्धारित करते हुए कि टोकन की न्यूनतम संख्या जिस पर GPU निष्पादन CPU-पक्ष कर्नेल लॉन्च की तुलना में अधिक महंगा है। चूंकि एम्बेडिंग मॉडल छोटे हैं, इसलिए हम देखते हैं कि यह इन्फ्लेक्शन पॉइंट हजारों टोकन और दर्जनों अनुक्रमों के बैचों पर आता है। कुछ अटेंशन कार्यान्वयन कर्नेल लॉन्च को कॉन्फ़िगर करने के लिए गतिशील होस्ट-साइड इनपुट पर भरोसा करते हैं, जो पूर्ण-मॉडल प्रीफिल/सघन CUDA ग्राफ़ को रोकता है। हमने अपने इनफेरेंस इंजन में उन्हें सक्षम करने के लिए प्रासंगिक कर्नेल में बदलावों को अपस्ट्रीम किया।
ओवरहेड को संबोधित करने के लिए, हम सभी एम्बेडिंग मॉडल के लिए पूरे-मॉडल CUDA ग्राफ़ बनाते हैं और GPU के काम के साथ CPU के काम को ओवरलैप करते हैं। चूंकि CUDA ग्राफ़ CPU-पक्ष के ओवरहेड को कम करते हैं, एक बार जब कोई ग्राफ़ लॉन्च हो जाता है, तो जब भी यह उपलब्ध हो, अगले बैच के निष्पादन को किक ऑफ़ और कतारबद्ध करने के लिए हमारे पास खाली समय होता है। लंबित बैच के परिणामों को LazyTensor के साथ ट्रैक किया जाता है, जो Rust में एक अतुल्यकालिक कार्य को पिछले बैच के निष्पादन समाप्त होने तक ब्लॉक करने की अनुमति देता है। CUDA ग्राफ़ यह सुनिश्चित करके कम विलंबता वाली सर्विसिंग में मदद करते हैं कि हम कर्नेल लॉन्च की लागत से पीछे नहीं हट रहे हैं और उच्च-थ्रूपुट मामले में बेहतर शेड्यूलिंग की सुविधा प्रदान करते हैं क्योंकि वे CPU को अगले बैच पर काम करने के लिए जल्दी से मुक्त करते हैं।
प्रत्येक अलग कॉन्फ़िगरेशन के लिए CUDA ग्राफ़ कैप्चर किए जाने चाहिए, जिसका एम्बेडिंग के लिए अर्थ है प्रति अनुक्रम गणना और टोकन गणना संयोजन का एक ग्राफ़। चूँकि यह ग्रिड व्यापक है, इसलिए हम टोकन गणना को उन बाल्टियों (buckets) में पैड करते हैं जो 64 या 256 के गुणक हैं। इसके परिणामस्वरूप अभी भी हजारों ग्राफ़ होते हैं जिन्हें किसी विशिष्ट मॉडल के लिए कैप्चर करने में कई मिनट लग सकते हैं। कैप्चर की लागत दो स्रोतों से आती है: एक ईगर फॉरवर्ड पास जिसे कर्नेल को संकलित करने और विभिन्न कर्नेल के लिए बफर सेट अप करने के लिए निष्पादित किया जाना चाहिए जिन्हें उनकी आवश्यकता है, उसके बाद कैप्चर रन होता है जो Python कोड को फिर से निष्पादित करता है।
जैसे-जैसे इंजन सेवा देता है, हम lazily CUDA ग्राफ़ कैप्चर करके स्टार्टअप लागत को कम करते हैं। हम प्रत्येक कॉन्फ़िगरेशन का ट्रैक रखते हैं और सुनिश्चित करते हैं कि यह दूसरे हिट पर ग्राफ़ कैप्चर और रीप्ले को ट्रिगर करने से पहले एक ईगर वार्मअप रन से गुजरे। उसी ग्राफ़ कॉन्फ़िगरेशन के सभी बाद के निष्पादन तब CUDA ग्राफ़ रीप्ले के माध्यम से जाते हैं। लेज़ी ग्राफ़ कैप्चर का स्टार्टअप के दौरान p99 विलंबता पर प्रभाव पड़ता है; हालांकि, यह कई घंटों में कई मिनट के ईगर काम को फैलाने में मूल्यवान है। त्वरित स्टार्टअप समय हमें एम्बेडिंग तैनाती को बेहतर ढंग से स्केल और प्रबंधित करने की अनुमति देता है।
लेज़ी टेंसर
CUDA के माध्यम से, GPU का काम अतुल्यकालिक है। चूंकि किसी कर्नेल को अतुल्यकालिक रूप से लॉन्च करने से यह एक स्ट्रीम पर कतारबद्ध हो जाता है, इसलिए होस्ट कोड को परिणामी वैक्टर को पढ़ने के लिए स्पष्ट रूप से सिंक्रनाइज़ करना होगा। उच्च स्तर की समानता की सुविधा के लिए और डिवाइस पर पिछले एक के पूरा होने की प्रतीक्षा करते समय भविष्य के बैचों को किक ऑफ़ करने में सक्षम होने के लिए, हम मानों को ट्रैक करने के लिए LazyTensor एब्स्ट्रक्शन पर भरोसा करते हैं।
LazyTensor पेज-लॉक मेमोरी में एक होस्ट बफर को ट्रैक करता है और डिवाइस से डेटा कॉपी करने वाले इवेंट के माध्यम से cudaMemcpyAsync ऑपरेशन को ट्रैक करता है। इसे उसी स्ट्रीम पर फॉरवर्ड पास लॉन्च होने के बाद किक ऑफ़ किया जाता है। चूंकि कॉपी ऑपरेशन को स्ट्रीम पर सभी पूर्व कर्नेल के निष्पादित होने की प्रतीक्षा करनी चाहिए, इसलिए संबद्ध इवेंट फॉरवर्ड पास के पूर्ण होने और CPU पर परिणाम की उपलब्धता दोनों को ट्रैक करता है।
GPU और CPU के काम को ओवरलैप करने के लिए हम अपने ROSE एन्कोडर इंजन में LazyTensors का लाभ उठाते हैं। प्रत्येक step() कॉल CUDA ग्राफ़ को चलाने और इसके समाप्त होने की प्रतीक्षा करने के बजाय, अपने परिणाम को अतुल्यकालिक रूप से ट्रैक करने के लिए step() एक LazyTensor लौटाता है। CUDA ग्राफ़ के साथ मिलकर, यह हमें कम विलंबता और बेहतर थ्रूपुट प्राप्त करने में मदद करता है।
ROSE
हमने अपने ROSE इंजन को अनुकूलित किया, जिसे हमने मूल रूप से LLM सर्विसिंग के लिए बनाया था, ताकि यह एम्बेडिंग मॉडल के निष्पादन को भी संभाल सके। एम्बेडिंग मॉडल का समर्थन करने के लिए आवश्यक प्रयास को कम करने के लिए, ROSE LLM और एम्बेडिंग के बीच आक्रामक रूप से कोड का पुन: उपयोग करता है। उदाहरण के लिए, pplx-embed सर्विसिंग और Qwen3.5 LLM डिकोडिंग सभी एक ही कर्नेल से गुजरते हैं। यह साझाकरण हमें प्रोटोटाइप, मूल्यांकन और उत्पादन इनफेरेंस के लिए LLM से मूल रूप से फ़ाइन-ट्यून किए गए एम्बेडिंग मॉडल की आसानी से सेवा करने की अनुमति देता है।
सघन लेयर (dense layers) के लिए, एम्बेडिंग और LLM इनफेरेंस समान हैं क्योंकि टोकन वैक्टर को स्वतंत्र रूप से संसाधित किया जाता है। अटेंशन लेयर में, LLM द्वारा आवश्यक पेजेड प्रीफिल और डिकोड सेटअप के साथ-साथ रैग्ड इनपुट के लिए समर्थन जोड़कर अंतर को संभाला जाता है। एम्बेडिंग मॉडल की सेवा करते समय, हम KV कैश को इंस्टेंटिएट नहीं करते हैं और पैडिंग से बचने के लिए रैग्ड प्रारूप का समर्थन करने वाले अटेंशन कर्नेल के रूपों में प्रेषित करते हैं। सहायक रूपांतरण और कैलिब्रेशन रूटीन भी LLM के साथ साझा किए जाते हैं।
Ivy
Ivy, हमारी इनफेरेंस HTTP प्रॉक्सी लेयर, प्रदर्शन में भी एक महत्वपूर्ण भूमिका निभाती है। चूंकि उत्पादन में अनुरोध पेलोड अलग-अलग होते हैं, इसलिए व्यक्तिगत अनुरोधों को व्यक्तिगत प्रतिकृतियों (replicated) पर रूट करने से लोड असंतुलन हो सकता है। Ivy बड़े-बैच अनुरोधों को टुकड़ों में विभाजित करता है और उपयोग में सुधार और विलंबता को सुचारू करने के लिए प्रतिकृतियों के बीच उनका लोड-बैलेंस करता है। इन-हाउस यूनिग्राम टोकनाइजेशन पर हमारा हालिया काम, जो Ivy में पूरी तरह से रोल आउट हो गया है, ऑफ-the-शेल्फ टोकनाइज़र की तुलना में विलंबता में काफी सुधार करता है।
...लेकिन कर्नेल अभी भी मायने रखते हैं
ROSE विभिन्न प्रकार के अटेंशन बैकएंड का समर्थन करता है। विभिन्न कर्नेल विशिष्ट समस्या आकारों के लिए उपयुक्त हो सकते हैं। समय के साथ, हमने रैग्ड अटेंशन को लागू करने के लिए FlashInfer 2, FlashInfer 3 और FlashAttention 4 कर्नेल को एकीकृत किया।
सामान्य तौर पर, हम देखते हैं कि FlashAttention 4 अधिक तेज़ है। हालाँकि, बहुत लंबी अनुक्रम लंबाई पर Qwen-आधारित मॉडलों पर FlashInfer 3 इससे बेहतर प्रदर्शन करता है। चूँकि प्रदर्शन और ट्यूनिंग अटेंशन हेड की संख्या और आयाम के साथ भिन्न हो सकते हैं, इसलिए हम कई कॉन्फ़िगरेशन के लिए समर्थन बनाए रखते हैं और सर्विसिंग करते समय हर मामले के आधार पर निर्णय लेते हैं।
बेंचमार्क
हम मूल्यांकन डेटासेट से प्राप्त वास्तविक मॉडल भार और इनपुट पर BF16 सटीकता पर इनफेरेंस चलाते हुए vLLM v0.22.0 के विरुद्ध बेंचमार्क करते हैं। सभी समय के रन वार्मअप रन से पहले थे जिन्होंने सत्यापित किया कि कोसाइन समानता में विचलन 0.1% के भीतर है।
कम विलंबता वाले एम्बेडिंग (p50 / p90 / p99 / अधिकतम ms)
हम पूर्व-टोकनीकृत अनुरोध बैच आकार 1, पूरी तरह से क्रमिक अनुरोधों, 128, 512 और 4096 टोकन की अनुक्रम लंबाई के लिए रनटाइमर की रिपोर्ट करते हैं।
कम विलंबता स्कोरिंग (p50 / p90 / p99 / अधिकतम ms)
पूर्व-टोकनीकृत अनुरोध बैच आकार 5, 25 और 50, 512 टोकन की अनुक्रम लंबाई।
उच्च-थ्रूपुट एम्बेडिंग (emb/s)
अनुरोध बैच आकार 100, अनुरोध सबमिट करने वाली चार समवर्ती प्रक्रियाएँ, 512, 1024, और 4096 टोकन की अनुक्रम लंबाई।
उच्च-समवर्ती एम्बेडिंग (p50 / p90 / p99 / अधिकतम ms)
अनुक्रम लंबाई 512, बैच आकार 1, लेकिन हम 1, 2, 4, 8 और 16 समवर्ती अनुरोध भेजते हैं। इस बेंचमार्क में Ivy और Tulip के बीच नेटवर्किंग ओवरहेड के साथ-साथ Ivy के माध्यम से टोकनाइजेशन लागत भी शामिल है।
निष्कर्ष और भविष्य का काम
Ivy, Tulip और ROSE से बना सर्विसिंग बुनियादी ढांचा हमें कम विलंबता और बेहतर थ्रूपुट के साथ Perplexity के लिए एम्बेडिंग की सेवा देने की अनुमति देता है, जिसके परिणामस्वरूप ऑफ-द-शेल्फ समाधानों की तुलना में कम लागत पर अधिक सटीक खोज होती है।
विशिष्ट मॉडलों पर ध्यान केंद्रित करके और पूरे स्टैक का स्वामित्व लेकर, हम प्रदर्शन और लचीलेपन के बीच प्रभावी संतुलन बनाने के लिए आवश्यक स्वतंत्रता प्राप्त करते हैं, जिसमें अधिक सामान्य Python मॉडलिंग कोड के साथ अत्यधिक पुन: प्रयोज्य और प्रदर्शनकारी Rust प्रिमिटिव्स को मिलाया जाता है। कई ओपन-सोर्स इनफेरेंस इंजन, जैसे vLLM, SGLang, और TokenSpeed, Rust और C++ जैसी भाषाओं को अपने स्टैक में एकीकृत कर रहे हैं। हमने पिछले दो वर्षों में Rust में निवेश किया है और प्रदर्शन और रखरखाव दोनों में बहुत लाभ प्राप्त किया है। एम्बेडिंग कार्यान्वयन के अधिकांश हिस्से को हमारे LLM सर्विसिंग स्टैक के साथ साझा करके, हम एम्बेडिंग मॉडलों के रखरखाव पर महत्वपूर्ण इंजीनियरिंग प्रयास खर्च किए बिना थ्रूपुट में भी लाभ प्राप्त करते हैं।
जैसे-जैसे मॉडल विकसित होंगे, हम CPU-बाउंड और GPU-बाउंड दोनों विलंबता को कम करने के लिए अपने स्टैक की प्रत्येक लेयर में सुधार करना जारी रखेंगे। Ivy और Tulip के भीतर हमारे कस्टम gRPC-आधारित प्रोटोकॉल हमें नेटवर्क विलंबता को कम करने के लिए संचार को ट्विक करने की अनुमति देते हैं, जबकि ROSE कम्प्यूटेशनल थ्रूपुट को बेहतर बनाने के लिए एक नींव प्रदान करता है। इसके अतिरिक्त, जैसे-जैसे पूरे पारिस्थितिकी तंत्र में फ्री-थ्रेडेड Python के लिए समर्थन बढ़ता है, हम ओवरहेड को कम करने के लिए Python-Rust अंतरसंचालनीयता (interoperability) में और सुधार करने में सक्षम होंगे।