为什么你的 Ollama 服务总“掉链子”？

很多开发者在本地部署大模型时，往往只满足于跑通 ollama run 这一条命令。模型能对话、代码能生成，就觉得万事大吉。但一旦想把 Ollama 作为后台服务长期运行，或者集成到 VS Code、自动化脚本中时，问题就来了：端口被占用、多模型加载导致内存爆炸、或者插件根本连不上服务。

其实，Ollama 不仅仅是一个命令行工具，它更是一个设计精良的后台服务。默认配置虽然适合单人临时测试，但在复杂的生产力场景下显得捉襟见肘。要让它像数据库或 Web 服务器那样稳定可靠，关键在于环境变量的配置。通过简单的几行 PowerShell 命令，我们就能精准控制它的并发行为和监听策略，彻底解决“不稳定”的痛点。

掌控监听地址：打破本地回环的限制

默认情况下，Ollama 启动后只监听 127.0.0.1:11434。这意味着只有本机进程可以访问它。这在单机开发没问题，但如果你想在局域网内的其他设备调用这台机器的算力，或者在某些容器化、虚拟化环境中让宿主机与虚拟机通信，这个默认限制就成了拦路虎。

更重要的是，有些安全软件或网络策略会对本地回环地址（localhost）的长连接进行干扰，导致插件在长时间无操作后断开连接。显式指定监听地址不仅能解决连通性问题，还能明确服务的边界。

在 Windows 环境下，我们可以通过设置 OLLAMA_HOST 环境变量来修改这一行为。如果你希望服务监听所有网络接口（允许局域网访问），可以将 host 设为 0.0.0.0；如果只是为了确保本地服务稳定性，避免某些应用解析 localhost 失败，显式绑定 127.0.0.1 也是个好习惯。

以下是在 PowerShell 中临时设置并启动服务的命令：

# 设置监听地址为所有接口，端口保持默认的 11434
$env:OLLAMA_HOST = "0.0.0.0:11434"

# 启动 Ollama 服务
ollama serve

如果你希望这个配置永久生效，不需要每次打开终端都输入一遍，可以在系统环境变量中进行设置。右键“此电脑” -> “属性” -> “高级系统设置” -> “环境变量”，在“系统变量”中新建 OLLAMA_HOST，值设为 0.0.0.0:11434。重启终端后，直接运行 ollama serve 即可自动应用该配置。

对于集成到自动化工作流的开发者，这一步至关重要。它确保了无论你的调度脚本运行在什么网络上下文中，都能通过明确的 IP 地址找到 Ollama 服务，避免了因 DNS 解析或 hosts 文件配置差异导致的连接超时。

限制并发模型：防止内存溢出的关键

在资源有限的笔记本或台式机上，最容易出现的问题就是“贪多嚼不烂”。Ollama 默认可能会尝试加载多个模型到显存或内存中，特别是当你同时开启多个聊天窗口，或者有多个 IDE 插件同时发起请求时。对于搭载 Ryzen AI 和 Radeon GPU 的设备，虽然统一内存架构提供了较大的容量，但带宽资源依然是宝贵的。一旦同时加载两个 7B 甚至更大的模型，系统很容易陷入频繁的数据交换，导致推理速度从每秒几十个 token 骤降到个位数，甚至直接触发 OOM（内存溢出）崩溃。

这时候，OLLAMA_MAX_LOADED_MODELS 环境变量就成了你的“保险丝”。它允许你强制限制 Ollama 同时驻留在内存中的模型数量。对于大多数单人开发场景，将其设置为 1 是最稳妥的选择。这意味着当新模型被请求时，旧模型会被卸载，从而保证当前任务拥有全部的硬件资源。

在 PowerShell 中，我们可以这样组合使用：

# 限制最大同时加载模型数量为 1
$env:OLLAMA_MAX_LOADED_MODELS = "1"

# 配合监听地址设置
$env:OLLAMA_HOST = "127.0.0.1:11434"

# 启动服务
ollama serve

这个配置对多用户场景或复杂插件集成意义非凡。想象一下，你的 VS Code 正在使用 Continue 插件调用 Ollama 进行代码补全，而你又打开了一个网页版聊天界面。如果没有并发限制，两个会话可能分别加载了不同版本的模型（比如一个 qwen2.5-coder，一个 llama3），瞬间吃光内存。设置了 MAX_LOADED_MODELS=1 后，Ollama 会智能地管理生命周期，确保同一时间只有一个模型在“舞台”上表演，其他请求需要等待或触发切换。这种机制虽然增加了少量的模型加载延迟，但换来了系统整体的流畅性和稳定性，避免了因资源争抢导致的卡死。

打造坚如磐石的后台服务

配置好环境变量只是第一步，如何让这些配置在后台持久、安静地运行，才是运维的关键。在 Windows 上，直接运行 ollama serve 会占用当前终端窗口，一旦关闭窗口服务就会停止，这显然不适合作为长期运行的后端。

对于需要高可靠性的工作流，建议将 Ollama 注册为 Windows 服务，或者使用简单的批处理脚本配合任务计划程序。这里提供一个简单的思路：创建一个名为 start-ollama.ps1 的脚本文件，内容如下：

# start-ollama.ps1
$env:OLLAMA_HOST = "127.0.0.1:11434"
$env:OLLAMA_MAX_LOADED_MODELS = "1"
# 确保日志输出到文件以便排查问题
ollama serve > "C:\logs\ollama.log" 2>&1

然后，通过 Windows 任务计划程序，设置该脚本在用户登录时自动运行，并选择“不管用户是否登录都要运行”以及“最高权限运行”。这样，Ollama 就会作为一个隐形的后台守护进程存在，即使你关闭了所有窗口，它依然在默默监听端口，随时准备响应 IDE 插件或自动化脚本的请求。

在实际使用中，这种配置带来的提升是显而易见的。你会发现 VS Code 的代码补全不再偶尔转圈等待，自动化测试脚本不会因为连接拒绝而中断，整机的风扇噪音也因为避免了不必要的多模型负载而变得更加平稳。

折腾环境变量的过程，本质上是从“玩具用法”向“工程化用法”的转变。对于依赖本地 AI 提升效率的开发者来说，花十分钟配置好 OLLAMA_HOST 和 OLLAMA_MAX_LOADED_MODELS，换来的是未来数月甚至数年的稳定体验。毕竟，最好的工具不是功能最花的，而是那个你永远不用担心它会挂掉的。