首页使用帮助OpenAI Vision API
HELP / OPENAI VISION API

OpenAI Vision API 怎么用?

OpenAI 的 Vision 不是一个单独端点:用支持图像输入的模型,通过 Responses API 或 Chat Completions 发送图片,模型返回文字或结构化结果。图片可用公开 URL、Base64 data URL 或 Files API 的 file_id 提供;生产环境还要正确选择 detail、控制图像 Token,并对 OCR、计数和坐标结果做评测与复核。

主关键词:OpenAI Vision API 怎么用图片理解input_imagedetail更新:2026-10-31
先给结论

问图、OCR、分类或抽取 → Responses API 图像输入;兼容已有消息接口 → Chat Completions;生成或编辑图片 → Images API。新项目优先评估 Responses API,把图片和问题放在同一条用户消息里。先用 detail:auto 建基线,再针对小字、细小目标或坐标任务测试 original;不要把模型描述当成确定事实。

官方资料(2026-10-31 核对):Images and vision · Responses API Reference · Image input cost calculator · Models

Vision、Images API 与文件输入先分清

真实需求推荐入口输入输出
描述图片、分类、OCR、问图Responses APIinput_text + input_image文字或结构化数据
已有 Chat Completions 消息集成Chat Completionstext + image_url文字
生成或编辑图片Images API 或 Responses image_generation提示词与可选参考图新图片
PDF 页面、文档或表格Responses input_file文件 URL、Base64 或 file_id基于文件内容的结果

本页只负责“输入图片、输出理解结果”。生成与编辑图片请看 OpenAI Images API 指南;文件生命周期和 purpose 请看 Files API 指南。把两类工作流拆开,才能分别追踪输入 Token、生成费用、准确率和失败原因。

最小可用示例:Responses API 分析一张图片

下面示例沿用官方当前 Vision 示例中的模型。生产环境应从当前 Models 页面选择支持图像输入且符合质量、延迟与成本要求的模型,不要把示例模型永久写死。

import OpenAI from "openai";

const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY
});

const response = await openai.responses.create({
  model: "gpt-6-astra",
  input: [{
    role: "user",
    content: [
      { type: "input_text", text: "列出图片里的主要物体,并说明不确定之处。" },
      {
        type: "input_image",
        image_url: "https://example.com/product.jpg",
        detail: "auto"
      }
    ]
  }]
});

console.log(response.output_text);

API Key 只能保存在服务端。若输出会进入订单、风控、审核或其他不可逆流程,应要求模型给出“不确定/无法判断”,并在业务层设置人工复核,而不是只依赖自然语言回答。

三种图片输入方式怎么选?

方式适合场景关键风险
公开 HTTPS URL临时、可公开访问的图片URL 失效、重定向、访问权限和外部内容变化
Base64 data URL小图、一次性请求、不希望另建公开 URL请求体膨胀、日志泄露和代理大小限制
Files API file_id重复使用、受控上传、需要生命周期管理purpose、权限、保留与删除策略
import fs from "node:fs";

// 先上传,再使用 file_id
const uploaded = await openai.files.create({
  file: fs.createReadStream("inspection.jpg"),
  purpose: "vision"
});

const result = await openai.responses.create({
  model: "gpt-6-astra",
  input: [{
    role: "user",
    content: [
      { type: "input_text", text: "读取标签文字;看不清的字段返回 null。" },
      { type: "input_image", file_id: uploaded.id, detail: "original" }
    ]
  }]
});

不要把 Base64、签名 URL 或用户图片写入普通请求日志。对外部 URL 设置允许协议、重定向次数、超时和内容类型校验;对上传文件验证真实格式、解码尺寸和资源消耗。

detail:auto、low、high、original 怎么选?

detail优先场景成本与质量边界
auto默认起点与常规问图由模型规则选择预处理;默认值不等于最低成本
low粗粒度分类、场景判断、缩略图通常更省输入 Token,但小字和细节可能丢失
high需要更多局部细节的通用任务模型会按自己的尺寸与 patch/tile 规则处理
original小字 OCR、细小目标、坐标敏感任务仅部分模型支持;输入成本可能更高,图片仍可能被缩放

官方当前说明,detail 支持值取决于模型,省略时 Responses 与 Chat Completions 都默认 auto。对于 OCR、小物体和坐标任务,在模型支持时可评测 original;但 original 仍受像素和 patch 预算影响,也不会让模型自动变成精确 OCR 或检测器。

格式、载荷、数量与 patch 限制

  • 支持格式:PNG、JPEG、WEBP 和非动画 GIF。
  • 请求载荷:官方当前通用上限为每次请求总计 512 MB。
  • 图片数量:每次请求最多 1,500 张图片。
  • patch:patch-based 输入在选定模型和 detail 预处理后,每张图最多 30,000 个 patch;超出会拒绝,而不是自动缩到上限内。
  • 上下文仍有限:图片 Token、文字提示和输出必须共同放入模型上下文,模型或 detail 的更低限制可能先触发。
理论上限不是推荐批量

不要设计“每次固定塞 1,500 张图”的流程。先按业务建立 1、4、16、32 张等批量基线,观察上下文占用、延迟、失败率和答案质量;需要大规模离线分析时应分批、建立作业状态和幂等键。

图像 Token 与成本怎么估算?

Vision 图片会被转换为输入 Token;图片尺寸、detail、模型的 patch/tile 规则决定图像 Token,文字提示与模型输出另外计费。图片 Token 也会计入 TPM 限额。官方提供 Image input cost calculator,可按模型、尺寸与 detail 估算一张图片的标准输入成本。

  • 记录模型、原始宽高、detail、图片数量、文字 Token、输出 Token 和实际 usage。
  • 用“单位可用结果成本”评估:总费用 ÷ 通过人工或规则校验的结果数。
  • 先裁剪无关边缘、修正旋转、放大小字区域,再决定是否使用 original。
  • 不要把 GPT Image 生成/编辑价格套到 Vision 图片输入;两者是不同计费流程。

项目用量和预算告警见 API Usage 指南;当前模型价格应以官方 Models/Pricing 与成本计算器为准。

结构化抽取:让“无法判断”成为合法结果

产品目录、票据、包装或截图抽取最好使用 Structured Outputs,把字段、枚举、null 和置信说明写入 Schema。Schema 只能约束输出形状,不能保证图片事实正确;图片模糊、遮挡或文本太小时仍应返回空值并触发复核。

const response = await openai.responses.create({
  model: "gpt-6-astra",
  input: [{
    role: "user",
    content: [
      { type: "input_text", text: "提取商品名和批次号;看不清就返回 null。" },
      { type: "input_image", file_id: uploaded.id, detail: "original" }
    ]
  }],
  text: {
    format: {
      type: "json_schema",
      name: "label_fields",
      strict: true,
      schema: {
        type: "object",
        properties: {
          product_name: { type: ["string", "null"] },
          lot_number: { type: ["string", "null"] },
          uncertainty: { type: "string" }
        },
        required: ["product_name", "lot_number", "uncertainty"],
        additionalProperties: false
      }
    }
  }
});

更多 Schema 与 JSON mode 边界见 Structured Outputs 指南。

常见失败与排查顺序

现象先查什么修正动作
图片无法读取URL 权限、重定向、格式、MIME、Base64 前缀、file_id purpose服务端先下载/解码验证,记录非敏感错误元数据
小字漏读或错读分辨率、旋转、裁剪、detail、压缩裁剪放大、纠偏,在支持时评测 original,并保留 OCR 复核
多图对应关系混乱图片顺序、问题是否逐图编号、上下文长度给每张图稳定编号,要求按编号输出,必要时拆批
成本或延迟突增图片尺寸、detail、数量、重试和输出长度限制输入、缓存业务侧结果、按错误类型重试
答案看似合理但事实错误是否允许“不确定”、是否有验证集结构化 null、规则交叉校验、人工复核和失败样本回归

Vision 的能力边界与安全

  • 模型可能误读小字、旋转/倒置内容、非拉丁文字、图表线型、全景图和鱼眼图。
  • 精确空间定位、棋盘位置、坐标和物体计数可能不可靠;计数往往只是近似。
  • 不适合解读 CT 等专业医学影像,也不能用于医疗建议。
  • 模型不读取原始文件名或元数据,且图片在分析前可能被缩放。
  • 系统会阻止 CAPTCHA 提交;不要把 Vision 用于绕过访问控制或安全机制。
  • 对人物照片、证件、未成年人、敏感场景和第三方图片建立最小化采集、访问控制、保留与删除策略。

如果输入或输出可能包含违规内容,可根据业务风险结合 Moderation API 和人工审核;高风险决策必须使用独立验证数据和适用的专业流程。

评测:按任务拆分而不是只看“看懂了吗”

任务样本指标
分类/描述清晰、模糊、遮挡、长尾类别准确率、拒答率、严重幻觉率
OCR/字段抽取小字、旋转、反光、多语言字符/字段准确率、null 正确率
多图比较顺序变化、相似图、缺失图图片归属正确率、遗漏率
空间/计数密集目标、坐标、边缘目标计数误差、定位误差、人工复核率
生产性能不同 detail、尺寸、图片数和模型P50/P95 延迟、失败率、单位可用结果成本

固定图片集、问题模板、期望答案和评分规则;每次模型、detail、裁剪或提示词变化都用同一版本回归。日志只保存必要的请求 ID、模型、参数、耗时、usage 和脱敏标签,不保存敏感原图。

上线前检查清单

  1. 已经区分 Vision 图片理解与 Images API 生成/编辑。
  2. 模型当前支持图片输入;示例模型没有被当成永久默认。
  3. URL、Base64 与 file_id 的选择、权限、保留和删除策略明确。
  4. 格式、真实 MIME、解码尺寸、总载荷、图片数量和上下文限制都有前置校验。
  5. auto/low/high/original 用真实样本比较过质量、延迟和成本。
  6. OCR、计数、坐标、医学和其他高风险结果有专门工具或人工复核。
  7. 多图已编号,输出允许 null/不确定,失败重试不会重复执行不可逆动作。
  8. 图片 Token、文字 Token、输出、TPM 和单位可用结果成本都有监控。

常见问题

Vision API 是一个单独的 OpenAI 端点吗?

不是单独的产品端点。通常使用支持图像输入的模型,通过 Responses API 或 Chat Completions API 发送图片并获得文字或结构化结果。Images API 主要用于生成或编辑图片。

图片可以用哪些方式传给模型?

可以提供公开图片 URL、Base64 data URL,或先通过 Files API 上传并使用 file_id。重复使用或需要受控生命周期时更适合 file_id;临时小图可使用 URL 或 Base64。

detail 应该选 low、high、original 还是 auto?

默认 auto 会按模型规则选择预处理方式。大范围分类和粗略描述先评测 low;小字 OCR、细小物体或坐标敏感任务在模型支持时评测 original。high 与 original 通常会使用更多图像 Token,且 original 仍可能被缩放。

一次请求最多可以传多少张图片?

官方当前通用要求允许每个请求最多 1,500 张图片、总载荷最高 512 MB,且每张图片处理后最多 30,000 个 patch;但模型上下文、detail、尺寸和 Token 限制仍可能更早触发,生产请求不应直接按理论上限设计。

Vision 可以准确完成 OCR、计数和坐标定位吗?

不能保证。官方明确提醒小字、旋转文字、图表、精确空间定位和物体计数可能出错。可以放大或裁剪目标区域、在支持时使用 original,并用专门 OCR、检测工具或人工复核关键结果。

多张图片输入会怎样计费?

每张图片都会转换为输入 Token并计入模型用量,文字提示和输出也会计费。成本取决于模型、图片尺寸、detail 和处理后的 patch 或 tile;应使用官方图片输入成本计算器并记录实际 usage。

Vision 和 Images API 有什么区别?

Vision 是输入图片、输出描述、分类、OCR 或结构化结果;Images API 是生成或编辑图片。需要问图用 Responses 或 Chat Completions 的图像输入,需要出图则使用 Images API 或 Responses 的 image_generation 工具。

本文核对日期为 2026-10-31。模型、detail 行为、图片限制、Token 计算与价格会调整;生产上线前请重新读取官方 Images and vision、Models 与 Image input cost calculator。

先建立小规模真实图片基线

从 30–100 张包含清晰、小字、旋转、遮挡和失败样本的图片开始,对 detail 与模型做可复现评测,再决定批量、成本和人工复核方案。