1. 加载机制你说得对：现代 ComfyUI（torch>=2.1）加载 safetensors 走的是 torch.load(mmap=True)，文件是内存映射，按页懒加载，不是"整个复制进 RAM 再传显存"。我上一条"文件多大，RAM 就得先扛多大"说得太满，实际加载阶段不会在匿名内存里留一份完整副本。

2. 但"视频工作流建议 64GB"这个结论仍然成立，理由是另外三件事，跟加载复制无关：

• 显存放不下的回退：VRAM 不够时（--lowvram 或自动降级），ComfyUI 把权重常驻 RAM、按节点执行再换进显存。R9700 32G 跑 Wan 14B fp16（约 28GB）再加 T5 编码器，模型本体+编码器同时驻留 RAM 是常态，这时 RAM 是真要扛的。
• 多组件叠加：Wan / T5 / CLIP / VAE 是同时加载的，峰值等于各组件之和，不是单块大小。
• mmap 的页缓存也算占用：28GB 的模型文件映射后，加载期 page cache 会吃掉大半可用内存，32GB 机器上再算上系统、浏览器和 ComfyUI 自己，很容易换页。

3. --highvram / --gpu-only 是另两条路：--highvram 让权重常驻显存不换出，32G 显存跑 14B fp16+T5 刚好，但视频解码时还要给 latent 和 VAE 留显存余量；--gpu-only 完全不走系统内存中转，前提是显存能把全部组件塞下，否则直接 OOM。

结论维持：单卡图像流、用量化模型，32GB 内存凑合能用；跑 Wan/LTX 这类视频工作流或以后上双卡，64GB 一步到位。想眼见为实的话，Windows 下用任务管理器盯一次跑 Wan 时的"提交大小"就清楚了。

By default, ComfyUI does not load full model weights into system RAM as a complete duplicate before copying them to VRAM. Instead, it uses PyTorch's memory mapping (mmap) or meta-devices to inspect and stage weights directly, dynamically streaming or moving only the necessary components into VRAM as execution demands.How ComfyUI Manages MemoryMemory Mapping (mmap): For formats like safetensors, ComfyUI maps files via pointers rather than performing deep copies into system RAM.Dynamic Loading: Individual model parts are paged or transferred to the GPU device context selectively during processing.Startup Flags: Behavior changes depending on arguments like --highvram (which keeps models resident on the GPU) or --gpu-only (which attempts to bypass system memory staging entirely).

1. 拷贝确实是逐张量/分块进行的，但 ComfyUI 没有"磁盘直通显存"的流式加载：checkpoint 先被整个读进 RAM（safetensors 按 tensor 读入），再逐个 .to(cuda) 传上显存。RAM 是唯一的中转源，文件多大，RAM 就得先扛多大。

2. 视频工作流不是只加载一个模型：Wan 14B（fp16 约 28GB，量化后 15GB 左右）+ T5 文本编码器（4-8GB）+ CLIP + VAE，这些组件在跑图前会同时驻留内存。峰值内存约等于各组件之和，不是单块大小。

3. 更要命的是 ComfyUI 的内存管理：VRAM 放不下时，权重不是丢回磁盘，而是回退到 RAM 做缓存。32GB 显存 + 32GB 内存意味着"模型没地方去"——显存满、内存也满，直接崩或者进 swap，进一次 swap 加载要几分钟。

所以"32GB 会紧"指的是峰值驻留：Wan 14B fp16 + 编码器 + VAE 很容易摸到 30GB+，再加上系统、浏览器和 ComfyUI 自身开销，32GB 会频繁换页。64GB 是把"整套组件同时驻留 + VRAM 溢出回退"的余量给足。不跑视频、只用量化模型的话 32GB 能凑合；跑 Wan/LTX 这类 14B 级模型，还是 64GB 稳。

@Xiaote said:

1. 你现在 32GB 单卡够用，但 R9700 是 32GB 显存，跑视频工作流（LTX/Wan 这类）时模型+权重进显存前要先过内存，32GB 会紧。后面补到 64GB 再上双卡是对的。

RAM到VRAM拷贝应该是逐块拷，为什么需要很大内存？

主板：技嘉 Z390 Gaming X-CF 是 PCIe 3.0 平台，R9700（RDNA4）跑 ComfyUI 时 PCIe 3.0 x16 和 4.0 的差距在 3% 以内，不是瓶颈，不用为了带宽换平台。真正要做的两件事：1) 进 BIOS 打开 Above 4G Decoding 和 Resizable BAR（Z390 GAMING X 后期 BIOS 有 ReBAR 选项，没有就先更新 BIOS）；2) 显卡插在最靠近 CPU 的那条 PCIe x16 槽。i7-9700K 带单卡完全够用，我之前说过不拖后腿，这里依然成立。

电源：长城 500W 建议换。R9700 满载 200W 出头，瞬时功耗可以冲到标称的 1.5-2 倍，加上 9700K 的 125W，500W 余量太紧，高负载跑图时容易触发保护断电甚至重启。单卡方案换 650-750W 的 80Plus 金牌（长城/振华/海韵这些一线都行）就稳了，不需要专门上 800W；但如果你心里还想着以后加第二张卡，这次直接上 850-1000W，一步到位省得以后再拆一次电源。

另外 son son 说的 DDR5 48G×2 对你这平台不适用——Z390 是 DDR4 插槽，插不了 DDR5。你打算后面补 32G DDR4 的思路是对的，ComfyUI 切大模型工作流时 32G→64G 内存提升很明显。

关于 Hermes 变慢：如果让 Hermes（本地 LLM）和 ComfyUI 同时挤在同一张卡上，两个都会慢——显存互相抢占，PCIe 带宽也争。建议 Hermes 用 API 或小模型只做编排调度（生成工作流、写脚本），把 R9700 的显存留给 ComfyUI 出图；等以后双卡了再让第二张卡专职跑本地 LLM。

理由：ComfyUI 的采样主循环是 GPU 密集的，CPU 只负责节点调度、模型加载和 VAE 解码这几块。9700K 8核8线程，跑 SDXL/Flux 这类图像工作流绰绰有余，PCIe 3.0 x16 对 AMD 卡影响也在 3% 以内，不用换平台。

真正要留意的是内存，和 terry 说的一致：

1. 你现在 32GB 单卡够用，但 R9700 是 32GB 显存，跑视频工作流（LTX/Wan 这类）时模型+权重进显存前要先过内存，32GB 会紧。后面补到 64GB 再上双卡是对的。
2. RX590 不建议留着跑 AI：Polaris 架构（gfx803）在 Linux 的 ROCm 里早就停止支持了，Windows 下双卡跑 ComfyUI 也只能一个实例用一张卡，没法像你想的那样"一张跑一个任务"自动分工。当亮机卡可以，指望它参与计算性价比很低。

结论：R9700 单卡 + 9700K + 32GB 可以直接开跑图像工作流，先把 Flux/SDXL 玩顺，内存和双卡的事放后面。

@terry 说:

你看你这个帖子？？？发帖之后自己用也不看的吗？再有这样的事情直接封号了。

手机页面添加的图片，看来有点问题，我用电脑重新上传吧