31,8x versnelling met één bestandswijziging
Ik heb een RAG-ingestiepipeline getest en stuitte op een bottleneck: het verwerken van één document duurde 50 seconden.
Mijn CPU deed niets. De app was niet bezig met berekeningen of logica; hij wachtte alleen tot een HTTP-verzoek was voltooid voordat het volgende werd gestart.
Ik heb de embedding-module herschreven om deze asynchroon uit te voeren. De runtime daalde van 49,61 seconden naar 1,56 seconden — zonder wijzigingen in de infrastructuur.
Testdetails
- Model: Amazon Titan Text Embeddings V2 (AWS Bedrock)
- Dataset: 33 tekstchunks
- Regio: us-east-1
Resultaten
- Sequentieel: 49,61 s
- Gelijktijdig: 1,56 s
- Versnelling: 31,8×
Waarom dit werkt Sequentiële code stuurt een verzoek en blokkeert totdat het antwoord binnen is, en herhaalt dit voor elke chunk. Met 33 chunks van elk 1,5 s verspil je ongeveer 50 s.
Asynchrone code verstuurt alle verzoeken tegelijkertijd; de totale tijd is gelijk aan de langzaamste individuele aanroep.
Impact op schaalbaarheid
- 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
Tips voor je pipeline
- Zoek naar inactiviteit (idle time). Voeg geen extra hardware toe als je code alleen maar op het netwerk wacht.
- Houd rekening met de rate limits van AWS Bedrock. Gebruik een
asyncio.Semaphoreom het aantal gelijktijdige verzoeken te beperken. - Geef de voorkeur aan non-blocking bibliotheken. Stap over van
boto3naaraioboto3of gebruikasyncio.to_thread()om aanroepen te wrappen.
Het wijzigen van één enkel bestand loste de bottleneck op. Weinig moeite. Grote impact.
Bron: https://dev.to/edwardyun/318x-speedup-by-changing-one-file-async-embedding-calls-on-aws-bedrock-4l61
Optionele leercommunity: https://t.me/GyaanSetuAi
