Cloudflare AI Gateway ajoute la tarification des jetons de cache à la comptabilité analytique personnalisée

Cloudflare a ajouté des tarifs de jetons de lecture et d'écriture de cache à la comptabilité analytique personnalisée d'AI Gateway, un petit élément du journal des modifications ayant des conséquences de facturation importantes pour les équipes qui revendent, acheminent ou rapprochent l'utilisation de modèles entre fournisseurs.

La mise à jour du 9 septembre signifie que les développeurs peuvent désormais transmettre les valeurs per_cache_read_token et per_cache_write_token dans le cf-aig-custom-cost en-tête. Lorsque l'un ou l'autre des taux spécifiques au cache est présent, Cloudflare indique qu'AI Gateway active la tarification des jetons de cache et tient compte des différences entre les fournisseurs afin que la même utilisation du cache ne soit pas comptée deux fois.

Cela semble étroit. Ce n'est pas. La tarification du cache est devenue l'une des parties les plus difficiles de la facturation unifiée des API d'IA, d'autant plus que les fournisseurs utilisent des noms, des unités et des règles de facturation différents pour le contexte réutilisé. Traiter chaque jeton mis en cache comme un jeton d'entrée normal peut être simple, mais cela peut être suffisamment erroné pour effacer la marge du revendeur ou induire les clients en erreur sur les charges de travail réellement coûteuses.

Ce qui a changé

AI Gateway permettait déjà d'attacher des données de coûts personnalisées aux demandes, donnant ainsi aux équipes un moyen de représenter les tarifs négociés ou les barèmes de prix internes au lieu de s'appuyer uniquement sur les tarifs des fournisseurs publics. Le nouveau changement étend ce mécanisme aux catégories de jetons spécifiques au cache.

En pratique, un opérateur de passerelle peut désormais indiquer à Cloudflare non seulement ce que coûte un jeton d'entrée ou de sortie, mais aussi ce que coûte une lecture ou une écriture du cache. Cette distinction est importante car les fournisseurs considèrent de plus en plus la mise en cache rapide comme sa propre couche économique. Une écriture dans le cache peut coûter plus cher qu'une lecture dans le cache. Une lecture du cache peut être considérablement moins chère qu'une nouvelle entrée. Certains fournisseurs peuvent exposer différemment la création et la récupération du cache dans les enregistrements d'utilisation.

La remarque de Cloudflare selon laquelle il gère les différences entre les fournisseurs pour éviter la double comptabilisation est également importante. Les champs de cache ne sont pas toujours clairement séparés des totaux des jetons d'entrée. Si un système de facturation ajoute naïvement des jetons de cache en plus de l'utilisation des entrées signalée par le fournisseur, il peut surfacturer les clients ou gonfler les coûts internes. S'il ignore les champs de cache, il peut sous-estimer le coût des applications à contexte long qui créent fréquemment des entrées de cache.

Pourquoi la comptabilité du cache est désormais importante

La mise en cache des invites était autrefois un détail d'optimisation. Pour de nombreuses charges de travail de production, cela fait désormais partie de l'architecture de prix.

Les invites système longues, le contexte de récupération augmentée, les référentiels d'agents de codage, les packs de documents juridiques et les bases de connaissances de support bénéficient tous de la réutilisation du contexte. Plus un système envoie de contexte répété, plus la tarification du cache modifie l’économie réelle de l’unité. Deux requêtes avec un nombre de jetons similaire peuvent avoir des coûts très différents si l'une écrit une entrée de cache et qu'une autre la lit.

Cela fait de la visibilité du cache un problème financier, pas seulement un problème d'ingénierie. Une équipe qui utilise des agents internes peut avoir besoin de savoir si un nouveau flux de travail est coûteux, car il génère trop de nouvelles invites, manque le cache ou écrit trop souvent de gros blocs de cache. Un revendeur devra peut-être montrer aux clients pourquoi l’utilisation facturée d’une application est inférieure à celle prévue, même si la taille apparente de l’invite est importante. Un fournisseur de passerelle peut avoir besoin de conserver les champs de cache dans les journaux, les analyses et les enregistrements du grand livre afin que le rapprochement de fin de mois corresponde aux factures du fournisseur.

C'est également là que l'analyse des coûts de l'API IA devient plus exigeante. Le coût global de la demande ne suffit plus. Les équipes doivent voir séparément le comportement des entrées, des sorties, de l'écriture et de la lecture du cache, puis connecter ces catégories aux clés API, aux clients, aux modèles et aux itinéraires.

Qui est concerné

Le public immédiat est constitué des utilisateurs de Cloudflare AI Gateway qui s'appuient sur des coûts personnalisés plutôt que sur les tarifs publics par défaut. Cela inclut les entreprises avec des tarifs de modèle négociés, les plates-formes qui balisent l'utilisation des fournisseurs pour les clients et les équipes qui utilisent Cloudflare comme plan de contrôle partagé entre plusieurs fournisseurs de modèles.

Les revendeurs sont particulièrement exposés. Si un revendeur facture ses clients en utilisant un modèle de jeton simplifié tout en payant les fournisseurs selon une tarification tenant compte du cache, la différence peut s'accumuler tranquillement. Une sous-charge des écritures du cache ou une surcharge des lectures du cache peuvent ne pas apparaître dans une seule requête, mais cela peut avoir une incidence sur les sessions d'agent, le traitement par lots ou les charges de travail de récupération de gros volumes.

Les développeurs qui créent des couches de passerelle compatibles OpenAI sont affectés même s'ils n'utilisent pas directement Cloudflare. Ce changement reflète une orientation plus large du marché : les surfaces de facturation des fournisseurs deviennent plus granulaires, tandis que les clients attendent toujours une facture claire et des rapports d'utilisation prévisibles.Des produits tels que Model Gate doivent traiter les champs de jetons de cache comme des données de premier ordre s'ils souhaitent des rapports précis, des limites d'utilisation et une analyse des marges sur plusieurs fournisseurs.

Conséquences pratiques

Les équipes Gateway doivent examiner la façon dont leurs journaux de demandes, leurs calculateurs de coûts et leurs factures représentent l'activité du cache. Si les lectures et écritures du cache sont aplaties en jetons d'invite ordinaires, l'analyse peut sembler plus simple que la facture sous-jacente. Si les enregistrements d'utilisation du fournisseur contiennent des champs de cache supprimés lors de l'ingestion, le rapprochement ultérieur sera difficile.

Les moteurs de tarification doivent également prendre en charge plusieurs tarifs par direction. L’ancienne répartition entrées/sorties n’est plus suffisante pour une comptabilité modèle avancée. Un grand livre modèle crédible a désormais besoin de place pour de nouveaux jetons d'entrée, des jetons de sortie, des écritures de cache, des lectures de cache et éventuellement des variantes spécifiques au fournisseur de ces catégories.

Les tableaux de bord destinés aux clients doivent exposer ces distinctions avec soin. La plupart des utilisateurs ne souhaitent pas lire la télémétrie brute du fournisseur, mais ils doivent comprendre pourquoi les coûts changent lorsqu'une application commence à réutiliser le contexte plus efficacement. La meilleure interface peut être une ventilation des coûts qui montre les économies de cache et les coûts de création de cache sans obliger les clients à apprendre la terminologie de chaque fournisseur.

Il existe également des implications opérationnelles pour les alertes et les limites. Une limite budgétaire client basée uniquement sur le nombre total de jetons peut ne pas réussir à capturer une charge de travail qui écrit des entrées de cache coûteuses. Une alerte de marge basée uniquement sur le nombre de demandes peut manquer une inadéquation de prix du fournisseur. Pour les équipes vendant l'accès via des clés par client, la comptabilité basée sur le cache doit être liée aux mêmes identifiants de client, de projet ou d'application utilisés pour le contrôle des dépenses.

Ce qui reste ouvert

Le journal des modifications établit la prise en charge des tarifs personnalisés de lecture et d'écriture du cache, mais il ne règle pas toutes les questions de mise en œuvre pour les opérateurs de passerelle. Les équipes doivent encore tester comment leurs fournisseurs spécifiques signalent l'utilisation du cache, comment les coûts calculés par Cloudflare apparaissent dans les journaux et les exportations, et comment les factures existantes doivent être comparées aux nouveaux champs de coûts personnalisés.

La direction générale est cependant claire. La facturation de la passerelle AI passe d'un simple compteur à jetons à un registre d'utilisation détaillé. La tarification du cache fait désormais partie de ce grand livre. Les équipes qui préservent les détails bénéficieront d’un rapprochement plus propre et d’une meilleure analyse client. Les équipes qui le suppriment risquent de ne pas remarquer le problème jusqu'à ce que la facture de leur fournisseur et celle de leur client cessent de raconter la même histoire.