尧图网站建设 
CivitAI 付费模型加载Paid Model Loading实施全解阶段式清单、覆盖率变更与编排器集成【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai导读本文围绕 CivitAI 仓库中 docs/features/paid-model-loading-checklist.md 这一实施清单系统拆解付费模型加载Paid Model Loading从决策、服务端管道、审核测试页、覆盖率变更到公开界面与编排器状态验证的完整落地过程。读完本文你将掌握该功能如何让任意检查点通过付费加载进入生成集群并承诺 48 小时驻留、GenerationCoverageNext覆盖率模型如何替换旧的CoveredCheckpoint门控、购买路径estimate/submit与分级限流的实现细节以及civitai/clientSDK 背后编排器orchestrator真实能力与文档中未构建差距的核对方法。功能背景付费模型加载是什么付费模型加载的核心设想是站点上任何模型都变得可生成。若模型未驻留在生成集群中用户付费将其加载进来并——按最初承诺——保证其驻留48 小时。价格由编排器按模型大小缩放设定详见 docs/features/paid-model-loading.md。要点驻留机制真实存在Koen 2026-09-04 确认spine 控制器在驱逐资源前会互相检查除非另一个 spine 控制器持有副本否则拒绝驱逐任何不足 48 小时驻留的资源PrepareResourceJob负责把资源下载进数据中心其后由该驱逐策略守护其生命周期代码位于civitai-spine-controller仓库的ClusterAwareEvictionPolicy.cs。文档曾误以为PinModelJob是目标原语实际它是遗留物。除非另一个控制器持有是良性的它只意味着副本可能在不同 spine 控制器间迁移可用性不中断因此界面可以按原承诺宣传 48 小时。价格半边仍然缺失成本函数硬编码返回零尚无按大小缩放的价格可展示——这是 C2 任务。该功能取代拍卖auctions作为让检查点进入生成器的机制。三个界面共享同一状态机模型版本页、生成器、以及链接到完整队列页的导航栏指示器。Phase 0决策——已全部关闭2026-09-08清单中 Phase 0 的每一项决策都有了答案不再阻塞任何工作答案与给出者记录在 docs/features/paid-model-loading-decisions.md 的 §1–§2由决策推导出的覆盖率模型及生产审计见 docs/features/paid-model-loading-coverage.md。决策项结论C14 — demo client、仅审核者还是平台从已有的审核测试页Phase 1.5开始我们能诚实卖什么按最初承诺的 48 小时副本可在窗口内于 spine 控制器间迁移可用性不中断任意模型仅检查点——体积正是加载器存在的原因LoRA 没有这个需求CoveredCheckpoint停止门控生成EcosystemCheckpoints与GenerationBaseModel保留。文档中早期LoRA 优先的建议是错的已删除无RentCivit许可的模型拒绝。实现为拒绝任何不在GenerationCoverage中的内容——今天零个已覆盖版本缺少该许可且以继承规则的方式而非重述规则不阻塞站点工作、但阻塞上线的项C2 — 按模型大小定价并启用收费Koen 负责。已核实这不是开关——PrepareResourceHandler.CalculateCost返回硬编码零因此定价函数必须新写在此之前whatif返回 0CTA 按钮上没有数字。C3 — Koen 的交接文档已完成并验证。C13 — 驱逐指标已完成并验证。Phase 1管道Plumbing——无用户可见界面Phase 1 没有用户可见表面但 Phase 2、3 的一切都建立在其上并且可以独立针对真实下载进行测试。C4 Webhook以暂不关闭C4 — 编排器在下载开始/推进时命中的端点以暂不关闭见 决策 2.4。其存在的两个理由都消失了C9 属于 Phase 2且旁观者需要的是完成时通知而非实时进度。Phase 2 需要服务端发送时机时会重新打开。主题广播助手与信号消息sendSignalToTopic(topic, message, data)位于 src/server/orchestrator/orchestrator.utils.ts用withSignals()包裹。⚠️ 目前仍无调用方也没有计划中的调用方——加载进度改为按用户投递且 C4 已关闭它留待 Phase 2 需要时使用若 Phase 2 不需要则应删除。源码中该函数实际 POST 到${SIGNALS_ENDPOINT}/groups/{topic}/signals/{message}与聊天所用形状一致。新增SignalMessages条目ResourceLoadUpdate resource-load:update投递到用户自己的频道而非主题。与已有的SchedulerDownload scheduler:download那是生成历史导出不是本功能不冲突。提取 versionId → AIRmodelVersionToAir位于 src/server/utils/resource-air.tsbustOrchestratorModelCache与modelVersionResourceCache均改指向它。fileType仅在调用方已加载文件时来自主文件——源码注释明确指出传了files与没传files的调用方是在询问两个不同的 AIR检查点主文件若是 diffusion model/UNet 会改变所广告的种类。服务端资源状态读取getResourceLoadState(versionIds)与getResourceLoadQueue({cursor, take})位于 src/server/services/resource-load.service.ts通过resourceLoad.getState/resourceLoad.getQueue暴露两者均为publicProcedureC5 之前保持旗标门控。队列读取经由新加的queryResourcesClient包装器位于services/orchestrator/models.tsSDK 调用保持在服务层。新鲜、未缓存——不复用modelVersionResourceCache其日级 TTL 且丢弃availability本构建不认识的状态上报为unknown不折叠进四种已知状态之一。服务测试src/server/services/tests/resource-load.service.test.ts 覆盖AIR 构造、unavailable上的queuePosition、unknown回退、无法解析的队列行、四种预提交拒绝不可生成、无权重文件、未扫描文件、版本不存在、进度 URL 指向/users/而绝不指向/groups/、owner 检查传播、有价与无价。尚未钉住的是unsupported与已available的拒绝。测试还演示了unknown语义编排器返回{ status: evicting, someNewField: 1 }这类未知状态或完全无数据时均上报unknown。购买路径resourceLoad.estimatewhatIf与resourceLoad.submit已存在、已门控、可工作缺的只是可展示的价格。✅assertWorkflowOwner用于 submit 结果——源码中submitResourceLoad在submitWorkflow后立即调用assertWorkflowOwner(workflow, userId, token)受no-unguarded-billable-submit守卫约束该守卫的 docstring 点名的故障模式正是新付费功能自建submitWorkflow调用而该 diff 的评审者没有理由把它与另一子系统的账单事故联系起来。✅status unsupported以及完全读不到状态时拒绝。✅ 已available时不扣费拒绝——resolveLoadable中的注释解释编排器接受已驻留的 prepare 并瞬间完成用户会白付钱。✅ 价格来自whatIf提交而非站点侧价格表——estimateResourceLoad返回{ cost, priced }编排器报价为零时priced为 false任何界面都无法把免费渲染成报价。仍被 C2 阻塞。⬜ 干净地呈现编排器自身的CanGenerate拒绝——PrepareResourceInput会在任何扣费前抛出ValidationException。✅ 模型缺少RentCivit许可时拒绝——实现为resolveLoadable的!eligible拒绝覆盖率GenerationCoverageNext与生态类型支持由isGenerationEligible组合estimate与submit都走它。resolveLoadable的完整拒绝链源码!state.eligible→ 此资源无法在站点上生成加载它买不到任何东西!state.loadable→ 按UNLOADABLE_MESSAGESno-weights/unsupported-format两种文案拒绝unsupported→ 生成集群无法托管此资源unknown→ 无法读取资源状态请重试available→ 资源已加载可直接生成。C10 — 分级每日速率限制档位每日加载数Free0 —— 在到达限流器前即被assertCanRequestLoad拒绝Bronze3Silver6Gold / Founder10每日阶梯之上还有一条与档位无关的 3 次/小时扁平限制——这是对集群的突发保护不是权益任何套餐都不能豁免。机制是现有rateLimit()tRPC 中间件src/server/middleware.trpc.ts。清单与源码src/server/routers/resource-load.router.ts记录了六条决定上限是否真正成立的性质分级阶梯可正确组合每周期最高匹配上限生效金卡用户同时命中无条件和金卡两行时得到 10 而非 0limit: 0不是成员门槛它可干净短路但中间件对审核者及 dev/test/preview 环境提前返回预览构建上再无其他东西拦住免费账号的免费加载——assertCanRequestLoad()才是门槛。userTiers是[free, founder, bronze, silver, gold]若免费行写成userReq: (u) u.tier free而非无条件行任何未匹配档位都等于没有限制validLimits为空、检查循环不执行、canProceed保持 true因此免费行必须是无条件兜底且founder需要自己的行差一错误比较是attempts limit因此每个非零数字都多放行一次——3 意味着 4。要么接受并写下来要么改中间件但它是全应用共享的改它会波及所有限流器审核者完全跳过限流dev/test/preview 同所以仅审核者上线等于没有任何上限也无法验证上限是否有效失败开放Redis 写入降级时请求被放行且少计rate-limit-write-degraded。对配额可接受但要知道它不是硬上限使用onlyCountSuccess: true被拒绝的购买不支持的资源、已驻留、Buzz 不足不应烧掉金卡用户的每日额度。resourceLoadRateLimits数组src/server/routers/resource-load.router.ts展示了完整配置每日行是权益套餐包含什么每小时行是集群的扁平、无套餐可豁免两者在同一个sharedKey: resource-load:submit上组合。同一sharedKey必须应用到生成提交路径否则通过 txt2img 隐式触发的 prepare 会完全绕过上限——当前上限对直接生成而非按按钮的人只是装饰。Phase 1.5审核测试页构建计划之外的产物是为了在 Phase 2 存在之前就能端到端驱动管道。✅/moderator/resource-load——requireModerator加resourceLoad旗标提交模型版本 id在提交前解析出名称、AIR、大小、可用性、是否可生成/有权重估算按钮在原因已知时禁用并显示原因而不是提交时才失败编排器报价为零时估算自称未定价来自持久化 store 的等待中列表带实时进度与停止关注集群队列每 15 秒轮询有实时信号进度时优先采用通过买家自己的信号频道接收实时进度⚠️ 审核者豁免rateLimit()此页完全不检验 C10。✅跟踪与通知—— src/store/resource-load.store.ts持久化、自排空、48 小时上限与ResourceLoadDrain挂载在AppHeader任何带resourceLoad旗标的已登录用户都会在下次落地页面时收到已完成加载的报告toast 需手动关闭。⬜此页之外还没有任何入口能创建关注store 支持kind: watching且 drain 会报告它但创建它的按钮是模型版本页上的 C5 任务——旁观者通知已构建但不可达。客户端 store 的排空语义源码级resourceLoadDrainVerdict纯函数可在无浏览器环境下测试在每次页面加载时对每个条目判定available完成toast 后移除版本缺失移除loading或带位置的在队列中保留其余移除无在途加载。每一条目都必须能离开是关键失败的加载与完成后被驱逐的加载都会读回unavailable与排队中无法区分因此RESOURCE_LOAD_EXPIRY_MS 48h是必须的——它匹配驻留策略但上限不得吞掉好结果——加载在上限之后完成仍要报告。track重新跟踪时保留原始requestedAt防止每次访问刷新让条目活过自己的截止时间。Phase 1.6覆盖率变更由 Phase 0 在 2026-09-08 的答案产生。规则、审计与每个测量数字都在 docs/features/paid-model-loading-coverage.md。新的覆盖率视图GenerationCoverageNext✅与GenerationCoverage并排的新视图迁移 packages/civitai-db-schema/prisma/migrations/20260908120000_generation_coverage_next/migration.sql 创建GenerationCoverageNext2026-09-08 已应用到生产。 不命名为GenerationCoverage2该名字在生产中已作为早期过期实验存在CREATE OR REPLACE会静默覆盖它。刻意不加入schema.full.prisma——切换时用新视图体替换GenerationCoverage自身并删除该视图Prisma 模型永不变。三分支无加载文件已覆盖、永不被加载、在EcosystemCheckpoints中且有加载文件、以及GenerationBaseModel基模型上的检查点且有加载文件。LORA/TI/VAE/LoCon/DoRA/Upscaler 分支不变。✅ 去掉CoveredCheckpoint合取项允许Diffusers但保持 Core ML 与 ONNX 排除数字见覆盖率文档。✅检查点必须有 SafeTensor 权重文件迁移20260909180000_generation_coverage_next_safetensor_checkpoints2026-09-09收窄了 09-08 的视图Diffusers 对除检查点外的所有类型仍可加载CoveredCheckpoint以析取项回归、豁免 6 个驻留拍卖的版本。已编写、尚未应用到任何环境。⬜ 保留EcosystemCheckpoints—— 63 个检查点默认值中有 62 个依赖它。✅ 与生产对比2026-09-08——当时无任何覆盖损失。⬜ 应用 SafeTensor 迁移后 2,242 个已覆盖检查点失去覆盖33,811 → 31,569其中 834 个有生成历史6.5M 生命周期生成量。这是收窄没有安全窗口——应在covered的读者就绪时再应用。关闭条件应用到生产且已覆盖检查点计数读数为 31,569。覆盖率数字2026-09-08 同一查询测出GenerationCoverageGenerationCoverageNext已覆盖检查点63833,796全部类型已覆盖行899,553933,38633,158 检查点、33,833 行。两者增量不同是因为从排除格式中移除Diffusers惠及所有类型而非仅检查点——约 675 行新增为 LoRA 等。⚠️514 不是已覆盖检查点数它是CoveredCheckpoint拍卖名单的行数今天有 638 个版本以检查点身份被覆盖因为EcosystemCheckpoints也贡献。加载器群体分桶EcosystemCheckpoints125 个A 类 51 个无加载文件 → 永不加载B 类 74 个走加载器社区检查点 33,792 个A 类 123B 类 33,669——约33,743 个可加载检查点对比拍卖今天覆盖的 514 个。许可门禁零个已覆盖版本缺少RentCivit两种方式验证逐分支 端到端对视图899,068 已覆盖行、0 无许可。视图有两条不检查许可的分支——EcosystemCheckpoints成员与usageControl ExternalGeneration——但当前无任何版本借此逃逸这两分支覆盖的 143 个版本都持RentCivit。结论门禁基于覆盖而非直接测许可因为若某版本日后走旁路它仍保持正确且以继承规则取代第二份意见。单一canGenerate派生isGenerationEligible位于 packages/civitai-shared/src/generation-eligibility.tscovered !isGenerationDisabled(flags) isBaseModelGenerationSupported(baseModel, modelType)。四个调用点全部改指它no-divergent-can-generate-derivation守卫把isBaseModelGenerationSupported挡在src/之外。仅覆盖会多报 736 个版本33 个 (baseModel, type) 组合如 Wan Video LORA 337、Flux.1 D DoRA 102 等——见覆盖率文档。其他 Phase 1.6 条目✅加载 CTA 门控于isGenerationEligible且有可加载文件——不基于covered、不基于usageControl、不基于有任何文件。审核页已做服务端在resolveLoadable中强制C5/C6 添加公开 CTA 时复查。✅estimate与submit拒绝任何不在覆盖中的内容即RentCivit门——resolveLoadable读取GenerationCoverageNext。✅审计covered的每个现有读者23 个文件分类见覆盖率文档。分类 A生成门禁generation.service的canGenerate与resource-data.redis.ts在调度切换前必须精读B 搜索models.search-index.ts 与 models-update.tsC 展示各 controller/selector 与/api/v1/model-versions/mini/[id]——后者已切换因为编排器读它做CanGenerate实测版本 3040959 上旧视图会拒绝所有值得做的加载D 池与相邻消费者daily-challenge、App Blocks workflow.service、model.service.ts与caches.ts的模型列表过滤E 无操作getCheckpointGenerationCoverage零调用方死代码backfill-trained-model-permissions.ts的断言在新视图下仍真。⬜ 共享限流键与 C2 定价必须先于站点生成门读取新视图落地generation.service、resource-data.redis、搜索索引。放宽它们会让数万更多版本可生成而针对非驻留版本的生成提交会触发隐式 prepare——今天免费且无上限因为 C10 只守resourceLoad.submit。两个已读取GenerationCoverageNext的调用方刻意在此规则之外resource-load.service购买路径——旗标门控放宽正是其目的与/api/v1/model-versions/mini/[id]编排器CanGenerate读取无站点代码调用它。⬜决定搜索展示什么索引从covered派生canGenerate切换后会宣传数万更多模型可生成却无法表达需要先加载。✅检查公开 API 字段/api/v1/model-versions/mini/[id]现从GenerationCoverageNext选择covered2026-09-08 完成。⚠️ 该字段对第三方消费者的含义已改变未打旗标、未公告。⬜查看池消费者——每日挑战模型选择、App Blocks 工作流服务、model.service.ts与caches.ts的模型列表过滤。⬜删除getCheckpointGenerationCoverage与CoveredCheckpoint一起零调用方。⬜决定handle-auctions.ts的去留一旦无行被读取。36 个贴错标签的 API 模型36 个EcosystemCheckpoints版本是外部 API 模型其唯一文件是Training Data格式Other。决策Justin 2026-09-08将其usageControl设为ExternalGeneration。model-version.controller.ts拒绝非审核者设置该值因此是直接 DB 写或审核者操作。已验证安全ExternalGeneration视图分支要求已发布且非 POI36/36 均满足覆盖保持不变。Phase 2公开界面依赖 C14 决策C5 — 模型版本页Create 按钮下方对所有人可见而非仅购买者四种状态unsupported完全无 CTA订阅按钮让旁观者可采纳他人进行中的加载页面已订阅model-version:id——扩展而非新增第二个订阅。C6 — 生成器未加载 → 按大小定价提供付费加载下载中 → 自动订阅并对所选资源内联显示进度已加载 → 不变任意模型决策已定仅检查点。C6 现在依赖Phase 1.6落地而非决策。C7 — 导航栏指示器镜像 src/components/Resource/UploadTracker.tsx——同样的IndicatorPopover形状挂在AppHeader其旁先显示队列位置下载开始后显示进度按钮通向队列页localStoragestore挂载时轮询资源端点、丢弃已完成项、对其余重新订阅⚠️ popover 在 header 内需显式传withinPortal应用主题将Popover设为withinPortal: false否则会被裁剪。C8 — 队列页读取resourceLoad.getQueue服务端包装queryResources({ view: queue })轮询信号订阅仅限本用户等待的条目跨 provider 排名已在服务端完成不要重建⚠️ 游标是活重排列表上的整数偏移分页不稳定——保持take小每项服务端要两次 grain 调用。C9 — 加载完成通知发给购买者和每个在 C5 按过订阅的人需要NotificationCategory与设置条目——notification-settings-polarity守卫src/server/notifications/tests/钉住默认极性。Phase 3后果盯住驱逐指标C13 已暴露它但无人查看。首次公开加载前把它放上仪表盘——它是 Briant饥饿担忧的唯一仪器。关闭条件指标在某个有名者监看的仪表盘上。C11 — 退役拍卖在 868gtq1kt把 featured 从拍卖中拆出有答案前不划定范围——拍卖承担两个职责付费加载替换其一。约 89 个src/下文件涉及。CoveredCheckpoint冲突已通过将其从覆盖合取项移除Phase 1.6解决——拍卖任务不能再取消覆盖付费检查点它作为析取项存活、覆盖 6 个缺 SafeTensor 文件的驻留拍卖版本这些都不加载故不可能被付费过。剩余问题只是该任务是否继续写无人读取的行。编排器状态对照源码验证以下信息直接读自编排器仓库civitai-orchestrationmainat9306e7333而非 SDK。该提交已部署因此下面标记为已构建的一切都已上线。已构建并可工作事项状态GET /v2/resources?viewqueue已实现ResourcesController.QueryAsync合并每个启用 provider 的队列、按 AIR 去重、排名、分页。一个不可达 provider 降级为空贡献而非让调用失败。把各 provider 排名拍平成 1..n已在服务端完成客户端勿重建GET /v2/resources/{air}已实现在控制器层把availability拼接到ResourceInfo按资源做响应缓存四种可用状态与 SDK 类型完全一致ResourceAvailability.cs含queuePosition只存在于unavailableprepareResource作为工作流步骤存在——PrepareResourceStep含 handler、PrepareResourceJob与生命周期校验标记[Preview]非仅 recipe调用信号设计成立进度事件存在step:*已能接收已驻留时的实例成功handler 检查可用性资源available时不发 job——重复 prepare 免费且瞬间完成进度事件——比 SDK 暗示的更好卡在下载上的步骤会发布WorkflowStepEvent携带Preparation { Resource, QueuePosition, Progress, EtaSeconds }——正是 UI 需要的负载。刷新间隔10 秒PreparationRefreshInterval注释解释为何更紧无意义worker 本身大致以该速率上报资源成本。发布按变更去重、1% 进度粒度PreparationProgressPublishThreshold 0.01完整下载最多约 100 个事件。门控规则进度最差的 job 门控该步骤。step:preparing被刻意从 OpenAPI 枚举中隐藏WorkflowCallbackSchemaFilter显式从广告值中移除preparing与scheduled这就是生成 SDK 联合只列生命周期转换、让人以为功能缺失的原因。功能没缺只是未广告。用step:*订阅即可匹配包括Preparing在内的每个状态——分发测试是x.EventType is null || x.EventType event.StatusgetOrchestratorCallbacks已用step:*生成今天就在接收这些事件。K2 答复Koen 已把缺失事件类型补进规范未来civitai/client发布应携带类型。未构建 此表曾有一行称 48 小时保证不存在——那是错的且错在最昂贵的方向上它宣称产品头条特性缺失。机制位于civitai-spine-controller——本清单从未读过的仓库PinModelJob作为原定原语是遗留物Koen2026-09-04。唯一真实差距是定价。差距后果成本硬编码为零PrepareResourceHandler.CalculateCost返回{ Factors [], Fixed [] }其自身注释说两个集合都空即短路为零成本C2 不是配置开关——按大小缩放的定价函数尚未编写。?whatiftrue今天返回零而非价格CTA 没有数字可显示驻留——本清单未读的仓库此处无法验证civitai-spine-controller未在站点侧检出。记录的是 Koen 的答复DM2026-09-04而非读到的源码spine 控制器在驱逐资源前互相检查拒绝驱逐任何不足 48 小时驻留的资源除非另一个 spine 控制器持有它PrepareResourceJob的唯一职责是把资源送进 DC驱逐策略自此守护其生命周期ClusterAwareEvictionPolicy.csPinModelJob是遗留物——看都不用看⚠️ 无任何东西暴露资源 48 小时窗口何时结束——仍无倒计时可构建。值得知道的站点相关细节队列游标是整数偏移而非稳定游标排名每请求从实时 provider 状态重算队列变动时条目在页间移动。适合单首页勿构建假设稳定性的分页视图。take被钳制在1..500默认 100站点侧 schemasrc/server/schema/resource-load.schema.ts进一步限制为 1..100、默认 50。队列调用对每项fan-outGetInfoAsyncGetAvailabilityAsync——500 项一页就是 1,000 次 grain 调用。保持小页、温和轮询。PrepareResourceInput.OnInitializedAsync拒绝CanGenerate为 false 的资源抛ValidationException——这是编排器自己的覆盖门会在我们扣费前拒绝值得作为干净错误呈现而非 400。PrepareResourceJob有24 小时MaxTimeout与 2 分钟 claim 时长。以实测约 10 KB/s 带宽大型检查点可能触及该上限。GET /v2/resources需要Consumer角色DELETE需要Manager。站点的缓存击穿路径已用系统 token 做删除。回调url是任意字符串指向 signalsgroup/groups/model-version:{id}/signals/{message}是站点侧选择编排器无需任何东西——这就是旁观者订阅可在无 C4 端点的情况下工作的方式。但加载进度不是主题广播它去/users/{userId}/signals/因为编排器直发事件体、该体指名付费用户workflowId为userId-timestamp测试断言 URL 含/users/且不含/groups/。信号路径与通知形态信号路径与图像生成同构工作流 → 站点端点 → 信号服务 → 客户端。发送侧按用户发送与主题广播都在 src/server/orchestrator/orchestrator.utils.ts全部经 withSignals() 路由——未包裹的信号服务 fetch 正是 2026-05-30 事件循环级联事故的形态。订阅侧useSignalTopic(topic)src/components/Signals/SignalsProvider.tsx 的useSignalTopic按主题引用计数、自动 join/leave 组src/components/Model/ModelVersions/model-version.utils.ts 已订阅model-version:id因此站点可按模型版本 id 订阅下载而无需新工作流步骤。主题命名约定已存在SignalTopic.ModelVersion model-versionsrc/server/common/enums.ts。决策 1.4 纠正了早期设计加载回调曾指向model-version:id信号组让所有观看该模型的人收到进度。那会泄露信息编排器直发WorkflowStepEventworkflowId是userId-timestamp——组播会把谁付了款告诉每个观看者。回调现指向/users/{userId}/signals/旁观者得不到实时进度改为在就绪时被通知。不在 v1 范围内记录在案付费提升队列位置——若机器人军团击穿限流Justin 预期它会回归。搜索结果中的加载状态。模型何时可用的硬性保证——当时数据中心带宽约 10 KB/sLoRA 花了四小时。对到达时间不做承诺——这与到达后停留多久是不同问题决策 1.3。无主缺口真实工作但无任务、无负责人列出以便被决策而非被发现退款路径失败或永不完成的加载。已决策退款决策 1.2未决的是谁退——K3 问 Koen 编排器是否已做。PrepareResourceJob24 小时MaxTimeout加约 10 KB/s 带宽使这不是罕见路径。驻留显示驻留真实存在但无 API 报告资源 48 小时窗口何时结束没有可倒计时的东西。需要先向编排器提需求。构建顺序与已决策事项速查构建计划docs/features/paid-model-loading-build-plan.md给出四阶段顺序Phase A管道已构建resource-air.ts、schema、service、router、信号消息、回调构建器、resourceLoad旗标、/moderator/resource-load审核页→Phase B只读界面store、utils、ResourceLoadCard非购买态、ResourceLoadTracker、队列页——无购买路径故不依赖定价→Phase C购买服务端半成品已构建缺口是 CTA、干净呈现CanGenerate拒绝、以及 C2 定价→Phase DC9 通知、C11 拍卖退役。不构建清单同样明确不建队列排名算法、不建尺寸→价格表、不建驻留倒计时、搜索不加加载状态、v1 不做队列位置提升。已决策、勿重开摘要限流在站点侧而非编排器侧浏览器用localStorage保存正在关注并在每次页面加载排空48 小时过期保证每项都能离开购买的持久记录是编排器的工作流标签resource-load、用买家 token 查询不是 localStorage 也不是 Redis进度信号去买家自己的频道旁观者无实时进度下次访问时被告知就绪真正 API 级通知是 Phase 2 目标进度显示在三处导航栏、模型版本页 Create 下方、生成器所选资源旁观者可订阅他人进行中的加载加载状态与队列是公开读取界面按原样承诺 48 小时加载只针对检查点CoveredCheckpoint停止门控生成只有GenerationBaseModel中的基模型可加载检查点需SafeTensor权重文件2026-09-09无文件 API 模型永不加载GGUF/PickleTensor/Diffusers 检查点得到不同拒绝文案——UNLOADABLE_MESSAGES在 src/server/schema/resource-load.schema.ts 是两者的单一来源永不完成的加载退款购买路径拒绝任何不在GenerationCoverageNext中的内容由isGenerationEligible组合生态类型支持每日上限必须覆盖隐式路径对非驻留资源的生成提交——同一配额而非第二配额免费档上线即 0/天并发 prepare 同一资源无需特殊处理。阻塞依赖C2定价与启用收费阻塞所有公开暴露——加载当前在编排器侧免费C2 前上线站点界面等于送出集群驻留。C14demo 客户端决策门控 C5–C8——Briant 主张先向高级用户演示Justin 主张小型独立第一方应用端到端驱动 Koen 的 API 或仅审核者上线Justin 拥有该决策。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CivitAI 付费模型加载（Paid Model Loading）实施全解：阶段式清单、覆盖率变更与编排器集成
CivitAI 付费模型加载Paid Model Loading实施全解阶段式清单、覆盖率变更与编排器集成【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai导读本文围绕 CivitAI 仓库中 docs/features/paid-model-loading-checklist.md 这一实施清单系统拆解付费模型加载Paid Model Loading从决策、服务端管道、审核测试页、覆盖率变更到公开界面与编排器状态验证的完整落地过程。读完本文你将掌握该功能如何让任意检查点通过付费加载进入生成集群并承诺 48 小时驻留、GenerationCoverageNext覆盖率模型如何替换旧的CoveredCheckpoint门控、购买路径estimate/submit与分级限流的实现细节以及civitai/clientSDK 背后编排器orchestrator真实能力与文档中未构建差距的核对方法。功能背景付费模型加载是什么付费模型加载的核心设想是站点上任何模型都变得可生成。若模型未驻留在生成集群中用户付费将其加载进来并——按最初承诺——保证其驻留48 小时。价格由编排器按模型大小缩放设定详见 docs/features/paid-model-loading.md。要点驻留机制真实存在Koen 2026-09-04 确认spine 控制器在驱逐资源前会互相检查除非另一个 spine 控制器持有副本否则拒绝驱逐任何不足 48 小时驻留的资源PrepareResourceJob负责把资源下载进数据中心其后由该驱逐策略守护其生命周期代码位于civitai-spine-controller仓库的ClusterAwareEvictionPolicy.cs。文档曾误以为PinModelJob是目标原语实际它是遗留物。除非另一个控制器持有是良性的它只意味着副本可能在不同 spine 控制器间迁移可用性不中断因此界面可以按原承诺宣传 48 小时。价格半边仍然缺失成本函数硬编码返回零尚无按大小缩放的价格可展示——这是 C2 任务。该功能取代拍卖auctions作为让检查点进入生成器的机制。三个界面共享同一状态机模型版本页、生成器、以及链接到完整队列页的导航栏指示器。Phase 0决策——已全部关闭2026-09-08清单中 Phase 0 的每一项决策都有了答案不再阻塞任何工作答案与给出者记录在 docs/features/paid-model-loading-decisions.md 的 §1–§2由决策推导出的覆盖率模型及生产审计见 docs/features/paid-model-loading-coverage.md。决策项结论C14 — demo client、仅审核者还是平台从已有的审核测试页Phase 1.5开始我们能诚实卖什么按最初承诺的 48 小时副本可在窗口内于 spine 控制器间迁移可用性不中断任意模型仅检查点——体积正是加载器存在的原因LoRA 没有这个需求CoveredCheckpoint停止门控生成EcosystemCheckpoints与GenerationBaseModel保留。文档中早期LoRA 优先的建议是错的已删除无RentCivit许可的模型拒绝。实现为拒绝任何不在GenerationCoverage中的内容——今天零个已覆盖版本缺少该许可且以继承规则的方式而非重述规则不阻塞站点工作、但阻塞上线的项C2 — 按模型大小定价并启用收费Koen 负责。已核实这不是开关——PrepareResourceHandler.CalculateCost返回硬编码零因此定价函数必须新写在此之前whatif返回 0CTA 按钮上没有数字。C3 — Koen 的交接文档已完成并验证。C13 — 驱逐指标已完成并验证。Phase 1管道Plumbing——无用户可见界面Phase 1 没有用户可见表面但 Phase 2、3 的一切都建立在其上并且可以独立针对真实下载进行测试。C4 Webhook以暂不关闭C4 — 编排器在下载开始/推进时命中的端点以暂不关闭见 决策 2.4。其存在的两个理由都消失了C9 属于 Phase 2且旁观者需要的是完成时通知而非实时进度。Phase 2 需要服务端发送时机时会重新打开。主题广播助手与信号消息sendSignalToTopic(topic, message, data)位于 src/server/orchestrator/orchestrator.utils.ts用withSignals()包裹。⚠️ 目前仍无调用方也没有计划中的调用方——加载进度改为按用户投递且 C4 已关闭它留待 Phase 2 需要时使用若 Phase 2 不需要则应删除。源码中该函数实际 POST 到${SIGNALS_ENDPOINT}/groups/{topic}/signals/{message}与聊天所用形状一致。新增SignalMessages条目ResourceLoadUpdate resource-load:update投递到用户自己的频道而非主题。与已有的SchedulerDownload scheduler:download那是生成历史导出不是本功能不冲突。提取 versionId → AIRmodelVersionToAir位于 src/server/utils/resource-air.tsbustOrchestratorModelCache与modelVersionResourceCache均改指向它。fileType仅在调用方已加载文件时来自主文件——源码注释明确指出传了files与没传files的调用方是在询问两个不同的 AIR检查点主文件若是 diffusion model/UNet 会改变所广告的种类。服务端资源状态读取getResourceLoadState(versionIds)与getResourceLoadQueue({cursor, take})位于 src/server/services/resource-load.service.ts通过resourceLoad.getState/resourceLoad.getQueue暴露两者均为publicProcedureC5 之前保持旗标门控。队列读取经由新加的queryResourcesClient包装器位于services/orchestrator/models.tsSDK 调用保持在服务层。新鲜、未缓存——不复用modelVersionResourceCache其日级 TTL 且丢弃availability本构建不认识的状态上报为unknown不折叠进四种已知状态之一。服务测试src/server/services/tests/resource-load.service.test.ts 覆盖AIR 构造、unavailable上的queuePosition、unknown回退、无法解析的队列行、四种预提交拒绝不可生成、无权重文件、未扫描文件、版本不存在、进度 URL 指向/users/而绝不指向/groups/、owner 检查传播、有价与无价。尚未钉住的是unsupported与已available的拒绝。测试还演示了unknown语义编排器返回{ status: evicting, someNewField: 1 }这类未知状态或完全无数据时均上报unknown。购买路径resourceLoad.estimatewhatIf与resourceLoad.submit已存在、已门控、可工作缺的只是可展示的价格。✅assertWorkflowOwner用于 submit 结果——源码中submitResourceLoad在submitWorkflow后立即调用assertWorkflowOwner(workflow, userId, token)受no-unguarded-billable-submit守卫约束该守卫的 docstring 点名的故障模式正是新付费功能自建submitWorkflow调用而该 diff 的评审者没有理由把它与另一子系统的账单事故联系起来。✅status unsupported以及完全读不到状态时拒绝。✅ 已available时不扣费拒绝——resolveLoadable中的注释解释编排器接受已驻留的 prepare 并瞬间完成用户会白付钱。✅ 价格来自whatIf提交而非站点侧价格表——estimateResourceLoad返回{ cost, priced }编排器报价为零时priced为 false任何界面都无法把免费渲染成报价。仍被 C2 阻塞。⬜ 干净地呈现编排器自身的CanGenerate拒绝——PrepareResourceInput会在任何扣费前抛出ValidationException。✅ 模型缺少RentCivit许可时拒绝——实现为resolveLoadable的!eligible拒绝覆盖率GenerationCoverageNext与生态类型支持由isGenerationEligible组合estimate与submit都走它。resolveLoadable的完整拒绝链源码!state.eligible→ 此资源无法在站点上生成加载它买不到任何东西!state.loadable→ 按UNLOADABLE_MESSAGESno-weights/unsupported-format两种文案拒绝unsupported→ 生成集群无法托管此资源unknown→ 无法读取资源状态请重试available→ 资源已加载可直接生成。C10 — 分级每日速率限制档位每日加载数Free0 —— 在到达限流器前即被assertCanRequestLoad拒绝Bronze3Silver6Gold / Founder10每日阶梯之上还有一条与档位无关的 3 次/小时扁平限制——这是对集群的突发保护不是权益任何套餐都不能豁免。机制是现有rateLimit()tRPC 中间件src/server/middleware.trpc.ts。清单与源码src/server/routers/resource-load.router.ts记录了六条决定上限是否真正成立的性质分级阶梯可正确组合每周期最高匹配上限生效金卡用户同时命中无条件和金卡两行时得到 10 而非 0limit: 0不是成员门槛它可干净短路但中间件对审核者及 dev/test/preview 环境提前返回预览构建上再无其他东西拦住免费账号的免费加载——assertCanRequestLoad()才是门槛。userTiers是[free, founder, bronze, silver, gold]若免费行写成userReq: (u) u.tier free而非无条件行任何未匹配档位都等于没有限制validLimits为空、检查循环不执行、canProceed保持 true因此免费行必须是无条件兜底且founder需要自己的行差一错误比较是attempts limit因此每个非零数字都多放行一次——3 意味着 4。要么接受并写下来要么改中间件但它是全应用共享的改它会波及所有限流器审核者完全跳过限流dev/test/preview 同所以仅审核者上线等于没有任何上限也无法验证上限是否有效失败开放Redis 写入降级时请求被放行且少计rate-limit-write-degraded。对配额可接受但要知道它不是硬上限使用onlyCountSuccess: true被拒绝的购买不支持的资源、已驻留、Buzz 不足不应烧掉金卡用户的每日额度。resourceLoadRateLimits数组src/server/routers/resource-load.router.ts展示了完整配置每日行是权益套餐包含什么每小时行是集群的扁平、无套餐可豁免两者在同一个sharedKey: resource-load:submit上组合。同一sharedKey必须应用到生成提交路径否则通过 txt2img 隐式触发的 prepare 会完全绕过上限——当前上限对直接生成而非按按钮的人只是装饰。Phase 1.5审核测试页构建计划之外的产物是为了在 Phase 2 存在之前就能端到端驱动管道。✅/moderator/resource-load——requireModerator加resourceLoad旗标提交模型版本 id在提交前解析出名称、AIR、大小、可用性、是否可生成/有权重估算按钮在原因已知时禁用并显示原因而不是提交时才失败编排器报价为零时估算自称未定价来自持久化 store 的等待中列表带实时进度与停止关注集群队列每 15 秒轮询有实时信号进度时优先采用通过买家自己的信号频道接收实时进度⚠️ 审核者豁免rateLimit()此页完全不检验 C10。✅跟踪与通知—— src/store/resource-load.store.ts持久化、自排空、48 小时上限与ResourceLoadDrain挂载在AppHeader任何带resourceLoad旗标的已登录用户都会在下次落地页面时收到已完成加载的报告toast 需手动关闭。⬜此页之外还没有任何入口能创建关注store 支持kind: watching且 drain 会报告它但创建它的按钮是模型版本页上的 C5 任务——旁观者通知已构建但不可达。客户端 store 的排空语义源码级resourceLoadDrainVerdict纯函数可在无浏览器环境下测试在每次页面加载时对每个条目判定available完成toast 后移除版本缺失移除loading或带位置的在队列中保留其余移除无在途加载。每一条目都必须能离开是关键失败的加载与完成后被驱逐的加载都会读回unavailable与排队中无法区分因此RESOURCE_LOAD_EXPIRY_MS 48h是必须的——它匹配驻留策略但上限不得吞掉好结果——加载在上限之后完成仍要报告。track重新跟踪时保留原始requestedAt防止每次访问刷新让条目活过自己的截止时间。Phase 1.6覆盖率变更由 Phase 0 在 2026-09-08 的答案产生。规则、审计与每个测量数字都在 docs/features/paid-model-loading-coverage.md。新的覆盖率视图GenerationCoverageNext✅与GenerationCoverage并排的新视图迁移 packages/civitai-db-schema/prisma/migrations/20260908120000_generation_coverage_next/migration.sql 创建GenerationCoverageNext2026-09-08 已应用到生产。 不命名为GenerationCoverage2该名字在生产中已作为早期过期实验存在CREATE OR REPLACE会静默覆盖它。刻意不加入schema.full.prisma——切换时用新视图体替换GenerationCoverage自身并删除该视图Prisma 模型永不变。三分支无加载文件已覆盖、永不被加载、在EcosystemCheckpoints中且有加载文件、以及GenerationBaseModel基模型上的检查点且有加载文件。LORA/TI/VAE/LoCon/DoRA/Upscaler 分支不变。✅ 去掉CoveredCheckpoint合取项允许Diffusers但保持 Core ML 与 ONNX 排除数字见覆盖率文档。✅检查点必须有 SafeTensor 权重文件迁移20260909180000_generation_coverage_next_safetensor_checkpoints2026-09-09收窄了 09-08 的视图Diffusers 对除检查点外的所有类型仍可加载CoveredCheckpoint以析取项回归、豁免 6 个驻留拍卖的版本。已编写、尚未应用到任何环境。⬜ 保留EcosystemCheckpoints—— 63 个检查点默认值中有 62 个依赖它。✅ 与生产对比2026-09-08——当时无任何覆盖损失。⬜ 应用 SafeTensor 迁移后 2,242 个已覆盖检查点失去覆盖33,811 → 31,569其中 834 个有生成历史6.5M 生命周期生成量。这是收窄没有安全窗口——应在covered的读者就绪时再应用。关闭条件应用到生产且已覆盖检查点计数读数为 31,569。覆盖率数字2026-09-08 同一查询测出GenerationCoverageGenerationCoverageNext已覆盖检查点63833,796全部类型已覆盖行899,553933,38633,158 检查点、33,833 行。两者增量不同是因为从排除格式中移除Diffusers惠及所有类型而非仅检查点——约 675 行新增为 LoRA 等。⚠️514 不是已覆盖检查点数它是CoveredCheckpoint拍卖名单的行数今天有 638 个版本以检查点身份被覆盖因为EcosystemCheckpoints也贡献。加载器群体分桶EcosystemCheckpoints125 个A 类 51 个无加载文件 → 永不加载B 类 74 个走加载器社区检查点 33,792 个A 类 123B 类 33,669——约33,743 个可加载检查点对比拍卖今天覆盖的 514 个。许可门禁零个已覆盖版本缺少RentCivit两种方式验证逐分支 端到端对视图899,068 已覆盖行、0 无许可。视图有两条不检查许可的分支——EcosystemCheckpoints成员与usageControl ExternalGeneration——但当前无任何版本借此逃逸这两分支覆盖的 143 个版本都持RentCivit。结论门禁基于覆盖而非直接测许可因为若某版本日后走旁路它仍保持正确且以继承规则取代第二份意见。单一canGenerate派生isGenerationEligible位于 packages/civitai-shared/src/generation-eligibility.tscovered !isGenerationDisabled(flags) isBaseModelGenerationSupported(baseModel, modelType)。四个调用点全部改指它no-divergent-can-generate-derivation守卫把isBaseModelGenerationSupported挡在src/之外。仅覆盖会多报 736 个版本33 个 (baseModel, type) 组合如 Wan Video LORA 337、Flux.1 D DoRA 102 等——见覆盖率文档。其他 Phase 1.6 条目✅加载 CTA 门控于isGenerationEligible且有可加载文件——不基于covered、不基于usageControl、不基于有任何文件。审核页已做服务端在resolveLoadable中强制C5/C6 添加公开 CTA 时复查。✅estimate与submit拒绝任何不在覆盖中的内容即RentCivit门——resolveLoadable读取GenerationCoverageNext。✅审计covered的每个现有读者23 个文件分类见覆盖率文档。分类 A生成门禁generation.service的canGenerate与resource-data.redis.ts在调度切换前必须精读B 搜索models.search-index.ts 与 models-update.tsC 展示各 controller/selector 与/api/v1/model-versions/mini/[id]——后者已切换因为编排器读它做CanGenerate实测版本 3040959 上旧视图会拒绝所有值得做的加载D 池与相邻消费者daily-challenge、App Blocks workflow.service、model.service.ts与caches.ts的模型列表过滤E 无操作getCheckpointGenerationCoverage零调用方死代码backfill-trained-model-permissions.ts的断言在新视图下仍真。⬜ 共享限流键与 C2 定价必须先于站点生成门读取新视图落地generation.service、resource-data.redis、搜索索引。放宽它们会让数万更多版本可生成而针对非驻留版本的生成提交会触发隐式 prepare——今天免费且无上限因为 C10 只守resourceLoad.submit。两个已读取GenerationCoverageNext的调用方刻意在此规则之外resource-load.service购买路径——旗标门控放宽正是其目的与/api/v1/model-versions/mini/[id]编排器CanGenerate读取无站点代码调用它。⬜决定搜索展示什么索引从covered派生canGenerate切换后会宣传数万更多模型可生成却无法表达需要先加载。✅检查公开 API 字段/api/v1/model-versions/mini/[id]现从GenerationCoverageNext选择covered2026-09-08 完成。⚠️ 该字段对第三方消费者的含义已改变未打旗标、未公告。⬜查看池消费者——每日挑战模型选择、App Blocks 工作流服务、model.service.ts与caches.ts的模型列表过滤。⬜删除getCheckpointGenerationCoverage与CoveredCheckpoint一起零调用方。⬜决定handle-auctions.ts的去留一旦无行被读取。36 个贴错标签的 API 模型36 个EcosystemCheckpoints版本是外部 API 模型其唯一文件是Training Data格式Other。决策Justin 2026-09-08将其usageControl设为ExternalGeneration。model-version.controller.ts拒绝非审核者设置该值因此是直接 DB 写或审核者操作。已验证安全ExternalGeneration视图分支要求已发布且非 POI36/36 均满足覆盖保持不变。Phase 2公开界面依赖 C14 决策C5 — 模型版本页Create 按钮下方对所有人可见而非仅购买者四种状态unsupported完全无 CTA订阅按钮让旁观者可采纳他人进行中的加载页面已订阅model-version:id——扩展而非新增第二个订阅。C6 — 生成器未加载 → 按大小定价提供付费加载下载中 → 自动订阅并对所选资源内联显示进度已加载 → 不变任意模型决策已定仅检查点。C6 现在依赖Phase 1.6落地而非决策。C7 — 导航栏指示器镜像 src/components/Resource/UploadTracker.tsx——同样的IndicatorPopover形状挂在AppHeader其旁先显示队列位置下载开始后显示进度按钮通向队列页localStoragestore挂载时轮询资源端点、丢弃已完成项、对其余重新订阅⚠️ popover 在 header 内需显式传withinPortal应用主题将Popover设为withinPortal: false否则会被裁剪。C8 — 队列页读取resourceLoad.getQueue服务端包装queryResources({ view: queue })轮询信号订阅仅限本用户等待的条目跨 provider 排名已在服务端完成不要重建⚠️ 游标是活重排列表上的整数偏移分页不稳定——保持take小每项服务端要两次 grain 调用。C9 — 加载完成通知发给购买者和每个在 C5 按过订阅的人需要NotificationCategory与设置条目——notification-settings-polarity守卫src/server/notifications/tests/钉住默认极性。Phase 3后果盯住驱逐指标C13 已暴露它但无人查看。首次公开加载前把它放上仪表盘——它是 Briant饥饿担忧的唯一仪器。关闭条件指标在某个有名者监看的仪表盘上。C11 — 退役拍卖在 868gtq1kt把 featured 从拍卖中拆出有答案前不划定范围——拍卖承担两个职责付费加载替换其一。约 89 个src/下文件涉及。CoveredCheckpoint冲突已通过将其从覆盖合取项移除Phase 1.6解决——拍卖任务不能再取消覆盖付费检查点它作为析取项存活、覆盖 6 个缺 SafeTensor 文件的驻留拍卖版本这些都不加载故不可能被付费过。剩余问题只是该任务是否继续写无人读取的行。编排器状态对照源码验证以下信息直接读自编排器仓库civitai-orchestrationmainat9306e7333而非 SDK。该提交已部署因此下面标记为已构建的一切都已上线。已构建并可工作事项状态GET /v2/resources?viewqueue已实现ResourcesController.QueryAsync合并每个启用 provider 的队列、按 AIR 去重、排名、分页。一个不可达 provider 降级为空贡献而非让调用失败。把各 provider 排名拍平成 1..n已在服务端完成客户端勿重建GET /v2/resources/{air}已实现在控制器层把availability拼接到ResourceInfo按资源做响应缓存四种可用状态与 SDK 类型完全一致ResourceAvailability.cs含queuePosition只存在于unavailableprepareResource作为工作流步骤存在——PrepareResourceStep含 handler、PrepareResourceJob与生命周期校验标记[Preview]非仅 recipe调用信号设计成立进度事件存在step:*已能接收已驻留时的实例成功handler 检查可用性资源available时不发 job——重复 prepare 免费且瞬间完成进度事件——比 SDK 暗示的更好卡在下载上的步骤会发布WorkflowStepEvent携带Preparation { Resource, QueuePosition, Progress, EtaSeconds }——正是 UI 需要的负载。刷新间隔10 秒PreparationRefreshInterval注释解释为何更紧无意义worker 本身大致以该速率上报资源成本。发布按变更去重、1% 进度粒度PreparationProgressPublishThreshold 0.01完整下载最多约 100 个事件。门控规则进度最差的 job 门控该步骤。step:preparing被刻意从 OpenAPI 枚举中隐藏WorkflowCallbackSchemaFilter显式从广告值中移除preparing与scheduled这就是生成 SDK 联合只列生命周期转换、让人以为功能缺失的原因。功能没缺只是未广告。用step:*订阅即可匹配包括Preparing在内的每个状态——分发测试是x.EventType is null || x.EventType event.StatusgetOrchestratorCallbacks已用step:*生成今天就在接收这些事件。K2 答复Koen 已把缺失事件类型补进规范未来civitai/client发布应携带类型。未构建 此表曾有一行称 48 小时保证不存在——那是错的且错在最昂贵的方向上它宣称产品头条特性缺失。机制位于civitai-spine-controller——本清单从未读过的仓库PinModelJob作为原定原语是遗留物Koen2026-09-04。唯一真实差距是定价。差距后果成本硬编码为零PrepareResourceHandler.CalculateCost返回{ Factors [], Fixed [] }其自身注释说两个集合都空即短路为零成本C2 不是配置开关——按大小缩放的定价函数尚未编写。?whatiftrue今天返回零而非价格CTA 没有数字可显示驻留——本清单未读的仓库此处无法验证civitai-spine-controller未在站点侧检出。记录的是 Koen 的答复DM2026-09-04而非读到的源码spine 控制器在驱逐资源前互相检查拒绝驱逐任何不足 48 小时驻留的资源除非另一个 spine 控制器持有它PrepareResourceJob的唯一职责是把资源送进 DC驱逐策略自此守护其生命周期ClusterAwareEvictionPolicy.csPinModelJob是遗留物——看都不用看⚠️ 无任何东西暴露资源 48 小时窗口何时结束——仍无倒计时可构建。值得知道的站点相关细节队列游标是整数偏移而非稳定游标排名每请求从实时 provider 状态重算队列变动时条目在页间移动。适合单首页勿构建假设稳定性的分页视图。take被钳制在1..500默认 100站点侧 schemasrc/server/schema/resource-load.schema.ts进一步限制为 1..100、默认 50。队列调用对每项fan-outGetInfoAsyncGetAvailabilityAsync——500 项一页就是 1,000 次 grain 调用。保持小页、温和轮询。PrepareResourceInput.OnInitializedAsync拒绝CanGenerate为 false 的资源抛ValidationException——这是编排器自己的覆盖门会在我们扣费前拒绝值得作为干净错误呈现而非 400。PrepareResourceJob有24 小时MaxTimeout与 2 分钟 claim 时长。以实测约 10 KB/s 带宽大型检查点可能触及该上限。GET /v2/resources需要Consumer角色DELETE需要Manager。站点的缓存击穿路径已用系统 token 做删除。回调url是任意字符串指向 signalsgroup/groups/model-version:{id}/signals/{message}是站点侧选择编排器无需任何东西——这就是旁观者订阅可在无 C4 端点的情况下工作的方式。但加载进度不是主题广播它去/users/{userId}/signals/因为编排器直发事件体、该体指名付费用户workflowId为userId-timestamp测试断言 URL 含/users/且不含/groups/。信号路径与通知形态信号路径与图像生成同构工作流 → 站点端点 → 信号服务 → 客户端。发送侧按用户发送与主题广播都在 src/server/orchestrator/orchestrator.utils.ts全部经 withSignals() 路由——未包裹的信号服务 fetch 正是 2026-05-30 事件循环级联事故的形态。订阅侧useSignalTopic(topic)src/components/Signals/SignalsProvider.tsx 的useSignalTopic按主题引用计数、自动 join/leave 组src/components/Model/ModelVersions/model-version.utils.ts 已订阅model-version:id因此站点可按模型版本 id 订阅下载而无需新工作流步骤。主题命名约定已存在SignalTopic.ModelVersion model-versionsrc/server/common/enums.ts。决策 1.4 纠正了早期设计加载回调曾指向model-version:id信号组让所有观看该模型的人收到进度。那会泄露信息编排器直发WorkflowStepEventworkflowId是userId-timestamp——组播会把谁付了款告诉每个观看者。回调现指向/users/{userId}/signals/旁观者得不到实时进度改为在就绪时被通知。不在 v1 范围内记录在案付费提升队列位置——若机器人军团击穿限流Justin 预期它会回归。搜索结果中的加载状态。模型何时可用的硬性保证——当时数据中心带宽约 10 KB/sLoRA 花了四小时。对到达时间不做承诺——这与到达后停留多久是不同问题决策 1.3。无主缺口真实工作但无任务、无负责人列出以便被决策而非被发现退款路径失败或永不完成的加载。已决策退款决策 1.2未决的是谁退——K3 问 Koen 编排器是否已做。PrepareResourceJob24 小时MaxTimeout加约 10 KB/s 带宽使这不是罕见路径。驻留显示驻留真实存在但无 API 报告资源 48 小时窗口何时结束没有可倒计时的东西。需要先向编排器提需求。构建顺序与已决策事项速查构建计划docs/features/paid-model-loading-build-plan.md给出四阶段顺序Phase A管道已构建resource-air.ts、schema、service、router、信号消息、回调构建器、resourceLoad旗标、/moderator/resource-load审核页→Phase B只读界面store、utils、ResourceLoadCard非购买态、ResourceLoadTracker、队列页——无购买路径故不依赖定价→Phase C购买服务端半成品已构建缺口是 CTA、干净呈现CanGenerate拒绝、以及 C2 定价→Phase DC9 通知、C11 拍卖退役。不构建清单同样明确不建队列排名算法、不建尺寸→价格表、不建驻留倒计时、搜索不加加载状态、v1 不做队列位置提升。已决策、勿重开摘要限流在站点侧而非编排器侧浏览器用localStorage保存正在关注并在每次页面加载排空48 小时过期保证每项都能离开购买的持久记录是编排器的工作流标签resource-load、用买家 token 查询不是 localStorage 也不是 Redis进度信号去买家自己的频道旁观者无实时进度下次访问时被告知就绪真正 API 级通知是 Phase 2 目标进度显示在三处导航栏、模型版本页 Create 下方、生成器所选资源旁观者可订阅他人进行中的加载加载状态与队列是公开读取界面按原样承诺 48 小时加载只针对检查点CoveredCheckpoint停止门控生成只有GenerationBaseModel中的基模型可加载检查点需SafeTensor权重文件2026-09-09无文件 API 模型永不加载GGUF/PickleTensor/Diffusers 检查点得到不同拒绝文案——UNLOADABLE_MESSAGES在 src/server/schema/resource-load.schema.ts 是两者的单一来源永不完成的加载退款购买路径拒绝任何不在GenerationCoverageNext中的内容由isGenerationEligible组合生态类型支持每日上限必须覆盖隐式路径对非驻留资源的生成提交——同一配额而非第二配额免费档上线即 0/天并发 prepare 同一资源无需特殊处理。阻塞依赖C2定价与启用收费阻塞所有公开暴露——加载当前在编排器侧免费C2 前上线站点界面等于送出集群驻留。C14demo 客户端决策门控 C5–C8——Briant 主张先向高级用户演示Justin 主张小型独立第一方应用端到端驱动 Koen 的 API 或仅审核者上线Justin 拥有该决策。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考