31,8-krotne przyspieszenie dzięki zmianie jednego pliku

Przetestowałem potok ingestii RAG i napotkałem wąskie gardło: przetworzenie jednego dokumentu zajmowało 50 sekund.

Mój procesor (CPU) bezczynnie czekał. Aplikacja nie wykonywała żadnych obliczeń ani logiki; po prostu czekała na zakończenie żądania HTTP, zanim uruchomiła kolejne.

Przepisałem moduł embeddingów, aby działał asynchronicznie. Czas wykonania spadł z 49,61 sekundy do 1,56 sekundy — bez żadnych zmian w infrastrukturze.

Szczegóły testu

  • Model: Amazon Titan Text Embeddings V2 (AWS Bedrock)
  • Zbiór danych: 33 fragmenty tekstu
  • Region: us-east-1

Wyniki

  • Sekwencyjnie: 49,61 s
  • Równolegle: 1,56 s
  • Przyspieszenie: 31,8×

Dlaczego to działa Kod sekwencyjny wysyła żądanie i blokuje wykonanie do momentu otrzymania odpowiedzi, powtarzając to dla każdego fragmentu. Przy 33 fragmentach po 1,5 s każdy, tracisz około 50 s.

Kod asynchroniczny wysyła wszystkie żądania jednocześnie; całkowity czas jest równy czasowi najwolniejszego pojedynczego żądania.

Wpływ na skalowalność

  • 31 fragmentów: 49,61 s → 1,56 s
  • 100 fragmentów: ~160 s → ~3 s
  • 500 fragmentów: ~800 s → ~5 s
  • 1000 fragmentów: ~1600 s → ~10 s

Wskazówki dla Twojego potoku

  • Szukaj czasu bezczynności. Nie dodawaj sprzętu, jeśli Twój kod po prostu czeka na sieć.
  • Przestrzegaj limitów przepustowości (rate limits) AWS Bedrock. Użyj asyncio.Semaphore, aby ograniczyć liczbę jednoczesnych żądań.
  • Wybieraj biblioteki nieblokujące. Przejdź z boto3 na aioboto3 lub owiń wywołania za pomocą asyncio.to_thread().

Zmiana jednego pliku usunęła wąskie gardło. Mały wysiłek. Duży efekt.

Źródło: https://dev.to/edwardyun/318x-speedup-by-changing-one-file-async-embedding-calls-on-aws-bedrock-4l61

Opcjonalna społeczność edukacyjna: https://t.me/GyaanSetuAi