Мултимодално ценообразуване: какво наистина се таксува при изображения, аудио и видео

Transformer приема последователност от вектори. Той няма мнение откъде са дошли. Глава 8 му подаде embeddings, извлечени от token id; нищо в архитектурата не изисква lookup.

Така че: нарежете картината на фиксирани квадрати, разгънете всеки квадрат в списък от числа и прекарайте всеки списък през един научен линеен слой, за да получите вектор с ширината на модела. Пач 32 × 32 от цветни пиксели е $32 \times 32 \times 3 = 3072$ числа; проекцията $E \in \mathbb{R}^{d \times 3072}$ го превръща в един $d$-мерен вектор — точно формата, в която пристига text token. Това е всичко, и е статията, чието заглавие го казва: едно изображение струва 16 × 16 думи.¹ Добавете позиционно кодиране, за да знае моделът кой квадрат къде е бил, преплетете резултатите с text embeddings и последователността, която моделът чете, е отчасти картина и отчасти изречение.

Три статии го превърнаха в продукт. CLIP обучи image encoder и text encoder да се съгласяват върху четиристотин милиона scraped двойки — там идеята, че пиксели и думи могат да споделят пространство, спря да бъде хипотеза.² Flamingo прикрепи замразен vision encoder към замразен езиков модел с няколко обучени свързващи слоя.³ LLaVA показа, че мостът може да бъде единична линейна проекция, а instruction-following може да се научи с генерирани данни — затова всеки отворен vision-language модел оттогава изглежда приблизително така.⁴

Последствието за фактурата ви е незабавно и съвсем непищно: пачовете са позиции в последователността, следователно са input tokens, следователно плащате за тях по input тарифата. Колко са е аритметика, и всеки доставчик я прави различно.

Всяко правило по-долу е имплементирано от собствената документация на доставчика и проверено спрямо работните примери в същата документация.

OpenAI покрива изображението с пачове 32 × 32 и умножава броя по фактор за конкретния модел. Ако броят пачове надхвърли бюджета за този модел и ниво на детайлност, изображението се мащабира надолу, докато се побере:

Anthropic го покрива с пачове 28 × 28, по един visual token всеки, и поставя таван както на дългия ръб, така и на броя tokens — 1,568 пиксела и 1,568 tokens при моделите standard-tier, 2,576 и 4,784 при high-resolution ниво. Прекалено големите изображения се мащабират до най-големия размер, който се побира и в двете ограничения.⁵

Google изобщо не брои пиксели. Изображение, при което и двете страни са 384 пиксела или по-малко, струва фиксирани 258 tokens. Всичко по-голямо се нарязва на tiles от по 258 tokens, а tile решетката идва от crop единица $\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;      
}

Пуснете всяко правило срещу числата, които самият му доставчик публикува:

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

Отпечатани са девет съвпадения; пълното изпълнение проверява петнадесет, тъй като таблицата на Anthropic дава и двете нива за всичките шест размера. Правилата вече са ваши и можете да ги пуснете върху всяка снимка, която имате — точно това е смисълът: това са единствените три функции в тази глава, които не можете да получите от ценова страница.

Пуснете една и съща 4:3 снимка през трите правила в шест размера:

Прочетете последната колона надолу. След като картината мине 384 пиксела, числото никога повече не се променя, и това не е случайност или таван. Заместете crop единицата обратно във формулата за tiles, за изображение поне толкова широко, колкото е високо:

Размерът се съкращава. Image tokens на Google зависят от aspect ratio и от нищо друго. Снимка 4:3 е четири tiles, независимо дали е миниатюра или плакат. Този единствен алгебричен факт е цялото обяснение на нулата в таблицата със спестявания по-горе, и никоя ценова страница никъде не го казва.

Другите две колони вместо това достигат таван, на различни височини и по различни причини — Anthropic при обявен token таван, OpenAI при patch бюджет след pixel ограничение — затова трите криви се пресичат при различни размери.

Сега го счупете. Очевидният начин да харчите по-малко за vision модел е да поискате по-малко детайл, така че изпратете detail: "low":

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

Искането за по-малко детайл струва 25 % повече. Това не е bug и OpenAI го казва в един ред от sizing таблицата: при това семейство модели low използва лимит 2048 пиксела с budget от 6,144 пача, докато high използва същия pixel limit с budget от 2,500 пача, „така че може да използва повече tokens от high“.⁷ Думата low назовава настройка за fidelity, не цена: при две от петте документирани семейства модели тя не носи никакво спестяване, а при едно от тези две струва повече.

Всичко досега беше модел, който чете изображение. Създаването на такова работи по механизъм, в който изобщо няма tokens, и точно затова се продава на картина, а не на дума.

Доставчиците публикуват image generation като цена на картина. Не е така. GPT Image моделите излъчват специализирани image tokens, чийто брой зависи от поискания размер и качество; умножете публикуваните бройки по публикуваната image output тарифа на GPT Image 1 от $40 на милион и сравнете с цените на изображение на същата страница:

Девет изведени стойности срещу девет публикувани, като всяка двойка съвпада в рамките на $0.002.¹¹ Google е още по-ясен и прави преобразуването вместо вас направо на ценовата страница: image output при $60 на милион tokens, „output images at 1K (1024x1024px) consume 1120 tokens and are equivalent to $0.067 per image“.¹²

Значи цена на изображение е цена на token с вграден брой. Това е приемливо, но скрива нещо. Вземете таблицата на текущото поколение и разделете наобратно:

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

По-голямото изображение е по-евтиното при всяко качество. Canvas 1024 × 1536 има 50 % повече пиксели от 1024 × 1024 и струва 23 % по-малко tokens при medium. OpenAI го отбелязва в изречение, което бихте пропуснали — „по-голяма неквадратна резолюция понякога може да произведе по-малко output tokens от по-малка или квадратна резолюция при същата настройка за качество“ — а при предишното поколение модели беше обратно: portrait струваше 50 % повече от square.¹¹ Всеки default на 1024x1024, написан преди тази промяна, сега е скъпият вариант.

Помолете три продукта да изговорят същите 519 символа — около 38 секунди аудио — и получавате три системи от единици от двама доставчици:

Един и същ доставчик продава и двете единици: tts-1 на OpenAI се ценообразува на милион символа, докато gpt-4o-mini-tts се ценообразува на милион tokens, $0.60 in и $12.00 out.¹³ Така че „най-евтиният text-to-speech“ не е въпрос с отговор, докато не кажете какво ще се говори.

А двете единици са слепи за противоположни неща. Цена на символ не вижда продължителност: изберете бавен, премерен глас или добавете паузи, и сметката не се движи, докато аудиото става по-дълго. Цена на секунда не вижда съдържание: тридесет секунди струват еднакво, независимо дали са плътен технически абзац или някой брои до десет. Сменете гласа и точно един от двамата ви доставчици преоценява.

Транскрипцията върви в обратната посока и е най-простият ред в цялата фактура — на минута аудио, фиксирано:

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)

Обърнете внимание на последния ред спрямо третия: да го правите на живо, докато думите пристигат, струва 5,7 пъти повече от това да го правите върху завършен файл. Тази разлика е цената на невъзможността за batch, и именно тя прави следващия раздел скъп.

Сега числото, което решава дали voice е функция или продукт.

Разговорът: support разговор от десет turn-а, 149 думи, което при обявени 150 думи в минута е 59,6 секунди реч — 21,2 изговорени от обаждащия се, 38,4 изговорени обратно. Token преобразуванията са на самите доставчици. 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 в секунда, и в двете посоки, което ценовата му страница потвърждава, като публикува $12.00 на милион и $0.018 на минута на същия ред.¹²

Разговорът се натрупва точно както каза Глава 16, защото механизмът е същият: „the entire conversation is sent to the model for each Response... thus turns later in the session will be more expensive“.¹⁴ Само че сега историята се измерва в audio tokens.

Сега сравнението, което решава продукта, и четирите нормализирани към минута:

Тридесет и осем пъти. Не тридесет и осем процента. Идентичният обмен, проведен със звук вместо текст, е почти два порядъка по-скъп, и никоя част от тази разлика не е марж, който някой е решил да начисли — тя е обменният курс. Една секунда assistant audio е двадесет tokens. Същата секунда носи 2,5 думи при обявения темп, а измереният transcript върви с 1,26 tokens на дума, така че като текст това са 3,15 tokens. Звукът е 6,3 пъти по-обемна опаковка за същото значение, а всеки от неговите tokens се таксува по 5,3 пъти text output тарифата и 16 пъти text input тарифата. Умножете bulk ratio по price ratio и порядъкът вече е там, преди да започне каквото и да е счетоводство.

Две оперативни последствия излизат директно от таблицата.

Audio caching не е оптимизация, той е бизнес моделът. Cached audio input е $0.40 на милион срещу $32.00 fresh — 98,75 % отстъпка, която разполовява разговора. Правилото е от Глава 16, непроменено: cache съвпада по prefix, така че всичко, вмъкнато в началото на разговора по средата на обаждането, го унищожава, а естественото място да поставите „обаждащият се вече е verified“ е точно там.

И нищо, което правите в клиента, не отменя таксуването на звук. Потребителят говори върху assistant, кодът ви спира playback, говорителят млъква. Каквото вече е било генерирано, вече е било таксувано, защото billing се натрупва при създаването на response; и според правилото от Глава 16 всичко, което остане в разговора, се изпраща отново като input audio на всеки следващ turn. Глава 14 каза това за прекъсване на text stream. При voice струва тридесет пъти повече.

Видео се продава на секунда от някои доставчици и на clip от други, с нива за резолюция и понякога за продължителност. Тези две форми не се различават само по удобство; те се пресичат.

Доставчикът на clip е по-скъп от този на секунда под 1,2 секунди и 16,7 пъти по-евтин при двадесет. Никакво подреждане на тези два модела не оцелява при промяна на дължината на clip, така че „кой video модел е най-евтин“ не е въпрос за модели.

Последният ред е по-лош, и е честното сърце на главата. mochi се таксува спрямо реални GPU seconds — измереното prediction време на задачата — по $0.001400 на секунда на A100 и $0.001525 на H100, които са тарифите на наетата машина и нищо друго.¹⁵ Това е напълно точна тарифа и не е цена, защото количеството, което умножава, е неизвестно, докато вече не сте се ангажирали да го платите. Редът по-горе приема дванадесет GPU-seconds на секунда output; учетворете това допускане и той излиза от най-евтината група, а едва при шест пъти попада в средата на таблицата. Това е единствената тарифа на тази страница, която не можете да сложите в оферта.

И така: tokens, image tokens, символи, минути, video seconds, цели clips, GPU seconds, flat units. Осем количества, и единственият начин да ги сложите на една ос е да обявите workload и да го оцените.

Това е разширението към computeCost от Глава 16 — същата tier механика, сега с критерии, които не са prompt length:

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

Двата маркирани реда са местата, където се чупи. Тарифа, quoted per unit, умножава u.images ?? 1; тарифа, quoted per token, умножава нещо, което по подразбиране е нула. Подайте и на двете празна usage — формата, която получавате, когато измерването е failed — и гледайте:

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

Нищо не се случи шест пъти, и струваше три долара веднъж и нищо пет пъти. Това не е разлика от закръгляне; това е решение какво означава липсващо число, взето поотделно за всяка единица и никога записано. Разумното правило е, че поле, което никой не е измерил, остава absent, защото „не е измерено“ и „измерено е и е излязло нула“ са различни неща. Тази функция тихо не е съгласна.

Вторият провал е duration. Clip-priced тарифата избира tier с maxDurationSeconds срещу u.videoSeconds ?? 0, така че usage, който никога не е записал duration, съвпада с най-краткия tier:

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

Четиридесет процента отстъпка за това, че не знаете колко дълго е било видеото. И двата bug-а имат един корен: default, избран за удобство вътре във функция, чиято цяла работа е да бъде точна.

След като costs са изчислими, сравнението се нуждае от другата половина — обявен представителен workload, по един за engine, заявен публично, така че читателят да може да не се съгласи с него:

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

Всеки от тези редове е аргумент. Text смесва една четвърт input и три четвърти output, защото реалната usage клони към output; fifty-fifty blend класира моделите различно. Image workload приема 1,500 output tokens — между 1,056 на OpenAI за medium square и 1,584 за medium portrait. Video приема пет секунди при 1080p, а току-що видяхме двама доставчици да си разменят местата при 1,2 секунди. Compute entry приема шестдесет GPU-seconds, защото няма какво друго да се приеме.

Това е методът, и е единственият честен наличен: не можете да сравнявате цени в различни единици; можете само да сравнявате цената на workload, който сте записали. Всяка таблица, която класира multimodal модели, без да отпечата workload, класира собствените си допускания.

Вече можете да оцените всичко, което модел може да произведе, в каквато и единица да се продава, и да кажете на глас кой workload е приело сравнението ви. Това затваря фактурата, която Глава 16 отвори, и затваря Част III: всичко от Глава 14 до тук беше за един call — как да го направите, какво да сложите в него, как да го sample-нете, какво връща, колко струва.

Глава 22 сменя единицата на анализ, и промяната е скъпа. Agent не е един call; той е loop, който сам решава колко calls да направи, а аритметиката от последните две глави е това, което превръща това от архитектурна диаграма в бюджет. Тя започва, като задава същия въпрос на същия модел два пъти, с един tool, добавен към каталога втория път, и измерва какво е направил този един tool: един call стана два, тридесет и девет input tokens станаха 420.

Дали това го прави agent зависи от това коя от две публикувани дефиниции отворите, а те не са съгласни. Една от тях не е съгласна със себе си.

Всяка цена, формула и conversion rate в тази глава беше прочетена от собствената страница на доставчика на 7 септември 2026 г. и е цитирана с тази дата, защото всички ще се променят. Token броевете, costs и сравненията бяха изчислени върху тези данни от кода, отпечатан по-горе, на една машина, без платено API повикване — което е и честната причина в тази глава да няма нито едно latency твърдение.

Image-token функциите, cost таблиците, voice-call breakdown и empty-usage резултатите бяха произведени от TypeScript, отпечатан в тази глава, пуснат на Node 22. Диалогът, използван за voice сравнението, е 149 думи и беше tokenized с tiktoken под o200k_base encoding при 188 tokens; продължителността му следва от обявен темп 150 думи в минута, който е параметър на сравнението, а не измерване. Всяка стойност от доставчик носи бележката под линия, която назовава страницата, от която идва.