Multimodal prissättning: vad bilder, ljud och video faktiskt debiterar

En transformer tar emot en sekvens av vektorer. Den har ingen åsikt om var de kom ifrån. Kapitel 8 matade den med embeddings som slogs upp från ett token-id; inget i arkitekturen kräver själva uppslagningen.

Alltså: skär bilden i fasta rutor, platta ut varje ruta till en lista med tal och skicka varje lista genom ett inlärt linjärt lager för att få en vektor med modellens bredd. En 32 × 32 patch med färgpixlar är $32 \times 32 \times 3 = 3072$ tal; projektionen $E \in \mathbb{R}^{d \times 3072}$ gör den till en $d$-dimensionell vektor, exakt samma form som en text-token anländer i. Det är hela saken, och det är artikeln vars titel säger det: en bild är värd 16 × 16 ord.¹ Lägg till en positionskodning så att modellen vet vilken ruta som låg var, fläta ihop resultaten med text-embeddings, och sekvensen modellen läser är delvis bild och delvis mening.

Tre artiklar gjorde det till en produkt. CLIP tränade en bild-encoder och en text-encoder att hålla med varandra, på fyrahundra miljoner skrapade par, och det var där idén att pixlar och ord kan dela ett rum slutade vara en hypotes.² Flamingo skruvade fast en frusen vision-encoder på en frusen språkmodell med några tränade brygglager.³ LLaVA visade att bryggan kunde vara en enda linjär projektion och att instruction-following kunde läras med genererade data, vilket är skälet till att varje öppen vision-language-modell sedan dess ser ungefär likadan ut.⁴

Konsekvensen för din faktura är omedelbar och oglamorös: patcharna är positioner i sekvensen, alltså är de input tokens, alltså betalar du för dem enligt input-priset. Hur många de är är aritmetik, och varje leverantör gör den annorlunda.

Varje regel nedan är implementerad från leverantörens egen dokumentation och kontrollerad mot de genomräknade exemplen i samma dokumentation.

OpenAI täcker bilden med 32 × 32 patches och multiplicerar antalet med en faktor per modell. Om patch-antalet överskrider budgeten för den modellen och detaljnivån skalas bilden ned tills den får plats:

Anthropic täcker den med 28 × 28 patches, en visual token vardera, och har tak både för långsidan och token-antalet — 1 568 pixlar och 1 568 tokens på standardmodeller, 2 576 och 4 784 på högupplösningsnivån. För stora bilder skalas till den största storlek som ryms inom båda.⁵

Google räknar inte pixlar alls. En bild där båda sidorna är högst 384 pixlar kostar fasta 258 tokens. Allt större skärs i tiles om 258 tokens styck, och tile-rutnätet kommer från en crop unit på $\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;      
}

Kör varje regel mot talen som dess egen leverantör trycker:

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

Nio överensstämmelser skrivs ut; hela körningen kontrollerar femton, eftersom Anthropics tabell ger båda nivåerna för alla sex storlekar. Reglerna är nu dina att köra på vilket fotografi du vill, vilket är poängen: det här är de enda tre funktionerna i kapitlet som du inte kan få från en prissida.

Skicka samma 4:3-fotografi genom alla tre i sex storlekar:

Läs sista kolumnen nedåt. När bilden väl är över 384 pixlar ändras talet aldrig igen, och det är varken en slump eller ett tak. Sätt tillbaka crop unit i tile-formeln, för en bild som är minst lika bred som den är hög:

Storleken försvinner. Googles image tokens beror på bildförhållandet och inget annat. Ett 4:3-fotografi är fyra tiles oavsett om det är en miniatyr eller en affisch. Det enda algebraiska faktumet är hela förklaringen till nollan i spartabellen ovan, och ingen prissida någonstans säger det.

De andra två kolumnerna har i stället tak, på olika höjder och av olika skäl — Anthropic vid ett deklarerat token-tak, OpenAI vid en patch-budget efter en pixelgräns — vilket är varför de tre kurvorna korsar varandra vid olika storlekar.

Bryt det nu. Det uppenbara sättet att spendera mindre på en vision-modell är att be om mindre detalj, så skicka detail: "low":

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

Att be om mindre detalj kostade 25 % mer. Det här är inte en bugg, och OpenAI säger det i en enda rad i storlekstabellen: på den modellfamiljen använder low en 2048-pixelgräns med en budget på 6 144 patches medan high använder samma pixelgräns med en budget på 2 500 patches, ”so it can use more tokens than high”.⁷ Ordet low namnger en fidelitetsinställning, inte ett pris: på två av de fem dokumenterade modellfamiljerna ger den ingen besparing alls, och på en av de två kostar den mer.

Allt hittills har handlat om en modell som läser en bild. Att skapa en körs på en mekanism utan tokens alls, och det är skälet till att den säljs per bild snarare än per ord.

Leverantörer publicerar bildgenerering som ett pris per bild. Det är inte det. GPT Image-modeller släpper ut specialiserade image tokens vars antal beror på begärd storlek och kvalitet; multiplicera de publicerade antalen med GPT Image 1:s publicerade bild-output-pris på $40 per miljon och jämför med priserna per bild på samma sida:

Nio härledda siffror mot nio publicerade, varje par överens inom $0.002.¹¹ Google är ännu tydligare och gör konverteringen åt dig på själva prissidan: bild-output för $60 per miljon tokens, ”output images at 1K (1024x1024px) consume 1120 tokens and are equivalent to $0.067 per image”.¹²

Ett pris per bild är alltså ett pris per token med antalet invikt. Det är okej, men det döljer något. Ta den nuvarande generationens tabell och dividera baklänges:

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

Den större bilden är den billigare vid varje kvalitet. En canvas på 1024 × 1536 har 50 % fler pixlar än en på 1024 × 1024 och kostar 23 % färre tokens vid medium. OpenAI flaggar det i en mening du skulle hoppa över — ”a larger non-square resolution can sometimes produce fewer output tokens than a smaller or square resolution at the same quality setting” — och på den tidigare modellgenerationen gick det åt andra hållet, där porträtt kostade 50 % mer än kvadrat.¹¹ Varje standardval av 1024x1024 som skrevs före den ändringen är nu det dyra alternativet.

Be tre produkter läsa upp samma 519 tecken — ungefär 38 sekunder ljud — och du får tre enhetssystem från två leverantörer:

Samma leverantör säljer båda enheterna: OpenAI:s tts-1 prissätts per miljon tecken medan gpt-4o-mini-tts prissätts per miljon tokens, $0.60 in och $12.00 ut.¹³ Så ”billigaste text-to-speech” är inte en fråga med ett svar förrän du säger vad som ska talas.

Och de två enheterna är blinda för motsatta saker. Ett pris per tecken kan inte se varaktighet: välj en långsam, eftertänksam röst, eller lägg till pauser, och fakturan rör sig inte medan ljudet blir längre. Ett pris per sekund kan inte se innehåll: trettio sekunder kostar lika mycket oavsett om det är ett tätt tekniskt stycke eller någon som räknar till tio. Byt röst och exakt en av dina två leverantörer prissätter om.

Transkribering går åt andra hållet och är den enklaste raden på hela fakturan — per minut ljud, fast:

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)

Notera sista raden mot den tredje: att göra det live, medan orden kommer in, kostar 5,7 gånger mer än att göra det på en färdig fil. Det gapet är priset för att inte kunna batcha, och det är vad som gör nästa avsnitt dyrt.

Nu talet som avgör om röst är en funktion eller en produkt.

Samtalet: en supportkonversation med tio turer, 149 ord, vilket vid deklarerade 150 ord per minut är 59,6 sekunder tal — 21,2 talade av uppringaren, 38,4 talade tillbaka. Token-konverteringarna är leverantörernas egna. 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 per sekund, i båda riktningar, vilket deras prissida bekräftar genom att publicera $12.00 per miljon och $0.018 per minut på samma rad.¹²

Konversationen ackumuleras exakt som Kapitel 16 sade att den skulle, eftersom det är samma mekanism: ”the entire conversation is sent to the model for each Response... thus turns later in the session will be more expensive”.¹⁴ Bara nu mäts historiken i audio tokens.

Nu jämförelsen som avgör produkten, alla fyra normaliserade till en minut:

Trettioåtta gånger. Inte trettioåtta procent. Exakt samma utbyte, genomfört i ljud i stället för text, är nästan två storleksordningar dyrare, och inget av det gapet är en marginal någon valde att ta ut — det är konverteringskursen. En sekund assistant-ljud är tjugo tokens. Samma sekund bär 2,5 ord vid den deklarerade takten, och den uppmätta transkriptionen ligger på 1,26 tokens per ord, så som text är den 3,15 tokens. Ljud är ett 6,3 gånger skrymmande paket för samma betydelse, och varje av dess tokens debiteras till 5,3 gånger textens output-pris och 16 gånger textens input-pris. Multiplicera en volymkvot med en priskvot och storleksordningen finns där redan innan någon redovisning börjar.

Två operativa konsekvenser faller rakt ut ur tabellen.

Audio caching är inte en optimering, det är affärsmodellen. Cachat audio input är $0.40 per miljon mot $32.00 färskt — en rabatt på 98,75 % som halverar samtalet. Regeln är Kapitel 16:s, oförändrad: cachen matchar ett prefix, så allt som infogas längst fram i konversationen mitt i samtalet förstör den, och den naturliga platsen att lägga ”uppringaren är nu verifierad” är exakt där.

Och inget du gör i klienten avdebiterar ett ljud. Användaren pratar över assistant, din kod stoppar uppspelningen, högtalaren tystnar. Det som redan hade genererats var redan debiterat, eftersom debitering uppstår när svaret skapas; och enligt Kapitel 16:s regel skickas allt som stannar i konversationen om, som input audio, varje tur efteråt. Kapitel 14 gjorde den här poängen om att avbryta en textström. I röst kostar det trettio gånger mer.

Video säljs per sekund av vissa leverantörer och per klipp av andra, med nivåer för upplösning och ibland för varaktighet. De två formerna skiljer sig inte bara i bekvämlighet; de korsar varandra.

Leverantören per klipp är dyrare än den per sekund under 1,2 sekunder och 16,7 gånger billigare vid tjugo. Ingen rangordning av de två modellerna överlever en ändring av klipplängden, så ”vilken videomodell är billigast” är inte en fråga om modeller.

Sista raden är värre, och den är kapitlets ärliga kärna. mochi debiteras mot verkliga GPU-sekunder — jobbets uppmätta prediction-tid — till $0.001400 per sekund på en A100 och $0.001525 på en H100, vilket är den hyrda maskinens priser och inget annat.¹⁵ Det är en fullkomligt exakt tariff och det är inte ett pris, eftersom kvantiteten den multiplicerar är okänd tills efter att du har förbundit dig att betala den. Raden ovan antar tolv GPU-sekunder per sekund output; fyrdubbla det antagandet och den lämnar det billigaste bandet, och först vid sex gånger landar den mitt i tabellen. Det är den enda tariffen på den här sidan som du inte kan lägga i en offert.

Alltså: tokens, image tokens, tecken, minuter, videosekunder, hela klipp, GPU-sekunder, fasta enheter. Åtta kvantiteter, och det enda sättet att lägga dem på en axel är att deklarera en arbetslast och prissätta den.

Det är utökningen av Kapitel 16:s computeCost — samma nivåmaskineri, nu med kriterier som inte är prompt-längd:

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

De två markerade raderna är där den går sönder. En tariff angiven per enhet multiplicerar u.images ?? 1; en tariff angiven per token multiplicerar något som standardmässigt är noll. Mata båda med en tom usage — formen du får när en mätning misslyckats — och se:

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

Inget hände, sex gånger, och det kostade tre dollar en gång och ingenting fem gånger. Det är inte en avrundningsskillnad; det är ett beslut om vad ett frånvarande tal betyder, taget separat för varje enhet och aldrig nedskrivet. Den sunda regeln är att ett fält som ingen har mätt förblir frånvarande, eftersom ”inte mätt” och ”mätt och blev noll” är olika saker. Den här funktionen håller tyst inte med.

Det andra felet är varaktighet. Tariffen per klipp väljer nivå med maxDurationSeconds mot u.videoSeconds ?? 0, så en usage som aldrig registrerade en varaktighet matchar den kortaste nivån:

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

Fyrtio procent rabatt för att inte veta hur lång videon var. Båda buggarna har samma rot: en default vald för bekvämlighet inuti en funktion vars hela jobb är att vara exakt.

När kostnaderna kan beräknas behöver jämförelsen den andra halvan — en deklarerad representativ arbetslast, en per engine, offentligt angiven så att en läsare kan säga emot den:

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

Var och en av de raderna är ett argument. Text blandar en fjärdedel input och tre fjärdedelar output eftersom verklig användning lutar mot output; en femtio-femtio-blandning rangordnar modellerna annorlunda. Bildarbetslasten antar 1 500 output tokens, mellan OpenAI:s 1 056 för en medium-kvadrat och 1 584 för ett medium-porträtt. Video antar fem sekunder i 1080p, och vi har just sett två leverantörer byta plats vid 1,2 sekunder. Compute-posten antar sextio GPU-sekunder eftersom det inte finns något annat att anta.

Det är metoden, och det är den enda ärliga som finns: du kan inte jämföra priser i olika enheter; du kan bara jämföra kostnaden för en arbetslast du har skrivit ned. Varje tabell som rangordnar multimodala modeller utan att skriva ut sin arbetslast rangordnar sina egna antaganden.

Du kan nu prissätta vad som helst en modell kan producera, i vilken enhet det än säljs, och säga högt vilken arbetslast din jämförelse antog. Det stänger fakturan som Kapitel 16 öppnade, och det stänger Del III: allt från Kapitel 14 till hit har handlat om ett anrop — hur man gör det, vad man lägger i det, hur man samplar det, vad det returnerar, vad det kostar.

Kapitel 22 ändrar analysenheten, och ändringen är dyr. En agent är inte ett anrop; den är en loop som själv bestämmer hur många anrop den ska göra, och aritmetiken i de två senaste kapitlen är det som gör om det från ett arkitekturdiagram till en budget. Det öppnar med att ställa samma fråga till samma modell två gånger, med ett verktyg lagt till i katalogen andra gången, och mäta vad det enda verktyget gjorde: ett anrop blev två, trettionio input tokens blev 420.

Om det gör den till en agent beror på vilken av två publicerade definitioner du öppnar, och de håller inte med varandra. En av dem håller inte med sig själv.

Varje pris, formel och konverteringskurs i det här kapitlet lästes från leverantörens egen sida den 7 september 2026 och citeras med det datumet, eftersom alla kommer att ändras. Token-antal, kostnader och jämförelser beräknades på dessa data av koden som trycktes ovan, på en maskin, utan att något betalt API-anrop gjordes — vilket också är det ärliga skälet till att det inte finns ett enda latency-påstående i kapitlet.

Image-token-funktionerna, kostnadstabellerna, röst-samtalsuppdelningen och resultaten för tom usage producerades av TypeScript-koden som trycktes i kapitlet, körd på Node 22. Dialogen som användes för röstjämförelsen är 149 ord och tokeniserades med tiktoken under o200k_base-encoding till 188 tokens; dess varaktighet följer av en deklarerad takt på 150 ord per minut, vilket är en parameter i jämförelsen och inte en mätning. Varje leverantörssiffra har fotnoten som namnger sidan den kom från.