// INTELLIGENCE ARTIFICIELLE
Combien de modèles, combien d’argent ? Chiffrer l’IA
6 min de lecturenijitech
Le coût unitaire est faible et invisible en pilote ; multiplié par le volume, il décide de toute la facture. Une façon pratique de le mesurer et de le faire baisser.
Article complet
Le coût de l’IA est l’une des lignes les plus mal estimées d’un budget. Non parce que la formule serait compliquée, mais à cause d’une illusion simple : ce que vous payez pendant un pilote est si faible que personne ne s’y arrête. Une fois le système en production, ce même petit chiffre est multiplié par le volume et devient toute la facture.
Trois nombres décident du coût
Le coût de modèle d’un système d’IA est en réalité le produit de trois nombres : appels par transaction, texte traité par appel, et prix unitaire du modèle choisi. Doublez l’un d’eux et la facture double ; doublez les trois et elle est multipliée par huit.
Questions à poser au moment du budget
- Combien d’appels de modèle demande une tâche — un seul, ou cinq enchaînés ?
- Combien de contexte est envoyé par appel, et tout est-il nécessaire ?
- Cette tâche veut-elle vraiment le modèle le plus puissant, ou y va-t-elle par habitude ?
- Si le volume est multiplié par dix, lequel des trois nombres augmente ?
Envoyer chaque tâche au modèle le plus puissant
Ranger un texte dans l’une de deux catégories et mener une analyse en plusieurs étapes ne demandent pas la même capacité. Mais si un seul nom de modèle est inscrit dans le code applicatif, les deux vont au même endroit. Les tâches simples comme la classification forment généralement le gros des appels ; les router vers un modèle plus petit efface d’emblée une part sensible de la facture.
La latence est la moitié invisible du coût
Le coût s’accumule dans le temps d’attente autant que sur la facture. Chaque seconde d’attente d’un utilisateur fait baisser la fréquence d’usage de la fonction. Un modèle plus petit est généralement à la fois moins cher et plus rapide — ces deux améliorations sortent donc souvent de la même décision.
Exécuter une partie du travail près de l’utilisateur change la même équation. Une transaction qui n’atteint jamais un serveur central ne produit ni latence ni frais d’appel.
L’endroit où vous écrivez la décision compte
Si le savoir « quelle tâche va à quel modèle » est enfoui dans le code applicatif, chaque changement de prix et chaque nouveau modèle devient une tâche de développement. Si la même décision vivait dans une couche de routage, ce serait une tâche de configuration. Les modèles vieillissent ; la chaîne reste.
En bref
Quatre façons pratiques de faire baisser le coût
- Router les tâches simples vers un petit modèle — le volume est là
- Élaguer le contexte envoyé ; il est rarement nécessaire en entier
- Compter la latence comme une ligne de coût, pas comme un sujet à part
- Écrire le choix du modèle dans la configuration, pas dans le code
Appliquées ensemble, le gain n’est pas de quelques pour cent mais d’un facteur — et aucune des quatre ne demande de renoncer à la justesse.
Du glossaire : Orchestration de modèles · Mise à l'échelle en périphérie