Grok Imagine quality 型号 11 月 2 日退役:迁移怎么做

grok-imagine-image-quality 将于 2026 年 11 月 2 日转向 Image 2.0 low。核对受影响别名、请求配置、回归样本、预算与回退方案。

Grok Imagine quality 型号 11 月 2 日退役:迁移怎么做

grok-imagine-image-quality 计划于 2026 年 11 月 2 日退役。xAI 迁移公告,该名称的请求届时由 grok-imagine-image-2.0 的 low 画质承接,请求和响应结构保持兼容。原始 grok-imagine-image 不在本次影响范围;已经路由到 quality 的旧别名 grok-imagine-image-pro 会一起过渡。

本文核对于 2026 年 9 月 8 日。变更仍在未来,不能用这份公告直接解释今天的报错。开发者现在要做的是找出模型选择位置,决定是否提前显式迁移,并检查新输出能否满足原来的验收标准。

本文讨论 xAI 直连。核对时 Ofox 目录尚未收录 Grok Imagine,Ofox key 不能用于 xAI 直连接口。

先确认是不是受影响的模型名

旧模型名中的 quality 与 Image 2.0 的 quality 参数是两件事。搜索完整 ID,避免把业务画质设置误当成退役模型。

重点检查配置文件、各环境默认值、后台生成与编辑任务、定时任务、数据库保存的模型选择,以及服务商适配层。如果调用第三方,核对它实际路由到哪个上游和切换时间,不能假定所有服务商跟随 xAI 直连同时更新。

把目标模型和画质写明确

保存旧配置,再建立候选配置:

{
  "model": "grok-imagine-image-2.0",
  "quality": "low"
}

这只是配置片段,不是完整请求。仍需保留 prompt、输入处理、鉴权和结果处理,并核对实际接口的字段。

生成参数文档支持 lowmediumauto;自动模式在生成与编辑时选择不同画质。预算或验收依赖某个档位时,显式固定它。若业务需要 medium,就单独建立候选方案,不能把官方的 low 路由安排理解为所有旧任务都适用 low。

用小规模回归样本检查业务要求

样本应覆盖难点,而不只是挑容易出图的提示词。例如可以准备十个 brief:

分组示例数量检查内容
简单背景商品3外形、比例、颜色
包装和可见文字3文案准确性、位置
编辑输入图片2指定修改与细节保留
特殊宽高比2裁切、主体位置

数量是建议方案,不是已发表的 benchmark。比较配置时固定输入素材和书面验收要求,在结果旁记录实际模型与参数。

让审阅者标注可用、需编辑、不可用,并写原因。图片好看但商品标签反复出错,在商品流程里仍然可能不合格;笼统的美观评分会掩盖这种问题。

同时更新任务预算

按新模型配置、输入图片数、请求数重新估算,别沿用旧的 quality_image_price 常量。下载迁移检查表,记录任务 ID、配置、输出数、输入数、验收数、实际费用和备注。

没有真实账单时,把 billed cost 留空;演算值单列为 estimated cost,不要让文档核对看起来像付费实测。适配层修改、人工审图等工程和人力成本也应与生成费用分开记录。

小范围切换,再扩大用量

通过配置开关先让少量业务使用候选设置,在版本控制中保留旧配置和新配置。扩大前分别确认应用能处理响应、素材符合要求、实际费用符合预算假设;其中一项通过不能代替另外两项。

回退方案应指向届时仍可用的模型,而不是一个即将改变路由的旧别名。切换日期前,核对备用模型之后实际指向哪里。更换模型或服务商也应作为新的候选方案重新检查。

跨服务商选择可参考 FLUX 流程视频 API 选择指南,它们不是未经验证即可替换的接口。具体费用见 Image 2.0 价格,完整请求见 Grok 图片 API 入门

常见问题

整个 Grok Imagine 都要关闭吗?
不是。公告针对具体图片模型 ID,不是整个 Imagine 家族。先检查应用实际使用的名称。
需要重写整个应用吗?
先检查模型选择和适配层。公告说明受影响的直连接口保留兼容的请求响应结构,但视觉验收与预算仍需单独验证。
11 月 2 日前的报错就是退役引起的吗?
未来公告本身不能证明这一点。应检查真实错误、接口、账号权限和服务状态。
迁移第一步做什么?
找出所有受影响 ID 的使用位置,保存旧配置,并准备有代表性的小规模样本。