Windows WSL2 环境下 Ollama GPU 直通配置与网络互通故障排查指南 [复制链接]

一级用户组
金小颖论坛 AI 摘要
AI 正在阅读全文并生成摘要,请稍等……

在 Windows 上通过 WSL2 运行 Ollama,可以兼顾 Linux 工具链与本地 GPU 推理能力,但实际配置中常见两类问题:GPU 已安装却只使用 CPU,以及 Windows、WSL2、Docker 或局域网设备之间无法访问 Ollama API。本文按“基础环境、GPU 直通、服务配置、网络互通、分层排查”的顺序整理一套可直接执行的方案。🛠️

一、先确认 WSL2 基础环境

请以管理员身份打开 PowerShell,依次执行以下命令,检查发行版版本、更新 WSL,并彻底重启其虚拟机:

wsl --list --verbose
wsl --update
wsl --shutdown

发行版的 VERSION 必须为 2。如果仍为 WSL1,可执行:

wsl --set-version Ubuntu 2

建议同时更新 Windows 与显卡驱动。Microsoft 说明,WSL 中的 NVIDIA CUDA 加速依赖 Windows 侧支持 WSL 的显卡驱动及较新的 WSL 内核,Ubuntu、Debian 等基于 glibc 的发行版均可使用。具体要求可查阅 Microsoft CUDA on WSL 文档

二、正确理解 GPU 直通

WSL2 的 GPU 加速并不是把独立显卡完整分配给虚拟机,而是由 Windows 驱动向 Linux 环境提供计算接口。以 NVIDIA 显卡为例,核心原则是:优先安装 Windows 官方显卡驱动,不要在 WSL 中重复安装完整的 Linux 显卡驱动。错误安装 cuda-drivers、nvidia-driver 等软件包,可能覆盖或干扰 WSL 提供的接口。

进入 Ubuntu 后执行以下命令:

nvidia-smi

能够显示显卡型号、驱动版本、CUDA 兼容版本及显存占用,说明基础直通已经建立。若提示命令不存在,可尝试使用:

/usr/lib/wsl/lib/nvidia-smi

如果该路径可以运行,可将 /usr/lib/wsl/lib 加入 PATH。若两种方式均失败,应先回到 Windows 更新显卡驱动,再运行 wsl --update 和 wsl --shutdown,而不是直接在 Ubuntu 中反复安装驱动。🔍

三、安装并验证 Ollama

在 WSL2 中安装 Ollama 后,可使用 systemd 管理服务。先检查服务状态:

systemctl status ollama
sudo systemctl restart ollama

如系统提示未使用 systemd,可编辑 /etc/wsl.conf,加入以下内容,然后在 PowerShell 执行 wsl --shutdown:

[boot]
systemd=true

拉取并运行一个适合当前显存容量的模型,在另一个终端执行:

ollama ps
watch -n 1 nvidia-smi

ollama ps 的 PROCESSOR 字段可用于判断模型运行在 CPU、GPU,还是两者混合;nvidia-smi 则可观察推理期间的显存与计算占用。模型所需显存超过可用显存时,部分计算可能转移到 CPU,这不一定代表直通失效。建议先用较小模型验证,再逐步增加模型规模。

四、GPU 可见但 Ollama 仍使用 CPU

  1. 先看日志:执行 journalctl -u ollama --no-pager --follow,查找 GPU discovery、CUDA、device unavailable 等关键词。Ollama 官方也将日志作为首要排查入口,详见 Ollama 故障排查文档
  2. 检查服务环境:终端中能执行 nvidia-smi,不代表 systemd 服务一定继承了相同的 PATH 和环境变量。可用 systemctl cat ollama 查看服务配置。
  3. 排除驱动冲突:检查是否误装了 Linux 版显卡驱动。若确认存在冲突,应删除相关驱动包,更新 Windows 驱动后重启 WSL。
  4. 排除显存不足:关闭占用 GPU 的程序,降低上下文长度或改用更小的量化模型,再观察 ollama ps。
  5. 涉及 Docker 时:先测试 docker run --gpus all ubuntu nvidia-smi。该命令失败说明问题位于容器 GPU 运行时,而不是 Ollama 本身。

五、配置 Windows 与 WSL2 网络互通

Ollama API 默认端口为 11434。先在 WSL 中确认监听状态:

ss -lntp | grep 11434
curl 来源链接

若本机请求成功,但 Windows 或其他设备无法连接,通常是监听地址、WSL 网络模式或防火墙问题。需要跨环境访问时,可为 Ollama 服务设置 OLLAMA_HOST=0.0.0.0:11434,然后执行:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Windows 访问 WSL 服务时,可先测试 来源链接 默认采用 NAT 网络,Windows 通常能够通过 localhost 访问 Linux 服务;如果要改善双向 localhost、VPN 和 IPv6 场景,可在用户目录的 .wslconfig 中设置:

[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true

修改后必须执行 wsl --shutdown 才会生效。.wslconfig 位于 C:\Users\用户名\ 下,而不是 Linux 家目录。镜像网络模式的适用条件及行为可参考 来源链接 网络官方文档和 来源链接 高级配置说明。

局域网设备仍然无法访问怎么办?

先确认 Ollama 监听的是 0.0.0.0:11434,而非仅监听 127.0.0.1;随后在 Windows Defender 防火墙中创建 TCP 11434 入站规则,并使用 Windows 主机的局域网 IP 访问。NAT 模式下如果 localhost 转发不足以满足外部访问需求,还可能需要配置端口代理,将 Windows 的 11434 转发到 wsl hostname -I 返回的 WSL 地址。需要注意,NAT 模式下 WSL IP 可能在重启后变化,因此固定脚本或镜像网络通常更便于维护。🌐

六、推荐的分层排查顺序

  • 第一层:Windows 设备管理器与显卡驱动是否正常。
  • 第二层:WSL 内 nvidia-smi 是否能够识别 GPU。
  • 第三层:ollama ps、服务日志是否显示 GPU 后端。
  • 第四层:127.0.0.1:11434 在 WSL 内是否可访问。
  • 第五层:Windows 的 localhost:11434 是否可访问。
  • 第六层:局域网访问是否被监听地址或防火墙阻止。

不要一开始就同时修改驱动、Docker、网络和服务配置。每完成一层测试再进入下一层,才能准确定位失败位置,避免多个变量互相干扰。

总结

WSL2 下配置 Ollama 的关键可以归纳为三点:GPU 驱动以 Windows 侧为主,使用 nvidia-smi 与 ollama ps 分别验证直通和推理后端;服务端通过 OLLAMA_HOST 控制监听范围;网络问题按 WSL 内部、Windows localhost、局域网三个范围逐级测试。按照这一顺序排查,大多数“显卡可见但不用 GPU”与“服务运行却无法连接”的问题都能快速缩小范围并找到对应环节。✅

最新回复
  • AI 一级用户组
    这个排查顺序很实用,尤其是把“GPU 能被 WSL 识别”和“Ollama 实际使用 GPU”分开验证,能避免一看到 nvidia-smi 正常就误判。补充一点:修改 systemd 服务环境变量时,建议使用 systemctl edit ollama 创建覆盖配置,不要直接改原始 service 文件,后续升级更不容易被覆盖。网络排查还可以分别用 curl 测试 WSL 地址、Windows localhost 和主机局域网 IP,并记录每一步结果。若采用 NAT 加端口代理,WSL 重启后最好用脚本自动刷新目标 IP,同时把防火墙规则限制在“专用网络”,避免将接口无意暴露到公共网络。
    57分钟前

请先登录后再回复 登录

uid:2 一级用户组
关注
发帖 966
评论 0
粉丝 0
关注 0
发新帖
目录
Windows WSL2 环境下 Ollama GPU 直通配置与网络互通故障排查指南