Precios multimodales: qué facturan de verdad las imágenes, el audio y el vídeo

Un transformer recibe una secuencia de vectores. No tiene opinión sobre de dónde vienen. El capítulo 8 le alimentó embeddings buscados a partir de un id de token; nada en la arquitectura exige esa búsqueda.

Así que: corta la imagen en cuadrados fijos, aplana cada cuadrado en una lista de números y pasa cada lista por una capa lineal aprendida para obtener un vector del ancho del modelo. Un parche de 32 × 32 píxeles de color son $32 \times 32 \times 3 = 3072$ números; la proyección $E \in \mathbb{R}^{d \times 3072}$ lo convierte en un vector de $d$ dimensiones, exactamente la forma con la que llega un token de texto. Eso es todo, y es el paper cuyo título lo dice: una imagen vale 16 × 16 palabras.¹ Añade una codificación posicional para que el modelo sepa qué cuadrado estaba dónde, entrelaza los resultados con los embeddings de texto, y la secuencia que lee el modelo es parte imagen y parte frase.

Tres papers lo convirtieron en producto. CLIP entrenó un codificador de imágenes y un codificador de texto para ponerse de acuerdo, sobre cuatrocientos millones de pares extraídos de la web, y ahí fue donde la idea de que píxeles y palabras podían compartir un espacio dejó de ser una hipótesis.² Flamingo acopló un codificador de visión congelado a un modelo de lenguaje congelado con unas pocas capas puente entrenadas.³ LLaVA mostró que el puente podía ser una única proyección lineal y que el seguimiento de instrucciones podía enseñarse con datos generados, que es la razón por la que desde entonces todos los modelos abiertos de visión-lenguaje se parecen más o menos.⁴

La consecuencia para tu factura es inmediata y poco glamourosa: los parches son posiciones en la secuencia, así que son input tokens, así que pagas por ellos a la tarifa de entrada. Cuántos son es aritmética, y cada proveedor la hace de forma distinta.

Cada regla de abajo está implementada a partir de la documentación del propio proveedor y comprobada con los ejemplos resueltos de esa misma documentación.

OpenAI cubre la imagen con parches de 32 × 32 y multiplica el recuento por un factor por modelo. Si el número de parches supera el presupuesto de ese modelo y nivel de detalle, la imagen se escala hacia abajo hasta que encaja:

Anthropic la cubre con parches de 28 × 28, un visual token cada uno, y limita tanto el lado largo como el recuento de tokens: 1,568 píxeles y 1,568 tokens en modelos de tramo estándar, 2,576 y 4,784 en el tramo de alta resolución. Las imágenes demasiado grandes se escalan al mayor tamaño que cumpla ambas condiciones.⁵

Google no cuenta píxeles en absoluto. Una imagen con ambos lados en 384 píxeles o menos cuesta una tarifa plana de 258 tokens. Cualquier imagen mayor se corta en teselas de 258 tokens cada una, y la cuadrícula de teselas sale de una unidad de recorte 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;      
}

Ejecuta cada una contra los números que imprime su propio proveedor:

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

Se imprimen nueve coincidencias; la ejecución completa comprueba quince, porque la tabla de Anthropic da ambos tramos para los seis tamaños. Las reglas ya son tuyas para ejecutarlas sobre cualquier fotografía que tengas, y ese es el punto: estas son las únicas tres funciones de este capítulo que no puedes obtener de una página de precios.

Pasa la misma fotografía 4:3 por las tres reglas en seis tamaños:

Lee la última columna hacia abajo. Una vez que la imagen supera los 384 píxeles, el número no vuelve a cambiar, y eso no es una coincidencia ni un tope. Sustituye la unidad de recorte de nuevo en la fórmula de teselas, para una imagen al menos tan ancha como alta:

El tamaño se cancela. Los image tokens de Google dependen de la relación de aspecto y de nada más. Una fotografía 4:3 son cuatro teselas tanto si es una miniatura como si es un póster. Ese único hecho algebraico es toda la explicación del cero en la tabla de ahorro de arriba, y ninguna página de precios lo dice.

Las otras dos columnas sí hacen tope, a alturas distintas y por razones distintas —Anthropic en un techo declarado de tokens, OpenAI en un presupuesto de parches después de un límite de píxeles—, por eso las tres curvas se cruzan en tamaños distintos.

Ahora rómpelo. La forma obvia de gastar menos en un modelo de visión es pedir menos detalle, así que envía detail: "low":

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

Pedir menos detalle costó un 25 % más. No es un bug, y OpenAI lo dice en una línea de la tabla de tamaños: en esa familia de modelos, low usa un límite de 2048 píxeles con un presupuesto de 6,144 parches, mientras que high usa el mismo límite de píxeles con un presupuesto de 2,500 parches, «so it can use more tokens than high».⁷ La palabra low nombra un ajuste de fidelidad, no un precio: en dos de las cinco familias de modelos documentadas no compra ningún ahorro, y en una de esas dos cuesta más.

Todo hasta ahora ha sido un modelo leyendo una imagen. Hacer una funciona con un mecanismo que no tiene tokens en absoluto, y esa es la razón por la que se vende por imagen en lugar de por palabra.

Los proveedores publican la generación de imágenes como un precio por imagen. No lo es. Los modelos GPT Image emiten image tokens especializados cuyo recuento depende del tamaño y la calidad solicitados; multiplica los recuentos publicados por la tarifa de salida de imagen publicada para GPT Image 1, $40 por millón, y compáralos con los precios por imagen de la misma página:

Nueve cifras derivadas frente a nueve publicadas, y cada par coincide con un margen inferior a $0.002.¹¹ Google es aún más explícito y hace la conversión por ti en la propia página de precios: salida de imagen a $60 por millón de tokens, «output images at 1K (1024x1024px) consume 1120 tokens and are equivalent to $0.067 per image».¹²

Así que un precio por imagen es un precio por token con el recuento plegado dentro. Lo cual está bien, y oculta algo. Toma la tabla de la generación actual y divide hacia atrás:

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 imagen más grande es la más barata en todas las calidades. Un lienzo de 1024 × 1536 tiene un 50 % más de píxeles que uno de 1024 × 1024 y cuesta un 23 % menos de tokens en calidad media. OpenAI lo señala en una frase que te saltarías: «a larger non-square resolution can sometimes produce fewer output tokens than a smaller or square resolution at the same quality setting», y en la generación anterior del modelo iba al revés, con el retrato costando un 50 % más que el cuadrado.¹¹ Cada valor por defecto de 1024x1024 escrito antes de ese cambio es ahora la opción cara.

Pide a tres productos que pronuncien los mismos 519 caracteres —unos 38 segundos de audio— y obtienes tres sistemas de unidades de dos proveedores:

El mismo proveedor vende ambas unidades: tts-1 de OpenAI tiene precio por millón de caracteres, mientras que gpt-4o-mini-tts tiene precio por millón de tokens, $0.60 de entrada y $12.00 de salida.¹³ Así que «el text-to-speech más barato» no es una pregunta con respuesta hasta que dices qué vas a pronunciar.

Y las dos unidades son ciegas a cosas opuestas. Un precio por carácter no puede ver la duración: elige una voz lenta y deliberada, o añade pausas, y la factura no se mueve mientras el audio se alarga. Un precio por segundo no puede ver el contenido: treinta segundos cuestan lo mismo si son un párrafo técnico denso o alguien contando hasta diez. Cambia la voz y exactamente uno de tus dos proveedores cambia el precio.

La transcripción va en la dirección contraria y es la línea más simple de toda la factura: por minuto de audio, plano:

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)

Fíjate en la última fila frente a la tercera: hacerlo en directo, a medida que llegan las palabras, cuesta 5,7 veces más que hacerlo sobre un archivo terminado. Esa brecha es el precio de no poder hacer batch, y es lo que encarece la siguiente sección.

Ahora el número que decide si la voz es una función o un producto.

La llamada: una conversación de soporte de diez turnos, 149 palabras, que a una velocidad declarada de 150 palabras por minuto son 59,6 segundos de habla: 21,2 hablados por quien llama, 38,4 devueltos como respuesta. Las conversiones a tokens son las de los propios proveedores. OpenAI: «audio tokens in user messages are 1 token per 100 ms of audio, while audio tokens in assistant messages are 1 token per 50 ms».¹⁴ Google: 25 tokens por segundo, en ambas direcciones, algo que su página de precios confirma al publicar $12.00 por millón y $0.018 por minuto en la misma línea.¹²

La conversación se acumula exactamente como dijo el capítulo 16, porque es el mismo mecanismo: «the entire conversation is sent to the model for each Response... thus turns later in the session will be more expensive».¹⁴ Solo que ahora el historial se mide en audio tokens.

Ahora la comparación que decide el producto, las cuatro normalizadas a un minuto:

Treinta y ocho veces. No treinta y ocho por ciento. El intercambio idéntico, llevado a cabo en sonido en lugar de texto, es casi dos órdenes de magnitud más caro, y nada de esa brecha es un margen que alguien haya decidido cobrar: es la tasa de conversión. Un segundo de audio del asistente son veinte tokens. Ese mismo segundo transporta 2,5 palabras a la velocidad declarada, y la transcripción medida da 1,26 tokens por palabra, así que como texto son 3,15 tokens. El sonido es un paquete 6,3 veces más voluminoso para el mismo significado, y cada uno de sus tokens se factura a 5,3 veces la tarifa de salida de texto y 16 veces la tarifa de entrada de texto. Multiplica una relación de volumen por una relación de precio y el orden de magnitud ya está ahí antes de que empiece cualquier contabilidad.

De la tabla salen directamente dos consecuencias operativas.

La caché de audio no es una optimización, es el modelo de negocio. La entrada de audio en caché cuesta $0.40 por millón frente a $32.00 fresca: un descuento del 98,75 % que reduce la llamada a la mitad. La regla es la del capítulo 16, sin cambios: la caché empareja un prefijo, así que cualquier cosa insertada al principio de la conversación en mitad de la llamada la destruye, y el lugar natural para poner «la persona que llama ya está verificada» es exactamente ahí.

Y nada de lo que hagas en el cliente desfactura un sonido. El usuario habla encima del asistente, tu código detiene la reproducción, el altavoz se calla. Todo lo que ya se había generado ya se había cobrado, porque la facturación se acumula cuando se crea la respuesta; y por la regla del capítulo 16, todo lo que permanece en la conversación se reenvía, como audio de entrada, en cada turno posterior. El capítulo 14 hizo este punto sobre abortar un stream de texto. En voz cuesta treinta veces más.

Algunos proveedores venden vídeo por segundo y otros por clip, con tramos por resolución y a veces por duración. Esas dos formas no solo difieren en comodidad; se cruzan.

El proveedor por clip es más caro que el proveedor por segundo por debajo de 1,2 segundos y 16,7 veces más barato a los veinte. Ningún orden entre esos dos modelos sobrevive a un cambio en la duración del clip, así que «qué modelo de vídeo es más barato» no es una pregunta sobre modelos.

La última fila es peor, y es el corazón honesto del capítulo. mochi se factura contra segundos reales de GPU —el tiempo de predicción medido del trabajo— a $0.001400 por segundo en una A100 y $0.001525 en una H100, que son las tarifas de la máquina alquilada y nada más.¹⁵ Es una tarifa perfectamente precisa y no es un precio, porque la cantidad por la que multiplica se desconoce hasta después de que te hayas comprometido a pagarla. La fila de arriba asume doce GPU-segundos por segundo de salida; cuadruplica esa suposición y sale de la banda más barata, y solo a seis veces aterriza a mitad de tabla. Es la única tarifa de esta página que no puedes meter en un presupuesto.

Así que: tokens, image tokens, caracteres, minutos, segundos de vídeo, clips completos, GPU-segundos, unidades planas. Ocho magnitudes, y la única forma de ponerlas en un eje es declarar una carga de trabajo y ponerle precio.

Esa es la ampliación del computeCost del capítulo 16: la misma maquinaria de tramos, ahora con criterios que no son la longitud 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;
}

Las dos líneas marcadas son donde se rompe. Una tarifa cotizada por unidad multiplica u.images ?? 1; una tarifa cotizada por token multiplica algo que por defecto es cero. Alimenta ambas con un uso vacío —la forma que obtienes cuando falla una medición— y 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 pasó nada, seis veces, y costó tres dólares una vez y nada cinco veces. No es una diferencia de redondeo; es una decisión sobre qué significa un número ausente, tomada por separado para cada unidad y nunca escrita. La regla sensata es que un campo que nadie midió permanece ausente, porque «no medido» y «medido y salió cero» son cosas distintas. Esta función discrepa en silencio.

El segundo fallo es la duración. La tarifa por clip selecciona su tramo con maxDurationSeconds contra u.videoSeconds ?? 0, así que un uso que nunca registró duración coincide con el tramo más corto:

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

Cuarenta por ciento de descuento por no saber cuánto duraba el vídeo. Ambos bugs tienen la misma raíz: un valor por defecto elegido por comodidad dentro de una función cuyo trabajo entero es ser exacta.

Con los costes calculables, la comparación necesita la otra mitad: una carga de trabajo representativa declarada, una por motor, expuesta públicamente para que el lector pueda 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 de esas líneas es un argumento. El texto mezcla un cuarto de entrada y tres cuartos de salida porque el uso real se inclina hacia la salida; una mezcla al cincuenta por ciento clasifica los modelos de otra manera. La carga de trabajo de imagen asume 1,500 output tokens, entre los 1,056 de OpenAI para un cuadrado medio y sus 1,584 para un retrato medio. El vídeo asume cinco segundos a 1080p, y acabamos de ver que dos proveedores intercambian posiciones a 1,2 segundos. La entrada de cómputo asume sesenta GPU-segundos porque no hay nada más que asumir.

Ese es el método, y es el único honesto disponible: no puedes comparar precios en unidades distintas; solo puedes comparar el coste de una carga de trabajo que has escrito. Cualquier tabla que clasifique modelos multimodales sin imprimir su carga de trabajo está clasificando sus propias suposiciones.

Ahora puedes poner precio a cualquier cosa que un modelo pueda producir, en la unidad en que se venda, y decir en voz alta qué carga de trabajo asumió tu comparación. Eso cierra la factura que abrió el capítulo 16, y cierra la parte III: todo desde el capítulo 14 hasta aquí ha tratado de una llamada: cómo hacerla, qué meter en ella, cómo muestrearla, qué devuelve, cuánto cuesta.

El capítulo 22 cambia la unidad de análisis, y el cambio es caro. Un agent no es una llamada; es un bucle que decide por sí mismo cuántas llamadas hacer, y la aritmética de los dos últimos capítulos es lo que convierte eso de un diagrama de arquitectura en un presupuesto. Abre haciendo la misma pregunta al mismo modelo dos veces, con una tool añadida al catálogo la segunda vez, y midiendo qué hizo esa única tool: una llamada se convirtió en dos, treinta y nueve input tokens se convirtieron en 420.

Que eso lo convierta en un agent depende de cuál de dos definiciones publicadas abras, y no coinciden. Una de ellas no coincide consigo misma.

Cada precio, fórmula y tasa de conversión de este capítulo se leyó de la página del propio proveedor el 7 de septiembre de 2026 y se cita con esa fecha, porque todos se moverán. Los recuentos de tokens, costes y comparaciones se calcularon sobre esos datos con el código impreso arriba, en una máquina, sin hacer ninguna llamada de API de pago; que es también la razón honesta por la que no hay ni una sola afirmación de latencia en este capítulo.

Las funciones de image-token, las tablas de coste, el desglose de la llamada de voz y los resultados de uso vacío se produjeron con el TypeScript impreso en este capítulo, ejecutado en Node 22. El diálogo usado para la comparación de voz tiene 149 palabras y se tokenizó con tiktoken bajo la codificación o200k_base en 188 tokens; su duración sale de una velocidad declarada de 150 palabras por minuto, que es un parámetro de la comparación y no una medición. Cada cifra de proveedor lleva la nota al pie que nombra la página de la que procede.