« 20 Mo » ne veut rien dire. Ce qui se déploie, ce n'est pas un framework, c'est une application, et la seule question qui compte est la part que le framework y occupe. Cet article détaille un chapitre du comparatif de douze frameworks agentiques, mesuré sur une application FastAPI minimale sous Python 3.12.
Mesurer ce que le framework ajoute, pas ce qu'il pèse seul
Mesurer un framework isolé paraît toujours léger. Il arrive dans une application qui existe déjà, et cette application a ses dépendances : FastAPI apporte Pydantic, httpx, Starlette et anyio. Les compter au débit du framework, c'est lui facturer ce que l'hôte avait de toute façon.
La mesure est donc ce que le framework ajoute : fastapi[standard] seul pèse 43 paquets et 36 Mo, et on regarde quelle fraction de l'application finale le framework représente une fois ajouté avec sa route vers Mistral.
D'un tiers à la quasi-totalité
Avec Pydantic AI, le framework et sa route représentent 36 % du disque de l'application finale : les deux tiers restants sont FastAPI et ce qu'il apportait déjà. Avec CrewAI, la part monte à 95 % : l'application FastAPI n'est plus qu'un détail de 5 % dans une image dominée par son framework d'agents.
Entre les deux, la progression est continue et sans palier : 45 % pour Agno, 49 et 51 % pour les deux LangChain, 62 % pour le SDK d'AWS, puis un saut au-dessus des trois quarts pour toute la seconde moitié du tableau.
Les deux colonnes ne désignent pas le même gagnant
Agno occupe la plus petite part des paquets, 25 % contre 26 % pour Pydantic AI, mais la plus grosse part du disque des deux : 45 % contre 36 %. Agno installe quatorze paquets contre quinze, pour vingt-neuf mégaoctets contre vingt.
C'est la raison d'être des deux colonnes. Le nombre de dépendances mesure ce qu'il faut auditer et suivre en avis de sécurité ; les mégaoctets mesurent ce qu'on construit.
La route vers Mistral coûte plus cher que le framework
C'est le résultat que je n'attendais pas. Cinq des douze n'ont aucune intégration Mistral et doivent passer par la gateway LiteLLM. Or cette gateway a un prix, mesurable seul :
| Ajouté à FastAPI | Total | Coût de la route |
|---|---|---|
litellm |
80 paquets, 186 Mo | +37 paquets, +150 Mo |
mistralai |
50 paquets, 47 Mo | +7 paquets, +11 Mo |
La gateway est 14 fois plus lourde sur le disque que le SDK officiel. Et on ne peut pas y couper en n'installant que le provider voulu : les extras de LiteLLM sont des fonctionnalités, pas des providers, par exemple proxy, cache ou CLI. Le support de tous les modèles est dans le cœur, et ses quatorze dépendances obligatoires comprennent le SDK d'OpenAI et boto3, le SDK d'AWS. Pour appeler Mistral, on installe donc les clients d'OpenAI et d'Amazon.
Le poids se lit dans les paquets : litellm lui-même 77 Mo, botocore 25, openai 11, tokenizers et hf_xet 17 à eux deux.
Autrement dit, pour 5 des 12, le choix du framework n'a presque aucune influence sur le poids. C'est le choix du provider qui décide. Une équipe qui quitte OpenAI pour un modèle européen paie cent cinquante mégaoctets de gateway avant d'avoir écrit une ligne d'agent. Ce n'est pas une fatalité technique : c'est l'effet d'un écosystème construit autour d'une seule API, dans lequel tout le reste est un cas particulier.
Trois cas à part
Semantic Kernel est le plus lourd des frameworks à route native : 85 % du disque final, soit 206 Mo ajoutés, alors qu'il parle à Mistral sans gateway. Le poids vient de lui, pas de sa route. C'est le seul du tableau dans ce cas.
openai-agents épingle une version ancienne de LiteLLM, la 1.83.0, quand tous les autres utilisent la 1.98.0. Il paie donc une gateway plus légère que ses voisins : 125 Mo au lieu de 150. Une dépendance épinglée est un coût gelé, pas un coût évité : il se paiera à la mise à jour.
CrewAI est hors échelle avec 672 Mo ajoutés : 34 fois Pydantic AI, et 522 Mo une fois la gateway déduite. Il est aussi le seul de la sélection à n'offrir aucun chemin maigre : crewai-core existe sur PyPI mais c'est un paquet d'utilitaires, version, chemins, télémétrie, dont on ne peut rien faire seul.
Ce que le poids ne dit pas
Un framework léger n'est pas un bon framework, et ce chapitre ne classe rien à lui seul. Il donne deux chiffres à mettre en face du reste : ce qu'il faut auditer, et ce qu'on transporte à chaque déploiement.
Les six autres critères sont dans le comparatif complet : observabilité, tenue en charge, gestion des erreurs, comptage des tokens, persistance, sortie typée.