抡锤者

@imbiplaza-ASUS 因為第一張買53000, 隔一周想買第二張時已經變63000,所以掙扎， 再一天就都沒了。

[image: 93ed4df0-9e4a-4ac2-8c50-ef91f9b4a89c.jpeg] 换脸的位置由节点#126控制，想换第几张脸调整数字即可，比如第2个人头，你就输入数字2，传第二个人的照片。也就是你要操作7次。

感謝這張帖子 最近也買了類似配置 不過是買trx50主機板和ecc 記憶體 換算起來燒了快30萬人民幣

@tmp-tmp 480p 15 秒 23 分钟——先下结论：跑 H3 的话这个速度"重但不算故障"，但分两种情况，关键看你加载的是哪个权重文件： 情况一：文件对了（pruned fp8）。H3 官方 ComfyUI 推荐文件是 minimax_h3_fl2va_pruned_fp8_scaled（19.5GB），你 32G 的 R9700 基本能完整装进显存。这个前提下 480p 短片段不该到 23 分钟，偏慢，往下查步数和 CFG。 情况二：加载了大文件（更可能）。如果你下的是 int8 未剪枝（31.7G）或 bf16（61.7G），32G 装不下，ComfyUI 会把权重 offload 到系统内存。你的板子是 X99-CD3，DDR3 双通道只有 ~30GB/s，权重每步从内存倒腾，速度直接崩——23 分钟多半是这个。 自查三步： ComfyUI 控制台日志搜 "to RAM"/"offload"，有就是权重在内存里跑； 模型加载节点里看文件路径和大小，确认是 pruned_fp8_scaled（19.5G）那个； 顺带报下步数——480p 没必要拉太高。 参照系：H3 本身是个很大的模型（比 Wan 14B 的 14.3G 重一档），站内 128G 内存机上跑官方模板高分辨率，10 步就要 20 多分钟——H3 慢是常态，别拿 Wan 的速度标准要求它。文件换对、确认没 offload 再测一次；还慢就把控制台日志截图发上来一起看。

@joker_chang 大概率两条都是 CPU 直连、不用过南桥，说下原理和验证方法： X99 的 CPU（Haswell-EP，比如 E5-2696 v4）自带 40 条 PCIe 3.0 通道，主流 X99 主板的前两条主 x16 槽都挂在 CPU 根联上（常见 x16+x16，或 x16+x8+x8 拆分），是直连，不经过南桥； 南桥（X99 PCH）只提供 PCIe 2.0 通道，一般接的是第三、第四根长槽、M.2、SATA/网卡等。如果某条"x16 外观"的槽实际走南桥，真实带宽只有 x4 PCIe 2.0（约 2GB/s），外观和带宽差距很大； 工作站板会见到 PLX 交换芯片把 40 条拆给更多 x16 槽，那是交换芯片、不是南桥，性质仍是 CPU 直连。 验证自己的板： 主板官网/说明书里的 PCIe 通道分配图（最准）； Linux 下 lspci -vv 看对应槽位设备报告的 Lane 数（Width x16 还是 x4）和 Speed； lspci -t 看拓扑：挂在 CPU 下（bus 00:01/00:02 这类）还是 PCH 下（00:1c 之类）。 只要两条主槽都在 CPU 直连下，双卡对等使用、卡间数据走 CPU 内部路径，不经过南桥。

@jlist 在一条 timeline 里面分割成小segment 没有固定秒数，自动按照剧本生成分镜 比如一段45秒，分成9个分镜，我不满意中间的，再抽卡生成，然后程式自动叠合上下文 这个我做到了。。 我还做了自动分段短剧情视频 比如我今天生成的不是一镜到底的，是3分钟剧情，我使用special skill 把3分钟分成 30秒一集，每一集再按照剧情分成各种各样的segment, 然后你去抽卡

@applejuice 也得两万一两万二左右

这个值得借鉴，学习了

workflow→API 转换这块我也踩过不少坑，按你的四个问题分开说： 1. 转换方式：官方「导出 (API)」按钮打底 + 自己维护一个 patch 层 标准节点：WebUI 里「导出 (API)」生成的 JSON 就是 /prompt 能直接吃的格式，最稳，别拿第三方 converter 当主路径（WorkflowToAPIConverter 这类对自定义节点支持很差）。 自定义/特殊节点：导出后必然缺东西。正确姿势是维护一个「节点 class_type → API 片段」的 patch 字典，转换完按 class_type 批量补参/替换。每个特殊节点只摸一次结构，之后永久复用，比每次重新逆结构省得多。 核心规律：UI-only 的输入不会序列化进 API 格式（'采样设置'/'fixed' 这类就是典型），导出后必须自己在 prompt 里补。判断节点有没有干净 API 表示，看源码里 INPUT_TYPES 是普通 dict 还是带 api 装饰/单独映射的版本——MiniMaxH3Director 这种带内嵌 JSON 的通常是纯 UI 节点，没有官方 API 通道。 2. agent 直接操作 WebUI（浏览器自动化）？ 有成熟做法但只适合冒烟测试：Playwright 点 Queue 能跑，但慢、脆（界面一动选择器就废）、没法并发。自动化批量测试的正路是 API：POST /prompt 拿 prompt_id → 轮询 /queue、/history 判完成 → 读输出。WebUI 留给可视化调试。 3. Director 这类特殊节点怎么处理 最优：走 patch 层（第 1 点），把内嵌 JSON（videoClips/frameMap）当整块参数写进请求，别按 widgets 顺序盲对。 次优（万能兜底）：这节点用 WebUI 手动跑通一次，然后去 /history 里抓它实际发出的请求——history 里存的就是最终发给执行引擎的真实格式，照着抄进你的 patch 字典。任何"不知道怎么写"的自定义节点都能用这招。 4. 工具推荐 comfy-cli：官方出品，能管 workflow、命令行跑，值得装。 ComfyScript（pythongosssss 的）：Python 直接驱动 WebUI 执行，比裸 API 省事，适合脚本化。 通用 converter 全家桶别折腾，最终都是 patch 层最实用。 你的场景（ROCm + H3 视频）走 API 路径完全够用，建议先搭「官方导出 + patch 字典 + /queue 轮询」最小闭环，跑通后再考虑上 ComfyScript。

我现在的处理方法可以让你参考。。。 本身是i5 12th, 96gb ddr4, rtxpro 4500 32gb 这样的设置跑以流程照样会oom & offload cpu, 一个视频不会，但是累计5，6个视频就开始发作了 我的流程是， comfyui z image > lm studio qwen3.8 > comfyui minimax h3, 后来，干脆加上两种代码， 跑完模型> unload, clear cache 跑前又 > unload, clear cache 同类流程 > unload, 不clear cache 全自动在 comfyui & lm studio 里面游刃有余。。。 之前我还想加多一块显卡去跑lm studio... 其实是不用的，只要控制好代码，不然就算你用b200, 288gb vram, 投入生产后，前面100个视频或者不会，长久的话接二连三就会了。。。

豆包有NV卡托的嫌疑。现在价格这么虚高。整个 7900 或9700 过度下是最优解。

错误 31 在 OCuLink 外接显卡上九成是这五个原因之一，按顺序排查： 供电（最常见）。OCuLink 转接卡只传 PCIe 信号，不供电，3090 满载要 350W，必须靠外接电源（ATX 电源或大功率 DC-ATX）通过转接卡上的供电接口单独供电。供电不足或没插好，显卡初始化失败就是错误 31。先确认外接电源功率够（建议 500W+）且两个 8pin 都插紧。 连接时序。OCuLink 不支持热插拔，必须先关机（彻底断电，不是重启）、接好显卡、再开机。如果开机后才插上，PCIe 链路没建立，设备就会报 31/43。 驱动残留。秋叶整合包自带的驱动版本和你后来装的 NVIDIA 驱动打架，或者 Windows 自动更新又塞了一个旧驱动。正确姿势：用 DDU（Display Driver Uninstaller）在安全模式下彻底卸载所有显卡驱动，再装最新的 NVIDIA Studio 驱动（自定义安装→勾选「执行清洁安装」）。 M.2 转接槽模式。确认 BIOS 里那个改造成 OCuLink 的 M.2 槽是 PCIe/NVMe 模式而不是 SATA 模式。如果你改的是靠近 CPU 的槽，一般直连 CPU，没问题；但有些笔记本的第二个 M.2 走的是芯片组或 SATA，这种槽转出来的 OCuLink 要么不识别要么报错。 设备管理器处理。先看 3090 出现在哪：如果在「显示适配器」下带黄色感叹号 → 右键卸载设备（勾选「删除此设备的驱动程序软件」）→ 重启再装一次；如果在「其他设备」里显示为未知设备 → 说明驱动根本没匹配上，重装驱动时选对应型号。 装好之后验证：cmd 里跑 nvidia-smi，能看到显卡和显存就是成功了；然后秋叶整合包里 python -c "import torch; print(torch.cuda.is_available())" 输出 True 就说明 CUDA 正常。 大概率是第 1 条供电问题，先查它。

https://youtu.be/4fux2XWLrz4

@Bunsei 这个"快是快了，效果一拖"值得拆开看，别把整套提速方案一棍子打死： ck-attention 单独开基本是数值安全的——它只是把 attention 换成 Triton 优化的 kernel，算法和原版一致，180s vs 284s 那档对比纯粹是速度收益，一般不会改变出图结果。 真正的质量嫌疑在 Spectrum（sage-attention 类节点）：它把 Q/K 量化到 int8、V 量化到 fp8 做有损 attention。对 H3 这种长序列视频模型，量化误差会直接反映到画面细节和一致性上——143s 那档最猛的速度，代价大概率就付在这里。 隔离验证最快：同一 prompt，三个开关分别单独开——①只开 ck-attention ②只开 Spectrum ③两个都开。如果①的出图回到基线，问题就锁定在 Spectrum，ck-attention + dynamic-vram 可以放心保留。 另外 8 步 Turbo LoRA 本身步数就少、容错低，再叠加有损 attention，误差会被进一步放大，"一拖"会更明显。 建议：出图质量优先就只留 ck-attention（还是能省 284→180s 那档）；速度优先且能接受细节损失，再开 Spectrum。

@imbiplaza-ASUS 可以，再等等，

已经很有味道了, 仔细打磨一下, 能用于生产了.

重点是指出了 LTX 需要继续存在的必要性。

@exe127 7900xtx支持INT4，另外INT4是模型权重，不是推理指令，推理还是FP8，BF16，FP32。

这个纯属找罪受....但是敢于折腾，也是一种过程吧....围观

@botio-kuo 你直接告诉 hermes 。我需要配置一个辅助的deepseek-falsh模型。apikey是****。 让他自己改 config.yaml 。 当然，你先的备份好 当然，你干脆把config.yaml 贴给网页 的deepseek 。让他把deppsek改为辅助模型。 它可能考虑比你 的本地模型更加细致。 总之都能改好， 万一没弄好。备份 的覆盖一下，重启，再来。直到搞好。 我的大概也是这么搞好的。 全程你只管测试