Mesurer l'empreinte d'un système d'IA depuis sa place

Une organisation qui utilise une API mesure ce qu'elle envoie et ce qu'elle reçoit ; elle ne mesure ni le mix électrique du centre de données, ni la fabrication du matériel, ni le refroidissement. Cette ligne de partage doit être posée d'emblée, parce qu'elle décide de ce qui sera un chiffre et de ce qui restera une hypothèse.

Le réflexe habituel consiste à convertir les jetons en kilowattheures par un coefficient trouvé dans une étude. Le résultat est un nombre, il n'est pas une mesure : le coefficient dépend du matériel, de la taille du modèle, du taux de charge, de la région, et aucun de ces paramètres n'est connu.

Produire ce nombre coûte peu et engage beaucoup, puisqu'il finira dans un rapport où personne ne pourra le vérifier.

Les jetons consommés, les appels évités et les requêtes redondantes se relèvent exactement, depuis votre propre code. Ce sont les trois seules que je fais figurer dans un bilan.

Les jetons consommés sont déjà comptés si la couche d'abstraction les journalise, ce qui est le prérequis de toute mesure de coût. Ils constituent la base commune à l'argument économique et à l'argument énergétique.

Les appels évités mesurent l'effet du cache et du routage : combien de requêtes n'ont pas atteint le modèle parce qu'un préfixe était réutilisé ou qu'un petit modèle a suffi. C'est la grandeur qui progresse quand le système s'améliore.

Les requêtes redondantes comptent ce qui a été calculé deux fois pour rien. Sur les systèmes que je reprends, ce poste est presque toujours non nul, et il se corrige en quelques heures.

Ces trois grandeurs viennent du même dispositif de journalisation que le reste, décrit dans l'observabilité des systèmes IA.

On les demande au fournisseur, et on archive sa réponse, y compris quand la réponse est qu'il ne publie rien. C'est ce qui distingue une organisation qui a cherché d'une organisation qui a estimé.

La demande est simple à formuler : consommation par million de jetons pour le modèle utilisé, région de traitement, et méthode de calcul. Certains fournisseurs publient une partie de ces éléments, d'autres rien.

Une absence de réponse documentée vaut mieux qu'un chiffre inventé. Elle situe honnêtement la limite du bilan, et elle constitue une pièce utile si la question revient dans un cadre contraignant.

Cette demande s'ajoute naturellement à celles qu'on adresse déjà au fournisseur, listées dans ce qui doit descendre la chaîne.

Le nombre moyen de jetons envoyés par requête utile est l'indicateur qui relie sobriété, coût et qualité. Il baisse quand le système s'améliore, sur les trois plans à la fois.

Le mot important est « utile » : une requête qui produit une réponse dont personne ne se sert consomme autant qu'une autre. Rapporter la consommation à l'usage réel, et non au nombre d'appels, évite de féliciter un système qui tourne à vide.

Cet indicateur a un autre mérite : il se comprend sans conversion. Une direction qui voit passer le contexte moyen de douze mille à cinq mille jetons comprend le progrès sans qu'on ait à parler de kilowattheures.

La démarche de réduction correspondante est décrite dans réduire de moitié le contexte envoyé.

Un bilan qui dit ce qu'il ne sait pas est le seul qui reste utilisable quand quelqu'un le vérifie. C'est un argument de crédibilité avant d'être un argument de méthode.

Les bilans énergétiques d'IA que je vois circuler reposent presque tous sur une chaîne de coefficients dont personne ne peut reconstituer l'origine. Ils impressionnent en comité et ne survivent pas à une question précise.

Un document plus modeste, qui donne trois chiffres exacts et nomme trois inconnues, se défend indéfiniment. Il permet aussi de suivre un progrès dans le temps, ce qu'une estimation ne permet jamais, parce qu'on ne sait pas si la variation vient du système ou du coefficient.

C'est le même principe que celui appliqué à l'évaluation : mesurer peu et exactement vaut mieux que mesurer beaucoup et approximativement, comme développé dans construire un jeu de tests en une journée.