Multimodal Pricing：画像・音声・動画で本当に課金されるもの

transformerはベクトル列を受け取ります。そのベクトルがどこから来たかについて、transformerに意見はありません。第8章ではtoken idから引いたembeddingを与えましたが、アーキテクチャ上、そのlookupが必須なわけではありません。

つまり、画像を固定サイズの正方形に切り、それぞれの正方形を数値のリストに平坦化し、そのリストを学習済みの線形層に通してモデル幅のベクトルにします。色付きピクセルの32 × 32パッチは$32 \times 32 \times 3 = 3072$個の数値です。射影$E \in \mathbb{R}^{d \times 3072}$はそれを1つの$d$次元ベクトルに変換し、これはテキストtokenが入ってくる形とまったく同じです。それがすべてであり、その論文のタイトルが言う通りです。画像は16 × 16語に相当します。¹ 位置encodingを足して、どの正方形がどこにあったかをモデルに知らせ、結果をテキストembeddingと交互に並べれば、モデルが読むsequenceは一部が画像で一部が文になります。

3本の論文がそれをプロダクトにしました。CLIPは画像encoderとテキストencoderを、スクレイピングされた4億組のペアで一致するよう訓練しました。ピクセルと言葉が同じ空間を共有できるという考えが仮説でなくなった地点です。² Flamingoは凍結されたvision encoderを、凍結された言語モデルに、少数の訓練済みブリッジ層で取り付けました。³ LLaVAは、そのブリッジが単一の線形射影でもよく、instruction-followingは生成データで教えられることを示しました。だからそれ以降のオープンなvision-languageモデルは、だいたい同じ形をしています。⁴

請求書への帰結は即座で、華やかではありません。パッチはsequence内の位置なのでinput tokenであり、したがってinputレートで支払います。 何個になるかは算術であり、各providerが違うやり方で計算します。

以下の各ルールはprovider自身のドキュメントから実装し、同じドキュメント内の計算例で照合しています。

OpenAIは画像を32 × 32パッチで覆い、その数にモデル別の係数を掛けます。パッチ数がそのモデルとdetailレベルの予算を超える場合、画像は収まるまで縮小されます。

Anthropicは28 × 28パッチで覆います。1パッチが1 visual tokenで、長辺とtoken数の両方に上限があります。standard-tierモデルでは1,568ピクセルと1,568 token、高解像度tierでは2,576と4,784です。大きすぎる画像は、両方に収まる最大サイズへ縮小されます。⁵

Googleはピクセルをまったく数えません。 両辺が384ピクセル以下の画像は一律258 tokenです。それより大きいものは1タイル258 tokenのタイルに切られ、タイルグリッドは$\lfloor \min(w,h) / 1.5 \rfloor$のcrop単位から決まります。⁶

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

9個の一致が出力されます。Anthropicの表は6サイズすべてについて両方のtierを示しているので、完全な実行では15個をチェックします。これで、このルールはあなたの手元のどの写真にも実行できます。それが目的です。この章で、価格ページからは得られない関数はこの3つだけです。

同じ4:3の写真を6つのサイズで3社すべてに通します。

最後の列を下に読んでください。画像が384ピクセルを超えると、数字は二度と変わりません。これは偶然でも上限でもありません。少なくとも横幅が縦幅以上の画像について、crop単位をタイル式に戻すとこうなります。

サイズが消えます。Googleの画像tokenはアスペクト比だけに依存し、それ以外には依存しません。 4:3の写真は、サムネイルでもポスターでも4タイルです。この1つの代数的事実が、上の節約表にあるゼロの全説明であり、どの価格ページにも書かれていません。

他の2列は代わりに上限に当たります。ただし高さも理由も異なります。Anthropicは宣言されたtoken上限、OpenAIはピクセル制限後のパッチ予算です。だから3本の曲線はサイズごとに違う場所で交差します。

では壊してみます。visionモデルで支出を減らす明らかな方法は、detailを下げることです。そこでdetail: "low"を送ります。

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

低いdetailを求めたら、25 %高くなりました。これはバグではなく、OpenAIもサイズ表の1行でそう述べています。そのモデルファミリーでは、lowは2048ピクセル制限と6,144パッチ予算を使い、highは同じピクセル制限で2,500パッチ予算を使うため、「highより多くのtokenを使うことがある」のです。⁷ lowという言葉は忠実度設定を指し、価格を指していません。文書化された5つのモデルファミリーのうち2つでは節約がまったくなく、その2つのうち1つではむしろ高くなります。

ここまでの話はすべて、モデルが画像を読む場合でした。画像を作る場合は、tokenがまったく存在しない仕組みで動きます。だから単語単位ではなく画像単位で売られます。

ベンダーは画像生成を画像1枚あたりの価格として公開します。しかし実際にはそうではありません。GPT Imageモデルは専用の画像tokenを出力し、その数は要求されたサイズとqualityに依存します。公開された数にGPT Image 1の公開済み画像outputレート、100万tokenあたり$40を掛け、同じページの画像単価と比較します。

9つの導出値を9つの公開値に照らすと、すべてのペアが$0.002以内で一致します。¹¹ Googleはさらに明示的で、価格ページ上で変換まで行っています。画像outputは100万tokenあたり$60で、「1K（1024x1024px）のoutput imagesは1120 tokenを消費し、画像1枚あたり$0.067に相当する」とされています。¹²

つまり画像単位の価格は、個数を折り込んだ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

どのqualityでも、大きい画像の方が安いのです。1024 × 1536のcanvasは1024 × 1024よりピクセルが50 %多いのに、mediumではtokenが23 %少なくなります。OpenAIは、読み飛ばしそうな一文でそれを示しています。「同じquality設定では、より大きな非正方形解像度が、より小さいまたは正方形の解像度より少ないoutput tokenを生成することがある」。そして前世代モデルでは逆方向で、portraitはsquareより50 %高くなっていました。¹¹ その変更前に書かれた1024x1024のdefaultは、今では高い選択肢です。

同じ519文字、約38秒の音声を3つのプロダクトに話させると、2つのベンダーから3つの単位体系が返ってきます。

同じベンダーが両方の単位を売っています。OpenAIのtts-1は100万文字単位で価格付けされ、gpt-4o-mini-ttsは100万token単位、inputが$0.60、outputが$12.00です。¹³ したがって「最安のtext-to-speech」は、何を話すのかを言うまで答えのある問いではありません。

そして2つの単位は、互いに反対のものを見落とします。文字単価はdurationを見られません。ゆっくり慎重な声を選ぶ、または間を追加する。請求額は動かず、音声だけが長くなります。秒単価はcontentを見られません。30秒は、密度の高い技術段落でも、誰かが10まで数えるだけでも同じです。声を変えると、2社のうち正確に1社だけが再価格付けします。

文字起こしは逆向きで、請求書全体で最も単純な行です。音声1分あたり、定額です。

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)

3行目に対する最後の行に注目してください。言葉が到着するliveで行うと、完成済みファイルで行う場合の5.7倍かかります。その差はbatchできないことの価格であり、次のセクションを高価にしているものです。

ここで、音声が機能なのかプロダクトなのかを決める数字に来ます。

通話は10ターンのsupport会話、149語です。宣言された150語/分では59.6秒の発話で、21.2秒がcaller、38.4秒が返答です。token変換はprovider自身のものです。OpenAIは「user messagesのaudio tokensは音声100 msにつき1 token、assistant messagesのaudio tokensは50 msにつき1 token」としています。¹⁴ Googleは両方向で秒25 tokenで、価格ページも同じ行で100万あたり$12.00と1分あたり$0.018を公開して確認しています。¹²

会話は第16章が述べた通りに累積します。同じ仕組みだからです。「各Responseごとに会話全体がモデルへ送られる...したがってsession後半のturnはより高価になる」。¹⁴ ただし今度はhistoryがaudio tokenで測られています。

プロダクトを決める比較です。4つすべてを1分に正規化します。

38倍。 38パーセントではありません。同一のやり取りをテキストではなく音で行うと、2桁近く高くなります。そしてその差のどれも、誰かが選んで乗せたmarginではありません。変換率です。assistant音声1秒は20 tokenです。同じ1秒は宣言レートでは2.5語を運び、測定されたtranscriptは1語あたり1.26 tokenなので、テキストなら3.15 tokenです。同じ意味に対して、音は6.3倍かさばるpackageであり、そのtokenはテキストoutputレートの5.3倍、テキストinputレートの16倍で課金されます。bulk比に価格比を掛ければ、どんな会計が始まる前から桁違いはすでにそこにあります。

表から、2つの運用上の帰結がまっすぐ出てきます。

Audio cachingは最適化ではなく、business modelです。 cached audio inputは100万あたり$0.40で、freshは$32.00です。98.75 %の割引で、通話を半額にします。ルールは第16章と同じで、変わっていません。cacheはprefixに一致するので、通話中に会話の前方へ何かを挿入すると壊れます。そして「callerは今verifiedになった」を置く自然な場所は、まさにそこです。

そしてclient側で何をしても、音の請求は消えません。 userがassistantにかぶせて話し、あなたのcodeがplaybackを止め、speakerが静かになる。すでに生成されたものはすでに課金されています。billingはresponseが作られた時点で発生するからです。そして第16章のルールにより、会話に残るものはすべて、それ以降の各turnでinput audioとして再送されます。第14章はこの点をtext streamのabortについて述べました。voiceでは30倍高くつきます。

動画は、あるベンダーでは秒単位で、別のベンダーではclip単位で売られ、解像度、時にはdurationに応じたtierがあります。この2つの形は単に利便性が違うだけではありません。交差します。

clip単位のベンダーは、1.2秒未満では秒単位のベンダーより高く、20秒では16.7倍安くなります。clip長を変えても維持される2モデルの順序はありません。だから「どのvideo modelが最安か」はモデルについての問いではありません。

最後の行はさらに厄介で、この章の正直な核心です。mochiは実GPU秒、つまりjobの測定されたprediction時間に対して課金されます。A100では秒$0.001400、H100では秒$0.001525で、これは借りた機械のレートそのものです。¹⁵ それは完全に正確な料金表ですが、価格ではありません。掛けられる数量が、支払いを約束した後まで分からないからです。上の行はoutput 1秒あたり12 GPU秒を仮定しています。その仮定を4倍にすると最安帯を離れ、6倍でようやく表の中ほどに着地します。このページで、見積もりに入れられない唯一の料金表です。

つまり、token、画像token、文字、分、video秒、clip全体、GPU秒、flat単位。8つの数量があり、それらを1つの軸に載せる唯一の方法は、workloadを宣言して価格計算することです。

これが第16章のcomputeCostへの拡張です。同じtier機構に、今度はprompt長ではないcriteriaが加わります。

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

印を付けた2行が壊れる場所です。単位あたりで引用された料金表はu.images ?? 1を掛けます。tokenあたりで引用された料金表は、defaultでゼロになる何かを掛けます。どちらにも空のusage、つまりmeasurementに失敗した時に得る形を与えて、見てみます。

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

6回何も起きず、1回は3ドルかかり、5回は何もかかりませんでした。これは丸め誤差ではありません。存在しない数値が何を意味するかについての判断で、単位ごとに別々に行われ、どこにも書かれていません。健全なルールは、誰も測定していないfieldはabsentのままにする、というものです。なぜなら「測定されていない」と「測定されてゼロだった」は違うからです。この関数は、静かにそれと食い違っています。

2つ目の失敗はdurationです。clip価格の料金表はmaxDurationSecondsをu.videoSeconds ?? 0と照合してtierを選ぶため、durationを記録しなかったusageは最短tierに一致します。

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

動画の長さが分からないだけで40 %オフです。2つのバグは同じ根を持ちます。正確であることが全仕事の関数の中で、都合のために選ばれたdefaultです。

costが計算できるようになったら、比較にはもう半分が必要です。engineごとに1つずつ、宣言された代表workloadを公開し、読者が反論できるようにします。

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を4分の1、outputを4分の3混ぜます。実使用はoutputに偏るからです。50対50のblendではモデル順位が変わります。画像workloadは1,500 output tokenを仮定します。OpenAIのmedium squareの1,056とmedium portraitの1,584の間です。動画は1080pで5秒を仮定し、1.2秒で2つのベンダーが入れ替わることをすでに見ました。compute項目は60 GPU秒を仮定します。ほかに仮定できるものがないからです。

これが方法であり、利用可能な唯一の正直な方法です。異なる単位の価格は比較できません。比較できるのは、書き下したworkloadのコストだけです。 workloadを印刷せずにmultimodalモデルを順位付けする表は、自分自身の仮定を順位付けしているだけです。

これで、モデルが生成できるものは、どの単位で売られていても価格計算でき、比較がどのworkloadを仮定したのかを声に出して言えるようになりました。これで第16章が開いた請求書は閉じます。そしてPart IIIも閉じます。第14章からここまでのすべては、1つのcallについてでした。どう作るか、何を入れるか、どうsampleするか、何が返るか、いくらかかるか。

第22章では分析単位が変わります。そしてその変化は高価です。agentは1つのcallではありません。自分で何回callするかを決めるloopです。前の2章の算術が、それをアーキテクチャ図からbudgetへ変えます。同じモデルに同じ質問を2回投げるところから始まります。2回目だけcatalogueにtoolを1つ追加し、その1つのtoolが何をしたかを測ります。1つのcallが2つになり、39 input tokenが420になりました。

それをagentと呼べるかは、公開された2つの定義のどちらを開くかによります。そして両者は一致しません。そのうち1つは、それ自身とも一致していません。

この章のすべての価格、式、変換率は、provider自身のページから2026年9月7日に読み取り、その日付付きで引用しています。すべて動くからです。token数、cost、比較は、上に印刷したcodeでそのdataから計算しました。1台のmachine上で実行し、有料API callは行っていません。それが、この章にlatency claimが1つもない正直な理由でもあります。

image-token関数、cost tables、voice-call breakdown、empty-usage resultsは、この章に印刷したTypeScriptをNode 22で実行して生成しました。voice比較に使ったdialogueは149語で、o200k_base encodingのもとtiktokenでtokenizeされ、188 tokenでした。そのdurationは宣言された150語/分のrateから来ており、比較のparameterであってmeasurementではありません。すべてのprovider figureには、それがどのpageから来たかを示すfootnoteが付いています。