多模态请求图片细节等级如何影响成本

多模态请求里的图片细节等级，影响的不是“图片文件变大了多少”，而是模型预处理图片时消耗多少视觉输入 token，以及它能不能看清小字、小目标和空间位置。实际选型可以先记住一句话：批量分类、粗筛优先考虑 low；普通图片理解用 high 或模型默认的 auto；OCR、坐标和密集小目标在模型支持时考虑 original。最终成本还要把文字输入、输出和调用次数一起算。

官方地址：https://developers.openai.com/api/docs/guides/images-vision

先把 low、high、original 和 auto 分工

low 适合只要大致语义的任务，例如判断“有没有表格”、给图片粗分类，或在大量图片里先做初筛。它通常能减少视觉输入开销，但并不保证任何模型、任何尺寸下都比其他等级更省。

high 是普通高保真理解的常用选择，适合读结构清楚的截图、商品属性或页面模块。original 面向大图、密集内容和对空间位置敏感的任务，但只有支持它的模型才能使用。auto 交给模型采用默认缩放行为，适合作为基线，不适合在成本敏感的批处理里完全不记录配置。

请求里怎么设置图片细节等级

在 Responses API 中，把图片作为 input_image 放进用户消息，并在同一个对象上设置 detail。下面是可迁移的最小结构；图片地址是占位符，示例没有声称已经执行。

const response = await client.responses.create({
  model: "你的视觉模型",
  input: [{
    role: "user",
    content: [
      { type: "input_text", text: "判断图中是否有可读的小字" },
      {
        type: "input_image",
        image_url: "https://example.com/sample.png",
        // OCR 或小字任务才提高视觉细节；粗分类可改为 low
        detail: "high"
      }
    ]
  }]
});

如果改用 low、high、original 做对照，应该固定模型、提示词、图片样本和输出长度，只改变一个变量。这样得到的 token 与质量差异才有比较意义。

成本要拆成三部分计算

不要只看图片文件大小，也不要把一次 API 账单全部归因于 detail。一条多模态请求至少包含图片输入 token、文字输入 token 和输出 token；同一张图重复发送时，还要乘以调用次数。官方图片输入成本计算器会按照模型、图片尺寸和细节等级估算视觉输入，实际单价则以对应模型价格页为准。

可以把预算表写成：总成本 = 图片输入 token × 输入单价 + 文字输入 token × 输入单价 + 输出 token × 输出单价。若接口返回 usage，还要记录输入 token、缓存输入 token（如果该接口提供）和输出 token，不能拿估算值替代实际用量。

高分辨率图片也不一定自动等于高成本或高收益。不同模型可能采用固定 token、tile 或 patch 预算，low 也不保证永远比 high 少。因此上线前应抽取一小批“难图”而不是只用清晰样本。

不要把省 token 等同于更划算

我的做法是先用 auto 建基线，再用 low 和 high 做同样本对照。记录四列：图片输入 token、总延迟、正确率或漏读率、失败后的重试次数。对于 OCR、小目标和坐标任务，宁可把 original 的成本单列，也不要用低精度结果冒充可靠答案。

当一次漏读会触发人工复核或再次调用时，表面上便宜的 low 可能反而更贵。批量初筛可以低成本分流，进入精查队列的少量图片再升级，这种分层策略通常比所有图片统一使用 high 更容易控制预算。

相关问题

detail 会改变输出 token 吗？

它直接控制图片输入的预处理和视觉输入 token；输出 token 还受提示词、模型和输出上限影响，应在 usage 中分开观察。

auto 是不是最省钱的设置？

不能这样推断。auto 使用模型默认行为，成本和效果要结合具体模型、图片尺寸与任务样本测量。

图片压缩后就一定更便宜吗？

不一定。压缩可能改变文字和小目标可读性，最终仍由模型的缩放与 token 规则决定；先用难图测试。

什么时候应该固定 high？

当任务需要稳定读取页面结构、较小文字或多个局部细节，并且漏判代价高于额外输入成本时，固定 high 比依赖 auto 更容易复盘。