ComfyUI 合作节点返回 429：区分工作流并发、调用并发与在途额度

先确认计算发生在哪里 Partner Nodes 通过 API 调用外部托管模型，可以与本地节点组合。于是同一张工作流中既可能有本机计算，也可能有账户级远程请求限制。遇到失败先定位具体节点与响应，不要把远程拒绝直接解释为本地显存不足。 两种并发限制独立存在 官方说明，Comfy Cloud 的工作流任务并发与 Partner Node 调用并发是不同限制，实际吞吐受先触达的一项约束。某条工作流同时发出多个合作节点请求时，工作流数量少也可能占满调用槽位。反过来，拥有空闲调用槽位也不说明 Cloud 还能再启动一条任务。 长任务为何容易占住容量 一个合作节点调用从请求接受到供应商返回结果期间都会占用槽位，视频或 3D 生成可能持续较久。已完成请求释放槽位，因此调度应关注“仍在运行多少个”，而不是只统计今天发送了多少条请求。编辑建议为每次调用保存状态和完成时间，避免把已提交当成已完成。 429 还有第二种原因 所核对文档还列出在途调用占用金额的限制，与同时运行的数量分别约束。即便还有并发槽位，高成本请求仍可能因剩余额度不足被拒绝。相关响应带有 X-Committed-Spend-* 头部；剩余额度为正，也不代表足够容纳下一次请求。 把在途金额换算清楚 响应头以整数美分表示已承诺支出。假设某次测试观察到 Remaining=150，而下一项请求需要 200 美分，即使还有空闲槽位，也可能因在途金额不足而被拒绝。这里的金额是自拟算例，不代表真实账户档位或模型价格。它说明“剩余为正”和“足够接纳下一项”不能等同。 这类余量是正在运行的请求占用上限，不是可消费积分余额，也不是决定账户层级的历史累计付费。三项分别记录，才能判断是等待已有任务完成就会缓解，还是需要处理账户余额。当前文档还区分部分高成本模型的并发限制，不能从一类模型的空闲情况推断另一类请求一定能接受。 响应头用于观察，不是精确时钟 X-Concurrency-* 提供当时的并发情况，但文档提醒这些值是尽力提供的观测信息，不宜当成精确调度信号。应用应处理实际接受或拒绝结果，并记录必要响应信息，而不是读取一次剩余值后同时发出一大批请求。 把账户问题与暂时繁忙分开 积分不足、访问被禁用与调用并发达到上限的处理方式不同。官方指出访问被禁用返回 403，余额也独立于并发槽位。重试前应先分类；某个节点或客户端是否自动重试，需要检查其实际行为，不应一律假定。 验收与容量安排 账户限额以当前页面与响应为准。建议先用小规模任务观察运行时间、失败类别和完成后的槽位释放，再设定队列与等待边界。只有清楚是哪一项限制在生效，才能判断下一步是调整调度、处理账户状态还是联系服务支持。 重试时保留原始任务身份 把本地待提交、远程已接受、远程运行中和已完成分别记录。明确收到限流拒绝的请求可以按策略稍后再提交；请求超时但不知道是否被接受时，应先查已获得的任务标识或节点运行状态，避免重复生成并消耗积分。界面反复点击运行是否创建新任务，也应作为客户端行为单独验证。 对于同一账户下的多条工作流，尽量用共同的调度记录观察在途数量；每条工作流只看自己的请求，容易误以为账户还有大量空位。等待和重试需要有上限，持续 403 或余额问题应进入明确失败状态，不能靠延长队列隐藏。

本篇涉及的工具1

ComfyUI官网

编排外部模型调用并观察账户限制

适合场景

在 ComfyUI 中批量调用外部图像、视频或 3D 模型的工作流维护人员。

需要留意

任务并发、调用并发、在途额度与积分余额独立核对。

了解项目 访问官网