GPUలపై వేగవంతమైన ఎంబెడ్డింగ్ లు

వేగవంతమైన మరియు ఖచ్చితమైన సెర్చ్ అనేది సెర్చ్ మరియు Computer నుండి మా API ప్లాట్ ఫామ్ వరకు Perplexity మొత్తానికి చాలా ముఖ్యం. తెరవెనుక, ఎంబెడ్డింగ్ మరియు ర్యాంకింగ్ మోడళ్ల ద్వారా హెవీ లిఫ్టింగ్ చేయబడుతుంది, ఇవి ఇచ్చిన క్వెరీ కోసం అత్యంత సంబంధిత ఫలితాలను గుర్తించడానికి మా సిస్టమ్ లకు సహాయపడతాయి. pplx-embed వంటి మా নিজস্ব మోడళ్లను శిక్షణ ఇవ్వడం మరియు సర్వ్ చేయడం ద్వారా మేము అత్యాధునిక నాణ్యతను మరియు లేటెన్సీని సాధిస్తాము.

ఈ వ్యాసం ఈ ప్రత్యేక మోడల్ వర్గానికి Perplexity సర్వింగ్ మౌలిక వసతులపై లోతైన దృశ్యాన్ని అందిస్తుంది. AI-స్థానిక శోధన కోసం inference అవసరాలను సమర్థవంతంగా తీర్చే మా పద్ధతులను మేము చర్చిస్తాము, తద్వారా మా ఎక్సాబైట్-స్థాయి శోధన సూచికను శక్తివంతం చేస్తూనే మోడళ్లను త్వరగా ప్రోటోటైప్ చేయడం మరియు మూల్యాంకనం చేయడం సాధ్యమవుతుంది. ఈ పద్ధతులు సమిష్టిగా శోధన నాణ్యత మరియు సామర్థ్యానికి సంబంధించిన Pareto సరిహద్దును విస్తరించి, అత్యల్ప ఖర్చు మరియు ఆలస్యంతో సాధ్యమైనంత ఉత్తమ ఫలితాలతో ఏజెంట్‌లు మరియు వినియోగదారులకు సేవలు అందించేందుకు మాకు వీలు కల్పిస్తాయి.

సెర్చ్ కోసం ఎంబెడ్డింగ్ లు

సాధారణ సెర్చ్ సెటప్ లో, ఇండెక్స్ చేయబడిన డాక్యుమెంట్లు ఎంబెడ్డింగ్ మోడల్ ను ఉపయోగించి అధిక-డైమెన్షనల్ వెక్టర్ స్పేస్ లోకి మ్యాప్ చేయబడతాయి మరియు వెక్టర్ డేటాబేస్ లో నిల్వ చేయబడతాయి. అదే మోడల్ ను ఉపయోగించి క్వెరీని ఎంబెండ్ చేయడం ద్వారా, క్వెరీ యొక్క వెక్టర్ కు అత్యంత సమీపంలో ఉన్న వెక్టర్ లను కనుగొనడం ద్వారా సమానమైన డాక్యుమెంట్లను గుర్తించవచ్చు. ఇది ఇన్ ఫరెన్స్ ఇంజిన్ సర్వ్ చేయడానికి రెండు వేర్వేరు ట్రాఫిక్ నమూనాలకు దారితీస్తుంది:

• బ్యాచ్ ఎంబెడ్డింగ్: డేటాబేస్ ను నిర్మించేటప్పుడు, విస్తరించేటప్పుడు లేదా రీ-ఇండెక్స్ చేసేటప్పుడు, ఖర్చును తగ్గించడానికి త్రూపుట్ ను గరిష్టం చేస్తూ బల్క్ డాక్యుమెంట్లు వెక్టర్ స్పేస్ లోకి ఎంబెండ్ చేయబడాలి.

వెక్టార్ సెర్చ్ తర్వాత, పెద్ద బ్యాచ్ ల డాక్యుమెంట్లు స్కోర్ చేయబడాలి, త్రూపుట్ మరియు లేటెన్సీ మధ్య సమతుల్యతను సాధించాలి.

• ఆన్ లైన్ ఎంబెడ్డింగ్: డేటాబేస్ ను క్వెరీ చేసేటప్పుడు, లుకప్ ల కోసం ఒక చిన్న క్వెరీ ఎంబెండ్ చేయబడాలి, లేటెన్సీని కనిష్ట స్థాయికి తగ్గిస్తుంది.

సాధ్యమైనంత ఎక్కువ సాధారణ భాగాలను వివిధ వినియోగ సందర్భాల్లో వినియోగించుకోవడానికి మేము మా inference మౌలిక వసతులను నిర్మించాము. సాధారణంగా embeddings సృష్టించడానికి మేము చిన్న Transformer మోడళ్లను ఉపయోగిస్తాము కాబట్టి, అమలులో ఎక్కువ భాగాన్ని మా LLM inference కోడ్‌తో పంచుకుంటాము: బ్యాచ్ embeddings గణన-పరిమిత prefill‌కు సమానంగా ఉంటాయి, కాగా ఆన్‌లైన్ embeddings, ఇవి తరచుగా కొద్దిమాత్రం tokens‌పై నడుస్తాయి, మెమరీ-పరిమిత decode‌కు గణనాత్మకంగా సమానంగా ఉంటాయి. అందువల్ల embedding మోడళ్లను సర్వ్ చేయడానికి మేము మా ఆప్టిమైజ్ చేసిన prefill మరియు decode kernelsను పునర్వినియోగిస్తాము. ఫలితంగా, తక్కువ అదనపు ఇంజినీరింగ్ శ్రమతోనే భారీ batch inference throughput‌ను సాధించగలుగుతాము, అదే సమయంలో ఆన్‌లైన్ embeddings workloads‌కు తక్కువ latency‌ను నిలుపుకుంటాము.

Tulips, Roses, మరియు కొన్ని Ivy

మేము అంతర్గతంగా మరియు మా API ప్లాట్ ఫామ్ ద్వారా బాహ్యంగా ప్రామాణీకరించబడిన APIల ద్వారా ఇన్ ఫరెన్స్ ను బహిర్గతం చేస్తాము. తెరవెనుక, ఎంబెడ్డింగ్ అభ్యర్థనను ప్రాసెస్ చేయడంలో అనేక సేవలు ఉంటాయి:

• Ivy అనేది Perplexity సేవలు కాల్ చేసే Rust HTTP గేట్ వే.

ఇది JSON పార్సింగ్, టోకనైజేషన్, ఇన్ పుట్ టెంప్లేటింగ్ మరియు బ్యాచ్ స్ప్లిటింగ్ వంటి అభ్యర్థనల కోసం CPU-వైపు పనిని హ్యాండిల్ చేస్తుంది, అభ్యర్థనలను డౌన్ స్ట్రీమ్ సర్వర్ ల కోసం కస్టమ్ gRPC ప్రోటోకాల్ కి అనువదిస్తుంది. ఈ విభజన బరువున్న ఇన్ ఫరెన్స్ ఇన్ స్టాన్స్ లను తాకకుండా టోకనైజేషన్ మరియు ఇన్ పుట్ ఫార్మాటింగ్ చుట్టూ నిర్దిష్ట పారామీటర్ లను కాన్ఫిగర్ చేయడానికి మాకు అనుమతిస్తుంది.

• Tulip అనేది ఇన్ ఫరెన్స్ సర్వర్ ఇంటర్ ఫేస్.

ఇది Rust, tokio, మరియు tonicలతో అమలు చేయబడిన gRPC సర్వర్. ట్యూలిప్ gRPC ఇన్‌ఫరెన్స్ అభ్యర్థనలను స్వీకరిస్తుంది, షెడ్యూలింగ్ మరియు బ్యాచింగ్‌లను నిర్వహిస్తుంది. ఇది తరువాత బ్యాచ్‌లను ROSE ఇంజిన్‌కు పంపుతుంది, పూర్తయిన ప్రతిస్పందనలను క్లైంట్‌లకు తిరిగి ఇస్తుంది.

• ROSE (రన్‌టైమ్-ఆప్టిమైజ్డ్ సర్వింగ్ ఇంజిన్) మోడల్ ఇన్‌ఫరెన్స్‌ను అమలు చేస్తుంది.

ఇది ప్రాథమికంగా Pythonలో నిర్వచించబడింది, విస్తృత శ్రేణి మోడళ్ల కోసం కెర్నల్స్, లేయర్లు మరియు నిర్వచనాలను అందిస్తుంది. ROSE మోడళ్ల ద్వారా ఫార్వర్డ్ పాస్ లను అమలు చేస్తుంది, ఎంబెడ్డింగ్ ల కోసం ప్రత్యేకించబడిన CUDA గ్రాఫ్ నిర్వహణను కూడా అందిస్తుంది. ఇది step() ఫంక్షన్ ద్వారా Tulipకి అనుసంధానించబడింది, ఇది బ్యాచ్ ను తీసుకుంటుంది మరియు యాక్సిలరేటర్ పై అది చేసే కంప్యూటేషన్ కు రిఫరెన్స్ ను అందిస్తుంది.

విస్తరించు

కెర్నల్ మించి అటెన్షన్ చెల్లించడం

ట్రాన్స్ ఫార్మర్-ఆధారిత మోడళ్లు మరియు అంతర్లీనంగా ఉన్న Hopper/Blackwell ఆర్కిటెక్చర్లు రెండూ పరిణతి చెందిన సాంకేతికతలు, కాబట్టి GPU వైపు ఇన్ ఫరెన్స్ ఎంబెడ్డింగ్ అనేది వివిధ ఇన్ ఫరెన్స్ ఇంజిన్ లలో చాలా వరకు సరైన అమలుకు చేరుకుంది. అయినప్పటికీ, మోడళ్లను ఎండ్-టు-ఎండ్ కాయింట్ కు అందించే రన్ టైమ్ లు మరియు హార్నెస్ లలో మెరుగుదలల కోసం అదనపు అవకాశాలను మేము కనుగొన్నాము. ప్రత్యేకించి, CUDA గ్రాఫ్ లను జాగ్రత్తగా నిర్వహించడం ద్వారా మరియు నేటివ్ Rust ఇంజిన్ లో GPU-వైపు ఫలితాన్ని అసਿੰక్రోనస్ గా ట్రాక్ చేయడానికి ఒక LazyTensor అబ్స్ట్రాక్షన్ ను నిర్మించడం ద్వారా మేము లేటెన్సీలను మెరుగుపరచగలమని మేము కనుగొన్నాము. మేము ఈ ఫీచర్ లను Tulipలో అమలు చేసాము, తద్వారా ఇది ROSE యొక్క మోడల్ ఇంప్లిమెంటేషన్ లతో సమర్థవంతంగా ఇంటర్ ఫేస్ చేయగలదు.

Tulip

మా మోడల్ సర్వింగ్ పై సాధ్యమైనంత తేలికైన ఇంటర్ ఫేస్ గా ఉండటానికి మేము Tulipని రూపొందించాము. ఇది టోకియో అసਿੰక్రోనస్ టాస్క్ లలో ఇన్‌కమింగ్ అభ్యర్థనలను హ్యాండిల్ చేస్తుంది, ఇది ట్రాక్ చేసే అభ్యర్థనల పూల్ ను నిర్వహిస్తుంది మరియు యాక్సిలరేటర్ కి పంపిణీ చేయడానికి బ్యాచ్ లను షెడ్యూల్ చేస్తుంది. Tulipలోని షెడ్యూలింగ్ మెకానిజం చాలా సులభం: Tulip పనిని పంపిణీ చేస్తున్నప్పుడు లేదా ఫలితాల కోసం వేచి ఉన్నప్పుడు అభ్యర్థనలు పేరుకుపోతాయి. పేరుకుపోయిన అభ్యర్థనల నుండి, మోడల్ ద్వారా రన్ చేయడానికి మొదటిగా వచ్చిన వారికి మొదటి ప్రాధాన్యత (first-come, first-served) ప్రాతిపదికన సీక్వెన్స్ లు ఎంపిక చేయబడతాయి.

సరళమైన scheduling యంత్రాంగం model performance‌పై ఒక పరిశీలన ద్వారా ప్రేరేపించబడింది. చిన్న embedding మోడళ్ల కోసం, మేము సర్వ్ చేసే sequence lengths వద్ద, dense layers యొక్క రేఖీయ ఖర్చు attention యొక్క చతురస్ర ఖర్చును మించి ప్రధానంగా ఉంటుంది అని గమనించాము. అందువల్ల, latency ప్రధానంగా tokens సంఖ్యకు అనుపాతంగా ఉంటుంది, sequences సంఖ్యకు కాదు. ఫలితంగా, ఒక batch GPUని పూర్తిగా వినియోగించడానికి సరిపడంత పెద్దదైన తర్వాత, అంటే ఒక బిలియన్ parameters కంటే తక్కువ ఉన్న modelలో సుమారు 512 tokens వద్ద, దానిలో మరిన్ని sequences‌ను నింపడం సామర్థ్యాన్ని మెరుగుపరచదు.

మోడల్ తో సమర్థవంతంగా ఇంటర్ ఫేస్ చేయడానికి, GPU మరియు CPU పనిని అతివ్యాప్తి చేయడానికి మరియు అందుబాటులో ఉన్న వనరులను పూర్తిగా ఉపయోగించుకోవడానికి Tulip CUDA గ్రాఫ్ లు మరియు లేజీ ఫలితాల ట్రాకింగ్ పై ఆధారపడుతుంది.

CUDA గ్రాఫ్ మేనేజ్ మెంట్

మోడల్ యొక్క ఫార్వర్డ్ పాస్ ను రన్ చేయడంలో CPU-వైపు మరియు GPU-వైపు పని రెండూ ఉంటాయి. తగిన పారామీటర్ లతో బ్యాచ్ లను షెడ్యూల్ చేయడానికి మరియు కెర్నల్స్ ను లాంచ్ చేయడానికి CPU బాధ్యత వహిస్తుంది, అయితే GPU సంబంధిత మ్యాట్రిక్స్ గుణకారం, అటెన్షన్, నార్మ్ లేదా యాక్టివేషన్ కెర్నల్స్ ను అమలు చేస్తుంది. శిక్షణ మరియు రీఇండెక్సింగ్ వంటి అధిక-త్రూపుట్ వర్క్ లోడ్ ల కోసం, CPU-వైపు ఓవర్ హెడ్ లు చాలా తక్కువగా ఉంటాయి ఎందుకంటే బ్యాచ్ పరిమాణాలు మరియు GPU-వైపు లేటెన్సీ రెండూ పెద్దవిగా ఉంటాయి. అయినప్పటికీ, చిన్న బ్యాచ్ పరిమాణాలపై, CPU-వైపు పని GPU-వైపు పనిని మించిపోతుంది.

విస్తరించు

ఓవర్ హెడ్ లను తగ్గించడానికి, స్వతంత్ర కెర్నల్స్ ను లాంచ్ చేసే బదులు, CUDA డ్రైవర్ కి ఒకే కాల్ తో ఫార్వర్డ్ పాస్ యొక్క అన్ని కెర్నల్స్ ను లాంచ్ చేయడానికి అవసరమైన మెటాడేటాను క్యాప్చర్ చేయడానికి CUDA గ్రాఫ్ ను నిర్మించవచ్చు. ఇది CUDA గ్రాఫ్ లు క్యాప్చర్ చేయగల కాన్ఫిగరేషన్ ల కోసం ఖరీదైన Python మరియు PyTorch కోడ్ ను మళ్లీ రన్ చేయవలసిన అవసరాన్ని తొలగిస్తుంది.

ప్రతి మోడల్ అంతటా, మేము ఒక ఇన్ఫ్లెక్షన్ పాయింట్ ను ట్రాక్ చేస్తాము, CPU-సైడ్ కెర్నల్ లాంచ్ కంటే GPU ఎగ్జిక్యూషన్ ఖరీదైనదిగా ఉండే కనీస టోకెన్ ల సంఖ్యను నిర్ణయిస్తాము. ఎంబెడ్డింగ్ మోడళ్లు చిన్నవి కాబట్టి, ఈ ఇన్ఫ్లెక్షన్ పాయింట్ వేల టోకెన్లు మరియు పదుల సీక్వెన్స్ ల బ్యాచ్ ల వద్ద వస్తుందని మేము గమనించాము. కొన్ని అటెన్షన్ ఇంప్లిమెంటేషన్ లు కెర్నల్ లాంచ్ లను కాన్ఫిగర్ చేయడానికి డైనమిక్ హోస్ట్-సైడ్ ఇన్ పుట్ లపై ఆధారపడతాయి, ఇది పూర్తి-మోడల్ ప్రీఫిల్/డెన్స్ CUDA గ్రాఫ్ లను నిరోధిస్తుంది. మా ఇన్ ఫరెన్స్ ఇంజిన్ లో వాటిని ప్రారంభించడానికి మేము సంబంధిత కెర్నల్స్ కు అప్ స్ట్రీమ్ మార్పులను చేసాము.

ఓవర్‌హెడ్‌లను పరిష్కరించడానికి, మేము అన్ని embedding మోడళ్ల కోసం పూర్తి-మోడల్ CUDA graphs‌ను నిర్మించి, CPU పనిని GPU పనితో సమాంతరంగా నడుపుతాము. CUDA graphs CPU-వైపు ఓవర్‌హెడ్‌లను తగ్గిస్తాయి కాబట్టి, ఒక graph ప్రారంభమైన తర్వాత, తదుపరి batch అందుబాటులో వచ్చిన వెంటనే దాన్ని ప్రారంభించి queue చేయడానికి మాకు ఖాళీ సమయం లభిస్తుంది. పెండింగ్‌లో ఉన్న batch ఫలితాలను LazyTensorతో ట్రాక్ చేస్తాము, ఇది Rustలోని ఒక async taskను ముందు batch execution పూర్తయ్యే వరకు block కావడానికి అనుమతిస్తుంది. CUDA graphs kernel launches ఖర్చు వల్ల మేము వెనుకపడకుండా చూసి low-latency serving‌కు సహాయపడతాయి, అలాగే తదుపరి batchపై పని చేయడానికి CPUను త్వరగా విడుదల చేయడం ద్వారా high-throughput సందర్భంలో మెరుగైన scheduling‌ను సులభతరం చేస్తాయి.

విస్తరించు

ప్రతి విభిన్న కాన్ఫిగరేషన్ కోసం CUDA గ్రాఫ్ లు క్యాప్చర్ చేయబడాలి, ఎంబెడ్డింగ్ ల కోసం అంటే ప్రతి సీక్వెన్స్ గణన మరియు టోకెన్ గణన కలయికకు ఒక గ్రాఫ్. ఈ గ్రిడ్ విస్తారమైనది కాబట్టి, మేము టోకెన్ గణనలను 64 లేదా 256 యొక్క గుణిజాలుగా ఉండే బకెట్ లకు ప్యాడ్ చేస్తాము. ఇది ఇప్పటికీ వేలకొద్దీ గ్రాఫ్ లకు దారితీస్తుంది, ఇది సాధారణ మోడల్ కోసం క్యాప్చర్ చేయడానికి అనేక నిమిషాలు పట్టవచ్చు. క్యాప్చర్ యొక్క ఖర్చు రెండు మూలాల నుండి వస్తుంది: కెర్నల్స్ ను కంపైల్ చేయడానికి మరియు వాటిని అవసరమైన వివిధ కెర్నల్స్ కోసం బఫర్ లను సెటప్ చేయడానికి అమలు చేయవలసిన ఈగర్ ఫార్వర్డ్ పాస్, ఆ తర్వాత Python కోడ్ ను మళ్లీ అమలు చేసే క్యాప్చర్ రన్.

ఇంజిన్ సర్వ్ చేస్తున్నప్పుడు CUDA గ్రాఫ్ లను లేజీగా క్యాప్చర్ చేయడం ద్వారా మేము ప్రారంభ ఖర్చులను తగ్గిస్తాము. మేము ప్రతి కాన్ఫిగరేషన్ ను ట్రాక్ చేస్తాము మరియు రెండవ హిట్‌లో గ్రాఫ్ క్యాప్చర్ మరియు రీప్లేను ట్రిగ్గర్ చేయడానికి ముందు అది ఈగర్ వార్మప్ రన్ గుండా వెళ్లేలా చూస్తాము. అదే గ్రాఫ్ కాన్ఫిగరేషన్ యొక్క తదుపరి అన్ని అమలులు CUDA గ్రాఫ్ రీప్లే ద్వారా వెళ్తాయి. లేజీ గ్రాఫ్ క్యాప్చర్ ప్రారంభ సమయంలో p99 లేటెన్సీలపై ప్రభావం చూపుతుంది; అయినప్పటికీ, అనేక గంటలలో బహుళ నిమిషాల ఈగర్ పనిని విస్తరించడంలో ఇది విలువైనది. శీఘ్ర ప్రారంభ సమయాలు ఎంబెడ్డింగ్ మోహరింపులను మెరుగ్గా స్కేల్ చేయడానికి మరియు నిర్వహించడానికి మాకు అనుమతిస్తాయి.

లేజీ టెన్సార్లు

CUDA ద్వారా GPU పని asynchronous‌గా ఉంటుంది. ఒక kernel‌ను asynchronously ప్రారంభించడం దాన్ని ఒక streamపై enqueue చేస్తుంది కాబట్టి, ఫలిత vectors‌ను చదవడానికి host code స్పష్టంగా synchronize కావాలి. device‌పై మునుపటి batch పూర్తయ్యే వరకు వేచిచూస్తూ future batches‌ను ప్రారంభించగల అధిక స్థాయి parallelism‌ను సులభతరం చేయడానికి, values‌ను ట్రాక్ చేయడానికి మేము LazyTensor abstractionపై ఆధారపడతాము.

LazyTensor పేజ్-లాక్డ్ మెమరీలోని హోస్ట్ బఫర్ ను మరియు డివైజ్ నుండి డేటాను కాపీ చేసే ఈవెంట్ ద్వారా cudaMemcpyAsync ఆపరేషన్ ను ట్రాక్ చేస్తుంది. అదే స్ట్రీమ్ లో ఫార్వర్డ్ పాస్ లాంచ్ అయిన తర్వాత ఇది ప్రారంభించబడుతుంది. కాపీ ఆపరేషన్ స్ట్రీమ్ లోని మునుపటి అన్ని కెర్నల్స్ ఎగ్జిక్యూట్ అయ్యే వరకు వేచి ఉండాలి కాబట్టి, సంబంధిత ఈవెంట్ ఫార్వర్డ్ పాస్ పూర్తవడాన్ని మరియు CPUలో ఫలితం అందుబాటులో ఉండటాన్ని రెండింటినీ ట్రాక్ చేస్తుంది.

విస్తరించు

GPU మరియు CPU పనిని అతివ్యాప్తి చేయడానికి మా ROSE ఎన్ కోడర్ ఇంజిన్ లో మేము LazyTensorలను సద్వినియోగం చేసుకుంటాము. ప్రతి step() కాల్ CUDA గ్రాఫ్ ను రన్ చేసి అది ముగిసే వరకు వేచి ఉండే బదులు, step() దాని ఫలితాన్ని అసਿੰక్రోనస్ గా ట్రాక్ చేయడానికి ఒక LazyTensorను అందిస్తుంది. CUDA గ్రాఫ్ లతో జతచేయబడి, తక్కువ లేటెన్సీలను మరియు మెరుగైన త్రూపుట్ ను సాధించడానికి ఇది మాకు సహాయపడుతుంది.

విస్తరించు

ROSE

మేము మొదట LLM సర్వింగ్ కోసం నిర్మించిన మా ROSE ఇంజిన్‌ను, embedding మోడళ్ల execution‌ను కూడా నిర్వహించేలా అనుకూలీకరించాము. embedding మోడళ్లకు మద్దతు ఇవ్వడానికి కావలసిన శ్రమను తగ్గించడానికి, ROSE LLMలు మరియు embeddings మధ్య కోడ్‌ను దూకుడుగా పునర్వినియోగిస్తుంది. ఉదాహరణకు, pplx-embed serving మరియు Qwen3.5 LLM decoding అన్నీ ఒకే kernels ద్వారా సాగుతాయి. ఈ పంచుకోవడం వలన, prototyping, evaluation, మరియు production inference కోసం మొదట LLM నుండి fine-tune చేసిన embedding మోడల్‌ను సులభంగా సర్వ్ చేయగలుగుతాము.

Dense layers కోసం, embedding మరియు LLM inference ఒకేలా ఉంటాయి, ఎందుకంటే token vectors‌ను స్వతంత్రంగా ప్రాసెస్ చేస్తారు. Attention layersలో, LLMలకు అవసరమైన paged prefill మరియు decode సెటప్‌లతో పాటు ragged inputs‌కు మద్దతు జోడించడం ద్వారా తేడాలను నిర్వహిస్తాము. embedding మోడల్‌ను సర్వ్ చేస్తూ, padding‌ను నివారించడానికి ragged format‌కు మద్దతు ఇచ్చే attention kernels వేరియంట్లకు dispatch చేస్తాము, అలాగే KV cache‌ను instantiate చేయము. supporting conversion మరియు calibration routines కూడా LLMలతో పంచుకోబడతాయి.

Ivy

మా inference HTTP proxy లేయర్ అయిన Ivy కూడా పనితీరులో ముఖ్య పాత్ర పోషిస్తుంది. ఉత్పత్తి వాతావరణంలో request payloads మారుతూ ఉండటం వల్ల, individual requests‌ను individual replicas‌కు పంపించడం load imbalance‌కు దారితీయవచ్చు. Ivy పెద్ద-batch requests‌ను chunks‌గా విభజించి replicas మధ్య load-balance చేస్తుంది, దీనివల్ల utilization మెరుగుపడి latency మరింత స్మూత్ అవుతుంది. పూర్తిగా Ivyలో అమలు చేసిన ఇన్-హౌస్ unigram tokenizationపై మా ఇటీవలి పని, రెడీమేడ్ tokenizers‌తో పోలిస్తే latencyలను గణనీయంగా మెరుగుపరుస్తుంది.

...అయినప్పటికీ కెర్నల్స్ ఇప్పటికీ ముఖ్యం

ROSE వివిధ రకాల అటెన్షన్ బ్యాక్ ఎండ్ లకు మద్దతు ఇస్తుంది. వివిధ కెర్నల్స్ నిర్దిష్ట సమస్య పరిమాణాలకు సరిపోతాయి. కాలక్రమేణా, రాగెడ్ అటెన్షన్ ను అమలు చేయడానికి మేము FlashInfer 2, FlashInfer 3 మరియు FlashAttention 4 కెర్నల్స్ ను ఏకీకృతం చేసాము.

విస్తరించు

సాధారణంగా, FlashAttention 4 వేగంగా ఉంటుందని మేము గమనించాము. అయితే, చాలా పొడవైన సీక్వెన్స్ పొడవుల వద్ద Qwen-ఆధారిత మోడళ్లపై FlashInfer 3 మెరుగైన పనితీరును కనబరుస్తుంది. అటెన్షన్ హెడ్ ల సంఖ్య మరియు డైమెన్షన్ ను బట్టి పనితీరు మరియు ట్యూనింగ్ మారుతూ ఉంటాయి కాబట్టి, మేము బహుళ కాన్ఫిగరేషన్ ల మద్దతును నిర్వహిస్తాము మరియు సర్వ్ చేసేటప్పుడు ప్రతి సందర్భాన్ని బట్టి నిర్ణయం తీసుకుంటాము.

బ్లేంచ్ మార్కులు

మేము vLLM v0.22.0తో బెంచ్‌మార్క్ చేస్తాము, BF16 precision‌లో వాస్తవ model weights మరియు evaluation datasets నుంచి పొందిన inputs‌పై inference నడుపుతాము. అన్ని timing రన్లకు ముందు warmup రన్లు నిర్వహించబడాయి, వీటి ద్వారా cosine similarityలోని deviation 0.1% లోపే ఉందని ధృవీకరించబడింది.

తక్కువ-లేటెన్సీ ఎంబెడ్డింగ్ లు (p50 / p90 / p99 / గరిష్ట ms)

ముందస్తుగా టోకెన్ చేయబడిన రిక్వెస్ట్ బ్యాచ్ పరిమాణం 1, పూర్తిగా సీక్వెన్షియల్ అభ్యర్థనలు, 128, 512 మరియు 4096 టోకెన్ ల సీక్వెన్స్ పొడవుల కోసం మేము రన్ టైమ్ లను నివేదిస్తాము.

విస్తరించు

తక్కువ-లేటెన్సీ స్కోరింగ్ (p50 / p90 / p99 / గరిష్ట ms)

ముందస్తుగా టోకెన్ చేయబడిన రిక్వెస్ట్ బ్యాచ్ పరిమాణాలు 5, 25 మరియు 50, 512 టోకెన్ ల సీక్వెన్స్ పొడవు.

విస్తరించు

అధిక-త్రూపుట్ ఎంబెడ్డింగ్ లు (emb/s)

రిక్వెస్ట్ బ్యాచ్ పరిమాణం 100, అభ్యర్థనలను సమర్పించే నాలుగు సమకాలీన ప్రాసెస్ లు, 512, 1024 మరియు 4096 టోకెన్ ల సీక్వెన్స్ పొడవులు.

విస్తరించు

అధిక concurrency ఉన్న embeddings (p50 / p90 / p99 / max ms)

సీక్వెన్స్ పొడవు 512, బ్యాచ్ పరిమాణం 1, కానీ మేము 1, 2, 4, 8 మరియు 16 సమకాలీన అభ్యర్థనలను పంపుతాము. ఈ బ్లేంచ్ మార్క్ Ivy మరియు Tulip మధ్య నెట్ వర్కింగ్ ఓవర్ హెడ్ తో పాటు Ivy ద్వారా టోకనైజేషన్ ఖర్చులను కూడా కలిగి ఉంటుంది.

విస్తరించు

ముగింపు మరియు భవిష్యత్తు పని

Ivy, Tulip మరియు ROSEలతో కూడిన సర్వింగ్ ఇన్ ఫ్రాస్ట్రక్చర్ తక్కువ లేటెన్సీ మరియు మెరుగైన త్రూపుట్ తో Perplexity కోసం ఎంబెడ్డింగ్ లను అందించడానికి మాకు అనుమతిస్తుంది, ఫలితంగా ఆఫ్-ది-షెల్ఫ్ సొల్యూషన్ లతో పోలిస్తే తగ్గిన ఖర్చుతో మరింత ఖచ్చితమైన సెర్చ్ లభిస్తుంది.

నిర్దిష్ట మోడళ్లపై దృష్టి సారించి, మొత్తం స్టాక్‌కు బాధ్యత వహించడం ద్వారా, అధికంగా పునర్వినియోగించుకోగల మరియు పనితీరు గల Rust ప్రిమిటివ్‌లను మరింత సాధారణ Python మోడలింగ్ కోడ్‌తో కలిపి, పనితీరు మరియు సౌలభ్యం మధ్య సమర్థవంతమైన సమతుల్యతను సాధించడానికి అవసరమైన స్వేచ్ఛను మేము పొందుతాము. vLLM, SGLang, మరియు TokenSpeed వంటి అనేక ఓపెన్-సోర్స్ ఇన్ఫరెన్స్ ఇంజిన్లు తమ స్టాక్‌లో Rust మరియు C++ వంటి భాషలను సమగ్రపరుస్తున్నాయి. గత రెండు సంవత్సరాల్లో మేము Rust‌లో పెట్టుబడి పెట్టాము, దాంతో పనితీరు మరియు నిర్వహణ సామర్థ్యం రెండింటిలోనూ గొప్ప ఫలితాలను పొందాము. మా LLM సర్వింగ్ స్టాక్‌తో embedding అమలులో ఎక్కువ భాగాన్ని పంచుకోవడం ద్వారా, embedding మోడళ్ల నిర్వహణపై గణనీయమైన ఇంజినీరింగ్ శ్రమ ఖర్చు చేయకుండానే, throughput‌లో కూడా లాభాలను సాధిస్తున్నాము.

మోడళ్లు అభివృద్ధి చెందుతున్న కొద్దీ, CPU-బౌండ్ మరియు GPU-బౌండ్ లేటెన్సీలను తగ్గించడానికి మా స్టాక్ లోని ప్రతి లేయర్ ను మేము మెరుగుపరుస్తూనే ఉంటాము. Ivy మరియు Tulip లోని మా కస్టమ్ gRPC-ఆధారిత ప్రోటోకాల్ లు నెట్ వర్క్ లేటెన్సీలను తగ్గించడానికి కమ్యూనికేషన్ ను సర్దుబాటు చేయడానికి మాకు అనుమతిస్తాయి, అయితే ROSE కంప్యూటేషనల్ త్రూపుట్ ను మెరుగుపరచడానికి ఒక పునాదిని అందిస్తుంది. అదనంగా, ఎకోసిస్టమ్ అంతటా ఫ్రీ-థ్రెడెడ్ Python కోసం మద్దతు పెరుగుతున్న కొద్దీ, ఓవర్ హెడ్ లను తగ్గించడానికి మేము Python-Rust పరస్పర చర్యను మరింత మెరుగుపరచగలుగుతాము.

ప్రస్తావనలు

• AI-ಮೊದಲ సెర్చ్ APIని ఆర్కిటెక్టింగ్ మరియు మూల్యాంకనం చేయడం
• pplx-embed: వెబ్-స్థాయి రిట్రీవల్ కోసం అత్యాధునిక ఎంబెడ్డింగ్ మోడళ్లు
• యూనిగ్రామ్ టోకనైజర్ CPU పనితీరును మెరుగుపరచడం
• vLLM
• FlashInfer
• FlashAttention

ఉదాహరణ

@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}
}