Pourquoi votre tableau de bord d'utilisation LLM ne correspond pas à la facture du fournisseur

Si votre tableau de bord d'utilisation LLM, votre console de fournisseur, votre exportation de facturation cloud et votre facture client affichent des chiffres différents, ne commencez pas par supposer qu'un système est erroné. Commencez par demander quel numéro fait autorité dans quel but.

Un tableau de bord de passerelle est généralement une vue opérationnelle : rapide, au niveau des requêtes et utile pour les alertes. Une facture fournisseur est une vue de facturation réglée : plus lente, agrégée et ajustée selon les règles de facturation du fournisseur. Les exportations de facturation cloud ajoutent une couche supplémentaire, en particulier pour les services de modèle géré, dans lesquels les données de facturation peuvent être regroupées par projet, SKU, région, type d'utilisation ou mois de facturation plutôt que par API requête.

Le problème pratique n'est pas seulement de "trouver le vrai nombre". Il s'agit de classer l'inadéquation, de conserver suffisamment de preuves pour l'expliquer et de décider quand un chiffre est suffisant pour les tableaux de bord, les rapports financiers ou la facturation client.

Utilisez deux registres, pas un seul numéro

L'erreur la plus courante consiste à essayer de faire en sorte qu'une estimation de passerelle en temps réel se comporte comme une facture finale. Il s'agit de différents enregistrements avec différentes tâches.

Grand livre d'utilisation opérationnelle

Le grand livre opérationnel est alimenté au moment de la demande par votre passerelle, SDK wrapper, proxy ou instrumentation d'application. Il doit être optimisé pour la vitesse et l’attribution. Il répond à des questions telles que :

• Quel locataire, équipe, API clé, projet ou workflow a créé cette requête ?
• Quel modèle s'appelait ?
• Combien de jetons d'entrée, de sortie, mis en cache ou de raisonnement ont été observés ou estimés ?
• La requête a-t-elle été réessayée, annulée, diffusée en continu, regroupée ou a-t-elle échoué ?
• Quel budget ou limite interne doit être facturé immédiatement ?

Ce grand livre est essentiel pour la gestion des coûts LLM, mais il n'est pas toujours précis par rapport à la facture. Il peut utiliser des jetons estimés avant que le fournisseur ne renvoie l'utilisation finale. Il peut appliquer un tableau de prix périmé. Il peut compter une tentative de demande que le fournisseur ne facture pas, ou manquer une nouvelle tentative que le fournisseur facture.

Grand livre des coûts réglés

Le grand livre des coûts réglés est alimenté à partir des API de coûts du fournisseur, des rapports d'utilisation du fournisseur ou des exportations de facturation cloud une fois que le fournisseur a regroupé et classé les frais. Il doit être optimisé pour les rapports financiers. Il répond à des questions telles que :

• Quel coût le fournisseur a-t-il signalé pour cette journée, ce modèle, ce projet, cette clé, cet élément de campagne ou ce type d'utilisation ?
• Quelles devises et quelle période de facturation s'appliquent ?
• Y a-t-il eu des corrections, des crédits ou des ajustements tardifs ?
• Quels coûts peuvent être imputés aux locataires en toute confiance ?
• Quels coûts restent non attribués car les métadonnées manquaient ?

Recommandations : utilisez le grand livre opérationnel pour les alertes, les réservations budgétaires, le débogage et les tableaux de bord en temps quasi réel. Utilisez le grand livre des coûts réglés pour la clôture financière, les factures clients, l'analyse de la marge et la rétrofacturation finale. Étiquetez tout numéro de pré-règlement comme étant estimé ou provisoire.

Classez l'incompatibilité avant de déboguer

La plupart des écarts de facturation LLM se répartissent en cinq classes. Classer l'écart en premier empêche les équipes de rechercher des détails de tokenisation lorsque le véritable problème est le calendrier de facturation, ou de rechercher des exportations de factures dans le cloud lorsque le véritable problème réside dans l'absence de métadonnées de locataire.

1. Dérive de la fenêtre temporelle

Cela se produit lorsque deux systèmes regroupent la même utilisation sur des périodes différentes.

Les causes courantes incluent les dates UTC par rapport aux dates locales, les jours de facturation du fournisseur qui ne correspondent pas aux jours du tableau de bord, les dates d'achèvement des tâches par lots qui diffèrent des dates de soumission, les demandes de streaming qui dépassent une limite de date et les champs de mois de facture cloud qui diffèrent des horodatages d'utilisation. Les exportations de facturation cloud peuvent également inclure des corrections ou une utilisation monétisée tardivement au cours d'une période de facturation ultérieure.

Étapes de débogage :

1. Convertissez chaque horodatage en UTC avant la comparaison.
2. Comparez séparément la date d'utilisation, l'heure de début de la demande, l'heure de fin de la demande, le temps de traitement du fournisseur, l'heure d'achèvement du lot et le mois de facturation.
3. Rapprochez d'abord les périodes fermées. Évitez de comparer le tableau de bord d'aujourd'hui à un rapport de fournisseur en cours de stabilisation.
4. Pour les charges de travail par lots, comparez la date de soumission de la demande et la date d'achèvement du lot.

Recommandation : définissez un calendrier de reporting qui sépare le « jour d'utilisation », le « jour de règlement » et le « mois de facturation ». Ne regroupez pas ces champs dans une seule colonne de date.

2. Dérive dimensionnelle

Cela se produit lorsque le tableau de bord et la facture regroupent des éléments différents.

Votre passerelle peut être regroupée par locataire, équipe, API clé, environnement ou workflow. Un coût de fournisseur API peut être regroupé par projet, utilisateur, clé API, modèle, élément de campagne ou source en fonction du fournisseur et du point de terminaison. Une exportation de facturation cloud peut être regroupée par projet, SKU, service, emplacement, type d'utilisation, étiquettes ou mois de facturation. Pour les services de modèles gérés, l'attribution d'invites par demande peut ne pas exister du tout dans l'exportation de facture.

Étapes de débogage :

1. Notez les dimensions de regroupement exactes utilisées par chaque système.
2. Normalisez les ID de modèle, les régions, les niveaux de service, les types de jetons, les éléments de campagne et les API sources avant de comparer les totaux.
3. Vérifiez si les projets de fournisseur, les espaces de travail, les clés API et les étiquettes de projet cloud correspondent clairement à vos locataires internes.
4. Identifiez explicitement les dépenses non attribuées au lieu de les insérer de force dans un compartiment de locataire.

Recommandation : traitez l'attribution des locataires comme un champ de facturation de premier ordre, et non comme un filtre de tableau de bord. Pour une LLM API attribution des coûts fiable, capturez les identifiants des locataires au moment de la demande et conservez les identifiants côté fournisseur nécessaires pour vous inscrire ultérieurement.

3. Dérive des prix

Cela se produit lorsque l'estimation opérationnelle utilise une logique de tarification différente de celle de la facture réglée par le fournisseur.

Les causes courantes incluent la tarification des jetons mis en cache, les frais d'écriture du cache par rapport aux frais d'accès au cache, les taux de jetons d'entrée et de sortie séparés, les alias de modèle qui ont été migrés vers un modèle tarifaire plus récent, les niveaux de service, la géographie des inférences, les remises par lots, les éléments de campagne de recherche de fichiers ou de recherche sur le Web, les unités d'image ou audio et la conversion de devises. Un tableau de bord qui multiplie le nombre total de jetons par un prix pondéré dérivera dès que la facture du fournisseur contiendra plusieurs types de jetons ou éléments de ligne.

Étapes de débogage :

1. Décomposez les coûts en éléments de campagne avant de comparer les totaux.
2. Séparez les jetons d'entrée, les jetons de sortie, les écritures de cache, les accès au cache, les jetons de raisonnement et les unités non-jetons lorsque les fournisseurs les signalent.
3. Versionnez votre tableau de prix interne et stockez la version de prix utilisée pour chaque estimation.
4. Vérifiez si le fournisseur signale les alias de modèle, les instantanés de modèle ou les éléments de gamme de produits différemment de votre passerelle.
5. Comparez la devise de facturation du fournisseur avant d'appliquer votre propre conversion de devise.

Faits : les surfaces de reporting des fournisseurs peuvent exposer des coûts regroupés et des dimensions de regroupement telles que le projet, l'utilisateur, la clé API, le modèle, l'élément de campagne, l'espace de travail, le type de jeton, la géographie, le niveau de service ou la devise, en fonction du fournisseur et de l'environnement. Les exportations vers le cloud peuvent exposer des étiquettes, des champs de ressources, des horodatages d'utilisation, le mois de facturation, les crédits et les corrections.

4. Demander une dérive du cycle de vie

Cela se produit lorsque les systèmes ne sont pas d'accord sur ce qui constitue une opération facturable.

Les tentatives sont généralement à l'origine du problème. Si une application réessaye après un délai d'attente, le tableau de bord de votre produit peut traiter la réponse finale réussie comme une action utilisateur, tandis que le fournisseur facture deux ou trois appels de modèle. Le routage de secours peut créer le même problème lorsqu'un appel principal ayant échoué et un appel de secours réussi sont affichés comme un seul résultat d'application.

Le streaming ajoute une autre source de dérive. Un utilisateur peut annuler un flux après avoir reçu une sortie partielle. Le fournisseur peut signaler les jetons générés jusqu'à annulation, tandis que votre application n'enregistre qu'une demande ayant échoué ou abandonnée. Les tâches par lots créent un cycle de vie différent : la soumission, la validation, le traitement, l'échec partiel, la récupération des résultats et la facturation peuvent ne pas partager le même horodatage.

Étapes de débogage :

1. Attribuez un ID de requête interne stable à l'action de l'utilisateur.
2. Attribuez des ID de tentative distincts pour chaque appel, nouvelle tentative et solution de secours du fournisseur.
3. Stockez les ID de réponse du fournisseur et les ID de demande lorsqu'ils sont disponibles.
4. Enregistrer l'état du flux : terminé, client annulé, serveur arrêté, délai d'attente ou perte de réseau.
5. Pour les tâches par lots, stockez l'ID de la tâche par lots, l'ID du fichier d'entrée le cas échéant, l'heure de soumission, l'heure d'achèvement et l'état par élément si disponible.

Recommandation : comparez les factures des fournisseurs aux tentatives des fournisseurs, et non aux actions des utilisateurs au niveau du produit. Ensuite, reportez les tentatives aux actions des utilisateurs pour l'analyse des produits.

5. Dérive fournisseur-règlement

Cela se produit lorsque les données de facturation côté fournisseur changent alors que votre tableau de bord a déjà affiché un numéro.

Les API de coût des fournisseurs et les exportations de facturation cloud sont plus proches de la vérité en matière de facturation, mais elles peuvent être retardées, regroupées ou ajustées ultérieurement. Les crédits, les corrections, l'utilisation tardive, les modifications mensuelles de la facture et la reclassification des produits peuvent tous faire évoluer le chiffre final. Ceci est particulièrement important lorsque le service financier compare une capture d'écran du tableau de bord du premier jour du mois avec une exportation de facture générée plus tard.

Étapes de débogage :

1. Suivez le moment où chaque tranche de coûts du fournisseur a été récupérée.
2. Stockez des instantanés immuables des importations à coût réglé.
3. Détecter les modifications entre les importations pour le même fournisseur, la même période et les mêmes dimensions de regroupement.
4. Conservez les ajustements tardifs sous forme de lignes d'ajustement au lieu de réécrire l'historique en silence.
5. Définissez un processus de clôture : par exemple, conservez une période provisoire jusqu'à ce que les données du fournisseur se stabilisent et que les contrôles d'écart soient réussis.

Recommandation : les factures des clients doivent utiliser des périodes réglées ou porter une étiquette provisoire explicite. Les tableaux de bord peuvent tolérer de légères variations dans les périodes d'ouverture ; la facturation des clients ne doit pas cacher une incertitude.

Le schéma de preuves minimum

La qualité d'un processus de rapprochement dépend de la qualité des preuves conservées avant que l'incohérence n'apparaisse. Au minimum, capturez des métadonnées qui vous permettent de passer d'un enregistrement opérationnel à un enregistrement de facturation du fournisseur sans stocker de contenu d'invite sensible.

Champs recommandés au niveau de la requête :

• Identifiants internes : internal_request_id, attempt_id, parent_request_id, tenant_id, team_id, project_id, environnement, workflow_id.
• Identifiants d'accès : gateway_api_key_id, provider_api_key_id si disponible, compte de service, user_id le cas échéant.
• Identifiants du fournisseur : fournisseur, provider_project_id, provider_workspace_id, provider_response_id, provider_request_id, cloud_account_id, cloud_project_id.
• Modèle et routage : requested_model, resolved_model, model_version, route_policy, fallback_from, fallback_to.
• Utilisation : input_tokens, output_tokens, cached_input_tokens, cache_write_tokens, reasoning_tokens, token_unit, non_token_quantity, quantity_unit.
• Estimation du prix : estimated_cost, devise, price_table_version, estimate_source, budget_reservation_id.
• Cycle de vie : état, error_class, retry_number, stream_started, stream_completed, stream_termination_status, batch_job_id, batch_item_id.
• Moment : request_started_at, request_completed_at, provider_reported_at, batch_submitted_at, batch_completed_at, usage_date_utc.

Ne stockez pas les invites ou les réponses brutes uniquement pour rapprocher la facturation. Les métadonnées des requêtes, le nombre de jetons, les identifiants de fournisseur et les dimensions normalisées suffisent généralement. Si les journaux d'appel peuvent contenir du contenu sensible, supprimez ou désactivez la capture de la charge utile des invites et des réponses tout en conservant les champs d'utilisation et d'identité.

Comparez au grain partagé fiable le plus bas

La réconciliation au niveau de la demande semble attrayante, mais elle n'est pas toujours possible. Le bon grain de comparaison dépend de ce que le fournisseur expose.

API de coût du fournisseur

Là où les points de terminaison des coûts du fournisseur exposent des compartiments quotidiens et des dimensions de regroupement telles que le projet, l'utilisateur, la clé API, le modèle, l'élément de campagne, l'espace de travail ou le type de jeton, commencez par là. Comparez les tranches de coûts réglés quotidiennement aux cumuls quotidiens de votre passerelle en utilisant les mêmes dimensions. Ne comparez pas un tableau de bord au niveau du locataire directement au total d'une organisation fournisseur à moins que la couverture des locataires ne soit complète.

Exemple de grain de comparaison :

• date_utc
• fournisseur
• provider_project_id ou workspace_id
• api_key_id si disponible
• modèle ou resolved_model
• line_item ou token_type
• devise

Services modèles facturés dans le cloud

Pour les services facturés dans le cloud, l'exportation de la facture peut ne pas inclure d'identifiants par demande. Dans ce cas, joignez les journaux d'appel à l'exportation de coût et d'utilisation selon une granularité plus grossière telle que le jour, le modèle, la région et le type d'utilisation. Utilisez les journaux au niveau des requêtes pour l'allocation des locataires, mais utilisez l'exportation de facturation cloud pour les totaux des factures.

Exemple de grain de comparaison :

• usage_date_utc
• cloud_account_id ou billing_account_id
• cloud_project_id
• région
• model_id
• usage_type ou SKU
• invoice_month

Fait : La documentation AWS Bedrock décrit l'utilisation des champs du rapport de coût et d'utilisation tels que le modèle, le type de jeton, le niveau de service et l'inférence interrégionale dans les données de type d'utilisation, tout en utilisant les journaux d'appel de modèle pour l'identité de la demande, le nombre de jetons, l'ID de modèle, la région et l'ID de demande. La documentation recommande de joindre les journaux d'appel avec CUR au niveau du modèle, du type d'utilisation et du jour pour obtenir des totaux précis par rapport à la facture.

Un workflow de réconciliation pratique

Utilisez ce workflow lorsque le service financier signale une incohérence de facture.

Étape 1 : Geler la comparaison

Choisissez un fournisseur, une période de facturation, une devise et un grain de comparaison. Exportez simultanément le numéro du tableau de bord, le rapport sur les coûts du fournisseur et la facturation cloud. Enregistrez les horodatages d’exportation. De nombreuses équipes perdent des heures à comparer des cibles en mouvement.

Étape 2 : Séparez les dollars estimés et réglés

Divisez les lignes en estimated_cost et settled_cost. Le coût estimé provient du tableau des prix de votre passerelle. Le coût réglé provient des données de facturation du fournisseur ou du cloud. N'écrasez jamais l'un par l'autre ; stockez les deux et suivez la variance.

Étape 3 : Normaliser les dimensions

Créez une table de mappage pour le fournisseur, le modèle, le modèle résolu, l'élément de campagne, le type de jeton, le niveau de service, la région, le projet, l'espace de travail, la clé API et le locataire. Incluez un compartiment « inconnu » ou « non attribué ». Une allocation forcée est pire qu'un écart explicite car elle masque le correctif opérationnel.

Étape 4 : Réconcilier les totaux de haut en bas

Commencez par le total de l'organisation du fournisseur par rapport au total de la facture du fournisseur. Ensuite, comparez par jour. Comparez ensuite par modèle et par élément de campagne. Ce n'est qu'après cette réussite que vous pourrez comparer l'allocation de locataire ou de clé API. Cet ordre vous indique si le problème concerne la tarification globale, la dérive temporelle ou l'attribution.

Étape 5 : Enquêter sur la variance par classe

Utilisez les cinq classes comme liste de contrôle :

• Dérivation de la fenêtre temporelle : non-concordance UTC, regroupement de dates locales, date d'achèvement du lot, mois de facturation, utilisation tardive.
• Dérive des dimensions : inadéquation projet/espace de travail, clé API manquante, modèle non mappé, étiquette de locataire manquante.
• Dérive des prix : jetons de cache, niveau de service, région, tarification par lots, éléments de campagne sans jetons, tableau de prix obsolète.
• Dérive du cycle de vie des requêtes : tentatives, replis, annulations de streaming, échecs partiels de lots, délais d'attente.
• Dérive fournisseur-règlement : crédits, corrections, tranches retardées, exportations de coûts modifiés.

Étape 6 : Appliquer des seuils de variance

Différents cas d'utilisation nécessitent des tolérances différentes. Un tableau de bord d'ingénierie peut tolérer un léger écart pour les périodes ouvertes s'il est clairement marqué comme en attente. Un système d’application du budget peut nécessiter des estimations prudentes pour éviter les dépenses excessives. Une facture client doit utiliser des coûts réglés ou une politique d'allocation documentée.

Recommandation : définissez des seuils par cas d'utilisation, et non par fournisseur. Par exemple :

• Tableau de bord opérationnel : autorise de légères variations pendant la période d'ouverture et affiche l'état en attente.
• Alertes budgétaires : utilisez des estimations prudentes et rapprochez-les plus tard.
• Refacturation interne : nécessite des compartiments de fournisseur réglés ainsi que des contrôles de couverture d'attribution.
• Facture client : nécessite une période de clôture, une importation avec frais réglés, un écart inférieur au seuil et aucune dépense importante non attribuée.

Modèle de mise en œuvre : tables de rapprochement

Un simple schéma suffit souvent. Vous avez besoin de tableaux distincts pour les tentatives opérationnelles, les catégories de coûts des fournisseurs, les cumuls normalisés et les résultats des écarts.

operational_attempts
- attempt_id
- internal_request_id
- tenant_id
- provider
- provider_project_id
- provider_workspace_id
- provider_api_key_id
- model_requested
- model_resolved
- region
- input_tokens
- output_tokens
- cached_input_tokens
- cache_write_tokens
- status
- retry_number
- stream_termination_status
- batch_job_id
- estimated_cost
- currency
- price_table_version
- usage_date_utc

provider_cost_buckets
- provider
- bucket_date_utc
- provider_project_id
- provider_workspace_id
- provider_api_key_id
- model
- line_item
- token_type
- service_tier
- region
- quantity
- quantity_unit
- settled_cost
- currency
- invoice_month
- imported_at

reconciliation_results
- period_start
- period_end
- grain_key
- estimated_cost
- settled_cost
- absolute_variance
- percent_variance
- variance_class
- status
- notes
- checked_at

Le choix de conception important consiste à préserver à la fois le coût estimé et le coût réglé. Une fois les données du fournisseur arrivées, vous pouvez calculer l'écart sans détruire l'enregistrement opérationnel d'origine qui expliquait les alertes et les décisions budgétaires à ce moment-là.

Corrections courantes après la première réconciliation

Le premier rapprochement révèle généralement des lacunes opérationnelles. Les correctifs sont simples, mais ils nécessitent une appropriation par l'ensemble de la plateforme et du secteur financier.

• Métadonnées de locataire manquantes : nécessitent tenant_id, team_id ou customer_id à la limite de la passerelle. Rejeter ou mettre en quarantaine les demandes de production sans métadonnées d'attribution.
• Tableaux de prix obsolètes : version des prix, suivi des dates d'entrée en vigueur et alerte lorsque les catalogues de modèles de fournisseurs ou les pages de tarification changent.
• Réessayez le surdénombrement ou le sous-dénombrement : séparez les ID de demande de produit des ID de tentative du fournisseur.
• Écarts d'annulation du streaming : enregistre l'utilisation partielle lorsque le fournisseur la renvoie et enregistre l'état de résiliation même lorsque le client se déconnecte.
• Ambigüité des lots : stocke les ID de tâche et compare-les par date d'achèvement ainsi que par date de soumission.
• Incohérence des factures Cloud : joignez les journaux d'appel aux exportations de facturation par jour, modèle, région et type d'utilisation au lieu d'attendre des lignes de facture par demande.
• Mouvement tardif inexpliqué : importations de coûts du fournisseur d'instantanés et enregistrements de lignes d'ajustement pour les crédits ou les corrections en retard.

Faits, recommandations et prédictions

Faits : Les systèmes de facturation des fournisseurs et du cloud exposent différentes dimensions et niveaux de détail de facturation. Certaines API de fournisseur exposent des catégories de coûts quotidiens et des dimensions de regroupement telles que le projet, l'utilisateur, la clé API, le modèle, l'élément de campagne, l'espace de travail, le type de jeton, le niveau de service, la géographie et la devise en fonction du point de terminaison et de l'environnement. Les exportations de facturation cloud incluent généralement les étiquettes de projet ou de ressource, les horodatages, le mois de facture, les crédits, les corrections, les SKU, les emplacements et les types d'utilisation. Les services modèles facturés dans le cloud peuvent nécessiter des journaux d'appel pour l'attribution au niveau de la demande.

Recommandations : Tenez un registre d'utilisation opérationnelle et un registre des coûts réglés. Comparez au grain partagé le plus bas et fiable. Préservez les preuves au niveau de la demande sans stocker de charges utiles sensibles. Normalisez les dimensions avant de comparer. Utilisez les données de facturation du fournisseur réglé ou du cloud pour les factures. Traitez les dépenses non attribuées comme un problème de qualité des données, et non comme quelque chose à cacher avec une allocation mixte.

Prédictions : Le rapprochement des factures LLM deviendra plus important à mesure que les équipes utiliseront davantage d'invites mises en cache, de tâches par lots, de niveaux de service, d'itinéraires de secours et de services de modèles hébergés dans le cloud. Les API de facturation des fournisseurs s'amélioreront probablement, mais elles ne supprimeront pas le besoin de métadonnées internes des locataires, car les fournisseurs ne peuvent pas déduire la hiérarchie de vos clients, de votre équipe ou de votre flux de travail.

Conclusion

Lorsqu'un tableau de bord LLM ne correspond pas à la facture du fournisseur, la réponse est rarement un bug. Il s'agit généralement d'un décalage entre les estimations opérationnelles, les coûts réglés par le fournisseur, les dimensions de facturation cloud et les règles d'attribution internes.

La solution durable est un manuel de rapprochement : conservez des registres opérationnels et réglés séparés, classez les écarts par fenêtre temporelle, dimension, tarification, cycle de vie ou dérive de règlement, conservez les preuves au niveau de la demande et facturez uniquement à partir des périodes réglées après vérifications des écarts. Cela donne aux équipes d'ingénierie des contrôles rapides sans demander au service financier de faire confiance aux chiffres provisoires comme dollars finaux.

Lecture connexe

• rapprochement quotidien des grands livres de coûts LLM par équipe