展开本页目录
开始前准备什么
- 本机ComfyUI与对应家族的权重;按下方实测模型来源和SHA核对。
- 保存报错与原始工作流
- 辨认错误属于哪一层
- 扫描实际模型目录
- 检查共享路径是否生效
- 重新选择存在的下拉项
- 校验后再做最小测试
- 记录根因和修复材料
2026-10-24 核验材料;实际执行范围、结果与限制见下方记录。
补充:原有练习资料与下载
含 UI/单独 API JSON、原输入、模型清单、校验脚本和真实负例;无权重及本次推理输出。
按官方 0.4 格式整理;仅结构核验,需在你的目标版本实际导入。
从本页工作流 Loader 字段读取;按官方来源准备兼容权重。
空结果栏,供你填写实际输出与故障;不预填虚构成功结果。
真实操作、成品与核验记录
保留原有缺 checkpoint 的 400 负例后,从 Comfy Org 官方归档取得 SD1.5 FP16 权重,放入 models/checkpoints,刷新实际列表,再通过成功 history 取得 384×384 扩散生成图。出现文件名只是中间检查,成功推理才是恢复结果。
· 按下列具体任务验收API或本地执行;产品原生功能、文件成功与内容质检分别说明。
- 运行环境
- ComfyUI 0.42.0 / macOS CPU / 官方SD1.5及LCM权重
1. 定位模型类别与错误字段
对照旧负例 ckpt_name,不把缺 checkpoint 与缺节点或 LoRA 混为一谈。
2. 安装并核对原始权重
下载固定 revision 的官方 FP16 safetensors,记录 2,132,696,762 字节与 SHA;不把网页 HTML 重命名为模型。
3. 实际执行生成与下载
同一ComfyUI加载实际基模、CLIP和VAE,以Euler/normal、20步、cfg=7、seed=20261024生成384×384图片,核对成功history与PNG。
这次实际得到什么
- 已真正加载基模并运行扩散,原来的“仅验证下拉框”限制已解除。




使用这份结果时注意
- SD1.5是兼容性教学基模,384×384用于加载恢复验收;不以低分辨率对照宣称产品图质量。
- ComfyUI 官方:缺模型、路径与架构不匹配
- ComfyUI 官方:服务端路由与队列协议
- 固定版本原生 SaveImage / LoadImage / LoRA 源码
- Comfy Org:基模归档与目录
- 官方LCM-LoRA权重说明
- ComfyUI官方LCM调度示例
- apizt当前模型、权限与价格
按完整错误分流
| 报错或现象 | 先检查 | 对应动作 |
|---|---|---|
| ckpt_name not in [] | checkpoint是否在models/checkpoints | 确认文件与路径,重新选择Loader |
| LoRA下拉为空 | models/loras与模型列表刷新 | 选择正确类别的权重 |
| Node type missing | 自定义节点是否安装 | 转到缺节点排查 |
| mat1/mat2或通道维度不符 | 模型与VAE/CLIP/LoRA家族 | 换回兼容组合 |
| CUDA out of memory | 显存、尺寸与batch | 降低预算并按OOM排查 |
- 报错或现象
- ckpt_name not in []
- 先检查
- checkpoint是否在models/checkpoints
- 对应动作
- 确认文件与路径,重新选择Loader
- 报错或现象
- LoRA下拉为空
- 先检查
- models/loras与模型列表刷新
- 对应动作
- 选择正确类别的权重
- 报错或现象
- Node type missing
- 先检查
- 自定义节点是否安装
- 对应动作
- 转到缺节点排查
- 报错或现象
- mat1/mat2或通道维度不符
- 先检查
- 模型与VAE/CLIP/LoRA家族
- 对应动作
- 换回兼容组合
- 报错或现象
- CUDA out of memory
- 先检查
- 显存、尺寸与batch
- 对应动作
- 降低预算并按OOM排查
1. 保存报错与原始工作流
下载 error-log.txt 阅读教学样本,再把自己的完整错误另存。定位 Prompt outputs failed validation 和 ckpt_name 的上下文,记录 ComfyUI 版本;教学日志明确不是本站真实推理产生。
2. 辨认错误属于哪一层
Value not in list 指向 Loader 选项或字段值;Node type missing 指向节点安装;tensor shape 错误更可能是家族组合。先分层,再处理目录,不用一个“重装”覆盖所有原因。
3. 扫描实际模型目录
运行 python file_inventory.py /你的/ComfyUI/models,把输出写入自己的 inventory.json。检查 checkpoint 是否在正确类别、是否多了一层压缩包目录、是否真是权重文件。脚本只读扫描,不加载模型。
4. 检查共享路径是否生效
如果文件在另一磁盘,核对 extra_model_paths.yaml 及启动日志;相对目录需基于实际 base_path。确保运行的是正在检查的 ComfyUI 实例,而非旧端口或另一套安装。
5. 重新选择存在的下拉项
重启或按当前版本刷新模型列表,再回到 Load Checkpoint 下拉选择实际模型。工作流可能保留作者机器上的旧名,必须重新选值;不能只把文件随意改成旧名来绕过家族核对。
6. 校验后再做最小测试
先导出最终 JSON 并运行结构检查,再用单图小尺寸任务核对加载是否通过。若进入采样后出现 shape 或 OOM,则另按对应问题排查,记录本次已解决的层级。
7. 记录根因和修复材料
保留错误、目录快照、修复后的 Loader 值和版本。缺模型修复意味着程序读到相应文件,并不自动表示模型效果、性能或商业使用权限均已验证。
8. 下载工作流、输入和结构检查
完整包包含官方来源 JSON、按本页整理的 UI workflow、单独的 API prompt、真实输入 PNG、模型与参数清单、空验收表、故障负样本和离线脚本。先执行 python check.py,再在自己的 ComfyUI 安装中导入与实际运行。包内权重未下载,结构检查不能替代前端兼容与推理验收。
怎样确认已经完成
- 故障按缺模型、缺节点、架构与显存分层,不混用修复步骤。
- 目录清单来自实际扫描且 Loader 重新选择真实下拉项。
- 最小运行后保存真实日志,教学错误样本不冒充本机故障。
常见问题
ComfyUI缺模型这次真实做到了什么?
保留原有缺 checkpoint 的 400 负例后,从 Comfy Org 官方归档取得 SD1.5 FP16 权重,放入 models/checkpoints,刷新实际列表,再通过成功 history 取得 384×384 扩散生成图。出现文件名只是中间检查,成功推理才是恢复结果。
是否需要登录第三方平台?
本页主流程按上方实测中的apizt API或本地工具执行。SD1.5是兼容性教学基模,384×384用于加载恢复验收;不以低分辨率对照宣称产品图质量。

