图片为什么按 token 计费
视觉模型不能直接按「张数」算钱，因为同一张图的内容量差异极大：一张纯色图和一张密集报表，模型要处理的信息量完全不同。通行做法是把图片按分辨率折算成 token：图片先被缩放、再被切成固定大小的图块，图块数量决定输入 token 数。因此同样的调用次数，图片尺寸不同，账单可能相差数倍，上传前的缩放与裁剪是最直接的优化点。
基本信息
| 计费机制 | 按图块数量折算 token，块数随分辨率上升 |
|---|---|
| 缩放规则 | 先把图片缩到限定尺寸内，再把短边缩到基准长度，最后按固定边长切块 |
| 精度档位 | 低细节档只收少量固定 token，高细节档按图块累加，公式随模型版本变化 |
| 计费参考 | 具体系数与档位以厂商官方计费文档为准，不同模型不同版本不一致 |
| 复用方式 | 同一图片在后续轮次中尽量命中前缀缓存，避免重复计入 |
| 取舍点 | 文字识别与细节判读需要更高分辨率，过度压缩会直接掉识别率 |
典型使用场景
- 客户端直接上传手机原图（数千万像素），token 数是压缩后的好几倍
- 票据、表格截图识别：需要看清小字，分辨率不能一味压低
- 同一张产品图在多轮对话里反复追问，若不走缓存每轮都重新计费
- 批量图片分类打标：只需判断大致内容，用低细节档即可大幅降本
- 服务端统一做图片预处理，用「按需缩放」替代「原图直传」
压缩与裁剪思路
压缩与裁剪思路
from PIL import Image
im = Image.open(path)
im.thumbnail((1024, 1024)) # 长边压到 1K 附近，多数识别任务仍够用
im = im.convert("RGB")
im.save(out, quality=85, optimize=True) # 同时减小文件体积与传输时间
# 裁剪掉与任务无关的区域：界面截图只留关键面板，去空白边框
# OCR 类任务例外：小字需要更高分辨率，压缩前先做识别效果抽测
# 压缩策略要放在服务端统一执行，避免各个客户端各自为政任务与分辨率取舍
| 任务类型 | 分辨率需求 | 说明 |
|---|---|---|
| 场景识别与打标 | 低 | 看整体即可，压缩收益最大 |
| 文档与票据识别 | 高 | 小字漏识别会直接导致答案错误 |
| 图表读数 | 中高 | 坐标轴标签与数字需要可辨认 |
| 界面截图排错 | 中 | 先裁掉无关区域比整体压缩更划算 |
| 多图对比 | 按张数合计 | 总像素而非张数决定成本 |
图片预处理要放在服务端统一执行：把「上传原图」改成「服务端按任务需要缩放」，图片类应用的成本差异通常非常可观，且客户端无需改造。
多轮对话中重复传同一张图时，注意它是否落在前缀缓存覆盖范围内：顺序稳定的前缀更容易命中缓存，图片被夹在变化的文本之后往往享受不到优惠。