Tarification multimodale : ce que facturent vraiment images, audio et vidéo

Un transformer prend une séquence de vecteurs. Il n’a pas d’opinion sur leur provenance. Le chapitre 8 l’alimentait avec des embeddings récupérés depuis un identifiant de token ; rien dans l’architecture n’exige cette récupération.

Donc : découpez l’image en carrés fixes, aplatissez chaque carré en une liste de nombres, puis faites passer chaque liste dans une couche linéaire apprise pour obtenir un vecteur de la largeur du modèle. Un patch de pixels couleur de 32 × 32 représente $32 \times 32 \times 3 = 3072$ nombres ; la projection $E \in \mathbb{R}^{d \times 3072}$ le transforme en un vecteur de dimension $d$, exactement la forme sous laquelle arrive un token de texte. C’est tout, et c’est le papier dont le titre le dit : une image vaut 16 × 16 mots.¹ Ajoutez un encodage positionnel pour que le modèle sache quel carré se trouvait où, intercalez les résultats avec les embeddings de texte, et la séquence lue par le modèle est en partie image et en partie phrase.

Trois articles en ont fait un produit. CLIP a entraîné un encodeur d’image et un encodeur de texte à s’accorder, sur quatre cents millions de paires extraites du Web, et c’est là que l’idée selon laquelle pixels et mots peuvent partager un espace a cessé d’être une hypothèse.² Flamingo a boulonné un encodeur de vision gelé à un modèle de langage gelé avec quelques couches de pont entraînées.³ LLaVA a montré que le pont pouvait être une simple projection linéaire et que le suivi d’instructions pouvait s’apprendre avec des données générées, ce qui explique pourquoi tous les modèles vision-langage ouverts depuis lui ont à peu près la même forme.⁴

La conséquence pour votre facture est immédiate et peu glamour : les patchs sont des positions dans la séquence, donc ce sont des input tokens, donc vous les payez au tarif d’entrée. Leur nombre relève de l’arithmétique, et chaque fournisseur la fait différemment.

Chaque règle ci-dessous est implémentée à partir de la documentation du fournisseur concerné et vérifiée avec les exemples chiffrés de cette même documentation.

OpenAI couvre l’image avec des patchs 32 × 32 et multiplie le compte par un facteur propre au modèle. Si le nombre de patchs dépasse le budget de ce modèle et de ce niveau de détail, l’image est réduite jusqu’à tenir dedans :

Anthropic la couvre avec des patchs 28 × 28, un visual token chacun, et plafonne à la fois le bord long et le nombre de tokens — 1 568 pixels et 1 568 tokens sur les modèles standard, 2 576 et 4 784 sur le palier haute résolution. Les images trop grandes sont réduites à la plus grande taille qui respecte les deux contraintes.⁵

Google ne compte pas les pixels du tout. Une image dont les deux côtés sont inférieurs ou égaux à 384 pixels coûte forfaitairement 258 tokens. Toute image plus grande est découpée en tuiles de 258 tokens chacune, et la grille de tuiles vient d’une unité de recadrage de $\lfloor \min(w,h) / 1.5 \rfloor$.⁶

export function openaiImageTokens(
  w: number, h: number,
  { maxDim, patchBudget, multiplier }: { maxDim: number; patchBudget: number; multiplier: number },
) {
  const fit = Math.min(1, maxDim / Math.max(w, h));      // never enlarges
  w = Math.floor(w * fit); h = Math.floor(h * fit);
  let patches = Math.ceil(w / 32) * Math.ceil(h / 32);   
  if (patches > patchBudget) {
    const s = Math.sqrt((32 * 32 * patchBudget) / (w * h));
    const adj = s * Math.min(
      Math.floor((w * s) / 32) / ((w * s) / 32),
      Math.floor((h * s) / 32) / ((h * s) / 32));
    patches = Math.ceil(Math.floor(w * adj) / 32) * Math.ceil(Math.floor(h * adj) / 32);
  }
  return Math.ceil(patches * multiplier);                
}

export function anthropicVisualTokens(
  w: number, h: number,
  { maxLongEdge, maxTokens }: { maxLongEdge: number; maxTokens: number },
) {
  const tok = (a: number, b: number) => Math.ceil(a / 28) * Math.ceil(b / 28);
  const long = Math.max(w, h), short = Math.min(w, h);
  for (let L = Math.min(long, maxLongEdge); L >= 1; L--) {     
    const t = tok(L, Math.round((short * L) / long));
    if (t <= maxTokens) return t;                              
  }
  return 0;
}

export function geminiImageTokens(w: number, h: number) {
  if (w <= 384 && h <= 384) return 258;
  const crop = Math.floor(Math.min(w, h) / 1.5);               
  return Math.ceil(w / crop) * Math.ceil(h / crop) * 258;      
}

Exécutez chacune sur les chiffres imprimés par son propre fournisseur :

OpenAI, gpt-5.4 at detail:high (2048 px, 2,500 patches, 1.2x)
  1024x1024 -> 1024 patches -> 1229 tokens   doc says 1229   MATCH
  2048x2048 -> 2500 patches -> 3000 tokens   doc says 3000   MATCH

Anthropic, the published table (one tier per row shown)
  200x200    std   64 @ 200x200     doc   64, not resized    OK
  1000x1000  std 1296 @ 1000x1000   doc 1296, not resized    OK
  1092x1092  std 1521 @ 1092x1092   doc 1521, not resized    OK
  1920x1080  std 1560 @ 1456x819    doc 1560, 1456x819       OK
  2000x1500  std 1564 @ 1269x952    doc 1564, 1269x952       OK
  3840x2160  hi  4784 @ 2576x1449   doc 4784, 2576x1449      OK

Google, the worked example
  960x540 -> crop 360 -> 3 x 2 = 6 tiles     doc says 6      MATCH

Neuf concordances sont imprimées ; l’exécution complète en vérifie quinze, puisque le tableau d’Anthropic donne les deux paliers pour les six tailles. Les règles sont désormais à vous, pour les exécuter sur n’importe quelle photographie : ce sont les trois seules fonctions de ce chapitre que vous ne pouvez pas obtenir depuis une page de prix.

Faites passer la même photographie 4:3 par les trois méthodes à six tailles :

Lisez la dernière colonne vers le bas. Dès que l’image dépasse 384 pixels, le nombre ne change plus jamais, et ce n’est ni une coïncidence ni un plafond. Remettez l’unité de recadrage dans la formule de tuiles, pour une image au moins aussi large que haute :

La taille s’annule. Les image tokens de Google dépendent du ratio d’aspect et de rien d’autre. Une photographie 4:3 représente quatre tuiles, qu’il s’agisse d’une miniature ou d’une affiche. Ce simple fait algébrique explique à lui seul le zéro du tableau d’économies ci-dessus, et aucune page de prix ne l’indique.

Les deux autres colonnes plafonnent au contraire, à des hauteurs différentes et pour des raisons différentes — Anthropic à un plafond déclaré de tokens, OpenAI à un budget de patchs après une limite de pixels — ce qui explique pourquoi les trois courbes se croisent à des tailles différentes.

Maintenant, cassez-le. La façon évidente de dépenser moins sur un modèle de vision est de demander moins de détail, donc envoyez detail: "low" :

1600x1200   low = 2280   high = 2280   ratio 1.00
3200x2400   low = 3687   high = 2942   ratio 1.25

Demander moins de détail a coûté 25 % de plus. Ce n’est pas un bug, et OpenAI le dit en une ligne du tableau de dimensionnement : sur cette famille de modèles, low utilise une limite de 2048 pixels avec un budget de 6 144 patchs, tandis que high utilise la même limite de pixels avec un budget de 2 500 patchs, « si bien qu’il peut utiliser plus de tokens que high ».⁷ Le mot low nomme un réglage de fidélité, pas un prix : sur deux des cinq familles de modèles documentées, il n’achète aucune économie, et sur l’une de ces deux, il coûte plus cher.

Jusqu’ici, tout concernait un modèle qui lisait une image. En produire une repose sur un mécanisme sans tokens du tout, et c’est pour cela que cela se vend à l’image plutôt qu’au mot.

Les fournisseurs publient la génération d’images comme un prix par image. Ce n’en est pas un. Les modèles GPT Image émettent des image tokens spécialisés dont le nombre dépend de la taille et de la qualité demandées ; multipliez les comptes publiés par le tarif de sortie image publié de GPT Image 1, $40 par million, et comparez avec les prix par image de la même page :

Neuf chiffres dérivés face à neuf chiffres publiés, chaque paire concordant à $0.002 près.¹¹ Google est encore plus explicite et fait la conversion pour vous directement sur la page de prix : sortie image à $60 par million de tokens, « les images de sortie en 1K (1024x1024px) consomment 1120 tokens et équivalent à $0.067 par image ».¹²

Un prix par image est donc un prix par token avec le compte intégré. C’est très bien, et cela cache quelque chose. Prenez le tableau de la génération actuelle et divisez à rebours :

quality   1024x1024            1024x1536
low       $0.006 -> 200 tok    $0.005 -> 167 tok
medium    $0.053 -> 1767 tok   $0.041 -> 1367 tok
high      $0.211 -> 7033 tok   $0.165 -> 5500 tok

L’image plus grande est la moins chère à chaque niveau de qualité. Une toile 1024 × 1536 a 50 % de pixels de plus qu’une 1024 × 1024 et coûte 23 % de tokens en moins en qualité moyenne. OpenAI le signale dans une phrase que vous sauteriez — « une résolution non carrée plus grande peut parfois produire moins d’output tokens qu’une résolution plus petite ou carrée au même niveau de qualité » — et sur la génération de modèles précédente, c’était l’inverse : le portrait coûtait 50 % de plus que le carré.¹¹ Chaque valeur par défaut 1024x1024 écrite avant ce changement est désormais l’option chère.

Demandez à trois produits de prononcer les mêmes 519 caractères — environ 38 secondes d’audio — et vous obtenez trois systèmes d’unités chez deux fournisseurs :

Le même fournisseur vend les deux unités : tts-1 d’OpenAI est tarifé au million de caractères, tandis que gpt-4o-mini-tts est tarifé au million de tokens, $0.60 en entrée et $12.00 en sortie.¹³ Donc « le text-to-speech le moins cher » n’est pas une question qui a une réponse tant que vous n’avez pas dit ce que vous faites prononcer.

Et les deux unités sont aveugles à des choses opposées. Un prix par caractère ne voit pas la durée : choisissez une voix lente et posée, ou ajoutez des pauses, et la facture ne bouge pas alors que l’audio s’allonge. Un prix par seconde ne voit pas le contenu : trente secondes coûtent la même chose, qu’il s’agisse d’un paragraphe technique dense ou de quelqu’un qui compte jusqu’à dix. Changez la voix, et exactement l’un de vos deux fournisseurs recalcule le prix.

La transcription va dans l’autre sens et constitue la ligne la plus simple de toute la facture — par minute d’audio, forfaitaire :

whisper                  $0.005960     ($0.006 / min)
gpt-transcribe           $0.004470     ($0.0045 / min)
gpt-4o-mini-transcribe   $0.002980     ($0.003 / min)
gpt-live-transcribe      $0.016887     ($0.017 / min)

Notez la dernière ligne par rapport à la troisième : le faire en direct, au fil de l’arrivée des mots, coûte 5,7 fois plus que le faire sur un fichier terminé. Cet écart est le prix de l’impossibilité de batch, et c’est ce qui rend la section suivante coûteuse.

Voici maintenant le chiffre qui décide si la voix est une fonctionnalité ou un produit.

L’appel : une conversation de support en dix tours, 149 mots, ce qui à 150 mots par minute déclarés donne 59,6 secondes de parole — 21,2 prononcées par l’appelant, 38,4 renvoyées en réponse. Les conversions en tokens sont celles des fournisseurs. OpenAI : « les audio tokens dans les messages utilisateur valent 1 token par 100 ms d’audio, tandis que les audio tokens dans les messages assistant valent 1 token par 50 ms ».¹⁴ Google : 25 tokens par seconde, dans les deux sens, ce que sa page de prix confirme en publiant $12.00 par million et $0.018 par minute sur la même ligne.¹²

La conversation s’accumule exactement comme le chapitre 16 disait qu’elle le ferait, parce que c’est le même mécanisme : « toute la conversation est envoyée au modèle pour chaque Response... ainsi les tours ultérieurs de la session seront plus chers ».¹⁴ Sauf qu’ici l’historique est mesuré en audio tokens.

Voici maintenant la comparaison qui décide le produit, les quatre normalisés à une minute :

Trente-huit fois. Pas trente-huit pour cent. Le même échange, mené en son plutôt qu’en texte, est presque deux ordres de grandeur plus cher, et aucun morceau de cet écart n’est une marge que quelqu’un a choisi de facturer : c’est le taux de conversion. Une seconde d’audio assistant représente vingt tokens. Cette même seconde transporte 2,5 mots au débit déclaré, et la transcription mesurée tourne à 1,26 tokens par mot ; en texte, elle représente donc 3,15 tokens. Le son est un paquet 6,3 fois plus volumineux pour le même sens, et chacun de ses tokens est facturé 5,3 fois le tarif de sortie texte et 16 fois le tarif d’entrée texte. Multipliez un ratio de volume par un ratio de prix et l’ordre de grandeur est déjà là avant toute comptabilité.

Deux conséquences opérationnelles sortent directement du tableau.

L’audio caching n’est pas une optimisation, c’est le modèle économique. L’entrée audio en cache coûte $0.40 par million contre $32.00 en frais — une remise de 98,75 % qui divise l’appel par deux. La règle est celle du chapitre 16, inchangée : le cache correspond à un préfixe, donc tout élément inséré au début de la conversation en plein appel le détruit, et l’endroit naturel où mettre « l’appelant est maintenant vérifié » est précisément là.

Et rien de ce que vous faites dans le client ne défacture un son. L’utilisateur parle par-dessus l’assistant, votre code arrête la lecture, le haut-parleur se tait. Tout ce qui avait déjà été généré était déjà facturé, parce que la facturation s’accumule quand la réponse est créée ; et selon la règle du chapitre 16, tout ce qui reste dans la conversation est renvoyé, comme audio d’entrée, à chaque tour suivant. Le chapitre 14 faisait ce point à propos de l’interruption d’un flux de texte. En voix, cela coûte trente fois plus.

La vidéo est vendue à la seconde par certains fournisseurs et au clip par d’autres, avec des paliers de résolution et parfois de durée. Ces deux formes ne diffèrent pas seulement par commodité ; elles se croisent.

Le fournisseur au clip est plus cher que celui à la seconde sous 1,2 seconde et 16,7 fois moins cher à vingt secondes. Aucun ordre entre ces deux modèles ne survit à un changement de durée de clip ; « quel modèle vidéo est le moins cher » n’est donc pas une question sur les modèles.

La dernière ligne est pire, et c’est le cœur honnête du chapitre. mochi est facturé sur des secondes GPU réelles — le temps de prédiction mesuré du job — à $0.001400 par seconde sur un A100 et $0.001525 sur un H100, qui sont les tarifs de la machine louée et rien d’autre.¹⁵ C’est un tarif parfaitement précis, et ce n’est pas un prix, parce que la quantité qu’il multiplie est inconnue jusqu’après votre engagement à la payer. La ligne ci-dessus suppose douze GPU-secondes par seconde de sortie ; quadruplez cette hypothèse et elle quitte la tranche la moins chère, et ce n’est qu’à six fois qu’elle arrive au milieu du tableau. C’est le seul tarif de cette page que vous ne pouvez pas mettre dans un devis.

Donc : tokens, image tokens, caractères, minutes, secondes de vidéo, clips entiers, GPU-secondes, unités forfaitaires. Huit quantités, et la seule façon de les placer sur un même axe est de déclarer une charge de travail et de la chiffrer.

C’est l’extension du computeCost du chapitre 16 — la même mécanique de paliers, désormais avec des critères qui ne sont pas la longueur du prompt :

export interface MediaCriteria {
  resolution?: string[]; quality?: string[];
  hasAudio?: boolean; maxDurationSeconds?: number;
}
export interface MediaTier { when?: MediaCriteria; price: number }
export type MediaRate = number | MediaTier[];

const matches = (when: MediaCriteria, u: Usage) => {
  const inList = (l?: string[], v?: string) => !l || (v !== undefined && l.includes(v));
  if (!inList(when.resolution, u.resolution)) return false;
  if (!inList(when.quality, u.quality)) return false;
  if (when.hasAudio !== undefined && when.hasAudio !== (u.hasAudio ?? false)) return false;
  if (when.maxDurationSeconds !== undefined
      && (u.videoSeconds ?? 0) > when.maxDurationSeconds) return false;   
  return true;
};

const mediaPrice = (rate: MediaRate | undefined, u: Usage): number => {
  if (rate === undefined) return 0;
  if (typeof rate === "number") return rate;
  for (const t of rate.filter((t) => t.when)) if (matches(t.when!, u)) return t.price;
  return rate.find((t) => !t.when)?.price ?? 0;      // the tier with no criteria is the default
};

export function computeCost(p: Pricing, u: Usage): number {
  let c = textCost(p, u);                             // Chapter 16, unchanged
  if (p.imageInputToken || p.imageOutputToken) {
    c += (u.imageInputTokens ?? 0) * (p.imageInputToken ?? 0)
       + (u.imageOutputTokens ?? 0) * (p.imageOutputToken ?? 0);
  } else if (p.imageUnit !== undefined) c += (u.images ?? 1) * mediaPrice(p.imageUnit, u);  
  if (p.videoSecond !== undefined) c += (u.videoSeconds ?? 0) * mediaPrice(p.videoSecond, u);
  if (p.videoUnit   !== undefined) c += (u.videoCount ?? 1)   * mediaPrice(p.videoUnit, u);
  c += (u.audioInputTokens ?? 0)       * (p.audioInputToken ?? 0)
     + (u.cachedAudioInputTokens ?? 0) * (p.cachedAudioInputToken ?? p.audioInputToken ?? 0)
     + (u.audioOutputTokens ?? 0)      * (p.audioOutputToken ?? 0)
     + (u.computeSeconds ?? 0)         * (p.computeSecond ?? 0)
     + (u.chars ?? 0)                  * (p.perChar ?? 0)
     + (u.minutes ?? 0)                * (p.perMinute ?? 0);
  return c;
}

Les deux lignes marquées sont celles où cela casse. Un tarif indiqué par unité multiplie u.images ?? 1 ; un tarif indiqué par token multiplie quelque chose qui vaut zéro par défaut. Donnez aux deux un usage vide — la forme que vous obtenez quand une mesure a échoué — et regardez :

per image (nano-banana-pro)     empty usage => $0.1500
per clip  (hailuo-02)           empty usage => $0.1500
per unit  (a cloned voice)      empty usage => $3.0000
per token (gpt-image-2)         empty usage => $0.0000
per second (veo-3.1)            empty usage => $0.0000
per GPU-second (mochi)          empty usage => $0.0000

Rien ne s’est passé, six fois, et cela a coûté trois dollars une fois et rien cinq fois. Ce n’est pas une différence d’arrondi ; c’est une décision sur ce que signifie un nombre absent, prise séparément pour chaque unité et jamais écrite. La règle saine veut qu’un champ que personne n’a mesuré reste absent, parce que « non mesuré » et « mesuré et égal à zéro » sont deux choses différentes. Cette fonction n’est discrètement pas d’accord.

Le deuxième échec est la durée. Le tarif au clip choisit son palier avec maxDurationSeconds comparé à u.videoSeconds ?? 0, donc un usage qui n’a jamais enregistré de durée correspond au palier le plus court :

duration recorded    ->  $0.45
duration missing     ->  $0.27

Quarante pour cent de remise pour ne pas savoir combien de temps durait la vidéo. Les deux bugs ont la même racine : une valeur par défaut choisie pour la commodité dans une fonction dont tout le rôle est d’être exacte.

Une fois les coûts calculables, la comparaison a besoin de son autre moitié — une charge de travail représentative déclarée, une par moteur, énoncée publiquement afin qu’un lecteur puisse la contester :

export const representative = {
  text:   { blend: [[{ promptTokens: 1e6 }, 0.25], [{ completionTokens: 1e6 }, 0.75]] },
  image:  { images: 1, imageInputTokens: 50, imageOutputTokens: 1500 },
  video:  { videoSeconds: 5, videoCount: 1, resolution: "1080p", hasAudio: true, computeSeconds: 60 },
  voice:  { chars: 1000, computeSeconds: 10 },
  stt:    { minutes: 1 },
};

Chacune de ces lignes est un argument. Le texte mélange un quart d’entrée et trois quarts de sortie parce que l’usage réel penche vers la sortie ; un mélange 50-50 classe les modèles autrement. La charge image suppose 1 500 output tokens, entre les 1 056 d’OpenAI pour un carré moyen et ses 1 584 pour un portrait moyen. La vidéo suppose cinq secondes en 1080p, et nous venons de voir deux fournisseurs échanger leurs places à 1,2 seconde. L’entrée compute suppose soixante GPU-secondes parce qu’il n’y a rien d’autre à supposer.

Voilà la méthode, et c’est la seule honnête disponible : vous ne pouvez pas comparer des prix dans des unités différentes ; vous ne pouvez comparer que le coût d’une charge de travail que vous avez écrite. Tout tableau qui classe des modèles multimodaux sans imprimer sa charge de travail classe ses propres hypothèses.

Vous pouvez désormais chiffrer tout ce qu’un modèle peut produire, quelle que soit l’unité dans laquelle il est vendu, et dire à voix haute quelle charge de travail votre comparaison supposait. Cela clôt la facture ouverte au chapitre 16, et clôt la partie III : tout, du chapitre 14 jusqu’ici, portait sur un appel — comment le faire, quoi y mettre, comment l’échantillonner, ce qu’il renvoie, ce qu’il coûte.

Le chapitre 22 change l’unité d’analyse, et le changement coûte cher. Un agent n’est pas un appel ; c’est une boucle qui décide elle-même combien d’appels effectuer, et l’arithmétique des deux derniers chapitres est ce qui transforme cela d’un schéma d’architecture en budget. Il commence par poser deux fois la même question au même modèle, avec un outil ajouté au catalogue la deuxième fois, et par mesurer ce qu’a fait ce seul outil : un appel est devenu deux, trente-neuf input tokens sont devenus 420.

Que cela en fasse un agent dépend de laquelle des deux définitions publiées vous ouvrez, et elles ne sont pas d’accord. L’une d’elles n’est pas d’accord avec elle-même.

Chaque prix, formule et taux de conversion de ce chapitre a été lu sur la page du fournisseur le 7 septembre 2026 et est cité avec cette date, parce qu’ils bougeront tous. Les nombres de tokens, coûts et comparaisons ont été calculés sur ces données par le code imprimé ci-dessus, sur une seule machine, sans aucun appel API payant — ce qui est aussi la raison honnête pour laquelle ce chapitre ne contient aucune affirmation de latence.

Les fonctions d’image-token, les tableaux de coûts, le détail de l’appel vocal et les résultats d’usage vide ont été produits par le TypeScript imprimé dans ce chapitre, exécuté sur Node 22. Le dialogue utilisé pour la comparaison vocale compte 149 mots et a été tokenized avec tiktoken sous l’encodage o200k_base à 188 tokens ; sa durée découle d’un débit déclaré de 150 mots par minute, qui est un paramètre de la comparaison et non une mesure. Chaque chiffre fournisseur porte la note qui nomme la page dont il vient.