Comment le coût d'un modèle de base partagé devrait-il être réparti ?

Le coût d’un modèle de base commun doit être réparti en fonction de la consommation réelle, chaque unité opérationnelle ou équipe payant proportionnellement aux ressources qu’elle utilise. La répartition en fonction de l’utilisation est l’approche la plus courante et la plus justifiable, même si les organisations ajoutent souvent des frais généraux fixes pour couvrir les infrastructures partagées qui ne peuvent pas être directement imputées. Les questions ci-dessous examinent en détail chaque aspect de ce défi, des mécanismes de refacturation aux outils et à la gouvernance.

Quelles sont les méthodes les plus courantes pour répartir les coûts liés aux infrastructures d'IA partagées ?

Les méthodes les plus courantes de répartition des coûts liés à une infrastructure d’IA partagée sont la répartition en fonction de l’utilisation, la répartition à taux fixe et les modèles de tarification à plusieurs niveaux. La répartition en fonction de l’utilisation facture chaque utilisateur proportionnellement à sa consommation réelle, par exemple en nombre d’appels d’inférence, de jetons traités ou d’heures de GPU utilisées. La répartition à taux fixe répartit un coût prédéterminé de manière égale ou selon des pourcentages convenus. La tarification à plusieurs niveaux applique des tarifs différents en fonction des niveaux de service ou de la priorité d'accès.

Dans la pratique, la plupart des grandes entreprises ont recours à une combinaison de ces deux approches. Une partie de base des coûts d’infrastructure partagée, comme le cluster de calcul exécutant le modèle de base, est répartie selon une clé de répartition fixe ou proportionnelle. Les coûts variables liés aux charges de travail réelles, tels que les appels d’API ou les tâches de réglage fin, sont ensuite répartis en fonction des données de consommation.

Chaque méthode présente des avantages et des inconvénients :

• Répartition en fonction de la consommation C'est la méthode la plus précise, mais elle nécessite un suivi et un marquage fiables au niveau de l'équipe ou de l'application.
• Répartition à taux fixe est simple à mettre en œuvre, mais peut susciter du ressentiment lorsque son utilisation varie d'une équipe à l'autre.
• Tarification échelonnée récompense les équipes qui acceptent des accords de niveau de service moins exigeants par des coûts réduits, ce qui peut contribuer à gérer la demande sur les ressources partagées.
• Répartition négociée répartit les coûts selon un accord préalable ; cette méthode est souvent utilisée lorsque la consommation est difficile à mesurer directement.

Le choix de la méthode appropriée dépend de la capacité de votre organisation à mettre en œuvre le modèle, ainsi que de la maturité de votre Pratiques FinOps, ainsi que la mesure dans laquelle les unités opérationnelles ont accepté d'assumer la responsabilité des dépenses liées à l'IA.

Comment fonctionne la facturation à l'utilisation pour un modèle de base ?

La facturation à l'utilisation d'un modèle de base consiste à mesurer la consommation de ce modèle par chaque équipe, à attribuer un coût unitaire à cette consommation, puis à facturer l'unité opérationnelle correspondante en conséquence. Les unités de consommation les plus courantes sont les requêtes d’inférence, les jetons traités, les heures de GPU ou les appels d’API. Le prix de chaque unité est calculé en divisant le coût total d’exploitation de l’infrastructure partagée par la consommation totale de l’ensemble des utilisateurs.

La mise en œuvre de ce système nécessite que trois éléments fonctionnent en parallèle. Premièrement, vous avez besoin d’un système de suivi fiable : chaque appel au modèle de base doit être associé à un identifiant d’équipe, de produit ou de centre de coûts. Deuxièmement, vous devez disposer d’un coût unitaire reflétant le coût total de l’infrastructure, y compris la puissance de calcul, le stockage, le réseau et l’assistance. Troisièmement, il faut un cycle de facturation régulier, dans le cadre duquel les équipes reçoivent un relevé indiquant ce qu’elles ont consommé et ce qu’elles doivent.

Un défi courant réside dans le fait que les coûts des modèles de base ne sont pas toujours linéaires. L’exécution d’un modèle à une capacité de 10% coûte presque autant que son exécution à une capacité de 80%, car les coûts fixes d’infrastructure prédominent. Cela signifie que les coûts unitaires peuvent fluctuer considérablement en fonction du taux d’utilisation global, ce qui complique les prévisions pour les équipes individuelles. Une solution consiste à fixer un coût de capacité réservée que toutes les équipes se partagent à parts égales, puis à appliquer des frais liés à l’utilisation uniquement pour la consommation dépassant ce seuil de référence.

Quelle est la différence entre le « showback » et le « chargeback » en matière de coûts liés à l'IA ?

Le « showback » permet de répertorier les coûts liés à l'IA pour chaque équipe ou unité opérationnelle afin d'assurer la transparence, sans pour autant impliquer de transfert effectif de fonds entre les budgets. Le « chargeback » va plus loin : il transfère des fonds réels de l'équipe utilisatrice vers l'équipe ou la fonction responsable de l'infrastructure partagée. Le « showback » favorise la prise de conscience ; le « chargeback » instaure la responsabilité financière.

Ces deux approches sont utiles, et de nombreuses organisations commencent par le « showback » avant de passer au « chargeback ». Le « showback » aide les équipes à comprendre les coûts liés à leur utilisation de l'IA avant que ceux-ci n'affectent leurs budgets, ce qui réduit les réticences et leur laisse le temps d'optimiser leurs habitudes de consommation. Le « chargeback » renforce ensuite ce changement de comportement en rendant ces coûts concrets.

Dans le cas spécifique des modèles de base, cette distinction est importante car l’infrastructure est généralement gérée de manière centralisée, souvent par une équipe de plateforme ou un service informatique, tandis que les utilisateurs sont des équipes produit ou des unités opérationnelles disposant de budgets distincts. Sans refacturation, l’équipe de plateforme prend en charge l’intégralité des coûts, quelle que soit l’intensité d’utilisation du modèle, ce qui dissuade les équipes utilisatrices d’exploiter le modèle de manière efficace. Avec la refacturation, chaque équipe a un intérêt financier direct à minimiser les appels d’inférence inutiles, à optimiser la conception des prompts et à éviter les tâches de réglage fin redondantes.

Le choix entre le « showback » et le « chargeback » relève en fin de compte d'une décision de gouvernance. Les organisations qui bénéficient d'une forte coordination interfonctionnelle et d'un système de responsabilisation des coûts bien établi ont tendance à adopter plus rapidement le « chargeback ». Celles qui en sont encore à instaurer la confiance entre les services financiers, informatiques et d'ingénierie considèrent souvent le « showback » comme une étape utile.

Quels sont les secteurs d'activité qui devraient prendre en charge le coût d'un modèle de base ?

Les unités opérationnelles qui utilisent activement le modèle de base devraient en supporter les coûts, proportionnellement à leur consommation. Si un modèle est utilisé exclusivement par une seule équipe, celle-ci devrait en assumer l'intégralité des coûts. Si plusieurs équipes partagent le modèle, les coûts devraient être répartis en fonction de l'utilisation, avec des frais généraux partagés pour l'infrastructure de base dont bénéficient tous les utilisateurs, quel que soit leur niveau de consommation.

Ce principe semble simple, mais il se complique lorsqu'un modèle de base est considéré comme une plateforme stratégique. Dans ce cas, la direction peut décider que le coût de l'infrastructure doit être traité comme une charge générale de l'entreprise plutôt que d'être refacturé aux équipes individuelles, car ce modèle apporte une valeur à l'échelle de l'organisation qu'il est difficile d'attribuer à une seule unité.

Un cadre pratique pour déterminer qui paie :

1. Identifier les consommateurs primaires en identifiant les équipes, les produits ou les applications qui génèrent le plus de trafic d'inférence.
2. Distinguer l'usage direct de l'usage indirect pour distinguer les équipes qui utilisent le modèle en production de celles qui le testent dans des environnements de développement.
3. Imputer les coûts variables aux consommateurs directs en fonction de la consommation mesurée.
4. Répartir les coûts d'infrastructure fixes pour l'ensemble des équipes disposant d'un accès, pondérées en fonction de leur part de capacité prévue ou réelle.
5. Réviser les affectations chaque trimestre à mesure que les habitudes d'utilisation évoluent au fil du temps.

Les équipes qui bénéficient indirectement du modèle, par exemple une équipe produit dont les clients utilisent une fonctionnalité basée sur l'IA développée par une autre équipe, ne sont généralement pas facturées directement. La valeur dont elles bénéficient est prise en compte via le produit, et non par le biais d'une répartition des coûts.

Comment faut-il traiter les coûts indirects et les frais généraux dans la tarification selon le modèle de la fondation ?

Les coûts indirects et généraux liés à un modèle de base, tels que le temps consacré à l'ingénierie de la plateforme, la surveillance de la sécurité, la gouvernance du modèle et les licences d'outils, doivent être regroupés et répartis entre toutes les équipes utilisatrices à l'aide d'une clé de répartition cohérente. Parmi les clés de répartition courantes, on peut citer la part de l'équipe dans le volume total d'inférences, le nombre d'applications connectées au modèle ou une répartition égale entre tous les utilisateurs enregistrés.

Les frais généraux sont souvent sous-estimés dans la tarification des modèles de base. Le coût de calcul direct lié à l’exécution de l’inférence est visible et mesurable, mais les coûts cachés liés à la maintenance de la plateforme, à la gestion des versions des modèles, à la garantie de la conformité et à l’assistance aux utilisateurs internes peuvent être considérables. Si ces coûts sont pris en charge de manière centralisée sans être répartis, ils deviennent invisibles pour les équipes utilisatrices, ce qui fausse le coût réel de l’IA et rend plus difficile la justification des investissements ou l’identification des inefficacités.

Une approche utile consiste à définir deux catégories de coûts. La première couvre les coûts variables directs, que vous imputez en fonction de l'utilisation. La seconde couvre les coûts partagés de la plateforme, que vous répartissez selon une méthode fixe convenue au préalable avec toutes les parties prenantes. La publication transparente de ces deux catégories de coûts, avant même la mise en place d’un système complet de refacturation, aide les équipes à comprendre le coût total lié à l’utilisation du modèle partagé et prépare l’organisation à une responsabilisation plus rigoureuse au fil du temps.

Cela reflète le degré de maturité gestion des coûts du cloud Les programmes gèrent les services partagés selon le principe suivant : la visibilité d'abord, l'allocation ensuite, la responsabilité enfin.

Quels outils et cadres permettent de répartir les coûts liés aux modèles de base ?

Parmi les outils et les cadres permettant la répartition des coûts liés aux modèles de base, on peut citer les cadres FinOps, les taxonomies de gestion technologique des activités (TBM), les plateformes de gestion des coûts du cloud et les outils d'observabilité de l'IA. Ensemble, ils fournissent les moyens de mesure, la structure de gouvernance et la couche de reporting nécessaires pour suivre, répartir et gérer les coûts liés à l'infrastructure d'IA.

Cadres FinOps et TBM

Le cadre FinOps, initialement développé pour la gestion des coûts du cloud, s'applique directement à l'infrastructure d'IA. Il définit les axes « informer », « optimiser » et « exploiter », qui se traduisent par : rendre visibles les coûts liés à l'IA, identifier le gaspillage ou les inefficacités, et mettre en place un rythme de gouvernance régulier. Le TBM ajoute une dimension stratégique en reliant les coûts de l’infrastructure d’IA aux services, aux produits et aux résultats commerciaux qu’elle soutient, ce qui s’avère utile lorsque vous devez justifier un investissement dans un modèle de base auprès de la direction ou du conseil d’administration.

Options d'outillage

En matière d'outils, les organisations combinent généralement plusieurs niveaux :

• Plateformes de gestion des coûts du cloud Telles qu’Apptio Cloudability, ces solutions permettent de suivre les coûts de calcul et de stockage au niveau des ressources et facilitent la répartition des ressources entre les équipes grâce à un système de balisage.
• Outils d'observabilité de l'IA l'utilisation des modèles d'instruments au niveau des appels, en enregistrant le nombre de tokens, la latence et les identifiants des utilisateurs ou des équipes qui servent à la répartition des coûts.
• Tableaux de bord internes de « showback » ou de « chargeback » agréger les données issues des outils de facturation et de surveillance du cloud pour les intégrer dans des rapports de coûts au niveau des équipes.
• Plates-formes TBM telles qu’Apptio Standard, qui traduisent les coûts liés à l’infrastructure d’IA en une taxonomie adaptée au monde de l’entreprise, permettant ainsi de produire des rapports sur le rapport coût-valeur à l’intention des décideurs de haut niveau.

Aucun outil ne permet à lui seul d'avoir une vue d'ensemble. Pour que la répartition des coûts du modèle de base soit efficace, il faut associer les données de facturation du cloud, les outils de mesure de l'utilisation et un processus de gouvernance garantissant que les équipes examinent régulièrement ces informations et agissent en conséquence. L'utilité de la technologie dépend entièrement du processus organisationnel qui la sous-tend.

Comment nous vous aidons à répartir les coûts liés aux modèles de base

Nous aidons les organisations à passer d'un suivi ponctuel des coûts liés à l'IA à un modèle d'allocation structuré et encadré, qui responsabilise les équipes et établit un lien entre les dépenses et la valeur ajoutée pour l'entreprise. Notre approche associe les pratiques FinOps aux cadres TBM afin de vous fournir à la fois les détails opérationnels et le contexte stratégique dont vous avez besoin.

Plus précisément, nous vous accompagnons dans les domaines suivants :

• Évaluation FinOps pour évaluer votre niveau actuel de maturité en matière de répartition des coûts partagés liés à l'IA et au cloud, et identifier les lacunes en matière de responsabilité.
• Conception de la répartition des coûts pour définir les clés de répartition, les centres de coûts et les mécanismes de refacturation ou de répercussion des coûts adaptés à votre environnement de modèle de base.
• Mise en œuvre de l'outillage en utilisant des plateformes telles qu’Apptio Cloudability et Apptio Standard pour instrumenter l’utilisation, automatiser la création de rapports et mettre en évidence des informations exploitables pour la prise de décision.
• Intégration entre TBM et FinOps pour établir un lien entre les coûts liés à l'infrastructure d'IA et les services ainsi que les résultats commerciaux qu'elle soutient, ce qui permet d'engager des discussions constructives avec les services financiers et la direction.
• Conception du système de gouvernance mettre en place un rythme régulier permettant aux équipes financières, informatiques et d'ingénierie d'examiner ensemble les coûts liés à l'IA et de prendre des décisions éclairées.

Si vous êtes prêt à mettre en place une gestion structurée et responsable des coûts liés à l'IA, contactez-nous et nous vous indiquerons par où commencer.