核验清单

  • ✓是否已经在自己实际调用的模型（比如DeepSeek的视觉模型、通义千问的qwen-vl系列）官方API文档的计费/定价章节里，查过图片输入具体是怎么折算成token的，而不是凭印象套用别的模型的规则
  • ✓是否核对过自己业务里实际传入的图片分辨率/尺寸，跟官方文档里给出的计算依据（分辨率、尺寸或精度模式）是否对得上，有没有超出官方说明的取值范围
  • ✓如果调用的模型支持"低精度/高精度"或类似的图片处理模式选项，是否已经确认自己当前用的是哪一种，以及这个选择跟账单token数之间的关系
  • ✓上线批量处理图片的功能之前，是否已经拿几张真实业务场景里会用到的样本图片（不同分辨率、不同内容类型）实际调用一遍，去账单或usage明细里看真实消耗了多少token，而不是直接假设图片和等量文字的token消耗一样
  • ✓是否已经把"单张图片实测token数 × 预计图片调用量"这个粗算结果，跟纯文本部分的预计token消耗加在一起，得到过一个相对完整的月度成本预估，而不是只按文字部分估算总成本

1. 现象：图片理解API的账单，不能按文字token的直觉去心算

调用DeepSeek、通义千问这类国内大模型的多模态能力时，只要请求里包含了图片（比如做图片内容理解、截图问答、文档扫描件识别这类场景），账单上产生的token消耗就不能简单套用纯文本场景下"数字数、按比例换算"的直觉。文本输入时，开发者大致能通过字数估算出一个token区间；但图片输入的token数从哪里来、由什么决定，跟文字完全是两套逻辑。很多开发者第一次看到图片理解相关调用的账单时会困惑：明明只发了一张图和一句简短的提示词，账单里却记了远超预期的token数——这背后就是图片按某种规则被折算成了token，而这套折算规则本身，跟平时熟悉的文字token计算方式并不是同一件事。

2. 折算通常跟什么有关：分辨率、尺寸，以及是否开启高精度模式

那么一张图片具体会被折算成多少token，通常由哪些因素决定？根据主流厂商公开的技术说明，比较普遍的规律是：图片会先按照分辨率或像素尺寸转换为token，图片本身越大、分辨率越高，折算出来的token数往往也越多，这跟视觉模型需要把图片切分成若干个"图块"分别编码理解有关，图块数量通常随分辨率上升而增加。另外，不少厂商的视觉理解模型还提供了区分处理精度的选项——比较简化、粗粒度的处理模式（有的厂商称作"低精度"）通常对应更少的token消耗，而需要看清楚图片里细节文字或小物体的场景（比如OCR、文档识别），往往需要开启更精细的处理模式，此时消耗的token数会明显更高。需要特别说明的是：具体的折算公式、图块划分规则、精度模式怎么切换，不同厂商、同一厂商的不同模型版本都可能不一样，不存在一套全行业统一的换算标准，这里只是说明"跟什么因素相关"这个大方向，具体数字必须去查自己实际调用模型对应的官方文档。

3. 该去哪里查：官方API文档的多模态计费章节，而不是第三方估算

既然折算规则因厂商、因模型版本而异，开发者最可靠的做法是直接去自己实际调用的那个模型的官方API文档里查证，而不是参考网上流传的某个通用公式或者别的模型的规则往自己身上套。以DeepSeek为例，官方定价与接口文档里会说明图片输入是按尺寸转换为token、和文本token一起计入输入消耗；以阿里云百炼平台的通义千问视觉理解系列（qwen-vl等）为例，官方计费说明页会给出这类模型按输入/输出token计费的整体规则，具体到图片如何转换为token数、是否区分处理精度，会在配套的视觉理解使用指南里进一步说明，且随模型版本更新可能调整。核对时建议重点确认三件事：这个模型是否公开了图片转token的具体计算依据、是否提供了精度或分辨率相关的可调参数、以及账单或调用返回的usage字段里能不能看到图片部分单独的token统计——如果官方文档里没有给出足够具体的说明，比较稳妥的做法是直接询问平台的技术支持或客服，而不是自己假设一个数字。

4. 容易被低估的场景：批量处理截图、文档扫描件的图片密集型应用

这个折算规则最容易被忽视、也最容易造成实际成本偏差的场景，是那些图片密集型的应用：比如批量识别用户上传的截图、批量解析扫描版PDF或票据、给大量商品图打标签这类需求。这类场景往往有两个特点同时叠加：一是单次调用里图片数量或分辨率可能偏高，二是业务量级本身很大（成百上千张只是起步）。如果开发者只按照"一次调用大概消耗多少token"的印象去估算总成本，却没有意识到图片本身的token消耗会随分辨率、精度模式明显浮动，很容易在业务量放大之后才发现，实际账单远高于当初按文字场景类比估算出来的数字。尤其是需要开启高精度模式来保证识别准确率的场景（比如小字文档、密集表格），这种低估的幅度通常会更明显，因为高精度模式本身对应的token消耗基数就更高。

5. 实际动作：先用少量样本实测账单，再按业务量级推算总成本

比较务实的做法，不是先假设一个换算比例再去套用，而是先做一次小规模的真实测算：从自己实际业务场景里挑几张有代表性的图片（覆盖不同分辨率、不同内容复杂度、如果用到高精度模式也要覆盖到），实际调用一遍要上线的这个模型接口，然后去调用返回的usage字段或者账单明细里，查这几次调用图片部分具体消耗了多少token、花了多少钱。有了这个"单张图片实测成本"的具体数字之后，再乘以预计的图片调用量级，就能得到一个相对靠谱的总成本预估，而不是拍脑袋套一个"图片≈多少字"的假设。如果业务里图片分辨率、内容类型跨度比较大（比如既有手机截图也有高清扫描件），建议分别测算，不要只用一种典型样本代表全部场景，避免测算结果偏差太大。

6. 小结：图片不是"另一种文字"，折算规则必须单独核实

调用DeepSeek、通义千问这类国内大模型的图片理解API时，图片输入会先按某种规则折算成token再计入账单，这个折算通常跟图片的分辨率、尺寸有关，部分厂商还会区分低精度和高精度两种处理模式，对应不同的token消耗——但具体的折算公式、图块划分规则、精度模式的具体名称与取值，不同厂商、不同模型版本可能都不一样，不存在一套统一的行业换算标准，必须以自己实际调用模型对应的官方文档为准。对于批量处理截图、扫描件这类图片密集型应用，上线前先用少量真实样本图片实测一遍账单消耗，再按业务量级推算总成本，会比直接假设"图片和等量文字token消耗一样"要靠谱得多，也能避免业务量放大之后才发现账单远超预期的情况。