האצה פי 31.8 באמצעות שינוי קובץ אחד

בדקתי pipeline של RAG ingestion ונתקלתי בצוואר בקבוק: עיבוד מסמך אחד לקח 50 שניות.

המעבד (CPU) שלי ישב במצב חוסר פעילות. האפליקציה לא ביצעה חישובים או לוגיקה; היא פשוט חיכתה לבקשת HTTP שתסתיים לפני שהיא מפעילה את הבאה.

כתבתי מחדש את מודול ה-embedding כך שירוץ בצורה אסינכרונית (asynchronously). זמן הריצה צנח מ-49.61 שניות ל-1.56 שניות — ללא שינויים בתשתית.

פרטי הבדיקה

  • מודל: Amazon Titan Text Embeddings V2 (AWS Bedrock)
  • סט נתונים: 33 מקטעי טקסט (chunks)
  • אזור (Region): us-east-1

תוצאות

  • סדרתי (Sequential): 49.61 שניות
  • מקבילי (Concurrent): 1.56 שניות
  • האצה: 31.8×

למה זה עובד קוד סדרתי שולח בקשה ונחסם עד שהיא חוזרת, וחוזר על כך עבור כל מקטע. עם 33 מקטעים של 1.5 שניות כל אחד, אתם מבזבזים כ-50 שניות.

קוד אסינכרוני מפעיל את כל הבקשות יחד; הזמן הכולל שווה לזמן של הבקשה האיטית ביותר.

השפעה על סקיילביליות (Scaling impact)

  • 31 מקטעים: 49.61 שניות ← 1.56 שניות
  • 100 מקטעים: כ-160 שניות ← כ-3 שניות
  • 500 מקטעים: כ-800 שניות ← כ-5 שניות
  • 1,000 מקטעים: כ-1,600 שניות ← כ-10 שניות

טיפים ל-pipeline שלכם

  • חפשו זמני חוסר פעילות (idle time). אל תוסיפו חומרה אם הקוד שלכם פשוט מחכה לרשת.
  • הקפידו על מגבלות הקצב (rate limits) של AWS Bedrock. השתמשו ב-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