图片 API 的 1K、2K、4K 怎么选？比例、请求档位与真实像素指南

图片 API 里最容易被混用的四个概念是：1K、2K、4K，宽高比，请求参数，以及最终文件的真实宽高。

它们看起来都在描述“图片有多大”，实际回答的是不同问题。只有把这四层拆开，才能避免横图被拉成竖图、为了并不存在的清晰度多付成本，或者拿到图片后才发现像素不符合交付要求。

先把四个概念分开

分辨率档位

1K、2K、4K 是模型或平台提供的分辨率档位，表达的是生成规模，而不是跨模型统一的固定宽高。

同样是 1K，正方形、横图和竖图可以有不同像素；同样是 4K，不同供应商也可能采用不同的像素预算和取整方式。因此不能看到“4K”就自行推导成某一组固定尺寸。

宽高比

宽高比只描述画布形状。1:1 是正方形，16:9 是横向宽屏，9:16 是竖向内容。

比例不会单独决定像素。16:9 可以是较小的预览图，也可以是高分辨率终稿。

API 请求值

API 通常只接受离散值，例如某个 size、image_size 或 aspect_ratio 枚举。它不是任意宽度和高度输入框。

请求值必须来自当前模型目录。即使上游模型支持某个比例，聚合平台也可能只开放已经验证、可以计价和可以稳定路由的子集。

真实输出像素

真实像素是生成文件最终解码得到的 width × height。它是验收交付物时最应该记录的数据。

某些渠道把档位作为目标，输出可能接近而不是严格等于某组尺寸；另一些渠道接受精确的像素预设。页面上的“约 1K”和“精确像素”不是同一个承诺。

为什么 K 不是固定的长边

Google 的Gemini 图片生成指南就是一个直观例子。在 Gemini 3.1 Flash Image 当前官方表格中：

• 1:1 的 1K 是 1024 × 1024；
• 16:9 的 1K 是 1376 × 768；
• 16:9 的 2K 是 2752 × 1536；
• 16:9 的 4K 是 5504 × 3072。

这说明 K 档位和宽高比共同决定实际尺寸，不能只按最长边命名。以上数字只是 Google 当前官方模型的示例，不是所有 OGA 模型或渠道的通用尺寸表。

先选比例，再选档位

最稳妥的顺序不是先点 4K，而是先确定图片最终出现在哪里。

比例确定后，再根据用途选择分辨率档位。

1K、2K、4K 的实际选择

1K：验证想法和批量迭代

1K 适合构图测试、提示词迭代、缩略图、低成本预览和大量候选方案。多数设计决策在这个阶段就能看清，没有必要让每次失败尝试都使用最高档位。

2K：多数数字内容的平衡点

2K 通常适合网站头图、营销物料、商品详情和需要二次裁切的数字内容。它给后期调整留下空间，同时避免 4K 带来的额外成本和等待时间。

4K：已经确认构图的终稿

4K 更适合大画布、高密度屏幕、需要局部裁切或后续排版的终稿。高档位不会自动修复错误文字、错误手指或不合理构图。先用较低档位确认内容，再生成 4K，通常比反复重跑 4K 更稳。

一个可靠的请求流程

1. 从模型与价格页面确认当前模型支持的操作、比例、档位和请求尺寸。
2. 根据最终版位选择宽高比，而不是根据“哪种图看起来更大”选择。
3. 用 1K 或当前最低可用档位验证构图、主体、文字和参考图一致性。
4. 确认内容后再切换到 2K 或 4K。
5. 任务完成后读取实际文件宽高，并和任务记录、价格快照一起保存。
6. 如果接口返回不支持的尺寸错误，重新查询模型目录，不要靠循环试值猜参数。

不要把上游能力当成当前线路能力

Google 官方文档说明 Gemini 3.1 Flash Image 支持 0.5K、1K、2K 和 4K，而 Gemini 3.1 Flash Lite Image 当前只支持 1K。这个差异已经说明：同属一个产品系列，也不能共享一张尺寸表。

OGA 的公共页面只展示当前公开合同中的能力。文章不会复制实时价格或渠道状态；调用前应以 GET /api/v1/models/{model_id} 返回的 size、档位、比例、尺寸语义和可用性为准。

最终判断标准很简单：比例决定形状，档位决定生成规模，请求值来自当前合同，真实像素用于验收。把这四层分开，图片 API 才能成为可预测的生产工具。