ComfyUI 五种缓存模式该选哪个：从 `--cache-ram` 的默认阈值倒推启动参数

2026-08-09

启动参数里最容易被人一把梭的就是缓存这一组。论坛上随手抄来的启动脚本，经常同时挂着 --high-ram 和一堆显存开关，抄的人也说不清它们各自在管什么。麻烦的是这一组开关在 comfy/cli_args.py（v0.31.0，核对日 2026-08-09）里是一个互斥组——你不能指望把几个缓存模式叠起来用出一个”更好的组合”，你只能选一个。

那就得先搞清楚这五个选项各自是什么语义，以及不选的时候系统在干什么。

一、这一组到底有几个开关

以下是 comfy/cli_args.py（v0.31.0）里这一组参数的 help 原意：

参数	help 原意
`--cache-ram [GB [GB]]`	RAM 压力缓存，这是默认缓存模式。第一个值设 active-cache 阈值，可选的第二个值设 inactive-cache/pin 阈值
`--cache-classic`	使用旧式（aggressive）缓存
`--cache-lru N`	LRU 缓存，最多缓存 N 个节点结果。可能占用更多 RAM/VRAM
`--cache-none`	降低 RAM/VRAM 占用，代价是每次运行都重新执行每个节点
`--high-ram`	在高内存机器、或偏好用页面文件而非重新加载模型的系统上可略微提升性能

读这张表的第一件事：--cache-ram 那一行写着”这是默认缓存模式”。 也就是说你什么都不加的时候，跑的不是”没有缓存”，也不是旧式缓存，而是 RAM 压力缓存，并且用的是一套有具体数字的默认阈值。绝大多数”我该加什么缓存参数”的问题，正确答案其实是”先搞清楚默认那套值在你这台机器上算出来是多少”。

需要说在前面的是：help 只交代了这几个开关各自属于哪种缓存策略、以及两个阈值分别代表 active 和 inactive/pin，并没有交代超过阈值之后的淘汰顺序、命中判断这些内部细节。所以下文只在 help 与源码常量给出的范围内讲，超出这个范围的机制我不会替它补。

二、默认值是按你的 RAM 算出来的

--cache-ram 不给值时的默认，help 写得很具体：

active 阈值为系统 RAM 的 10%，最小 2GB、最大 10GB
inactive 阈值为系统 RAM 的 100%，最大 128GB

这两行是纯算术，可以直接倒推出三个分界点，也是我认为最值得记住的判断依据：

RAM 低于 20GB 的机器，active 阈值一直被 2GB 的下限托着。 因为 20GB 的 10% 正好是 2GB，再往下 10% 算出来不足 2GB，就会被最小值兜住。换句话说 8GB 内存和 16GB 内存的机器，默认拿到的 active 阈值是同一个数——2GB。指望”加内存条自动让缓存更宽裕”，在 20GB 这条线以下是不成立的。

RAM 超过 100GB 的机器，active 阈值被 10GB 封顶。 128GB 内存和 256GB 内存的默认 active 阈值都是 10GB，不会继续涨。工作站用户如果觉得”我内存这么大它怎么还在反复折腾”，这就是原因之一：默认策略主动给 active 部分设了一个上限，多出来的内存它默认不往这里放。

inactive 阈值默认等于全部 RAM，直到 128GB 封顶。 也就是说 inactive/pin 这一侧默认是很激进的，它默认认为整台机器的内存都可以拿来做这件事。这也解释了为什么”内存看着被占满”在默认配置下并不一定是异常。

顺带提一句 pin 相关的一个版本变化：v0.31.0（2026-08-08）的 release notes 里有一条 “Don’t pin too much memory on Linux systems with no swap partition.”（PR #15266）。如果你在 Linux 上跑、而且这台机器没有 swap 分区，那么早于这个版本的时候确实会 pin 得过多，这是官方在 2026-08-08 才处理的问题。升级到 v0.31.0 是比调参数更直接的做法。

三、想手动给值，先记住它只收两个

--cache-ram 接受 0、1 或 2 个值。给一个值就是只设 active 阈值，给两个值是 active 加 inactive。源码里有一条很硬的检查：超过两个值会直接 parser.error，报错文案是

--cache-ram accepts at most two values: active GB and inactive GB

这条报错值得单独拎出来，因为它是启动期报错，不是运行期报错——你会看到 ComfyUI 根本没起来。有人习惯把多个数字并排写在一个参数后面（比如想同时指定几档阈值），在这里就会被挡下。看到这行报错不用查别的，就是值给多了。

按 help 的语义，手动指定的写法是这样：

# 只设 active 阈值
python main.py --cache-ram <active GB>

# 同时设 active 与 inactive/pin 阈值
python main.py --cache-ram <active GB> <inactive GB>

这里的两个占位符刻意没有填具体数字——官方 help 只交代了这两个位置各自是什么含义，并没有给”推荐值”这种东西，我们也没有可以拿来推荐一个数的依据。真要填，参照物只有第二节那套默认公式在你这台机器上算出来的值。

以上为按官方参数语义组合的示例，未逐项实测，以官方文档与 --help 输出为准。

什么时候需要手动给值？我的判断依据是：只有当你确认默认公式算出来的数字明显不适合这台机器时才动它。 典型的两种情况，一是内存超过 100GB 的工作站，默认 active 被封在 10GB，你可能希望往上抬；二是这台机器还要同时跑别的吃内存的东西（数据库、虚拟机、另一个推理服务），默认 inactive 阈值等于全部 RAM 就太贪了，你需要主动压低第二个值给别人留地方。除此之外，我倾向于先不动。

四、`--high-ram` 的连带效果：它会隐含旧式缓存

这是这一组里最容易踩的一处。--high-ram 的 help 只讲了一句性能层面的话——高内存机器、或者宁可用页面文件也不愿重新加载模型的系统，用它可能略微提升性能。听起来像个纯粹的性能开关。

但源码里还有一条 help 文本没写出来的逻辑：--high-ram 会把 cache_classic 置真。 也就是说你加了 --high-ram，等于同时把缓存模式从默认的 RAM 压力缓存换成了旧式（aggressive）缓存。

这个设计相当反直觉，因为参数名字里完全看不出”缓存模式”四个字。它带来的实际后果是：你以为自己只是打开了一个性能偏好，其实默认那套 active/inactive 阈值机制已经不再是你以为的那套了。如果你在排查内存相关的问题，启动命令里挂着 --high-ram，那就不能再用第二节那套默认阈值来解释现象——先把它去掉，回到默认，再看现象是否还在。这是一步很便宜的判定动作。

反过来说，如果你确实想要旧式缓存，直接写 --cache-classic 比靠 --high-ram 顺带带出来要诚实得多，至少半年后回头看启动脚本能看懂自己当初想干什么。

五、`--cache-lru N` 与 `--cache-none`：一头一尾的两个极端

--cache-lru N 是按节点数量而不是按内存容量来算的：最多缓存 N 个节点结果。它的 help 里明确带了一句代价——可能占用更多 RAM/VRAM。

这句话我理解应该这样读：默认的 RAM 压力缓存是拿”内存用了多少”当刹车，而 LRU 是拿”缓存了几个节点”当刹车。节点数量和内存占用之间没有固定换算关系，一个装着高分辨率 latent 或视频帧序列的节点结果，跟一个装着一行文本的节点结果，在 LRU 眼里都算”一个”。所以工作流里大体积中间产物越多，同样的 N 值撑出来的内存占用就越难预测。help 那句提醒不是客套。

什么情况下值得考虑它？我能给出的判断依据是：你的工作流节点数稳定、中间产物体积也稳定，并且你确实知道自己想留住哪几个节点的结果。 换句话说这是给”反复微调同一张固定拓扑的图”的人用的。如果你每天在装卸各种自定义节点、图的形状天天变，用节点计数当刹车就没什么优势。

另一头是 --cache-none：降低 RAM/VRAM 占用，代价是每次运行都重新执行每个节点。

要理解这个代价有多大，得配合 README「Notes」章节里的执行模型一起看。官方的原始规则是两条：只有输出端所有输入都正确的那部分图会被执行；只有相对上次执行发生变化的部分会被执行——提交两次相同的图，只有第一次会真正执行，如果只改了图的末端，那么只有你改动的部分以及依赖它的部分会重新执行。

这条规则和 --cache-none 正好是一体两面。平时”改了个参数，前面几十个节点唰一下跳过去”的体验，靠的就是缓存。开了 --cache-none，这个体验就没了。 你按一次运行就是全图从头跑一遍。

所以 --cache-none 的正确定位不是”省内存的通用建议”，而是两种具体场合：一是内存实在不够、宁可慢也要先跑通；二是你在排查一个疑似”缓存拿到了脏结果”的问题，需要一个干净的对照组。第二种用法我觉得比第一种更有价值——它是个诊断工具，加上它跑一次，如果现象消失，方向就锁定在缓存这一侧了；如果现象照旧，那就跟缓存无关，可以掉头去查别的。

六、一条可以照着走的选择路径

把上面几条串起来，按你的处境倒推：

第一步，先确认你现在到底在哪个模式。 去看启动命令：如果这一组一个都没写，你在默认的 RAM 压力缓存上，阈值按第二节的公式算；如果写了 --high-ram，你其实在旧式缓存上；其它三个则是写什么就是什么。这一步很多人跳过，然后拿着别人默认模式下的经验来解释自己旧式缓存下的现象。

第二步，内存 20GB 以下、又主要跑图片工作流的机器，别急着调这一组。 默认 active 阈值被 2GB 兜底，你手动往上抬也不见得是好事——这台机器本来就没多少余量。真出了问题，优先看显存那一组参数和模型本身的选择，缓存这一组能腾挪的空间有限。

第三步，内存充裕（比如 64GB 往上）、跑的是节点多、中间产物大的工作流，两条路选一条。 想要”宁可用页面文件也不重新加载模型”的行为，用 --high-ram，但要清楚你同时换成了旧式缓存；想要精确控制，直接 --cache-ram <active> <inactive> 自己给两个数，把 inactive 压到给其它程序留出余量的水平。这两条别混着想。

第四步，内存超过 100GB 的工作站，默认 active 封顶在 10GB，这是你少数几个”确实该手动给值”的场景。

第五步，出问题的时候，--cache-none 是最省事的对照组。 它不是长期配置，是一次性的判定动作。

第六步，--cache-lru N 留给拓扑固定、你清楚自己在缓存什么的场景。 记住它的刹车是节点计数不是内存容量。

七、两个别混为一谈的东西

最后提醒两处容易串台的地方。

缓存这一组和显存那一组是两回事。 --cache-ram / --cache-classic / --cache-lru / --cache-none 管的是节点结果的缓存，--lowvram / --highvram / --novram / --gpu-only / --cpu 那一组管的是模型权重放哪儿运行。名字里都带 ram，但不是一个互斥组，讨论的也不是一个层面的事。把”我显存不够”的问题拿到缓存这一组来解，或者反过来，都是南辕北辙。

“改了参数模型又重新加载了一遍”这个现象，别急着归到缓存配置上。 官方仓库 issue #14618 反映了「改动 prompt 后每次都重新加载模型」这一现象，创建于 2026-06-24，标签为 Potential Bug，截至 2026-08-09 仍为 open。这里要说清楚两点：Potential Bug 的字面含义是”疑似 bug”，不等于官方已经确认；而这个 issue 仍然处于 open 状态，也就是说没有一个”官方给出的解决办法”可以抄。我没有读过这条 issue 的正文与评论，所以复现条件、根因、有没有绕过办法，这篇都不会给。

它对你的实际意义只有一条：如果你已经按第一步确认了自己的缓存模式、也理解了 README 里”只重跑变化部分”的执行模型，但现象依然对不上，那么存在一个尚未关闭的开放议题指向类似现象——这时候继续折腾缓存参数的性价比就很低了，去仓库里跟一下这条 issue 的进展，比自己盲调更划算。

延伸阅读

本文依据 ComfyUI 官方仓库（github.com/Comfy-Org/ComfyUI）的 README、comfy/cli_args.py、 release notes 与官方安全公告整理，核对日 2026-08-09，对应版本 v0.31.0；文中引用的 issue 状态为该日期的快照。本文内容为官方文档与源码口径，非本机实测。参数、默认值与功能随版本变动，请以官方文档与 python main.py --help 的实际输出为准。