Le mythe du serverless selon lequel « vous ne payez que pour les millisecondes d'exécution de votre code » s'effondre lorsque vous essayez d'exécuter un agent IA sur AWS Lambda. En pratique, les postes de dépense les plus importants ne sont pas les frais de calcul Lambda, mais la latence de démarrage à froid, les boucles de tentatives et la consommation de tokens générée par ces boucles.

Pourquoi la vision habituelle du serverless induit en erreur pour les agents IA

La plupart des développeurs traitent une fonction Lambda comme un simple bac à sable de calcul : gardez le handler rapide, définissez une taille de mémoire modeste, et la facture restera stable. Cela fonctionne pour des points de terminaison HTTP simples, mais un agent qui appelle un modèle de langage, évalue la réponse et tente éventuellement de recommencer tout le cycle ne correspond pas directement à une seule invocation Lambda. Le flux de travail interne de l'agent multiplie le nombre d'appels au modèle, et chaque appel supplémentaire ajoute un coût en tokens qui peut éclipser les frais de calcul.

Les démarrages à froid sont le coût caché

Lorsqu'un conteneur Lambda est provisionné pour la première fois, il doit décompresser le package de déploiement. L'agent en question importe un grand ensemble de bibliothèques Python, l'image peut donc être volumineuse. Supprimer les outils réservés au développement — comme une bibliothèque d'automatisation de navigateur utilisée uniquement pour les tests locaux — réduit la taille de l'image, ce qui raccourcit par conséquent le temps de décompression. Un package plus léger signifie que la fonction est prête à traiter une requête plus rapidement, réduisant ainsi le temps d'attente pour la montée en température du conteneur.

Un second levier réside dans l'emplacement du code d'initialisation. En construisant le graphe de l'agent au moment de l'importation du module, le travail le plus lourd s'effectue une seule fois par démarrage de conteneur plutôt qu'à chaque requête. Les invocations à chaud ignorent alors entièrement ce travail. Le compromis est un démarrage à froid légèrement plus long, mais le bénéfice est un temps de configuration par requête quasi nul une fois le conteneur opérationnel.

La mémoire sert aussi de curseur de latence

Sur Lambda, la quantité de mémoire allouée détermine également la part de CPU dont dispose la fonction. Allouer 1 Go de mémoire à la fonction lui octroie un cœur de CPU virtuel complet. Ce surplus de CPU accélère l'importation des bibliothèques et la création du graphe de l'agent, réduisant ainsi la latence de démarrage à froid et de montée en température.

Le coût de la boucle : les tentatives multiplient la consommation de tokens

L'agent suit une boucle travailleur-évaluateur. Le travailleur génère une réponse, l'évaluateur la vérifie, et si l'évaluateur signale une erreur, la tâche est renvoyée au travailleur. La boucle peut se répéter jusqu'à cinq fois avant d'abandonner. Cela signifie qu'une seule requête externe peut déclencher :

  • jusqu'à cinq appels au modèle travailleur
  • jusqu'à cinq appels au modèle évaluateur
  • autant d'appels d'outils que l'agent décide d'effectuer

La facture Lambda reste prévisible car AWS facture à la milliseconde d'exécution, mais la facture des tokens peut varier considérablement selon le nombre de tentatives nécessaires.

Le piège du timeout : API Gateway vs Lambda

API Gateway impose un timeout strict de 29 secondes sur la requête HTTP qu'il gère. Une boucle d'agent de cinq tours peut facilement dépasser cette limite, même si la fonction Lambda sous-jacente est configurée pour une fenêtre d'exécution de cinq minutes. Contourner API Gateway en utilisant les Lambda Function URLs supprime ce plafond de 29 secondes, permettant à la fonction de terminer sa boucle sans être interrompue.

Ce que les développeurs devraient budgétiser

La leçon est simple : budgétiser un agent IA serverless nécessite plus que l'addition des millisecondes d'exécution Lambda. Vous devez prendre en compte :

  • la taille du package de déploiement et la latence de démarrage à froid qui en résulte
  • le paramètre de mémoire qui détermine le CPU et donc la vitesse d'importation
  • le nombre de tentatives prévu dans la boucle travailleur-évaluateur, ce qui impacte directement la consommation de tokens
  • le choix de l'interface (API Gateway vs Function URL) pour éviter les timeouts prématurés

Ignorer l'une de ces variables peut vous laisser avec une facture qui ne ressemble en rien à celle que vous aviez prévue.