Ускорение в 31,8 раза благодаря изменению всего одного файла

Я протестировал конвейер загрузки данных RAG и столкнулся с узким местом: обработка одного документа занимала 50 секунд.

Мой процессор простаивал. Приложение не выполняло математических вычислений или логических операций; оно просто ждало завершения HTTP-запроса, прежде чем запустить следующий.

Я переписал модуль эмбеддингов для асинхронной работы. Время выполнения сократилось с 49,61 до 1,56 секунды — без каких-либо изменений в инфраструктуре.

Детали теста

  • Модель: Amazon Titan Text Embeddings V2 (AWS Bedrock)
  • Набор данных: 33 текстовых чанка
  • Регион: us-east-1

Результаты

  • Последовательно: 49,61 с
  • Параллельно: 1,56 с
  • Ускорение: 31,8×

Почему это работает Последовательный код отправляет запрос и блокируется до получения ответа, повторяя это для каждого чанка. При 33 чанках по 1,5 с каждый вы тратите около 50 секунд впустую.

Асинхронный код отправляет все запросы одновременно; общее время выполнения равно времени самого медленного запроса.

Влияние на масштабирование

  • 31 чанк: 49,61 с → 1,56 с
  • 100 чанков: ~160 с → ~3 с
  • 500 чанков: ~800 с → ~5 с
  • 1000 чанков: ~1600 с → ~10 с

Советы для вашего конвейера

  • Ищите время простоя. Не добавляйте оборудование, если ваш код просто ждет ответа от сети.
  • Соблюдайте лимиты запросов (rate limits) AWS Bedrock. Используйте asyncio.Semaphore, чтобы ограничить количество одновременных запросов.
  • Отдавайте предпочтение неблокирующим библиотекам. Перейдите с 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