没有哪条规则规定模型一遇到显存不够就必须报错但现实中你跑 PyTorch 经常看到CUDA out of memory任务管理器里却明明还躺着一大块“共享 GPU 内存”。这个问题隔三差五就有人问显存不够时程序到底会不会自动用共享 GPU 内存我的结论很简单图形应用会深度学习框架默认不会就算能用速度也会掉到让你怀疑人生。这篇文章把机制、场景和实操一次性说清楚顺便帮低显存用户理一理跑本地大模型和绘图工作流时该怎么调。1. 先把“共享GPU内存”这个东西彻底讲清楚很多人的第一反应是打开任务管理器看到“专用 GPU 内存”旁边有个“共享 GPU 内存”数字还不小8GB、16GB都有于是以为这是显卡的备用显存。实际上这个理解从一开始就有偏差。1.1 任务管理器里那三行数字各代表什么以 Windows 10/11 为例在任务管理器 - 性能 - GPU 页面你会看到几行关键信息专用 GPU 内存显卡上物理存在的显存比如 RTX 3060 笔记本版经常标 6GB这里就是 6GB。共享 GPU 内存系统把物理内存DDR4/DDR5划出一部分默认通常是内存容量的一半左右。比如 32GB 内存显示共享 GPU 内存往往是 16GB。GPU 总容量专用显存加上共享 GPU 内存的总和。注意这只是一个“理论上限”不代表你的程序真的能完整使用。很多人看到那个 16GB 的共享 GPU 内存就以为“我其实有 22GB 显存可用”。这种理解是有问题的。共享 GPU 内存不是藏在显卡上的第二块显存它本质上是系统内存是借给 GPU 模块去访问的。Windows 图形驱动在 WDDMWindows Display Driver Model体系下允许 GPU 通过 PCIe 总线访问系统内存这部分配额显示为共享 GPU 内存。还有个容易混淆的地方如果你用的是 AMD 的核显或者某些 ARM 芯片芯片内部本身就是 CPU/GPU 共享同一块物理内存那属于统一内存架构和独显的“共享 GPU 内存”机制完全不是一回事。手机上的 GPU 也基本全是这种统一内存设计所以你看不到“共享 GPU 内存还剩多少”这种问题。1.2 共享GPU内存的本质是“借用系统内存”不是额外显存先打个比方显存相当于你桌子上的文件随拿随用手一伸就到了系统内存相当于房间角落的柜子得走过去打开柜子拿文件这中间每趟都要花时间。共享 GPU 内存就是系统给显卡开放的那部分“柜子使用权”文件依然放在柜子里而不是搬到桌子上。在 Windows 驱动模型下共享 GPU 内存的分配逻辑大致是这样的当显存快要不够用且系统内存压力不大时驱动可能把一些不会立刻用到的资源放到系统内存里比如纹理备份、后台缓冲区、某些缓存数据。这样一来程序不会立刻崩溃但一旦 GPU 需要访问这些数据就必须通过 PCIe 总线来回搬运。如果你去 NVIDIA 控制面板里翻会发现有一个“系统内存备用容量”之类的设置项调整的范围通常能到显存总量的好几倍。这里设置的其实就是驱动允许 GPU 占用的系统内存范围。但它主要影响图形驱动层面的分配和 CUDA 深度学习程序的关系不大后面会详细说。1.3 显存的位置和硬件结构决定了它的性能上限说到显存干脆把“显存位置”一并讲清楚。独立显卡上你能看到的那些小颗粒就是显存芯片。NVIDIA 的 RTX 40 系列大多使用 GDDR6X芯片分布在 GPU 核心周围通过显存控制器与核心通信专业卡和部分计算卡使用 HBM 显存堆叠在核心旁边带宽更高。显存之所以是“高速文件柜”是因为它距离 GPU 计算单元最近总线位宽又大比如 RTX 4090 的显存带宽能到每秒 1TB 左右而普通系统内存双通道 DDR5 也就每秒几十 GBPCIe 4.0 x16 单向理论带宽才 32GB/s。这个数量级差距直接决定了共享 GPU 内存“能应急但绝不能当主力”。2. 显存不够时不同场景下程序到底会不会用共享GPU内存这个问题不能一概而论。游戏、视频处理、深度学习框架、大模型推理运行时的行为完全不同。2.1 游戏和图形应用会但这是“兜底”而不是“加速”如果你玩 3A 游戏显存爆了之后一般不会立刻报错而是帧数骤降、地图加载变慢、场景贴图模糊甚至卡顿到像幻灯片。原因就是 Windows 图形驱动把一部分显存溢出的资源放到了共享 GPU 内存区域。画面还能继续输出是因为驱动在帮你兜底但每帧渲染都需要从系统内存里把纹理和缓冲数据捞回来PCIe 带宽就成了瓶颈。所以对游戏场景来说共享 GPU 内存确实会被调用但代价是性能直接崩盘。这也解释了为什么有些人说“我的显卡显示有 12GB 显存加 8GB 共享可一设置高画质还是卡”。因为从共享抬头的那一刻起实际有效带宽已经掉了好几个数量级GPU 核心再强也只能干等数据。2.2 PyTorch、TensorFlow、PaddleOCR 这类框架默认不会自动用这是很多人踩坑最深的地方。你跑一个 PyTorch 训练脚本显存不够时大概率直接报RuntimeError: CUDA out of memory. Tried to allocate 2.00 GiB哪怕任务管理器里共享 GPU 内存还剩一堆程序也不会自动把多出来的张量放到其中。原因在于 CUDA 驱动和 Windows 图形驱动走的是两套路径。PyTorch 等框架通过 CUDA 驱动程序直接向 GPU 申请显存CUDA 的显存分配器发现剩余物理显存不足时直接返回错误而不是悄悄把数据放入系统内存。有人会问不是有 CUDA Managed Memory统一内存吗确实CUDA 里有一种机制允许 GPU 和 CPU 共享内存地址空间数据可以在系统内存和显存之间自动迁移。但在主流深度学习框架里默认并不会开启这个功能。即使你手动用 Managed Memory 分配张量一旦超过物理显存性能也会惨不忍睹因为每次内核执行都要处理数据迁移开发效率和使用体验都很差。类似地PaddleOCR 的 GPU 版本、TensorFlow 等都是同样的逻辑。在显存不足时它们的第一反应是报错而不是偷偷调用共享 GPU 内存。所以“任务管理器里明明有共享 GPU 内存为什么深度学习还是 OOM”这个问题原因就在这里。2.3 Ollama 和 llama.cpp确实用了内存但属于“CPU/GPU 混跑”大模型推理这块和网页绘图不太一样。以 Ollama 为例它的底层是 llama.cpp。llama.cpp 有个特点加载模型时会把权重文件通过内存映射的方式打开模型层数中一部分放进显存放不下的部分留在系统内存里由 CPU 计算。你看到的“内存占用高”不是因为自动调用了共享 GPU 内存而是模型被拆成了两部分一部分给 GPU一部分给 CPU。具体点说你在 Ollama 里跑一个 7B 模型假设有 33 层transformer如果你有 6GB 显存可能 20 层放到了显存里剩下 13 层留在内存里由 CPU 推理。这时程序的响应速度取决于 CPU 算力和内存带宽明显会比全 GPU 推理慢。要想让更多层进显存可以设置环境变量OLLAMA_NUM_GPU或修改模型参数里的num_gpu。但如果你本身显存已经被占满强行把层数往显存里塞结果还是 OOM。所以准确说法是Ollama 不依赖“共享 GPU 内存”它天然支持 CPUGPU 混合推理利用的是普通系统内存。这比所谓的“共享 GPU 内存”更灵活也更容易理解。2.4 ComfyUI 的 Dynamic VRAM最接近“显存不够自动调用共享内存”的例子如果你是玩 Stable Diffusion 的一定听说过 ComfyUI 的dynamic_vram或者--dynamic-vram相关参数。ComfyUI 的机制和 PyTorch 原生逻辑又不一样它默认有一套显存管理策略很多版本里可以通过--lowvram、--novram或在设置里选择“Dynamic VRAM”模式。启用后当显存不足以放下一整批中间张量时ComfyUI 会把一部分临时数据放到系统内存里GPU 要用的时候再取回来。你也可以通过环境变量控制分页策略比如强制使用系统内存作为后备存储。这就是真正意义上的“把系统内存当显存分页用”但它不是 Windows 驱动层面的共享 GPU 内存而是应用层自己实现的 swap 机制。效果非常两极分化显存刚好差一点点时Dynamic VRAM 能帮你把 6GB 的卡跑出接近 8GB 的名堂但一旦大量张量开始进出系统内存生成速度会成倍变慢因为每多一次 paging就要多付一次 PCIe 传输的代价。如果你用的是 ComfyUI想要降低 OOM 概率除了开启 Dynamic VRAM还可以关掉部分批处理、启用 lowvram 模式、减少采样器中间缓存或者手动设置PYTORCH_CUDA_ALLOC_CONFgarbage_collection_threshold:0.8,max_split_size_mb:128来优化显存分配碎片。3. 共享GPU内存能救急但为什么慢得离谱既然它确实在某些场景里会用到那性能到底损失多少讲清楚这个问题你就能理解为什么我只把它当“急救方案”而不是日常方案。3.1 三档带宽的真实差距先看一组典型数据硬件路径典型带宽延迟特征GDDR6 显存如 RTX 3060 192-bit约 360 GB/s极低GDDR6X 显存如 RTX 4070/4090500 GB/s 到 1 TB/s极低DDR5 双通道内存约 60-90 GB/s中PCIe 4.0 x16 实际单向25-28 GB/s高PCIe 3.0 x16 实际单向12-14 GB/s更高注意当 GPU 访问所谓“共享 GPU 内存”时数据并不是直接从系统内存“飞”到 GPU 核心而是要走:内存控制器 - CPU - PCIe 控制器 - GPU 显存控制器 / GPU 核心。整条链路的瓶颈基本就是 PCIe 带宽和延迟。算一笔账如果你的模型权重有 4GB要从系统内存送到显存里跑一次推理在 PCIe 4.0 x16 下最快也要 0.15 秒左右还没算中间其他开销。如果每步推理都要这样搬运速度自然快不了。3.2 权重在内存里的真实体验拿本地大模型推理来说6GB 显存跑 7B Q4 量化模型如果全部放显存可能一秒能出 30-40 个 token。一旦模型层被塞到系统内存让 CPU 参与计算或反复搬运速度可能掉到一秒几个 token有些模型甚至会出现“打字机”式的卡顿输出——不是网络问题是数据搬运问题。ComfyUI 绘图同理。SDXL 模型在显存足够的显卡上生成一张 1024x1024 图可能只要 10 秒上下显存紧张、不断触发 Dynamic VRAM 后整个过程可能拖到 1 分钟甚至更久。你打开任务管理器也会看到一个很经典的画面GPU 使用率忽高忽低显存占用却顶在几乎满格CPU 内存和 GPU 占用都不算高但整个程序卡得像死机。很多人问“GPU、CPU、内存占用都不高但卡”大部分情况就是数据在内存和显存之间倒腾瞬时负载看起来不高每一步都在等传输。3.3 为什么显存带宽比内存带宽重要这么多AI 计算和传统 CPU 任务不一样它是典型的“高并发、数据密集”负载。GPU 成百上千个核心同时运算需要的数据都必须“喂”到嘴边。显存带宽就是喂食速度如果喂食通道从 1TB/s 降到 25GB/s即使 GPU 算力再强也是在高速发动机前面加了一根细管子。这也是为什么“大力出奇迹”这句老话在显卡上不成立——共享内存再大也解决不了带宽不足的根本问题。4. 低显存用户实操指南怎么判断、怎么调、怎么选模型离开机制层面落到实际操作。很多人的诉求很简单我就 6GB 显存还能不能愉快地玩本地大模型我该怎么判断问题出在哪4.1 动手前先给显卡做个体检不管遇到什么问题第一步都是先看显存到底被谁吃了。在 Windows 下可以用命令行执行nvidia-smi输出里会列出显卡型号、驱动版本、显存总量/已用/可用以及当前占用显存的进程。如果是多显卡机器怎么看程序正在用哪块 GPU可以用nvidia-smi -L列出所有 GPU 编号然后在运行 Python 或训练脚本时指定CUDA_VISIBLE_DEVICES0 python train.py在 Linux 下看硬件配置可以用lspci | grep -i vga lspci | grep -i nvidia如果你在 Windows 上打开任务管理器看到“GPU 0”和“GPU 1”一般一个是核显一个是独显GPU 编号不固定。你可以在任务管理器里看哪一个跑的是 3D 或 CUDA或者在 NVIDIA 控制面板里设置首选图形处理器。关于“显存检测 mats”和“显存测试软件U盘版”这两个热词我想多说一句。MatsNVIDIA Memory Test System是 NVIDIA 工程用的显存检测工具主要用于故障排查不是用来测“有多少显存可用”的。U盘版显存测试工具也是同样的目的是针对二手显卡、矿卡做显存颗粒检测用的。正常用户日常看显存占用不需要用到这些nvidia-smi 和任务管理器足矣。4.2 6G显存能跑什么模型16G显存32G内存能跑到什么程度这个问题非常典型。6GB 显存是目前笔记本的主流配置跑模型时要现实一点7B-8B 模型量化到 Q4_K_M 或 Q4_0模型文件大约 4.5GB-5GB可以放进 6GB 显存这是最稳妥的路线。比如 Ollama 安装后拉取qwen2.5:7b-instruct-q4_K_M或者llama3.1:8b-instruct-q4_K_M。9B 模型量化后大概 5.5GB 左右6GB 显存会非常紧张推理时如果上下文调得稍长就很容易 OOM。14B 模型量化后约 8-9GB6GB 显存强行跑需要把大量层留在内存里速度会很慢。如果是 16GB 显存 32GB 内存可以做不少事本地部署 13B-14B 的 Q4 量化模型比如qwen2.5:14b-instruct-q4_K_M体验不错。甚至 30B 左右的重量化模型Q3/Q4也可以硬着头皮跑代价是速度慢。要是你想跑 70B 模型16GB 显存完全不够内存 32GB 也不够得靠量化到 4bit 后还有 40GB 左右的模型文件才能启动基本要实现 CPUGPU 合力。真到这个规模不如直接考虑云 GPU。有个细节可以留意Ollama 里跑模型时日志会显示offloaded X/33 layers to GPU这句就是告诉你到底多少层真正在显存里。6GB 显存跑 7B 模型如果层数被“offload”得不多调低num_ctx到 2048 或 4096能显著降低缓存占用。4.3 PyTorch 和 Unsloth 训练时怎么省显存、怎么解决评估占满显存训练场景比推理更吃显存。以 LoRA 微调一个 9B 模型为例如果在 6GB 显存上跑常规全参数微调不可能。即使做 QLoRA 4bit也需要 8-12GB 显存左右。所以 6GB 想微调 9B 模型非常勉强16GB 会比较舒服。关键操作包括用 4bit 量化bitsandbytes库的BitsAndBytesConfig(load_in_4bitTrue)加载模型大幅降低权重和优化器状态占用。开梯度检查点调用model.gradient_checkpointing_enable()以增加少量计算为代价把激活值重算显存占用能省 50% 左右。混合精度PyTorch 里使用torch.cuda.amp.autocast()和GradScaler把 float32 降为 float16 / bfloat16显存占用立竿见影。控制 LoRA rankrank 从 16 降到 8显存占用也会下降一些。及时清理缓存每个 step 之后del掉不用的张量必要时调用torch.cuda.empty_cache()。但注意empty_cache()只是把缓存归还给 GPU driver不等于显存一定立刻减少到预期值偶尔调用即可。用 AdamW 8bit 或 SGD 而不是全精度 AdamW优化器状态占显存能少 3-4 倍。Unsloth 训练 LoRA 时很多人反馈“评估时总是占满显存导致速度很慢”。这不是错觉。评估阶段虽然包在torch.no_grad()里不需要保存梯度但评估时默认 batch size 如果太大依然会有大量中间张量同时存在。解决方法很简单把评估的 batch size 调小比如 1 或 2或者减少评估频率把eval_steps从 50 调到 200也可以把评估数据和训练数据一样做截断避免超长序列撑爆显存。另外评估时还可以临时把模型切到半精度推理模式不开 gradient checkpointing 也能省一点显存。4.4 本地实在跑不动怎么办云GPU和集群方案如果你试遍所有优化手段6GB 显存跑 30B 模型还是慢到不能忍那就得接受一个现实本地硬件有物理上限。这时候最省心的路是租云 GPU。租卡时别再只看“显存多大”还得看带宽。同一张 A100 可能被虚拟化成多种规格选卡时看显存带宽和实际卡型比单纯看“40GB”更可靠。至于 gpu 集群普通用户其实很难用起来需要分布式框架DeepSpeed ZeRO、FSDP和合理的网络拓扑。如果你想多卡并行训练代码和运维都得花不少功夫不是加几张卡就能自动加速的。我一般建议个人项目先单卡榨干再考虑多卡预算有限时上云比自建集群划算得多。5. 高频问题排查速查表与避坑心得最后把平时被问得最多的问题整理成一张表方便遇到问题对照处理。5.1 高频问题从现象到原因到处理现象可能原因处理思路任务管理器显示“共享 GPU 内存”很大但跑 PyTorch 还是报 CUDA OOMPyTorch 不会自动使用共享 GPU 内存CUDA 显存不足即报错降低 batch size、开混合精度、换更小模型或量化运行 Ollama 时内存占用很高GPU 显存也满了模型层部分在显存部分在内存由 CPU/GPU 混合推理调大num_gpu让更多层进显存或降低num_ctxComfyUI 绘图到一半提示显存不足显存确实不够Dynamic VRAM 没有覆盖所有临时张量开 lowvram 模式、换显存占用更小的 checkpoint、减少 batch sizenvidia-smi 看不到进程但显存占用高可能是残留的僵尸进程或驱动未释放显存Windows 下用taskkill /F /PID杀掉残留进程Linux 用fuser -v /dev/nvidia*查看游戏里显存没满但帧数暴跌可能驱动已经在用共享 GPU 内存或内存带宽不足降低纹理质量、关掉高清材质包检查虚拟内存是否过小GPU、CPU、内存占用都不高但程序卡数据在内存/显存/缓存间倒腾瓶颈在传输链路降低资源占用、换更快内存/显卡、减少序列长度和 batch5.2 我踩过坑之后的几条死规矩第一不要为了“扩大共享 GPU 内存”去手动改 Windows 虚拟内存大小。这个方法对 CUDA 程序几乎没用因为 PyTorch 等框架根本不走这条路径改了只会浪费磁盘空间。第二不要迷信 NVIDIA 控制面板里的“系统内存备用容量”。它影响的是图形驱动的资源分配对 CUDA 训练和推理没有决定作用。你把备用容量调大跑深度学习时该 OOM 还是 OOM。第三分清“核显共享显存”和“独显共享 GPU 内存”的区别。核显的“共享显存”本身是统一内存架构性能损失比独显跨 PCIe 访问小得多。如果你用的是笔记本双显卡注意程序别跑到核显上否则显存显示可能有误导性。第四看到显存不够先看进程再杀进程。很多情况下不是因为模型太大而是上一个训练脚本的进程还在后台占着显存尤其是 Windows 上 PyTorch 崩溃后有时不会立刻释放显存资源。第五6GB 显存跑本地大模型我的经验是优先追求“能跑”而不是“跑最大”。一个 Q4 量化的 7B 模型、2K 上下文日常聊天已经够用硬冲 30B 模型体验会很差还不如调用 API 或者用云 GPU。最后分享一个我很常用的小技巧用 Ollama 跑模型时如果想尽量把层都塞进显存可以打开一个命令行窗口运行ollama serve然后看启动日志里的offloaded层数。比如显示offloaded 25/33 layers to GPU说明还有 8 层在 CPU 上。如果显存还有余量加大OLLAMA_NUM_GPU或减少num_ctx把 25 层提到 30 层推理速度往往能明显提升。这个调法比盲目换卡更实在也是我在低显存刻板日子里觉得最值得掌握的方法。
没有哪条规则规定模型一遇到显存不够就必须报错但现实中你跑 PyTorch 经常看到CUDA out of memory任务管理器里却明明还躺着一大块“共享 GPU 内存”。这个问题隔三差五就有人问显存不够时程序到底会不会自动用共享 GPU 内存我的结论很简单图形应用会深度学习框架默认不会就算能用速度也会掉到让你怀疑人生。这篇文章把机制、场景和实操一次性说清楚顺便帮低显存用户理一理跑本地大模型和绘图工作流时该怎么调。1. 先把“共享GPU内存”这个东西彻底讲清楚很多人的第一反应是打开任务管理器看到“专用 GPU 内存”旁边有个“共享 GPU 内存”数字还不小8GB、16GB都有于是以为这是显卡的备用显存。实际上这个理解从一开始就有偏差。1.1 任务管理器里那三行数字各代表什么以 Windows 10/11 为例在任务管理器 - 性能 - GPU 页面你会看到几行关键信息专用 GPU 内存显卡上物理存在的显存比如 RTX 3060 笔记本版经常标 6GB这里就是 6GB。共享 GPU 内存系统把物理内存DDR4/DDR5划出一部分默认通常是内存容量的一半左右。比如 32GB 内存显示共享 GPU 内存往往是 16GB。GPU 总容量专用显存加上共享 GPU 内存的总和。注意这只是一个“理论上限”不代表你的程序真的能完整使用。很多人看到那个 16GB 的共享 GPU 内存就以为“我其实有 22GB 显存可用”。这种理解是有问题的。共享 GPU 内存不是藏在显卡上的第二块显存它本质上是系统内存是借给 GPU 模块去访问的。Windows 图形驱动在 WDDMWindows Display Driver Model体系下允许 GPU 通过 PCIe 总线访问系统内存这部分配额显示为共享 GPU 内存。还有个容易混淆的地方如果你用的是 AMD 的核显或者某些 ARM 芯片芯片内部本身就是 CPU/GPU 共享同一块物理内存那属于统一内存架构和独显的“共享 GPU 内存”机制完全不是一回事。手机上的 GPU 也基本全是这种统一内存设计所以你看不到“共享 GPU 内存还剩多少”这种问题。1.2 共享GPU内存的本质是“借用系统内存”不是额外显存先打个比方显存相当于你桌子上的文件随拿随用手一伸就到了系统内存相当于房间角落的柜子得走过去打开柜子拿文件这中间每趟都要花时间。共享 GPU 内存就是系统给显卡开放的那部分“柜子使用权”文件依然放在柜子里而不是搬到桌子上。在 Windows 驱动模型下共享 GPU 内存的分配逻辑大致是这样的当显存快要不够用且系统内存压力不大时驱动可能把一些不会立刻用到的资源放到系统内存里比如纹理备份、后台缓冲区、某些缓存数据。这样一来程序不会立刻崩溃但一旦 GPU 需要访问这些数据就必须通过 PCIe 总线来回搬运。如果你去 NVIDIA 控制面板里翻会发现有一个“系统内存备用容量”之类的设置项调整的范围通常能到显存总量的好几倍。这里设置的其实就是驱动允许 GPU 占用的系统内存范围。但它主要影响图形驱动层面的分配和 CUDA 深度学习程序的关系不大后面会详细说。1.3 显存的位置和硬件结构决定了它的性能上限说到显存干脆把“显存位置”一并讲清楚。独立显卡上你能看到的那些小颗粒就是显存芯片。NVIDIA 的 RTX 40 系列大多使用 GDDR6X芯片分布在 GPU 核心周围通过显存控制器与核心通信专业卡和部分计算卡使用 HBM 显存堆叠在核心旁边带宽更高。显存之所以是“高速文件柜”是因为它距离 GPU 计算单元最近总线位宽又大比如 RTX 4090 的显存带宽能到每秒 1TB 左右而普通系统内存双通道 DDR5 也就每秒几十 GBPCIe 4.0 x16 单向理论带宽才 32GB/s。这个数量级差距直接决定了共享 GPU 内存“能应急但绝不能当主力”。2. 显存不够时不同场景下程序到底会不会用共享GPU内存这个问题不能一概而论。游戏、视频处理、深度学习框架、大模型推理运行时的行为完全不同。2.1 游戏和图形应用会但这是“兜底”而不是“加速”如果你玩 3A 游戏显存爆了之后一般不会立刻报错而是帧数骤降、地图加载变慢、场景贴图模糊甚至卡顿到像幻灯片。原因就是 Windows 图形驱动把一部分显存溢出的资源放到了共享 GPU 内存区域。画面还能继续输出是因为驱动在帮你兜底但每帧渲染都需要从系统内存里把纹理和缓冲数据捞回来PCIe 带宽就成了瓶颈。所以对游戏场景来说共享 GPU 内存确实会被调用但代价是性能直接崩盘。这也解释了为什么有些人说“我的显卡显示有 12GB 显存加 8GB 共享可一设置高画质还是卡”。因为从共享抬头的那一刻起实际有效带宽已经掉了好几个数量级GPU 核心再强也只能干等数据。2.2 PyTorch、TensorFlow、PaddleOCR 这类框架默认不会自动用这是很多人踩坑最深的地方。你跑一个 PyTorch 训练脚本显存不够时大概率直接报RuntimeError: CUDA out of memory. Tried to allocate 2.00 GiB哪怕任务管理器里共享 GPU 内存还剩一堆程序也不会自动把多出来的张量放到其中。原因在于 CUDA 驱动和 Windows 图形驱动走的是两套路径。PyTorch 等框架通过 CUDA 驱动程序直接向 GPU 申请显存CUDA 的显存分配器发现剩余物理显存不足时直接返回错误而不是悄悄把数据放入系统内存。有人会问不是有 CUDA Managed Memory统一内存吗确实CUDA 里有一种机制允许 GPU 和 CPU 共享内存地址空间数据可以在系统内存和显存之间自动迁移。但在主流深度学习框架里默认并不会开启这个功能。即使你手动用 Managed Memory 分配张量一旦超过物理显存性能也会惨不忍睹因为每次内核执行都要处理数据迁移开发效率和使用体验都很差。类似地PaddleOCR 的 GPU 版本、TensorFlow 等都是同样的逻辑。在显存不足时它们的第一反应是报错而不是偷偷调用共享 GPU 内存。所以“任务管理器里明明有共享 GPU 内存为什么深度学习还是 OOM”这个问题原因就在这里。2.3 Ollama 和 llama.cpp确实用了内存但属于“CPU/GPU 混跑”大模型推理这块和网页绘图不太一样。以 Ollama 为例它的底层是 llama.cpp。llama.cpp 有个特点加载模型时会把权重文件通过内存映射的方式打开模型层数中一部分放进显存放不下的部分留在系统内存里由 CPU 计算。你看到的“内存占用高”不是因为自动调用了共享 GPU 内存而是模型被拆成了两部分一部分给 GPU一部分给 CPU。具体点说你在 Ollama 里跑一个 7B 模型假设有 33 层transformer如果你有 6GB 显存可能 20 层放到了显存里剩下 13 层留在内存里由 CPU 推理。这时程序的响应速度取决于 CPU 算力和内存带宽明显会比全 GPU 推理慢。要想让更多层进显存可以设置环境变量OLLAMA_NUM_GPU或修改模型参数里的num_gpu。但如果你本身显存已经被占满强行把层数往显存里塞结果还是 OOM。所以准确说法是Ollama 不依赖“共享 GPU 内存”它天然支持 CPUGPU 混合推理利用的是普通系统内存。这比所谓的“共享 GPU 内存”更灵活也更容易理解。2.4 ComfyUI 的 Dynamic VRAM最接近“显存不够自动调用共享内存”的例子如果你是玩 Stable Diffusion 的一定听说过 ComfyUI 的dynamic_vram或者--dynamic-vram相关参数。ComfyUI 的机制和 PyTorch 原生逻辑又不一样它默认有一套显存管理策略很多版本里可以通过--lowvram、--novram或在设置里选择“Dynamic VRAM”模式。启用后当显存不足以放下一整批中间张量时ComfyUI 会把一部分临时数据放到系统内存里GPU 要用的时候再取回来。你也可以通过环境变量控制分页策略比如强制使用系统内存作为后备存储。这就是真正意义上的“把系统内存当显存分页用”但它不是 Windows 驱动层面的共享 GPU 内存而是应用层自己实现的 swap 机制。效果非常两极分化显存刚好差一点点时Dynamic VRAM 能帮你把 6GB 的卡跑出接近 8GB 的名堂但一旦大量张量开始进出系统内存生成速度会成倍变慢因为每多一次 paging就要多付一次 PCIe 传输的代价。如果你用的是 ComfyUI想要降低 OOM 概率除了开启 Dynamic VRAM还可以关掉部分批处理、启用 lowvram 模式、减少采样器中间缓存或者手动设置PYTORCH_CUDA_ALLOC_CONFgarbage_collection_threshold:0.8,max_split_size_mb:128来优化显存分配碎片。3. 共享GPU内存能救急但为什么慢得离谱既然它确实在某些场景里会用到那性能到底损失多少讲清楚这个问题你就能理解为什么我只把它当“急救方案”而不是日常方案。3.1 三档带宽的真实差距先看一组典型数据硬件路径典型带宽延迟特征GDDR6 显存如 RTX 3060 192-bit约 360 GB/s极低GDDR6X 显存如 RTX 4070/4090500 GB/s 到 1 TB/s极低DDR5 双通道内存约 60-90 GB/s中PCIe 4.0 x16 实际单向25-28 GB/s高PCIe 3.0 x16 实际单向12-14 GB/s更高注意当 GPU 访问所谓“共享 GPU 内存”时数据并不是直接从系统内存“飞”到 GPU 核心而是要走:内存控制器 - CPU - PCIe 控制器 - GPU 显存控制器 / GPU 核心。整条链路的瓶颈基本就是 PCIe 带宽和延迟。算一笔账如果你的模型权重有 4GB要从系统内存送到显存里跑一次推理在 PCIe 4.0 x16 下最快也要 0.15 秒左右还没算中间其他开销。如果每步推理都要这样搬运速度自然快不了。3.2 权重在内存里的真实体验拿本地大模型推理来说6GB 显存跑 7B Q4 量化模型如果全部放显存可能一秒能出 30-40 个 token。一旦模型层被塞到系统内存让 CPU 参与计算或反复搬运速度可能掉到一秒几个 token有些模型甚至会出现“打字机”式的卡顿输出——不是网络问题是数据搬运问题。ComfyUI 绘图同理。SDXL 模型在显存足够的显卡上生成一张 1024x1024 图可能只要 10 秒上下显存紧张、不断触发 Dynamic VRAM 后整个过程可能拖到 1 分钟甚至更久。你打开任务管理器也会看到一个很经典的画面GPU 使用率忽高忽低显存占用却顶在几乎满格CPU 内存和 GPU 占用都不算高但整个程序卡得像死机。很多人问“GPU、CPU、内存占用都不高但卡”大部分情况就是数据在内存和显存之间倒腾瞬时负载看起来不高每一步都在等传输。3.3 为什么显存带宽比内存带宽重要这么多AI 计算和传统 CPU 任务不一样它是典型的“高并发、数据密集”负载。GPU 成百上千个核心同时运算需要的数据都必须“喂”到嘴边。显存带宽就是喂食速度如果喂食通道从 1TB/s 降到 25GB/s即使 GPU 算力再强也是在高速发动机前面加了一根细管子。这也是为什么“大力出奇迹”这句老话在显卡上不成立——共享内存再大也解决不了带宽不足的根本问题。4. 低显存用户实操指南怎么判断、怎么调、怎么选模型离开机制层面落到实际操作。很多人的诉求很简单我就 6GB 显存还能不能愉快地玩本地大模型我该怎么判断问题出在哪4.1 动手前先给显卡做个体检不管遇到什么问题第一步都是先看显存到底被谁吃了。在 Windows 下可以用命令行执行nvidia-smi输出里会列出显卡型号、驱动版本、显存总量/已用/可用以及当前占用显存的进程。如果是多显卡机器怎么看程序正在用哪块 GPU可以用nvidia-smi -L列出所有 GPU 编号然后在运行 Python 或训练脚本时指定CUDA_VISIBLE_DEVICES0 python train.py在 Linux 下看硬件配置可以用lspci | grep -i vga lspci | grep -i nvidia如果你在 Windows 上打开任务管理器看到“GPU 0”和“GPU 1”一般一个是核显一个是独显GPU 编号不固定。你可以在任务管理器里看哪一个跑的是 3D 或 CUDA或者在 NVIDIA 控制面板里设置首选图形处理器。关于“显存检测 mats”和“显存测试软件U盘版”这两个热词我想多说一句。MatsNVIDIA Memory Test System是 NVIDIA 工程用的显存检测工具主要用于故障排查不是用来测“有多少显存可用”的。U盘版显存测试工具也是同样的目的是针对二手显卡、矿卡做显存颗粒检测用的。正常用户日常看显存占用不需要用到这些nvidia-smi 和任务管理器足矣。4.2 6G显存能跑什么模型16G显存32G内存能跑到什么程度这个问题非常典型。6GB 显存是目前笔记本的主流配置跑模型时要现实一点7B-8B 模型量化到 Q4_K_M 或 Q4_0模型文件大约 4.5GB-5GB可以放进 6GB 显存这是最稳妥的路线。比如 Ollama 安装后拉取qwen2.5:7b-instruct-q4_K_M或者llama3.1:8b-instruct-q4_K_M。9B 模型量化后大概 5.5GB 左右6GB 显存会非常紧张推理时如果上下文调得稍长就很容易 OOM。14B 模型量化后约 8-9GB6GB 显存强行跑需要把大量层留在内存里速度会很慢。如果是 16GB 显存 32GB 内存可以做不少事本地部署 13B-14B 的 Q4 量化模型比如qwen2.5:14b-instruct-q4_K_M体验不错。甚至 30B 左右的重量化模型Q3/Q4也可以硬着头皮跑代价是速度慢。要是你想跑 70B 模型16GB 显存完全不够内存 32GB 也不够得靠量化到 4bit 后还有 40GB 左右的模型文件才能启动基本要实现 CPUGPU 合力。真到这个规模不如直接考虑云 GPU。有个细节可以留意Ollama 里跑模型时日志会显示offloaded X/33 layers to GPU这句就是告诉你到底多少层真正在显存里。6GB 显存跑 7B 模型如果层数被“offload”得不多调低num_ctx到 2048 或 4096能显著降低缓存占用。4.3 PyTorch 和 Unsloth 训练时怎么省显存、怎么解决评估占满显存训练场景比推理更吃显存。以 LoRA 微调一个 9B 模型为例如果在 6GB 显存上跑常规全参数微调不可能。即使做 QLoRA 4bit也需要 8-12GB 显存左右。所以 6GB 想微调 9B 模型非常勉强16GB 会比较舒服。关键操作包括用 4bit 量化bitsandbytes库的BitsAndBytesConfig(load_in_4bitTrue)加载模型大幅降低权重和优化器状态占用。开梯度检查点调用model.gradient_checkpointing_enable()以增加少量计算为代价把激活值重算显存占用能省 50% 左右。混合精度PyTorch 里使用torch.cuda.amp.autocast()和GradScaler把 float32 降为 float16 / bfloat16显存占用立竿见影。控制 LoRA rankrank 从 16 降到 8显存占用也会下降一些。及时清理缓存每个 step 之后del掉不用的张量必要时调用torch.cuda.empty_cache()。但注意empty_cache()只是把缓存归还给 GPU driver不等于显存一定立刻减少到预期值偶尔调用即可。用 AdamW 8bit 或 SGD 而不是全精度 AdamW优化器状态占显存能少 3-4 倍。Unsloth 训练 LoRA 时很多人反馈“评估时总是占满显存导致速度很慢”。这不是错觉。评估阶段虽然包在torch.no_grad()里不需要保存梯度但评估时默认 batch size 如果太大依然会有大量中间张量同时存在。解决方法很简单把评估的 batch size 调小比如 1 或 2或者减少评估频率把eval_steps从 50 调到 200也可以把评估数据和训练数据一样做截断避免超长序列撑爆显存。另外评估时还可以临时把模型切到半精度推理模式不开 gradient checkpointing 也能省一点显存。4.4 本地实在跑不动怎么办云GPU和集群方案如果你试遍所有优化手段6GB 显存跑 30B 模型还是慢到不能忍那就得接受一个现实本地硬件有物理上限。这时候最省心的路是租云 GPU。租卡时别再只看“显存多大”还得看带宽。同一张 A100 可能被虚拟化成多种规格选卡时看显存带宽和实际卡型比单纯看“40GB”更可靠。至于 gpu 集群普通用户其实很难用起来需要分布式框架DeepSpeed ZeRO、FSDP和合理的网络拓扑。如果你想多卡并行训练代码和运维都得花不少功夫不是加几张卡就能自动加速的。我一般建议个人项目先单卡榨干再考虑多卡预算有限时上云比自建集群划算得多。5. 高频问题排查速查表与避坑心得最后把平时被问得最多的问题整理成一张表方便遇到问题对照处理。5.1 高频问题从现象到原因到处理现象可能原因处理思路任务管理器显示“共享 GPU 内存”很大但跑 PyTorch 还是报 CUDA OOMPyTorch 不会自动使用共享 GPU 内存CUDA 显存不足即报错降低 batch size、开混合精度、换更小模型或量化运行 Ollama 时内存占用很高GPU 显存也满了模型层部分在显存部分在内存由 CPU/GPU 混合推理调大num_gpu让更多层进显存或降低num_ctxComfyUI 绘图到一半提示显存不足显存确实不够Dynamic VRAM 没有覆盖所有临时张量开 lowvram 模式、换显存占用更小的 checkpoint、减少 batch sizenvidia-smi 看不到进程但显存占用高可能是残留的僵尸进程或驱动未释放显存Windows 下用taskkill /F /PID杀掉残留进程Linux 用fuser -v /dev/nvidia*查看游戏里显存没满但帧数暴跌可能驱动已经在用共享 GPU 内存或内存带宽不足降低纹理质量、关掉高清材质包检查虚拟内存是否过小GPU、CPU、内存占用都不高但程序卡数据在内存/显存/缓存间倒腾瓶颈在传输链路降低资源占用、换更快内存/显卡、减少序列长度和 batch5.2 我踩过坑之后的几条死规矩第一不要为了“扩大共享 GPU 内存”去手动改 Windows 虚拟内存大小。这个方法对 CUDA 程序几乎没用因为 PyTorch 等框架根本不走这条路径改了只会浪费磁盘空间。第二不要迷信 NVIDIA 控制面板里的“系统内存备用容量”。它影响的是图形驱动的资源分配对 CUDA 训练和推理没有决定作用。你把备用容量调大跑深度学习时该 OOM 还是 OOM。第三分清“核显共享显存”和“独显共享 GPU 内存”的区别。核显的“共享显存”本身是统一内存架构性能损失比独显跨 PCIe 访问小得多。如果你用的是笔记本双显卡注意程序别跑到核显上否则显存显示可能有误导性。第四看到显存不够先看进程再杀进程。很多情况下不是因为模型太大而是上一个训练脚本的进程还在后台占着显存尤其是 Windows 上 PyTorch 崩溃后有时不会立刻释放显存资源。第五6GB 显存跑本地大模型我的经验是优先追求“能跑”而不是“跑最大”。一个 Q4 量化的 7B 模型、2K 上下文日常聊天已经够用硬冲 30B 模型体验会很差还不如调用 API 或者用云 GPU。最后分享一个我很常用的小技巧用 Ollama 跑模型时如果想尽量把层都塞进显存可以打开一个命令行窗口运行ollama serve然后看启动日志里的offloaded层数。比如显示offloaded 25/33 layers to GPU说明还有 8 层在 CPU 上。如果显存还有余量加大OLLAMA_NUM_GPU或减少num_ctx把 25 层提到 30 层推理速度往往能明显提升。这个调法比盲目换卡更实在也是我在低显存刻板日子里觉得最值得掌握的方法。
