ఒకే ఫైల్ మార్పుతో 31.8x వేగవంతం

నేను ఒక RAG ingestion pipelineని పరీక్షించాను మరియు ఒక అడ్డంకిని (bottleneck) ఎదుర్కొన్నాను: ఒక డాక్యుమెంట్‌ను ప్రాసెస్ చేయడానికి 50 సెకన్లు పట్టింది.

నా CPU ఖాళీగా ఉంది. యాప్ ఎటువంటి గణిత లేదా లాజిక్ పనులను చేయడం లేదు; తదుపరి రిక్వెస్ట్‌ను ప్రారంభించే ముందు, ఒక HTTP రిక్వెస్ట్ పూర్తయ్యే వరకు అది కేవలం వేచి చూస్తోంది.

నేను embedding moduleను asynchronously రన్ అయ్యేలా తిరిగి రాశాను. ఎటువంటి ఇన్‌ఫ్రాస్ట్రక్చర్ మార్పులు చేయకుండానే, రన్‌టైమ్ 49.61 సెకన్ల నుండి 1.56 సెకన్లకు తగ్గింది.

టెస్ట్ వివరాలు

  • Model: Amazon Titan Text Embeddings V2 (AWS Bedrock)
  • Dataset: 33 text chunks
  • Region: us-east-1

ఫలితాలు

  • Sequential: 49.61 s
  • Concurrent: 1.56 s
  • Speedup: 31.8×

ఇది ఎందుకు పనిచేస్తుంది Sequential కోడ్ ఒక రిక్వెస్ట్‌ను పంపి, అది తిరిగి వచ్చే వరకు వేచి ఉంటుంది (block అవుతుంది), మరియు ప్రతి chunk కోసం ఇదే ప్రక్రియను పునరావృతం చేస్తుంది. ఒక్కో chunkకు 1.5 సెకన్లు చొప్పున 33 chunks ఉన్నప్పుడు, మీరు సుమారు 50 సెకన్ల సమయాన్ని వృథా చేస్తారు.

Async కోడ్ అన్ని రిక్వెస్ట్‌లను ఒకేసారి పంపిస్తుంది; మొత్తం సమయం అనేది అన్నిటికంటే నెమ్మదిగా ఉన్న ఒకే ఒక్క రిక్వెస్ట్ సమయానికి సమానంగా ఉంటుంది.

స్కేలింగ్ ప్రభావం

  • 31 chunks: 49.61 s → 1.56 s
  • 100 chunks: ~160 s → ~3 s
  • 500 chunks: ~800 s → ~5 s
  • 1,000 chunks: ~1,600 s → ~10 s

మీ పైప్‌లైన్ కోసం చిట్కాలు

  • ఖాళీగా ఉన్న సమయాన్ని (idle time) గమనించండి. మీ కోడ్ కేవలం నెట్‌వర్క్ కోసం వేచి చూస్తుంటే, అదనపు హార్డ్‌వేర్‌ను జోడించకండి.
  • AWS Bedrock రేట్ లిమిట్‌లను గౌరవించండి. కన్కరెంట్ రిక్వెస్ట్‌లను పరిమితం చేయడానికి asyncio.Semaphoreని ఉపయోగించండి.
  • non-blocking లైబ్రరీలను ఎంచుకోండి. boto3 నుండి aioboto3కి మారండి లేదా కాల్స్‌ను asyncio.to_thread()తో wrap చేయండి.

ఒకే ఫైల్‌ను మార్చడం ద్వారా అడ్డంకి తొలగిపోయింది. తక్కువ శ్రమ. ఎక్కువ ప్రభావం.

Source: https://dev.to/edwardyun/318x-speedup-by-changing-one-file-async-embedding-calls-on-aws-bedrock-4l61

Optional learning community: https://t.me/GyaanSetuAi