图像编辑实测账单：默认质量也可能更贵

一次 AI 修图到底花多少钱，不能只看平台标出的单张估价。作者运营的 YepShot 同时接入 Nano Banana 2.1、GPT Image 2.5 和 2.6，他用相同照片跑编辑请求，再读取账单，发现 GPT Image 2.6 的 medium 档涨价明显，画幅和参考图也会改变成本。

这篇最有用的，是把定价问题拆到了具体请求：输入照片、蒙版、输出尺寸，究竟分别怎么影响账单。但它仍是一个小型产品的实测，部分表格在所提供原文中缺失，不能当成完整价目表。

medium 涨价，为什么会影响产品积分

作者称 GPT Image 2.6 于 11 月 4 日推出，测试发生在 11 月 5 日和 6 日。他使用 fal.ai 的 Flare 端点 openai/gpt-image-2.6/flare/edit，输入一张 4:3 照片，输出也保持 4:3。统计的是完整请求费用，包含输入照片、提示词和可能产生的推理 token。

作者给出的 GPT Image 2.5 三档费用是 $0.019、$0.029、$0.042，并称 2.6 的 medium 在相同设置下达到原来的两到三倍，high、max 则没有变化。所提供原文缺少对应表格，无法逐行核对；后文明确给出，2.6 medium 的 1K 编辑约 $0.041，2K 约 $0.075。

fal 对 2.6 按 token 计费：图像输出每百万 token $30，图像输入每百万 token $8。每增加一张输入图，包括作为图片上传的蒙版，约增加 $0.0085，作者观察到这一增量不随质量档变化。

用户点一次「编辑」，背后可能已经多付了一张蒙版的输入费用。

作者的定价规则是：按最便宜的批量积分单价计算，用户消耗的积分至少覆盖实测成本的两倍。因此，1K 编辑从 GPT Image 2.5 的 3 积分，调整到 2.6 的 6 积分。这是他们产品的商业选择，并非所有团队都适用的利润标准。

像素更多，为什么反而可能更便宜

fal 的尺寸估价有个反直觉之处：medium 下，1024 × 1024 的图像输出费用是 $0.043，1024 × 1536 却是 $0.034。这里比较的是图像输出部分，不能直接与前面的完整请求费用混用。

因此，只按像素面积估算预算会出错。不要求正方形的场景，可以先比较不同画幅的报价。

动画也需要单独测。2.6 的编辑端点支持 output_format: "gif"，作者用一张照片生成 576 × 432、9 帧的 GIF。他表示三个质量档肉眼看不出区别，但所提供原文没有保留对应费用表。

GIF 只有 256 色。作者将帧尺寸提高到 768 × 576 后，费用达到 $0.073，文件为 2.5 MB，观感却没有更好；把 reasoning_effort 设为 low 也没改变价格。最后他选择 medium，每帧约 512 × 512 像素，默认 9 帧、每帧 200 ms，用于一个小幅动作。

跨模型比较同样要对齐条件。作者按 10 月 9 日的官方价格，将 Gemini API 返回的 usageMetadata 换算为费用，4:3 输入下的 Nano Banana 2.1 数据为：

• 1K 约 $0.044，耗时约 25 秒。
• 2K 约 $0.057，耗时约 29 秒。
• 4K 约 $0.121，耗时约 44 秒。

它每增加一张参考图，约增加 1,120 个输入 token，即 $0.0017。按这组数据，1K 时两者价格接近；2K 时 Nano Banana 更便宜，额外参考图的成本约为 GPT Image 2.6 的五分之一。但原文没有提供足够的质量对照结论，无法据此选出综合赢家。

上线前，蒙版和尺寸比调用成功更重要

作者最初接入 GPT Image 2.5 时，把涂抹区域传给 fal 的 mask_url，结果修改颜色、纹理时，整件衣服或整张脸也被重画。

他的解决方式是把蒙版作为额外输入图，再在提示词末尾说明：最后一张是蒙版，只修改白色区域。作者在 2.6 上沿用了这个办法，没有重新测试 mask_url。因此，这能说明一种有效的接入经验，不能证明 2.6 的 mask_url 仍有相同问题。

输出内容也有意外。作者在 Flare 跑了 48 条编辑提示词，其中 3 个结果生成了原图没有的真实品牌名；另外在 Sunburst 测试的 10 条中，有 1 个音箱出现真实品牌。商品图尤其需要检查书脊、耳机和包装等配角位置。这些样本不足以推算稳定的发生概率。

尺寸约束则可以直接写进参数校验：宽高都必须是 16 的倍数，最长边不超过 3840，宽高比不超过 3:1，总像素不超过 3840 × 2160。作者先根据目标像素数和照片比例计算宽高，再向下取整到 16 的倍数，避免超限。

我的判断

我认同作者先测账单再定价的做法。完整请求成本比「一张图多少钱」更接近产品实际支出，尤其是支持蒙版、多参考图和不同画幅的编辑器。

但这份实测没有交代足够的重复次数、价格波动、失败重试和结果可用率，也没有给出质量档之间的系统对照。GIF 升档无收益、蒙版改传图片更有效，都应视为特定任务下的经验。更便宜的模型如果需要多次重试，最终未必省钱，而原文没有完成这层比较。

作者同时是 YepShot 的开发者。公开提示词和结果有助于复核，但这仍不是独立评测。

能拿来做什么

• 给现有图片编辑接口记录模型、画幅、质量档、输入图数量和实际费用；Gemini 可以同时保存 usageMetadata，方便核对成本变化。
• 在 Node 服务端统一校验尺寸，并按原图比例计算后向下取整到 16 的倍数，避免把不合法参数送到模型端点。
• 为局部编辑准备同一组照片和蒙版，对照测试 mask_url 与额外输入图两种方式，再决定接入方案，并把蒙版成本计入报价。
• 商品图交付前检查新增文字和品牌标识；制定积分价格时，用自己的完整请求账单验证覆盖范围。