跑Stable Diffusion的朋友对下面这行红色报错应该都不陌生CUDA out of memory. Tried to allocate 2.00 GiB (GPU 0; 8.00 GiB total capacity; 6.31 GiB already allocated; 1.19 GiB free; ...)我第一次在8G显存的笔记本上跑SDXL看到这个报错的时候第一反应也是“完了显卡废了得换卡”。查了一圈12G/16G卡的价格差点就下单了。后来冷静下来翻了翻PyTorch的官方文档和社区讨论发现事情没那么简单——很多时候报OOM不是因为你的显存真的装不下模型而是PyTorch默认的显存分配策略太“笨”了。这篇内容就是围绕一个环境变量展开的PYTORCH_CUDA_ALLOC_CONF。我会把这几个核心参数的原理拆开讲清楚再给出8G、6G、4G显存卡分别怎么设置、实测收益有多大最后排一排设置完仍然翻车的原因。整个过程适合所有用WebUI、ComfyUI跑图尤其是显存卡在8G及以下的朋友。换显卡之前先花十分钟试一下这个参数大概率能省下一大笔钱。1. 先别怪显卡OOM的真正根源在PyTorch的内存分配策略1.1 任务管理器里的显存占用很多是“虚标”的你可能会发现一个奇怪的现象刚启动WebUI还没开始出图任务管理器里显存占用就已经快满了。这时候很多人以为模型加载就把显存吃光了其实不然。PyTorch的默认显存分配器Caching Allocator在设计上做了一个非常重要的取舍为了让训练和推理过程中的显存分配够快它不会频繁地向驱动申请或归还显存而是搞了一个缓存池。第一次需要显存的时候直接向GPU要一大块比如要4GB之后所有张量都在这块池子里划来划去你用完了释放数据虽然标记为“空闲”但这块显存并不会真正还给驱动而是留在池子里等下一次请求复用。这样做的好处是速度快。cudaMalloc/cudaFree这种系统级调用是很贵的每次分配都要和驱动交互如果每个张量都走这个流程训练根本跑不动。坏处就是任务管理器看到的显存“已占用”大部分是缓存而不是真正在用的数据。所以“显存好像满了”很可能是假象池子里堆了一堆已经释放但还没还给驱动的空闲块。1.2 为什么明明剩余空间够还是分配不出连续块更让人抓狂的情况是报错信息里写着“1.19 GiB free”但我明明才申请2GB按理说总量8GB剩下1.19GB是不够但有时候显示free有3GB多还是申请一块2GB的连续内存失败。这就涉及到显存碎片化的问题。缓存池里的内存块经过无数次申请、释放、切分会变得非常零碎。比如一个大块的连续显存被切成了几个小块用完之后这些小块的“状态”是空闲的分布却不连续。当一个新的请求进来需要一块较大的连续空间时分配器在缓存池里翻来翻去找不到合适大小的空闲块就会尝试调用cudaMalloc向驱动申请新显存。但如果此时GPU物理上已经没有足够连续显存可给了就会直接报OOM。打个比方你的房间总空间是够的但东西摆得太碎抽屉东一个西一个你想放一个特别大的行李箱怎么都塞不进去。这时候问题的关键不是房间太小而是空间被切成了太多小块没法拼成完整的一块。我后来看了一些PYTORCH_CUDA_ALLOC_CONF相关的讨论帖发现很多8G卡用户都卡在同一个地方——不是模型太大而是分配器在反复的切块、拆分过程中把显存搞碎了。这个参数能帮我们干预分配器的行为从源头上减少碎片化这才是它真正能解决OOM问题的原因。2. 三个关键参数逐个拆解max_split_size_mb、expandable_segments、garbage_collection_thresholdPYTORCH_CUDA_ALLOC_CONF是一个环境变量可以同时传入多个配置项用英文逗号分隔。今天只讲和跑Stable Diffusion关系最密切的三个max_split_size_mb、expandable_segments:True、garbage_collection_threshold。2.1 max_split_size_mb让大块显存不被拆碎这是社区里讨论最多、也是我之前误解最深的参数。官方文档对它的定义是限制分配器把大块内存拆分成小块的行为阈值。默认情况下分配器为了尽可能塞下各种请求会把一个大的空闲块拆成小块去满足小请求。比如缓存池里有一块512MB的连续显存这时候来了一个100MB的请求分配器会直接从这个512MB的块上切走100MB剩下的412MB继续留在池子里。下次又来一个80MB的请求再切一刀……切到后面大块被分成几十个小碎块如果一个大的连续请求比如1024MB进来就没法满足了。max_split_size_mb设得越大分配器就越“吝啬”拆分大块。如果你把它设成128MB那么小于128MB的请求会尽量从已有的小块里找或者向上取整到合适的块大小而不是直接去拆那些大于128MB的大块。这样可以保护大的连续空闲块留给后续真正需要大内存的操作使用。但注意这个参数不是越大越好。设成512MB甚至1024MB后小请求反而可能找不到合适的块被迫申请新的显存峰值占用会上升更容易爆。我在8G卡上测试SDXL时max_split_size_mb从16设到64效果最好再往上比如256反而出图帧率略有下降、显存峰值升高。推荐起步值是64如果还碎可以试着提到128不要一上来就512。2.2 expandable_segments:True改变整个分配器的玩法这个参数是PyTorch 2.0之后加入的也是最近社区里讨论热度最高的一个。它做的事情是不再使用默认的缓存分配器而是改用CUDA的异步分配机制cudaMallocAsync。用一句话描述区别默认分配器是“一次性锁一大片地皮然后在里面盖房子拆房子”expandable_segments:True则是“用多少、扩多少房子之间可以动态调整边界”。显存不再是一大块固定区域而是由多段可扩展的内存段组成。这样做最直接的好处是大幅降低碎片化同时减少无谓的预分配。我在8G卡上实测开expandable_segments:True后跑1024x1024的SDXL峰值显存从7.8GB降到了7.1GB左右出图失败率明显下降。ComfyUI用户尤其推荐试这个参数因为ComfyUI的节点式工作流会频繁创建和释放大量中间张量恰好是默认分配器最不擅长的场景。代价也有异步分配在某些老驱动、老显卡上可能出现兼容性问题另外开启后和个别自定义CUDA算子可能存在冲突。如果你的WebUI装了很多老的自定义节点或者升级PyTorch版本有心无力那就先别开这个用另外两个参数也能缓解大部分问题。2.3 garbage_collection_threshold显存逼近临界点前先清缓存garbage_collection_threshold的取值在0到1之间默认是0。它的含义是当显存使用率达到这个比例时分配器会在下一次分配前主动清理空闲缓存块。默认情况下缓存池里的空闲块会一直堆着直到系统真的扛不住了才统一回收。这个设计在训练时问题不大但在跑图这种“不断申请大块、释放大块”的场景里空闲缓存越积越多就会挤占真正需要的空间。设一个0.8左右的阈值相当于给显存设了“警戒水位”用到了80%就提前把能清的缓存清掉给后续的大分配留出空间。这个参数和max_split_size_mb是绝配。一个负责减少碎片化一个负责及时释放无用缓存。但阈值别设太低0.5以下会导致分配器频繁清理而清理操作需要同步等待出图速度会肉眼可见地变慢。我一般建议从0.8起步4G以下显存可以试试0.85甚至0.9。3. 实测配置8G/6G/4G显存分别怎么设收益有多大3.1 8G显存跑SDXL从“必爆”到“勉强能跑”的调整过程先说我的主力测试机笔记本版RTX 3060 8GPyTorch 2.1.2ComfyUI和A1111 WebUI都试过。没设置任何环境变量时SDXL 1024x1024直出基本必爆512x768有时候也会爆报错信息五花八门但核心都是OOM。第一阶段我只加了expandable_segments:True。效果立竿见影1024x1024能出图了但不太稳定连续出三四张之后显存占用逐步走高最终还是会爆。原因是缓存池里的旧缓存不断积累异步分配也无法完全避免。第二阶段我加上garbage_collection_threshold:0.8稳定性好了很多。连续出图基本不再出现“越跑越卡、最终爆显存”的问题。第三阶段再把max_split_size_mb:64加进去主要是为了防止放大和refiner阶段的大块分配被碎片化卡住。最终我在这台8G卡上长期使用的配置是PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True,max_split_size_mb:64,garbage_collection_threshold:0.8设置之后SDXL 1024x1024可以稳定出图但依然很紧张——分辨率再往上加、或者叠加ControlNet后仍有爆显存风险。所以8G跑SDXL属于“能用但要有节制”出图时开个低Batch Size放大别一下拉太高。项目未设置参数设置参数后SDXL 1024x1024必爆勉强稳定出图SDXL 512x768偶尔爆稳定SD 1.5 768x768偶尔爆稳定且显存余量充足512x512峰值显存约7.8G约7.1G单张出图速度基准略慢5%~8%速度上有一点损失换来的是不再频繁报错对我来说非常值。3.2 6G显存跑SD 1.5用max_split_size_mb把碎片化压住6G卡比如RTX 2060、RTX 3060笔记本版是另一个很庞大的用户群。这类显存跑SD 1.5的512x512绰绰有余但一旦上到576x768、768x768或者开了高清修复就特别容易爆。实测下来6G卡上expandable_segments:True的效果没有8G卡那么明显但max_split_size_mb和garbage_collection_threshold的作用很突出。我建议的配置PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:128,garbage_collection_threshold:0.85max_split_size_mb从64提高到128是因为6G卡跑SD 1.5时单次大分配没那么多大块缓存更容易被拆碎用128MB作为拆分阈值能更好地保护连续内存块。实测768x768从“时好时坏”变成“稳定出图”高清修复也从高风险变成可接受。如果你用的还是老一点的显卡、驱动或者PyTorch版本在2.0以下expandable_segments大概率不支持但上面这个没有任何兼容性问题可以放心用。3.3 4G及以下显存的极限玩法4G显存跑SD是很痛苦的但也不是完全跑不了。我拿GTX 1650 4G试过SD 1.5在512x512分辨率下把步数调低、用低显存模式是可以出图的只是速度和稳定性都比较感人。4G卡的思路和6G/8G不太一样。此时显存空间本来就小碎片化的杀伤力更大所以要尽量保护大块连续空间PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:256,garbage_collection_threshold:0.9256MB的意义在于让分配器尽量把所有小块请求都收纳进去不去拆大块这样一旦模型需要分配比较大的中间张量比如Attention矩阵可以立刻拿到一整块连续空间。garbage_collection_threshold:0.9是极限水位让系统尽量多用一点缓存池里的空间再清理。即便如此4G卡也仅建议SD 1.5加512x512以下分辨率配合WebUI的--lowvram参数使用。SDXL就不要想了不是参数能解决的那是物理极限。3.4 各平台的设置位置总结配置方法很简单就是把环境变量写到WebUI或ComfyUI的启动脚本里。不同系统的格式不一样Windows CMDset PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True,max_split_size_mb:64,garbage_collection_threshold:0.8Windows PowerShell$env:PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True,max_split_size_mb:64,garbage_collection_threshold:0.8Linux / macOS 终端export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True,max_split_size_mb:64,garbage_collection_threshold:0.8A1111 WebUI用户编辑根目录下的webui-user.bat在set COMMANDLINE_ARGS那一行之前加上set PYTORCH_CUDA_ALLOC_CONF...。注意别加到COMMANDLINE_ARGS里面那是传给WebUI的参数不是环境变量。ComfyUI用户修改run_nvidia_gpu.bat或你自己用的启动脚本同样在启动python进程之前设置环境变量。如果你是用Docker或者云端GPU也在启动命令前加上export即可。注意修改环境变量之后必须完全关闭并重新启动WebUI/ComfyUI才能生效。很多朋友改完直接刷新页面结果跟没改一样白折腾半小时。4. 设置之后反而更糟排查思路与避坑指南4.1 设置后直接报错或参数不生效最典型的一种情况设置expandable_segments:True后启动时直接报类似expandable_segments not supported的错误或者提示需要更新PyTorch。这是因为expandable_segments依赖PyTorch 2.0以上版本和较新的CUDA驱动。解决办法很简单要么升级PyTorch要么不用这个参数只保留max_split_size_mb和garbage_collection_threshold。还有一种情况是环境变量被覆盖。很多人既在系统环境变量里设了一份又去改了启动脚本但脚本里写错了一个拼写系统环境变量又不生效导致实际上用的是默认配置。排查办法在启动脚本里加一行echo %PYTORCH_CUDA_ALLOC_CONF%Windows或echo $PYTORCH_CUDA_ALLOC_CONFLinux看看实际生效的值到底是什么。4.2 max_split_size_mb设得过大显存不降反升很多教程会说“遇到OOM就调大max_split_size_mb”但这句话有误导性。调大确实能保护大块空间但也意味着小请求更难找到合适的块分配器可能被迫向驱动申请新的显存导致峰值占用不降反升。我自己的经验是跑图场景推荐从64起步最大不要超过256如果设了256后显存峰值明显变高降回128再试。这个参数不是越大越好它是权衡“大块保护”和“小块利用率”之间的一根杠杆。4.3 garbage_collection_threshold设太低出图速度断崖式下跌如果设了0.5、0.6这种偏低的阈值你会发现出图过程中显存时不时被强制清理速度明显变慢甚至每跑一步都要卡一下。因为清理缓存需要同步等待GPU完成当前所有任务这个操作本身是有开销的。阈值越低清理越频繁开销越大。0.7~0.85是我试过的甜点区低于0.7基本都会感觉到速度下降。4G以下显存可以用0.9但不要用0.99因为太晚清理可能仍然会在分配前卡死。4.4 调完参数仍然OOM先按这份清单逐项检查如果环境变量都设对了、参数也合理但依然OOM问题很可能不在分配器上。我踩过几次坑之后养成了一套排查习惯nvidia-smi 看一圈。确认没有残留的Python进程占着显存。WebUI或ComfyUI崩过之后后台进程不一定跟着退出经常有僵尸进程把显存锁死。看看是不是多个GPU应用在打架。浏览器开一堆标签页、又开了视频剪辑软件、还在跑别的AI工具这些都会抢显存。Chrome的硬件加速在8G卡上对显存的挤占比很多人想象中严重。确认分辨率、采样器、附加组件是否超载。SDXL加refiner加ControlNet加高分放大8G卡再怎么优化都救不回来。参数优化解决的是碎片化和缓存问题不是无中生有帮你变出物理显存。PyTorch版本和WebUI版本是否匹配。我用A1111的时候发现分支更新到很激进的新版本后某些自定义节点占显存会莫名变多回退到稳定版就正常了。别把环境变量设到python tokenizers脚本里这种低级错误真的有人犯过。环境变量必须在启动Python进程之前就存在于环境中。5. 调了参数还报OOM能用上的兜底方案5.1 WebUI的三档显存模式A1111 WebUI本身就带显存优化参数很多人完全没用过。启动时加--medvram模型会在显存和内存之间做更细粒度的管理把不用的模块先移出显存--lowvram则更激进能大幅降低显存占用但出图速度也会明显变慢。这两个参数和PYTORCH_CUDA_ALLOC_CONF并不冲突可以叠加使用。我在8G卡上开expandable_segments:True之后其实已经很少需要--medvram了但6G卡用户建议组合起来用。具体设置也是在webui-user.bat里的COMMANDLINE_ARGS中加。5.2 分辨率与放大策略先低后高如果你死活要跑1024x1024以上的图又不想把显存参数调到极限可以在出图流程上做文章。先用512x512或512x768出草图然后再用图像放大插件放大而不是直接在高分辨率下采样。这样做的好处是前期推理阶段不占用太多中间张量显存放大阶段虽然显存需求高但那是相对短期的操作分配器更容易找到连续空间。我在8G卡上跑SDXL时就是先出512x768的草稿再用2倍放大插件拉高最后用图像修复补细节。虽然操作上多了一步但出图成功率几乎100%比在1024x1024下反复跟OOM搏斗舒服多了。5.3 ComfyUI的显存清理节点ComfyUI用户有个优势可以通过节点手动控制显存释放。工作流中在合适的位置插入显存清理节点比如常见的“显存清理”或“VRAM Management”节点在每次潜空间解码前清一次缓存。这类节点本质上是手动触发torch.cuda.empty_cache()跟garbage_collection_threshold是互补关系——一个是主动调用一个是阈值自动触发。5.4 换用更省显存的模型和采样器如果参数调优和流程优化都做完了仍然被显存卡脖子那就得在模型选择上妥协了。SD 1.5相比SDXL在同样分辨率下省很多显存SD Turbo、LCM这类蒸馏模型不仅省显存速度也快不少再不行就上专门给低显存优化的精简版模型。采样器尽量选DPM系列显存占用相对温和。注意模型文件体积和运行时显存占用是两回事。文件只有2GB不代表运行时只占2GB实际占用要加上Unet、VAE、CLIP等多个组件的权重还要加上推理时的中间激活值。所以别看到模型文件不大就觉得显存肯定够。5.5 终极手段把不常用的模块暂时“踢”出显存WebUI和ComfyUI在加载模型后默认会保留模型权重在显存中方便下一次使用。如果你频繁切换模型旧模型的权重和中间缓存会占着显存不走。这种情况下可以手动运行torch.cuda.empty_cache()或者清除WebUI的模型缓存设置腾出空间给当前任务。最后分享一点实操心得折腾了差不多两个星期在换了不下二十组参数组合之后我目前在日常使用中固定的配置是expandable_segments:True,max_split_size_mb:64,garbage_collection_threshold:0.8。8G卡跑SD 1.5基本告别OOMSDXL也建立了“草图再放大”的工作流出图成功率可以用“稳定”来形容。最开始我也觉得换个16G卡一了百了但试过参数调优之后才明白软件优化能做到的事情远超很多人的预期。如果你现在也卡在OOM报错上不妨先花十分钟把这篇文章里的配置手动试一遍再决定要不要掏钱换显卡。实测下来这两个十分钟的成本差距可能是一张显卡的价格。 
长河君 · 2026/9/20 12:15:21 · 阅读 1.2k 告别CUDA OOM：用PYTORCH_CUDA_ALLOC_CONF优化显存，8G卡也能跑SDXL
跑Stable Diffusion的朋友对下面这行红色报错应该都不陌生CUDA out of memory. Tried to allocate 2.00 GiB (GPU 0; 8.00 GiB total capacity; 6.31 GiB already allocated; 1.19 GiB free; ...)我第一次在8G显存的笔记本上跑SDXL看到这个报错的时候第一反应也是“完了显卡废了得换卡”。查了一圈12G/16G卡的价格差点就下单了。后来冷静下来翻了翻PyTorch的官方文档和社区讨论发现事情没那么简单——很多时候报OOM不是因为你的显存真的装不下模型而是PyTorch默认的显存分配策略太“笨”了。这篇内容就是围绕一个环境变量展开的PYTORCH_CUDA_ALLOC_CONF。我会把这几个核心参数的原理拆开讲清楚再给出8G、6G、4G显存卡分别怎么设置、实测收益有多大最后排一排设置完仍然翻车的原因。整个过程适合所有用WebUI、ComfyUI跑图尤其是显存卡在8G及以下的朋友。换显卡之前先花十分钟试一下这个参数大概率能省下一大笔钱。1. 先别怪显卡OOM的真正根源在PyTorch的内存分配策略1.1 任务管理器里的显存占用很多是“虚标”的你可能会发现一个奇怪的现象刚启动WebUI还没开始出图任务管理器里显存占用就已经快满了。这时候很多人以为模型加载就把显存吃光了其实不然。PyTorch的默认显存分配器Caching Allocator在设计上做了一个非常重要的取舍为了让训练和推理过程中的显存分配够快它不会频繁地向驱动申请或归还显存而是搞了一个缓存池。第一次需要显存的时候直接向GPU要一大块比如要4GB之后所有张量都在这块池子里划来划去你用完了释放数据虽然标记为“空闲”但这块显存并不会真正还给驱动而是留在池子里等下一次请求复用。这样做的好处是速度快。cudaMalloc/cudaFree这种系统级调用是很贵的每次分配都要和驱动交互如果每个张量都走这个流程训练根本跑不动。坏处就是任务管理器看到的显存“已占用”大部分是缓存而不是真正在用的数据。所以“显存好像满了”很可能是假象池子里堆了一堆已经释放但还没还给驱动的空闲块。1.2 为什么明明剩余空间够还是分配不出连续块更让人抓狂的情况是报错信息里写着“1.19 GiB free”但我明明才申请2GB按理说总量8GB剩下1.19GB是不够但有时候显示free有3GB多还是申请一块2GB的连续内存失败。这就涉及到显存碎片化的问题。缓存池里的内存块经过无数次申请、释放、切分会变得非常零碎。比如一个大块的连续显存被切成了几个小块用完之后这些小块的“状态”是空闲的分布却不连续。当一个新的请求进来需要一块较大的连续空间时分配器在缓存池里翻来翻去找不到合适大小的空闲块就会尝试调用cudaMalloc向驱动申请新显存。但如果此时GPU物理上已经没有足够连续显存可给了就会直接报OOM。打个比方你的房间总空间是够的但东西摆得太碎抽屉东一个西一个你想放一个特别大的行李箱怎么都塞不进去。这时候问题的关键不是房间太小而是空间被切成了太多小块没法拼成完整的一块。我后来看了一些PYTORCH_CUDA_ALLOC_CONF相关的讨论帖发现很多8G卡用户都卡在同一个地方——不是模型太大而是分配器在反复的切块、拆分过程中把显存搞碎了。这个参数能帮我们干预分配器的行为从源头上减少碎片化这才是它真正能解决OOM问题的原因。2. 三个关键参数逐个拆解max_split_size_mb、expandable_segments、garbage_collection_thresholdPYTORCH_CUDA_ALLOC_CONF是一个环境变量可以同时传入多个配置项用英文逗号分隔。今天只讲和跑Stable Diffusion关系最密切的三个max_split_size_mb、expandable_segments:True、garbage_collection_threshold。2.1 max_split_size_mb让大块显存不被拆碎这是社区里讨论最多、也是我之前误解最深的参数。官方文档对它的定义是限制分配器把大块内存拆分成小块的行为阈值。默认情况下分配器为了尽可能塞下各种请求会把一个大的空闲块拆成小块去满足小请求。比如缓存池里有一块512MB的连续显存这时候来了一个100MB的请求分配器会直接从这个512MB的块上切走100MB剩下的412MB继续留在池子里。下次又来一个80MB的请求再切一刀……切到后面大块被分成几十个小碎块如果一个大的连续请求比如1024MB进来就没法满足了。max_split_size_mb设得越大分配器就越“吝啬”拆分大块。如果你把它设成128MB那么小于128MB的请求会尽量从已有的小块里找或者向上取整到合适的块大小而不是直接去拆那些大于128MB的大块。这样可以保护大的连续空闲块留给后续真正需要大内存的操作使用。但注意这个参数不是越大越好。设成512MB甚至1024MB后小请求反而可能找不到合适的块被迫申请新的显存峰值占用会上升更容易爆。我在8G卡上测试SDXL时max_split_size_mb从16设到64效果最好再往上比如256反而出图帧率略有下降、显存峰值升高。推荐起步值是64如果还碎可以试着提到128不要一上来就512。2.2 expandable_segments:True改变整个分配器的玩法这个参数是PyTorch 2.0之后加入的也是最近社区里讨论热度最高的一个。它做的事情是不再使用默认的缓存分配器而是改用CUDA的异步分配机制cudaMallocAsync。用一句话描述区别默认分配器是“一次性锁一大片地皮然后在里面盖房子拆房子”expandable_segments:True则是“用多少、扩多少房子之间可以动态调整边界”。显存不再是一大块固定区域而是由多段可扩展的内存段组成。这样做最直接的好处是大幅降低碎片化同时减少无谓的预分配。我在8G卡上实测开expandable_segments:True后跑1024x1024的SDXL峰值显存从7.8GB降到了7.1GB左右出图失败率明显下降。ComfyUI用户尤其推荐试这个参数因为ComfyUI的节点式工作流会频繁创建和释放大量中间张量恰好是默认分配器最不擅长的场景。代价也有异步分配在某些老驱动、老显卡上可能出现兼容性问题另外开启后和个别自定义CUDA算子可能存在冲突。如果你的WebUI装了很多老的自定义节点或者升级PyTorch版本有心无力那就先别开这个用另外两个参数也能缓解大部分问题。2.3 garbage_collection_threshold显存逼近临界点前先清缓存garbage_collection_threshold的取值在0到1之间默认是0。它的含义是当显存使用率达到这个比例时分配器会在下一次分配前主动清理空闲缓存块。默认情况下缓存池里的空闲块会一直堆着直到系统真的扛不住了才统一回收。这个设计在训练时问题不大但在跑图这种“不断申请大块、释放大块”的场景里空闲缓存越积越多就会挤占真正需要的空间。设一个0.8左右的阈值相当于给显存设了“警戒水位”用到了80%就提前把能清的缓存清掉给后续的大分配留出空间。这个参数和max_split_size_mb是绝配。一个负责减少碎片化一个负责及时释放无用缓存。但阈值别设太低0.5以下会导致分配器频繁清理而清理操作需要同步等待出图速度会肉眼可见地变慢。我一般建议从0.8起步4G以下显存可以试试0.85甚至0.9。3. 实测配置8G/6G/4G显存分别怎么设收益有多大3.1 8G显存跑SDXL从“必爆”到“勉强能跑”的调整过程先说我的主力测试机笔记本版RTX 3060 8GPyTorch 2.1.2ComfyUI和A1111 WebUI都试过。没设置任何环境变量时SDXL 1024x1024直出基本必爆512x768有时候也会爆报错信息五花八门但核心都是OOM。第一阶段我只加了expandable_segments:True。效果立竿见影1024x1024能出图了但不太稳定连续出三四张之后显存占用逐步走高最终还是会爆。原因是缓存池里的旧缓存不断积累异步分配也无法完全避免。第二阶段我加上garbage_collection_threshold:0.8稳定性好了很多。连续出图基本不再出现“越跑越卡、最终爆显存”的问题。第三阶段再把max_split_size_mb:64加进去主要是为了防止放大和refiner阶段的大块分配被碎片化卡住。最终我在这台8G卡上长期使用的配置是PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True,max_split_size_mb:64,garbage_collection_threshold:0.8设置之后SDXL 1024x1024可以稳定出图但依然很紧张——分辨率再往上加、或者叠加ControlNet后仍有爆显存风险。所以8G跑SDXL属于“能用但要有节制”出图时开个低Batch Size放大别一下拉太高。项目未设置参数设置参数后SDXL 1024x1024必爆勉强稳定出图SDXL 512x768偶尔爆稳定SD 1.5 768x768偶尔爆稳定且显存余量充足512x512峰值显存约7.8G约7.1G单张出图速度基准略慢5%~8%速度上有一点损失换来的是不再频繁报错对我来说非常值。3.2 6G显存跑SD 1.5用max_split_size_mb把碎片化压住6G卡比如RTX 2060、RTX 3060笔记本版是另一个很庞大的用户群。这类显存跑SD 1.5的512x512绰绰有余但一旦上到576x768、768x768或者开了高清修复就特别容易爆。实测下来6G卡上expandable_segments:True的效果没有8G卡那么明显但max_split_size_mb和garbage_collection_threshold的作用很突出。我建议的配置PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:128,garbage_collection_threshold:0.85max_split_size_mb从64提高到128是因为6G卡跑SD 1.5时单次大分配没那么多大块缓存更容易被拆碎用128MB作为拆分阈值能更好地保护连续内存块。实测768x768从“时好时坏”变成“稳定出图”高清修复也从高风险变成可接受。如果你用的还是老一点的显卡、驱动或者PyTorch版本在2.0以下expandable_segments大概率不支持但上面这个没有任何兼容性问题可以放心用。3.3 4G及以下显存的极限玩法4G显存跑SD是很痛苦的但也不是完全跑不了。我拿GTX 1650 4G试过SD 1.5在512x512分辨率下把步数调低、用低显存模式是可以出图的只是速度和稳定性都比较感人。4G卡的思路和6G/8G不太一样。此时显存空间本来就小碎片化的杀伤力更大所以要尽量保护大块连续空间PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:256,garbage_collection_threshold:0.9256MB的意义在于让分配器尽量把所有小块请求都收纳进去不去拆大块这样一旦模型需要分配比较大的中间张量比如Attention矩阵可以立刻拿到一整块连续空间。garbage_collection_threshold:0.9是极限水位让系统尽量多用一点缓存池里的空间再清理。即便如此4G卡也仅建议SD 1.5加512x512以下分辨率配合WebUI的--lowvram参数使用。SDXL就不要想了不是参数能解决的那是物理极限。3.4 各平台的设置位置总结配置方法很简单就是把环境变量写到WebUI或ComfyUI的启动脚本里。不同系统的格式不一样Windows CMDset PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True,max_split_size_mb:64,garbage_collection_threshold:0.8Windows PowerShell$env:PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True,max_split_size_mb:64,garbage_collection_threshold:0.8Linux / macOS 终端export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True,max_split_size_mb:64,garbage_collection_threshold:0.8A1111 WebUI用户编辑根目录下的webui-user.bat在set COMMANDLINE_ARGS那一行之前加上set PYTORCH_CUDA_ALLOC_CONF...。注意别加到COMMANDLINE_ARGS里面那是传给WebUI的参数不是环境变量。ComfyUI用户修改run_nvidia_gpu.bat或你自己用的启动脚本同样在启动python进程之前设置环境变量。如果你是用Docker或者云端GPU也在启动命令前加上export即可。注意修改环境变量之后必须完全关闭并重新启动WebUI/ComfyUI才能生效。很多朋友改完直接刷新页面结果跟没改一样白折腾半小时。4. 设置之后反而更糟排查思路与避坑指南4.1 设置后直接报错或参数不生效最典型的一种情况设置expandable_segments:True后启动时直接报类似expandable_segments not supported的错误或者提示需要更新PyTorch。这是因为expandable_segments依赖PyTorch 2.0以上版本和较新的CUDA驱动。解决办法很简单要么升级PyTorch要么不用这个参数只保留max_split_size_mb和garbage_collection_threshold。还有一种情况是环境变量被覆盖。很多人既在系统环境变量里设了一份又去改了启动脚本但脚本里写错了一个拼写系统环境变量又不生效导致实际上用的是默认配置。排查办法在启动脚本里加一行echo %PYTORCH_CUDA_ALLOC_CONF%Windows或echo $PYTORCH_CUDA_ALLOC_CONFLinux看看实际生效的值到底是什么。4.2 max_split_size_mb设得过大显存不降反升很多教程会说“遇到OOM就调大max_split_size_mb”但这句话有误导性。调大确实能保护大块空间但也意味着小请求更难找到合适的块分配器可能被迫向驱动申请新的显存导致峰值占用不降反升。我自己的经验是跑图场景推荐从64起步最大不要超过256如果设了256后显存峰值明显变高降回128再试。这个参数不是越大越好它是权衡“大块保护”和“小块利用率”之间的一根杠杆。4.3 garbage_collection_threshold设太低出图速度断崖式下跌如果设了0.5、0.6这种偏低的阈值你会发现出图过程中显存时不时被强制清理速度明显变慢甚至每跑一步都要卡一下。因为清理缓存需要同步等待GPU完成当前所有任务这个操作本身是有开销的。阈值越低清理越频繁开销越大。0.7~0.85是我试过的甜点区低于0.7基本都会感觉到速度下降。4G以下显存可以用0.9但不要用0.99因为太晚清理可能仍然会在分配前卡死。4.4 调完参数仍然OOM先按这份清单逐项检查如果环境变量都设对了、参数也合理但依然OOM问题很可能不在分配器上。我踩过几次坑之后养成了一套排查习惯nvidia-smi 看一圈。确认没有残留的Python进程占着显存。WebUI或ComfyUI崩过之后后台进程不一定跟着退出经常有僵尸进程把显存锁死。看看是不是多个GPU应用在打架。浏览器开一堆标签页、又开了视频剪辑软件、还在跑别的AI工具这些都会抢显存。Chrome的硬件加速在8G卡上对显存的挤占比很多人想象中严重。确认分辨率、采样器、附加组件是否超载。SDXL加refiner加ControlNet加高分放大8G卡再怎么优化都救不回来。参数优化解决的是碎片化和缓存问题不是无中生有帮你变出物理显存。PyTorch版本和WebUI版本是否匹配。我用A1111的时候发现分支更新到很激进的新版本后某些自定义节点占显存会莫名变多回退到稳定版就正常了。别把环境变量设到python tokenizers脚本里这种低级错误真的有人犯过。环境变量必须在启动Python进程之前就存在于环境中。5. 调了参数还报OOM能用上的兜底方案5.1 WebUI的三档显存模式A1111 WebUI本身就带显存优化参数很多人完全没用过。启动时加--medvram模型会在显存和内存之间做更细粒度的管理把不用的模块先移出显存--lowvram则更激进能大幅降低显存占用但出图速度也会明显变慢。这两个参数和PYTORCH_CUDA_ALLOC_CONF并不冲突可以叠加使用。我在8G卡上开expandable_segments:True之后其实已经很少需要--medvram了但6G卡用户建议组合起来用。具体设置也是在webui-user.bat里的COMMANDLINE_ARGS中加。5.2 分辨率与放大策略先低后高如果你死活要跑1024x1024以上的图又不想把显存参数调到极限可以在出图流程上做文章。先用512x512或512x768出草图然后再用图像放大插件放大而不是直接在高分辨率下采样。这样做的好处是前期推理阶段不占用太多中间张量显存放大阶段虽然显存需求高但那是相对短期的操作分配器更容易找到连续空间。我在8G卡上跑SDXL时就是先出512x768的草稿再用2倍放大插件拉高最后用图像修复补细节。虽然操作上多了一步但出图成功率几乎100%比在1024x1024下反复跟OOM搏斗舒服多了。5.3 ComfyUI的显存清理节点ComfyUI用户有个优势可以通过节点手动控制显存释放。工作流中在合适的位置插入显存清理节点比如常见的“显存清理”或“VRAM Management”节点在每次潜空间解码前清一次缓存。这类节点本质上是手动触发torch.cuda.empty_cache()跟garbage_collection_threshold是互补关系——一个是主动调用一个是阈值自动触发。5.4 换用更省显存的模型和采样器如果参数调优和流程优化都做完了仍然被显存卡脖子那就得在模型选择上妥协了。SD 1.5相比SDXL在同样分辨率下省很多显存SD Turbo、LCM这类蒸馏模型不仅省显存速度也快不少再不行就上专门给低显存优化的精简版模型。采样器尽量选DPM系列显存占用相对温和。注意模型文件体积和运行时显存占用是两回事。文件只有2GB不代表运行时只占2GB实际占用要加上Unet、VAE、CLIP等多个组件的权重还要加上推理时的中间激活值。所以别看到模型文件不大就觉得显存肯定够。5.5 终极手段把不常用的模块暂时“踢”出显存WebUI和ComfyUI在加载模型后默认会保留模型权重在显存中方便下一次使用。如果你频繁切换模型旧模型的权重和中间缓存会占着显存不走。这种情况下可以手动运行torch.cuda.empty_cache()或者清除WebUI的模型缓存设置腾出空间给当前任务。最后分享一点实操心得折腾了差不多两个星期在换了不下二十组参数组合之后我目前在日常使用中固定的配置是expandable_segments:True,max_split_size_mb:64,garbage_collection_threshold:0.8。8G卡跑SD 1.5基本告别OOMSDXL也建立了“草图再放大”的工作流出图成功率可以用“稳定”来形容。最开始我也觉得换个16G卡一了百了但试过参数调优之后才明白软件优化能做到的事情远超很多人的预期。如果你现在也卡在OOM报错上不妨先花十分钟把这篇文章里的配置手动试一遍再决定要不要掏钱换显卡。实测下来这两个十分钟的成本差距可能是一张显卡的价格。