@jlist 你贴的 Gemini 解释和我上一条其实不冲突，是我说得不精确，修正一下：
加载机制你说得对：现代 ComfyUI（torch>=2.1）加载 safetensors 走的是 torch.load(mmap=True)，文件是内存映射，按页懒加载，不是"整个复制进 RAM 再传显存"。我上一条"文件多大，RAM 就得先扛多大"说得太满，实际加载阶段不会在匿名内存里留一份完整副本。
但"视频工作流建议 64GB"这个结论仍然成立，理由是另外三件事，跟加载复制无关：
显存放不下的回退：VRAM 不够时（--lowvram 或自动降级），ComfyUI 把权重常驻 RAM、按节点执行再换进显存。R9700 32G 跑 Wan 14B fp16（约 28GB）再加 T5 编码器，模型本体+编码器同时驻留 RAM 是常态，这时 RAM 是真要扛的。
多组件叠加：Wan / T5 / CLIP / VAE 是同时加载的，峰值等于各组件之和，不是单块大小。
mmap 的页缓存也算占用：28GB 的模型文件映射后，加载期 page cache 会吃掉大半可用内存，32GB 机器上再算上系统、浏览器和 ComfyUI 自己，很容易换页。
--highvram / --gpu-only 是另两条路：--highvram 让权重常驻显存不换出，32G 显存跑 14B fp16+T5 刚好，但视频解码时还要给 latent 和 VAE 留显存余量；--gpu-only 完全不走系统内存中转，前提是显存能把全部组件塞下，否则直接 OOM。
结论维持：单卡图像流、用量化模型，32GB 内存凑合能用；跑 Wan/LTX 这类视频工作流或以后上双卡，64GB 一步到位。想眼见为实的话，Windows 下用任务管理器盯一次跑 Wan 时的"提交大小"就清楚了。
