多模态成本账：一张图吃掉多少 token，账单被我拆成五项

结算单上最反常识的一行

上个月结算，视觉链路的调用量只有文本链路的 1/23，账单却占了 61%。我原以为是单价不同，把五天的请求日志捞出来重算才发现：同一张扫描件，走两条不同的预处理路径，进上下文的 token 差了 4.6 倍。

这不是模型贵，是我们从来没给图片记过账。文本请求的 token 一眼可见，图片的 token 要按像素切块算，没人算，就没人管。

第一笔：一张图到底占多少上下文

视觉编码器按固定像素块切图，所以图片成本正比于面积，和文件大小几乎无关。我这边按 32×32 像素一块的口径算：

• 1024×1024 的截图：32×32 合计 1024 个视觉 token，约等于读一篇八百字的中文。
• A4 扫描件按 200dpi：1654×2339，切出 52×73，合 3796 个 token。一次带三张的请求，光图片就 11388 token，占掉整个上下文的 78%，提示词和用户问题被挤在角落。
• 长边压到 1280：905×1280 变成 28×40，1120 个 token，只剩原来的三成。
• 单块裁剪 512×512：256 个 token。需要精读时只裁字段所在那一块，比整图放大便宜得多。
• 4MB 和 800KB 是同一个价：一张 3000×2000 的 JPEG 压成 800KB 的 PNG，token 完全一样，成本只跟像素有关、跟字节无关。所以「先把图压小」这句话，压文件大小没用，要压的是分辨率。

按我们采购口径 8 元/百万 token 折算：原图路径单张 0.030 元，一天 3000 张就是 91 元，一个月 2700 元；压到长边 1280 后单张 0.009 元，一天 27 元。同一个功能，账单差 3.4 倍，识别准确率只掉了 0.6 个百分点。

第二笔到第五笔：日志里翻出来的隐性成本

图片的钱不只花在 token 上。把网关日志和工单系统对了一遍，还有四笔一直在付：

• 重试放大：图片超尺寸、格式不支持时返回 400，客户端默认重试两次，实际请求量是业务量的 1.31 倍。这 31% 全打在账单上，却不产生任何结果。
• base64 让请求体膨胀：一张 1.2MB 扫描件编码后约 1.6MB，一天 3000 张就是 4.8GB 出网流量，日志留存还要再存一份。
• 重复的图片规范提示词：每次请求都带 800 token 的字段说明与格式约定，图片越多，这部分被付费的次数越多，而它完全可以裁到 300 token 以内。
• 人工返工：字段识别错的单子进人工复核，平均 12 分钟一张。按 30 元/小时算，一张返工 6 元，等于 750 张图的 token 钱。

这四笔加起来，占视觉链路总成本的 34%，比任何一次换模型省下来的都多。

把单张成本压掉七成的五条手段

账单是算出来的，也只能靠算压下去。五条我都上过线，附实测数：

• 两阶段识别：先用长边 768 的缩略图判版式（约 816 token），只对需要精读的 18% 局部做 512×512 裁剪。单张均摊从 3796 降到 1040 token。
• 图片指纹缓存：按 sha256 加预处理参数做键，命中率 41%。合同、发票、证件这类重复提交的场景能到 63%，命中直接返回上次结果，一次调用都不发。
• OCR 前置分流：先用轻量 OCR 抽文本，置信度高且版式简单的直接走文本链路，只把 12% 的复杂件送多模态。这一步把视觉链路请求量砍掉七成，准确率基本无感。
• 输出收紧：要求模型只输出固定字段的短 JSON，禁止自由描述。输出 token 从 380 降到 62，单次成本里那部分固定开销直接消失。
• 把图片从历史里摘出去：多轮会话里同一张图会跟着上下文反复重算，一个 8 轮的对话若全程未命中缓存，等于同一张图付了 8 次钱。改成首轮抽成结构化字段、后续轮只带字段，单会话的图片成本回到一次。

五条叠起来，单张均摊从 3796 降到 1040 token，日成本 91 元压到 25 元，降幅 72%。代价是有的：把金额类字段也塞进缩略图路径后，返工率从 0.4% 涨到 1.1%。所以第三条最终改成分档——版式判断走缩略图，金额、日期、证件号一律回原始分辨率。

有三处钱不该省

压账单最容易做过头。这三处我都试过，省下来的是 token，赔进去的是别的东西：

• 关键字段的分辨率：一次识别错花 12 分钟返工，折 6 元，等于 750 张图的 token 成本。金额、日期、身份证号这类字段，原图进，不犹豫。
• 上下文里的图片数量：为省 token 把多页合同的图截到前三张，模型漏看第四页的补充条款，最后是法务退回重来。这种错误不进返工统计，代价却最高。
• 审核环节的二次调用：抽检那次调用看着像重复花钱，省掉它之后一次错误输出的合规成本，够付半年 token。

小结

多模态的成本不是单价问题，是预处理、重试、缓存、输出四件事叠出来的结果。先把账本建起来——每次请求记下图片数、像素总量、视觉 token、是否命中缓存——再谈压缩；没有账本的优化，只是猜哪一环贵。

顺序建议：记 token 账、压图片尺寸、上缓存与分流、最后收输出格式。反过来做，通常只是把贵的那部分藏进了别的地方。

还有一条：账要按业务维度分开记。同样是这个模型，支撑合同审阅和支撑商品图打标，单张有效成本差三倍以上，混在一个总账里看，永远看不出该动哪一环。