Civitai 许可费谱系与父费规则parent-fee rule设计解析从扁平谱系到 LoRA 递归链【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai本文解读 Civitai 仓库中 Creator Studio 的许可费设计记录 licensing-lineage-parent-fee.md回答一个核心问题一次图像生成中每个资源checkpoint、LoRA、embedding 等究竟欠几笔许可费、分别付给谁。文章以 v1 扁平谱系规则为主线结合 mini endpoint 的fees[]发射实现、model-version.controller.ts的谱系校验与配套测试以及 Creator Studio 的读侧代码完整还原费用发射fee emission从产品规则到代码落地的全过程。读完你将对 Civitai 许可费模型的前向兼容设计、单祖先约束的写时强制、以及未来 LoRA→LoRA 递归链的扩展路径有清晰认识。两种费用概念own fee 与 parent fee当用户生成一张图像时生成涉及的每一个资源都可能欠费但欠费分为两个完全不同的概念Own fee自身费——资源自身的定价。例如 LoRA 每图0.1Buzz、checkpoint 每图1Buzz、Anima 这类生态基座每图5Buzz。Parent / ecosystem fee父费 / 生态费——欠给上游该资源所派生自的基座的费用。一次生成的总费用 所有使用资源的费用之和货币之间从不转换Buzz 与现金结算各自独立。这一两笔费用、各自结算的结构正是 licensing-fee-owner-stamping.md 中fees[]数组设计的出发点每个费用条目自带收款人因此数组可以随谱系深度自由伸缩。v1 规则只有 checkpoint / diffusion 才承担父费v1 的产品规则源于 Justin 在 2026-07-14 的扁平谱系答复并叠加了仅 checkpoint 承担父费的细化只有一条只有 checkpoint / diffusion 模型承担父费。LoRA以及 embedding、VAE 等只承担自身费。理由是LoRA 是运行在一个已经向生态付费的 checkpoint 之上的适配器adapter它本身不欠生态费。版本类型父谱系父费发射的费用Checkpoint / diffusion其生态 / 基座是own parent≤2LoRA —v1无否仅 own≤1LoRA —未来另一个 LoRA可能own 向上遍历祖先链这条规则带来两个直接推论分别决定了数据建模和代码形态每次生成、每个基座 checkpoint 的生态费只出现一次——因为一次生成中只有一个 base checkpoint父费按构造天然去重编排器orchestrator无需跨资源做生态费去重详见下文去重非问题。非 checkpoint 的禁入路径就是规则本身——即使数据里存在可解析的父关系如licensingSourceVersionIdLoRA 今天也绝不能发射父费实现时不能依赖数据恰好为空。谱系是类型一致的父永远是同类一个版本的父永远是它自己的种类绝不跨种类LoRA永远不会是 checkpoint 的微调版本因此 LoRA 的父永远不会是 checkpoint。如果 LoRA 有父那一定是LoRA-of-a-LoRA另一个 LoRA 的衍生品。checkpoint 的父就是它的生态 / 基座。这一点在 model-version.controller.ts 中有完整的写时强制实现当保存携带licensingSourceVersionId时服务端会同时校验父版本是否是已注册的LicensingRoot、base model 是否一致、以及model type 是否一致任何一项不满足都会把该字段强制置空coerce to null而不是抛错。校验顺序为not-a-root→base-model-mismatch→model-not-found→model-type-mismatch并会通过logToAxiom以model-version-licensing-source-rejected事件记录被拒绝的原因且区分seeded服务端在用户未提及该字段时修复存量值与客户端主动提交。其中model-type 一致性校验是后来补上的关键一环内部工单 CU 868kwf2fd、Freshdesk #69622由于每一行LicensingRoot都是 Checkpoint一个 LoRA 若继承了 checkpoint 的父费会以该 checkpoint 的所有者为收款人、按 checkpoint 的每图费率在标着 LoRA 自己名字的计费行上向所有生成者收费报告中真实案例用户以 10 Buzz/图 而非 5 Buzz/图 被多扣了一个月且站点上没有可清除该状态的界面。修复刻意选择强制置空而非抛错版本编辑器会从defaultValues回填存量值抛错会让所有已打上错误印记的版本无法被其所有者保存该修复落地时约 159 个版本处于此状态。配套测试 model-version.controller.licensing-lineage.test.ts 覆盖了全部判定分支从 LoRA 上移除 checkpoint 根、在 checkpoint 上保留 checkpoint 根、在 LoRA 上保留 LoRA 根尽管目前尚无此类根存在、从 checkpoint 上移除 LoRA 根model-type-mismatch、拒绝目标 model 无法容纳的根model-not-found、以及保存时省略该字段场景下对存量印记的修复与保留。为什么 checkpoint 保持扁平、LoRA 却可能深入这是决定最终代码形态的关键推论Checkpoint 永久扁平checkpoint 恰好只有一个祖先它的生态单跳。Justin 所说的其实不存在层级对 checkpoint 是永久成立的——最多 2 笔费用没有需要遍历的链条。LoRA→LoRA 是真正递归的LoRA C 派生自 LoRA B、LoRA B 派生自 LoRA A。这是未来唯一可能出现的真实多级链条——逐祖先叠加费用。它今天不存在于 checkpoint 分支只可能在 LoRA 分支出现。去重非问题the dedup non-issue由于一次生成中只有唯一一个base checkpoint 承担生态费该费用按构造每次生成只收取一次——编排器不需要跨资源去重生态费。去重担忧只在一个更早的错误模型下才成立那个模型里 LoRA 也发射生态费同一个基座生态费会从多个资源里重复出现。有趣的是licensing-fee-owner-stamping.md 的开销单里仍保留着将生态费去重为每次生成一次这条待办注明以仅 checkpoint/diffusion 承担父费 每次生成一个 base checkpoint规则为准确认计费时不存在重复计费——即产品规则本身已经把该待办消解掉了。费用发射mini endpoint的实现与前瞻性费用发射发生在主应用的 mini endpoint——src/pages/api/v1/model-versions/mini/[id].ts该端点由 briant 负责文档中的描述是设计意图而非命令式 diff。这是编排器在决定某资源能否生成、应收取多少费用时所读取的端点。按模型类型门控父费解析源码中fees[]的构建逻辑mini/[id].ts围绕三个布尔量展开isLicensingRoot——本版本自身是LicensingRoot表中的一行、且licensingFee 0。此时本版本的 own fee 就是谱系费结算给自身例如生态的 Turbo checkpoint 按自己的费率收费而非按基座费率。hasSourceRule——非根、存在licensingSourceVersionId、且父版本的sourceLicensingFee 0、且能解析出sourceLicensingFeeRecipientUserId。此时派生版本继承所选中根的费率并结算给它构建在 Turbo 之上的 checkpoint 继承 Turbo 费率。注意父为 null 不构成对(baseModel, modelType)默认费率的回退——旧的三级BaseModelLicensingFee规则已被移除衍生版本必须携带显式父关系。hasOwnFee——版本自身有正费用、且它不是谱系费用的接收者自身避免把根的自费重复计为附加费。fees数组的每个条目形如{ role: baseModel | version, // 谱系费 或 自身费 amount: number, type: string, // 如 perImageBuzz settlementCurrency: string, // 如 buzz recipientModelVersionId: number, recipientUserId: number, // 收款人的 User.id }recipientUserId是请求时刻recipientModelVersionId所有者的 ID因此收款与编排器写入的ResourceCompensation记录会跟随所有权转移而不是记到旧所有者名下。为什么fees[]是前向兼容的fees[]的形状已经为未来做好了准备每个条目自带recipientUserId因此数组可以从own 一个 parent平滑增长为own N 个遍历祖先编排器遍历fees[]与读侧按 owner 分组都无需改契约。当 LoRA 谱系落地时发射器只需遍历 LoRA 的父链、为每个祖先 push 一个条目——解除门控是一次放宽 遍历的改动而不是重新设计。这一点与 licensing-fee-owner-stamping.md 中单祖先在写时强制执行因此fees[]块最多 2 笔的结论互为表里model-version.controller.ts要求licensingSourceVersionId必须是共享同一 base model 的LicensingRoot从数据入口上保证了谱系深度为 1。读侧Creator Studio不受影响按模型的收益读取只是按 owner 分组读取已有的resourceCompensations行——费用条数、计费规则的任何变化都只改变底层数字不改变读取功能本身。因此整个谱系/父费问题与已上线的仪表盘 tile、分析表格完全正交。读侧实现见 apps/creator-studio/src/lib/server/models-earnings.ts 的getModelEarningsWHERE userId X … GROUP BY modelVersionId, accountType带缓存并在 Postgres 侧补齐名称/类型。它读取orchestration.resourceCompensations——该表是SharedSummingMergeTreeORDER BY (date, userId, modelVersionId, accountType, source)PARTITION BY toYYYYMM(date)因此读侧必须做sum(amount)GROUP BY普通求和引擎无sumMerge。读侧还有两个关键约定脏行过滤每次读取都带match(accountType,^[A-Za-z]$) AND amount 0 AND amount 1e12。大小写差异这里的accountType是首字母大写Yellow/Blue/Green/CashSettled与buzzTransactions的小写值不同读取时需lowerFirst到统一的货币词汇source还包含compensation_recovered_*变体licenseFee可能结算为CashSettled现金而非 Buzz。历史上该表已做过回溯填充99.7% 的行31.15M / 31.25M追溯至 2024-08-01 均完成了归属余下 0.3% 的userId 0行是无法映射的版本已删除模型自然落在任何按创作者userId X的读取之外。由于 owner 在写时盖章所有权转移自动自愈转移后写入的行携带新所有者历史行保留旧所有者——按时间点归属不做追溯重指派。待确认事项Open question截至该设计记录定稿仍有两点等待产品方Justin的明确确认确认**目前仅 checkpoint/diffusion 承担父费LoRA 仅自身费**作为写入代码的规则——记录中已按已决定处理但在代码门控前需要显式 ✅。当 LoRA 父费最终放开时确认意图是LoRA→LoRA 的向上遍历链、为每个祖先叠加一笔费用与上述前向兼容的fees[]形状一致。相关文档与代码索引设计记录licensing-lineage-parent-fee.md本文主体费用发射侧配套清单licensing-fee-owner-stamping.mdowner 盖章 / 收益读取侧mini endpoint → orchestrator →ResourceCompensation→ ClickHouse 视图费用设置 UIlicensing.md/licensing批量编辑器与本文的发射链相互独立发射端点src/pages/api/v1/model-versions/mini/[id].ts写时谱系校验model-version.controller.ts 及其测试 model-version.controller.licensing-lineage.test.ts读侧收益查询apps/creator-studio/src/lib/server/models-earnings.ts【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Civitai 许可费谱系与父费规则（parent-fee rule）设计解析：从扁平谱系到 LoRA 递归链
Civitai 许可费谱系与父费规则parent-fee rule设计解析从扁平谱系到 LoRA 递归链【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai本文解读 Civitai 仓库中 Creator Studio 的许可费设计记录 licensing-lineage-parent-fee.md回答一个核心问题一次图像生成中每个资源checkpoint、LoRA、embedding 等究竟欠几笔许可费、分别付给谁。文章以 v1 扁平谱系规则为主线结合 mini endpoint 的fees[]发射实现、model-version.controller.ts的谱系校验与配套测试以及 Creator Studio 的读侧代码完整还原费用发射fee emission从产品规则到代码落地的全过程。读完你将对 Civitai 许可费模型的前向兼容设计、单祖先约束的写时强制、以及未来 LoRA→LoRA 递归链的扩展路径有清晰认识。两种费用概念own fee 与 parent fee当用户生成一张图像时生成涉及的每一个资源都可能欠费但欠费分为两个完全不同的概念Own fee自身费——资源自身的定价。例如 LoRA 每图0.1Buzz、checkpoint 每图1Buzz、Anima 这类生态基座每图5Buzz。Parent / ecosystem fee父费 / 生态费——欠给上游该资源所派生自的基座的费用。一次生成的总费用 所有使用资源的费用之和货币之间从不转换Buzz 与现金结算各自独立。这一两笔费用、各自结算的结构正是 licensing-fee-owner-stamping.md 中fees[]数组设计的出发点每个费用条目自带收款人因此数组可以随谱系深度自由伸缩。v1 规则只有 checkpoint / diffusion 才承担父费v1 的产品规则源于 Justin 在 2026-07-14 的扁平谱系答复并叠加了仅 checkpoint 承担父费的细化只有一条只有 checkpoint / diffusion 模型承担父费。LoRA以及 embedding、VAE 等只承担自身费。理由是LoRA 是运行在一个已经向生态付费的 checkpoint 之上的适配器adapter它本身不欠生态费。版本类型父谱系父费发射的费用Checkpoint / diffusion其生态 / 基座是own parent≤2LoRA —v1无否仅 own≤1LoRA —未来另一个 LoRA可能own 向上遍历祖先链这条规则带来两个直接推论分别决定了数据建模和代码形态每次生成、每个基座 checkpoint 的生态费只出现一次——因为一次生成中只有一个 base checkpoint父费按构造天然去重编排器orchestrator无需跨资源做生态费去重详见下文去重非问题。非 checkpoint 的禁入路径就是规则本身——即使数据里存在可解析的父关系如licensingSourceVersionIdLoRA 今天也绝不能发射父费实现时不能依赖数据恰好为空。谱系是类型一致的父永远是同类一个版本的父永远是它自己的种类绝不跨种类LoRA永远不会是 checkpoint 的微调版本因此 LoRA 的父永远不会是 checkpoint。如果 LoRA 有父那一定是LoRA-of-a-LoRA另一个 LoRA 的衍生品。checkpoint 的父就是它的生态 / 基座。这一点在 model-version.controller.ts 中有完整的写时强制实现当保存携带licensingSourceVersionId时服务端会同时校验父版本是否是已注册的LicensingRoot、base model 是否一致、以及model type 是否一致任何一项不满足都会把该字段强制置空coerce to null而不是抛错。校验顺序为not-a-root→base-model-mismatch→model-not-found→model-type-mismatch并会通过logToAxiom以model-version-licensing-source-rejected事件记录被拒绝的原因且区分seeded服务端在用户未提及该字段时修复存量值与客户端主动提交。其中model-type 一致性校验是后来补上的关键一环内部工单 CU 868kwf2fd、Freshdesk #69622由于每一行LicensingRoot都是 Checkpoint一个 LoRA 若继承了 checkpoint 的父费会以该 checkpoint 的所有者为收款人、按 checkpoint 的每图费率在标着 LoRA 自己名字的计费行上向所有生成者收费报告中真实案例用户以 10 Buzz/图 而非 5 Buzz/图 被多扣了一个月且站点上没有可清除该状态的界面。修复刻意选择强制置空而非抛错版本编辑器会从defaultValues回填存量值抛错会让所有已打上错误印记的版本无法被其所有者保存该修复落地时约 159 个版本处于此状态。配套测试 model-version.controller.licensing-lineage.test.ts 覆盖了全部判定分支从 LoRA 上移除 checkpoint 根、在 checkpoint 上保留 checkpoint 根、在 LoRA 上保留 LoRA 根尽管目前尚无此类根存在、从 checkpoint 上移除 LoRA 根model-type-mismatch、拒绝目标 model 无法容纳的根model-not-found、以及保存时省略该字段场景下对存量印记的修复与保留。为什么 checkpoint 保持扁平、LoRA 却可能深入这是决定最终代码形态的关键推论Checkpoint 永久扁平checkpoint 恰好只有一个祖先它的生态单跳。Justin 所说的其实不存在层级对 checkpoint 是永久成立的——最多 2 笔费用没有需要遍历的链条。LoRA→LoRA 是真正递归的LoRA C 派生自 LoRA B、LoRA B 派生自 LoRA A。这是未来唯一可能出现的真实多级链条——逐祖先叠加费用。它今天不存在于 checkpoint 分支只可能在 LoRA 分支出现。去重非问题the dedup non-issue由于一次生成中只有唯一一个base checkpoint 承担生态费该费用按构造每次生成只收取一次——编排器不需要跨资源去重生态费。去重担忧只在一个更早的错误模型下才成立那个模型里 LoRA 也发射生态费同一个基座生态费会从多个资源里重复出现。有趣的是licensing-fee-owner-stamping.md 的开销单里仍保留着将生态费去重为每次生成一次这条待办注明以仅 checkpoint/diffusion 承担父费 每次生成一个 base checkpoint规则为准确认计费时不存在重复计费——即产品规则本身已经把该待办消解掉了。费用发射mini endpoint的实现与前瞻性费用发射发生在主应用的 mini endpoint——src/pages/api/v1/model-versions/mini/[id].ts该端点由 briant 负责文档中的描述是设计意图而非命令式 diff。这是编排器在决定某资源能否生成、应收取多少费用时所读取的端点。按模型类型门控父费解析源码中fees[]的构建逻辑mini/[id].ts围绕三个布尔量展开isLicensingRoot——本版本自身是LicensingRoot表中的一行、且licensingFee 0。此时本版本的 own fee 就是谱系费结算给自身例如生态的 Turbo checkpoint 按自己的费率收费而非按基座费率。hasSourceRule——非根、存在licensingSourceVersionId、且父版本的sourceLicensingFee 0、且能解析出sourceLicensingFeeRecipientUserId。此时派生版本继承所选中根的费率并结算给它构建在 Turbo 之上的 checkpoint 继承 Turbo 费率。注意父为 null 不构成对(baseModel, modelType)默认费率的回退——旧的三级BaseModelLicensingFee规则已被移除衍生版本必须携带显式父关系。hasOwnFee——版本自身有正费用、且它不是谱系费用的接收者自身避免把根的自费重复计为附加费。fees数组的每个条目形如{ role: baseModel | version, // 谱系费 或 自身费 amount: number, type: string, // 如 perImageBuzz settlementCurrency: string, // 如 buzz recipientModelVersionId: number, recipientUserId: number, // 收款人的 User.id }recipientUserId是请求时刻recipientModelVersionId所有者的 ID因此收款与编排器写入的ResourceCompensation记录会跟随所有权转移而不是记到旧所有者名下。为什么fees[]是前向兼容的fees[]的形状已经为未来做好了准备每个条目自带recipientUserId因此数组可以从own 一个 parent平滑增长为own N 个遍历祖先编排器遍历fees[]与读侧按 owner 分组都无需改契约。当 LoRA 谱系落地时发射器只需遍历 LoRA 的父链、为每个祖先 push 一个条目——解除门控是一次放宽 遍历的改动而不是重新设计。这一点与 licensing-fee-owner-stamping.md 中单祖先在写时强制执行因此fees[]块最多 2 笔的结论互为表里model-version.controller.ts要求licensingSourceVersionId必须是共享同一 base model 的LicensingRoot从数据入口上保证了谱系深度为 1。读侧Creator Studio不受影响按模型的收益读取只是按 owner 分组读取已有的resourceCompensations行——费用条数、计费规则的任何变化都只改变底层数字不改变读取功能本身。因此整个谱系/父费问题与已上线的仪表盘 tile、分析表格完全正交。读侧实现见 apps/creator-studio/src/lib/server/models-earnings.ts 的getModelEarningsWHERE userId X … GROUP BY modelVersionId, accountType带缓存并在 Postgres 侧补齐名称/类型。它读取orchestration.resourceCompensations——该表是SharedSummingMergeTreeORDER BY (date, userId, modelVersionId, accountType, source)PARTITION BY toYYYYMM(date)因此读侧必须做sum(amount)GROUP BY普通求和引擎无sumMerge。读侧还有两个关键约定脏行过滤每次读取都带match(accountType,^[A-Za-z]$) AND amount 0 AND amount 1e12。大小写差异这里的accountType是首字母大写Yellow/Blue/Green/CashSettled与buzzTransactions的小写值不同读取时需lowerFirst到统一的货币词汇source还包含compensation_recovered_*变体licenseFee可能结算为CashSettled现金而非 Buzz。历史上该表已做过回溯填充99.7% 的行31.15M / 31.25M追溯至 2024-08-01 均完成了归属余下 0.3% 的userId 0行是无法映射的版本已删除模型自然落在任何按创作者userId X的读取之外。由于 owner 在写时盖章所有权转移自动自愈转移后写入的行携带新所有者历史行保留旧所有者——按时间点归属不做追溯重指派。待确认事项Open question截至该设计记录定稿仍有两点等待产品方Justin的明确确认确认**目前仅 checkpoint/diffusion 承担父费LoRA 仅自身费**作为写入代码的规则——记录中已按已决定处理但在代码门控前需要显式 ✅。当 LoRA 父费最终放开时确认意图是LoRA→LoRA 的向上遍历链、为每个祖先叠加一笔费用与上述前向兼容的fees[]形状一致。相关文档与代码索引设计记录licensing-lineage-parent-fee.md本文主体费用发射侧配套清单licensing-fee-owner-stamping.mdowner 盖章 / 收益读取侧mini endpoint → orchestrator →ResourceCompensation→ ClickHouse 视图费用设置 UIlicensing.md/licensing批量编辑器与本文的发射链相互独立发射端点src/pages/api/v1/model-versions/mini/[id].ts写时谱系校验model-version.controller.ts 及其测试 model-version.controller.licensing-lineage.test.ts读侧收益查询apps/creator-studio/src/lib/server/models-earnings.ts【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考