মাত্র একটি ফাইল পরিবর্তনের মাধ্যমে 31.8x গতি বৃদ্ধি

আমি একটি RAG ইনজেশন পাইপলাইন পরীক্ষা করছিলাম এবং একটি বাধার (bottleneck) সম্মুখীন হলাম: একটি ডকুমেন্ট প্রসেস করতে 50 সেকেন্ড সময় নিচ্ছিল।

আমার CPU অলস বসে ছিল। অ্যাপটি কোনো গাণিতিক বা লজিক্যাল কাজ করছিল না; এটি কেবল পরবর্তী রিকোয়েস্টটি শুরু করার আগে একটি HTTP রিকোয়েস্ট শেষ হওয়ার জন্য অপেক্ষা করছিল।

আমি এমবেডিং মডিউলটি অ্যাসিনক্রোনাসলি (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) কোড একটি রিকোয়েস্ট পাঠায় এবং সেটি ফিরে না আসা পর্যন্ত আটকে থাকে, এবং প্রতিটি চাঙ্কের জন্য এটি বারবার ঘটে। প্রতিটি চাঙ্ক 1.5 সেকেন্ড করে নিলে 33টি চাঙ্কের জন্য আপনি প্রায় 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-এর রেট লিমিট (rate limits) মেনে চলুন। কনকারেন্ট রিকোয়েস্টের সংখ্যা সীমিত করতে একটি 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