एका फाईलमध्ये बदल करून 31.8x वेगाची वाढ

मी एका RAG ingestion pipeline ची चाचणी केली आणि मला एक अडथळा (bottleneck) जाणवला: एका दस्तऐवजावर प्रक्रिया करण्यासाठी 50 सेकंद लागत होते.

माझा CPU रिकामी (idle) बसला होता. ॲप कोणतेही गणित किंवा लॉजिक करत नव्हते; ते फक्त पुढची विनंती (request) सुरू करण्यापूर्वी HTTP request पूर्ण होण्याची वाट पाहत होते.

मी 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×

हे का काम करते Sequential कोड एक विनंती पाठवतो आणि ती परत येईपर्यंत थांबतो (blocks), आणि प्रत्येक चंकसाठी ही प्रक्रिया पुन्हा पुन्हा होते. जर प्रत्येक चंकसाठी 1.5 s लागत असतील, तर 33 चंक्ससाठी सुमारे 50 s वाया जातात.

Async कोड सर्व विनंत्या एकाच वेळी पाठवतो; एकूण वेळ हा सर्वात संथ (slowest) सिंगल रिक्वेस्टच्या वेळेइतकाच असतो.

स्केलिंगचा प्रभाव (Scaling impact)

  • 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 च्या रेट लिमिट्सचा (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