એક ફાઇલના ફેરફાર સાથે 31.8x સ્પીડઅપ
મેં એક RAG ingestion pipeline ટેસ્ટ કરી અને એક બોટલનેક (bottleneck) નો સામનો કર્યો: એક ડોક્યુમેન્ટને પ્રોસેસ કરવામાં 50 સેકન્ડ લાગી હતી.
મારો CPU નિષ્ક્રિય (idle) હતો. એપ કોઈ ગણતરી કે લોજિક કરી રહી નહોતી; તે ફક્ત આગામી રિક્વેસ્ટ શરૂ કરતા પહેલા એક HTTP રિક્વેસ્ટ પૂરી થવાની રાહ જોતી હતી.
મેં એમ્બેડિંગ મોડ્યુલને અસિંક્રોનસલી (asynchronously) ચલાવવા માટે ફરીથી લખ્યું. ઇન્ફ્રાસ્ટ્રક્ચરમાં કોઈ ફેરફાર કર્યા વગર, રનટાઇમ 49.61 સેકન્ડથી ઘટીને 1.56 સેકન્ડ થઈ ગયો.
ટેસ્ટ વિગતો (Test Details)
- મોડલ: Amazon Titan Text Embeddings V2 (AWS Bedrock)
- ડેટાસેટ: 33 ટેક્સ્ટ ચંક્સ (text chunks)
- રીજન: us-east-1
પરિણામો (Results)
- સિક્વન્શિયલ (Sequential): 49.61 s
- કન્કરન્ટ (Concurrent): 1.56 s
- સ્પીડઅપ (Speedup): 31.8×
તે કેવી રીતે કામ કરે છે સિક્વન્શિયલ કોડ એક રિક્વેસ્ટ મોકલે છે અને તે પાછી આવે ત્યાં સુધી બ્લોક રહે છે, અને દરેક ચંક માટે આ પ્રક્રિયાનું પુનરાવર્તન કરે છે. જો દરેક ચંકમાં 1.5 સેકન્ડ લાગે, તો 33 ચંક્સ માટે તમે આશરે 50 સેકન્ડ વેડફી રહ્યા છો.
અસિંક (Async) કોડ બધી રિક્વેસ્ટ એકસાથે મોકલે છે; કુલ સમય સૌથી ધીમી સિંગલ રિક્વેસ્ટ જેટલો જ હોય છે.
સ્કેલિંગની અસર (Scaling impact)
- 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 time) શોધો. જો તમારો કોડ ફક્ત નેટવર્કની રાહ જોઈ રહ્યો હોય, તો વધારાનું હાર્ડવેર ઉમેરશો નહીં.
- AWS Bedrock ની રેટ લિમિટનું પાલન કરો. કન્કરન્ટ રિક્વેસ્ટને મર્યાદિત કરવા માટે
asyncio.Semaphoreનો ઉપયોગ કરો. - નોન-બ્લોકિંગ લાઈબ્રેરીઓને પ્રાધાન્ય આપો.
boto3થીaioboto3પર સ્વિચ કરો અથવા કોલ્સનેasyncio.to_thread()સાથે રેપ (wrap) કરો.
માત્ર એક ફાઇલ બદલવાથી બોટલનેક દૂર થઈ ગયો. ઓછી મહેનત. ઊંચો પ્રભાવ.
સ્ત્રોત: https://dev.to/edwardyun/318x-speedup-by-changing-one-file-async-embedding-calls-on-aws-bedrock-4l61
વૈકલ્પિક લર્નિંગ કોમ્યુનિટી: https://t.me/GyaanSetuAi