Azure GPT-Image-2 和 OpenAI 直连 gpt-image-2 的核心能力来自同一个 OpenAI 模型家族。它们不是两款需要争夺“画质第一”的模型,真正不同的是谁托管请求、谁管理身份与配额、谁出账单、谁提供支持,以及应用最终要遵守哪套接口合同。
如果项目必须进入 Azure 订阅、使用 Microsoft Entra ID、由微软账单和支持承接,或需要与现有 Azure 网络和监控体系统一,先选 Azure OpenAI。如果项目允许使用 OpenAI 官方 API,且更看重接入简单、官方用量层级和 WebP 直出,先选 OpenAI 直连。
先确定硬性条件,再比较成本和样图。否则很容易拿 OpenAI 的单价解释 Azure 账单,或用一次随机生成结果证明两个平台的模型不同。
先用硬条件排除一条路线
| 必须满足的条件 | Azure OpenAI 更合适 | OpenAI 直连更合适 |
|---|---|---|
| 资源归属 | 工作负载必须归入 Azure 订阅、资源组与组织治理 | 可以由 OpenAI organization/project 独立管理 |
| 身份认证 | 必须使用 Microsoft Entra ID、Azure RBAC 或 Azure 原生密钥体系 | OpenAI project key 和项目权限已经足够 |
| 采购与支持 | 合同、发票、支持与 SLA 需要由微软承接 | 可以接受 OpenAI 的合同、账单与支持归属 |
| 区域与部署 | 必须在已核验的 Azure 区域和部署类型中运行 | OpenAI 项目与可用的数据控制能满足要求 |
| 输出文件 | PNG/JPEG 足够,或已有统一转码链路 | 希望 API 直接返回 PNG、JPEG 或 WebP |
| 运维体系 | 指标、告警、预算和访问控制已经集中在 Azure | 应用已有 OpenAI 请求日志、预算和密钥轮换 |
只要其中一项是不可妥协的要求,路线通常已经确定。若两边都满足,OpenAI 直连可以作为较短的基线;Azure 是否值得增加资源、部署和配额管理,要看这些管理能力能否真正减少企业接入成本。
中国地区读者还需要多做一步:不要从“Azure 支持区域”或“OpenAI 提供数据控制”直接推导本地账号、付款、网络或服务可用性。必须在将要使用的租户、订阅和 OpenAI 项目中分别核验。
同一模型家族,为什么接口仍然不同
微软当前的 Azure 图像生成文档 把 GPT-Image-2 标为正式可用。OpenAI 的 GPT Image 2 模型页 则列出直连模型 ID gpt-image-2,以及当前快照 gpt-image-2-2026-04-21。
这能确认模型身份,却不能证明两个平台会返回逐字节相同的图片。请求还会经过各自的端点、认证、内容安全配置、配额、版本发布、日志和计费系统。生产系统应把这些差异写进架构,而不是把它们当作“换个 base URL”就能忽略的细节。

| 合同表面 | Azure OpenAI / Microsoft Foundry | OpenAI 直连 |
|---|---|---|
| 请求入口 | 自己的 Azure OpenAI 资源端点 | api.openai.com |
| 模型选择 | Azure 中创建的部署名 | gpt-image-2 或官方列出的快照 |
| 认证 | Azure API key,或文档支持的 Microsoft Entra ID 流程 | OpenAI project API key |
| 生成接口 | 当前文档的 Azure /openai/v1/images/generations 路线 | /v1/images/generations |
| 编辑接口 | Azure 资源、部署名和 API version 共同组成路径 | /v1/images/edits |
| 返回方式 | base64 图像数据 | base64 图像数据 |
| 当前文档输出格式 | PNG、JPEG;未列 WebP | PNG、JPEG、WebP,并可设置 JPEG/WebP 压缩 |
| 配额归属 | 订阅、区域、模型、部署类型与具体部署 | OpenAI 项目用量层级与模型限制 |
| 计费与支持 | Azure 订阅、微软账单与支持 | OpenAI organization/project、OpenAI 账单与支持 |
两边仍有大量共同参数。官方文档都支持文本和图像输入、生成和编辑、质量档位、灵活尺寸与 base64 输出。GPT-Image-2 的尺寸条件包括:两条边都是 16 的倍数,长边不超过 3840 像素,长短边比例不超过 3:1,总像素位于 655,360 到 8,294,400 之间。
共同参数也不能盲目复制。OpenAI 直连当前把 auto 列为质量选项,并支持 WebP;Azure 当前列出 low、medium、high,默认值写为 high,输出格式只列 PNG/JPEG。如果交付链要求 WebP,Azure 路线需要显式转码,不能假设同名模型会自动拥有相同格式参数。
两条最小请求不能只改域名
Azure 请求使用资源端点,正文中的 model 是你创建的部署名:
bashcurl "https://YOUR-RESOURCE.openai.azure.com/openai/v1/images/generations?api-version=preview" \ -H "api-key: $AZURE_OPENAI_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "YOUR-GPT-IMAGE-2-DEPLOYMENT", "prompt": "白色台灯,置于中性灰摄影棚背景", "size": "1536x1024", "quality": "medium", "output_format": "png" }'
OpenAI 直连则使用官方主机和模型 ID:
bashcurl "https://api.openai.com/v1/images/generations" \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-image-2", "prompt": "白色台灯,置于中性灰摄影棚背景", "size": "1536x1024", "quality": "medium", "output_format": "webp" }'
真正实施时应重新打开官方文档复制当前路径。Azure 的生成与编辑示例目前并非一条永远不变的 URL:生成文档展示 v1 风格路径与 api-version=preview,编辑文档仍需要部署路径和明确版本。模型正式可用,不代表外围接口已经没有版本差异。
两条路线都应把 b64_json 解码为文件,记录 request ID、实际尺寸、MIME、存储位置和删除规则。仅把 base64 放进日志,不算完成资产交付。
价格要按账单 owner 分开计算
OpenAI 公布了直连价格。截至 2026 年 8 月 5 日,OpenAI 价格页 列出的 GPT-Image-2 标准价为:图像输入、缓存图像输入、图像输出每百万 token 分别 8、2、30 美元;文本输入和缓存文本输入分别为 5、1.25 美元。官方 成本计算器 对 1024×1024 输出给出的示例是:low 0.006 美元、medium 0.053 美元、high 0.211 美元,输入成本另算。
这些数字只属于 OpenAI 直连。Azure 的 Azure OpenAI 价格页 说明 GPT-Image 系列按 token 计价,但实际比较必须使用目标币种、合同、区域、部署类型和账户中的当前价格。不能把 OpenAI 表格复制到 Azure 预算中。
更稳妥的成本口径是:
text单次请求成本 = 文本输入 + 参考图输入 + 生成图输出 每张可交付图片成本 = (全部已计费请求 + 存储/出口 + 必要转码 + 人工修复) / 最终通过业务验收的图片数
Azure 可能因为现有企业合同和统一运维而降低总成本;OpenAI 直连也可能因为少一层部署和转码而更省工程时间。没有账户数据时,两种结论都不能写成通用规律。
Azure 公共配额数字冲突,门户实值才是答案
微软当前两份公开文档对 GPT-Image-2 默认限制给出了不同描述:图像生成指南写的是每个部署 5 images/min,通用 配额与限制页 列的是默认 9 RPM。这不是任选一个数字引用,而是明确提醒:不要用网页默认值设计容量。
在 Azure 中打开目标订阅、区域、模型和部署类型的配额视图,再做与预计并发相符的小规模请求。记录成功数、429、延迟和门户实值。OpenAI 直连也要查看目标项目的当前用量层级和模型限制;模型页上的 Free tier、Tier 1 到 Tier 5 是账户层级合同,不是每个项目都能直接获得同一上限。
用迁移验证表证明路线可运行

迁移前完成以下验证:
- 锁定身份:记录 provider、Azure 资源或 OpenAI 项目、部署名/模型 ID、端点、API version 和区域。
- 锁定输入:两边使用相同 prompt、合法参考图、尺寸、质量和输出数量;无法匹配的参数单独标记。
- 验证返回合同:解码 base64,检查实际尺寸与 MIME,保存 request ID,并写入受控存储。
- 验证硬条件:真实测试 Entra ID、密钥轮换、网络路径、WebP 转码或区域要求,而不是只看控制台截图。
- 验证容量:只跑业务需要的并发,记录限流和重试信息,不用公开默认值代替测试。
- 对账:Azure 请求日志对应 Azure 成本视图;OpenAI request ID 对应 OpenAI usage。失败请求和编辑输入也进入成本分母。
- 准备回滚:新路线未通过身份、存储、审核、延迟、成本和输出检查前,保留旧路线。
如果唯一证据是“这张图看起来不一样”,不要得出平台更换了模型的结论。随机性、别名版本、参数不匹配、内容安全处理和不同请求路径都可能改变输出。画质确实是业务门槛时,应在同等输入和可比设置下做多次测试,并随结果公开路线与参数。
最终选择:让最难的条件决定
需要微软承接采购、支持、Azure 身份和资源治理时,选择 Azure,并把资源、部署、配额、API 版本和格式转换纳入实施范围。允许直连且接入简洁是首要目标时,选择 OpenAI API,同时做好项目隔离、密钥轮换、预算、存储和审核处理。
不要因为两边都写着 gpt-image-2 就迁移。只有当目标路线解决了当前路线无法满足的硬条件,并且迁移验证表证明真实请求可以稳定交付时,迁移才有价值。
需要继续实现 OpenAI 直连,可阅读 GPT-Image-2 API 指南。Azure 路线则应在部署时同时打开微软图像生成、模型区域、配额和实际账户价格页面。
下一步:先写出任何一条路线一旦不满足就会被淘汰的条件,再用准备上线的真实账户、区域和输入跑一次低成本请求。



