Claude Sonnet 5 : mesurer l’effet de son nouveau tokenizer avant de migrer

Ce qui change et ce que le nombre de tokens ne démontre pas

La documentation de migration d’Anthropic indique que Claude Sonnet 5 utilise un nouveau tokenizer. Pour un même texte d’entrée, le décompte peut être environ 30 % plus élevé qu’avec Claude Sonnet 4.6, même si l’augmentation exacte dépend du contenu. L’annonce du modèle présente cette variation sous la forme d’une fourchette approximative allant de 1,0 à 1,35 fois, elle aussi dépendante du type de texte. Ces deux descriptions donnent des indications sur le même changement ; elles ne garantissent pas que tous les prompts augmenteront dans les mêmes proportions.

La première conséquence est comptable : un texte qui produisait auparavant un certain nombre de tokens peut en enregistrer davantage avec Sonnet 5. La deuxième est opérationnelle : si une application utilise presque toute sa fenêtre de contexte, ce même contenu peut occuper une part plus importante du budget. Le guide avertit également qu’une valeur de max_tokens réglée pour Sonnet 4.6 peut tronquer une réponse équivalente lors du passage à Sonnet 5. Il ne suffit donc pas de remplacer l’identifiant du modèle en supposant que les mesures précédentes décrivent toujours le nouveau comportement.

Ce chiffre ne permet pas, à lui seul, de conclure que le coût augmentera dans les mêmes proportions, que toutes les entrées gagneront 30 % de tokens, que le modèle sera moins performant ou que la fenêtre de contexte maximale annoncée sera réduite. Le coût dépend des tarifs applicables, des tokens d’entrée et de sortie facturés, ainsi que du traitement éventuel du cache. L’utilité d’une réponse doit être évaluée séparément. Un nombre supérieur de tokens comptabilisés décrit une différence de représentation, pas la qualité du résultat.

La documentation consacrée aux nouveautés précise que Sonnet 5 prend en charge une fenêtre de contexte d’un million de tokens et un maximum de sortie de 128 000 tokens. Même si la limite nominale du contexte peut être supérieure à celle d’une configuration antérieure, la quantité de texte qui tient dans cette limite dépend de sa tokenisation. Il convient donc de distinguer la limite du modèle de la capacité réelle d’une application à y faire tenir ses documents, instructions, historiques et outils.

Que mesurer dans une intégration réelle

Une comparaison utile ne consiste pas à opposer uniquement deux décomptes de tokens d’entrée. Elle doit examiner ce qui se passe dans le budget complet d’une requête : instructions système, question, documents récupérés, historique, définitions des outils et réponse générée. Pour une tâche reposant sur un contexte long, l’augmentation du nombre de tokens des documents peut compter davantage que celle d’une question courte. Dans une application qui produit de longues réponses, il faut aussi vérifier les limites de génération et la valeur de max_tokens.

Le décompte de tokens est une mesure intermédiaire. Pour savoir si le changement touche le produit, il faut au minimum enregistrer les requêtes qui dépassent le budget prévu, les réponses tronquées, les erreurs de limite, les nouvelles tentatives, les réponses rejetées et les résultats acceptés. Il faut définir la notion de tâche acceptée avant le test : par exemple, une réponse qui satisfait les critères de validité, de format et de qualité fixés par l’équipe. Sans définition préalable, on risque de présenter comme une économie une exécution moins coûteuse qui n’a tout simplement pas accompli le travail demandé.

Le coût par tâche acceptée peut être calculé en divisant le coût total des exécutions incluses par le nombre de tâches qui satisfont le critère d’acceptation défini à l’avance. Le numérateur doit inclure les réponses échouées, les nouvelles tentatives et les générations rejetées qui ont entraîné une consommation facturable. Il faut aussi préciser comment le cache est comptabilisé, quel tarif a été appliqué et quel canal d’accès a été utilisé. Cette mesure n’est pas un tarif officiel : c’est une mesure opérationnelle proposée pour comparer une intégration.

Il faut également distinguer un prompt répété d’un prompt inédit. Si une partie du contexte est réutilisée au moyen du cache, le montant obtenu peut différer de celui d’une entrée traitée sans ce mécanisme. Les pages officielles consacrées aux tarifs décrivent les prix et les multiplicateurs associés au cache, mais l’équipe doit consulter les valeurs en vigueur pour son modèle, sa région et sa plateforme au moment de la mesure. Évitez d’utiliser dans une prévision actuelle un chiffre historique ou provenant d’une autre plateforme.

Constituer un corpus qui permette d’attribuer le changement

Le corpus d’évaluation doit représenter l’usage réel et rester figé pendant la comparaison. Un échantillon stratifié peut distinguer le français, les autres langues utilisées par le produit, le code, les documents longs, les textes courts et les contenus répétés. Cette stratification ne signifie pas que ces catégories évolueront toujours dans le même sens ; elle sert justement à repérer les variations selon les catégories. Si le produit traite des conversations, incluez des historiques représentatifs. S’il récupère des documents, conservez également les requêtes et les passages réellement transmis au modèle.

Enregistrez le texte exact de chaque entrée, sa composition, le décompte obtenu avec chaque modèle et le résultat de la tâche. Évitez de normaliser les espaces, de modifier les instructions ou de mettre à jour les documents entre les exécutions, sauf si cette transformation fait explicitement partie du test. Enregistrez aussi la configuration, la date et le canal d’accès. Ainsi, si les décomptes changent, vous pourrez examiner la différence au lieu de l’attribuer vaguement à la migration.

La qualité doit être évaluée à l’aide de critères identiques et d’un examen cohérent. Dans la mesure du possible, faites évaluer les résultats sans révéler aux personnes chargées de la révision quel modèle les a produits. L’objectif n’est pas de proclamer qu’une version est globalement supérieure, mais de vérifier si le remplacement préserve les résultats exigés pour les tâches de l’équipe. Un décompte supérieur peut coexister avec une qualité similaire ou meilleure ; un coût inférieur peut coexister avec davantage d’échecs. Il est donc important d’examiner ensemble la consommation et l’acceptation.

Protocole de comparaison entre Sonnet 5 et Sonnet 4.6

Avant de lancer le test, déterminez la question à laquelle vous voulez répondre. Il peut s’agir de savoir si les prompts actuels tiennent toujours avec une marge suffisante, s’il faut réajuster les limites de sortie ou si les dépenses par tâche acceptée varient de façon significative. Ne réunissez pas ces questions dans une seule conclusion : chacune requiert une mesure différente. Définissez également ce qui serait considéré comme significatif pour le produit, par exemple une réduction de la marge de contexte qui obligerait à retirer du contenu nécessaire, ou une variation de coût dépassant le seuil interne de l’équipe.

Exécutez les mêmes entrées avec les deux versions et gardez identiques, dans la mesure permise par les interfaces, les instructions, les outils, les paramètres de génération et les règles d’acceptation. Si une fonctionnalité n’a pas d’équivalent entre les versions, consignez cette différence et ne lui attribuez pas automatiquement un effet lié au tokenizer. Enregistrez séparément le décompte des tokens d’entrée, celui des tokens de sortie, les états de fin, les erreurs et l’utilisation du cache. Pour chaque exécution, consignez le coût calculé avec le tarif applicable à ce canal.

Comparez ensuite les résultats par strate, et pas seulement au moyen d’une moyenne globale. Une moyenne peut masquer une faible hausse pour le français et une augmentation plus forte pour certains documents longs, ou montrer que le problème ne concerne que les requêtes proches de la limite. Examinez les valeurs extrêmes et les tâches échouées. Si le taux d’acceptation évolue, étudiez des exemples précis pour distinguer les erreurs de contenu des coupures dues aux limites, des formats invalides ou des modifications de configuration.

Répétez le test lorsqu’une variable pertinente change. Si les tarifs, la documentation, le corpus ou le système de cache sont mis à jour, un chiffre antérieur ne décrit plus exactement les nouvelles conditions. Conserver une version datée du jeu de test et du calcul permet de comparer les résultats au fil du temps sans confondre les changements du modèle avec ceux de l’environnement.

Distinguer la tokenisation, les tarifs et le canal d’accès

Pour attribuer un changement au tokenizer, comparer une facture avant et après la migration ne suffit pas. Le prix peut avoir changé, l’utilisation du cache peut différer, le prompt peut avoir été modifié et les réponses peuvent être de longueur différente. La comparaison la plus claire sépare trois questions : combien de tokens le même contenu représente-t-il, quel montant est facturé dans les conditions en vigueur et combien de tâches acceptées chaque configuration produit-elle ? Une différence dans l’une de ces mesures n’explique pas automatiquement les autres.

Il ne faut pas non plus supposer que tous les canaux proposent des conditions identiques. La documentation d’Amazon Bedrock fournit des informations propres à ce service sur la disponibilité, les points de terminaison, les régions, les API et la facturation du modèle. La documentation de la plateforme d’Anthropic constitue la référence correspondante pour l’API directe. Les sources vérifiées disponibles ne permettent pas d’affirmer que tous les détails de comptage, de cache, de limites ou de facturation sont identiques d’un canal à l’autre. Si l’application passe par un tiers, mesurez les résultats sur cette plateforme et consultez sa documentation et ses conditions en vigueur, plutôt que d’extrapoler ceux de l’API directe.

La même prudence s’impose pour les comparaisons de prix publiées dans des annonces. Un prix annoncé ou une comparaison historique ne décrit pas nécessairement ce qui est facturé aujourd’hui sur chaque plateforme et dans chaque région. Utilisez la documentation tarifaire en vigueur pour convertir l’utilisation mesurée en coût, et conservez la date ainsi que le canal correspondant au tarif appliqué. Si les conditions ne peuvent pas être rendues équivalentes, présentez la comparaison comme une évaluation du système dans son ensemble, et non comme une mesure isolée du tokenizer.

Décider de migrer, d’ajuster ou de conserver temporairement l’ancienne version

La migration est mieux étayée lorsque le test montre que les tâches requises satisfont toujours les critères d’acceptation, que les prompts tiennent avec une marge suffisante et que le coût par tâche acceptée reste dans les limites définies par l’équipe. Si le nombre de tokens augmente sans provoquer de troncature ni de variation significative du budget, il peut s’agir d’un changement comptable qui ne nécessite pas de revoir l’architecture. Il reste toutefois utile de mettre à jour les prévisions et les tableaux de bord qui dépendaient des anciens décomptes.

Si le problème ne se manifeste que dans les requêtes proches de la limite, il peut suffire d’examiner ces cas : réduire le contexte redondant, ajuster la sélection des documents ou recalibrer max_tokens si l’application a besoin de réponses plus longues. Ces changements doivent être validés avec les mêmes tâches de test, car toute modification des prompts ou du contenu introduit une nouvelle variable. Il ne faut pas réduire un contexte important uniquement pour compenser un décompte supérieur : le résultat doit rester acceptable.

Si la comparaison révèle des échecs fréquents, une hausse du coût par tâche acceptée ou des résultats non concluants en raison de différences entre les canaux, il peut être raisonnable de reporter la migration de cette intégration, de la segmenter par type de tâche ou de procéder à un déploiement contrôlé. Conserver temporairement Sonnet 4.6 ne signifie pas que Sonnet 5 est globalement moins bon ; cela signifie que les données de l’équipe ne justifient pas encore le changement pour cet usage précis. La décision doit également tenir compte de la disponibilité et des conditions en vigueur pour les deux versions.

Consignez la décision ainsi que les conditions susceptibles de la rendre caduque. Une conclusion telle que « migrer » n’est utile que si elle est accompagnée de la version évaluée, du corpus, du canal, du tarif et de la date. Sans ces informations, les chiffres ne sont plus reproductibles et une modification ultérieure des prix ou de la documentation peut rendre obsolète une comparaison auparavant raisonnable.

Limites de la conclusion

Les informations publiées par Anthropic fournissent un point de départ pour le test, pas un substitut au corpus de chaque organisation. La fourchette approximative de tokens varie selon le contenu ; un échantillon surtout composé de textes courts peut donc ne pas représenter les documents longs, le code, le français ou d’autres contenus utilisés en production. Cette fourchette ne permet pas non plus de déduire le coût final d’une tâche, car elle ne précise ni la répartition des entrées et des sorties, ni le tarif appliqué, ni le traitement du cache dans chaque intégration.

Les conditions peuvent évoluer avec le temps. L’annonce d’un modèle, une page de migration et une page tarifaire peuvent être mises à jour à des dates différentes. Avant le déploiement, vérifiez la documentation officielle en vigueur et notez la version et le canal évalués. Les sources consultées n’établissent pas d’équivalence universelle des décomptes, des limites et de la facturation entre l’API d’Anthropic et les services tiers ; toute conclusion à cet égard nécessite une vérification sur le canal concerné.

La question utile n’est donc pas de savoir si Sonnet 5 consomme toujours un pourcentage fixe de tokens en plus, mais dans quelle mesure son utilisation des ressources change pour la charge de travail à migrer et si ce changement affecte le résultat attendu. Une expérience contrôlée permet d’y répondre plus sûrement que l’extrapolation d’un chiffre général. Pour comparer d’autres options disponibles dans le catalogue, l’index des modèles peut servir de point de départ ; une évaluation de migration doit toutefois conserver les mêmes conditions et critères pour chaque cas.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.