我一开始以为，这会是一个很快的问题：把本地模板索引和模型数据库做一次查询，就能知道哪些文生图、图生图、视频、音频和 3D 任务可以运行。用户的目标也很明确，希望把本地能处理的类型都实际试一遍。看起来，剩下的只是筛选和提交。
但第一次结果出来以后，我发现“本地可用”这 4 个字比想象中重。模板标题里写着某个模型，不代表运行时真的注册了所需节点；数据库里有一个相似名字，也不代表本地文件正好是这个版本；文件即使齐全，还要看这台机器能不能在加载时承受它的峰值内存。本地模型筛选不是查一个名字，而是把一条运行链逐层对上。
看起来像缺失，实际是索引误报
这次最先遇到的异常，是模板索引报告了大量缺失节点。数量多到让人直觉上怀疑：是不是本地运行环境根本没有准备好，或者这些模板大部分都依赖额外组件？如果按这个结果直接筛选，很多候选会被提前排除。
继续看节点结构后，问题变得具体了。索引里混进了用于界面整理的虚拟节点，也把子图本身当成了一个普通节点。它们出现在数据库字段里，却不是运行时需要单独安装的自定义节点。真正的节点藏在子图内部，必须先展开，再重新计算依赖。
这件事让我重新意识到，数据表里的“缺少”不一定等于运行时的“缺少”。如果不处理这个层级差异，后面会导致两种错误：一方面把本来能跑的模板误判为不可用，另一方面为了填补虚假的缺口去下载无关组件。筛选速度越快，错误扩散得反而越快。
重新展开子图、过滤界面虚拟节点以后，结果完全变了：本地候选里不再有缺失自定义节点的模板。这个结果并不是说所有模板都能运行，而是把第一层误报清掉了，终于可以继续问真正的问题。
模板名字只说明意图
最容易误判的捷径，就是按模板标题或数据库里的模型名直接下结论。标题通常告诉我作者想完成什么任务，却没有完整告诉我运行时要加载哪些节点、哪些编码器、哪个变体和哪一种精度。一个名字相同或相近的模型，可能对应不同的目录、格式和权重组合。
我没有把“节点齐全”直接当成“模板可跑”，是因为节点只是执行图的骨架。实际运行还需要把图里的节点类型交给当前运行时的节点注册表核对。注册表回答的是更接近现场的问题：这个环境现在到底认识哪些节点，它们能不能被加载，而不是索引文件曾经记录过什么。
这一层对模板分类也很重要。有些模板使用合作伙伴或云端接口节点，即使标题里写的是视频或图像任务，也不属于完全本地运行。它们和本地开源模板应该分开统计，否则“候选数量”会显得很大，真正能在本机完成的数量却被夸大。
模板标题描述的是任务意图，运行时注册表描述的才是当前环境能执行的节点事实。
所以第一层筛选应该是：展开子图，去掉虚拟节点，再用运行时注册表核对实际节点。只有这一步通过，才值得进入模型文件对账；否则连依赖清单都可能是假的。
模型文件还要逐项对账
节点通过以后，我继续把模板声明的模型需求和本地文件清单逐项比较。这里又出现了一个容易被名字遮住的差异：本地已经有某个系列的模型，不等于模板所需的那一个变体就在本地。可能差在量化方式、精度、文本编码器、VAE，甚至只是文件所在的角色不同。
这次对账后，文生图可以直接使用已有的图像模型，图生图也能沿用同一套基础模型。文生视频则需要把模板里的文本编码器选择调整为本地已有的精度版本。音频和 3D 当时还各有缺口，分别需要补充对应文件。它们不是“名字搜到了”就自动变成 READY，而是要把每一个文件放回它在工作流里的位置。
我更愿意把这一步看成装配检查。模板是装配图，节点是接口，模型文件是零件。零件数量够，不代表规格相同；规格相同，也不代表放在正确接口上。只有把需求、变体和本地文件逐项对齐，才有资格说“模型文件齐全”。
如果跳过对账，最容易出现的后果不是立刻报错，而是提交以后才发现某个下拉项无法匹配，或者运行到中途才因编码器、VAE 不对而失败。那时已经占用了队列和内存，失败信息也更难判断到底是模板问题还是环境问题。
能加载，不等于值得硬试
最后一层是内存预算，也是这次最关键的取舍。某个重型图生视频方案的权重合计约 61GB，而机器统一内存约 64GB。只看硬盘目录，它像是已经准备好了；只看模型名字，它也像是最符合目标的方案。但加载时还需要运行时、缓存和中间张量，不能把 64GB 当成可全部分配的容量。
当模型权重已经贴近整机内存上限时，“试试看”不是中性动作，而是在拿共享运行环境赌一次崩溃。
这次我选择不硬试，是因为它的失败信息量很低：即使最终报错，也很难证明是模型、精度还是并发导致；如果直接触发内存不足，还可能把后端一起打掉，影响正在排队的其他任务。相比之下，更小的备选模型虽然画面能力不一定相同，却能在预算内完成同一类图生视频试跑。
实际结果印证了这个判断。最后 6 类任务各自都有 1 个实际产物，但耗时和并发风险不同。图像、视频、音频和 3D 的成功，并不能反推重模型也应该继续尝试；一次成功证明的是某条配置链跑通，不是整台机器对所有候选都具备余量。
这件事也让我看到“并发”是预算的一部分。队列可以串行执行，不代表多个大模型同时加载是安全的。即使单个任务在纸面上没有超过内存上限，两个任务的加载峰值叠加，也可能让后端崩溃。忽略这一点，模型筛选就只是在算静态文件大小，没有算真实运行成本。
一条可复用的筛选流程
现在回头看，这次真正形成的方法不是某个数据库查询，而是 4 层判定。第 1 层展开模板和子图，过滤 UI 虚拟节点，得到真实执行节点；第 2 层对照运行时节点注册表，确认当前环境认识这些节点；第 3 层把模型需求和本地文件按角色、版本、精度逐项对账；第 4 层估算加载峰值、运行时余量和并发风险。
这 4 层不能随意合并。第 1 层解决的是结构误报，第 2 层解决的是环境事实，第 3 层解决的是文件匹配，第 4 层解决的是资源边界。前一层没有过，后一层的结论就没有稳定基础。尤其不能因为数据库查询很快，就跳过需要理解结构和变体的部分。
我会把结果分成 3 类，而不是只给一个能跑或不能跑：可以直接试跑的，经过小幅替换或补齐后可跑的，理论上匹配但超过当前资源预算的。第 3 类应该主动切备选，而不是留在“以后再试”的模糊清单里。筛选的价值不只是找出能跑的模型，也包括尽早排除低信息量、 高风险的失败。
这套方法可以复用到任何本地 AI 工作流。换成别的图像、视频、音频或 3D 框架，字段名字可能不同，但判断顺序不会变：先确认图的真实结构，再确认运行时能力，再确认文件和版本，最后确认机器负载。这样得到的结论，才是对“现在这台机器能不能完成这项任务”的回答。
下次我会怎么做
下次再遇到“把本地模型都试一遍”的要求，我会先把范围拆成任务类型和资源预算，而不是先看模板标题。模板入库后，第一件事是做子图展开和虚拟节点过滤；随后保存运行时注册表快照，避免把索引记录误当成当前能力。
模型清单会按组件逐项对账，并明确哪些只是换一个本地变体，哪些必须补文件。对每个候选，我还会提前记录权重总量、预计峰值和是否允许与其他任务并发。只要静态预算已经说明它会把整机内存压到边缘，我就直接切换到更小的方案，把试跑机会留给能产生有效信息的配置。
这件事让我重新意识到，工具真正改变的不是查询速度，而是我们能不能把判断过程留下来。一个流程成熟的标志，不是它能把所有候选都提交一次，而是下一次筛选时，看到一个漂亮的名字，也知道还要往下追问 4 层：它展开后是什么，它在运行时注册了吗，它的文件变体对上了吗，它加载时真的有余量吗？