GPU-களில் வேகமான உட்பொதித்தல்கள்

இந்தக் கட்டுரை Perplexity இன் இந்த சிறப்பு வகை மாதிரிகளுக்கான சர்விங் உள்கட்டமைப்பின் உட்புறக் பார்வையை வழங்குகிறது.

ஆசிரியர்கள்Perplexity Engineering

தேடல் மற்றும் கணினி முதல் எங்கள் API தளம் வரை Perplexity-ன் அனைத்து பகுதிகளுக்கும் வேகமான மற்றும் துல்லியமான தேடல் இன்றியமையாதது ஆகும். திரைக்குப் பின்னால், கடினமான உழைப்பு எம்ப்ட்டிங் மற்றும் ரேங்கிங் மாதிரிகளால் செய்யப்படுகிறது, அவை கொடுக்கப்பட்ட வினவலுக்கு மிகவும் பொருத்தமான முடிவுகளை எங்கள் கணினிகள் அடையாளம் காண உதவுகின்றன. pplx-embed போன்ற எங்கள் சொந்த மாதிரிகளைப் பயிற்றுவித்து வழங்குவதன் மூலம் அதிநவீன தரம் மற்றும் தாமதத்தை அடைகிறோம்.

இந்தக் கட்டுரை இந்த சிறப்புக் வகுப்பு மாதிரிகளுக்கான Perplexity-இன் சர்விங் உள்கட்டமைப்பின் இன்டீரியர் பார்வையை வழங்குகிறது. AI-நேட்டிவ் தேடலின் ஊகத் தேவைகளை திறம்பட நிவர்த்தி செய்வதற்கான எங்கள் நுட்பங்களைப் பற்றி விவாதிக்கிறோம், இது எங்களின் exabyte-scale search index-ஐ இயக்கும் போது மாதிரிகளின் விரைவான முன்மாதிரி மற்றும் மதிப்பீட்டை செயல்படுத்துகிறது. இந்த நுட்பங்கள் கூட்டாக தேடல் தரம் மற்றும் செயல்திறனின் Pareto எல்லையை விரிவுபடுத்துகின்றன, குறைந்த செலவிலும் தாமதத்திலும் ஏஜெண்டுகள் மற்றும் பயனர்களுக்கு சாத்தியமான சிறந்த முடிவுகளை வழங்க எங்களுக்கு உதவுகின்றன.

தேடலுக்கான உட்பொதித்தல்கள்

ஒரு வழக்கமான search அமைப்பில், indexed documents-கள் embedding model-ஐ பயன்படுத்தி உயர்ந்த பரிமாணமுள்ள vector space-ஆக map செய்யப்பட்டு, vector database-இல் சேமிக்கப்படுகின்றன. அதே model-ஐப் பயன்படுத்தி ஒரு query-யை embed செய்வதன் மூலம், அந்த query-யின் vector-க்கு மிக அருகிலுள்ள vectors-ஐக் கண்டுபிடித்து, ஒத்த documents-களை கண்டறியலாம். இதனால் inference engine-க்கு சேவை செய்ய இரண்டு வெவ்வேறு traffic patterns உருவாகின்றன:

  • Batch Embedding: database-ஐ உருவாக்கும், விரிவாக்கும் அல்லது re-index செய்கிற போது, bulk documents-ஐ vector space-இல் embed செய்ய வேண்டும்; இதன் மூலம் throughput-ஐ அதிகப்படுத்தி cost-ஐ குறைக்க முடியும்.

வெக்டர் தேடலைத் தொடர்ந்து, ஆவணங்களின் பெரிய தொகுதிகள் மதிப்பிடப்பட வேண்டும், இது த்ரூபுட் மற்றும் தாமதத்திற்கு இடையே சமநிலையை ஏற்படுத்துகிறது.

  • ஆன்லைன் உட்பொதித்தல் (Online Embedding): தரவுத்தளத்தை வினவும்போது, தேடல்களுக்கு தாமதத்தைக் குறைக்க ஒரு குறுகிய வினவல் உட்பொதிக்கப்பட வேண்டும்.

பயன்பாட்டு வழக்குகளில் இயன்றவரை பல பொதுவான கூறுகளைப் பயன்படுத்த எங்கள் ஊக உள்கட்டமைப்பை உருவாக்கினோம். உட்பொதித்தல்களை உருவாக்க நாங்கள் வழக்கமாக சிறிய Transformer மாதிரிகளைப் பயன்படுத்துவதால், எங்களது LLM ஊகக் குறியீட்டுடன் செயலாக்கத்தில் பெரும்பகுதியைப் பகிர்ந்து கொள்கிறோம்: தொகுதி உட்பொதித்தல்கள் கணக்கீடு-கட்டுப்படுத்தப்பட்ட ப்ரீஃபில் (compute-bound prefill) போன்றது, அதே நேரத்தில் ஆன்லைன் உட்பொதித்தல்கள், பெரும்பாலும் சில டோக்கன்களில் இயங்கும், கணக்கீட்டு ரீதியாக நினைவகம்-கட்டுப்படுத்தப்பட்ட டீகோட் (memory-bound decode) போன்றது. இதனால் எம்ப்ட்டிங் மாதிரிகளுக்குச் சேவை செய்ய எங்களது உகந்ததாக்கப்பட்ட ப்ரீஃபில் மற்றும் டீகோட் கர்னல்களை மீண்டும் பயன்படுத்துகிறோம். இதன் விளைவாக, ஆன்லைன் எம்ப்ட்டிங் பணிச்சுமைகளுக்கு குறைந்த தாமதத்தைப் பாதுகாக்கும் அதே வேளையில், குறைந்தபட்ச கூடுதல் இன்ஜினியரிங் பணியுடன் பெரிய அளவிலான தொகுதி ஊகத் த்ரூபுட்டை அடைய முடியும்.

Tulips, Roses, மற்றும் சில Ivy

எங்கள் API தளம் மூலம் உள்நாட்டிலும் வெளியிலும் நிலையான APIகள் மூலம் ஊகத்தை வெளிப்படுத்துகிறோம். திரைக்குப் பின்னால், ஒரு எம்ப்ட்டிங் கோரிக்கையை செயலாக்குவதில் பல சேவைகள் ஈடுபட்டுள்ளன:

  • Ivy என்பது Perplexity சேவைகள் அழைக்கும் ஒரு Rust HTTP கேட்வே ஆகும்.

இது JSON பாகுபடுத்துதல், டோக்கனைசேஷன், உள்ளீட்டு டெம்ப்ளேட்டிங் மற்றும் தொகுதி பிரிப்பு போன்ற கோரிக்கைகளுக்கான CPU-சார்ந்த வேலையைக் கையாளுகிறது, கோரிக்கைகளை கீழ்நிலை சேவையகங்களுக்கான தனிப்பயன் gRPC நெறிமுறையாக மொழிபெயர்க்கிறது. இந்தப் பிரிப்பு, கனமான ஊக நிகழ்வுகளைத் தொடாமல் டோக்கனைசேஷன் மற்றும் உள்ளீட்டு வடிவமைப்பு தொடர்பான சில அளவுருக்களை உள்ளமைக்க நம்மை அனுமதிக்கிறது.

  • Tulip என்பது ஊக சேவையக இடைமுகம் ஆகும்.

இது Rust, tokio, மற்றும் tonic கொண்டு செயல்படுத்தப்பட்ட ஒரு gRPC server ஆகும். Tulip, gRPC inference requests-ஐப் பெற்று, scheduling மற்றும் batching-ஐ கையாளுகிறது. பின்னர் அது batches-ஐ ROSE engine-க்கு அனுப்பி, client-களுக்கு முடிக்கப்பட்ட responses-ஐ திருப்பி வழங்குகிறது.

  • ROSE (Runtime-Optimized Serving Engine) மாதிரி அனுமானத்தை (model inference) செயல்படுத்துகிறது.

இது முதன்மையாக Python-ல் வரையறுக்கப்பட்டுள்ளது, பரந்த அளவிலான மாதிரிகளுக்காக kernels, லேயர்கள் மற்றும் வரையறைகளை வழங்குகிறது. ROSE மாதிரிகள் வழியாக ஃபார்வர்டு பாஸ்களை செயல்படுத்துகிறது, மேலும் எம்ப்ட்டிங்குகளுக்காக பிரத்யேகமான CUDA வரைபடு மேலாண்மையையும் வழங்குகிறது. இது ஒரு step() செயல்பாடு மூலம் Tulip-டன் இணைக்கப்பட்டுள்ளது, இது ஒரு தொகுதியை எடுத்து, முடுக்கியில் (accelerator) அது செய்யும் கணக்கீட்டிற்கான குறிப்பை வழங்குகிறது.

GPUகளில் ROSE-ஐ இயக்கும் Tulip servers-க்கு Ivy-இலிருந்து தொடங்கும் embedding requests-க்கான model-serving architecture.

கர்னலுக்கு அப்பால் கவனம் செலுத்துதல்

Transformer அடிப்படையிலான மாதிரிகளும், அடிப்படையான Hopper/Blackwell கட்டமைப்புகளும் முதிர்ந்த தொழில்நுட்பங்கள் என்பதால், GPU பக்கத்தில் உள்ள embedding inference பல்வேறு inference engines முழுவதும் பெரும்பாலும் உகந்த implementation-ஆக ஒருங்கிணைந்துவிட்டது. இருந்தாலும், client-க்கு models-ஐ end-to-end-ஆக வெளிப்படுத்தும் runtimes மற்றும் harnesses-இல் மேலதிக மேம்பாட்டு வாய்ப்புகளை நாங்கள் கண்டறிந்தோம். குறிப்பாக, CUDA graphs-ஐ கவனமாக நிர்வகிப்பதன் மூலமும், native Rust engine-இல் GPU-side முடிவை asynchronously கண்காணிக்க ஒரு LazyTensor abstraction-ஐ உருவாக்குவதன் மூலமும் latencies-ஐ மேம்படுத்த முடியும் என்பதை கண்டோம். இந்த அம்சங்களை Tulip-இல் நாங்கள் செயல்படுத்தினோம், இதனால் அது ROSE-இன் model implementations-உடன் திறம்பட interface செய்ய முடிந்தது.

Tulip

எங்கள் மாதிரிச் சேவையின் மீது முடிந்தவரை இலகுவான இடைமுகமாக இருக்க Tulip-ஐ வடிவமைத்துள்ளோம். இது டோக்கியோ ஒத்திசைவற்ற பணிகளில் (Tokio async tasks) உள்வரும் கோரிக்கைகளைக் கையாளுகிறது, இது கண்காணிக்கும் கோரிக்கைகளின் குளத்தைப் பராமரிக்கிறது மற்றும் முடுக்கிக்கு அனுப்பும் தொகுதிகளை திட்டமிடுகிறது. Tulip-ல் உள்ள திட்டமிடல் பொறிமுறை மிகவும் எளிமையானது: Tulip வேலையை அனுப்பும்போது அல்லது முடிவுகளுக்காகக் காத்திருக்கும் போது கோரிக்கைகள் குவிகின்றன. குவிந்த கோரிக்கைகளிலிருந்து, மாதிரி வழியாக இயக்க முதலில் வருவோருக்கு முன்னுரிமை என்ற அடிப்படையில் வரிசைகள் தேர்ந்தெடுக்கப்படுகின்றன.

எளிய திட்டமிடல் பொறிமுறையானது மாதிரி செயல்திறன் பற்றிய அவதானிப்பால் தூண்டப்படுகிறது. சிறிய எம்ப்ட்டிங் மாதிரிகளுக்கு, நாம் சேவை செய்யும் வரிசை நீளங்களில், கவன ஈர்ப்பின் இருபடிச் செலவை விட அடர்த்தியான லேயர்களின் நேரியல் செலவு ஆதிக்கம் செலுத்துவதைக் கவனித்தோம். எனவே, தாமதம் பெரும்பாலும் வரிசைகளின் எண்ணிக்கைக்கு அல்ல, டோக்கன்களின் எண்ணிக்கைக்கு விகிதாசாரமாகும். இதன் விளைவாக, ஒரு தொகுதி GPU-ஐ நிரப்புவதற்குப் போதுமானதாக மாறியவுடன், அதாவது ஒரு பில்லியன் அளவுள்ள மாதிரிக்கு கீழ் 512 டோக்கன்கள் இருக்கும் போது, அதில் அதிக வரிசைகளைச் சேர்ப்பது செயல்திறனை மேம்படுத்தாது.

மாதிரியுடன் திறம்பட இடைமுகப்படுத்த, Tulip CUDA வரைபடங்கள் மற்றும் லேசி ரிசல்ட் டிராக்கிங் ஆகியவற்றை நம்பி GPU மற்றும் CPU வேலையை ஒன்றுடன் ஒன்று சேர்த்து கிடைக்கக்கூடிய வளங்களை முழுமையாகப் பயன்படுத்துகிறது.

CUDA வரைபட மேலாண்மை

ஒரு மாதிரியின் ஃபார்வர்டு பாஸை இயக்குவது CPU-சார்ந்த மற்றும் GPU-சார்ந்த வேலை இரண்டையும் உள்ளடக்கியது. பொருத்தமான அளவுருக்களுடன் தொகுதிகளை திட்டமிடவும் கர்னல்களைத் தொடங்கவும் CPU பொறுப்பாகும், அதே நேரத்தில் GPU தொடர்புடைய மேட்ரிக்ஸ் பெருக்கல், கவன ஈர்ப்பு (attention), நார்ம் அல்லது ஆக்டிவேஷன் கர்னல்களை இயக்குகிறது. பயிற்சி மற்றும் மறு குறியீட்டு (reindexing) போன்ற அதிக த்ரூபுட் பணிச்சுமைகளுக்கு, தொகுதி அளவுகள் மற்றும் GPU-சார்ந்த தாமதம் இரண்டும் பெரியதாக இருப்பதால் CPU-சார்ந்த ஓவர்ஹெட்டுகள் குறைவாக இருக்கும். இருப்பினும், சிறிய தொகுதி அளவுகளில், CPU-சார்ந்த வேலை GPU-சார்ந்த வேலையை விட அதிகமாக இருக்கலாம்.

CUDA graphகள் இல்லாமல் ஒரு forward pass போது CPU மற்றும் GPU செயல்பாடு.

ஓவர்ஹெட்டுகளைத் தணிக்க, தனிப்பட்ட கர்னல்களைத் தொடங்குவதற்குப் பதிலாக, CUDA டிரைவருக்கு ஒரே ஒரு அழைப்புடன் ஃபார்வர்டு பாஸின் அனைத்து கர்னல்களையும் தொடங்க தேவையான மெட்டாடேட்டாவைக் கைப்பற்ற ஒரு CUDA வரைபடத்தை உருவாக்கலாம். இது CUDA வரைபடங்களைக் கைப்பற்றக்கூடிய உள்ளமைவுகளுக்கு விலை உயர்ந்த Python மற்றும் PyTorch குறியீட்டை மீண்டும் இயக்கும் தேவையை நீக்குகிறது.

ஒவ்வொரு மாதிரிக்கும், GPU செயலாக்கம் CPU-தரப்பு கர்னல் துவக்கத்தை விட விலை அதிகம் உள்ள குறைந்தபட்ச டோக்கன்களின் எண்ணிக்கையைத் தீர்மானிக்கும் ஒரு மாறுதல் புள்ளியை (inflection point) நாங்கள் கண்காணிக்கிறோம். உட்பொதித்தல் மாதிரிகள் சிறியவை என்பதால், இந்த மாறுதல் புள்ளி ஆயிரக்கணக்கான டோக்கன்கள் மற்றும் பத்துக்கும் மேற்பட்ட வரிசைகளின் தொகுதிகளில் வருவதை நாங்கள் கவனிக்கிறோம். சில கவன ஈர்ப்பு செயலாக்கங்கள் கர்னல் துவக்கங்களை உள்ளமைக்க டைனமிக் ஹோஸ்ட்-சைடு உள்ளீடுகளை நம்பியுள்ளன, முழு-மாதிரி ப்ரீஃபில்/அடர்த்தியான CUDA வரைபடங்களைத் தடுக்கின்றன. எங்கள் ஊக இயந்திரத்தில் அவற்றை இயக்க தொடர்புடைய கர்னல்களில் மாற்றங்களை upstream செய்துள்ளோம்.

ஓவர்ஹெட்டுகளை நிவர்த்தி செய்ய, அனைத்து எம்ப்ட்டிங் மாதிரிகளுக்கும் முழு-மாதிரி CUDA வரைபடங்களை உருவாக்குகிறோம் மற்றும் GPU வேலையுடன் CPU வேலையை ஒன்றுடன் ஒன்று சேர்க்கிறோம். CUDA வரைபடங்கள் CPU-சார்ந்த ஓவர்ஹெட்டுகளைக் குறைப்பதால், ஒரு வரைபடம் தொடங்கப்பட்டதும், அடுத்த தொகுதி கிடைக்கும் Whenever அதைத் தொடங்கவும் வரிசைப்படுத்தவும் எங்களுக்கு இலவச நேரம் கிடைக்கும். நிலுவையில் உள்ள தொகுதியின் முடிவுகள் LazyTensor உடன் கண்காணிக்கப்படுகின்றன, இது முந்தைய தொகுதி செயலாக்கத்தை முடிக்கும் வரை Rust-ல் ஒரு ஒத்திசைவற்ற பணி தடுக்க அனுமதிக்கிறது. கர்னல் துவக்கங்களின் செலவால் நாம் பின்னுக்குத் தள்ளப்படவில்லை என்பதை உறுதி செய்வதன் மூலம் குறைந்த தாமதச் சேவைக்கு CUDA வரைபடங்கள் உதவுகின்றன மற்றும் அடுத்த தொகுதியில் வேலை செய்ய CPU-ஐ முன்கூட்டியே விடுவிப்பதால் அதிக த்ரூபுட் வழக்கில் மேம்பட்ட திட்டமிடலை எளிதாக்குகின்றன.

CUDA graphகளுடன் ஒரு forward pass போது CPU மற்றும் GPU செயல்பாடு.

ஒவ்வொரு தனித்துவமான உள்ளமைவுக்கும் CUDA வரைபடங்கள் கைப்பற்றப்பட வேண்டும், அதாவது எம்ப்ட்டிங்குகளுக்கு வரிசை எண்ணிக்கை மற்றும் டோக்கன் எண்ணிக்கை கலவைக்கு ஒரு வரைபடம் தேவை. இந்த கட்டம் விரிவானது என்பதால், டோக்கன் எண்ணிக்கைகளை 64 அல்லது 256 இன் மடங்குகளாக இருக்கும் பக்கெட்டுகளுக்கு பேட் செய்கிறோம். இது இன்னும் ஆயிரக்கணக்கான வரைபடங்களை விளைவிக்கிறது, இது ஒரு வழக்கமான மாதிரிக்கு பிடிக்க பல நிமிடங்கள் ஆகலாம். கேப்சர் செலவு இரண்டு மூலங்களிலிருந்து வருகிறது: கர்னல்களை கம்பைல் செய்ய மற்றும் அவற்றுக்குத் தேவையான பல்வேறு கர்னல்களுக்கு பஃபர்களை அமைக்க இயக்கப்பட வேண்டிய ஒரு ஈகர் ஃபார்வர்டு பாஸ், அதைத் தொடர்ந்து Python குறியீட்டை மீண்டும் இயக்கும் கேப்சர் ரன்.

இயந்திரம் சேவை செய்யும் போது CUDA வரைபடங்களை சோம்பலாக (lazily) கைப்பற்றுவதன் மூலம் தொடக்கச் செலவுகளைக் குறைக்கிறோம். ஒவ்வொரு உள்ளமைவையும் நாங்கள் கண்காணித்து, இரண்டாவது ஹிட்டில் வரைபடம் கேப்சர் மற்றும் ரீப்ளேவைத் தூண்டுவதற்கு முன்பு அது ஒரு ஈகர் வார்ம்அப் ஓ செல்வதை உறுதிசெய்கிறோம். அதே வரைபட உள்ளமைவின் அனைத்து அடுத்தடுத்த செயலாக்கங்களும் CUDA வரைபட்டு ரீப்ளே மூலம் செல்கின்றன. லேசி வரைபட்டு கேப்சர் தொடக்கத்தின் போது p99 தாமதங்களில் தாக்கத்தை ஏற்படுத்துகிறது; இருப்பினும், பல நிமிட ஈகர் வேலையை பல மணிநேரங்களில் பரப்புவதில் இது மதிப்புமிக்கது. விரைவான தொடக்க நேரங்கள் எம்ப்ட்டிங் வரிசைப்படுத்தல்களை சிறப்பாக அளவிட மற்றும் நிர்வகிக்க அனுமதிக்கின்றன.

லேசி டென்சர்கள் (Lazy Tensors)

CUDA வழியாக, GPU வேலை asynchronous ஆகும். ஒரு kernel-ஐ asynchronous-ஆக launch செய்வது அதை ஒரு stream-இல் enqueue செய்வதால், host code முடிவான vectors-ஐப் படிக்க explicitly synchronize செய்ய வேண்டும். அதிக அளவிலான parallelism-ஐ எளிதாக்கவும், device-இல் முந்தைய batch முடிவடையும் வரை காத்திருக்கும்போது எதிர்கால batches-ஐ தொடங்கவும், மதிப்புகளை track செய்ய ஒரு LazyTensor abstraction-ஐ நாங்கள் நம்புகிறோம்.

LazyTensor என்பது பக்க-பூட்டப்பட்ட நினைவகத்தில் (page-locked memory) உள்ள ஒரு ஹோஸ்ட் பஃபரையும், சாதனத்திலிருந்து தரவை நகலெடுக்கும் ஒரு நிகழ்வு (event) மூலம் cudaMemcpyAsync செயல்பாட்டையும் கண்காணிக்கிறது. அதே ஸ்ட்ரீமில் ஃபார்வர்டு பாஸ் தொடங்கிய பிறகு இது தொடங்கப்படுகிறது. காப்பி செயல்பாடு ஸ்ட்ரீமில் உள்ள முந்தைய அனைத்து கர்னல்களும் இயக்கப்படுவதற்காகக் காத்திருக்க வேண்டும் என்பதால், தொடர்புடைய நிகழ்வு ஃபார்வர்டு பாஸின் நிறைவு மற்றும் CPU-வில் முடிவு கிடைப்பதை இரண்டையும் கண்காணிக்கிறது.

CUDA graph launch முதல் அசிங்க்ரோனஸ் நகலெடுப்பு மற்றும் ஒத்திசைவு வரை, LazyTensor செயல்பாடு.

GPU மற்றும் CPU வேலையை ஒன்றுடன் ஒன்று சேர்க்க (overlap) எங்கள் ROSE என்கோடர் இயந்திரத்தில் LazyTensor-களைப் பயன்படுத்துகிறோம். ஒவ்வொரு step() அழைப்பும் CUDA வரைபடத்தை இயக்குவதற்கும் அது முடியும் வரை காத்திருப்பதற்கும் பதிலாக, step() அதன் முடிவை ஒத்திசைவற்ற முறையில் கண்காணிக்க ஒரு LazyTensor-ஐ வழங்குகிறது. CUDA வரைபடங்களுடன் இணைந்து, குறைந்த தாமதங்கள் மற்றும் சிறந்த த்ரூபுட்டை அடைய இது எங்களுக்கு உதவுகிறது.

தொடர்ச்சியான GPU batchகளுடன் மேலிடப்படும் CPU தயாரிப்பு மற்றும் ஒத்திசைவு.

ROSE

LLM சர்விங் செய்வதற்காக நாங்கள் ursprünglich உருவாக்கிய எங்களின் ROSE இயந்திரத்தை, எம்ப்ட்டிங் மாதிரிகளின் செயலாக்கத்தையும் கையாள நாங்கள் மாற்றியமைத்துள்ளோம். எம்ப்ட்டிங் மாதிரிகளை ஆதரிக்க தேவையான முயற்சியைக் குறைக்க, ROSE LLM-கள் மற்றும் எம்ப்ட்டிங்குகளுக்கு இடையே குறியீட்டை தீவிரமாக மீண்டும் பயன்படுத்துகிறது. உதாரணமாக, pplx-embed சர்விங் மற்றும் Qwen3.5 LLM டீகோடிங் அனைத்தும் ஒரே கர்னல்கள் வழியாக செல்கின்றன. முன்மாதிரி, மதிப்பீடு மற்றும் தயாரிப்பு ஊகம் ஆகியவற்றிற்காக LLM- இலிருந்து முதலில் ஃபைன்-ட்யூன் செய்யப்பட்ட எம்ப்ட்டிங் மாதிரிக்கு எளிதில் சேவை செய்ய இந்தப் பகிர்வு எங்களுக்கு உதவுகிறது.

அடர்த்தியான லேயர்களுக்கு, டோக்கன் வெக்டர்கள் தனித்தனியாக செயலாக்கப்படுவதால் எம்ப்ட்டிங் மற்றும் LLM ஊகம் ஒரே மாதிரியாக இருக்கும். கவன ஈர்ப்பு லேயர்களில், LLM-களுக்குத் தேவையான பேக்ட் ப்ரீஃபில் மற்றும் டீகோட் அமைப்புகளுடன், ராக்டு உள்ளீடுகளுக்கான (ragged inputs) ஆதரவைச் சேர்ப்பதன் மூலம் வேறுபாடுகள் கையாளப்படுகின்றன. ஒரு எம்ப்ட்டிங் மாதிரிக்குச் சேவை செய்யும் போது, நாங்கள் KV கேச்-ஐ இன்ஸ்டன்டியேட் செய்ய மாட்டோம் மற்றும் பேடிங்கைத் தவிர்க்க ராக்டு வடிவத்தை ஆதரிக்கும் கவன ஈர்ப்பு கர்னல்களின் மாறுபாடுகளுக்கு அனுப்புகிறோம். துணைபுரியும் மாற்று மற்றும் அளவுத்திருத்த வழக்கங்களும் LLM-களுடன் பகிரப்படுகின்றன.

Ivy

எங்கள் inference HTTP proxy layer ஆன Ivy, செயல்திறனில் முக்கிய பங்கையும் வகிக்கிறது. production-இல் request payloads மாறுபடுவதால், individual requests-ஐ individual replicas-க்கு route செய்வது load imbalance-ஐ ஏற்படுத்தக்கூடும். Ivy பெரிய-batch requests-ஐ chunks-ஆகப் பிரித்து, அவற்றை replicas-களுக்கு இடையே load-balance செய்கிறது; இதனால் utilization மேம்பட்டு latency மென்மையடைகிறது. Ivy-இல் முழுமையாக roll out செய்யப்பட்டுள்ள in-house unigram tokenization பற்றிய எங்களின் சமீபத்திய வேலை, off-the-shelf tokenizers-ஐ விட latencies-ஐ குறிப்பிடத்தக்க வகையில் மேம்படுத்துகிறது.

...ஆனால் கர்னல்கள் இன்னும் முக்கியம்

ROSE பல்வேறு கவன ஈர்ப்பு பேக்கெண்டுகளை ஆதரிக்கிறது. வெவ்வேறு கர்னல்கள் குறிப்பிட்ட சிக்கல் அளவிற்குப் பொருத்தமானதாக இருக்கலாம். காலப்போக்கில், ராக்டு கவன ஈர்ப்பை செயல்படுத்த FlashInfer 2, FlashInfer 3 மற்றும் FlashAttention 4 கர்னல்களை ஒருங்கிணைத்தோம்.

மாதிரி கட்டமைப்புகள் மற்றும் பிரச்சினை அளவுகளுக்கிடையில் attention-kernel செயல்திறன்.

பொதுவாக, FlashAttention 4 வேகமானது என்பதைக் காண்கிறோம். இருப்பினும், மிகவும் நீண்ட வரிசை நீளங்களில் Qwen-அடிப்படையிலான மாதிரிகளில் FlashInfer 3 இதை விட சிறப்பாகச் செயல்படுகிறது. செயல்திறன் மற்றும் ட்யூனிங் ஆகியவை கவன ஈர்ப்பு ஹெட்ஸின் (attention heads) எண்ணிக்கை மற்றும் பரிமாணத்துடன் மாறுபடும் என்பதால், நாங்கள் பல உள்ளமைவுகளுக்கான ஆதரவைப் பேணுகிறோம் மற்றும் சர்வ் செய்யும் போது ஒவ்வொரு வழக்கின் அடிப்படையில் முடிவெடுக்கிறோம்.

பெஞ்ச்மார்க்குகள்

மதிப்பீட்டுத் தரவுத்தொகுப்புகளிலிருந்து பெறப்பட்ட உண்மையான மாதிரி எடைகள் மற்றும் உள்ளீடுகளில் BF16 துல்லியத்தில் ஊகத்தை இயக்கி, vLLM v0.22.0-க்கு எதிராக நாங்கள் பெஞ்ச்மார்க் செய்கிறோம். அனைத்து நேர ஓட்டங்களுக்கும் முன் வார்ம்அப் ஓட்டங்கள் இருந்தன, அவை கோசைன் ஒற்றுமையின் வேறுபாடு 0.1%க்குள் இருப்பதை சரிபார்த்தன.

குறைந்த தாமத உட்பொதித்தல்கள் (p50 / p90 / p99 / அதிகபட்ச ms)

முன் டோக்கன் செய்யப்பட்ட கோரிக்கை தொகுதி அளவு 1, முழுமையான வரிசை கோரிக்கைகள், 128, 512 மற்றும் 4096 டோக்கன்களின் வரிசை நீளங்களுக்கான இயக்க நேரங்களை நாங்கள் தெரிவிக்கிறோம்.

128, 512, மற்றும் 4096 token sequence நீளங்களில் pre-tokenized, sequential-request embedding latency benchmarks, request batch size 1 உடன்.

குறைந்த தாமத ஸ்கோரிங் (p50 / p90 / p99 / அதிகபட்ச ms)

முன் டோக்கன் செய்யப்பட்ட கோரிக்கை தொகுதி அளவுகள் 5, 25 மற்றும் 50, 512 டோக்கன்களின் வரிசை நீளம்.

512 sequence length-இல் pre-tokenized, sequential-request scoring latency benchmarks, request batch sizes 5, 25, மற்றும் 50 உடன்.

அதிக த்ரூபுட் உட்பொதித்தல்கள் (emb/s)

கோரிக்கை தொகுதி அளவு 100, கோரிக்கைகளை சமர்ப்பிக்கும் நான்கு ஒரே நேரத்தில் நிகழும் செயல்முறைகள், 512, 1024 மற்றும் 4096 டோக்கன்களின் வரிசை நீளங்கள்.

512, 1024, மற்றும் 4096 token sequence நீளங்களில் embedding throughput, request batch size 100 மற்றும் நான்கு ஒரே நேர செயல்முறைகளுடன்.

அதிக ஒத்திசைவு உட்பொதித்தல்கள் (p50 / p90 / p99 / அதிகபட்ச ms)

வரிசை நீளம் 512, தொகுதி அளவு 1, ஆனால் நாங்கள் 1, 2, 4, 8 மற்றும் 16 ஒரே நேரத்தில் கோரிக்கைகளை அனுப்புகிறோம். இந்த பெஞ்ச்மார்க் Ivy மற்றும் Tulip இடையேயான நெட்வொர்க்கிங் ஓவர்ஹெட்டுடன் சேர்த்து, Ivy மூலம் டோக்கனைசேஷன் செலவுகளையும் உள்ளடக்கியது.

Ivy tokenization மற்றும் Ivy–Tulip networking overhead உட்பட, concurrent request எண்ணிக்கைகளில் embedding latency.

முடிவுரை மற்றும் எதிர்கால வேலை

Ivy, Tulip மற்றும் ROSE ஆகியவற்றால் உருவாக்கப்பட்ட சர்விங் உள்கட்டமைப்பு Perplexity-க்கான உட்பொதித்தல்களை குறைந்த தாமதத்துடனும் சிறந்த த்ரூபுட்டுடனும் வழங்க அனுமதிக்கிறது, இதன் விளைவாக ஆஃப்-தி-ஷெல்ஃப் தீர்வுகளுடன் ஒப்பிடும்போது குறைந்த செலவில் மிகவும் துல்லியமான தேடல் கிடைக்கிறது.

குறிப்பிட்ட மாதிரிகள்மீது கவனம் செலுத்தி, முழு stack-இன் பொறுப்பையும் ஏற்றுக்கொள்வதன் மூலம், உயர்ந்த அளவில் மீள்பயன்படுத்தக்கூடியதும் செயல்திறன் மிக்கதுமான Rust primitives-ஐ, மேலும் பொதுவான Python modeling code-உடன் இணைத்து, செயல்திறனும் நெகிழ்வுத்தன்மையும் இடையே ஒரு பயனுள்ள சமநிலையை ஏற்படுத்த தேவையான சுதந்திரத்தை நாங்கள் பெறுகிறோம். vLLM, SGLang, மற்றும் TokenSpeed போன்ற பல open-source inference engines, Rust மற்றும் C++ போன்ற மொழிகளை தங்களின் stack-இல் ஒருங்கிணைத்துக் கொண்டிருக்கின்றன. கடந்த இரண்டு ஆண்டுகளாக நாங்கள் Rust-இல் முதலீடு செய்து வருகிறோம்; அதனால் செயல்திறனிலும் maintainability-யிலும் சிறந்த பலன்களைப் பெற்றுள்ளோம். எங்கள் embedding implementation-இன் பெரும்பகுதியை எங்கள் LLM serving stack-உடன் பகிர்வதன் மூலம், embedding models-ஐ பராமரிக்க குறிப்பிடத்தக்க engineering effort-ஐ செலவிட வேண்டாமலேயே, throughput-இலும் நாங்கள் மேம்பாடுகளைப் பெறுகிறோம்.

மாதிரிகள் உருவாகும்போது, 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}
}