单张RTX显卡同时跑Ollama与ComfyUI不爆显存的实战指南

在家庭实验室里，很多人既想用 Ollama 跑本地大模型做代码助手，又想用 ComfyUI 生成 Stable Diffusion 图像。问题是，大多数人只有一张 16GB 显存的消费级显卡（比如 RTX 5060 Ti），两个吃显存大户同时抢占资源，极易触发 OOM（Out of Memory）崩溃。这篇文章基于实际配置经验，拆解如何让一张显卡优雅地服务两个工作负载。

Ollama GPU 调度与 ComfyUI 共享单张 RTX 显卡

先算清楚账：16GB 显存到底能装多少

任何共享策略的前提，是先搞清楚每个应用实际消耗多少显存。盲目启动只会换来频繁的崩溃日志。

Ollama 的显存占用（量化后）

以常见的 Q4_K_M 量化为参考：

Qwen2.5-Coder:14b / DeepSeek^广告-R1:14b：约 7.5GB
Llama3.1:8b / Qwen3:8b：约 4.5GB
Nomic-Embed-Text 嵌入模型：约 1.2GB
系统开销 + CUDA 上下文：约 1-2GB

量化（Quantization）是将模型权重从高精度浮点数（如 FP16/FP32）压缩为低比特整数表示的技术。Q4_K_M 中的"Q4"表示每个权重用 4 位整数存储（相比 FP16 的 16 位，体积约缩小 75%），"K"代表采用 K-quants 分组量化算法（对不同层分别优化精度），"M"表示中等精度档位（介于 Small 和 Large 之间）。GGUF 格式的量化模型由 llama.cpp 项目定义，Ollama 底层即基于 llama.cpp 运行，因此直接支持这套命名体系。量化不可避免地带来精度损失，但对大多数日常任务而言，Q4_K_M 与 FP16 的输出差异在主观体验上几乎可以忽略，而显存节省却非常可观——这正是它成为家庭实验室首选的原因。

ComfyUI 的显存占用

Stable Diffusion 这边的变量更多：

ComfyUI 基础 + VAE：约 1.5-2GB
SDXL（1024×1024）：约 6-8GB
SD 1.5（512×512）：约 3-4GB
每个 ControlNet 单元：额外 1-2GB
Hi-Res 修复 + 放大：额外 2-4GB

几种组合能不能跑得起来

把这些数字拼起来，就能预判成败：

Ollama 14b + SDXL 1024×1024 ≈ 14.5GB（勉强可行，边界紧张）
Ollama 14b + SD 1.5 + ControlNet ≈ 13.5GB（舒适区间）
两个 14b 模型 ≈ 15GB（只剩 1GB 给系统，不推荐）
Ollama 14b + SDXL + Hi-Res + ControlNet：大概率 OOM

这组对照表的价值在于，它把"能不能同时跑"这个模糊问题，变成了可以提前计算的加法题。

调度策略：按时间分段还是按优先级抢占

显存是物理约束，无法凭空扩容，所以核心思路是让两个应用"错峰"或"分级"使用。

策略一：基于时间的调度（排班制）

给每个应用分配明确的时间窗口。例如工作时段（6:00-10:00、14:00-18:00）优先给 Ollama 做代码助手，创意时段（10:00-12:00、18:00-22:00）优先给 ComfyUI，夜间则交给 Ollama 跑后台嵌入计算。实现上可以用 systemd 定时器或 cron，配合 gpu-grant / gpu-revoke 脚本切换权限。

这种方式的优点是可预测、实现简单，缺点是不够灵活——如果你在创意时段突然需要查一段代码，就得等窗口切换。

策略二：基于优先级的抢占（预约制）

另一种思路是让应用主动申请 GPU 访问权，由一个"仲裁器"（arbiter）根据优先级分配。文章给出的伪代码设计了三级优先级：交互式用户请求（优先级 10，如即时聊天或出图）、后台处理（优先级 5，如嵌入和批处理）、维护任务（优先级 1）。

每个应用在调用生成前先 requestAccess，用完后 releaseAccess，高优先级请求可以抢占低优先级的持有者。这种设计更贴近真实使用场景——交互永远比后台任务更紧急。

这种仲裁器模式在设计上借鉴了操作系统的资源调度思想。GPU 本身并不像 CPU 那样内置抢占式调度器——NVIDIA 的 MPS（Multi-Process Service）和 MIG（Multi-Instance GPU）虽然提供了一定程度的多进程共享能力，但 MIG 仅在数据中心级卡（如 A100、H100）上可用，消费级 RTX 卡不支持。MPS 可以让多个 CUDA 进程共享 GPU，但并不提供优先级抢占，且在进程之间缺乏显存隔离保障。因此，文章描述的仲裁器方案是在应用层以软件方式实现调度逻辑，通过令牌（token）或锁（lock）机制序列化对 GPU 的访问，从而绕开底层缺乏细粒度调度支持的限制。

显存分区：静态切分还是动态管理

除了时间维度，还可以从空间维度切分显存。

静态分区（固定切分）

预先划定每个应用的显存上限，谁都不越界。文章给出三种典型配比：

7GB/9GB（Ollama 偏重）：Ollama 跑 14b 模型，ComfyUI 跑 SDXL + 单 ControlNet，适合以编码辅助为主的开发工作
5GB/11GB（均衡）：Ollama 跑 8b 模型，ComfyUI 可用多 ControlNet + Hi-Res 修复
3GB/13GB（ComfyUI 偏重）：Ollama 只做嵌入或极小模型，ComfyUI 专注批量出图和视频生成

静态分区的硬伤在于：空闲应用的配额被白白浪费、无法应对突发负载、调整配比需要重启应用，而且在 CUDA/Vulkan 层面正确实现相当复杂。

动态分区（更推荐）

更务实的做法是允许应用使用可用显存，但设置软限制和监控。文章提供了一个基于 nvidia-smi 的 Python 监控脚本思路：实时读取显存使用率，超过 80% 提示、超过 90% 告警、接近 95% 时可触发清理或通知。

对多数家庭实验室用户，作者给出的实用动态策略是：白天用 8b 小模型做日常辅助，专门的 LLM 会话时切换到 14b；ComfyUI 平时用中等设置，极限参数留给专门的创作时段；始终开着显存监控避免意外。

量化：提升显存效率的最佳杠杆

选对量化等级，能决定你的配置"装得下"还是"跑不动"。以 14b 模型为例：

量化	显存占用	质量影响
Q8_0	~10.5GB	极小
Q6_K	~9.0GB	很微小
Q5_K_M	~7.8GB	轻微
Q4_K_M	~7.5GB	可察觉但可接受
Q3_K_M	~6.2GB	中等
Q2_K	~5.0GB	明显

实用建议很清晰：代码辅助用 Q4_K_M 或 Q5_K_M；数学逻辑任务用 Q5_K_M 或 Q6_K 以保证推理质量；闲聊可用 Q3_K_M 甚至 Q2_K 省显存；嵌入模型始终用量化版；除非你有 24GB 以上显存，否则避免 F16 浮点。你甚至可以为同一个模型拉取多个量化版本，按当前需求随时切换。

ComfyUI 优化：榨干有限显存

Stable Diffusion 侧有大量可调旋钮：

能用 SD 1.5 就别上 SDXL，显存直接省掉约一半
启用注意力切片（attention slicing），用算力换显存
开启 VAE 分块（VAE tiling），分块处理降低峰值显存
限制 ControlNet 单元数量，每多一个加 1-2GB
批次大小保持为 1
启用模型卸载，把闲置组件移到内存
使用 xformers 更省显存的注意力实现

分辨率对显存的影响同样显著。SD 1.5 下 512×512 仅需约 3.5GB，而 1024×1024 配 Hi-Res 修复会飙到约 12GB；SDXL 则更吃显存，1280×720 配 Hi-Res 可达约 15GB，在 16GB 卡上已是极限。启动时加上 --medvram 参数并配置 PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128 缓解内存碎片，是常见的保命操作。

注意力切片（Attention Slicing）和 xformers 都针对 Transformer 架构中计算开销最大的自注意力操作。标准自注意力的显存复杂度与序列长度的平方成正比，在高分辨率图像生成时尤为突出。注意力切片将注意力头拆分为多个批次逐步计算，以更多计算步骤换取更低的峰值显存占用。xformers 则通过 Flash Attention 等融合算子，在数学等价的前提下大幅降低中间张量的显存占用并提升计算速度，二者可以叠加使用。VAE 分块（VAE Tiling）则作用于图像的编码/解码阶段：高分辨率图像经 VAE 解码时会产生巨大的中间张量，分块处理将其切成小块分批解码，有效压制峰值显存，代价是轻微增加处理时间。

队列管理与监控：防止资源耗尽

即便调度得当，并发请求仍可能瞬间顶爆显存。文章给出了 Ollama 请求队列和 ComfyUI 任务队列的实现思路，核心都是 max_concurrent=1 的串行处理——确保同一时刻只有一个重任务占用 GPU，并支持按优先级插队。

监控层面，需要盯住的关键指标包括：显存使用量（80%/90%/95% 三级告警）、GPU 利用率、温度（超过 80°C 告警防降频）、功耗、应用响应时间、队列深度和错误率。作者提供的监控脚本通过 nvidia-smi 读取整卡状态，并访问 Ollama 的 /api/tags 和 ComfyUI 的本地端口做健康检查，一旦无响应立即告警。

排障：几类高频问题的应对

频繁 OOM：实现优雅降级——捕获 CUDA OOM 异常后，自动用更短的 max_length 重试，宁可降质量也不崩溃。

切换时性能骤降：多因模型重载和显存碎片，可通过保持模型热加载、使用 NVMe 快速存储、准备多量化模型池来缓解。

应用无响应：引入心跳机制、无响应 N 秒后自动重启、为每个应用配健康检查端点。

显存碎片：定期垃圾回收、在 PyTorch 应用里调用 torch.cuda.empty_cache()、必要时重启应用做碎片整理。

写在最后

作者的核心观点值得记住：目标不是让两个系统同时满载运行——那在消费级硬件上根本不现实；真正的目标是让两套系统在你需要时都可用，性能可预测、使用无挫败感。

推荐的起步配置是：Ollama 跑 Qwen2.5-Coder:14b-q4_K_M 或 Llama3.1:8b-q4_K_M；ComfyUI 用 SD 1.5 并开启注意力切片和 VAE 分块；调度采用时间分段 + 优先级抢占；监控做好显存告警和健康检查；工作流上尽量把同类任务打包处理，减少上下文切换成本。

凭借精心的调度、合理的模型选择和基础监控，一张 RTX 5060 Ti 完全可以胜任开发与创作兼顾的双用途 AI 工作站。

背景补充

显存碎片（Memory Fragmentation）是 GPU 内存管理中的常见问题：频繁分配和释放不同大小的张量后，空闲显存被分割成大量不连续的小块，即使总空闲量充足，也无法满足需要连续大块显存的单次分配请求，进而触发 OOM。PyTorch 的 CUDA 内存分配器默认使用缓存池来缓解这一问题，torch.cuda.empty_cache() 会将缓存池中的空闲块归还给 CUDA，使其对其他进程可见，但并不整理已分配内存的布局。PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128 则限制分配器切割大内存块的最大粒度，减少细碎化程度。在 Ollama 与 ComfyUI 交替使用的场景下，两个进程各自持有缓存但不释放，正是加剧碎片的主要原因，因此在切换工作负载前主动触发清理或重启进程是有实际意义的操作。