एक फ़ाइल बदलने से 31.8x की गति वृद्धि

मैंने एक RAG ingestion pipeline का परीक्षण किया और एक बाधा (bottleneck) का सामना किया: एक दस्तावेज़ को प्रोसेस करने में 50 सेकंड लग रहे थे।

मेरा CPU खाली बैठा था। ऐप कोई गणित या लॉजिक नहीं कर रहा था; यह बस अगले अनुरोध को शुरू करने से पहले एक HTTP अनुरोध के पूरा होने का इंतज़ार कर रहा था।

मैंने embedding module को asynchronously चलाने के लिए फिर से लिखा। रनटाइम 49.61 सेकंड से घटकर 1.56 सेकंड रह गया—बिना किसी इंफ्रास्ट्रक्चर बदलाव के।

परीक्षण का विवरण

  • मॉडल: Amazon Titan Text Embeddings V2 (AWS Bedrock)
  • डेटासेट: 33 टेक्स्ट चंक्स (text chunks)
  • रीजन: us-east-1

परिणाम

  • सीक्वेंशियल (Sequential): 49.61 s
  • कन्करेंट (Concurrent): 1.56 s
  • स्पीडअप (Speedup): 31.8×

यह कैसे काम करता है सीक्वेंशियल कोड एक अनुरोध भेजता है और उसके वापस आने तक रुक जाता है, और यही प्रक्रिया हर चंक के लिए दोहराई जाती है। 1.5 सेकंड प्रति चंक के हिसाब से 33 चंक्स के साथ, आप लगभग 50 सेकंड बर्बाद करते हैं।

Async कोड सभी अनुरोधों को एक साथ भेजता है; कुल समय सबसे धीमे एकल अनुरोध के बराबर होता है।

स्केलिंग का प्रभाव

  • 31 चंक्स: 49.61 s → 1.56 s
  • 100 चंक्स: ~160 s → ~3 s
  • 500 चंक्स: ~800 s → ~5 s
  • 1,000 चंक्स: ~1,600 s → ~10 s

आपके पाइपलाइन के लिए सुझाव

  • Idle time (खाली समय) पर ध्यान दें। यदि आपका कोड केवल नेटवर्क का इंतज़ार कर रहा है, तो हार्डवेयर न बढ़ाएं।
  • AWS Bedrock की रेट लिमिट्स (rate limits) का पालन करें। कन्करेंट अनुरोधों को सीमित करने के लिए asyncio.Semaphore का उपयोग करें।
  • नॉन-ब्लॉकिंग (non-blocking) लाइब्रेरीज़ को प्राथमिकता दें। boto3 से aioboto3 पर स्विच करें या कॉल्स को asyncio.to_thread() के साथ रैप करें।

सिर्फ एक फ़ाइल बदलने से बाधा दूर हो गई। कम प्रयास। बड़ा प्रभाव।

स्रोत: https://dev.to/edwardyun/318x-speedup-by-changing-one-file-async-embedding-calls-on-aws-bedrock-4l61

वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi