Ignis · 生成计费

生成前、生成中、生成后，用的不是同一个 Key

代码确认：Ignis 的预估积分和实际扣费都会查积分配置表，但入口不同。任务提交还会再解析一层 Provider Key。下面按真实代码把每一段放到同一张图里。

代码核对Nano Pro 示例2026-07-15

01 · 完整过程

从积分配置到流水显示，一共经过 8 个节点

墨蓝色节点是 Ignis 真正做映射或计算的地方。虚线表示“读取配置”，实线表示一次任务的先后过程。

IGNIS 前端 IGNIS 服务端 / 数据库 统一生成 / 技术计费 getPricingSnapshot modelKey + generationLine + 参数 models:[providerKey] modelKey + costAmount /api/points/usage key / aliases + 积分换算比例 points + extra ① IGNIS 积分配置 points_pricing_items key / aliasescost_per_unit / points_per_unitmax_usage_unitsdisplay_name / usage_category ② 前端预估 查 pricingLookupKey maxUsageUnits × pointsPerUnit× batchSize → 按钮积分 ③ 用户提交 产品参数 modelKey / generationLine清晰度 / 时长 / 数量等 ④ IGNIS 任务服务 解析实际 providerKey generationLine + t2i / edit任务：model_key执行项：provider_key请求头 metadata.pricing_key仅作为下游计费元数据 ⑤ 技术计费配置 按 Provider 模型算成本 _model_ids → config_idbase_price + 参数倍率model_identifierfallback 可能换实际服务 ⑥ 成本回调 告诉 Ignis 实际花了多少 modelKey / costAmountorderNo / usageUnits?metadata.pricing_key 等当前没有 providerKey 字段 ⑦ IGNIS 实扣 只拿回调 modelKey 匹配 modelKey → key / aliasesceil(costAmount ÷ costPerUnit× pointsPerUnit)不使用 metadata.pricing_key 匹配未命中则 costAmount × 10 ⑧ 积分流水 展示积分、功能、模型名 points / usage_categorypricing_name；不展示线路 LEGEND Ignis 映射 / 计算 Ignis 配置 外部生成 / 计费 读取配置

最容易混淆的是两个同名字段：请求头的 metadata.pricing_key 来自线路预估映射；流水里的 extra.pricing_key 则是 Ignis 最终命中的积分配置 key。当前代码没有用前者决定实扣。

02 · Key 字典

每一种 Key 各管一件事

它们不需要强行改成同一个名字，但必须有稳定的对应关系和统一维护入口。

名称从哪里来现在用在哪里是否决定实际服务
产品 modelKey模型目录、前端提交页面选中模型、主任务 model_key、表单还原否，还要再解析
generationLine用户选择标准/稳定线路参与预估 Key 和 Provider Key 映射间接决定
pricingLookupKeyIgnis 模型目录代码生成前查询 Ignis 积分配置；也放进请求头元数据否
providerKeyIgnis 服务端按模型、线路和任务类型解析下游请求 models[]；任务执行项 provider_key是
回调 modelKey统一计费服务回调匹配 Ignis 积分配置的 key / aliases不再选服务，只决定积分换算项
流水 pricing_keyIgnis 命中的积分配置 key写入 ledger.extra，辅助分类和展示否

03 · Nano Pro 实例

线路已经能区分生成服务，但计费映射还有一处看不见

下表只写代码和当前技术配置接口能直接确认的内容。看不见的映射不做猜测。

线路前端提交Ignis 预估 KeyIgnis 实际提交的 Provider Key技术计费配置
标准线路modelKey=nano-banana-pro
generationLine=standard		nano-banana-profunpub-nano-banana-pro-t2i
funpub-nano-banana-pro-edit		kie-nano-banana-pro 当前明确包含这组模型 ID；model_identifier=nano-banana-pro
稳定线路modelKey=nano-banana-pro
generationLine=stable		nano-banana-pro-stablefunpub-nano-banana-pro-stable-t2i
funpub-nano-banana-pro-stable-edit		当前接口中的 Google 配置列出的是 google-nanobanana-pro*，没有列出左侧 stable Key。中间怎么映射，需要后端确认。
还有一个明确事实：KIE 和 Google 两条技术计费配置当前都写着 model_identifier=nano-banana-pro。如果成本回调只返回这个 modelKey，Ignis 无法仅靠它判断最终走了哪条线路；只能相信 costAmount 已按实际服务算对。

04 · 这意味着什么

当前能完成扣费，但预估、解释和对账还不够稳

预估

参数没有完整进入公式

前端现在主要算固定最高份数和数量。代码明确写着时长不参与，分辨率等参数也没有统一复用技术计费公式。

用户感知

固定低价和固定高价都难解释

低价可能明显低于实扣；统一改成最高价，又会让低配置任务看起来突然变贵。部分视频模型最低和最高差距达到数倍。

对账

fallback 后缺少最终服务标识

任务里能看到请求时的 provider_key，但成本回调和积分流水没有明确的最终 Provider 或 Billing Config。

建议讨论两件事：一是让 Ignis 同步技术计费配置，人工只维护展示名、线路名和积分比例；二是由服务端提供统一预估接口，复用实际成本公式。另建议成本回调补充 actualProviderKey 或 billingConfigId，至少用于 fallback 对账。

05 · 代码依据

每个判断对应到哪里

结论代码或接口
预估读取积分快照points.ts:3458–3491；points-pricing-context.tsx:99–176
前端预估公式GenerationPageClient.tsx:4766–4816
Nano 线路到预估/Provider 的映射model-catalog.ts:489–617
提交 Provider、计费元数据和任务保存provider-adapter.ts:74–120；generation.ts:716–733, 769–774
成本回调入参和实际扣分points.ts:281–312, 4807–4831
流水保存与页面展示points.ts:2835–2853, 4870–4963；ledger-ui.ts:554–582, 737–740
技术计费配置现状model-config-dashboard.pages.dev/api/billing-config，读取 config_id / model_identifier / config / _model_ids