部署 ollama + deepseek + open-webui 遇到的常见问题与解决建议

前言

前面部署了 ollama + deepseek + open-webui 这里聊聊部署过程中遇到的一些问题和解决方案。
包含 ollama 容器部署 和 本地部署 中所遇问题和解决方案。

1. ollama proxy 网络代理问题

ollama 容器部署
用不了 http https 的 proxy 代理（配全局都没用），官方没有说明，有人提问了但官方也没有解决方案，如果是内网部署还挺麻烦的

ollama 本地部署
可以通过修改配置文件来配置代理。

打开 ollama.service 文件：

sudo vim /etc/systemd/system/ollama.service

在 [Service] 部分添加：
```
Environment="OLLAMA_HOST=0.0.0.0"
```

保存并重启服务：

sudo systemctl restart ollama
sudo systemctl enable ollama

ollama 无论是本地还是容器部署，都无法直接使用使用全局配置的Proxy代理。

2. 无法直接启动模型

ollma 容器 无法直接启动模型
就好比，我无法直接执行下面命令：

docker run -it -v ollama:/root/.ollama -p 11434:11434 --name ollama2 ollama/ollama:0.5.8 ollama  run deepseek-r1:7b

会报错：Error: unknown command “ollama” for “ollama”
具体为啥可以看官方的 Dockerfile 文件

这样将导致不方便写 docker-compose.yml 或 k8s.yml ，无法让其一步执行完，还得再单独 ollama run 跑一次。
所以有能力的话，最好还是自己做一个 docker 镜像。

3. 500 错误：下载模型时遇到问题

在 ollama run 在下载模型时出现 500 错误的情况。根据我的观察，这可能是因为 ollama 的官方网站或服务在某些时段遭遇了攻击或过载，导致无法正常处理请求。
虽然出现了 500 错误，但等待一段时间后问题会自动恢复。

4. 硬件配置对性能的影响

在使用 deepseek 时，我遇到了性能问题，特别是在硬件配置不达标的情况下，模型的表现会非常差。具体来说：

场景一：

我尝试在一台 32 核 CPU、128GB 内存、机械硬盘的超融合集群的 虚拟机 上部署 8B 模型。结果，模型的表现极差，甚至出现了非常离谱的回答——比如问 7B 和 8B 模型的区别是什么，得到的答案居然是“这两台机器的硬件区别”，完全是乱来。
然后，在一台小米笔记本上部署测试，笔记本配置为 i5-7200U（4核），8GB 内存，SSD 硬盘。虽然这台笔记本的硬件配置远不如前述虚拟机，但 7B 模型 在这台机器上能正经回答关于 7B 和 8B 模型区别 这个问题，相比下效果好很多。

官方建议的硬件配置真的不容忽视，特别是对于 deepseek 这类计算量较大的模型。官方推荐的硬件配置和部署方案如果达不到，精度和准确度都会大打折扣。特别是硬盘方面，SSD 的作用显著，性能差距非常明显。

场景二：

在同一台超微服务器上，用两张不同显卡跑了不同大小的 deepseek-r1 模型，得出以下记录：

显卡	模型	环境	速度
Nvidia 1050	7B	CPU	慢
Nvidia 2080 Ti	7B	`GPU`	快
Nvidia 2080 Ti	8B	`GPU`	快
Nvidia 2080 Ti	32B	CPU	慢

环境 部分，是模型自动跑的，通过 top 、nvidia-smi 等命令查看。

在我使用 1050 显卡 时，7B 模型 未能利用显卡，而是直接使用了 CPU。这可能是因为 ollama 对不同显卡的支持存在兼容性问题，或者是显卡的性能不足以满足模型的需求。而在 2080Ti 上，7B 和 8B 模型 能正常使用显卡，而 32B 模型 则回退到 CPU。这是由于 ollama 的资源调度机制，可能会基于显卡的内存、架构和驱动支持来决定是否使用 GPU。不同的硬件平台会影响其利用 GPU 的优先级。

另外，当使用 CPU 时，由于缺乏显卡的并行处理能力，处理时间会大幅增加，因此 CPU 跑 7B 模型 会非常慢，尤其在大规模推理时，处理速度可能只有 GPU 的几分之一。

5. ollama 启动与 open-webui 调用速度差异

在测试过程中，我发现 直接使用 ollama 启动并与模型对话 的速度比通过 open-webui 调用 API 的速度要快得多。速度差距非常明显，直接启动 ollama 的响应时间更短，几乎可以立刻得到回复，而通过 open-webui 调用 API 时，响应时间则明显较慢。

至于为什么会有这种差异，我猜测是由于 open-webui 在前端和后端之间有额外的通信开销和数据处理，而直接启动 ollama 可以避免这些额外的延迟，直接与模型进行交互。但具体的原因可能还需要更深入的分析，涉及到 API 调用、网络请求等多个因素。

6. 网络配置：开放端口访问

默认情况下，ollama 服务只绑定到 127.0.0.1 地址，这意味着只能在本机访问。如果希望其他机器也能访问服务，可以修改配置。

修改配置方法

打开 ollama.service 文件：

sudo vim /etc/systemd/system/ollama.service

在 [Service] 部分添加：
```
Environment="OLLAMA_HOST=0.0.0.0"
```

保存并重启服务：

sudo systemctl restart ollama
sudo systemctl enable ollama

这样，ollama 就会监听所有 IP 地址，允许其他机器访问。

临时配置方式

你还可以通过设置环境变量来临时修改绑定地址：

export OLLAMA_HOST=0.0.0.0
ollama serve

但是需要注意，使用这种方式时，一旦关闭终端，服务也会停止。如果需要后台运行，可以使用 nohup 或者将其作为系统服务来管理。

7. 内存不足导致的性能问题

由于笔记本（我前面使用笔记本）的内存限制，1.5B 模型 + open-webui 的组合在使用过程中非常慢，尤其是在内存不足时，体验非常差。我曾在笔记本上运行 1.5B 模型，问一个简单的问题竟然等了 5 分钟，连续提问之后，甚至出现了 500 错误，导致 open-webui 服务挂掉（ollama 没挂）。

因为 open-webui 作为前端容器，它不仅需要处理用户的请求，还需要通过 API 与后端模型容器交互。这会导致以下几个因素：

API 调用的额外开销：每次用户请求都需要通过网络与后端容器进行通信。如果系统内存不足，网络请求的延迟和处理时间会增加，容易出现超时、错误等问题，特别是在大量并发请求时，可能导致服务挂掉（如 500 错误）。
请求队列的积压：在内存不足的情况下，open-webui 可能会积压请求，导致响应变慢，最终无法及时处理所有请求，进而导致服务崩溃。

然而，ollama（和其中的 deepseek）容器在内存不够的情况下依旧能够稳定运行，不会像 open-webui 一样挂掉，并且单独提问也比在 open-webui 回答的速度快。这个现象可能与 open-webui 容器在处理大量 API 请求时的资源消耗有关，而 ollama 可能是通过更高效的资源管理，减少了对内存和 CPU 的依赖。

相比之下，ollama 容器直接运行模型，不依赖于外部的 API 调用，且可能具有以下优势：

内部资源管理更高效：ollama 在处理请求时，不需要通过复杂的前端请求-后端响应流程。它将整个流程封装在一个容器内，可能在内存和 CPU 使用上进行了更精简的优化。这使得即使在内存不足的情况下，它依旧能够较为稳定地运行。
直接与模型交互：当你直接与 ollama 容器进行交互时，数据传输的路径更短，计算更加集中，减少了外部请求和资源竞争的问题。
容错性较强：ollama 可能有更好的内存管理策略，比如缓存、分页加载或其他优化策略，能够在内存资源有限的情况下保持运行稳定。