AWS ajoute le suivi de la consommation dans les flux vocaux : 12 minutes d'audio, 720 unités

Dans un agent vocal, la conversation dure vingt minutes, mais le client reste en partie silencieux, écoute la réponse ou cherche son numéro de commande. Qu'est-ce qui figurera exactement sur la facture du modèle ? AWS a ajouté à SageMaker AI un mécanisme permettant aux éditeurs de modèles en streaming de transmettre la consommation réelle à AWS Marketplace au fil de la session. Si le produit compte les secondes d'audio traité, 12 minutes de cet audio se transforment en 720 unités facturables.

C'est une évolution utile pour les équipes qui vendent ou déploient de la reconnaissance et de la synthèse vocales via le Marketplace. Elle permet de lier le paiement de la partie logicielle à la consommation. Le coût de l'infrastructure SageMaker reste toutefois une ligne distincte : un endpoint actif continue de coûter de l'argent.

Pourquoi la réponse du serveur ne suffit pas

Dans une API classique, tout est relativement simple : on envoie une requête, on reçoit le résultat, et le serveur indique le volume d'utilisation dans un en-tête de réponse. À ce stade, le travail est terminé et la consommation est connue.

Dans une interface vocale, la connexion dure plus longtemps. Le client envoie le son en continu et reçoit la transcription ; la session peut durer une demi-minute ou une demi-heure. L'en-tête transmis à l'établissement de la connexion ne permet pas de signaler régulièrement la nouvelle consommation. Et une facturation horaire de la partie logicielle peut inclure des périodes où le modèle est disponible mais ne traite rien.

AWS a résolu le problème avec une seconde connexion WebSocket entre SageMaker et le serveur du modèle. La première transporte les données à traiter et les résultats ; la seconde, de petits messages de facturation. Un identifiant de requête commun relie les deux connexions à une même conversation.

C'est l'éditeur qui définit ce qu'est une unité facturable. Les messages utilisent le nom inference.count, mais cela n'oblige pas à compter chaque requête comme une unité : il peut s'agir, par exemple, de secondes d'audio. Les règles de comptage et le prix doivent correspondre à l'offre du Marketplace.

Comment compter la consommation pendant la conversation

Imaginons un service de transcription d'appels facturé à la seconde d'audio. Le serveur a accumulé 30 secondes de traitement supplémentaires et envoyé un message indiquant 30 unités utilisées. Puis il a traité 30 secondes de plus et en a signalé 30 autres. Chaque enregistrement contient l'incrément depuis le rapport précédent ; renvoyer le total cumulé gonflerait donc la consommation.

AWS recommande de signaler l'utilisation progressivement et d'envoyer le dernier enregistrement dès la fin de la session. Ainsi, en cas de coupure soudaine, moins d'audio traité reste non comptabilisé. Une connexion ouverte ne signifie pas à elle seule de l'audio facturable : cela dépend des règles de chaque produit.

Le canal est soumis à des limites : un message par seconde et par connexion, 512 octets au maximum et exactement un enregistrement par trame texte. Plusieurs unités accumulées peuvent être transmises en un seul enregistrement. Pour se protéger des doublons, un ClientToken est prévu : un doublon portant le même jeton au sein d'une même connexion est rejeté.

Le premier partenaire est Deepgram, qui utilise le mécanisme pour facturer la reconnaissance et la synthèse vocales. Dans son intégration, le serveur calcule la consommation automatiquement ; l'application cliente n'a besoin d'aucune configuration supplémentaire du comptage.

Où le comptage peut se perdre

Le principal choix de l'éditeur concerne le comportement en cas de défaillance du canal de facturation. Par défaut, le traitement continue même si ce canal ne s'est pas ouvert ou s'est interrompu. La conversation est préservée, mais la transmission de la consommation cesse. On peut rendre le canal obligatoire : sa perte arrête alors le traitement.

Cette décision doit tenir compte du produit. Pour un centre de contact, interrompre une conversation peut coûter plus cher que des secondes non comptabilisées. De plus, un canal obligatoire ne garantit pas un débit correct : les messages erronés peuvent quand même être rejetés. La livraison via TCP ne confirme pas non plus que la consommation a été portée en facture.

Avant la mise en production, AWS recommande un test avec un volume connu : transmettre 12 minutes d'audio comptabilisable, obtenir au total 720 unités et comparer les enregistrements du serveur aux rapports du vendeur et aux débits de l'acheteur. Il faut tester séparément les coupures et les messages incorrects. Conclusion pratique pour l'acheteur : clarifier la définition de l'unité et chiffrer l'infrastructure à part. Pour l'éditeur : intégrer le rapprochement des débits à la préparation de la version.