默认图 1.5 积分，2K 为何只要约 1 积分

一次默认的 nano_banana_2 请求花了我 1.5 积分，而一次指定 2K 的 nano_banana_2 请求只花了约 1 积分。

更便宜的任务，要求的分辨率反而更高。

如果我只记录请求中选择的模型，以及之后扣掉的积分，这看起来就很反常。缺失的字段是实际执行任务的模型。

默认请求并没有由 nano_banana_2 执行。服务器把它路由给了 nano_banana_flash。2K 请求才真正由 nano_banana_2 执行。

这不是两个等价任务遇到了奇怪的分辨率加价，而是两个请求使用了相同的模型名称，最终却交给了不同模型。

请求模型不等于实际执行模型

记录费用时，我通常会先写下 nano_banana_2 这样的标签。它描述的是我请求了什么。

但不一定描述服务器实际运行了什么。

默认任务的请求没有任何参数。实际执行模型字段显示的是 nano_banana_flash，扣费为 1.5 积分。

2K 任务的请求明确包含 resolution=2k。实际执行模型字段仍是 nano_banana_2，我支付了约 1 积分。

我不能用这两个任务推导通用定价公式。它们只能说明一个更有限的事实：请求中的模型名称相同，并不保证实际执行模型相同；在这两个测量过的任务中，默认请求也不是更便宜的那个。

这已经足以改变我的记录方式。

每个任务至少要分开记录 3 件事：请求了什么、用了什么设置，以及实际由哪个模型执行。扣费应该与这些字段放在一起，而不能只跟着请求模型名称。

如果只写“Nano Banana 2 花了 1.5 积分”，就丢掉了一个事实：那次任务实际执行的并不是 Nano Banana 2。

如果只写“2K 花了约 1 积分”，则丢掉了让这次比较有意义的请求和路由背景。

“默认”也是一种配置

不传参数，看起来像是什么都没选。但我仍然提交了一种明确的请求配置。

无参数请求产生了一种路由和一种扣费。明确指定 2K 的请求产生了另一种路由和另一种扣费。

我不会把这理解为 2K 永远更便宜的证据，而是理解为：不能只凭分辨率推断费用。

观察到的费用对应的是完整任务配置。

比较测试时，这一点很重要。如果一次用默认设置，另一次指定 2K，差异就不一定只有分辨率。实际执行模型也可能不同。

把两个输出都称为“同一个模型”，只是在描述请求字段，却忽略了执行字段。

一张看起来整齐的表格，就是这样保留下了错误结论。两行记录可能有相同的请求标签，却对应不同的路由结果。

解决办法不是写一份语气更笃定的价目表，而是保留更完整的生成日志。

Pro 标签带来了第二个路由问题

nano_banana_pro 测试再次说明了这一点。

我请求了 2K 的 nano_banana_pro，没有设置 quality=high。服务器将任务降级为 nano_banana_2，我支付了约 1 积分。

请求标签里有“pro”，实际执行标签里没有。

所以，我不能把这个任务当成一次已测量的 nano_banana_pro 执行。它证明的是：一个 Pro 请求，因为缺少 quality=high，被路由给了 nano_banana_2。

图片出来后，这个区别很容易被抹掉。输出已经存在，扣费看得见，请求模型又很熟悉。如果不保留实际执行模型字段，我以后就可能误记成“Pro 在 2K 下花约 1 积分”。

但实际发生的不是这样。

我请求了没有高质量设置的 Pro，任务由 Nano Banana 2 执行，花了约 1 积分。

这个区别决定了该任务能否支持附在它身上的价格说法。

其他任务也需要同样记账

其他图片任务进一步说明，完整配置必须保留。

一次带有 Soul ID、9:16 比例和 2K 质量设置的 soul_2 请求，实际由 text2image_soul_v2 执行，花了 0.12 积分。

一次 16:9、2K 的 soul_cinematic 请求，实际由 soul_cinematic 执行，花了约 1 积分。

一次 16:9、预算设置为 50 的 soul_cast 请求，实际由 soul_cast 执行。约 1.5 积分的费用被标为假定值，没有达到同样的实测确定程度。

一次 16:9 的 soul_location 请求，实际由 soul_location 执行。约 0.5 积分的费用是根据余额变化推算的。

这些标记很重要，因为确定程度也是事实的一部分。实测扣费、假定成本和根据余额差推算的费用，不应被当作相同的证据。

我测试的其他图片任务也需要这样谨慎对待。seedream_v4_5 在 1:1、basic 质量下花了 1 积分。flux_kontext 在 1:1 下进行链式编辑，花了约 1 积分。gpt_image_2 在 1K、low 质量下实际由 imagegen_2_0 执行，花了 0.5 积分。一次 1K、low 质量、单张批次的 ms_image 任务花了约 0.5 积分。一次 1K 的 marketing_studio_image 任务也花了约 0.5 积分。

这些是我运行过的配置和观察到的费用，不意味着可以删掉设置，然后在每个请求名称旁边发布一个通用价格。

我现在记录什么

每次图片测试，我都把请求模型与实际执行模型分成两列。分辨率、质量、比例及其他设置也保留在旁边。然后加上观察到的扣费，并标明它是实测、假定还是推算。

这样的结构会保留那个反常结果，而不是把它改写成更符合直觉的说法。

默认 nano_banana_2 请求花了 1.5 积分，因为它实际由 nano_banana_flash 执行。明确指定 2K 的请求花了约 1 积分，实际模型仍是 nano_banana_2。没有 quality=high 的 Pro 请求，最终也落到了 nano_banana_2。

今天就在图片生成费用日志中加一个“实际执行模型”字段。下次两个看似相同的模型请求产生不同扣费时，先比较路由和设置，再判断是不是分辨率的原因。

---

积分花了多少，尝试了多少次，结果如何，都要记录和衡量。我相信数字，因为数字不会奉承任何人，更不会奉承我。