GPU वर जलद एम्बेडिंग्स

हा लेख या विशिष्ट प्रकारच्या मॉडेल्ससाठी Perplexity च्या सर्व्हिंग इन्फ्रास्ट्रक्चरचे अंतर्गत दृश्य प्रस्तुत करतो.

लेखकPerplexity Engineering

सर्च आणि कॉम्प्युटरपासून ते आमच्या API प्लॅटफॉर्मपर्यंत, Perplexity च्या सर्वच भागांसाठी जलद आणि अचूक शोध अत्यंत महत्त्वाचा आहे. पडद्यामागे, हे कठीण काम एम्बेडिंग आणि रँकिंग मॉडेल्सद्वारे केले जाते, जे आमच्या सिस्टम्सना दिलेल्या क्वेरीसाठी सर्वात संबंधित परिणाम ओळखण्यात मदत करतात. pplx-embed सारखी आमची स्वतःची मॉडेल्स ट्रेन करून आणि सर्व्ह करून आम्ही अत्याधुनिक गुणवत्ता आणि लेटन्सी साध्य करतो.

हा लेख या विशेष वर्गवारीतील मॉडेल्ससाठी Perplexity च्या सर्व्हिंग इन्फ्रास्ट्रक्चरचे अंतर्गत दृश्य प्रस्तुत करतो. AI-नेम सर्चच्या इन्फरन्स गरजा कार्यक्षमतेने पूर्ण करण्यासाठी आम्ही आमच्या तंत्रज्ञानावर चर्चा करतो, ज्यामुळे आमच्या एक्साबाईट-स्केल सर्च इंडेक्स ला पॉवर देताना मॉडेल्सचे जलद प्रोटोटायपिंग आणि मूल्यमापन शक्य होते. ही तंत्रे एकत्रितपणे सर्च गुणवत्ता आणि कार्यक्षमतेची पॅरेटो सीमा विस्तृत करतात, ज्यामुळे आम्हाला सर्वात कमी खर्चात आणि लेटन्सीमध्ये एजंट्स आणि वापरकर्त्यांना सर्वोत्तम संभाव्य निकाल देणे शक्य होते.

सर्चसाठी एम्बेडिंग्स

विशिष्ट सर्च सेटअपमध्ये, इंडेक्स केलेले दस्तऐवज एम्बेडिंग मॉडेल वापरून उच्च-आयामी व्हॅक्टर स्पेसमध्ये मॅप केले जातात आणि व्हॅक्टर डेटाबेसमध्ये साठवले जातात. त्याच मॉडेलचा वापर करून क्वेरी एम्बेड करून, क्वेरीच्या सर्वात जवळ असलेले व्हॅक्टर शोधून समान दस्तऐवज शोधले जाऊ शकतात. यामुळे इन्फरन्स इंजिनसाठी दोन वेगवेगळे ट्रॅफिक पॅटर्न निर्माण होतात:

  • बॅच एम्बेडिंग: डेटाबेस तयार करताना, विस्तृत करताना किंवा री-इंडेक्स करताना, खर्च कमी करण्यासाठी थ्रूपुट जास्तीत जास्त वाढवून मोठ्या प्रमाणावर कागदपत्रे व्हॅक्टर स्पेसमध्ये एम्बेड करणे आवश्यक असते.

व्हॅक्टर सर्च नंतर, कागदपत्रांच्या मोठ्या बॅचेसचे स्कोरिंग करणे आवश्यक असते, ज्यामुळे थ्रूपुट आणि लेटन्सीमध्ये समतोल साधला जातो.

  • ऑनलाइन एम्बेडिंग: डेटाबेस क्वेरी करताना, लुकअपसाठी एक छोटी क्वेरी एम्बेड करणे आवश्यक असते, ज्यामुळे लेटन्सी कमी होते.

वापराच्या विविध प्रकरणांमध्ये शक्य तितके सामान्य घटक वापरण्यासाठी आम्ही आमचे इन्फ्रास्ट्रक्चर तयार केले. एम्बेडिंग्स तयार करण्यासाठी आम्ही सहसा लहान ट्रान्सफॉर्मर मॉडेल्स वापरत असल्याने, अंमलबजावणीचा मोठा भाग आमच्या LLM इन्फरन्स कोडसोबत सामायिक करतो: बॅच एम्बेडिंग्स हे कॉम्प्युट-बाउंड प्रिफिलसारखे असतात, तर ऑनलाइन एम्बेडिंग्स, जे अनेकदा काही टोकन्सवर चालतात, ते कम्प्युटेशनलदृष्ट्या मेमरी-बाउंड डिकोडसारखे असतात. त्यामुळे एम्बेडिंग मॉडेल्स सर्व्ह करण्यासाठी आम्ही आमचे ऑप्टिमाइझ केलेले प्रिफिल आणि डिकोड कर्नेल्स पुन्हा वापरतो. परिणामी, ऑनलाइन एम्बेडिंग वर्कलोड्ससाठी कमी लेटन्सी राखून, किमान अतिरिक्त अभियांत्रिकी कामासह आम्ही प्रचंड बॅच इन्फरन्स थ्रूपुट साध्य करू शकतो.

Tulips, Roses, आणि थोडे Ivy

आम्ही आमच्या API प्लॅटफॉर्मद्वारे अंतर्गत आणि बाह्य दोन्ही प्रकारे मानकीकृत API द्वारे इन्फरन्स उघड करतो. पडद्यामागे, एम्बेडिंग विनंतीच्या प्रक्रियेमध्ये अनेक सेवा गुंतलेल्या असतात:

  • Ivy हे एक Rust HTTP गेटवे आहे ज्याला Perplexity सेवा कॉल करतात.

हे JSON पार्सिंग, टोकनायझेशन, इनपुट टेम्पलेटिंग आणि बॅच स्प्लिटिंग सारख्या विनंत्यांसाठी CPU-बाजूचे कार्य हाताळते, आणि डाउनस्ट्रीम सर्व्हरसाठी कस्टम gRPC प्रोटोकॉलमध्ये विनंत्या अनुवादित करते. हे पृथक्करण आम्हाला जड इन्फरन्स इन्स्टन्सेसला स्पर्श न करता टोकनायझेशन आणि इनपुट फॉरमॅटिंगभोवती विशिष्ट पॅरामीटर्स कॉन्फिगर करण्यास अनुमती देते.

  • Tulip हे इन्फरन्स सर्व्हर इंटरफेस आहे.

हा एक gRPC सर्व्हर आहे जो Rust, tokio आणि tonic सह तयार केला आहे. Tulip gRPC इन्फरन्स विनंत्या प्राप्त करतो, शेड्युलिंग आणि बॅचिंग हाताळतो. त्यानंतर तो बॅचेस ROSE इंजिनला पाठवतो, पूर्ण झालेले प्रतिसाद क्लायंटला परत करतो.

  • ROSE (Runtime-Optimized Serving Engine) मॉडेल इन्फरन्स लागू करते.

हे प्रामुख्याने Python मध्ये परिभाषित केले गेले असून, विविध प्रकारच्या मॉडेल्ससाठी कर्नेल, लेअर्स आणि परिभाषा प्रदान करते. ROSE मॉडेल्सद्वारे फॉरवर्ड पास लागू करते, तसेच एम्बेडिंग्ससाठी विशेष CUDA आलेख व्यवस्थापन प्रदान करते. हे step() फंक्शनद्वारे Tulip शी जोडलेले असते, जे एक बॅच घेते आणि ॲक्सिलेटरवर ते करत असलेल्या गणनेचा संदर्भ परत करते.

GPU वर ROSE चालवणाऱ्या Ivy पासून Tulip सर्व्हरपर्यंत, एम्बेडिंग विनंत्यांसाठी मॉडेल-सेविंग आर्किटेक्चर.

कर्नेलच्या पलीकडे लक्ष देणे

ट्रान्सफॉर्मर-आधारित मॉडेल्स आणि अंतर्भूत Hopper/Blackwell आर्किटेक्चर दोन्ही प्रगत तंत्रज्ञान आहेत, त्यामुळे GPU बाजूला एम्बेडिंग इन्फरन्स विविध इन्फरन्स इंजिनवर मोठ्या प्रमाणावर इष्टतम अंमलबजावणीपर्यंत पोहोचला आहे. असे असले तरी, आम्हाला रनटाइम्स आणि हार्नेसमध्ये सुधारणा करण्यासाठी अतिरिक्त संधी सापडल्या ज्या मॉडेल्सना क्लायंटसमोर एंड-टू-एंड आणतात. विशेषतः, आम्हाला आढळले की CUDA आलेख काळजीपूर्वक व्यवस्थापित करून आणि नेटिव्ह Rust इंजिनमध्ये GPU-बाजूचा निकाल असिंक्रोनसपणे ट्रॅक करण्यासाठी LazyTensor ॲब्स्ट्रॅक्शन तयार करून आम्ही लेटन्सी सुधारू शकतो. ROSE च्या मॉडेल अंमलबजावणीसह प्रभावीपणे संवाद साधण्यासाठी आम्ही Tulip मध्ये ही वैशिष्ट्ये लागू केली.

Tulip

आम्ही Tulip आमच्या मॉडेल सर्व्हिंगवर शक्य तितका हलका इंटरफेस म्हणून डिझाइन केला आहे. हे Tokio ॲसिंक टास्कमध्ये येणार्‍या विनंत्या हाताळते, ट्रॅक करत असलेल्या विनंत्यांचा पूल राखते आणि ॲक्सिलेटरवर पाठवण्यासाठी बॅच शेड्यूल करते. Tulip मधील शेड्युलिंग यंत्रणा अतिशय सोपी आहे: Tulip कार्य पाठवत असताना किंवा निकालांची वाट पाहत असताना विनंत्या जमा होतात. जमा झालेल्या विनंत्यांमधून, मॉडेलमधून चालवण्यासाठी सिक्वेन्स प्रथम-येणाऱ्या, प्रथम-सेवेच्या आधारावर निवडल्या जातात.

सोप्या शेड्युलिंग यंत्रणेची प्रेरणा मॉडेल कामगिरीवरील एका निरीक्षणातून मिळते. लहान एम्बेडिंग मॉडेल्ससाठी, आम्ही ज्या सिक्वेन्स लांबींसाठी सेवा देतो, त्यावर dense layers चा रेखीय खर्च attention च्या द्विघात खर्चापेक्षा अधिक प्रभावी असल्याचे आमच्या लक्षात आले. त्यामुळे latency प्रामुख्याने tokens च्या संख्येशी प्रमाणबद्ध असते, sequences च्या संख्येशी नाही. परिणामी, batch GPU पूर्णपणे saturate होईल इतका मोठा झाला की, जे एक अब्ज parameters पेक्षा कमी असलेल्या model वर सुमारे 512 tokens इतके असते, त्यात अधिक sequences pack केल्याने कार्यक्षमता सुधारत नाही.

मॉडेलशी प्रभावीपणे संवाद साधण्यासाठी, Tulip GPU आणि CPU चे कार्य ओव्हरलॅप करण्यासाठी आणि उपलब्ध संसाधनांचा पुरेपूर वापर करण्यासाठी CUDA आलेख आणि लेझी निकाल ट्रॅकिंगवर अवलंबून असतो.

CUDA आलेख व्यवस्थापन

मॉडेलचा फॉरवर्ड पास चालवण्यामध्ये CPU-बाजूचे आणि GPU-बाजूचे दोन्ही कार्य समाविष्ट असते. बॅचेस शेड्यूल करण्यासाठी आणि योग्य पॅरामीटर्ससह कर्नेल लाँच करण्यासाठी CPU जबाबदार असतो, तर GPU संबंधित मॅट्रिक्स मल्टिप्लिकेशन, अटेंशन, नॉर्म किंवा ॲक्टिव्हेशन कर्नेल्स कार्यान्वित करतो. प्रशिक्षण आणि रीइंडेक्सिंग सारख्या उच्च-थ्रूपुट वर्कलोड्ससाठी, CPU-बाजूचे ओव्हरहेड्स नगण्य असतात कारण बॅच साईझ आणि GPU-बाजूची लेटन्सी दोन्ही मोठी असतात. तथापि, लहान बॅच साईझवर, CPU-बाजूचे कार्य GPU-बाजूच्या कार्यापेक्षा जास्त असू शकते.

CUDA ग्राफ्सशिवाय फॉरवर्ड पासदरम्यान CPU आणि GPU अंमलबजावणी.

ओव्हरहेड्स कमी करण्यासाठी, स्वतंत्र कर्नेल लाँच करण्याऐवजी, CUDA ड्रायव्हरला एकाच कॉलसह फॉरवर्ड पासचे सर्व कर्नेल लाँच करण्यासाठी आवश्यक असलेले मेटाडेटा कॅप्चर करण्यासाठी CUDA आलेख तयार केला जाऊ शकतो. यामुळे CUDA आलेख कॅप्चर केले जाऊ शकतात अशा कॉन्फिगरेशनसाठी महागडा Python आणि PyTorch कोड पुन्हा चालवण्याची गरज नाहीशी होते.

प्रत्येक मॉडेलमध्ये, आम्ही एक इन्फ्लेक्शन पॉईंट ट्रॅक करतो, ज्यामध्ये टोकन्सची किमान संख्या ठरवली जाते जिथे GPU अंमलबजावणी CPU-बाजूच्या कर्नेल लाँचपेक्षा अधिक महाग असते. एम्बेडिंग मॉडेल्स लहान असल्यामुळे, आम्हाला निदर्शनास आले की हा इन्फ्लेक्शन पॉईंट हजारो टोकन्स आणि शेकडो सिक्वेन्सच्या बॅचेसवर येतो. काही अटेंशन अंमलबजावणी कर्नेल लाँच कॉन्फिगर करण्यासाठी डायनॅमिक होस्ट-साईड इनपुट्सवर अवलंबून असतात, ज्यामुळे फुल-मॉडेल प्रिफिल/डेंस CUDA आलेख प्रतिबंधित होतात. आमच्या इन्फरन्स इंजिनमध्ये त्यांना सक्षम करण्यासाठी आम्ही संबंधित कर्नेल्समध्ये अपस्ट्रीम बदल केले.

ओव्हरहेड्स संबोधित करण्यासाठी, आम्ही सर्व एम्बेडिंग मॉडेल्ससाठी संपूर्ण-मॉडेल CUDA आलेख तयार करतो आणि GPU कार्याशी CPU कार्य ओव्हरलॅप करतो. CUDA आलेख CPU-बाजूचे ओव्हरहेड्स कमी करत असल्याने, एकदा आलेख लाँच झाल्यानंतर, पुढील बॅच उपलब्ध झाल्यावर त्याची अंमलबजावणी सुरू करण्यासाठी आणि एनक्यु करण्यासाठी आमच्याकडे मोकळा वेळ असतो. प्रलंबित बॅचचे परिणाम LazyTensor सह ट्रॅक केले जातात, ज्यामुळे मागील बॅचची अंमलबजावणी पूर्ण होईपर्यंत Rust मधील ॲसिंक टास्क ब्लॉक करण्याची परवानगी मिळते. कर्नेल लाँचच्या खर्चानुसार आपण मागे राहिलो नाही याची खात्री करून CUDA आलेख कमी-लेटन्सी सर्व्हिंगला मदत करतात आणि उच्च-थ्रूपुट प्रकरणात सुधारित शेड्युलिंग सुलभ करतात कारण ते CPU ला पुढील बॅचवर लवकर कार्य करण्यास मोकळे करतात.

CUDA ग्राफ्ससह फॉरवर्ड पासदरम्यान CPU आणि GPU अंमलबजावणी.

प्रत्येक भिन्न कॉन्फिगरेशनसाठी CUDA आलेख कॅप्चर करणे आवश्यक आहे, ज्याचा अर्थ एम्बेडिंगसाठी प्रति सिक्वेन्स संख्या आणि टोकन संख्या संयोजन असा आलेख आहे. ही ग्रिड विस्तृत असल्याने, आम्ही टोकन संख्या 64 किंवा 256 च्या पटीत असलेल्या बकेटमध्ये पॅड करतो. यामुळे अजूनही हजारो आलेख तयार होतात ज्यांना विशिष्ट मॉडेलसाठी कॅप्चर करण्यासाठी अनेक मिनिटे लागू शकतात. कॅप्चरचा खर्च दोन स्त्रोतांकडून येतो: एक इगर फॉरवर्ड पास जो कर्नेल कंपाइल करण्यासाठी आणि विविध कर्नेल्ससाठी बफर सेट करण्यासाठी कार्यान्वित करणे आवश्यक आहे, त्यानंतर कॅप्चर रन जो Python कोड पुन्हा कार्यान्वित करतो.

इंजिन सर्व्ह करत असताना आम्ही लेझी पद्धतीने CUDA आलेख कॅप्चर करून स्टार्टअप खर्च कमी करतो. आम्ही प्रत्येक कॉन्फिगरेशनचा मागोवा ठेवतो आणि आलेख कॅप्चर आणि रीप्ले ट्रिगर करण्यापूर्वी ते इगर वार्मअप रनमधून जाते याची खात्री करतो. त्याच आलेख कॉन्फिगरेशनच्या सर्व त्यानंतरच्या अंमलबजावणी नंतर CUDA आलेख रीप्लेमधून जातात. स्टार्टअप दरम्यान लेझी आलेख कॅप्चरचा p99 लेटन्सीवर प्रभाव पडतो; तथापि, अनेक तासांवर अनेक मिनिटांचे इगर कार्य पसरवण्यात ते मूल्यवान आहे. जलद स्टार्टअप वेळा आम्हाला एम्बेडिंग तैनाती अधिक चांगल्या प्रकारे स्केल आणि व्यवस्थापित करण्यास अनुमती देतात.

लेझी टेन्सर्स

CUDA द्वारे, GPU कार्य असिंक्रोनस असते. कर्नेल असिंक्रोनसपणे लाँच केल्याने ते प्रवाहावर एनक्यु होते, परिणामी व्हॅक्टर वाचण्यासाठी होस्ट कोडने स्पष्टपणे सिंक्रोनाइझ करणे आवश्यक असते. उच्च पदवीचे समांतरवाद सुलभ करण्यासाठी आणि डिव्हाइसवर मागील बॅच पूर्ण होण्याची वाट पाहत असताना भविष्यातील बॅच सुरू करण्यास सक्षम होण्यासाठी, आम्ही मूल्ये ट्रॅक करण्यासाठी LazyTensor ॲब्स्ट्रॅक्शनवर अवलंबून असतो.

LazyTensor पेज-लॉक केलेल्या मेमरीमधील होस्ट बफर आणि डिव्हाइसवरून डेटा कॉपी करणार्‍या इव्हेंटद्वारे cudaMemcpyAsync ऑपरेशन ट्रॅक करतो. त्याच प्रवाहात फॉरवर्ड पास लाँच झाल्यानंतर हे सुरू केले जाते. कॉपी ऑपरेशनला प्रवाहावरील सर्व पूर्व कर्नेल्स कार्यान्वित होण्याची प्रतीक्षा करावी लागत असल्याने, संबंधित इव्हेंट फॉरवर्ड पासचे पूर्ण होणे आणि CPU वर निकालाची उपलब्धता या दोन्ही गोष्टी ट्रॅक करतो.

CUDA ग्राफ लॉन्चपासून असिंक्रोनस कॉपीिंग आणि समकालिकीकरणापर्यंत LazyTensor अंमलबजावणी.

GPU आणि CPU चे काम ओव्हरलॅप करण्यासाठी आम्ही आमच्या ROSE एन्कोडर इंजिनमध्ये LazyTensor चा वापर करतो. प्रत्येक step() कॉल CUDA आलेख चालवून तो पूर्ण होण्याची वाट पाहण्याऐवजी, step() हा निकाल असिंक्रोनसपणे ट्रॅक करण्यासाठी LazyTensor परत करतो. CUDA आलेखांच्या साथीने, यामुळे आम्हाला कमी लेटन्सी आणि अधिक थ्रूपुट साध्य करण्यात मदत होते.

सततच्या GPU बॅचेसवर आच्छादित CPU तयारी आणि समकालिकीकरण.

ROSE

आम्ही आमचे ROSE इंजिन अनुकूल केले, जे आम्ही मूळतः LLM सर्व्हिंगसाठी तयार केले होते, जेणेकरून ते एम्बेडिंग मॉडेल्सची अंमलबजावणी देखील हाताळू शकेल. एम्बेडिंग मॉडेल्सना समर्थन देण्यासाठी आवश्यक असलेले प्रयत्न कमी करण्यासाठी, ROSE LLMs आणि एम्बेडिंग्स दरम्यान आक्रमकपणे कोड पुन्हा वापरतो. उदाहरणार्थ, pplx-embed सर्व्हिंग आणि Qwen3.5 LLM डिकोडिंग हे सर्व एकाच कर्नेल्समधून जातात. हे सामामीकरण आम्हाला प्रोटोटायपिंग, मूल्यमापन आणि प्रोडक्शन इन्फरन्ससाठी मूळतः LLM मधून फाईन-ट्यून केलेले एम्बेडिंग मॉडेल सहजपणे सर्व्ह करण्यास अनुमती देते.

डेंस लेअर्ससाठी, टोकन व्हॅक्टर स्वतंत्रपणे प्रक्रिया केले जात असल्याने एम्बेडिंग आणि LLM इन्फरन्स समान असतात. अटेंशन लेअर्समध्ये, LLMs द्वारे आवश्यक असलेल्या पेजिड प्रिफिल आणि डिकोड सेटअप्ससह, रॅग्ड इनपुट्ससाठी समर्थन जोड1ून फरक हाताळले जातात. एम्बेडिंग मॉडेल सर्व्ह करताना, आम्ही KV कॅश इन्स्टंटिएट करत नाही आणि पॅडिंग टाळण्यासाठी रॅग्ड स्वरूपाला समर्थन देणार्‍या अटेंशन कर्नेल्सच्या विविधतेवर पाठवतो. सहाय्यक रूपांतरण आणि कॅलिब्रेशन रूटीन देखील LLMs सोबत सामायिक केले जातात.

Ivy

आमचे इन्फरन्स HTTP प्रॉक्सी लेयर असलेले Ivy देखील कार्यप्रदर्शनात महत्त्वाची भूमिका बजावते. प्रोडक्शनमध्ये रिक्वेस्ट पेलोड्स बदलत असल्याने, वैयक्तिक रिक्वेस्ट्स वैयक्तिक प्रतिकृतींना (replicas) रूट केल्यामुळे लोड असंतुलन होऊ शकते. Ivy मोठ्या बॅचच्या रिक्वेस्ट्सचे तुकडे करते आणि प्रतिकृतींमध्ये लोड-बैलन्स करते, ज्यामुळे युटिलायझेशन सुधारते आणि लेटन्सी सुरळीत होते. Ivy मध्ये पूर्णपणे लागू केलेल्या आमच्या इन-हाउस युनिग्राम टोकनायझेशन वरील अलीकडील कार्यामुळे रेडीमेड टोकनायझर्सच्या तुलनेत लेटन्सीमध्ये मोठ्या प्रमाणात सुधारणा झाली आहे.

...तरीही कर्नेल्स महत्त्वाचे आहेत

ROSE विविध अटेंशन बॅकएंड्सना समर्थन देते. विशिष्ट समस्येच्या आकारांसाठी वेगवेगळे कर्नेल योग्य असू शकतात. काळाच्या ओघात, आम्ही रॅग्ड अटेंशन लागू करण्यासाठी FlashInfer 2, FlashInfer 3 आणि FlashAttention 4 कर्नेल समाकलित केले.

मॉडेल संरचना आणि समस्या आकारांनुसार अटेंशन-कर्नल कार्यप्रदर्शन.

सर्वसाधारणपणे, आम्हाला असे निदर्शनास येते की FlashAttention 4 अधिक वेगवान आहे. तथापि, अतिशय लांब सिक्वेन्स लांबीवर Qwen-आधारित मॉडेल्सवर FlashInfer 3 उत्तम कामगिरी करते. कार्यप्रदर्शन आणि ट्यूनिंग हे अटेंशन हेडच्या संख्येनुसार आणि परिमाणांनुसार बदलू शकत असल्याने, आम्ही अनेक कॉन्फिगरेशनसाठी समर्थन कायम ठेवतो आणि सर्व्ह करताना प्रत्येक प्रकरणावर स्वतंत्र निर्णय घेतो.

बेंचमार्क

आम्ही vLLM v0.22.0 विरुद्ध बेंचमार्क करतो, वास्तविक मॉडेल वजनांवर BF16 अचूकतेवर इन्फरन्स चालवतो आणि मूल्यमापन डेटासेटवरून इनपुट प्राप्त करतो. सर्व टायमिंग रन्सपूर्वी वार्मअप रन्स घेतले गेले ज्यांनी हे सत्यापित केले की कोसाइन साम्यामधील फरक 0.1% च्या आत आहे.

कमी-लेटन्सी एम्बेडिंग्स (p50 / p90 / p99 / कमाल ms)

आम्ही पूर्व-टोकन केलेल्या रिक्वेस्ट बॅच साईझ 1, पूर्णपणे अनुक्रमिक विनंत्या, 128, 512 आणि 4096 टोकन्सची सिक्वेन्स लांबी यासाठी रनटाइम्स रिपोर्ट करतो.

128, 512, आणि 4096 टोकन्सच्या अनुक्रम लांबींवर, विनंती बॅच आकार 1 सह, पूर्व-टोकनाइज्ड, अनुक्रमिक-विनंती एम्बेडिंग लेटन्सी बेंचमार्क्स.

कमी-लेटन्सी स्कोरिंग (p50 / p90 / p99 / कमाल ms)

पूर्व-टोकन केलेल्या रिक्वेस्ट बॅच साईझ 5, 25 आणि 50, 512 टोकन्सची सिक्वेन्स लांबी.

512 अनुक्रम लांबीवर पूर्व-टोकनाइज्ड, अनुक्रमिक-विनंती स्कोअरिंग लेटन्सी बेंचमार्क्स, 5, 25, आणि 50 च्या विनंती बॅच आकारांसह.

उच्च-थ्रूपुट एम्बेडिंग्स (emb/s)

रिक्वेस्ट बॅच साईझ 100, विनंत्या सबमिट करणारे चार समवर्ती प्रक्रिया, 512, 1024 आणि 4096 टोकन्सची सिक्वेन्स लांबी.

512, 1024, आणि 4096 टोकन्सच्या अनुक्रम लांबींवर एम्बेडिंग थ्रूपुट, विनंती बॅच आकार 100 आणि चार समकालीन प्रक्रियाांसह.

उच्च-समवर्ती एम्बेडिंग्स (p50 / p90 / p99 / कमाल ms)

सिक्वेन्स लांबी 512, बॅच साईझ 1, पण आम्ही 1, 2, 4, 8 आणि 16 समवर्ती विनंत्या पाठवतो. या बेंचमार्क्रेमध्ये Ivy आणि Tulip मधील नेटवर्किंग ओव्हरहेडसह Ivy द्वारे टोकनायझेशन खर्च देखील समाविष्ट आहे.

समकालीन विनंती संख्यांनुसार एम्बेडिंग लेटन्सी, ज्यात Ivy टोकनायझेशन आणि Ivy–Tulip नेटवर्किंग ओव्हरहेड समाविष्ट आहे.

निष्कर्ष आणि भविष्कारी कार्य

Ivy, Tulip आणि ROSE ने बनलेले सर्व्हिंग इन्फ्रास्ट्रक्चर आम्हाला Perplexity साठी कमी लेटन्सी आणि चांगल्या थ्रूपुटसह एम्बेडिंग्स सर्व्ह करण्याची परवानगी देते, ज्यामुळे रेडीमेड सोल्यूशन्सच्या तुलनेत कमी खर्चात अधिक अचूक शोध मिळतो.

विशिष्ट मॉडेल्सवर लक्ष केंद्रित करून आणि संपूर्ण स्टॅकची मालकी घेऊन, कार्यप्रदर्शन आणि लवचिकता यांच्यात प्रभावी समतोल साधण्यासाठी आवश्यक असलेले स्वातंत्र्य आम्हाला मिळते. यामध्ये अत्यंत पुनर्रूप वापरता येण्यायोग्य आणि कार्यक्षम Rust प्रिमिटिव्ह्ज अधिक सामान्य Python मॉडेलिंग कोडसोबत मिसळले जातात. vLLM, SGLang, आणि TokenSpeed यांसारख्या अनेक ओपन-सोर्स इन्फरन्स इंजिन्स त्यांच्या स्टॅकमध्ये Rust आणि C++ सारख्या भाषा समाविष्ट करत आहेत. आम्ही गेल्या दोन वर्षांत Rust मध्ये गुंतवणूक केली आहे आणि कार्यप्रदर्शन आणि देखभाल सुलभता या दोन्हीमध्ये मोठे फायदे मिळवले आहेत. एम्बेडिंग अंमलबजावणीचा मोठा भाग आमच्या LLM सर्व्हिंग स्टॅकसोबत सामायिक करून, एम्बेडिंग मॉडेल्सच्या देखभालीवर मोठा अभियांत्रिकी वेळ खर्च न करता आम्हाला थ्रूपुटमध्येही फायदे मिळतात.

मॉडेल्स विकसित होत असताना, CPU-बाउंड आणि GPU-बाउंड दोन्ही लेटन्सी कमी करण्यासाठी आम्ही आमच्या स्टॅकच्या प्रत्येक स्तरामध्ये सुधारणा करत राहू. Ivy आणि Tulip मधील आमचे कस्टम gRPC-आधारित प्रोटोकॉल आम्हाला नेटवर्क लेटन्सी कमी करण्यासाठी संप्रेषण बदलण्याची परवानगी देतात, तर ROSE संगणकीय थ्रूपुट सुधारण्यासाठी पाया प्रदान करते. याव्यतिरिक्त, संपूर्ण इकोसिस्टममध्ये फ्री-थ्रेडेड Python साठी समर्थन वाढत असताना, आम्ही ओव्हरहेड्स कमी करण्यासाठी Python-Rust परस्परसंवाद आणखी सुधारण्यास सक्षम होऊ.

संदर्भ

उद्धरण

BibTeX
@online{perplexity2026FastEmbeddingsOnGpus,
  author = {{Perplexity} and Nandor Licker and Sebastian Sepulveda and Phi Hoang and Jerry Ma},
  title = {{Fast embeddings on GPUs}},
  date = {2026-09-04},
  url = {https://www.perplexity.ai/hub/blog/fast-embeddings-on-gpus}
}