把本地 AI 跑起来这件事最烦的不是模型本身而是工具链东拼西凑、环境互相打架。Open WebUI、Ollama、ComfyUI 这三个项目过去一年我反复部署了不下十几次踩过的坑足够写满两页笔记。这篇文章干脆把完整流程沉淀下来Ollama 负责后台推理Open WebUI 负责聊天界面ComfyUI 负责图像生成的节点化流水线三套系统怎么各自装好、再安全地串起来每一步都给到可以直接抄的配置和命令。适合刚接触本地大模型、想在个人电脑或内网服务器上搭一套完整 AI 工作台的朋友也适合被报错折磨到想放弃的折腾党。1. 项目概述与整体思路1.1 三件套的定位推理、对话与图像生成很多人第一次接触这三个名词时容易把它们当成三个同类工具来回比较其实分工完全不同。Ollama 是底层的大模型运行引擎。它把 llama.cpp 这类推理后端封装成简洁的命令行和 HTTP API你只需要ollama run qwen2.5就能拉起一个本地模型默认监听本机的 11434 端口。它解决的是模型怎么跑起来的问题本身不提供好看的界面。Open WebUI 是一个自托管的网页聊天界面早期叫 Ollama WebUI后来改名并扩展成支持多种后端的前端项目。它默认通过 3000 端口提供 Web 服务页面风格接近 ChatGPT支持多用户登录、对话历史、知识库附件和模型管理。它解决的是怎么舒服地和大模型聊天的问题。ComfyUI 则完全是另一条赛道基于节点的工作流式图像生成工具。它把文生图、图生图、局部重绘这些操作拆成一个个可视化节点由用户拖拽连线组成流水线。它解决的是怎么精细控制图像生成过程的问题背后依赖 PyTorch 和各类扩散模型。这三者原本互不依赖但组合起来非常有意思Ollama 跑一个文本模型负责理解和总结Open WebUI 提供统一入口ComfyUI 在旁边处理图像。比如你在 Open WebUI 里让文本模型分析一张图的需求描述再把优化后的提示词手动或通过脚本喂给 ComfyUI 生成素材一套本地 AI 工作台就成型了。1.2 为什么选择这套组合而不是全家桶市面上其实有更省事的方案比如一键整合包、各种 AI 桌面包但我仍然推荐拆开部署理由有三点。第一故障隔离。Ollama 的显存占用、Open WebUI 的 Node 服务、ComfyUI 的 PyTorch 进程三者各自独立崩溃互不拖累。整合包一旦某个依赖升级出问题往往需要整体重装排查成本反而更高。第二升级灵活。Ollama 几乎每周都有新版本ComfyUI 的插件生态更新极快拆开部署可以分别跟进不至于为了更新一个组件被迫停掉整套服务。第三资源可控。文本模型和图像模型对显存的需求差异很大分开部署意味着你可以给 Ollama 分配 CPU 推理或小显存模型而把 GPU 主要留给 ComfyUI 出图避免同时抢占显存导致双双崩溃。我自己在 8GB 显存的笔记本上就是这个策略Ollama 跑 7B 级别的量化模型ComfyUI 用 SDXL 出图二者错开使用。2. 环境准备与基础安装2.1 硬件评估与系统选型在动手装之前先对自己的机器做一个合理预期否则装完跑不动会非常打击信心。文本模型方面Ollama 的显存需求主要看模型参数量和量化位数。7B 模型的 Q4 量化版本大约需要 4 到 6GB 显存8GB 显存的显卡可以流畅跑13B 模型 Q4 需要 8 到 10GB32B 模型 Q4 基本要到 16GB 以上。如果没有独显CPU 推理也能跑但速度会慢到让人怀疑人生7B 模型在普通笔记本 CPU 上大概每秒只能输出几个 token适合偶尔用用不适合对话。图像模型方面ComfyUI 跑 SD1.5 系列 4GB 显存勉强够用SDXL 则建议至少 8GBFlux 系列动辄需要 12GB 以上显存如果显存不够可以通过 GGUF 量化版本来降低需求。操作系统上Windows、Linux、macOS 都能装齐全套。个人开发我更推荐 Windows 加 WSL2或者直接用 Ubuntu 服务器ComfyUI 的秋叶整合包是 Windows 专属Linux 用户只能走手动部署路线。如果你的主力机器是 MacM 系列芯片跑 Ollama 效果不错但 ComfyUI 的生态在 Apple Silicon 上相对受限。2.2 Ollama 安装Windows、Linux 与 Docker 对比Ollama 的安装方式比较灵活我这里列三种主流路线你可以根据场景选。Windows 用户直接去官网下载 OllamaSetup.exe双击安装后托盘区会常驻一个小图标命令行里就能用ollama --version验证。这个方式最省心自动注册系统服务开机自启。Linux 用户用官方脚本一键安装curl -fsSL https://ollama.com/install.sh | sh安装后默认以 systemd 服务运行监听 11434 端口。如果你不想用 root 权限也可以下载源码包手动解压到用户目录运行但日常使用官方脚本最省事。Docker 部署适合已经有容器环境、或者需要多台机器共用模型的场景docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama这个命令把模型数据挂载到名为ollama的数据卷里容器删了重拉模型还在不会白下载。三种方式本质一样都是后台起一个服务然后通过命令行或 API 交互。装好后先跑一个小模型验证环境ollama run qwen2.5能正常对话就说明推理链路通了。注意第一次运行会先下载模型几百 MB 到几个 GB 不等取决于你选的模型。2.3 模型下载太慢怎么处理这是国内用户最常见的痛点。Ollama 默认从官方仓库拉取模型在网络状况不理想的时候一个几 GB 的模型可能下到一半就断掉而且断点续传机制并不是每次都靠谱。我的建议是分两条路走。第一条路修改 Ollama 的下载相关环境变量。Linux 下编辑 systemd 服务配置加入代理等网络参数Windows 下在系统环境变量里添加OLLAMA_HOST、OLLAMA_MODELS等。注意这里说的网络参数不是为了绕过什么限制而是面向企业内网或本地网络加速环境的标准做法比如在内网部署了缓存镜像的情况。第二条路更实在绕过 Ollama 的模型仓库直接从国内模型社区下载 GGUF 格式文件再用 Ollama 的 Modelfile 机制导入。以阿里系的 ModelScope魔搭社区为例上面有大量量化好的 GGUF 模型浏览器或命令行下载速度稳定很多。拿到.gguf文件后写一个简单的 ModelfileFROM ./qwen2.5-7b-instruct-q4_k_m.gguf然后在模型文件所在目录执行ollama create qwen2.5-gguf -f Modelfile这样就把本地 GGUF 文件注册成了 Ollama 里的模型ollama run qwen2.5-gguf就能直接对话。这个办法的好处是完全不依赖官方仓库的下载速度坏处是需要自己手动找模型文件但熟悉之后反而更灵活。2.4 修改模型存储路径与离线导入Ollama 默认把模型存在~/.ollama/models下Windows 是C:\Users\用户名\.ollama\models。系统盘空间不够的时候这个默认路径非常坑。修改方法是在系统环境变量里添加OLLAMA_MODELS指向你希望存放模型的大分区比如D:\ollama\models。Linux 下如果 Ollama 以 systemd 运行需要编辑服务文件sudo systemctl edit ollama.service在 override 片段中加入[Service] EnvironmentOLLAMA_MODELS/data/ollama/models然后重启服务。注意改完路径后之前下好的模型不会自动搬过去需要手动移动旧目录里的文件。这个操作要在服务停止状态下进行防止文件被占用。离线环境部署的话思路是在一台有网的机器上用上面的 GGUF 导入方案准备好模型然后把整个OLLAMA_MODELS目录拷贝到目标机器设置好同样的环境变量即可。3. Open WebUI 容器化部署3.1 Docker 部署的几步操作Open WebUI 官方推荐用 Docker 部署因为它的依赖关系比较重Node 和 Python 混在一起手工安装麻烦容器化之后一条命令解决。标准部署命令docker run -d -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main这里有个细节需要留意--add-hosthost.docker.internal:host-gateway让容器内能通过host.docker.internal这个主机名访问宿主机。因为 Ollama 如果直接跑在宿主机上容器里的 Open WebUI 无法用localhost访问它必须靠这个映射。拉取镜像如果慢可以配置 Docker 的国内镜像加速器这是 Docker 官方支持的 registry mirror 机制属于标准加速手段。编辑/etc/docker/daemon.jsonWindows 桌面版在设置里配置{ registry-mirrors: [https://docker.mirrors.example.com] }重启 Docker 后生效。这个配置只是换一个拉取镜像的源不影响后续使用。启动完成后浏览器访问http://localhost:3000第一次进入会要求注册管理员账号之后就可以正常使用了。3.2 与 Ollama 对接的关键配置Open WebUI 默认会尝试连接http://localhost:11434但在容器环境下这个地址指向容器自身所以必须手动指定后端地址。如果你希望界面更直观可以在容器启动时通过环境变量配置docker run -d -p 3000:8080 \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -v open-webui:/app/backend/data \ --add-hosthost.docker.internal:host-gateway \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main或者让 Open WebUI 和 Ollama 都跑在 Docker 里放到同一个自定义网络下用容器名互相访问docker network create ai-net docker run -d --network ai-net --name ollama -v ollama:/root/.ollama ollama/ollama docker run -d --network ai-net -p 3000:8080 -e OLLAMA_BASE_URLhttp://ollama:11434 -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main两种方案各有优劣。第一种简单直接Ollama 升级版本时不用动容器网络第二种更贴近生产环境容器间通信不受宿主机防火墙影响。部署完成后打开 Open WebUI 的设置页面如果能看到 Ollama 里已有的模型列表说明对接成功。如果模型列表为空先确认 Ollama 的 API 是否可访问在宿主机上执行curl http://localhost:11434/api/tags有 JSON 返回就正常。3.3 内网离线环境的部署思路有些场景需要在完全隔离的内网部署没法直接拉镜像。思路是提前在能联网的机器上把镜像保存下来再拷贝进内网。docker save ghcr.io/open-webui/open-webui:main -o openwebui.tar把openwebui.tar拷到内网机器后docker load -i openwebui.tar然后正常docker run即可。模型文件同理按照前面说的 GGUF 导入方案处理。这里建议把 Open WebUI 的数据目录也单独备份因为里面包含用户账号、聊天记录和配置重装后直接挂载原目录就能恢复。4. ComfyUI 环境搭建整合包与手动部署4.1 秋叶整合包适合谁ComfyUI 在国内流行起来秋叶整合包功不可没。它是一个 Windows 下的打包分发方案把 Python 环境、PyTorch、ComfyUI 本体、常用节点插件预先整合好用户解压后双击启动脚本即可使用。对于第一次接触 ComfyUI、不想折腾 CUDA 环境的朋友秋叶包确实是省钱省力的选择。启动器还能管理模型下载、插件安装和版本更新非常适合把注意力集中在画图本身的人。但它也有明显的局限体积大通常几个 GB 起步只支持 Windows整合包的版本更新相对滞后想用最新的采样器或节点功能时需要手动替换文件出了问题后因为环境是打包的定位问题比手动部署更难。我的建议是如果你只是想在本地快速出图且主力系统是 Windows直接用秋叶包没问题。但如果你是长期折腾型玩家或者需要在 Linux 服务器上跑 ComfyUI手动部署是必须掌握的能力。4.2 PyTorch CUDA 手动环境构建手动部署 ComfyUI 的核心是先装好 PyTorch 的 CUDA 版本。这一步很多人翻车原因多半是直接pip install torch装到了 CPU 版。正确的流程是先用nvidia-smi确认驱动支持的 CUDA 版本然后在 Python 3.10 或 3.11 的虚拟环境里安装匹配的 PyTorch。例如 CUDA 12.1 对应的安装命令pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完后在 Python 里验证import torch print(torch.__version__) print(torch.cuda.is_available())能输出True说明 GPU 可用。如果输出False多半是 PyTorch 版本和驱动不匹配需要重新选版本。之后克隆 ComfyUI 本体并安装依赖git clone https://github.com/comfyanonymous/ComfyUI cd ComfyUI pip install -r requirements.txt启动python main.py浏览器访问http://127.0.0.1:8188看到默认的节点工作流就说明安装成功。注意 ComfyUI 的默认端口是 8188和 Ollama 的 11434、Open WebUI 的 3000 不一样三者不会冲突。4.3 模型目录组织与 GGUF 插件ComfyUI 的模型目录结构非常规整安装目录下有一个models文件夹里面按类型分子目录checkpoints放完整的大模型文件如 SDXL、Flux 的 safetensors 文件这是最常用的目录loras放 LoRA 微调模型vae放 VAE 文件用于解码图像controlnet放 ControlNet 模型upscale_models放放大模型把这些模型文件下载后放到对应目录刷新 ComfyUI 页面就能在节点里选到。下载模型时我习惯优先找量化版本特别是显存吃紧的情况下。ComfyUI 生态里有一个叫 ComfyUI-GGUF 的插件可以加载 GGUF 格式的扩散模型配合小显存显卡大幅降低门槛。安装插件的标准路径是custom_nodes目录在 ComfyUI 根目录下cd custom_nodes git clone https://github.com/city96/ComfyUI-GGUF然后重启 ComfyUI 就能在节点列表里看到 GGUF 相关的加载器。5. 三端联调与统一入口设计5.1 让 Open WebUI 与 Ollama 实时互通三套系统分别装好后最自然的第一步是把 Open WebUI 和 Ollama 打通。按照第 3 节的配置Open WebUI 在页面上就能直接列出 Ollama 里已安装的模型。不同模型的切换在聊天界面的顶部下拉菜单里完成体验和 ChatGPT 切换模型几乎一致。这里有一个实用技巧Ollama 支持多模型同时加载如果显存够但默认配置下每个模型首次请求都会重新加载响应速度会慢。可以通过设置 Ollama 的OLLAMA_KEEP_ALIVE环境变量控制模型在内存中的驻留时间比如设为5m表示空闲 5 分钟后释放。还有一个容易忽略的点是模型名称的统一。在 Ollama 里自定义模型时名字里不要带奇怪的字符否则 Open WebUI 下拉列表里显示会不正常。建议用模型名:版本这样的格式比如qwen2.5:7b。5.2 ComfyUI 与文本模型的工作流衔接ComfyUI 和 Ollama 之间没有官方集成但实际使用中可以通过两种方式衔接。第一种是 API 层面。ComfyUI 本身提供/prompt接口可以接收 JSON 格式的工作流配置并执行。你可以在 Open WebUI 里调用 Ollama 拿到文本模型生成的提示词再写一个脚本把提示词组装成 ComfyUI 的 API 请求实现自动出图。这个过程一开始会比较繁琐需要先在工作流编辑器里把需要的节点搭好然后导出 API 格式的 JSON再写个 Python 脚本替换其中的文本参数。第二种是手工流程。我自己更常用在 Open WebUI 里让文本模型帮我分析创意、优化提示词然后把最终提示词复制到 ComfyUI 的 CLIP Text Encode 节点里直接出图。这种半自动方式部署成本最低也最容易控制出图质量。5.3 一个可落地的本地 AI 工作台配置给一套完整的本地部署留一份示例环境清单。假设你有一台 16GB 显存的 NVIDIA 显卡、系统为 Ubuntu 22.04最终形态是这样的组件部署方式端口核心配置Ollamasystemd 服务11434OLLAMA_MODELS 指向数据盘Open WebUIDocker 容器3000OLLAMA_BASE_URL 指向宿主机ComfyUIPython 虚拟环境8188安装 ComfyUI-GGUF 插件Ollama 里常驻一个 Qwen 2.5 7B 或 14B 的量化模型负责文本理解和对话ComfyUI 里备好 SDXL 或 Flux GGUF 模型负责出图。日常使用中浏览器开两个标签页一个聊天一个画图互不干扰。6. 常见问题与排查实录6.1 Ollama 报 500 internal server error搜索热词里出现频率最高的就是ollama run qwen3.5:2b error: 500 internal server error: llama-server process这句话我几乎每周都会在社区里看到。这个错误本身含义很明确Ollama 成功把任务交给了 llama-server 推理进程但推理进程在处理请求时异常退出。最常见的原因是内存不足。llama-server 在加载模型时需要连续的 RAM 或显存空间如果机器内存紧张进程直接被系统杀掉前端就会收到 500 错误。解决办法是换一个更小的量化模型或者关闭其他占用内存的应用后再试。第二个常见原因是模型文件损坏。下载中断导致的模型文件不完整会让 llama-server 在加载时崩溃。可以删掉对应模型重新拉取或者直接重新导入 GGUF 文件。排查时先看 Ollama 的日志。Linux 下用journalctl -u ollama -f实时查看Windows 下可以右键系统托盘图标查看日志文件。日志里如果有CUDA error: out of memory字样的基本就是显存问题如果是killed就是内存不足如果是文件层面的报错重新下载模型即可。6.2 ComfyUI 生成视频或大图时爆内存ComfyUI 在生成高分辨率图片或视频时爆显存/爆内存几乎是所有玩家的必经之路。核心原因是扩散模型的中间特征图非常占显存分辨率每翻一倍显存占用按平方增长。应对方案从轻到重排列降低 batch size 到 1这是最直接有效的操作使用--lowvram参数启动 ComfyUI让 PyTorch 自动做显存换入换出在启动命令里加--force-fp16让计算走半精度换用 GGUF 量化模型这是对低显存最友好的路线图片尺寸设置不要超过 1024×1024需要大图先小图出图再放大如果爆的是系统内存而不是显存检查 VAE 解码阶段是否用了 CPU 解码如果是可以把 VAE 也放到 GPU 上。6.3 下载慢、连接失败与模型冲突下载相关的坑主要集中在镜像失效和断点续传失败。我在实际使用中的做法是大模型文件优先从 ModelScope 下载它支持直接用git clone或命令行工具拉取速度和稳定性都优于浏览器直链同时用完整性校验工具比对文件的 SHA256确认没问题再放入模型目录。模型冲突则常见于 Ollama 里同名模型版本混乱。比如从官方仓库拉过一个qwen2.5:7b又从 GGUF 导入了一个同名模型命令行里执行时可能加载到不同的版本。我的经验是两个来源的模型一定用不同的名字区分避免频繁踩坑。6.4 Docker 容器互通问题速查Open WebUI 连不上 Ollama 时先检查三个地方。第一Ollama 是否监听了正确的地址。默认127.0.0.1:11434只允许本机访问容器访问宿主机时需要确保 Ollama 监听0.0.0.0可以在启动时设置OLLAMA_HOST0.0.0.0。第二容器到宿主机的网络路径。用了host.docker.internal的话确认启动容器时加了--add-hosthost.docker.internal:host-gateway参数。这个参数在 Windows Docker Desktop 和 Linux 上的 Docker Engine 都兼容。第三防火墙。Linux 服务器上尤其常见ufw或firewalld默认拦截非本机流量记得放行 11434 和 3000 端口。把这三个地方过一遍九成以上的连接问题都能解决。剩下的一成是版本兼容性比如 Open WebUI 对某些 Ollama 新特性依赖较新版本升级其中之一后再测一次基本就好。这套部署流程写到这里核心步骤都已经覆盖。如果一定要我给你一条最优先的建议那就是在动手之前先把模型下载问题想清楚因为整个流程里浪费时间最多的地方往往不是配置而是等待下载。我个人现在的工作习惯是Ollama 用 GGUF 导入方式管理文本模型ComfyUI 固定用 Git 方式更新本体和插件Open WebUI 全交给 Docker 管理留一个备份数据卷的定时任务。这套组合跑了几个月除了升级时有几次小报错日常使用非常稳定。后续想再扩展的话可以研究一下用 Open WebUI 的函数功能去调用 ComfyUI 的 API把聊天和出图做成一个完整闭环那就是另一个值得单独写一篇的话题了。