Multimodális árazás: mit számláznak valójában a képek, a hang és a videó

Egy transformer vektorok sorozatát fogadja. Nincs véleménye arról, honnan jöttek. A 8. fejezet token id alapján kikeresett embeddingeket adott neki; az architektúrában semmi sem teszi kötelezővé ezt a keresést.

Tehát: vágd a képet rögzített négyzetekre, lapítsd minden négyzetet számok listájává, és küldd át mindegyik listát egy tanult lineáris rétegen, hogy a model szélességének megfelelő vektort kapj. Egy 32 × 32-es színes pixelpatch $32 \times 32 \times 3 = 3072$ szám; a $E \in \mathbb{R}^{d \times 3072}$ projekció ebből egy $d$ dimenziós vektort csinál, pontosan olyan alakút, amilyenben egy text token érkezik. Ennyi az egész, és ez az a tanulmány, amelynek címe ki is mondja: egy kép 16 × 16 szót ér.¹ Adj hozzá pozicionális kódolást, hogy a model tudja, melyik négyzet hol volt, fűzd össze az eredményeket a text embeddingekkel, és a model által olvasott sorozat részben kép, részben mondat.

Három tanulmány csinált ebből terméket. A CLIP egy image encodert és egy text encodert tanított meg egyetérteni négyszázmillió lekapart páron arról, hogy mi mihez tartozik; itt szűnt meg hipotézis lenni az az ötlet, hogy pixelek és szavak közös térben élhetnek.² A Flamingo egy fagyasztott vision encodert csavarozott egy fagyasztott nyelvi modelhez néhány tanított hídréteggel.³ A LLaVA megmutatta, hogy a híd lehet egyetlen lineáris projekció, az instruction-following pedig generált adatokkal tanítható, ezért néz ki azóta minden nyílt vision-language model nagyjából ugyanúgy.⁴

A számlád szempontjából a következmény azonnali és prózai: a patchek pozíciók a sorozatban, tehát input tokenek, tehát az input díjon fizetsz értük. Hány darab? Aritmetika, és minden provider másképp csinálja.

Az alábbi szabályok mindegyike a provider saját dokumentációjából van implementálva, és ugyanannak a dokumentációnak a kidolgozott példáival ellenőrizve.

Az OpenAI 32 × 32-es patchekkel fedi le a képet, és a darabszámot egy modelenkénti faktorral szorozza. Ha a patchszám meghaladja az adott model és részletességi szint keretét, a képet addig kicsinyíti, amíg belefér:

Az Anthropic 28 × 28-as patchekkel fedi le, vizuális tokenenként egyet, és plafont tesz mind a hosszú élre, mind a tokenszámra — standard-tier modelleknél 1,568 pixel és 1,568 token, a nagyfelbontású tieren 2,576 és 4,784. A túlméretes képeket a legnagyobb olyan méretre skálázza, amely mindkettőbe belefér.⁵

A Google egyáltalán nem pixeleket számol. Egy kép, amelynek mindkét oldala legfeljebb 384 pixel, fixen 258 tokenbe kerül. Ami nagyobb, azt 258 tokenes csempékre vágja, és a csemperács egy $\lfloor \min(w,h) / 1.5 \rfloor$ crop unitból jön.⁶

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

Futtasd mindegyiket a saját vendorja által nyomtatott számokon:

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

Kilenc egyezés jelenik meg; a teljes futás tizenötöt ellenőriz, mert az Anthropic táblája mind a hat mérethez mindkét tiert megadja. A szabályok most már a tieid, bármelyik fotódon futtathatod őket, és ez a lényeg: ez az egyetlen három függvény ebben a fejezetben, amelyet nem kapsz meg egy árlistából.

Küldd át ugyanazt a 4:3-as fotót mindhárom rendszeren hat méretben:

Olvasd lefelé az utolsó oszlopot. Amint a kép 384 pixel fölé kerül, a szám soha többé nem változik, és ez nem véletlen, nem is plafon. Helyettesítsd vissza a crop unitot a csempeképletbe, egy legalább olyan széles képhez, mint amilyen magas:

A méret kiesik. A Google image tokenjei az oldalaránytól függenek, és semmi mástól. Egy 4:3-as fotó négy csempe, akár bélyegkép, akár poszter. Ez az egyetlen algebrai tény magyarázza a fenti megtakarítási tábla nulláját, és ezt egyetlen árlista sem mondja ki sehol.

A másik két oszlop ehelyett plafonoz, különböző magasságokon és különböző okokból — az Anthropic deklarált tokenplafonnál, az OpenAI pedig pixelkorlát utáni patchkeretnél —, ezért keresztezik egymást a három görbe különböző méreteknél.

Most törd el. Egy vision modelen kevesebbet költeni nyilván úgy lehet, hogy kevesebb részletet kérsz, ezért küldd el ezt: detail: "low":

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

Kevesebb részletet kérni 25 %-kal többe került. Ez nem bug, és az OpenAI egyetlen sorban ki is mondja a méretezési táblában: azon a modelcsaládon a low 2048 pixeles korlátot használ 6,144 patchből álló kerettel, míg a high ugyanazt a pixelkorlátot használja 2,500 patchből álló kerettel, „so it can use more tokens than high”.⁷ A low szó hűségbeállítást nevez meg, nem árat: az öt dokumentált modelcsaládból kettőn egyáltalán nem hoz megtakarítást, és e kettő egyikén többe kerül.

Eddig minden arról szólt, hogy egy model olvas egy képet. Egy kép elkészítése olyan mechanizmuson fut, amelyben egyáltalán nincsenek tokenek, és ezért adják el képenként, nem szavanként.

A vendorok a képgenerálást képenkénti árként publikálják. Nem az. A GPT Image modellek specializált image tokeneket bocsátanak ki, amelyek száma a kért mérettől és minőségtől függ; szorozd meg a publikált darabszámokat a GPT Image 1 közzétett, milliónként $40-os image output díjával, és hasonlítsd össze ugyanazon az oldalon a képenkénti árakkal:

Kilenc származtatott szám kilenc publikált számmal szemben, minden pár $0.002-en belül egyezik.¹¹ A Google még explicitebb, és magán az árlistán végzi el helyetted a konverziót: image output $60 millió tokenenként, „output images at 1K (1024x1024px) consume 1120 tokens and are equivalent to $0.067 per image”.¹²

Tehát a képenkénti ár tokenenkénti ár, beépített darabszámmal. Ez rendben van, és elrejt valamit. Fogd a jelenlegi generáció tábláját, és ossz visszafelé:

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 nagyobb kép minden minőségen olcsóbb. Egy 1024 × 1536-os canvas 50 %-kal több pixel, mint egy 1024 × 1024-es, és 23 %-kal kevesebb tokenbe kerül mediumon. Az OpenAI egy olyan mondatban jelzi, amelyet simán átugranál — „a larger non-square resolution can sometimes produce fewer output tokens than a smaller or square resolution at the same quality setting” —, az előző modelgeneráción pedig fordítva volt: a portré 50 %-kal többe került, mint a négyzet.¹¹ Minden 1024x1024 default, amelyet a változás előtt írtak, most a drága opció.

Kérj meg három terméket, hogy mondja ki ugyanazt az 519 karaktert — körülbelül 38 másodpercnyi hangot —, és két vendortól három egységrendszert kapsz:

Ugyanaz a vendor mindkét egységet árulja: az OpenAI tts-1 millió karakterenként van árazva, míg a gpt-4o-mini-tts millió tokenenként, $0.60 be és $12.00 ki.¹³ Így a „legolcsóbb text-to-speech” nem megválaszolható kérdés addig, amíg meg nem mondod, mit mondatsz ki.

És a két egység ellentétes dolgokra vak. A karakterenkénti ár nem látja az időtartamot: válassz lassú, megfontolt hangot, vagy adj hozzá szüneteket, és a számla nem mozdul, miközben a hang hosszabb lesz. A másodpercenkénti ár nem látja a tartalmat: harminc másodperc ugyanannyiba kerül, akár sűrű technikai bekezdés, akár valaki tízig számol. Változtasd meg a hangot, és a két vendorod közül pontosan az egyik áraz újra.

Az átírás fordítva működik, és a teljes számla legegyszerűbb sora — hangpercenként, fixen:

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)

Figyeld meg az utolsó sort a harmadikhoz képest: élőben, ahogy a szavak érkeznek, 5,7-szer annyiba kerül, mint kész fájlon. Ez a különbség annak az ára, hogy nem lehet batch-elni, és ez teszi drágává a következő szakaszt.

Most jön az a szám, amely eldönti, hogy a voice funkció vagy termék.

A hívás: tízfordulós support beszélgetés, 149 szó, ami deklarált 150 szó/perc mellett 59,6 másodperc beszéd — ebből 21,2-t a hívó mond, 38,4-et válaszként mondanak vissza. A tokenkonverziók a providerok sajátjai. 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 token másodpercenként, mindkét irányban, amit az árlistája is megerősít azzal, hogy ugyanazon a soron $12.00 milliónként és $0.018 percenként szerepel.¹²

A beszélgetés pontosan úgy halmozódik, ahogy a 16. fejezet mondta, mert ugyanaz a mechanizmus: „the entire conversation is sent to the model for each Response... thus turns later in the session will be more expensive”.¹⁴ Csak most az előzményeket audio tokenekben mérjük.

Most az összehasonlítás, amely eldönti a terméket, mind a négyet percre normalizálva:

Harmincnyolcszor. Nem harmincnyolc százalékkal. Az azonos eszmecsere hangban, szöveg helyett, majdnem két nagyságrenddel drágább, és ebből a különbségből semmi sem olyan árrés, amelyet valaki felszámítani választott — ez a konverziós arány. Egy másodpercnyi assistant audio húsz token. Ugyanez a másodperc a deklarált sebesség mellett 2,5 szót hordoz, a mért átirat pedig 1,26 token/szóval fut, tehát szövegként 3,15 token. A hang ugyanarra a jelentésre 6,3-szor terjedelmesebb csomag, és minden tokenjét 5,3-szoros text output díjon és 16-szoros text input díjon számlázzák. Szorozz össze egy tömegességi arányt egy árarányal, és a nagyságrend már azelőtt megvan, hogy bármilyen könyvelés elkezdődne.

Két működési következmény egyenesen kiesik a táblából.

Az audio caching nem optimalizálás, hanem az üzleti modell. A cached audio input $0.40 milliónként a friss $32.00-val szemben — 98,75 %-os kedvezmény, amely megfelezi a hívást. A szabály a 16. fejezeté, változatlanul: a cache prefixet illeszt, tehát bármi, amit hívás közben a beszélgetés elejére szúrsz be, elpusztítja, és a „the caller is now verified” természetes helye pontosan ott van.

És semmi, amit a kliensben csinálsz, nem számlátlanít egy hangot. A user rászól az assistantre, a kódod leállítja a lejátszást, a hangszóró elnémul. Ami addig már legenerálódott, azért már fizettél, mert a számlázás a response létrehozásakor keletkezik; és a 16. fejezet szabálya szerint ami a beszélgetésben marad, azt minden következő fordulóban újraküldik input audio-ként. A 14. fejezet ugyanezt a pontot tette meg text stream megszakításáról. Hangban ez harmincszor többe kerül.

A videót egyes vendorok másodpercenként, mások klipenként adják el, felbontási tierekkel, néha időtartam szerinti tierekkel is. Ez a két forma nem pusztán kényelmességben különbözik; keresztezik egymást.

A klipenkénti vendor drágább, mint a másodpercenkénti 1,2 másodperc alatt, húsz másodpercnél pedig 16,7-szer olcsóbb. A kliphossz változását ez a két model semmilyen sorrendje nem éli túl, tehát a „melyik video model a legolcsóbb” nem modellekről szóló kérdés.

Az utolsó sor rosszabb, és ez a fejezet őszinte magja. A mochi számlázása valós GPU-másodpercek alapján történik — a job mért predikciós ideje szerint — $0.001400 másodpercenként A100-on és $0.001525 H100-on, amelyek nem mások, mint a bérelt gép díjai.¹⁵ Ez tökéletesen precíz tarifa, és nem ár, mert az általa szorzott mennyiség ismeretlen addig, amíg már el nem kötelezted magad a fizetésre. A fenti sor tizenkét GPU-másodpercet feltételez egy másodpercnyi outputra; négyszerezd ezt a feltételezést, és kikerül a legolcsóbb sávból, csak hatszorosnál ér a tábla közepére. Ez az egyetlen tarifa ezen az oldalon, amelyet nem tehetsz ajánlatba.

Tehát: tokenek, image tokenek, karakterek, percek, videómásodpercek, egész klipek, GPU-másodpercek, fix egységek. Nyolc mennyiség, és egyetlen módon tehetők egy tengelyre: deklarálsz egy workloadot, és beárazod.

Ez a 16. fejezet computeCost függvényének kiterjesztése — ugyanaz a tier-gépezet, immár olyan kritériumokkal, amelyek nem prompt-hosszok:

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

A két jelölt sor az, ahol eltörik. Egy egységenként jegyzett tarifa a u.images ?? 1 értéket szorozza; egy tokenenként jegyzett tarifa olyasmit szoroz, ami alapból nullára esik. Adj mindkettőnek üres usage-et — azt az alakot, amelyet akkor kapsz, amikor egy mérés elbukott —, és figyeld:

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

Semmi sem történt, hatszor, és egyszer három dollárba került, ötször pedig semmibe. Ez nem kerekítési különbség; ez döntés arról, mit jelent egy hiányzó szám, minden egységre külön meghozva és sehol le nem írva. A helyes szabály az, hogy egy mező, amelyet senki sem mért, hiányzó marad, mert a „nem mért” és a „mértük, és nulla lett” különböző dolgok. Ez a függvény csendben nem ért egyet.

A második hiba az időtartam. A klipárazású tarifa a tierjét a maxDurationSeconds és u.videoSeconds ?? 0 összevetésével választja, így egy usage, amely sosem rögzített időtartamot, a legrövidebb tierhez illeszkedik:

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

Negyven százalék kedvezmény azért, mert nem tudjuk, milyen hosszú volt a videó. Mindkét bug gyökere ugyanaz: kényelmi default egy olyan függvényben, amelynek az lenne az egész dolga, hogy pontos legyen.

Miután a költségek kiszámíthatók, az összehasonlításhoz kell a másik fél — egy deklarált reprezentatív workload, engine-enként egy, nyilvánosan kimondva, hogy az olvasó vitatkozhasson vele:

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

Ezek közül minden sor állítás. A text negyed inputot és háromnegyed outputot kever, mert a valós használat output felé torzít; egy fele-fele keverék másképp rangsorolná a modelleket. Az image workload 1,500 output tokent feltételez, az OpenAI medium négyzetre adott 1,056 és medium portréra adott 1,584 értéke között. A video öt másodpercet feltételez 1080p-n, és épp láttuk, hogy két vendor 1,2 másodpercnél helyet cserél. A compute bejegyzés hatvan GPU-másodpercet feltételez, mert nincs mi mást feltételezni.

Ez a módszer, és ez az egyetlen őszinte elérhető módszer: különböző egységű árakat nem tudsz összehasonlítani; csak egy leírt workload költségét tudod összehasonlítani. Bármelyik tábla, amely multimodal modelleket rangsorol anélkül, hogy kinyomtatná a workloadját, a saját feltételezéseit rangsorolja.

Most már be tudsz árazni bármit, amit egy model elő tud állítani, bármilyen egységben adják el, és hangosan ki tudod mondani, milyen workloadot feltételezett az összehasonlításod. Ez lezárja a számlát, amelyet a 16. fejezet megnyitott, és lezárja a III. részt: a 14. fejezettől idáig minden egy hívásról szólt — hogyan indítsd el, mit tegyél bele, hogyan mintavételezd, mit ad vissza, mennyibe kerül.

A 22. fejezet megváltoztatja az elemzés egységét, és ez a változás drága. Egy agent nem egy hívás; olyan ciklus, amely maga dönti el, hány hívást indít, és az előző két fejezet aritmetikája az, ami ezt architektúra-diagramból költségvetéssé alakítja. Azzal nyit, hogy ugyanannak a modelnek kétszer felteszi ugyanazt a kérdést, másodszor egy toollal kiegészítve a katalógust, és leméri, mit tett ez az egy tool: egy hívásból kettő lett, harminckilenc input tokenből 420.

Hogy ettől agent lesz-e, attól függ, melyik két publikált definíciót nyitod meg, és ezek nem értenek egyet. Az egyik saját magával sem.

Ebben a fejezetben minden árat, képletet és konverziós rátát a provider saját oldaláról olvastunk le 2026. szeptember 7-én, és ezzel a dátummal idézünk, mert mind mozogni fog. A tokenszámokat, költségeket és összehasonlításokat a fenti kód számolta ezen az adaton, egy gépen, fizetett API-hívás nélkül — és ez az őszinte oka annak is, hogy ebben a fejezetben egyetlen latency állítás sincs.

Az image-token függvényeket, a költségtáblákat, a voice-call bontást és az empty-usage eredményeket a fejezetben kinyomtatott TypeScript állította elő Node 22-n futtatva. A voice összehasonlításhoz használt dialógus 149 szó, és tiktoken segítségével tokenizáltuk a o200k_base encoding alatt 188 tokenre; időtartama a deklarált 150 szó/perc sebességből következik, ami az összehasonlítás paramétere, nem mérés. Minden provideradatnál szerepel az a lábjegyzet, amely megnevezi az oldalt, ahonnan származik.