ಒಂದು ಫೈಲ್ ಬದಲಾವಣೆಯೊಂದಿಗೆ 31.8x ವೇಗವರ್ಧನೆ

ನಾನು ಒಂದು RAG ingestion pipeline ಅನ್ನು ಪರೀಕ್ಷಿಸಿದೆ ಮತ್ತು ಅದರಲ್ಲಿ ಒಂದು bottleneck ಅನ್ನು ಎದುರಿಸಿದೆ: ಒಂದು ದಾಖಲೆಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು 50 ಸೆಕೆಂಡುಗಳು ಬೇಕಾಗುತ್ತಿತ್ತು.

ನನ್ನ CPU ಸುಮ್ಮನೆ ಕುಳಿತಿತ್ತು (idle). ಅಪ್ಲಿಕೇಶನ್ ಯಾವುದೇ ಗಣಿತ ಅಥವಾ ತರ್ಕವನ್ನು (logic) ಮಾಡುತ್ತಿರಲಿಲ್ಲ; ಮುಂದಿನದನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಅದು ಕೇವಲ ಒಂದು HTTP ವಿನಂತಿ (request) ಮುಗಿಯುವವರೆಗೆ ಕಾಯುತ್ತಿತ್ತು.

ನಾನು embedding module ಅನ್ನು asynchronously ಕಾರ್ಯನಿರ್ವಹಿಸುವಂತೆ ಮರುಬರೆಯಿದೆ. ಯಾವುದೇ ಮೂಲಸೌಕರ್ಯ (infrastructure) ಬದಲಾವಣೆಗಳಿಲ್ಲದೆ, runtime 49.61 ಸೆಕೆಂಡುಗಳಿಂದ 1.56 ಸೆಕೆಂಡುಗಳಿಗೆ ಇಳಿಕೆಯಾಯಿತು.

ಪರೀಕ್ಷೆಯ ವಿವರಗಳು

  • ಮಾಡೆಲ್: Amazon Titan Text Embeddings V2 (AWS Bedrock)
  • ಡೇಟಾಸೆಟ್: 33 ಪಠ್ಯದ ತುಣುಕುಗಳು (text chunks)
  • ಪ್ರದೇಶ (Region): us-east-1

ಫಲಿತಾಂಶಗಳು

  • Sequential: 49.61 s
  • Concurrent: 1.56 s
  • ವೇಗವರ್ಧನೆ: 31.8×

ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ Sequential ಕೋಡ್ ಒಂದು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಹಿಂತಿರುಗುವವರೆಗೆ ಕಾಯುತ್ತದೆ (blocks), ಹೀಗೆ ಪ್ರತಿ ತುಣುಕುಗೂ ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ. ಪ್ರತಿ ತುಣುಕುಗೆ 1.5 s ಬೇಕಾದಾಗ, 33 ತುಣುಕುಗಳಿಗಾಗಿ ನೀವು ಸುಮಾರು ~50 s ವ್ಯರ್ಥ ಮಾಡುತ್ತೀರಿ.

Async ಕೋಡ್ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಒಟ್ಟಿಗೆ ಕಳುಹಿಸುತ್ತದೆ; ಒಟ್ಟು ಸಮಯವು ಅತ್ಯಂತ ನಿಧಾನವಾದ ಏಕೈಕ ವಿನಂತಿಯ ಸಮಯಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ.

Scaling ಪರಿಣಾಮ

  • 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 ಸಮಯವನ್ನು ಗಮನಿಸಿ. ನಿಮ್ಮ ಕೋಡ್ ಕೇವಲ ನೆಟ್‌ವರ್ಕ್‌ನ ನಿರೀಕ್ಷೆಯಲ್ಲಿಯೇ ಇದ್ದರೆ, ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಹೆಚ್ಚಿಸಬೇಡಿ.
  • AWS Bedrock ರೇಟ್ ಮಿತಿಗಳನ್ನು (rate limits) ಗೌರವಿಸಿ. ಏಕಕಾಲಿಕ ವಿನಂತಿಗಳನ್ನು (concurrent requests) ನಿಯಂತ್ರಿಸಲು asyncio.Semaphore ಬಳಸಿ.
  • Non-blocking ಲೈಬ್ರರಿಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡಿ. boto3 ನಿಂದ aioboto3 ಗೆ ಬದಲಾಯಿಸಿ ಅಥವಾ ಕರೆಗಳನ್ನು asyncio.to_thread() ಮೂಲಕ ಸುತ್ತುವರಿಯಿರಿ (wrap).

ಕೇವಲ ಒಂದು ಫೈಲ್ ಬದಲಾಯಿಸುವುದರಿಂದ bottleneck ಅನ್ನು ನಿವಾರಿಸಬಹುದು. ಕಡಿಮೆ ಶ್ರಮ. ಹೆಚ್ಚಿನ ಪರಿಣಾಮ.

ಮೂಲ (Source): https://dev.to/edwardyun/318x-speedup-by-changing-one-file-async-embedding-calls-on-aws-bedrock-4l61

ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi