ราคา Multimodal: รูปภาพ เสียง และวิดีโอคิดเงินจริงอย่างไร

transformer รับลำดับของเวกเตอร์ มันไม่สนว่าเวกเตอร์เหล่านั้นมาจากไหน บทที่ 8 ป้อน embeddings ที่ lookup จาก token id ให้มัน ไม่มีอะไรใน architecture บังคับว่าต้องมี lookup

ดังนั้น: ตัดภาพเป็นสี่เหลี่ยมขนาดคงที่ แผ่แต่ละสี่เหลี่ยมเป็นรายการตัวเลข แล้วดันแต่ละรายการผ่าน learned linear layer หนึ่งชั้นเพื่อให้ได้เวกเตอร์ที่มีความกว้างเท่ากับของโมเดล patch สีขนาด 32 × 32 คือ $32 \times 32 \times 3 = 3072$ ตัวเลข; projection $E \in \mathbb{R}^{d \times 3072}$ แปลงมันเป็นเวกเตอร์มิติ $d$ หนึ่งตัว ซึ่งมี shape เดียวกับที่ text token เข้ามาพอดี ทั้งหมดมีแค่นี้ และนี่คือ paper ที่ชื่อก็บอกไว้: รูปภาพหนึ่งภาพมีค่าเท่ากับคำ 16 × 16 คำ¹ เพิ่ม positional encoding เพื่อให้โมเดลรู้ว่าสี่เหลี่ยมไหนอยู่ตรงไหน สลับผลลัพธ์เข้ากับ text embeddings แล้วลำดับที่โมเดลอ่านก็เป็นรูปภาพส่วนหนึ่งและประโยคอีกส่วนหนึ่ง

paper สามฉบับทำให้มันกลายเป็นผลิตภัณฑ์ CLIP ฝึก image encoder และ text encoder ให้เห็นพ้องกัน บนคู่ข้อมูลที่ scrape มา 400 ล้านคู่ ซึ่งเป็นจุดที่แนวคิดว่า pixel และคำสามารถแชร์ space เดียวกันเลิกเป็นแค่สมมติฐาน² Flamingo เอา frozen vision encoder ไป bolt เข้ากับ frozen language model ด้วย bridging layers ที่ฝึกเพิ่มไม่กี่ชั้น³ LLaVA แสดงว่า bridge เป็น linear projection ชั้นเดียวได้ และสอน instruction-following ด้วยข้อมูลที่สร้างขึ้นได้ ซึ่งเป็นเหตุผลที่ open vision-language model ทุกตัวหลังจากนั้นหน้าตาใกล้เคียงกัน⁴

ผลต่อ invoice ของคุณตรงไปตรงมาและไม่หวือหวา: patches คือ positions ใน sequence ดังนั้นมันคือ input tokens ดังนั้นคุณจ่ายเงินตาม input rate จำนวนเท่าไรเป็นเลขคณิต และ provider แต่ละรายทำต่างกัน

กฎทุกข้อด้านล่าง implement จาก documentation ของ provider เอง และตรวจเทียบกับ worked examples ใน documentation เดียวกัน

OpenAI คลุมภาพด้วย patch 32 × 32 แล้วคูณจำนวนด้วย factor ต่อโมเดล หากจำนวน patch เกินงบของโมเดลและ detail level นั้น ภาพจะถูกย่อจนกว่าจะพอดี:

Anthropic คลุมภาพด้วย patch 28 × 28 หนึ่ง visual token ต่อ patch และกำหนดเพดานทั้งด้านยาวและจำนวน token — 1,568 pixels และ 1,568 tokens ในโมเดล standard-tier, 2,576 และ 4,784 ใน tier ความละเอียดสูง ภาพที่ใหญ่เกินจะถูก scale ลงสู่ขนาดใหญ่ที่สุดที่ยังพอดีกับทั้งสองเงื่อนไข⁵

Google ไม่ได้นับ pixels เลย ภาพที่ทั้งสองด้านยาวไม่เกิน 384 pixels คิดเหมา 258 tokens ภาพที่ใหญ่กว่านั้นจะถูกตัดเป็น tiles tile ละ 258 tokens และ grid ของ tile มาจาก crop unit ขนาด $\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;      
}

รันแต่ละกฎกับตัวเลขที่ vendor ของมันพิมพ์เอง:

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 ให้ทั้งสอง tier สำหรับทั้งหกขนาด ตอนนี้กฎเหล่านี้เป็นของคุณแล้ว จะรันกับภาพถ่ายไหนก็ได้ที่คุณมี และนั่นคือประเด็น: นี่คือ function เพียงสามตัวในบทนี้ที่คุณเอามาจากหน้าราคาไม่ได้

ส่งภาพถ่าย 4:3 ภาพเดียวกันผ่านทั้งสามระบบที่หกขนาด:

อ่านคอลัมน์สุดท้ายลงมา เมื่อภาพกว้างเกิน 384 pixels ตัวเลขไม่เปลี่ยนอีกเลย และนั่นไม่ใช่เรื่องบังเอิญหรือเพดาน แทน crop unit กลับเข้าไปในสูตร tile สำหรับภาพที่อย่างน้อยก็กว้างเท่ากับสูง:

ขนาดหักล้างกันหมด image tokens ของ Google ขึ้นกับ aspect ratio และไม่ขึ้นกับอย่างอื่นเลย ภาพถ่าย 4:3 มีสี่ tiles ไม่ว่าจะเป็น thumbnail หรือ poster ข้อเท็จจริงเชิงพีชคณิตข้อนี้เพียงข้อเดียวอธิบายศูนย์ในตาราง savings ด้านบนทั้งหมด และไม่มีหน้าราคาไหนระบุไว้

อีกสองคอลัมน์ใช้เพดานแทน ที่ความสูงต่างกันและด้วยเหตุผลต่างกัน — Anthropic ที่เพดาน token ที่ประกาศไว้, OpenAI ที่ patch budget หลังจาก pixel limit — จึงทำให้เส้นโค้งทั้งสามตัดกันที่ขนาดต่างกัน

ทีนี้ลองทำให้มันพัง วิธีที่ดูชัดเจนในการใช้เงินน้อยลงกับ vision model คือขอรายละเอียดน้อยลง ดังนั้นส่ง detail: "low":

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

การขอ detail น้อยลง กลับแพงขึ้น 25 % นี่ไม่ใช่ bug และ OpenAI บอกไว้ในบรรทัดหนึ่งของ sizing table: ใน model family นั้น low ใช้ 2048-pixel limit พร้อม 6,144-patch budget ขณะที่ high ใช้ pixel limit เดียวกันพร้อม 2,500-patch budget "so it can use more tokens than high"⁷ คำว่า low ตั้งชื่อ fidelity setting ไม่ใช่ราคา: ในสองจากห้า model families ที่ document ไว้ มันไม่ประหยัดเลย และในหนึ่งจากสองนั้น มันแพงกว่า

ทุกอย่างจนถึงตอนนี้คือโมเดล อ่าน รูปภาพ การสร้างรูปภาพหนึ่งภาพทำงานบนกลไกที่ไม่มี token อยู่เลย และนั่นคือเหตุผลที่มันถูกขายเป็นราคาต่อภาพ ไม่ใช่ต่อคำ

Vendors เผยแพร่ image generation เป็นราคาต่อภาพ แต่มันไม่ใช่ GPT Image models ปล่อย image tokens เฉพาะทางที่จำนวนขึ้นกับ size และ quality ที่ขอ; คูณจำนวนที่เผยแพร่ด้วย image output rate ที่เผยแพร่ของ GPT Image 1 ที่ $40 ต่อหนึ่งล้าน แล้วเทียบกับราคาต่อภาพในหน้าเดียวกัน:

ตัวเลขที่ derive มาเก้าตัวเทียบกับตัวเลขที่เผยแพร่เก้าตัว ทุกคู่ตรงกันภายใน $0.002¹¹ Google ยิ่ง explicit กว่านั้น และทำ conversion ให้คุณบนหน้าราคาเอง: image output ที่ $60 ต่อหนึ่งล้าน tokens, "output images at 1K (1024x1024px) consume 1120 tokens and are equivalent to $0.067 per image"¹²

ดังนั้นราคาต่อภาพคือราคาต่อ token ที่พับจำนวนเข้าไปแล้ว ซึ่งก็ไม่เป็นไร และมันซ่อนบางอย่างไว้ เอาตารางของ generation ปัจจุบันแล้วหารย้อนกลับ:

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 canvas 1024 × 1536 มี pixels มากกว่า 1024 × 1024 อยู่ 50 % และใช้ tokens น้อยกว่า 23 % ที่ medium OpenAI ชี้ไว้ในประโยคที่คุณน่าจะข้าม — "a larger non-square resolution can sometimes produce fewer output tokens than a smaller or square resolution at the same quality setting" — และใน model generation ก่อนหน้า มันวิ่งกลับทาง portrait แพงกว่า square 50 %¹¹ ค่า default ของ 1024x1024 ทุกตัวที่เขียนไว้ก่อนการเปลี่ยนแปลงนั้น ตอนนี้เป็นตัวเลือกที่แพง

ขอให้ผลิตภัณฑ์สามตัวพูดข้อความ 519 ตัวอักษรเดียวกัน — เสียงประมาณ 38 วินาที — แล้วคุณได้ระบบหน่วยสามแบบจาก vendors สองราย:

vendor รายเดียวขายทั้งสองหน่วย: tts-1 ของ OpenAI คิดราคาต่อหนึ่งล้านตัวอักษร ขณะที่ gpt-4o-mini-tts คิดราคาต่อหนึ่งล้าน tokens, $0.60 เข้าและ $12.00 ออก¹³ ดังนั้น "text-to-speech ที่ถูกที่สุด" จึงไม่ใช่คำถามที่มีคำตอบ จนกว่าคุณจะบอกว่าคุณกำลังพูดอะไร

และสองหน่วยนี้บอดต่อสิ่งตรงข้ามกัน ราคาต่อตัวอักษรมองไม่เห็น duration: เลือกเสียงที่ช้า ตั้งใจพูด หรือเพิ่ม pause แล้วบิลไม่ขยับในขณะที่ audio ยาวขึ้น ราคาต่อวินาทีมองไม่เห็น content: สามสิบวินาทีราคาเท่ากันไม่ว่าจะเป็นย่อหน้าทางเทคนิคที่แน่นมาก หรือคนกำลังนับหนึ่งถึงสิบ เปลี่ยน voice แล้ว vendor หนึ่งในสองรายของคุณเท่านั้นที่ reprice

Transcription วิ่งกลับทางและเป็นบรรทัดที่ง่ายที่สุดใน invoice ทั้งหมด — คิดตามนาทีของ audio แบบ flat:

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)

สังเกตแถวสุดท้ายเทียบกับแถวที่สาม: การทำแบบ live ขณะที่คำพูดเข้ามา แพงกว่าการทำกับไฟล์ที่เสร็จแล้ว 5.7 เท่า ช่องว่างนั้นคือราคาของการ batch ไม่ได้ และเป็นสิ่งที่ทำให้ส่วนถัดไปแพง

ทีนี้คือตัวเลขที่ตัดสินว่า voice เป็น feature หรือ product

สายสนทนา: บทสนทนา support สิบ turn, 149 คำ ซึ่งที่อัตรา 150 words per minute ที่ประกาศไว้ เท่ากับ speech 59.6 วินาที — 21.2 วินาทีพูดโดยผู้โทร, 38.4 วินาทีพูดตอบกลับ token conversions เป็นของ providers เอง 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"¹⁴ เพียงแต่ตอนนี้ history ถูกวัดเป็น audio tokens

ทีนี้คือการเปรียบเทียบที่ตัดสิน product ทั้งสี่ normalise เป็นหนึ่งนาที:

สามสิบแปดเท่า ไม่ใช่สามสิบแปดเปอร์เซ็นต์ การแลกเปลี่ยนข้อมูลเดียวกันทุกอย่าง แต่ทำในรูปเสียงแทน text แพงกว่าเกือบสอง order of magnitude และช่องว่างนั้นไม่มีส่วนไหนเป็น margin ที่ใครเลือกจะชาร์จ — มันคือ conversion rate เสียง assistant หนึ่งวินาทีคือยี่สิบ tokens วินาทีเดียวกันนั้นบรรทุก 2.5 คำตาม rate ที่ประกาศ และ transcript ที่วัดได้วิ่งที่ 1.26 tokens ต่อคำ ดังนั้นเมื่อเป็น text มันคือ 3.15 tokens เสียงเป็น package ที่ เทอะทะกว่า 6.3 เท่า สำหรับความหมายเดียวกัน และ token ของมันแต่ละตัวถูกคิดเงินที่ 5.3 เท่าของ text output rate และ 16 เท่าของ text input rate คูณ bulk ratio ด้วย price ratio แล้ว order of magnitude ก็อยู่ตรงนั้นแล้วก่อนบัญชีใด ๆ จะเริ่ม

ผลเชิงปฏิบัติการสองอย่างหล่นออกจากตารางโดยตรง

Audio caching ไม่ใช่ optimisation แต่มันคือ business model Cached audio input อยู่ที่ $0.40 ต่อหนึ่งล้าน เทียบกับ fresh $32.00 — ส่วนลด 98.75 % ที่ลดค่า call ลงครึ่งหนึ่ง กฎคือของบทที่ 16 ไม่เปลี่ยน: cache match prefix ดังนั้นอะไรที่ถูกแทรกไว้ด้านหน้าของบทสนทนากลางสายจะทำลายมัน และตำแหน่งธรรมชาติที่จะใส่ "ตอนนี้ผู้โทรยืนยันตัวตนแล้ว" ก็คือตรงนั้นพอดี

และไม่มีอะไรที่คุณทำใน client จะ un-bill เสียงได้ ผู้ใช้พูดแทรก assistant, code ของคุณหยุด playback, speaker เงียบลง อะไรก็ตามที่ถูก generate ไปแล้วถูก charge ไปแล้ว เพราะ billing accrue เมื่อ response ถูกสร้าง; และตามกฎของบทที่ 16 อะไรก็ตามที่ยังอยู่ใน conversation จะถูกส่งซ้ำเป็น input audio ทุก turn หลังจากนั้น บทที่ 14 พูดประเด็นนี้เกี่ยวกับการ abort text stream ใน voice มันแพงกว่าสามสิบเท่า

วิดีโอถูกขายเป็นราคาต่อวินาทีโดย vendors บางราย และต่อ clip โดยบางราย พร้อม tiers ตาม resolution และบางครั้งตาม duration รูปทรงสองแบบนี้ไม่ได้ต่างกันแค่ความสะดวก; มันตัดกัน

vendor แบบต่อ clip แพงกว่าแบบต่อวินาทีเมื่อสั้นกว่า 1.2 วินาที และถูกกว่า 16.7 เท่าที่ความยาวยี่สิบวินาที ไม่มีการจัดอันดับของสองโมเดลนี้ที่รอดจากการเปลี่ยนความยาว clip ดังนั้น "video model ไหนถูกที่สุด" จึงไม่ใช่คำถามเกี่ยวกับโมเดล

แถวสุดท้ายแย่กว่า และเป็นหัวใจที่ซื่อสัตย์ของบทนี้ mochi ถูกคิดเงินตาม GPU seconds จริง — prediction time ที่วัดได้ของ job — ที่ $0.001400 ต่อวินาทีบน A100 และ $0.001525 บน H100 ซึ่งเป็น rate ของเครื่องเช่าเท่านั้น¹⁵ นั่นเป็น tariff ที่แม่นยำสมบูรณ์แบบ และมัน ไม่ใช่ราคา เพราะปริมาณที่มันคูณด้วยไม่รู้จนกว่าคุณจะ commit ว่าจะจ่ายมันไปแล้ว แถวด้านบน assume สิบสอง GPU-seconds ต่อหนึ่งวินาทีของ output; เพิ่มสมมติฐานนั้นสี่เท่าแล้วมันหลุดจาก band ที่ถูกที่สุด และเมื่อหกเท่าเท่านั้นจึงลงกลางตาราง มันเป็น tariff เดียวในหน้านี้ที่คุณใส่ใน quote ไม่ได้

ดังนั้น: tokens, image tokens, ตัวอักษร, นาที, video seconds, clips ทั้งก้อน, GPU seconds, flat units แปดปริมาณ และวิธีเดียวที่จะวางทั้งหมดบนแกนเดียวกันได้คือประกาศ workload แล้วคิดราคา

นี่คือ extension ของ computeCost จากบทที่ 16 — tier machinery เดิม แต่ตอนนี้มี criteria ที่ไม่ใช่ 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;
}

สองบรรทัดที่ mark ไว้คือจุดที่มันพัง tariff ที่ quote ต่อ unit คูณ u.images ?? 1; tariff ที่ quote ต่อ token คูณสิ่งที่ default เป็นศูนย์ ป้อน usage ว่างให้ทั้งคู่ — shape ที่คุณได้เมื่อ 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

ไม่มีอะไรเกิดขึ้นหกครั้ง และมัน cost สามดอลลาร์หนึ่งครั้งกับไม่ cost อะไรเลยห้าครั้ง นั่นไม่ใช่ความต่างจาก rounding; มันคือการตัดสินใจว่าเลขที่หายไปหมายความว่าอะไร ซึ่งถูกทำแยกกันสำหรับแต่ละ unit และไม่เคยเขียนไว้ กฎที่ถูกต้องคือ field ที่ไม่มีใครวัดจะยังคง absent เพราะ "not measured" กับ "measured and came out zero" เป็นคนละเรื่องกัน function นี้กลับไม่เห็นด้วยอย่างเงียบ ๆ

failure ที่สองคือ duration tariff แบบคิดราคา clip เลือก tier ด้วย maxDurationSeconds เทียบกับ u.videoSeconds ?? 0 ดังนั้น usage ที่ไม่เคยบันทึก duration จะ match tier ที่ สั้นที่สุด:

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

ลด 40 เปอร์เซ็นต์เพราะไม่รู้ว่าวิดีโอยาวเท่าไร bug ทั้งสองมีรากเดียวกัน: default ที่เลือกเพื่อความสะดวกภายใน function ที่หน้าที่ทั้งหมดคือความแม่นยำ

เมื่อคำนวณต้นทุนได้แล้ว การเปรียบเทียบต้องมีอีกครึ่งหนึ่ง — 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 },
};

ทุกบรรทัดในนั้นคือ argument Text ผสม input หนึ่งในสี่และ output สามในสี่ เพราะการใช้งานจริงเอนเอียงไปทาง output; blend ห้าสิบห้าสิบจัดอันดับโมเดลต่างออกไป image workload assume output tokens 1,500 ระหว่าง 1,056 ของ OpenAI สำหรับ medium square กับ 1,584 สำหรับ medium portrait วิดีโอ assume ห้าวินาทีที่ 1080p และเราเพิ่งเห็น vendors สองรายสลับตำแหน่งกันที่ 1.2 วินาที compute entry assume หกสิบ GPU-seconds เพราะไม่มีอย่างอื่นให้ assume

นี่คือวิธีการ และเป็นวิธีเดียวที่ซื่อสัตย์ที่มี: คุณเปรียบเทียบราคาในหน่วยต่างกันไม่ได้; คุณเปรียบเทียบได้เพียงต้นทุนของ workload ที่คุณเขียนไว้ ตารางใดก็ตามที่ rank multimodal models โดยไม่พิมพ์ workload ของตัวเอง กำลัง rank สมมติฐานของตัวเอง

ตอนนี้คุณคิดราคาทุกอย่างที่โมเดลผลิตได้ ไม่ว่าจะขายในหน่วยไหน และพูดออกมาชัดเจนได้ว่า comparison ของคุณ assume workload ใด นั่นปิด invoice ที่บทที่ 16 เปิดไว้ และปิด Part III: ทุกอย่างตั้งแต่บทที่ 14 ถึงตรงนี้ว่าด้วย หนึ่ง call — ทำอย่างไร ใส่อะไรเข้าไป sample อย่างไร return อะไร cost เท่าไร

บทที่ 22 เปลี่ยน unit of analysis และการเปลี่ยนนั้นแพง agent ไม่ใช่หนึ่ง call; มันคือ loop ที่ตัดสินใจเองว่าจะทำกี่ call และเลขคณิตของสองบทล่าสุดคือสิ่งที่แปลงมันจาก architecture diagram เป็น budget บทนั้นเปิดด้วยการถามคำถามเดียวกันกับโมเดลเดียวกันสองครั้ง โดยเพิ่ม tool หนึ่งตัวเข้า catalogue ในครั้งที่สอง แล้ววัดว่า tool หนึ่งตัวนั้นทำอะไร: หนึ่ง call กลายเป็นสอง, input tokens สามสิบเก้ากลายเป็น 420

สิ่งนั้นจะทำให้มันเป็น agent หรือไม่ ขึ้นกับว่าคุณเปิดนิยามที่เผยแพร่ไว้ชุดใดในสองชุด และสองชุดนั้นไม่เห็นตรงกัน ชุดหนึ่งยังไม่เห็นตรงกับตัวเองด้วยซ้ำ

ราคา สูตร และ conversion rate ทุกตัวในบทนี้อ่านจากหน้าของ provider เองเมื่อ 7 กันยายน 2026 และ quote พร้อมวันที่นั้น เพราะทั้งหมดจะขยับ token counts, costs และ comparisons คำนวณจากข้อมูลนั้นด้วย code ที่พิมพ์ด้านบน บนเครื่องเดียว โดยไม่ได้เรียก paid API เลย — ซึ่งเป็นเหตุผลที่ซื่อสัตย์เช่นกันว่าทำไมบทนี้จึงไม่มี latency claim แม้แต่รายการเดียว

image-token functions, cost tables, voice-call breakdown และ empty-usage results ผลิตโดย TypeScript ที่พิมพ์ในบทนี้ รันบน Node 22 dialogue ที่ใช้สำหรับ voice comparison มี 149 คำ และถูก tokenize ด้วย tiktoken ภายใต้ encoding o200k_base ที่ 188 tokens; duration ของมันมาจาก declared rate 150 words per minute ซึ่งเป็น parameter ของ comparison ไม่ใช่ measurement ตัวเลข provider ทุกตัวมี footnote ที่ระบุหน้าแหล่งที่มา