多模态输入控制图片尺寸与输入成本的实现方法

多模态接口的图片输入优化，核心不是把所有图片压到最小，而是让“任务需要的细节”与“发送的像素”匹配。粗分类可以先用低细节；小字识别、细小目标和坐标判断需要保留更多细节。实际工程中建议先在客户端等比缩放，再明确传入 detail，最后用 patch/token 估算单图成本。

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

先把图片任务分成三档

先写清楚模型要回答什么，再决定图片尺寸。只需要判断“有没有车辆”时，不必保留海报上的每个小字；需要读取账单字段或返回图中坐标时，缩放过度会直接损失证据。

用最长边和像素面积统一准备输入

图片文件只有几十 KB，并不代表视觉输入 token 很少；真正影响预处理的是尺寸、detail 和模型规则。下面的函数只做安全缩小：保持比例、限制最长边和总像素，原图另存，不覆盖用户文件。

from pathlib import Path
from PIL import Image

def prepare_image(source: str, target: str, max_side: int = 1600,
                  max_pixels: int = 2_500_000) -> tuple[int, int]:
    # 只缩小过大的图片，避免低分辨率原图被无意义放大。
    with Image.open(source) as image:
        image = image.convert("RGB")
        width, height = image.size
        scale = min(1.0, max_side / max(width, height))
        if width * height * scale * scale > max_pixels:
            scale = min(scale, (max_pixels / (width * height)) ** 0.5)
        new_size = (max(1, int(width * scale)), max(1, int(height * scale)))
        # LANCZOS 保留文字边缘；输出到新文件，保留原图用于回溯。
        image.resize(new_size, Image.Resampling.LANCZOS).save(
            target, format="WEBP", quality=88, method=6
        )
        return new_size

size = prepare_image("invoice-original.jpg", "invoice-input.webp")
print(f"prepared={size[0]}x{size[1]}")  # 只记录尺寸，不输出图片内容或密钥。

这里的 max_side 不是平台统一硬编码值，而是业务策略。票据 OCR 可以提高上限并只裁剪文字区域；缩略图分类则可以更保守。若原图本来就小，函数不会放大它。

把 detail 当成任务参数显式传入

官方图像输入文档说明，detail 控制图像预处理；不同模型支持的级别和尺寸预算并不完全相同。粗粒度理解可试 low，普通高保真理解用 high，需要保留大图空间细节时再考虑 original。不要把 low 简化理解成“永远更省”，具体模型仍要看它的 sizing table 和成本计算器。

import base64
import json

def image_part(path: str, detail: str = "high") -> dict:
    # 发送前读取已准备好的副本；真实项目应从安全配置注入 API 凭据。
    encoded = base64.b64encode(Path(path).read_bytes()).decode("ascii")
    return {
        "type": "input_image",
        "detail": detail,
        "image_url": f"data:image/webp;base64,{encoded}",
    }

request = {
    "model": "gpt-5.6-sol",
    "input": [{
        "role": "user",
        "content": [
            {"type": "input_text", "text": "读取图片中的发票号码，只返回号码。"},
            image_part("invoice-input.webp", detail="high"),
        ],
    }],
}
print(json.dumps(request, ensure_ascii=False)[:240])  # 只检查结构，避免打印完整 base64。

示例只展示请求结构，不在文章中放真实密钥，也不把完整 base64 打到日志。若任务是判断整页布局，图片可以不做激进裁剪；若目标是某个小区域，先裁剪目标区域通常比把整张海报不断放大更可控。

用 patch 和 token 估算输入成本

当前官方说明将图像输入计入可计费 input token，也计入 TPM。对采用 patch 规则的模型，可以先按 32×32 像素覆盖估算：ceil(width / 32) × ceil(height / 32)。之后还要套用模型的像素上限、patch budget 和 multiplier，不能只用图片字节数判断贵不贵。

import math

def patch_count(width: int, height: int, patch: int = 32) -> int:
    # 估算覆盖图像所需的 patch 数；最终账单仍以模型规则为准。
    return math.ceil(width / patch) * math.ceil(height / patch)

width, height = 1280, 960
patches = patch_count(width, height)
print({"size": f"{width}x{height}", "patches": patches})  # 用于比较候选尺寸。

例如 1280×960 的基础覆盖量是 40×30，也就是 1200 个 patch。若把同一张图的宽高都放大一倍，覆盖量大致会变成四倍；但某些模型会先按 detail 的预算缩小，所以最终 token 还要结合官方计算器确认。生产代码可把模型、detail、宽高和图片数量记入指标，在成本回归时比较。

发送前的边界检查与复查

每次请求前至少检查四件事：图片格式是否受支持、单次图片数量是否符合模型限制、总 payload 是否过大、单图经过预处理后是否可能超过 patch 上限。接口文档当前列出 PNG、JPEG、WEBP 和非动画 GIF 等支持格式，并提醒超大 patch 输入可能直接被拒绝。

质量复查不要只看“模型回答了没有”。抽样检查小字是否可读、局部目标是否仍可定位、同一问题在 low/high 下是否出现明显分歧；只有证据不足时才提高尺寸或 detail。对于不需要坐标的任务，先降低图片面积和数量通常比盲目发送原图更容易控制成本。

常见问题

图片压成 WEBP 后，输入 token 一定会下降吗？

不一定。WEBP 主要影响传输体积，输入 token 还受像素尺寸、detail、模型 patch 或 tile 规则影响；应在缩放后按模型规则估算。

什么时候应该从 low 切换到 high？

当整体语义能识别但小字、细小目标或局部关系经常丢失时，再提高 detail，并记录质量和成本变化。

为什么不能所有请求都用 original？

original 更适合大图、密集细节或空间敏感任务，但会带来更高输入量和更严格的尺寸边界；普通场景没有必要承担这部分开销。

把图像输入优化成“任务分档—等比缩放—显式 detail—成本估算—结果抽样”的固定链路，既能减少无效像素，也能让识别质量和调用费用有迹可循。