Nano Banana Pro 生图前就报错

Higgsfield API error (HTTP 500). Internal Server Error

Nano Banana Pro 立即返回了这条信息。没有创建任务，也没有生成图片。

出错的命令使用 nano_banana_2，带有参考图、--aspect_ratio auto 和 --resolution 4k。无论我提供本地路径还是上传 ID，结果都一样。

最直观的怀疑对象是参考文件。但问题不止于此。

两个独立的参数问题，返回了同一条几乎没有帮助的服务器错误。

文档允许用 auto，实际却会报错

模型的参数定义把 auto 列为 aspect_ratio 的可接受值。可传入它，仍然会触发 HTTP 500。

这点很关键，因为列在枚举里的值，通常看起来比手选比例更稳妥。我原以为服务器会检查原图，再决定比例。结果请求在任务创建前就失败了。

第二个问题是 --image 参数。这个参数在该模型上也会导致 500 错误。

Nano Banana Pro 要求通过 input_images 接收参考图。仅仅把上传 ID 放进数组还不够。数组里必须是特定结构的对象：

[
  {
    "id": "<upload-id>",
    "type": "media_input"
  }
]

字符串数组会报 Input should be a valid object。对象里有 ID、没有类型，则会报 Field required。

这些校验信息比最初的 500 更有用。它们表明，服务器需要的并不只是一张已上传的图片，而是结构化的媒体输入。

再试 4K 前，我先缩小了请求

我没有反复提交完整的放大命令，而是先构造了一个 1K 的最小测试请求。

首先，上传原图：

higgsfield upload create <path> --json

这一步返回了 input_images 所需的上传 ID。

接着，检查原图尺寸。我用的是 PIL：

python -c "from PIL import Image; print(Image.open(p).size)"

知道尺寸后，我选了模型支持、且最接近原图的明确比例。这次的两张原图分别对应 2:3 和 4:3。

我没有传入 auto。

然后，把媒体对象放进 JSON 文件，通过下面的参数传入：

--input_images @file.json

测试使用 1K，是为了在正式输出前先验证请求结构。等这个请求成功创建并完成任务后，我才把同样的结构用于 4K 生成。

两次 4K 放大都完成了。这项验证是在 2026 年 6 月 11 日做的。

最小测试为什么有用

原来的放大请求，在同时使用 --image 和 auto 时失败了 3 次。重复这条命令，并不能说明问题出在图片、比例、分辨率，还是请求结构。

这个小测试把变量拆开了。

校验错误明确了所需的对象结构。指定比例则排除了有问题的 auto 值。只有这两处修改在 1K 下都验证有效后，我才回到原定的 4K 输出。

额外成本只有一次 1K 测试。

没有理由再测试 8K。平台上的 Nano Banana Pro 和 Bytedance Image Upscale 最高都只支持 4K。

先确认失败的请求有没有创建任务

即时返回的 HTTP 500 看起来可能已经花了钱，因为它来自 API，而不是本地校验。但这次失败发生在任务创建之前，没有消耗点数。

不过，我仍然会验证，而不是直接假定没扣费。

遇到即时返回的 500 后，我会检查：

higgsfield generate list

如果没有创建任务，就说明请求还没进入生成队列便失败了。这样就能区分格式有误的请求，与已经生成、但后续处理失败的结果。

排查方式也因此不同。任务创建前的 500，需要检查参数，不是带着相同参数再试一次全分辨率生成。

我现在遵守的规则

对于 nano_banana_2，我从不使用 --aspect_ratio auto。我会检查原图尺寸，再选择最接近、且明确受支持的比例。

参考图也通过 input_images 传入，使用对象数组。每个对象都包含上传 ID 和 "type": "media_input"。

在任何付费批量生成之前，我会先发一个最小的 1K 请求。用这个有记录的最小测试，确认媒体结构、比例和任务创建流程。

如果你今天也遇到 Nano Banana Pro 立即返回 500，先检查任务列表。然后替换 auto，停用 --image，用结构正确的 input_images 做一次 1K 测试。

---

文中的每个解决办法，都是我先犯错才换来的。错在我的电影里，总比错在你的品牌上好。