Preus multimodals: què facturen realment imatges, àudio i vídeo

Un transformer rep una seqüència de vectors. No li importa d’on venen. El capítol 8 li donava embeddings buscats a partir d’un id de token; res en l’arquitectura exigeix aquesta cerca.

Per tant: talla la imatge en quadrats fixos, aplana cada quadrat en una llista de nombres i passa cada llista per una capa lineal apresa per obtenir un vector de l’amplada del model. Un patch de 32 × 32 de píxels de color són $32 \times 32 \times 3 = 3072$ nombres; la projecció $E \in \mathbb{R}^{d \times 3072}$ el converteix en un vector de $d$ dimensions, exactament la forma amb què arriba un text token. Això és tot, i és el paper que ho diu al títol: una imatge val 16 × 16 paraules.¹ Afegeix una codificació posicional perquè el model sàpiga quin quadrat era on, intercala els resultats amb els text embeddings, i la seqüència que llegeix el model és en part imatge i en part frase.

Tres papers ho van convertir en producte. CLIP va entrenar un codificador d’imatges i un codificador de text perquè coincidissin, sobre quatre-cents milions de parells extrets del web, i és allà on la idea que píxels i paraules poden compartir un espai va deixar de ser una hipòtesi.² Flamingo va acoblar un codificador de visió congelat a un model de llenguatge congelat amb unes quantes capes pont entrenades.³ LLaVA va demostrar que el pont podia ser una sola projecció lineal i que el seguiment d’instruccions es podia ensenyar amb dades generades, i per això tots els models oberts de visió-llenguatge des d’aleshores s’assemblen força.⁴

La conseqüència per a la teva factura és immediata i poc glamurosa: els patches són posicions en la seqüència, per tant són input tokens, per tant els pagues a la tarifa d’entrada. Quants n’hi ha és aritmètica, i cada proveïdor la fa diferent.

Cada regla de sota està implementada a partir de la documentació pròpia del proveïdor i comprovada contra els exemples resolts de la mateixa documentació.

OpenAI cobreix la imatge amb patches de 32 × 32 i multiplica el recompte per un factor per model. Si el nombre de patches supera el pressupost d’aquell model i nivell de detall, la imatge s’escala cap avall fins que hi cap:

Anthropic la cobreix amb patches de 28 × 28, un visual token cadascun, i limita tant el costat llarg com el nombre de tokens: 1.568 píxels i 1.568 tokens en models de tram estàndard, 2.576 i 4.784 en el tram d’alta resolució. Les imatges massa grans s’escalen a la mida més gran que compleix tots dos límits.⁵

Google no compta píxels en absolut. Una imatge amb tots dos costats a 384 píxels o menys costa una tarifa plana de 258 tokens. Qualsevol imatge més gran es talla en tiles de 258 tokens cadascun, i la graella de tiles surt d’una unitat de retall 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;      
}

Executa cadascuna contra les xifres que imprimeix el seu propi proveïdor:

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

S’imprimeixen nou coincidències; l’execució completa en comprova quinze, perquè la taula d’Anthropic dona tots dos trams per a les sis mides. Ara pots executar aquestes regles sobre qualsevol fotografia que tinguis, que és el punt: aquestes són les úniques tres funcions d’aquest capítol que no pots obtenir d’una pàgina de preus.

Passa la mateixa fotografia 4:3 per totes tres a sis mides:

Llegeix l’última columna cap avall. Un cop la imatge supera els 384 píxels, el nombre no torna a canviar mai, i això no és una coincidència ni un límit. Substitueix la unitat de retall dins la fórmula de tiles, per a una imatge almenys tan ampla com alta:

La mida es cancel·la. Els image tokens de Google depenen de la relació d’aspecte i de res més. Una fotografia 4:3 són quatre tiles tant si és una miniatura com un pòster. Aquest únic fet algebraic és tota l’explicació del zero a la taula d’estalvis de més amunt, i cap pàgina de preus ho diu.

Les altres dues columnes, en canvi, limiten: a alçades diferents i per motius diferents —Anthropic en un sostre declarat de token, OpenAI en un pressupost de patches després d’un límit de píxels—, i per això les tres corbes s’encreuen a mides diferents.

Ara trenca-ho. La manera òbvia de gastar menys en un model de visió és demanar menys detall, així que envia detail: "low":

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

Demanar menys detall va costar un 25 % més. No és un error, i OpenAI ho diu en una línia de la taula de mides: en aquesta família de models, low usa un límit de 2048 píxels amb un pressupost de 6.144 patches, mentre que high usa el mateix límit de píxels amb un pressupost de 2.500 patches, «així que pot usar més tokens que high».⁷ La paraula low anomena un paràmetre de fidelitat, no un preu: en dues de les cinc famílies de models documentades no compra cap estalvi, i en una d’aquestes dues costa més.

Tot fins ara ha estat un model llegint una imatge. Fer-ne una funciona amb un mecanisme que no té tokens en absolut, i per això es ven per imatge i no per paraula.

Els proveïdors publiquen la generació d’imatges com un preu per imatge. No ho és. Els models GPT Image emeten image tokens especialitzats el recompte dels quals depèn de la mida i la qualitat demanades; multiplica els recomptes publicats per la tarifa d’image output publicada de GPT Image 1, $40 per milió, i compara-ho amb els preus per imatge de la mateixa pàgina:

Nou xifres derivades contra nou de publicades, totes les parelles coincidint dins de $0.002.¹¹ Google encara és més explícit i fa la conversió per tu a la mateixa pàgina de preus: image output a $60 per milió de tokens, «les imatges de sortida a 1K (1024x1024px) consumeixen 1120 tokens i equivalen a $0.067 per imatge».¹²

Així que un preu per imatge és un preu per token amb el recompte plegat a dins. Està bé, i amaga una cosa. Agafa la taula de la generació actual i divideix enrere:

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

La imatge més gran és la més barata en totes les qualitats. Un canvas de 1024 × 1536 té un 50 % més de píxels que un de 1024 × 1024 i costa un 23 % menys de tokens a medium. OpenAI ho marca en una frase que et saltaries: «una resolució no quadrada més gran de vegades pot produir menys output tokens que una resolució més petita o quadrada amb el mateix paràmetre de qualitat»; i en la generació anterior de models anava a l’inrevés, amb el retrat costant un 50 % més que el quadrat.¹¹ Cada valor per defecte de 1024x1024 escrit abans d’aquest canvi és ara l’opció cara.

Demana a tres productes que pronunciïn els mateixos 519 caràcters —uns 38 segons d’àudio— i obtens tres sistemes d’unitats de dos proveïdors:

El mateix proveïdor ven totes dues unitats: tts-1 d’OpenAI es valora per milió de caràcters mentre que gpt-4o-mini-tts es valora per milió de tokens, $0.60 d’entrada i $12.00 de sortida.¹³ Per tant, «el text-to-speech més barat» no és una pregunta amb resposta fins que dius què es dirà.

I les dues unitats són cegues a coses oposades. Un preu per caràcter no veu la durada: tria una veu lenta i deliberada, o afegeix pauses, i la factura no es mou mentre l’àudio s’allarga. Un preu per segon no veu el contingut: trenta segons costen el mateix tant si són un paràgraf tècnic dens com si algú compta fins a deu. Canvia la veu i exactament un dels teus dos proveïdors revalora.

La transcripció va a l’inrevés i és la línia més simple de tota la factura: per minut d’àudio, plana:

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)

Fixa’t en l’última fila contra la tercera: fer-ho en directe, a mesura que arriben les paraules, costa 5,7 vegades fer-ho sobre un fitxer acabat. Aquesta diferència és el preu de no poder agrupar en batch, i és el que encareix la secció següent.

Ara la xifra que decideix si la veu és una funcionalitat o un producte.

La trucada: una conversa de suport de deu torns, 149 paraules, que a 150 paraules per minut declarades són 59,6 segons de parla: 21,2 parlats per qui truca, 38,4 retornats en veu. Les conversions de token són les dels mateixos proveïdors. OpenAI: «els audio tokens en missatges d’usuari són 1 token per cada 100 ms d’àudio, mentre que els audio tokens en missatges de l’assistent són 1 token per cada 50 ms».¹⁴ Google: 25 tokens per segon, en totes dues direccions, cosa que la seva pàgina de preus confirma publicant $12.00 per milió i $0.018 per minut a la mateixa línia.¹²

La conversa s’acumula exactament com deia el capítol 16, perquè és el mateix mecanisme: «tota la conversa s’envia al model per a cada Response... per tant, els torns posteriors de la sessió seran més cars».¹⁴ Només que ara l’historial es mesura en audio tokens.

Ara la comparació que decideix el producte, totes quatre normalitzades a un minut:

Trenta-vuit vegades. No trenta-vuit per cent. El mateix intercanvi, fet amb so en lloc de text, és gairebé dos ordres de magnitud més car, i cap part d’aquesta diferència és un marge que algú hagi decidit cobrar: és el tipus de conversió. Un segon d’àudio d’assistant són vint tokens. Aquell mateix segon porta 2,5 paraules al ritme declarat, i la transcripció mesurada surt a 1,26 tokens per paraula, així que com a text són 3,15 tokens. El so és un paquet 6,3 vegades més voluminós pel mateix significat, i cadascun dels seus tokens es factura a 5,3 vegades la tarifa de text output i 16 vegades la tarifa de text input. Multiplica una relació de volum per una relació de preu i l’ordre de magnitud ja hi és abans que comenci cap comptabilitat.

De la taula en surten directament dues conseqüències operatives.

L’audio caching no és una optimització, és el model de negoci. L’entrada d’àudio en cache és $0.40 per milió contra $32.00 en fresc: un descompte del 98,75 % que redueix la trucada a la meitat. La regla és la del capítol 16, sense canvis: la cache coincideix amb un prefix, així que qualsevol cosa inserida al davant de la conversa a mitja trucada la destrueix, i el lloc natural per posar «la persona que truca ja està verificada» és exactament allà.

I res del que facis al client desfactura un so. L’usuari parla per sobre de l’assistant, el teu codi atura la reproducció, l’altaveu calla. El que ja s’havia generat ja s’havia cobrat, perquè la facturació s’acumula quan es crea la resposta; i segons la regla del capítol 16, tot el que queda a la conversa es torna a enviar, com a àudio d’entrada, a cada torn posterior. El capítol 14 ho deia sobre avortar un stream de text. En veu costa trenta vegades més.

Alguns proveïdors venen vídeo per segon i d’altres per clip, amb trams per resolució i de vegades per durada. Aquestes dues formes no només difereixen en comoditat; s’encreuen.

El proveïdor per clip és més car que el de per segon per sota d’1,2 segons i 16,7 vegades més barat a vint. Cap ordenació d’aquests dos models sobreviu a un canvi de durada del clip, així que «quin model de vídeo és més barat» no és una pregunta sobre models.

L’última fila és pitjor, i és el cor honest del capítol. mochi es factura contra segons reals de GPU —el temps de predicció mesurat de la feina— a $0.001400 per segon en una A100 i $0.001525 en una H100, que són les tarifes de la màquina llogada i res més.¹⁵ És una tarifa perfectament precisa i no és un preu, perquè la quantitat que multiplica és desconeguda fins després que t’hagis compromès a pagar-la. La fila de dalt assumeix dotze segons de GPU per segon de sortida; quadruplica aquest supòsit i surt del tram més barat, i només a sis vegades aterra a mitja taula. És l’única tarifa d’aquesta pàgina que no pots posar en un pressupost.

Així doncs: tokens, image tokens, caràcters, minuts, segons de vídeo, clips sencers, segons de GPU, unitats planes. Vuit quantitats, i l’única manera de posar-les en un mateix eix és declarar una càrrega de treball i posar-li preu.

Aquesta és l’extensió del computeCost del capítol 16: la mateixa maquinària de trams, ara amb criteris que no són la llargada del 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 dues línies marcades són on es trenca. Una tarifa citada per unitat multiplica u.images ?? 1; una tarifa citada per token multiplica alguna cosa que per defecte és zero. Dona a totes dues un ús buit —la forma que obtens quan una mesura ha fallat— i mira:

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

No ha passat res, sis vegades, i ha costat tres dòlars una vegada i res cinc vegades. No és una diferència d’arrodoniment; és una decisió sobre què vol dir un nombre absent, presa per separat per a cada unitat i mai escrita. La regla sensata és que un camp que ningú no ha mesurat continua absent, perquè «no mesurat» i «mesurat i ha sortit zero» són coses diferents. Aquesta funció hi discrepa en silenci.

La segona fallada és la durada. La tarifa per clip selecciona el seu tram amb maxDurationSeconds contra u.videoSeconds ?? 0, de manera que un ús que mai no ha registrat una durada encaixa amb el tram més curt:

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

Un quaranta per cent de descompte per no saber quant durava el vídeo. Tots dos errors tenen la mateixa arrel: un valor per defecte triat per comoditat dins d’una funció que té com a única feina ser exacta.

Amb els costos computables, la comparació necessita l’altra meitat: una càrrega de treball representativa declarada, una per engine, exposada en públic perquè el lector hi pugui discrepar:

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 },
};

Cada una d’aquestes línies és un argument. El text barreja un quart d’entrada i tres quarts de sortida perquè l’ús real s’inclina cap a la sortida; una barreja cinquanta-cinquanta ordena els models diferent. La càrrega d’imatge assumeix 1.500 output tokens, entre els 1.056 d’OpenAI per a un quadrat medium i els 1.584 per a un retrat medium. El vídeo assumeix cinc segons a 1080p, i acabem de veure dos proveïdors intercanviar-se el lloc a 1,2 segons. L’entrada de computació assumeix seixanta segons de GPU perquè no hi ha res més a assumir.

Aquest és el mètode, i és l’únic honest disponible: no pots comparar preus en unitats diferents; només pots comparar el cost d’una càrrega de treball que has escrit. Qualsevol taula que ordeni models multimodals sense imprimir la seva càrrega de treball està ordenant els seus propis supòsits.

Ara pots posar preu a qualsevol cosa que pugui produir un model, en la unitat en què es vengui, i dir en veu alta quina càrrega de treball ha assumit la comparació. Això tanca la factura que va obrir el capítol 16, i tanca la part III: tot, del capítol 14 fins aquí, ha anat sobre una crida: com fer-la, què posar-hi, com mostrejar-la, què retorna, què costa.

El capítol 22 canvia la unitat d’anàlisi, i el canvi és car. Un agent no és una crida; és un bucle que decideix per si mateix quantes crides farà, i l’aritmètica dels dos últims capítols és el que converteix això d’un diagrama d’arquitectura en un pressupost. Comença fent la mateixa pregunta al mateix model dues vegades, amb una eina afegida al catàleg la segona vegada, i mesurant què ha fet aquella eina: una crida es va convertir en dues, trenta-nou input tokens es van convertir en 420.

Que això el converteixi en un agent depèn de quina de dues definicions publicades obris, i no coincideixen. Una d’elles no coincideix ni amb si mateixa.

Cada preu, fórmula i tipus de conversió d’aquest capítol s’ha llegit a la pàgina pròpia del proveïdor el 7 de setembre de 2026 i se cita amb aquesta data, perquè tots es mouran. Els recomptes de token, costos i comparacions s’han calculat sobre aquestes dades amb el codi imprès més amunt, en una sola màquina, sense fer cap crida API de pagament; que és també el motiu honest pel qual no hi ha ni una sola afirmació de latència en aquest capítol.

Les funcions d’image-token, les taules de cost, el desglossament de la trucada de veu i els resultats d’ús buit s’han produït amb el TypeScript imprès en aquest capítol, executat sobre Node 22. El diàleg usat per a la comparació de veu té 149 paraules i s’ha tokenitzat amb tiktoken sota la codificació o200k_base a 188 tokens; la seva durada deriva d’un ritme declarat de 150 paraules per minut, que és un paràmetre de la comparació i no una mesura. Cada xifra de proveïdor porta la nota que anomena la pàgina d’on ve.