GPU-களில் வேகமான உட்பொதித்தல்கள்
தேடல் மற்றும் கணினி முதல் எங்கள் API தளம் வரை Perplexity-ன் அனைத்து பகுதிகளுக்கும் வேகமான மற்றும் துல்லியமான தேடல் இன்றியமையாதது ஆகும். திரைக்குப் பின்னால், கடினமான உழைப்பு எம்ப்ட்டிங் மற்றும் ரேங்கிங் மாதிரிகளால் செய்யப்படுகிறது, அவை கொடுக்கப்பட்ட வினவலுக்கு மிகவும் பொருத்தமான முடிவுகளை எங்கள் கணினிகள் அடையாளம் காண உதவுகின்றன. மாநிலத்தை அடைகிறோம்
தேடல் மற்றும் கணினி முதல் எங்கள் API தளம் வரை Perplexity-ன் அனைத்து பகுதிகளுக்கும் வேகமான மற்றும் துல்லியமான தேடல் இன்றியமையாதது ஆகும். திரைக்குப் பின்னால், கடினமான உழைப்பு எம்ப்ட்டிங் மற்றும் ரேங்கிங் மாதிரிகளால் செய்யப்படுகிறது, அவை கொடுக்கப்பட்ட வினவலுக்கு மிகவும் பொருத்தமான முடிவுகளை எங்கள் கணினிகள் அடையாளம் காண உதவுகின்றன. pplx-embed போன்ற எங்கள் சொந்த மாதிரிகளைப் பயிற்றுவித்து வழங்குவதன் மூலம் அதிநவீன தரம் மற்றும் தாமதத்தை அடைகிறோம்.
இந்தக் கட்டுரை இந்த சிறப்புக் வகுப்பு மாதிரிகளுக்கான Perplexity-இன் சர்விங் உள்கட்டமைப்பின் இன்டீரியர் பார்வையை வழங்குகிறது. AI-நேட்டிவ் தேடலின் ஊகத் தேவைகளை திறம்பட நிவர்த்தி செய்வதற்கான எங்கள் நுட்பங்களைப் பற்றி விவாதிக்கிறோம், இது எங்களின் exabyte-scale search index-ஐ இயக்கும் போது மாதிரிகளின் விரைவான முன்மாதிரி மற்றும் மதிப்பீட்டை செயல்படுத்துகிறது. இந்த நுட்பங்கள் கூட்டாக தேடல் தரம் மற்றும் செயல்திறனின் Pareto எல்லையை விரிவுபடுத்துகின்றன, குறைந்த செலவிலும் தாமதத்திலும் ஏஜெண்டுகள் மற்றும் பயனர்களுக்கு சாத்தியமான சிறந்த முடிவுகளை வழங்க எங்களுக்கு உதவுகின்றன.
தேடலுக்கான உட்பொதித்தல்கள்
ஒரு வழக்கமான தேடல் அமைப்பில், அட்டவணைப்படுத்தப்பட்ட ஆவணங்கள் ஒரு எம்ப்ட்டிங் மாதிரியைப் பயன்படுத்தி உயர்-பரிமாண வெக்டர் ஸ்பேஸ்-ல் மேப் செய்யப்பட்டு வெக்டர் தரவுத்தளத்தில் சேமிக்கப்படும். அதே மாதிரியைப் பயன்படுத்தி ஒரு வினவலை உட்பொதிப்பதன் மூலம், வினவலின் வெக்டருக்கு மிக நெருக்கமான வெக்டர்களைக் கண்டுபிடிப்பதன் மூலம் ஒத்த ஆவணங்களைக் கண்டறிய முடியும். இது ஒரு ஊக இயந்திரம் சேவை செய்ய இரண்டு வெவ்வேறு போக்குவரத்து வடிவங்களை உருவாக்குகிறது:
- தொகுதி உட்பொதித்தல் (Batch Embedding): தரவுத்தளத்தை உருவாக்கும்போது, விரிவுபடுத்தும்போது அல்லது மறு குறியீடு செய்யும்போது, செலவைக் குறைக்க த்ரூபுட்டை அதிகரிக்க, மொத்த ஆவணங்கள் வெக்டர் ஸ்பேஸ்-ல் உட்பொதிக்கப்பட வேண்டும்.
வெக்டர் தேடலைத் தொடர்ந்து, ஆவணங்களின் பெரிய தொகுதிகள் மதிப்பிடப்பட வேண்டும், இது த்ரூபுட் மற்றும் தாமதத்திற்கு இடையே சமநிலையை ஏற்படுத்துகிறது.
- ஆன்லைன் உட்பொதித்தல் (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 சேவையகம் ஆகும். Tulip gRPC ஊக கோரிக்கைகளைப் பெறுகிறது, திட்டமிடல் மற்றும் தொகுத்தலைக் கையாளுகிறது. பின்னர் அது தொகுதிகளை ROSE இயந்திரத்திற்கு அனுப்பி, முடிக்கப்பட்ட பதில்களை கிளைண்டுகளுக்குத் தருகிறது.
- **ROSE** (Runtime-Optimized Serving Engine) மாதிரி ஊகத்தை (model inference) செயல்படுத்துகிறது.
இது முதன்மையாக Python-ல் வரையறுக்கப்பட்டுள்ளது, பரந்த அளவிலான மாதிரிகளுக்காக kernels, லேயர்கள் மற்றும் வரையறைகளை வழங்குகிறது. ROSE மாதிரிகள் வழியாக ஃபார்வர்டு பாஸ்களை செயல்படுத்துகிறது, மேலும் எம்ப்ட்டிங்குகளுக்காக பிரத்யேகமான CUDA வரைபடு மேலாண்மையையும் வழங்குகிறது. இது ஒரு step() செயல்பாடு மூலம் Tulip-டன் இணைக்கப்பட்டுள்ளது, இது ஒரு தொகுதியை எடுத்து, முடுக்கியில் (accelerator) அது செய்யும் கணக்கீட்டிற்கான குறிப்பை வழங்குகிறது.
கர்னலுக்கு அப்பால் கவனம் செலுத்துதல்
Transformer-அடிப்படையிலான மாதிரிகள் மற்றும் அடிப்படை Hopper/Blackwell கட்டமைப்புகள் இரண்டும் முதிர்ந்த தொழில்நுட்பங்கள் ஆகும், எனவே GPU தரப்பினhல் உட்பொதித்தல் ஊகம் (embedding inference) பல்வேறு ஊக இயந்திரங்களில் (inference engines) பெரும்பாலும் உகந்த செயலாக்கமாக ஒருங்கிணைந்துள்ளது. அப்படியிருந்தும், ரன்டைம்கள் மற்றும் ஹார்னஸ்களில் கூடுதல் மேம்பாட்டு வாய்ப்புகளை நாங்கள் கண்டுபிடித்தோம், அவை மாதிரிகளை எண்ட்-டூ-எண்டாக ஒரு கிளையண்டிற்கு வெளிப்படுத்துகின்றன. குறிப்பாக, CUDA வரைபடங்களை கவனமாக நிர்வகிப்பதன் மூலமும் மற்றும் நேட்டிவ் Rust இயந்திரத்தில் GPU தரப்பு முடிவை ஒத்திசைவற்ற முறையில் (asynchronously) கண்காணிக்க LazyTensor சுருக்கத்தை உருவாக்குவதன் மூலமும் தாமதங்களை மேம்படுத்த முடியும் என்பதைக் கண்டறிந்தோம். இந்த அம்சங்களை நாங்கள் Tulip-ல் செயல்படுத்தினோம், இதனால் அது ROSE இன் மாதிரி செயலாக்கங்களுடன் திறம்பட இடைமுகப்படுத்த முடியும்.
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 டிரைவருக்கு ஒரே ஒரு அழைப்புடன் ஃபார்வர்டு பாஸின் அனைத்து கர்னல்களையும் தொடங்க தேவையான மெட்டாடேட்டாவைக் கைப்பற்ற ஒரு CUDA வரைபடத்தை உருவாக்கலாம். இது CUDA வரைபடங்களைக் கைப்பற்றக்கூடிய உள்ளமைவுகளுக்கு விலை உயர்ந்த Python மற்றும் PyTorch குறியீட்டை மீண்டும் இயக்கும் தேவையை நீக்குகிறது.
ஒவ்வொரு மாதிரிக்கும், GPU செயலாக்கம் CPU-தரப்பு கர்னல் துவக்கத்தை விட விலை அதிகம் உள்ள குறைந்தபட்ச டோக்கன்களின் எண்ணிக்கையைத் தீர்மானிக்கும் ஒரு மாறுதல் புள்ளியை (inflection point) நாங்கள் கண்காணிக்கிறோம். உட்பொதித்தல் மாதிரிகள் சிறியவை என்பதால், இந்த மாறுதல் புள்ளி ஆயிரக்கணக்கான டோக்கன்கள் மற்றும் பத்துக்கும் மேற்பட்ட வரிசைகளின் தொகுதிகளில் வருவதை நாங்கள் கவனிக்கிறோம். சில கவன ஈர்ப்பு செயலாக்கங்கள் கர்னல் துவக்கங்களை உள்ளமைக்க டைனமிக் ஹோஸ்ட்-சைடு உள்ளீடுகளை நம்பியுள்ளன, முழு-மாதிரி ப்ரீஃபில்/அடர்த்தியான CUDA வரைபடங்களைத் தடுக்கின்றன. எங்கள் ஊக இயந்திரத்தில் அவற்றை இயக்க தொடர்புடைய கர்னல்களில் மாற்றங்களை upstream செய்துள்ளோம்.
ஓவர்ஹெட்டுகளை நிவர்த்தி செய்ய, அனைத்து எம்ப்ட்டிங் மாதிரிகளுக்கும் முழு-மாதிரி CUDA வரைபடங்களை உருவாக்குகிறோம் மற்றும் GPU வேலையுடன் CPU வேலையை ஒன்றுடன் ஒன்று சேர்க்கிறோம். CUDA வரைபடங்கள் CPU-சார்ந்த ஓவர்ஹெட்டுகளைக் குறைப்பதால், ஒரு வரைபடம் தொடங்கப்பட்டதும், அடுத்த தொகுதி கிடைக்கும் Whenever அதைத் தொடங்கவும் வரிசைப்படுத்தவும் எங்களுக்கு இலவச நேரம் கிடைக்கும். நிலுவையில் உள்ள தொகுதியின் முடிவுகள் LazyTensor உடன் கண்காணிக்கப்படுகின்றன, இது முந்தைய தொகுதி செயலாக்கத்தை முடிக்கும் வரை Rust-ல் ஒரு ஒத்திசைவற்ற பணி தடுக்க அனுமதிக்கிறது. கர்னல் துவக்கங்களின் செலவால் நாம் பின்னுக்குத் தள்ளப்படவில்லை என்பதை உறுதி செய்வதன் மூலம் குறைந்த தாமதச் சேவைக்கு CUDA வரைபடங்கள் உதவுகின்றன மற்றும் அடுத்த தொகுதியில் வேலை செய்ய CPU-ஐ முன்கூட்டியே விடுவிப்பதால் அதிக த்ரூபுட் வழக்கில் மேம்பட்ட திட்டமிடலை எளிதாக்குகின்றன.
ஒவ்வொரு தனித்துவமான உள்ளமைவுக்கும் CUDA வரைபடங்கள் கைப்பற்றப்பட வேண்டும், அதாவது எம்ப்ட்டிங்குகளுக்கு வரிசை எண்ணிக்கை மற்றும் டோக்கன் எண்ணிக்கை கலவைக்கு ஒரு வரைபடம் தேவை. இந்த கட்டம் விரிவானது என்பதால், டோக்கன் எண்ணிக்கைகளை 64 அல்லது 256 இன் மடங்குகளாக இருக்கும் பக்கெட்டுகளுக்கு பேட் செய்கிறோம். இது இன்னும் ஆயிரக்கணக்கான வரைபடங்களை விளைவிக்கிறது, இது ஒரு வழக்கமான மாதிரிக்கு பிடிக்க பல நிமிடங்கள் ஆகலாம். கேப்சர் செலவு இரண்டு மூலங்களிலிருந்து வருகிறது: கர்னல்களை கம்பைல் செய்ய மற்றும் அவற்றுக்குத் தேவையான பல்வேறு கர்னல்களுக்கு பஃபர்களை அமைக்க இயக்கப்பட வேண்டிய ஒரு ஈகர் ஃபார்வர்டு பாஸ், அதைத் தொடர்ந்து Python குறியீட்டை மீண்டும் இயக்கும் கேப்சர் ரன்.
இயந்திரம் சேவை செய்யும் போது CUDA வரைபடங்களை சோம்பலாக (lazily) கைப்பற்றுவதன் மூலம் தொடக்கச் செலவுகளைக் குறைக்கிறோம். ஒவ்வொரு உள்ளமைவையும் நாங்கள் கண்காணித்து, இரண்டாவது ஹிட்டில் வரைபடம் கேப்சர் மற்றும் ரீப்ளேவைத் தூண்டுவதற்கு முன்பு அது ஒரு ஈகர் வார்ம்அப் ஓ செல்வதை உறுதிசெய்கிறோம். அதே வரைபட உள்ளமைவின் அனைத்து அடுத்தடுத்த செயலாக்கங்களும் CUDA வரைபட்டு ரீப்ளே மூலம் செல்கின்றன. லேசி வரைபட்டு கேப்சர் தொடக்கத்தின் போது p99 தாமதங்களில் தாக்கத்தை ஏற்படுத்துகிறது; இருப்பினும், பல நிமிட ஈகர் வேலையை பல மணிநேரங்களில் பரப்புவதில் இது மதிப்புமிக்கது. விரைவான தொடக்க நேரங்கள் எம்ப்ட்டிங் வரிசைப்படுத்தல்களை சிறப்பாக அளவிட மற்றும் நிர்வகிக்க அனுமதிக்கின்றன.
லேசி டென்சர்கள் (Lazy Tensors)
CUDA மூலம், GPU வேலை ஒத்திசைவற்றது (asynchronous). ஒரு கர்னலை ஒத்திசைவற்ற முறையில் தொடங்குவது அதை ஒரு ஸ்ட்ரீமில் வரிசைப்படுத்துவதால், விளைந்த வெக்டர்களைப் படிக்க ஹோஸ்ட் குறியீடு வெளிப்படையாக ஒத்திசைக்க வேண்டும். அதிக அளவு இணக்கத்தன்மையை (parallelism) எளிதாக்குவதற்கும், சாதனத்தில் முந்தையது முடிவடையும் வரை காத்திருக்கும்போது எதிர்கால தொகுதிகளைத் தொடங்க முடிய为了, மதிப்புகளைக் கண்காணிக்க நாங்கள் ஒரு LazyTensor சுருக்கத்தை நம்பியுள்ளோம்.
LazyTensor என்பது பக்க-பூட்டப்பட்ட நினைவகத்தில் (page-locked memory) உள்ள ஒரு ஹோஸ்ட் பஃபரையும், சாதனத்திலிருந்து தரவை நகலெடுக்கும் ஒரு நிகழ்வு (event) மூலம் cudaMemcpyAsync செயல்பாட்டையும் கண்காணிக்கிறது. அதே ஸ்ட்ரீமில் ஃபார்வர்டு பாஸ் தொடங்கிய பிறகு இது தொடங்கப்படுகிறது. காப்பி செயல்பாடு ஸ்ட்ரீமில் உள்ள முந்தைய அனைத்து கர்னல்களும் இயக்கப்படுவதற்காகக் காத்திருக்க வேண்டும் என்பதால், தொடர்புடைய நிகழ்வு ஃபார்வர்டு பாஸின் நிறைவு மற்றும் CPU-வில் முடிவு கிடைப்பதை இரண்டையும் கண்காணிக்கிறது.
GPU மற்றும் CPU வேலையை ஒன்றுடன் ஒன்று சேர்க்க (overlap) எங்கள் ROSE என்கோடர் இயந்திரத்தில் LazyTensor-களைப் பயன்படுத்துகிறோம். ஒவ்வொரு step() அழைப்பும் CUDA வரைபடத்தை இயக்குவதற்கும் அது முடியும் வரை காத்திருப்பதற்கும் பதிலாக, step() அதன் முடிவை ஒத்திசைவற்ற முறையில் கண்காணிக்க ஒரு LazyTensor-ஐ வழங்குகிறது. CUDA வரைபடங்களுடன் இணைந்து, குறைந்த தாமதங்கள் மற்றும் சிறந்த த்ரூபுட்டை அடைய இது எங்களுக்கு உதவுகிறது.
ROSE
LLM சர்விங் செய்வதற்காக நாங்கள் ursprünglich உருவாக்கிய எங்களின் ROSE இயந்திரத்தை, எம்ப்ட்டிங் மாதிரிகளின் செயலாக்கத்தையும் கையாள நாங்கள் மாற்றியமைத்துள்ளோம். எம்ப்ட்டிங் மாதிரிகளை ஆதரிக்க தேவையான முயற்சியைக் குறைக்க, ROSE LLM-கள் மற்றும் எம்ப்ட்டிங்குகளுக்கு இடையே குறியீட்டை தீவிரமாக மீண்டும் பயன்படுத்துகிறது. உதாரணமாக, pplx-embed சர்விங் மற்றும் Qwen3.5 LLM டீகோடிங் அனைத்தும் ஒரே கர்னல்கள் வழியாக செல்கின்றன. முன்மாதிரி, மதிப்பீடு மற்றும் தயாரிப்பு ஊகம் ஆகியவற்றிற்காக LLM- இலிருந்து முதலில் ஃபைன்-ட்யூன் செய்யப்பட்ட எம்ப்ட்டிங் மாதிரிக்கு எளிதில் சேவை செய்ய இந்தப் பகிர்வு எங்களுக்கு உதவுகிறது.
அடர்த்தியான லேயர்களுக்கு, டோக்கன் வெக்டர்கள் தனித்தனியாக செயலாக்கப்படுவதால் எம்ப்ட்டிங் மற்றும் LLM ஊகம் ஒரே மாதிரியாக இருக்கும். கவன ஈர்ப்பு லேயர்களில், LLM-களுக்குத் தேவையான பேக்ட் ப்ரீஃபில் மற்றும் டீகோட் அமைப்புகளுடன், ராக்டு உள்ளீடுகளுக்கான (ragged inputs) ஆதரவைச் சேர்ப்பதன் மூலம் வேறுபாடுகள் கையாளப்படுகின்றன. ஒரு எம்ப்ட்டிங் மாதிரிக்குச் சேவை செய்யும் போது, நாங்கள் KV கேச்-ஐ இன்ஸ்டன்டியேட் செய்ய மாட்டோம் மற்றும் பேடிங்கைத் தவிர்க்க ராக்டு வடிவத்தை ஆதரிக்கும் கவன ஈர்ப்பு கர்னல்களின் மாறுபாடுகளுக்கு அனுப்புகிறோம். துணைபுரியும் மாற்று மற்றும் அளவுத்திருத்த வழக்கங்களும் LLM-களுடன் பகிரப்படுகின்றன.
Ivy
எங்களின் ஊக HTTP ப்ராக்ஸி லேயரான Ivy-யும் செயல்திறனில் முக்கியப் பங்கு வகிக்கிறது. தயாரிப்பில் கோரிக்கை பேலோடுகள் மாறுபடுவதால், தனிப்பட்ட கோரிக்கைகளை தனிப்பட்ட ரெப்ளிகாக்களுக்கு ரூட் செய்வது சுமை ஏற்றத்தாழ்வை ஏற்படுத்தலாம். Ivy பெரிய தொகுதி கோரிக்கைகளை சன்க்களாகப் பிரித்து, ரெப்ளிகாக்களுக்கு இடையில் சுமை சமநிலைப்படுத்துகிறது (load-balances), பயன்பாட்டை மேம்படுத்துகிறது மற்றும் தாமதத்தை மென்மையாக்குகிறது. Ivy-யில் முழுமையாக வெளியிடப்பட்ட in-house unigram tokenization பற்றிய எங்கள் சமீபத்திய பணி, ஆஃப்-The-शेல்ஃப் டோக்கனைசர்களை விட தாமதங்களை கணிசமாக மேம்படுத்துகிறது.
...ஆனால் கர்னல்கள் இன்னும் முக்கியம்
ROSE பல்வேறு கவன ஈர்ப்பு பேக்கெண்டுகளை ஆதரிக்கிறது. வெவ்வேறு கர்னல்கள் குறிப்பிட்ட சிக்கல் அளவிற்குப் பொருத்தமானதாக இருக்கலாம். காலப்போக்கில், ராக்டு கவன ஈர்ப்பை செயல்படுத்த FlashInfer 2, FlashInfer 3 மற்றும் FlashAttention 4 கர்னல்களை ஒருங்கிணைத்தோம்.
பொதுவாக, FlashAttention 4 வேகமானது என்பதைக் காண்கிறோம். இருப்பினும், மிகவும் நீண்ட வரிசை நீளங்களில் Qwen-அடிப்படையிலான மாதிரிகளில் FlashInfer 3 இதை விட சிறப்பாகச் செயல்படுகிறது. செயல்திறன் மற்றும் ட்யூனிங் ஆகியவை கவன ஈர்ப்பு ஹெட்ஸின் (attention heads) எண்ணிக்கை மற்றும் பரிமாணத்துடன் மாறுபடும் என்பதால், நாங்கள் பல உள்ளமைவுகளுக்கான ஆதரவைப் பேணுகிறோம் மற்றும் சர்வ் செய்யும் போது ஒவ்வொரு வழக்கின் அடிப்படையில் முடிவெடுக்கிறோம்.
பெஞ்ச்மார்க்குகள்
மதிப்பீட்டுத் தரவுத்தொகுப்புகளிலிருந்து பெறப்பட்ட உண்மையான மாதிரி எடைகள் மற்றும் உள்ளீடுகளில் 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 இன்டர்ஆப்பரபிலிட்டியை மேலும் மேம்படுத்த முடியும்.