★ FEATURED ARTICLE 最近一直在折腾怎么在 Windows 上跑本地大模型试过几套方案之后最终稳定下来的是 WSL2 Ubuntu Ollama Open WebUI 这套组合。Ollama 负责模型下载和推理Open WebUI 提供类似聊天产品的浏览器界面而 WSL2 Ubuntu 承接了兼容性最稳的 Linux 运行环境。在正式开工之前我做了不少功课也踩了不少坑整个搭建过程前后花了两天。这篇文章不打算复述官方文档而是把“为什么这样组合、每一步需要注意什么、出问题了怎么排查”完整呈现出来给准备入坑本地模型的朋友一条更顺的路径。1. 这套组合解决了什么问题1.1 为什么不是虚拟机、双系统而是 WSL2本地跑大模型其实有很多种环境选择原生 Linux、虚拟机、Docker Desktop for Windows、WSL2。我全都试过或者至少对比过一圈最终还是选了 WSL2 作为承载层。WSL2 本质是个轻量级虚拟机底层基于 Windows 自带的虚拟化机制但它和传统虚拟机最大的不同在于“集成度”。启动一个 Ubuntu 发行版只需要两三秒不像 Hyper-V 虚拟机要等完整的开机流程文件和 Windows 互通直接访问/mnt/c、/mnt/d就能读写 Windows 磁盘还支持 localhost 转发Windows 浏览器可以直接访问 WSL 里跑的服务不需要手动配置端口映射。双系统就更不用说了切系统太伤效率。考虑到本地大模型主要是交互式对话和测试场景随时在 Windows 和 Linux 之间切换而不重启这个体验太重要了。它让我工作、写代码、跑模型完全兼容在同一个桌面上。1.2 四个组件的分工与请求链路这套组合里每个组件都不是可有可无的我整理了一个表格组件职责说明WSL2轻量 Linux 运行层秒级启动、与 Windows 内核级集成Ubuntu应用与依赖环境负责 apt 包管理、systemd、网络栈Ollama模型推理引擎拉取模型、暴露 API、调用 GPU/CPUOpen WebUI浏览器交互层网页聊天界面、会话管理、多模型切换它们的协作链路是浏览器访问localhost:8080打开 Open WebUI 界面Open WebUI 把用户输入转发给 Ollama 的 API默认端口 11434Ollama 负责把 prompt 交给已加载的模型做推理结果再原路返回页面渲染。这条链路里每个环节都有值得注意的地方端口绑定、环境变量、驱动透传、容器网络模式后面我会逐个展开。2. 系统准备WSL2 与 Ubuntu 容易被忽略的细节2.1 安装命令与版本确认如果你用的 Windows 10 2004 或更高版本安装 WSL2 其实只需要一条命令。在管理员 PowerShell 里执行wsl --install这条命令会自动启用“适用于 Linux 的 Windows 子系统”和“虚拟机平台”两个功能再下载默认发行版。重启之后按提示设置用户名和密码即可。如果不想用默认发行版可以指定版本wsl --install -d Ubuntu-22.04我建议装完以后立刻确认 WSL 版本是 2wsl -l -v输出结果里 Version 必须是 2。这里我踩过唯一的坑是某些比较旧的系统默认装成了 WSL1后续 Docker、GPU 转发都会有奇怪的问题所以这一步值得花一分钟确认。2.2 Linux 初始化与文件系统习惯进到 Ubuntu 终端先做两件事更新系统、建立工作目录。sudo apt update sudo apt upgrade -y mkdir -p ~/models ~/tools如果 apt 下载慢可以把软件的源换成国内网络环境下更快的镜像地址网上教程很多我这里不重复贴具体域名了。但换源后一定要重新执行sudo apt update不然会出现索引不一致的问题。比较容易被忽略的其实是文件存放位置。WSL2 里读写 Windows 文件系统/mnt/c、/mnt/d性能损耗很明显跨系统 I/O 对于小文件还好一旦涉及大文件就会放大这个问题。模型文件动辄好几个 GB放到 Windows 盘会让 Ollama 启动和加载模型明显变慢。我一开始把模型目录放在 Windows 分区实测加载一个 4GB 左右的模型要多花好几秒后来果断把模型放到 WSL 内部文件系统速度恢复正常。规则很简单日常操作和项目文件都放 WSL 内需要给 Windows 用的文件再单独放共享位置。2.3.wslconfig资源限制与 systemd大模型是高内存消耗场景WSL2 默认会按 Windows 可用资源动态占用但若不限制反而容易出现不稳定。我建议在 Windows 用户目录下创建一个.wslconfig文件内容类似这样[wsl2] memory12GB processors6 swap4GB这个文件由 Windows 侧读取改完必须执行wsl --shutdown再重新进 Ubuntu 才生效。限制内存的意义在于避免 WSL 把 Windows 宿主的可用内存全部吃掉导致 Windows 本身卡顿也避免系统在资源紧张时把 WSL 的进程回收掉。另外建议确认 systemd 是启用状态。新版 WSL 默认支持但如果你是从旧版本升级过来的需要在/etc/wsl.conf里加上[boot] systemdtrue启用后 Ollama 这类服务可以直接用systemctl管理崩溃了可以自动重启这在后文讲开机自启时会非常舒服。3. Ollama 的安装、模型拉取与 GPU 调用3.1 安装并确认 API 服务正常Ollama 在 Linux 上的安装方式很简单官方提供了一个一键安装脚本直接执行即可。装完以后先启动服务sudo systemctl start ollama systemctl status ollama如果服务没起来也可以在前台跑ollama serve看日志。确认服务正常最直接的方法是调用 APIcurl http://localhost:11434/api/version能返回带版本号的 JSON就说明 Ollama 已经在运行了。这里有一个关键点Ollama 服务默认只监听127.0.0.1这对同机访问是够用的。但如果你打算从另一台机器、或让 Docker 容器通过网络访问它就需要设置环境变量OLLAMA_HOST0.0.0.0否则外部请求会被拒绝。我会在讲 Open WebUI 部署时再提到这个变量。3.2 模型选择、存储路径与环境变量拉取模型用ollama pullollama pull qwen2.5:7b ollama pull llama3.2:3b模型选择我实际用的最多的是 qwen2.5 系列中文任务的处理质量明显比同参数量的其他模型好。如果你的显卡显存不太够优先考虑小参数量的量化版本7B 至少需要 8GB 显存4B 或 3B 更省。官方模型库列表随时在更新按需选择就好。模型文件的默认存放位置是/usr/share/ollama/.ollama/models如果你是用 root 身份跑的会在~/.ollama/models。可以通过环境变量OLLAMA_MODELS/your/path自定义目录。改路径时最容易出问题的是权限Ollama 服务进程通常以ollama用户运行手动拷贝模型文件到新目录后经常因为属主不对导致模型加载失败。正确做法是用ollama pull拉取让它自己写入目标目录或者用软链接并配合chown修改属主。3.3 确认 GPU 真的被调用了很多人以为装了显卡驱动就能在 WSL 里用 GPU实际上还是要验证的。第一步是确认 WSL 内能看到显卡nvidia-smi如果提示找不到命令或没有输出回 Windows 更新显卡驱动。WSL2 的驱动是透传的理论上 Windows 装了最新驱动WSL2 里就能直接看到。但这里有个特别容易误导人的地方WSL 里nvidia-smi显示的驱动版本和显存信息是从 Windows 透传过来的它只能证明“驱动通了”不代表推理一定在用 GPU。要看模型是否真正用 GPU 跑有两个可靠验证方式一是ollama run加载模型时观察/tmp/ollama.log看有没有出现 CUDA 相关初始化的记录二是推理过程中在另一个终端执行nvidia-smi查看显存占用和进程列表。如果显存占用一直为零而 CPU 跑满大概率是回退到 CPU 了。WSL2 里 Windows 任务管理器看不到 WSL 的显存占用所以判断 GPU 状态必须以 WSL 内的nvidia-smi为准这个坑我在群里被问了很多次。4. Open WebUI 的部署方式与连接配置4.1 Docker 部署最省心的方式Open WebUI 官方推荐 Docker 方式部署。前提是 Docker Desktop 已安装并启用 WSL2 后端。然后在 Ubuntu 终端执行docker run -d \ --networkhost \ -v open-webui:/app/backend/data \ -e OLLAMA_BASE_URLhttp://127.0.0.1:11434 \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main逐个解释关键点--networkhost容器直接使用宿主机网络栈。这样容器访问127.0.0.1:11434就能直达 Ollama绕开了 Docker bridge 网络下“容器内 localhost 不是宿主机”的经典问题。-v open-webui持久化用户账号、聊天记录、设置项。没有这个 volume容器一删数据全没了。--restart always让容器跟随 Docker 服务自动重启。第一次启动后等它初始化完成Windows 浏览器访问http://localhost:8080就能看到 Open WebUI 页面。4.2 pip 方式不想碰 Docker 的选择如果 Docker 在你那边不可用或者就是不想为这件事多装一个大工具可以直接用 Python 部署pip install open-webui open-webui serve默认端口同样是 8080。两种部署方式的取舍我实际体会下来是这样的pip 方式轻量和 Ollama 天然共享 localhost几乎不会遇到容器网络不通的尴尬缺点是进程要自己管理多模型或多服务时容易乱。Docker 方式隔离性好、升级方便但首次拉镜像体积大、网络不好时比较痛苦。我的建议是如果你以后会频繁升级 Open WebUI优先 Docker如果只是想快速跑通pip 更直接。4.3 首次登录与模型关联Open WebUI 首次打开会要求注册账号第一个注册的账号会自动成为管理员。这个设计很容易被人忽略如果这台机器会被别人访问注册完第一件事就去“管理面板-用户设置”里关闭“允许注册”避免任何人都能注册账号。模型关联方面有两种方式。如果 Docker 启动参数里已经给了OLLAMA_BASE_URL打开页面后自动就能看到 Ollama 里所有已下载的模型。如果当时没配置也可以在“管理员设置-连接”里手动填 Ollama 的地址。注意修改连接配置后要刷新页面模型列表才会重新加载。5. 从本机到局域网访问方式与开机自启5.1 本机访问与系统代理干扰WSL2 默认的 NAT 模式自带 localhost 转发能力所以 Windows 浏览器直接访问localhost:8080就能打开 Open WebUI。大多数情况下你只需要这一条路径。但有两次我遇到“Windows 能 ping 通 WSL 但浏览器打不开页面”的情况最后定位到是系统代理在干扰。某些网络环境或安全软件会给 localhost 也走代理。排查方法很简单临时关闭系统代理再访问如果恢复正常就把 localhost 加入代理排除列表。5.2 局域网设备访问portproxy 与防火墙想让手机、平板或者办公室里其他电脑访问 Open WebUI问题就来了WSL2 的端口转发默认只对 Windows 本机生效局域网其他设备访问 Windows 的 IP 是连不上的。需要用 Windows 侧的端口转发把请求转到 WSL2 内部 IP。管理员权限执行netsh interface portproxy add v4tov4 listenport8080 listenaddress0.0.0.0 connectport8080 connectaddressWSL内网IPWSL 内网 IP 通过wsl hostname -I查看。然后还要在 Windows 防火墙里放行 8080 端口的入站连接在“高级安全 Windows Defender 防火墙”里新建一条允许 TCP 8080 入站的规则。这里有个明显痛点WSL2 重启后内网 IP 会变portproxy 里的connectaddress就要跟着改。我的做法是写了一个 PowerShell 脚本每次 WSL 重启后自动获取新的 IP 并刷新 portproxy 规则手动改太容易漏了。5.3 开机自启的完整方案WSL 里的 systemd 可以管理服务但有一个问题WSL 本身不会在 Windows 开机时自动启动。要让整套环境开机可用需要在 Windows 任务计划程序里做一个开机触发任务。我的实际配置是任务计划程序新建任务触发器设为“计算机启动时”操作为执行wsl.exe -d Ubuntu -u root -- systemctl start ollama另外再建一个任务启动open-webui如果它是用 pip 方式的执行nohup open-webui serve 如果是 Docker 方式Docker Desktop 自启后--restart always会拉起容器。为了方便免密执行 systemctl需要在 WSL 里配置 sudoers。整套配置完成后Windows 开机后一两分钟内所有服务就绪浏览器直接访问即可。这套方案比网上常见的“写一个 .bat 放启动文件夹”要稳定得多因为 systemd 负责服务自愈进程级别的问题能自动处理。6. 实测踩坑记录与排查链路6.1 页面打不开逐层排查思路症状是 Windows 浏览器访问localhost:8080一片空白或直接拒绝连接。这种事我第一次搭的时候几乎想放弃后来总结出排查链路先在 WSL 内自测curl http://localhost:8080如果能返回 HTML说明服务本身是好的问题出在跨系统访问层。接着看监听状态ss -tlnp | grep 8080确认服务监听在0.0.0.0或::而不是只监听127.0.0.1。然后回到 Windows尝试访问 WSL 内网 IP 的对应端口如果 IP 能通但 localhost 不通多半是系统代理或 Windows 的 localhost 转发除了问题。我实际遇到的情况是系统代理拦截 localhost关闭代理后一切正常。这个坑在没有任何网络代理的环境里不会出现但在企业联网环境很常见。如果你也是这种环境优先怀疑代理。6.2 VHD 磁盘与内存膨胀WSL2 跑了一段时间后Windows 磁盘里虚拟磁盘文件越来越大。这是 WSL 的虚拟硬盘动态扩展导致的文件只增不减即使你在 WSL 里删了大量数据宿主机上的 VHDX 文件也不会自动变小。处理方法是先关掉 WSL然后在 Windows 管理员 PowerShell 里压缩 VHDXwsl --shutdown Optimize-VHD -Path C:\path\to\ext4.vhdx -Mode Full如果没装 Hyper-V 管理工具Optimize-VHD不可用可以用 diskpart 命令行工具手动 compact。另外还要注意虽然 WSL2 支持内存回收但如果你跑大模型时发现 Windows 总内存不够用回到第一节的.wslconfig调整参数给它设一个合理上限更稳。6.3 模型连不上与镜像拉取慢Open WebUI 页面能打开但模型列表是空的发送消息报连接错误通常出在 Open WebUI 到 Ollama 这一段。第一件事是看 Open WebUI 的启动日志和容器日志。如果 Docker 用的是默认 bridge 模式容器里访问宿主机要填的不是127.0.0.1而是 WSL 的内网 IP。如果是 host 模式还连不上重点检查 Ollama 的监听地址和防火墙。另一个常见场景是镜像拉取慢。Open WebUI 的官方镜像比较大在国内网络环境第一次拉取可能非常慢甚至超时。我的经验是如果镜像拉不下来不要硬等转用 pip 方式安装 Open WebUI 是更快的路径或者找一台网络通畅的机器把镜像保存成 tar 文件传输到本机再docker load虽然笨但非常可靠。这几类问题叠加在一起看起来像配置很复杂但实际上只要理解了“宿主、容器、WSL、Windows”这几层网络关系排查方向就很清晰。就我个人的使用体验而言整套环境搭好之后日常使用非常简单稳定反而最花时间的都是初始搭建时的网络和权限问题。如果你按照这篇文章的顺序一次搭完后面基本不会再有大坑。以后我还想继续折腾自定义模型文件、接入更多推理后端这套组合的扩展性也足够。
阅读完成 · 觉得有帮助？
