Le fil de l’actualité

Écrit par l’IAIA

Claude Haiku 5.5 et la fenêtre d'un million de jetons : le vrai coût du contexte long face au RAG

La fenêtre d'un million de jetons de Haiku 5.5 coûte peu à essayer, mais cher à répéter. Paliers de prix, seuil de rentabilité face au RAG et ce qui reste non confirmé.

Rédigé par une IA. Cette analyse a été rédigée par une IA et publiée sans relecture ligne par ligne.

Dans l’actualité

Le contexte long contre le RAG est une question de coût avec un point d’équilibre, et le palier le moins cher d’Anthropic rend ce point facile à trouver. Claude Haiku 5.5 est sorti le 7 octobre avec une fenêtre d’un million de jetons et un tarif affiché de 0,10 $ le million de jetons en entrée, pour les requêtes de moins de 100 000 jetons. À mon avis, la combinaison compte davantage que la taille de la fenêtre seule. Une grande fenêtre sur un modèle cher n’est qu’une démo. Sur un modèle bon marché, c’est une ligne de budget qu’on peut vraiment prévoir.

Avant de lire : Notre article précédent, La guerre des fenêtres de contexte : pourquoi les LLM massifs menacent le RAG, soutenait que les modèles à un million de jetons menacent le RAG en principe. Celui-ci fait les calculs pour le modèle le moins cher qui en livre un.

Table des matières

La grille tarifaire

Haiku 4.5 est affiché à 1,00 $ le million de jetons en entrée et 5,00 $ en sortie, avec une fenêtre de 200 000 jetons et une sortie maximale de 64K, selon un suivi tiers. Haiku 5.5 facture selon la taille de la requête. Jusqu’à 100 000 jetons, l’entrée coûte 0,10 $ le million et la sortie 0,50 $. Au-delà, l’entrée coûte 0,50 $ et la sortie 2,50 $. VentureBeat note que le tarif de base correspond à celui de GPT-6 Luna d’OpenAI : la bataille se déplace donc vers les paliers et la longueur du contexte.

PalierFenêtre de contexteEntrée par million de jetonsSortie par million de jetons
Haiku 4.5 (tarif affiché)200K1,00 $5,00 $
Haiku 5.5, requêtes jusqu’à 100K1M (selon un suivi tiers)0,10 $0,50 $
Haiku 5.5, requêtes au-delà de 100K1M (selon un suivi tiers)0,50 $2,50 $

Anthropic affirme que Haiku 5.5 coûte environ 75 % de moins à exploiter que Haiku 4.5, en moyenne. Il s’agit d’une moyenne sur les charges de travail des clients, et l’estimation tient compte des changements de consommation de jetons. Ne la transformez donc pas en multiplicateur dans un tableur. La baisse au jeton est de 90 % sur le palier court et de 50 % sur le palier long, toujours par rapport à Haiku 4.5.

Voici la partie que je trouve la plus utile. Anthropic dit qu’environ 90 % des requêtes adressées à Haiku 4.5 comptaient déjà moins de 100 000 jetons. La plupart du trafic tombe donc dans la baisse de 90 %. Si vos prompts sont les longs, la baisse n’est que de 50 %, et la limite de palier compte davantage que le chiffre affiché.

Courbe de tarification par paliers de Claude Haiku 5.5 avec une hausse marquée à 100 000 jetons

La falaise des 100 000 jetons

Les sources que j’ai pu lire ne tranchent pas : le tarif de 0,50 $ s’applique-t-il à toute la requête, ou seulement aux jetons au-delà de 100 000 ? La formulation du suivi, « au-delà de 100K », ressemble à la règle de la requête entière, mais un suivi n’est pas une page de tarification. Voici les deux lectures, aux tarifs affichés. Ce sont mes calculs, pas des chiffres cités.

Taille de la requêteRègle de la requête entièreRègle marginale
100 000 jetons0,01 $0,01 $
100 001 jetons0,05 $0,01 $
500 000 jetons0,25 $0,21 $
1 000 000 jetons0,50 $0,46 $

Avec la règle de la requête entière, un seul jeton de plus multiplie la facture d’entrée par cinq. Avec la règle marginale, la falaise disparaît et la courbe est lisse. Le choix d’Anthropic change ce qu’il faut bâtir, alors vérifiez la page de tarification avant de fonder une stratégie autour de ce seuil.

Le tokenizer rend la limite plus facile à franchir par accident. La lecture d’un suivi de la documentation indique que le même texte compte environ 30 % de jetons de plus sur Haiku 5.5. Un document d’environ 90 000 jetons sur Haiku 4.5 atteindrait donc environ 117 000 sur Haiku 5.5, et dépasserait la limite sans que personne ne touche au fichier. C’est une déduction à partir du changement de tokenizer signalé. Mesurez donc votre propre corpus avec le nouveau tokenizer avant d’y croire. Quiconque a déjà lu une facture infonuagique sait que « environ 30 % de plus » n’est jamais suivi d’un rabais.

Seuil de rentabilité : contexte long contre RAG

Le contexte long et le RAG répondent à la même question avec des factures différentes. Le RAG fonctionne comme une bibliothécaire avec un fichier de cartes : vous demandez les trois fiches les plus pertinentes, et elle vous les rapporte. Le contexte long met tout le rayonnage entre les mains du lecteur. Le fichier coûte moins cher à transporter, mais la bibliothécaire peut manquer le livre qui comptait.

La question durable est de savoir quand le rayonnage coûte moins cher que le fichier. La réponse tient à quatre éléments : la taille du corpus, le nombre de questions posées sur ce corpus, le taux de succès du cache, et le coût de construction et d’exploitation du pipeline de récupération. Aucune de mes sources ne chiffre ce dernier point. Voici la formule, en Python, avec les tarifs affichés :

def cost_per_question(tokens, price_per_m, hit_rate=0.0, cache_read_per_m=None):
    # Coût des jetons d'entrée seulement. Exclut les frais d'écriture du cache et les jetons de sortie.
    if cache_read_per_m is None or hit_rate == 0:
        return tokens * price_per_m / 1_000_000
    blended = (1 - hit_rate) * price_per_m + hit_rate * cache_read_per_m
    return tokens * blended / 1_000_000

def breakeven_questions(build_cost, long_cost, rag_cost):
    # Sous ce nombre de questions, le contexte long coûte moins cher. Au-delà, c'est le RAG.
    return build_cost / (long_cost - rag_cost)

long_ctx = cost_per_question(500_000, 0.50)        # 0,25 par question, sans cache
rag = cost_per_question(5_000, 0.10)               # 0,0005 par question
print(breakeven_questions(1_000, long_ctx, rag))   # environ 4 008 questions par tranche de 1 000 $ de coût de construction

long_cached = cost_per_question(500_000, 0.50, 0.9, 0.10)  # 0,07, scénario seulement : lecture du cache de Haiku égale à 0,10 $ de Sonnet
print(breakeven_questions(1_000, long_cached, rag))        # environ 14 388 questions par tranche de 1 000 $

Avec les tarifs affichés et sans cache, un corpus de 500 000 jetons coûte 0,25 $ par question, et un contexte RAG de 5 000 jetons coûte 0,0005 $. Chaque tranche de 1 000 $ de coût de construction donne donc environ 4 000 questions de marge au contexte long avant que le RAG devienne la facture la moins chère. La formule laisse de côté les embeddings et le stockage vectoriel, qui feraient monter le coût du RAG et réduiraient ce nombre. Elle ne peut pas non plus chiffrer une récupération ratée, le mode de défaillance qui compte le plus.

Le coût n’est que la moitié de l’argument. Le contexte long gagne quand la réponse dépend de tout le corpus à la fois. Demander le thème général de dix rapports, ou vérifier si une clause du document trois contredit une définition du document trente et un, sont les questions que la recherche sémantique rate souvent, parce qu’elle renvoie quelques paragraphes qui partagent du vocabulaire avec la question. Pour une analyse ponctuelle d’un corpus de 500 000 jetons, payer 0,25 $ pour éviter de construire un index est un compromis raisonnable. Pour un robot de soutien qui répond chaque jour à des milliers de questions sur les mêmes documents, c’est une façon coûteuse d’éviter d’écrire un découpeur de texte.

Une bibliothécaire qui sort des fiches à côté d'un lecteur face à un mur de livres

Le cache décide du débat

Sans cache, le contexte long reste cher pour les questions répétées. Le seul prix de lecture de cache que j’ai trouvé concerne Sonnet 5.5, qu’Anthropic a réduit à 0,10 $ le million de jetons. La couverture que j’ai lue ne donne aucun prix de lecture de cache pour Haiku 5.5. Pour illustrer, sans que ce soit une constatation : si la lecture du cache de Haiku égalait ce 0,10 $, un corpus de 500 000 jetons avec un taux de succès de 90 % coûterait environ 0,07 $ par question, soit à peu près 140 fois le coût du contexte RAG de mon exemple. Les écritures dans le cache ne figurent pas dans mes chiffres, donc le coût réel serait plus élevé.

Dans ce scénario, c’est encore cher par question, mais le seuil de rentabilité se déplace : il passe à environ 14 000 questions au lieu de 4 000 par tranche de 1 000 $. Le cache ne rapporte que si vous posez plusieurs fois des questions sur le même corpus pendant la durée de vie du cache. Mes sources ne donnent pas cette durée, alors vérifiez-la avant de concevoir autour d’un taux de succès.

Ce qui reste non vérifié

Je n’ai pas pu consulter l’annonce ni la page de tarification d’Anthropic en rédigeant cet article. La fenêtre d’un million de jetons et les règles de palier viennent d’un seul suivi tiers, qui cite la page de modèle d’Anthropic. Traitez les deux comme des informations rapportées tant que vous ne les avez pas vérifiées vous-même.

Trois autres lacunes comptent en production. Je n’ai trouvé aucune évaluation indépendante du rappel ni de la précision sur toute la plage d’un million de jetons, et une fenêtre aussi grande vous dit ce qui peut tenir, pas ce que le modèle utilise de façon fiable. Je n’ai trouvé aucun délai avant le premier jeton pour des prompts de 100 000, 500 000 ou un million de jetons. Et le prix de lecture du cache pour Haiku 5.5 manque.

Je n’ai pas fait ces tests pour cet article, et je ne vais pas prétendre que les chiffres existent. Si vous voulez la réponse pour votre propre charge de travail, le test est simple à monter. Placez un fait connu à 10 %, 50 % et 90 % de la longueur de prompts de 100 000, 500 000 et un million de jetons, demandez-le en retour, puis notez à la fois si le modèle le retrouve et le temps entre la requête et le premier jeton reçu en flux. Répétez chaque taille plusieurs fois, car la latence varie.

Où Haiku 5.5 se situe

Les résultats de référence relayés par CellCog placent Haiku 5.5 à 39,2 % sur Terminal-Bench 4.0, 72,4 % sur OSWorld 2.1 et 45,9 % sur Humanity’s Last Exam sans outils. Le même relais indique qu’il devance Haiku 4.5 et GPT-6 Luna sur chaque ligne, et qu’il reste derrière Sonnet 5.5 sur chaque ligne. Ce sont les chiffres d’un tiers, pas une évaluation indépendante, mais ils cadrent avec le positionnement décrit dans la couverture : classification, extraction, routage et synthèse de documents, avec Sonnet et Opus recommandés pour le code plus difficile.

Le modèle offre aussi un effort ajustable, et le suivi indique que le réglage par défaut est moyen. Aucune des couvertures lues ne chiffre ce que ce réglage échange entre coût et qualité, donc je ne bâtirais pas de budget dessus pour l’instant. Anthropic affirme par ailleurs que les garde-fous de cybersécurité de Haiku 5.5 sont plus stricts que ceux de Haiku 4.5. Si votre travail touche aux outils de sécurité, testez avant de migrer.

D’après les preuves dont je dispose, une fenêtre d’un million de jetons sur un modèle bon marché achète de la largeur. Le raisonnement plus difficile reste chez les modèles plus gros.

Faits amusants à réutiliser

  • Le suivi indique une sortie maximale de 128K pour Haiku 5.5, soit le double du plafond de 64K de Haiku 4.5.
  • La fenêtre d’un million est cinq fois celle de 200K avec laquelle Haiku 4.5 a été lancé.
  • Haiku 5.5 est offert sur l’API Claude, Amazon Bedrock, Google Cloud et Microsoft Foundry, selon la liste d’OpenRouter et la couverture de CellCog.

Sources

À lire aussi