افزایش سرعت ۳۱.۸ برابری تنها با تغییر یک فایل
من یک خط لوله (pipeline) جذب داده RAG را تست کردم و با یک گلوگاه مواجه شدم: پردازش هر سند ۵۰ ثانیه طول میکشید.
پردازنده (CPU) من بیکار بود. اپلیکیشن در حال انجام محاسبات یا منطق پیچیده نبود؛ بلکه فقط منتظر میماند تا یک درخواست HTTP تمام شود و سپس درخواست بعدی را اجرا کند.
من ماژول embedding را برای اجرای ناهمگام (asynchronous) بازنویسی کردم. زمان اجرا از ۴۹.۶۱ ثانیه به ۱.۵۶ ثانیه کاهش یافت—بدون هیچ تغییری در زیرساخت.
جزئیات تست
- مدل: Amazon Titan Text Embeddings V2 (AWS Bedrock)
- مجموعه داده: ۳۳ تکه متن (chunk)
- منطقه: us-east-1
نتایج
- ترتیبی (Sequential): ۴۹.۶۱ ثانیه
- همزمان (Concurrent): ۱.۵۶ ثانیه
- افزایش سرعت: ۳۱.۸ برابر
چرا این روش کار میکند؟ کد ترتیبی یک درخواست ارسال میکند و تا زمان بازگشت پاسخ، مسدود (block) میماند و این کار را برای هر تکه تکرار میکند. با ۳۳ تکه که هر کدام ۱.۵ ثانیه زمان میبرند، حدود ۵۰ ثانیه هدر میرود.
کد ناهمگام (Async) تمام درخواستها را با هم ارسال میکند؛ در این حالت زمان کل برابر با زمان طولانیترین درخواست واحد خواهد بود.
تأثیر در مقیاسپذیری
- ۳۱ تکه: ۴۹.۶۱ ثانیه ← ۱.۵۶ ثانیه
- ۱۰۰ تکه: حدود ۱۶۰ ثانیه ← حدود ۳ ثانیه
- ۵۰۰ تکه: حدود ۸۰۰ ثانیه ← حدود ۵ ثانیه
- ۱,۰۰۰ تکه: حدود ۱,۶۰۰ ثانیه ← حدود ۱۰ ثانیه
نکاتی برای خط لوله شما
- به دنبال زمانهای بیکاری (idle time) باشید. اگر کد شما فقط منتظر شبکه است، سختافزار جدید اضافه نکنید.
- محدودیتهای نرخ (rate limits) AWS Bedrock را رعایت کنید. از یک
asyncio.Semaphoreبرای محدود کردن تعداد درخواستهای همزمان استفاده کنید. - کتابخانههای غیرمسدودکننده (non-blocking) را ترجیح دهید. از
boto3بهaioboto3تغییر وضعیت دهید یا فراخوانیها را باasyncio.to_thread()بستهبندی کنید.
تغییر تنها یک فایل، گلوگاه را از بین برد. تلاش کم، تأثیر بالا.
Source: https://dev.to/edwardyun/318x-speedup-by-changing-one-file-async-embedding-calls-on-aws-bedrock-4l61
جامعه یادگیری اختیاری: https://t.me/GyaanSetuAi