一張圖片算幾個權杖？15 個 API 實測：6 到 1,298
目錄
同一張 1024x1024 圖片，在 GPT-5.6 會計入 693 個輸入權杖，Qwen 3.8 Max 是 988 個，Gemini 是 1,089 個，Claude 則是 1,372 個。套用各供應商的輸入費率後，15 個視覺模型處理一張圖片的費用介於 $0.00005 與 $0.0137。差距幾乎完全來自各模型的輸入費率，而不是圖片 tokenizer。五家供應商公布了圖片計費規則，但我們的實測結果與其中三家不符。這篇是文字 tokenizer 實測的圖片篇：將本機產生的相同 PNG 傳給目錄中的每個視覺模型，分別測量有圖與無圖時的 prompt token，兩者相減即為圖片成本。測試涵蓋六種尺寸、五種長寬比、三種內容、三種檔案格式，以及一次放入一到四張圖片的情境。
TL;DR
- 一張 1024x1024 圖片：GPT-5.6 為 693 個權杖，Gemini 為 1,089 個，Claude 為 1,372 個；費用從 $0.00005（qwen3-vl-flash）到 $0.0137（claude-fable-5）。
- 三種計費方式：patch 公式（Qwen：精確符合 (side/32)²+2）、設有上限的 tile（GPT 到 693 就封頂），以及固定費用（Gemini 不分尺寸一律 1,089，縮圖也不例外）。
- 三條文件規則與實測不符：Claude 旗艦模型約在 1,920px 才縮圖，不是 1,568；Gemini 文件寫 258，實際固定收 1,089；Qwen 使用 32px 網格，不是 28。
- 檔案格式與內容完全不影響權杖數：計費只看幾何尺寸。
各家供應商如何說明圖片計費方式？
七個模型家族中有五個公布了計費規則，其中三家的規則經不起實測。下表濃縮了整篇文章；後續各節不是提供規則不符的實測證據，就是說明文件完全沒提到的成本行為：
| 家族 | 文件說法 | 實測結果 |
|---|---|---|
| OpenAI | 使用 32px patch，各模型有自己的 patch 額度（文件） | 行為吻合：64px 為 6 個權杖，硬上限為 693 個 |
| Anthropic | (w x h)/750，長邊超過 1,568px 後縮圖（文件） | 在 512-1,024px 時公式完全吻合；1,568 上限只適用於 Haiku，旗艦模型會持續計費到約 1,920px |
| 圖片不超過 384px 時計 258 個權杖，更大的圖片每個 768px tile 計 258 個（文件） | 所有尺寸固定為 1,089，包括 64px 圖示；我們測試的介面中，文件所列的 media_resolution 設定沒有任何可用寫法 | |
| Alibaba | 每個 28x28px 計一個權杖，最低 4 個（文件） | qwen3-vl 精確符合 32px 網格（(side/32)²+2），最低 66 個，1,600px 封頂 |
| Moonshot | 動態計算權杖，未公布公式，接受最高 4K 圖片（文件） | 行為一致：呈二次方成長，測到 3,072px 仍未發現上限（11,674 個權杖） |
| MiniMax / ByteDance | 找不到公開公式 | MiniMax 呈二次方成長，2,048px 封頂；ByteDance 固定每張 1,298 個 |
右欄呈現出一個明確模式：文件中的規則全都以幾何尺寸為核心，包括 patch、tile 與除數。幾何規則可以量測，所以我們直接實測。兩欄不一致時，預算試算表也會跟著算錯：若 Claude 旗艦模型的 pipeline 依文件所寫的 1,568px 上限估算，大圖預算會低估約 45%；若 Gemini pipeline 預期縮圖只需 258 個權杖，實際上每個圖示都要支付 4.2 倍。
一張圖片需要多少權杖？
在我們的測試矩陣中，答案介於 6 到 5,486，取決於模型與尺寸，而權杖數只決定了一半的帳單。下表是同一張 1024x1024 PNG 傳給目錄中每個視覺模型的結果，並套用各模型的輸入費率：
| 模型 | 權杖數（1024²） | 約等於多少英文單字 | × 模型每 1K 輸入權杖價格 | 輸入費率 /1M | 每張圖片費用 |
|---|---|---|---|---|---|
| qwen3-vl-flash | 1,026 | 約 770 | 1.03x | $0.05 | $0.00005 |
| qwen3-vl-plus | 1,026 | 約 770 | 1.03x | $0.20 | $0.0002 |
| minimax-m3 | 1,371 | 約 1,030 | 1.37x | $0.30 | $0.0004 |
| Dola-Seed-2.0-pro | 1,298 | 約 970 | 1.30x | $0.50 | $0.0006 |
| gpt-5.6-luna | 693 | 約 520 | 0.69x | $1.00 | $0.0007 |
| gemini-3.7-flash | 1,089 | 約 820 | 1.09x | $0.75 | $0.0008 |
| claude-haiku-4-5 | 1,373 | 約 1,030 | 1.37x | $1.00 | $0.0014 |
| gemini-3.6-flash | 1,089 | 約 820 | 1.09x | $1.50 | $0.0016 |
| qwen3.8-max | 988 | 約 740 | 0.99x | $2.00 | $0.0020 |
| gemini-3.1-pro-preview | 1,089 | 約 820 | 1.09x | $2.00 | $0.0022 |
| claude-sonnet-5 | 1,372 | 約 1,030 | 1.37x | $2.00 優惠價 | $0.0027 |
| kimi-k3 | 1,379 | 約 1,030 | 1.38x | $3.00 | $0.0041 |
| claude-opus-5 | 1,372 | 約 1,030 | 1.37x | $5.00 | $0.0069 |
| claude-fable-5 | 1,372 | 約 1,030 | 1.37x | $10.00 | $0.0137 |
這裡有三個重點。第一，這個換算非常直接：以每個權杖約 0.75 個英文單字計算，一張 1024px 圖片占用的 context 預算，相當於一份 520 到 1,030 個英文單字的文件。這也是圖片密集的對話比純文字更快耗盡 context window 與預算的原因。第二，美元成本幾乎完全由費率決定。各模型的權杖數集中在 2 倍範圍內（693 到 1,379），因此一張圖片的費用，大致是該模型每 1,000 個輸入權杖價格的 0.69x 到 1.38x；美元欄位基本上只是再次反映各模型的輸入費率。第三，同一家族確實共用 tokenizer：兩個 qwen3-vl 版本、兩個 GPT-5.6 版本、三個 Gemini，以及四個 Claude 模型，在每個正方形圖片尺寸下都回傳完全相同或幾乎相同的結果。這與我們在文字實測中觀察到的「每個家族共用一套 tokenizer」模式一致。
哪些因素決定圖片的權杖成本？
五個因素會改變帳單，另有三個常被認為有影響，實際上卻完全無關。後續內容會逐項深入說明下表：
| 因素 | 影響 | 適用範圍 |
|---|---|---|
| 計費方式 | patch 公式、設上限的 tile，或固定費用 | 見下方計費方式表 |
| 解析度（面積） | 最主要的因素，大致呈二次方成長 | 除兩個固定費用模型外的所有模型 |
| 縮圖上限 | 超過上限的像素不再計費 | 1,600px（Qwen）、約 1,920px（Claude 旗艦）、1,568px（Haiku）、693 個權杖上限（GPT）；Kimi 無上限 |
| 長寬比 | 次要因素：外接網格對長條圖收費較高，長邊上限則會降低極端比例的費用 | GPT 在 3:1 時增加 84%，到 8:1 時反而減少 11%；Haiku 在 8:1 時減少 71% |
| 圖片數量 | 嚴格線性累加，沒有數量折扣 | 全部 15 個模型 |
| 內容（照片、文字或空白） | 沒有影響 | 所有受測模型 |
| 檔案格式（PNG/JPEG/WebP） | 沒有影響 | 所有受測模型 |
| 檔案位元組大小 | 沒有影響 | 所有受測模型 |
後三項值得特別說明，因為這兩種錯誤觀念都很常見：測試矩陣中沒有任何 API 會根據壓縮率或圖片複雜度計費。輸入幾何尺寸，輸出權杖數。
圖片計費有哪三種方式？
三種方式分別是 patch 公式、設有上限的 tile，以及固定費用。它們對小圖的定價差異很大。我們以六個尺寸進行階梯測試，從 64px 到 2,048px 的正方形圖片：
| 模型 | 64px | 128px | 256px | 512px | 1,024px | 2,048px | 計費方式 |
|---|---|---|---|---|---|---|---|
| qwen3-vl（兩者） | 66 | 66 | 66 | 258 | 1,026 | 2,502 | patch：(side/32)²+2，最低 8x8，1,600px 封頂 |
| qwen3.8-max | 28 | 28 | 28 | 220 | 988 | 2,464 | patch，最低值較小 |
| gpt-5.6（兩者） | 6 | 21 | 78 | 309 | 693 | 693 | tile，硬上限 693 |
| gemini（三者） | 1,089 | 1,089 | 1,089 | 1,089 | 1,089 | 1,089 | 固定費用，不分尺寸 |
| Dola-Seed-2.0-pro | 1,298 | 1,298 | 1,298 | 1,298 | 1,298 | 1,298 | 固定費用，不分尺寸 |
| kimi-k3 | 17 | 33 | 108 | 369 | 1,379 | 5,486 | 二次方成長，未發現上限 |
| minimax-m3 | 18 | 27 | 102 | 363 | 1,371 | 5,186 | 二次方成長，2,048px 封頂 |
| claude（四者） | 12 | 28 | 103 | 364 | 1,372 | 4,764 | (w x h)/750，設有縮圖上限 |
Qwen 的公式精確到足以直接用於預算估算：1,024px 正方形圖片會計為 (1024/32)² + 2 = 1,026，實測逐一權杖吻合。最低值會補齊為 8x8 個 patch（66），縮圖上限則是 1,600px（從 1,600 到 1,920px 的實測結果全都正好是 2,502）。GPT 採 tile 計算，最高到 693，絕不超過：1,024px 與 2,048px 圖片費用相同。固定費用模型對縮圖流量尤其不利：Gemini 對 64px 圖示收取 1,089 個權杖，與縮圖後的 4K 螢幕截圖相同；Seed 則固定收取 1,298 個。另一端的 Kimi K3 超過其他模型的上限後仍持續成長：3,072px 正方形圖片計入 11,674 個權杖，是測試矩陣中唯一始終未觀察到縮圖行為的模型。
縮圖邊界究竟在哪裡？
除了 Kimi，每個家族都會在計費前縮小大型圖片，而實際邊界應以量測結果為準，不是文件說法。Claude 的邊界尤其值得細看，因為在 claude-sonnet-5 以上的模型會直接影響實際費用：1,568px 計 3,139 個權杖，1,728px 計 3,847 個，1,920px 計 4,764 個，之後不再增加（2,048px 與 2,304px 也都是 4,764）。三個旗艦模型會對超過文件上限約 45% 的實際像素繼續計費；只有 claude-haiku-4-5 符合文件描述。若能控制上傳 pipeline，請在編碼前依各模型的實測上限縮圖。超過邊界的像素不是繼續收費（Kimi），就是被直接丟棄（其他模型）；上傳過大的圖片只會浪費頻寬，沒有其他收益。
圖片形狀、內容或檔案格式會影響帳單嗎？
我們觀察到的所有形狀差異，都能由兩個因素解釋，而且都與檔案大小無關：模型計算的是面積還是外接網格，以及它的長邊縮圖門檻設在哪裡。至於內容與格式，所有模型都完全不受影響：512px 的純色圖片、雜訊圖與文字頁面，在每個受測模型上的計費都相同。同一張圖片分別存成 243KB（PNG）、176KB（JPEG）與 174KB（WebP），結果也完全一致。
這項因素測試將面積固定為一百萬像素，只改變圖片形狀：
| 模型 | 1:1 | 2:1 | 3:1 | 4:1 | 8:1（長邊 2,896px） |
|---|---|---|---|---|---|
| gpt-5.6（兩者） | 693 | 1,271 | 1,278 | 1,230 | 616 |
| claude 旗艦三款 | 1,372 | 1,355 | 1,411 | 1,409 | 1,107 |
| claude-haiku-4-5 | 1,373 | 1,356 | 1,068 | 788 | 396 |
| minimax-m3 | 1,371 | 1,352 | 1,410 | 1,298 | 650 |
| kimi-k3 | 1,379 | 1,361 | 1,417 | 1,415 | 1,361 |
| qwen3-vl（兩者） | 1,026 | 1,037 | 992 | 1,026 | 992 |
| gemini（三者） | 1,089 | 1,081 | 1,083 | 1,056 | 1,034 |
| Dola-Seed-2.0-pro | 1,298 | 1,277 | 1,304 | 1,298 | 1,315 |
對照這兩個因素即可理解各列結果。Qwen、Kimi、Gemini 與 Seed 幾乎不變：只看面積，或採固定費用，不另計形狀。GPT 是唯一使用外接網格計費的模型；相同像素數的長條圖，費用最多比正方形高 84%。到了 8:1，圖片跨過長邊上限，縮圖後反而抵消溢價，只需 616 個權杖，比正方形還便宜。採長邊縮圖門檻的模型家族，也會在各自的邊界出現相同轉折：Haiku 從 3:1 開始降價（長邊 1,774 超過其 1,568 上限，依序為 1,068、788、396）；Claude 旗艦模型要到 8:1 才降價（2,896 超過約 1,920px 的邊界，降至 1,107）；MiniMax 也在 8:1 超過 2,048 後降至 650。對寬幅文件與螢幕截圖流量而言，實務做法很明確：使用 GPT 時，應自行切割或縮小長條圖；使用 Haiku 時，極端長寬比反而是 Claude 最便宜的像素。
哪些方法真的能降低圖片輸入成本？
依影響程度排序有三種。第一，縮放到模型的上限：超過縮圖邊界的每個像素，在 Kimi 上仍會計費（無上限），在其他模型上則全數浪費。第二，在 GPT 使用 detail: "low"：512px 時沒有差異（三種設定都是 309），但 2,048px 時會將圖片固定在 309 個權杖，相較 high 或 auto 的 693 個減少 55%。這也是我們找到唯一能在單次請求中調整圖片成本的模型參數。第三，依工作負載選擇計費方式：固定費用模型（Gemini、Seed）不適合縮圖與圖示流量，卻適合尺寸一致的大型掃描文件；patch 與 tile 模型會按小圖實際尺寸收費（64px 圖示在 GPT 為 6 個權杖，在 Kimi 為 17 個）。
多圖片請求沒有任何折扣：在同一則訊息中放入 1、2、4 份相同圖片時，全部 15 個模型都嚴格線性累加，每張都按完整單張價格計費。這種算法對固定費用模型的影響最大：在一次 Gemini 請求中放入四張 256px 縮圖，需要 4,356 個圖片權杖；同樣四張圖片在 qwen3-vl-flash 只需 264 個。
常見問題
一張 1024x1024 圖片需要多少權杖？
使用同一張 PNG 實測：GPT-5.6 為 693，Qwen 3.8 Max 為 988，qwen3-vl 為 1,026，Gemini 為 1,089，ByteDance Seed 為 1,298，MiniMax 為 1,371，Claude 為 1,372，Kimi K3 為 1,379。相較於 2 倍的權杖差距，套用的費率更重要：美元成本從 $0.00005（qwen3-vl-flash）到 $0.0137（claude-fable-5）。
圖片檔案格式或壓縮率會影響權杖成本嗎？
不會，所有受測模型都相同：同一張 512px 圖片分別存成 PNG（243KB）、JPEG（176KB）與 WebP（174KB），計入的權杖數完全一致；純色、雜訊與文字密集內容也相同。計費只取決於像素尺寸；壓縮是為了節省頻寬，不是權杖。
detail: "low" 能減少圖片權杖嗎？
在 GPT-5.6 上可以，但只對超過小圖門檻的圖片有效：2,048px 圖片在 low 設定下為 309 個權杖，high 或 auto 則為 693 個，減少 55%；512px 時三種設定都是 309。測試矩陣中的其他模型，都沒有提供可用的單次請求圖片成本調整參數。
在一次請求中批次傳送多張圖片會更便宜嗎？
不會：在每個模型上，1、2、4 份相同圖片的費用都嚴格線性累加，每張圖片仍按完整價格計費。批次處理可減少請求開銷與延遲，但不會減少圖片權杖；對固定費用模型（Gemini、Seed）而言，一次請求放入多張小圖反而是成本最高的形式。
測量時間為 2026-08-13/14，透過 Synthorai 閘道測試 17 個模型（15 個視覺模型、2 個純文字對照模型）：使用本機依精確尺寸產生的 PNG，將含圖片的 prompt token 減去加入隨機字串但文字相同的基準值，得到圖片成本；測試包含六段尺寸階梯（64-2,048px）、最高至 3,072px 的邊界探測、六種 1MP 長寬比（1:1 至 8:1，另含 1:4 直式長圖）、三種內容、PNG/JPEG/WebP、GPT 的 detail low/high/auto、1/2/4 張圖片堆疊，以及每個模型的代碼詞辨識檢查。美元金額以實測權杖數乘上測量當日各模型頁面列出的輸入費率計算（Sonnet 5 採 $2 優惠費率）。視覺計費規則可能隨時變更；若要依賴任何單一數值，請先重新執行尺寸階梯測試。