Accélération de 31,8x avec une seule modification de fichier

J'ai testé un pipeline d'ingestion RAG et j'ai rencontré un goulot d'étranglement : un document mettait 50 secondes à être traité.

Mon CPU restait inactif. L'application ne faisait ni calculs ni logique ; elle attendait simplement qu'une requête HTTP se termine avant de lancer la suivante.

J'ai réécrit le module d'embedding pour qu'il s'exécute de manière asynchrone. Le temps d'exécution est passé de 49,61 secondes à 1,56 seconde — sans aucun changement d'infrastructure.

Détails du test

  • Modèle : Amazon Titan Text Embeddings V2 (AWS Bedrock)
  • Jeu de données : 33 segments de texte
  • Région : us-east-1

Résultats

  • Séquentiel : 49,61 s
  • Concurrent : 1,56 s
  • Accélération : 31,8×

Pourquoi ça marche Le code séquentiel envoie une requête et bloque jusqu'à ce qu'elle revienne, répétant l'opération pour chaque segment. Avec 33 segments à 1,5 s chacun, vous perdez environ 50 s.

Le code asynchrone lance toutes les requêtes simultanément ; le temps total est égal à la requête individuelle la plus lente.

Impact sur le passage à l'échelle

  • 31 segments : 49,61 s → 1,56 s
  • 100 segments : ~160 s → ~3 s
  • 500 segments : ~800 s → ~5 s
  • 1 000 segments : ~1 600 s → ~10 s

Conseils pour votre pipeline

  • Recherchez les temps d'inactivité. N'ajoutez pas de matériel si votre code ne fait qu'attendre le réseau.
  • Respectez les limites de débit (rate limits) d'AWS Bedrock. Utilisez un asyncio.Semaphore pour limiter le nombre de requêtes concurrentes.
  • Privilégiez les bibliothèques non bloquantes. Passez de boto3 à aioboto3 ou enveloppez les appels avec asyncio.to_thread().

Modifier un seul fichier a supprimé le goulot d'étranglement. Faible effort. Impact élevé.

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

Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi