多模态定价：图像、音频和视频到底按什么收费

transformer 接收的是一串向量。它并不关心这些向量从哪里来。第 8 章喂给它的是从 token id 查出来的 embeddings；架构里没有任何东西要求必须查表。

所以：把图片切成固定大小的方块，把每个方块展平成一串数字，再让每串数字通过一个学习得到的线性层，变成模型宽度对应的向量。一个 32 × 32 的彩色像素 patch 是 $32 \times 32 \times 3 = 3072$ 个数字；投影 $E \in \mathbb{R}^{d \times 3072}$ 会把它变成一个 $d$ 维向量，形状与一个文本 token 进入模型时完全相同。事情就这么多，而那篇论文的标题也正是这么说的：一张图像值 16 × 16 个词。¹ 加上位置编码，让模型知道哪个方块原来在哪里；再把结果与文本 embeddings 交错在一起，模型读取的序列就一部分是图片，一部分是句子。

三篇论文把它变成了产品。CLIP 在四亿个抓取来的图文对上训练一个图像编码器和一个文本编码器，让它们达成一致；也正是在那里，像素和文字可以共享一个空间的想法不再只是猜想。² Flamingo 把一个冻结的视觉编码器，用少数训练过的桥接层接到一个冻结的语言模型上。³ LLaVA 证明这座桥可以只是一个线性投影，而 instruction-following 可以用生成数据教会；这就是为什么此后的每个开放视觉语言模型看起来都大致相同。⁴

对你的发票来说，后果直接且不华丽：这些 patch 是序列中的位置，所以它们是输入 token，所以你按输入费率付费。 多少个是算术问题，而且每家供应商的算法都不同。

下面每条规则都按供应商自己的文档实现，并用同一文档中的示例校验过。

OpenAI 用 32 × 32 的 patch 覆盖图像，再把数量乘以每个模型自己的系数。如果 patch 数超过该模型与细节级别的预算，图像会被缩小，直到符合预算：

Anthropic 用 28 × 28 的 patch 覆盖图像，每个 patch 一个视觉 token，并同时限制长边和 token 数——标准档模型为 1,568 像素和 1,568 token，高分辨率档为 2,576 和 4,784。过大的图像会被缩放到同时满足两项限制的最大尺寸。⁵

Google 完全不数像素。 如果图像两边都不超过 384 像素，固定收费 258 token。任何更大的图像都会切成每块 258 token 的 tile，而 tile 网格来自一个 $\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 像素，这个数字就再也不变；这不是巧合，也不是上限。把裁剪单位代回 tile 公式，对于一张宽度至少不小于高度的图像：

尺寸抵消了。Google 的 image tokens 只取决于宽高比，除此之外什么都不取决。 一张 4:3 的照片，不管是缩略图还是海报，都是四个 tile。这个单一的代数事实，就是前面节省表中零的全部解释，而且没有任何价格页把它写出来。

另外两列则是在不同高度、出于不同原因封顶——Anthropic 封在声明的 token 上限，OpenAI 封在像素限制之后的 patch 预算——这就是三条曲线会在不同尺寸交叉的原因。

现在把它弄坏。想在视觉模型上少花钱，显而易见的做法是要求更少细节，所以发送 detail: "low"：

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

要求更少细节，成本却多了 25 %。这不是 bug，OpenAI 在尺寸表里用一行就说明了：在那个模型家族上，low 使用 2048 像素限制和 6,144 patch 预算，而 high 使用同样的像素限制但只有 2,500 patch 预算，“so it can use more tokens than high”。⁷ low 这个词命名的是保真度设置，不是价格：在五个已记录的模型家族里，有两个完全不省钱；而在这两个之一上，它还更贵。

到目前为止，所有内容都是模型在读取图像。制作一张图运行在一种完全没有 token 的机制上，这也是它按图片而不是按文字出售的原因。

供应商把图像生成发布为每张图的价格。但它并不真的是。GPT Image 模型会发出专门的 image tokens，其数量取决于请求的尺寸和质量；把公开的计数乘以 GPT Image 1 公开的 image output 费率——每百万 $40——再与同一页上的按图价格比较：

九个推导数字对九个公开数字，每一对相差都不超过 $0.002。¹¹ Google 更直白，直接在价格页上替你完成换算：图像输出每百万 token $60，“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

在每个质量档位，更大的图像反而是更便宜的。1024 × 1536 的画布比 1024 × 1024 多 50 % 像素，但在 medium 下少花 23 % token。OpenAI 用一句你很可能跳过的话标出了这一点——“a larger non-square resolution can sometimes produce fewer output tokens than a smaller or square resolution at the same quality setting”——而在上一代模型上方向相反，竖版比方图贵 50 %。¹¹ 在这次变化之前写下的每一个 1024x1024 默认值，现在都是昂贵选项。

让三个产品朗读同一段 519 个字符——大约 38 秒音频——你会从两家供应商那里得到三套单位系统：

同一家供应商同时出售两种单位：OpenAI 的 tts-1 按每百万字符计价，而 gpt-4o-mini-tts 按每百万 token 计价，输入 $0.60，输出 $12.00。¹³ 所以，“最便宜的 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 的代价，也正是下一节昂贵的原因。

现在来到决定语音究竟是功能还是产品的那个数字。

这通电话：一段十轮客服对话，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 token，其价格页在同一行发布 $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 音频是二十个 token。按声明速率，同一秒承载 2.5 个词，而测得的转录文本为每词 1.26 token，所以作为文本是 3.15 token。声音是承载同一含义时臃肿 6.3 倍的包装，而它的每个 token 又按文本输出费率的 5.3 倍、文本输入费率的 16 倍收费。把体积比乘以价格比，在任何会计开始之前，数量级就已经摆在那里。

两个运营后果直接从表里掉出来。

Audio caching 不是优化，而是商业模式。 Cached audio input 是每百万 $0.40，新鲜的是 $32.00——98.75 % 的折扣，足以把电话成本砍半。规则就是第 16 章的规则，没有变化：cache 匹配前缀，所以任何在通话中途插入对话开头的内容都会摧毁它，而“来电者现已验证”最自然的位置正好就是那里。

而且你在客户端做的任何事，都不能让已经出声的内容不计费。 用户打断 assistant，你的代码停止播放，扬声器安静下来。已经生成的内容已经被计费，因为计费在 response 创建时累积；并且按照第 16 章的规则，凡是留在对话中的内容，此后每一轮都会作为输入音频重新发送。第 14 章对中止文本流已经说明过这一点。到了语音里，它贵三十倍。

有些供应商按秒出售视频，有些按片段出售，并按分辨率、有时也按时长分档。这两种形状不只是便利程度不同；它们会交叉。

按片段收费的供应商，在 1.2 秒以下比按秒收费的更贵，在二十秒时便宜 16.7 倍。这两个模型的排序无法经受片段长度变化，所以“哪个视频模型最便宜”并不是关于模型的问题。

最后一行更糟，也是本章最诚实的核心。mochi 按真实 GPU 秒数计费——作业测得的预测时间——A100 上每秒 $0.001400，H100 上每秒 $0.001525，这就是出租机器的费率，别无其他。¹⁵ 这是一条完全精确的费率，但它不是价格，因为它乘上的数量，要在你承诺付款之后才知道。上面那一行假设每秒输出需要十二个 GPU-second；把这个假设翻四倍，它就离开最便宜区间；只有到六倍时才落到表的中段。这是本页唯一一条你无法写进报价的费率。

所以：tokens、image tokens、字符、分钟、视频秒、整段视频、GPU seconds、固定单位。八种数量，而把它们放到同一条轴上的唯一办法，就是声明一个工作负载并给它定价。

这是对第 16 章 computeCost 的扩展——同一套阶梯机制，只是现在条件不再是 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;
}

标出的两行就是它坏掉的地方。按单位报价的费率会乘以 u.images ?? 1；按 token 报价的费率会乘以某个默认值为零的东西。给两者都喂一个空 usage——也就是测量失败时得到的形状——然后看：

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

什么都没有发生，六次；其中一次花了三美元，另外五次什么都不花。这不是四舍五入差异；这是关于一个缺失数字意味着什么的决定，并且每个单位各自作出、从未写下。合理的规则是：没有人测量过的字段保持缺失，因为“未测量”和“测量后结果为零”是不同的事情。这个函数却悄悄不同意。

第二个失败是时长。按片段收费的费率用 maxDurationSeconds 对 u.videoSeconds ?? 0 选择阶梯，所以一个从未记录时长的 usage 会匹配最短阶梯：

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

不知道视频有多长，就打六折。两个 bug 的根源相同：在一个职责是精确的函数内部，为了方便选择了默认值。

成本可计算之后，比较还需要另一半——一个声明的代表性工作负载，每个引擎一个，公开写出，让读者可以不同意：

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

其中每一行都是一个论点。文本混合四分之一输入和四分之三输出，因为真实使用偏向输出；五五混合会让模型排序不同。图像工作负载假设 1,500 个输出 token，介于 OpenAI 的 medium 方图 1,056 和 medium 竖图 1,584 之间。视频假设 1080p 下五秒，而我们刚刚看到两家供应商在 1.2 秒处互换位置。计算项假设六十个 GPU-second，因为没有别的可以假设。

这就是方法，而且这是唯一诚实的方法：你无法比较不同单位下的价格；你只能比较一个你已经写下来的工作负载的成本。 任何给多模态模型排名却不打印工作负载的表，排名的都是它自己的假设。

你现在可以给模型能生成的任何东西定价，不管它按什么单位出售，并且能大声说出你的比较假设了哪种工作负载。这关闭了第 16 章打开的发票，也关闭了第三部分：从第 14 章到这里，一切都在讲一次调用——如何发起、放什么进去、如何采样、返回什么、花多少钱。

第 22 章会改变分析单位，而这个变化很贵。agent 不是一次调用；它是一个循环，会自己决定要调用多少次，而过去两章的算术会把它从架构图变成预算。它开篇会对同一个模型问两遍同一个问题，第二次只是在目录里加了一个工具，然后测量这一个工具做了什么：一次调用变成两次，三十九个输入 token 变成 420 个。

这是否让它成为 agent，取决于你打开的是两个公开定义中的哪一个，而它们并不一致。其中一个甚至与自身不一致。

本章中的每个价格、公式和换算率，都是在 2026 年 9 月 7 日从供应商自己的页面读取，并带着该日期引用，因为它们都会变化。token 计数、成本和比较，是用上面打印的代码在这些数据上计算出来的，在一台机器上运行，没有发起任何付费 API 调用——这也是本章没有任何延迟声明的诚实原因。

image-token 函数、成本表、语音通话拆分和空 usage 结果，均由本章打印的 TypeScript 生成，在 Node 22 上运行。用于语音比较的对话为 149 个词，并用 tiktoken 在 o200k_base encoding 下 tokenized 为 188 个 token；其时长来自声明的每分钟 150 词速率，这是比较参数，不是测量值。每个供应商数字都有脚注说明来源页面。