Preços multimodais: o que imagens, áudio e vídeo faturam realmente

Um transformer recebe uma sequência de vetores. Não tem opinião sobre a origem deles. O Capítulo 8 alimentou-o com embeddings procurados a partir de um token id; nada na arquitetura exige essa consulta.

Portanto: corte a imagem em quadrados fixos, achate cada quadrado numa lista de números e passe cada lista por uma camada linear aprendida para obter um vetor com a largura do modelo. Um patch 32 × 32 de píxeis de cor são $32 \times 32 \times 3 = 3072$ números; a projeção $E \in \mathbb{R}^{d \times 3072}$ transforma-o num vetor de $d$ dimensões, exatamente com a forma em que chega um token de texto. É tudo, e é o artigo cujo título o diz: uma imagem vale 16 × 16 palavras.¹ Acrescente uma codificação posicional para o modelo saber que quadrado estava onde, intercale os resultados com os text embeddings, e a sequência que o modelo lê é parte imagem e parte frase.

Três artigos transformaram isto num produto. CLIP treinou um image encoder e um text encoder para concordarem, em quatrocentos milhões de pares recolhidos da Web, e foi aí que a ideia de píxeis e palavras poderem partilhar um espaço deixou de ser hipótese.² Flamingo aparafusou um vision encoder congelado a um modelo de linguagem congelado com algumas camadas de ponte treinadas.³ LLaVA mostrou que a ponte podia ser uma única projeção linear e que o seguimento de instruções podia ser ensinado com dados gerados, que é a razão pela qual todos os modelos abertos de visão-linguagem desde então têm aproximadamente a mesma forma.⁴

A consequência para a sua fatura é imediata e pouco glamorosa: os patches são posições na sequência, logo são input tokens, logo paga por eles à taxa de input. Quantos são é aritmética, e cada fornecedor fá-la de maneira diferente.

Todas as regras abaixo estão implementadas a partir da documentação do próprio fornecedor e verificadas contra os exemplos resolvidos nessa mesma documentação.

A OpenAI cobre a imagem com patches 32 × 32 e multiplica a contagem por um fator por modelo. Se a contagem de patches exceder o orçamento desse modelo e nível de detalhe, a imagem é reduzida até caber:

A Anthropic cobre-a com patches 28 × 28, um visual token cada, e limita tanto a aresta longa como a contagem de tokens — 1,568 píxeis e 1,568 tokens nos modelos de escalão standard, 2,576 e 4,784 no escalão de alta resolução. Imagens demasiado grandes são reduzidas para o maior tamanho que respeite ambos.⁵

A Google não conta píxeis de todo. Uma imagem com ambos os lados até 384 píxeis custa uma taxa fixa de 258 tokens. Qualquer coisa maior é cortada em tiles de 258 tokens cada, e a grelha de tiles vem de uma unidade de crop 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;      
}

Execute cada uma contra os números que o seu próprio fornecedor imprime:

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ão impressas nove concordâncias; a execução completa verifica quinze, porque a tabela da Anthropic dá ambos os escalões para todos os seis tamanhos. As regras são agora suas para correr em qualquer fotografia que tenha, que é o ponto: estas são as únicas três funções neste capítulo que não consegue obter numa página de preços.

Passe a mesma fotografia 4:3 pelas três regras em seis tamanhos:

Leia a última coluna de cima para baixo. Assim que a imagem passa os 384 píxeis, o número nunca mais muda, e isso não é coincidência nem limite. Substitua a unidade de crop de volta na fórmula dos tiles, para uma imagem pelo menos tão larga como alta:

O tamanho cancela. Os image tokens da Google dependem do aspect ratio e de mais nada. Uma fotografia 4:3 são quatro tiles, quer seja uma miniatura ou um cartaz. Esse único facto algébrico é toda a explicação para o zero na tabela de poupança acima, e nenhuma página de preços em lado nenhum o afirma.

As outras duas colunas impõem limites, em vez disso, a alturas diferentes e por razões diferentes — a Anthropic num teto declarado de tokens, a OpenAI num orçamento de patches depois de um limite de píxeis — e é por isso que as três curvas se cruzam em tamanhos diferentes.

Agora parta a intuição. A forma óbvia de gastar menos num modelo de visão é pedir menos detalhe, por isso envie detail: "low":

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

Pedir menos detalhe custou 25 % mais. Isto não é um bug e a OpenAI di-lo numa linha da tabela de dimensionamento: nessa família de modelos, low usa um limite de 2048 píxeis com um orçamento de 6,144 patches, enquanto high usa o mesmo limite de píxeis com um orçamento de 2,500 patches, «por isso pode usar mais tokens do que high».⁷ A palavra low designa uma definição de fidelidade, não um preço: em duas das cinco famílias de modelos documentadas não compra poupança nenhuma, e numa dessas duas custa mais.

Tudo até aqui foi um modelo a ler uma imagem. Fazer uma imagem corre num mecanismo sem tokens nenhuns, e é essa a razão pela qual é vendido à imagem e não à palavra.

Os fornecedores publicam geração de imagens como preço por imagem. Não é. Os modelos GPT Image emitem image tokens especializados cuja contagem depende do tamanho e da qualidade pedidos; multiplique as contagens publicadas pela taxa de image output publicada do GPT Image 1, $40 por milhão, e compare com os preços por imagem na mesma página:

Nove valores derivados contra nove publicados, cada par a concordar dentro de $0.002.¹¹ A Google é ainda mais explícita e faz a conversão por si na própria página de preços: image output a $60 por milhão de tokens, «output images at 1K (1024x1024px) consume 1120 tokens and are equivalent to $0.067 per image».¹²

Portanto, um preço por imagem é um preço por token com a contagem dobrada lá dentro. O que está bem, e esconde uma coisa. Pegue na tabela da geração atual e divida ao contrário:

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

A imagem maior é a mais barata em todas as qualidades. Um canvas 1024 × 1536 tem mais 50 % de píxeis do que um 1024 × 1024 e custa menos 23 % de tokens em medium. A OpenAI assinala isto numa frase que saltaria por cima — «a larger non-square resolution can sometimes produce fewer output tokens than a smaller or square resolution at the same quality setting» — e na geração anterior de modelos acontecia o inverso, com portrait a custar 50 % mais do que square.¹¹ Todos os defaults de 1024x1024 escritos antes dessa mudança são agora a opção cara.

Peça a três produtos para falar os mesmos 519 caracteres — cerca de 38 segundos de áudio — e obtém três sistemas de unidades de dois fornecedores:

O mesmo fornecedor vende ambas as unidades: o tts-1 da OpenAI tem preço por milhão de caracteres, enquanto gpt-4o-mini-tts tem preço por milhão de tokens, $0.60 de entrada e $12.00 de saída.¹³ Portanto, «text-to-speech mais barato» não é uma pergunta com resposta até dizer o que vai ser falado.

E as duas unidades são cegas a coisas opostas. Um preço por carácter não vê duração: escolha uma voz lenta e deliberada, ou acrescente pausas, e a fatura não se mexe enquanto o áudio fica mais longo. Um preço por segundo não vê conteúdo: trinta segundos custam o mesmo quer sejam um parágrafo técnico denso ou alguém a contar até dez. Mude a voz e exatamente um dos seus dois fornecedores recalcula o preço.

A transcrição vai no sentido oposto e é a linha mais simples de toda a fatura — por minuto de áudio, fixa:

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)

Repare na última linha contra a terceira: fazê-lo em direto, à medida que as palavras chegam, custa 5,7 vezes fazê-lo sobre um ficheiro terminado. Essa diferença é o preço de não poder fazer batch, e é o que torna a secção seguinte cara.

Agora o número que decide se a voz é uma funcionalidade ou um produto.

A chamada: uma conversa de suporte de dez turnos, 149 palavras, que a uma taxa declarada de 150 palavras por minuto dá 59,6 segundos de fala — 21,2 falados por quem liga, 38,4 respondidos. As conversões de tokens são dos próprios fornecedores. 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, em ambas as direções, o que a sua página de preços confirma ao publicar $12.00 por milhão e $0.018 por minuto na mesma linha.¹²

A conversa acumula exatamente como o Capítulo 16 disse que acumularia, porque é o mesmo mecanismo: «the entire conversation is sent to the model for each Response... thus turns later in the session will be more expensive».¹⁴ Só que agora o histórico é medido em audio tokens.

Agora a comparação que decide o produto, todos os quatro normalizados para um minuto:

Trinta e oito vezes. Não trinta e oito por cento. A troca idêntica, conduzida em som em vez de texto, é quase duas ordens de magnitude mais cara, e nenhuma parte dessa diferença é uma margem que alguém decidiu cobrar — é a taxa de conversão. Um segundo de áudio do assistant são vinte tokens. Esse mesmo segundo transporta 2,5 palavras à taxa declarada, e a transcrição medida dá 1,26 tokens por palavra, por isso em texto são 3,15 tokens. Som é um pacote 6,3 vezes mais volumoso para o mesmo significado, e cada um dos seus tokens é faturado a 5,3 vezes a taxa de text output e 16 vezes a taxa de text input. Multiplique uma razão de volume por uma razão de preço e a ordem de magnitude já lá está antes de qualquer contabilidade começar.

Duas consequências operacionais saem diretamente da tabela.

Audio caching não é uma otimização, é o modelo de negócio. Cached audio input custa $0.40 por milhão contra $32.00 fresh — um desconto de 98,75 % que corta a chamada para metade. A regra é a do Capítulo 16, sem alterações: a cache corresponde a um prefixo, por isso qualquer coisa inserida no início da conversa a meio da chamada destrói-a, e o lugar natural para pôr «o chamador está agora verificado» é precisamente aí.

E nada do que fizer no cliente desfatura um som. O utilizador fala por cima do assistant, o seu código para a reprodução, a coluna fica em silêncio. O que já tinha sido gerado já tinha sido cobrado, porque a faturação acumula quando a resposta é criada; e pela regra do Capítulo 16, o que ficar na conversa é reenviado, como input audio, em todos os turnos seguintes. O Capítulo 14 fez este ponto sobre abortar um stream de texto. Em voz custa trinta vezes mais.

Vídeo é vendido por segundo por alguns fornecedores e por clip por outros, com escalões por resolução e por vezes por duração. Essas duas formas não diferem apenas em conveniência; cruzam-se.

O fornecedor por clip é mais caro do que o de por segundo abaixo de 1,2 segundos e 16,7 vezes mais barato aos vinte. Nenhuma ordenação desses dois modelos sobrevive a uma mudança no comprimento do clip, por isso «qual modelo de vídeo é mais barato» não é uma pergunta sobre modelos.

A última linha é pior, e é o coração honesto do capítulo. mochi é faturado contra segundos reais de GPU — o tempo de previsão medido do trabalho — a $0.001400 por segundo numa A100 e $0.001525 numa H100, que são as taxas da máquina alugada e nada mais.¹⁵ É uma tarifa perfeitamente precisa e não é um preço, porque a quantidade que multiplica é desconhecida até depois de se comprometer a pagá-la. A linha acima assume doze GPU-segundos por segundo de output; quadruplicar essa suposição tira-o da faixa mais barata, e só a seis vezes o coloca a meio da tabela. É a única tarifa nesta página que não consegue pôr num orçamento.

Portanto: tokens, image tokens, caracteres, minutos, segundos de vídeo, clips inteiros, GPU-segundos, unidades fixas. Oito quantidades, e a única forma de as pôr num eixo é declarar uma carga de trabalho e calcular-lhe o preço.

Essa é a extensão ao computeCost do Capítulo 16 — a mesma maquinaria de escalões, agora com critérios que não são o comprimento do 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;
}

As duas linhas assinaladas são onde isto falha. Uma tarifa cotada por unidade multiplica u.images ?? 1; uma tarifa cotada por token multiplica algo que por defeito é zero. Dê às duas uma utilização vazia — a forma que obtém quando uma medição falhou — e veja:

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

Nada aconteceu, seis vezes, e custou três dólares uma vez e nada cinco vezes. Isto não é diferença de arredondamento; é uma decisão sobre o que significa um número ausente, tomada separadamente para cada unidade e nunca escrita. A regra sensata é que um campo que ninguém mediu fica ausente, porque «não medido» e «medido e deu zero» são coisas diferentes. Esta função discorda em silêncio.

A segunda falha é a duração. A tarifa por clip escolhe o seu escalão com maxDurationSeconds contra u.videoSeconds ?? 0, por isso uma utilização que nunca registou uma duração corresponde ao escalão mais curto:

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

Quarenta por cento de desconto por não saber quanto tempo durou o vídeo. Ambos os bugs têm a mesma raiz: um default escolhido por conveniência dentro de uma função cujo trabalho inteiro é ser exata.

Com os custos calculáveis, a comparação precisa da outra metade — uma carga de trabalho representativa declarada, uma por engine, dita em público para que o leitor possa discordar dela:

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 uma dessas linhas é um argumento. Texto mistura um quarto de input e três quartos de output porque a utilização real pende para output; uma mistura cinquenta-cinquenta ordena os modelos de outra forma. A carga de imagem assume 1,500 output tokens, entre os 1,056 da OpenAI para um quadrado medium e os seus 1,584 para um portrait medium. Vídeo assume cinco segundos a 1080p, e acabámos de ver dois fornecedores trocar de lugar a 1,2 segundos. A entrada de compute assume sessenta GPU-segundos porque não há mais nada para assumir.

Esse é o método, e é o único honesto disponível: não pode comparar preços em unidades diferentes; só pode comparar o custo de uma carga de trabalho que escreveu. Qualquer tabela que ordene modelos multimodais sem imprimir a sua carga de trabalho está a ordenar as suas próprias suposições.

Agora consegue atribuir preço a qualquer coisa que um modelo possa produzir, em qualquer unidade em que seja vendida, e dizer em voz alta qual foi a carga de trabalho assumida pela comparação. Isso fecha a fatura que o Capítulo 16 abriu, e fecha a Parte III: tudo do Capítulo 14 até aqui foi sobre uma chamada — como fazê-la, o que pôr nela, como a amostrar, o que devolve, quanto custa.

O Capítulo 22 muda a unidade de análise, e a mudança é cara. Um agent não é uma chamada; é um ciclo que decide por si mesmo quantas chamadas fazer, e a aritmética dos últimos dois capítulos é o que transforma isso de um diagrama de arquitetura num orçamento. Abre fazendo a mesma pergunta ao mesmo modelo duas vezes, com uma ferramenta acrescentada ao catálogo da segunda vez, e medindo o que essa única ferramenta fez: uma chamada tornou-se duas, trinta e nove input tokens tornaram-se 420.

Se isso faz dele um agent depende de qual de duas definições publicadas abre, e elas não concordam. Uma delas não concorda consigo própria.

Todos os preços, fórmulas e taxas de conversão neste capítulo foram lidos na página do próprio fornecedor em 7 de setembro de 2026 e são citados com essa data, porque todos vão mudar. As contagens de tokens, custos e comparações foram calculados sobre esses dados pelo código impresso acima, numa máquina, sem nenhuma chamada de API paga — que é também a razão honesta pela qual não há uma única afirmação de latência neste capítulo.

As funções de image-token, as tabelas de custos, a decomposição da chamada de voz e os resultados de utilização vazia foram produzidos pelo TypeScript impresso neste capítulo, corrido em Node 22. O diálogo usado para a comparação de voz tem 149 palavras e foi tokenized com tiktoken sob a codificação o200k_base em 188 tokens; a sua duração resulta de uma taxa declarada de 150 palavras por minuto, que é um parâmetro da comparação e não uma medição. Cada valor de fornecedor traz a nota de rodapé que nomeia a página de onde veio.