1. 项目概述：Ollama负载均衡服务器的核心价值

在AI应用开发，尤其是基于本地大语言模型（LLM）构建服务的场景里，我们常常会遇到一个瓶颈：单个Ollama实例的处理能力是有限的。当并发请求上来，或者需要同时服务多个不同的模型时，一个实例很容易成为性能瓶颈，导致响应延迟，甚至服务崩溃。直接暴露Ollama的原生端口（默认11434）也存在一定的安全风险，比如模型被误删、数据泄露等。这时候，一个专门为Ollama设计的负载均衡器就显得尤为重要。

我最近深度使用并研究了 adysec/OllamaR 这个开源项目，它正是一个为解决上述痛点而生的高性能、易配置的Ollama负载均衡服务器。它的核心目标非常明确： 将来自客户端的请求，智能、高效地分发到后端多个Ollama服务节点上 ，从而提升整个AI服务集群的可用性、吞吐量和响应速度。简单来说，它让你能用多个“廉价”的Ollama实例，组合出一个稳定、强大的AI服务池。

这个项目最吸引我的地方在于它的“克制”与“专注”。它没有试图去重新实现一个Ollama，而是巧妙地扮演了一个“智能调度员”的角色。它完整支持了最核心的聊天（ /api/chat ）和嵌入（ /api/embed , /api/embeddings ）接口，确保了业务功能的连续性。同时，它主动屏蔽了诸如 /api/delete 、 /api/pull 等具有潜在危险性的管理接口，从架构层面切断了通过负载均衡器攻击后端Ollama服务的路径，安全性设计考虑得很周到。对于需要构建生产级AI应用，或者单纯想优化自己本地AI服务体验的开发者来说，这是一个非常值得投入时间研究的工具。

2. 核心架构与设计思路拆解

要理解 OllamaR 怎么用，首先得弄明白它是怎么“想”的。它的设计哲学可以概括为： 透明代理、安全过滤、动态管理 。

2.1 透明代理与请求分发机制

OllamaR 本质上是一个反向代理服务器。当客户端向 OllamaR 的端口（例如 11435 ）发送请求时， OllamaR 会根据预设的负载均衡策略，从后端的Ollama服务器池中选择一个合适的节点，然后将客户端的请求原封不动地转发过去，并将节点的响应返回给客户端。对于客户端而言，它感知不到后端有多个Ollama实例，仿佛就在和一个高性能的Ollama服务对话。

负载均衡策略 是这里的核心。虽然项目文档没有明确列出所有支持的策略，但根据这类系统的常见实践和其“高性能”的特性描述，我们可以合理推断它至少支持以下几种：

  1. 轮询（Round Robin） ：依次将请求分发到每个后端服务器，实现最简单的负载均摊。
  2. 最少连接（Least Connections） ：将新请求发送给当前连接数最少的后端服务器，这对于处理时间长短不一的AI推理请求尤其有效。
  3. IP哈希（IP Hash） ：根据客户端IP地址计算哈希值，将同一客户端的请求固定分发到某个后端服务器，有助于维持会话状态（虽然Ollama本身是无状态的，但某些客户端配置可能受益于此）。

在实际部署时，选择哪种策略需要结合业务场景。例如，如果请求都是独立的、无状态的聊天问答，轮询或最少连接是不错的选择。如果后端服务器配置异构（有的GPU强，有的CPU强），可能还需要考虑加权策略。

2.2 安全性设计：接口的“白名单”思维

这是 OllamaR 一个非常亮眼的设计。Ollama的原生API提供了完整的模型生命周期管理功能，包括拉取（pull）、删除（delete）、创建（create）等。这些功能在单机开发时很方便，但在多实例、对外服务的生产环境中，就是潜在的安全漏洞。

OllamaR 采取了一种“白名单”策略。它只开放业务必需的、只读或无害的接口：

  • 信息查询类 ： / , /api/tags , /v1/models , /api/version 。这些接口用于检查服务状态和获取模型列表，没有破坏性。
  • 核心功能类 ： /api/chat , /api/embed , /api/embeddings 。这是AI服务的核心，必须开放。
  • 显式屏蔽类 ： /api/show , /api/copy , /api/create , /api/push , /api/delete , /api/pull , /api/ps 。所有涉及模型变更、删除、拉取的操作都被拦截。

这意味着，即使攻击者获取了 OllamaR 的访问权限，他也无法通过它来删除你后端辛苦下载的几十GB模型文件，也无法随意拉取新模型占满磁盘。模型的管理工作必须在后端每个Ollama实例上单独、受控地进行。这种设计实现了 管理面与数据面的分离 ，极大地提升了系统的整体安全性。

2.3 动态可扩展性与服务发现

“支持动态添加或移除后端服务节点，无需重启服务器”这一特性，对于追求高可用的系统至关重要。传统的负载均衡器修改后端列表往往需要重启服务，会导致短暂的连接中断。

OllamaR likely通过以下两种方式之一实现动态性：

  1. 配置文件热重载 ：监控配置文件（如 ollama.db 或一个专门的 config.yaml ）的变化，当文件被更新后，自动重新加载后端服务器列表。
  2. 内置API管理端点 ：提供一个内部的管理API（通常不对外暴露），通过调用此API来增删节点。

项目提到使用 ollama.db 来存储源服务器列表，并通过 /api/tags 接口获取。这里我的理解是： ollama.db 可能是一个轻量级的数据库或结构化文件，里面记录了所有可用的后端Ollama服务器地址（如 http://192.168.1.10:11434 , http://192.168.1.11:11434 ）。 OllamaR 会定期或按需读取这个列表。而 /api/tags 接口的“获取”，可能指的是 OllamaR 会聚合所有后端服务器的模型列表，返回一个统一的视图给客户端。

实操心得：后端节点的健康检查 一个成熟的负载均衡器必须包含健康检查机制。 OllamaR 很可能（或应该）实现了对后端Ollama节点的定期健康探测，比如定时调用 /api/tags 或 / 接口。如果某个节点连续多次响应失败或超时，负载均衡器会将其从可用池中标记为“下线”，不再向其分发流量，直到它恢复健康。在你自己设计类似系统或评估时，一定要验证这个功能，它是实现“快速故障转移”的基础。

3. 详细部署与配置实操指南

理论讲清楚了，我们来看看如何亲手搭建一个 OllamaR 服务。以下步骤基于从源码构建和配置的通用流程，假设你已经在本地或服务器上准备好了基础环境。

3.1 环境准备与源码获取

首先，你需要一个Linux或类Unix环境（Windows可通过WSL2）。确保已安装Go语言开发环境（建议Go 1.19+），因为项目是用Go编写的。 

# 1. 克隆仓库
git clone https://github.com/adysec/OllamaR.git
cd OllamaR

# 2. 检查Go环境
go version

# 3. 拉取项目依赖
go mod tidy

3.2 编译与安装

项目通常提供了Makefile或直接的go build指令。 

# 方式一：直接使用go build (推荐，最透明)
go build -o ollamar main.go # 假设入口文件是main.go，请根据实际项目结构调整

# 方式二：如果有Makefile
make build

编译完成后，当前目录下会生成一个名为 ollamar （或你指定的名字）的可执行文件。你可以把它移动到系统路径下，比如 /usr/local/bin/ ，方便全局调用。 

sudo mv ollamar /usr/local/bin/

3.3 配置后端服务器列表

这是最关键的一步。你需要告诉 OllamaR 你的“兵”都在哪里。根据项目说明，它使用 ollama.db 文件。我们需要创建这个文件。它很可能是一个JSON或类似格式的文本文件。

创建一个名为 ollama.db 的文件，内容如下所示（这是一个JSON格式的示例，具体格式请以项目README为准）： 

{
  "servers": [
    {
      "name": "ollama-node-1",
      "url": "http://192.168.1.100:11434",
      "weight": 10,
      "max_conns": 100
    },
    {
      "name": "ollama-node-2",
      "url": "http://192.168.1.101:11434",
      "weight": 10,
      "max_conns": 100
    },
    {
      "name": "cloud-ollama",
      "url": "https://api.example-ollama.com", // 示例：公网Ollama服务
      "weight": 5,
      "max_conns": 50
    }
  ]
}

配置参数解析：

  • name : 后端服务器标识，便于在日志中区分。
  • url : Ollama实例的完整访问地址。支持内网和公网地址。
  • weight : 权重。在加权轮询或加权最少连接策略中，权重高的节点获得更多流量。你可以根据服务器硬件性能（GPU显存、CPU核心数）来设置。
  • max_conns : 该节点最大并发连接数限制，用于防止过载。

重要注意事项：后端Ollama服务准备 在配置 ollama.db 之前，请确保列表中的每个Ollama服务都是独立且正常运行的。在每个后端服务器上，你需要：

  1. 正确安装并启动了Ollama。
  2. 已经拉取（ ollama pull ）了需要的模型，例如 llama3.1:8b , qwen2.5:7b 等。
  3. 防火墙规则允许 OllamaR 服务器访问其11434端口（或你自定义的端口）。
  4. 特别注意 ：如果你使用公网Ollama服务，请确保其API兼容性，并且注意网络延迟和潜在费用。

3.4 启动OllamaR服务

假设你的配置文件 ollama.db 放在 /etc/ollamar/ 目录下，你可以这样启动服务： 

# 指定配置文件和监听端口启动
ollamar --config /etc/ollamar/ollama.db --port 11435

或者，如果程序支持环境变量配置： 

export OLLAMAR_CONFIG_PATH=/etc/ollamar/ollama.db
export OLLAMAR_PORT=11435
ollamar

启动后，你应该看到类似以下的日志，表明服务已启动并在监听指定端口，并且成功连接到了后端节点。 

[INFO] 加载配置文件: /etc/ollamar/ollama.db
[INFO] 发现 3 个后端服务器。
[INFO] 开始监听地址: 0.0.0.0:11435
[INFO] 健康检查已启动。

3.5 验证服务状态

使用 curl 命令或任何HTTP客户端（如Postman）测试 OllamaR 是否工作正常。 

# 1. 测试基础端点，应返回"Ollama is running"
curl http://localhost:11435/

# 2. 获取聚合的模型列表 (Ollama原生接口)
curl http://localhost:11435/api/tags

# 3. 获取聚合的模型列表 (OpenAI兼容接口)
curl http://localhost:11435/v1/models

# 4. 测试聊天接口 (示例，使用DeepSeek-R1模型)
curl http://localhost:11435/api/chat -d '{
  "model": "deepseek-r1:latest",
  "messages": [
    {"role": "user", "content": "你好，请介绍一下你自己。"}
  ],
  "stream": false
}'

如果一切顺利， /api/tags 和 /v1/models 应该返回一个合并了所有后端服务器模型的列表。 /api/chat 的请求会被随机或按策略分发到某一个后端节点执行并返回结果。

4. 高级配置与性能调优

基础服务跑起来之后，我们可以针对生产环境进行一些优化。

4.1 负载均衡策略选择

如果 OllamaR 支持通过配置选择策略，你可以在 ollama.db 或另一个主配置文件中指定。例如： 

{
  "load_balancer": {
    "strategy": "least_connections", // 可选：round_robin, least_conns, ip_hash
    "health_check_interval": "10s",
    "fail_threshold": 3
  },
  "servers": [...]
}
  • strategy : 负载均衡策略。
  • health_check_interval : 对后端节点进行健康检查的频率。
  • fail_threshold : 连续失败多少次后标记节点不健康。

4.2 连接池与超时设置

AI模型推理是计算密集型任务，请求耗时可能从几百毫秒到数十秒不等。合理的超时和连接池设置能防止资源耗尽。 

{
  "server": {
    "read_timeout": "300s",   // 请求读取超时，对于长文本生成要设大
    "write_timeout": "300s",  // 响应写入超时
    "idle_timeout": "60s"     // 连接空闲超时
  },
  "upstream": {
    "max_idle_conns_per_host": 100, // 每个后端主机最大空闲连接数
    "dial_timeout": "5s"            // 连接后端超时时间
  }
}

4.3 日志与监控

生产环境必须要有日志。查看 OllamaR 是否支持日志级别配置（如DEBUG, INFO, WARN, ERROR）。将日志级别设置为INFO，并配置日志轮转，避免磁盘被撑满。

同时，考虑集成监控系统（如Prometheus+Grafana），如果 OllamaR 暴露了Metrics端点（例如 /metrics ），你可以监控：

  • 请求总量（QPS）
  • 请求延迟分布（P50, P95, P99）
  • 后端节点的健康状态
  • 当前活跃连接数

这些指标是容量规划和故障排查的黄金数据。

5. 典型使用场景与集成示例

了解了如何部署，我们来看看它具体能在哪些场景下发光发热。

5.1 场景一：本地多GPU服务器负载均衡

假设你有一台服务器，装了两张甚至更多张GPU卡。单个Ollama实例默认会使用所有可用的GPU，但这可能不是最优的。你可以启动多个Ollama实例，每个实例绑定到不同的GPU，然后通过 OllamaR 进行负载均衡。

操作步骤：

  1. 启动Ollama实例1，绑定到GPU 0： 
    CUDA_VISIBLE_DEVICES=0 ollama serve
# 或者通过Ollama的环境变量配置
  2. 启动Ollama实例2，绑定到GPU 1： 
    CUDA_VISIBLE_DEVICES=1 ollama serve
  3. 在两个实例上分别拉取模型。
  4. 配置 OllamaR 的 ollama.db ，将 localhost:11434 和 localhost:11435 （第二个实例需指定不同端口）作为两个后端节点。
  5. 客户端所有请求发往 OllamaR ，它会将计算任务分摊到两张GPU上，显著提升并发处理能力。

5.2 场景二：混合云与本地服务代理

你的应用可能需要同时访问本地私有模型和云端强大的公有模型（如通过OpenAI兼容API访问的云服务）。 OllamaR 可以帮你统一入口。

配置示例 ( ollama.db ): 

{
  "servers": [
    {"name": "local-llama", "url": "http://localhost:11434"},
    {"name": "cloud-gpt", "url": "https://api.openai.com/v1", "weight": 1} // 注意：需要处理鉴权头转发
  ]
}

在这个场景下， OllamaR 需要能够处理向后端转发自定义HTTP Header（如 Authorization ）。你需要确认 OllamaR 是否支持此功能，或者在代码层面进行修改以支持。这样，客户端可以用同一套代码，通过选择不同的 model 名称（如 gpt-4o vs llama3.1:8b ），来无缝切换使用本地或云端模型。

5.3 场景三：作为AI应用的后端服务层

在微服务架构中，你的Web应用后端（如Python Flask、Node.js服务）不应该直接连接多个Ollama实例。最佳实践是让 OllamaR 作为独立的“AI网关”或“模型服务层”。 

[客户端] -> [Web应用服务器] -> [OllamaR负载均衡器] -> [多个Ollama实例]

这样做的好处是：

  • 解耦 ：Web应用无需关心后端有多少个Ollama实例、它们在哪里。
  • 弹性 ：可以随时在 OllamaR 层增减Ollama节点，Web应用无感知。
  • 专业化 ： OllamaR 可以专注于路由、负载均衡、熔断降级等网络治理功能。

6. 常见问题排查与运维技巧

在实际运行中，你可能会遇到以下问题。这里记录了我的排查思路和解决方法。

6.1 问题排查清单

问题现象 可能原因 排查步骤与解决方案
启动 OllamaR 失败，提示端口占用 端口已被其他进程使用 sudo lsof -i :11435 查看占用进程，终止或为 OllamaR 更换端口。
请求 /api/tags 返回空列表或部分模型缺失 1. 后端Ollama服务未启动或网络不通。
2. 后端模型未成功拉取。
3. OllamaR 配置的后端地址错误。 		1. 逐一 curl 后端 /api/tags 接口，确认每个节点可达且返回正常。
2. 登录后端服务器，运行 ollama list 确认模型存在。
3. 检查 ollama.db 中的 url 格式是否正确（有无多余空格）。
聊天请求超时或返回5XX错误 1. 后端Ollama实例处理超时。
2. 负载均衡器到后端的网络延迟高。
3. 后端实例崩溃。 		1. 查看 OllamaR 日志，看错误是来自哪个后端节点。
2. 直接请求该问题节点的 /api/chat ，看是否复现。
3. 检查该节点的系统资源（GPU内存、CPU、磁盘IO），可能是OOM导致。
4. 适当调大 OllamaR 的 read_timeout 和 write_timeout 。
请求被拒绝，返回 403 或 Method Not Allowed 请求了被 OllamaR 屏蔽的接口，如 /api/delete 。 确认客户端代码是否误调了管理接口。生产环境应只使用 /api/chat 和 /api/embed 。
性能不佳，感觉没有负载均衡 负载均衡策略配置不当，或所有请求被哈希到同一节点。 1. 检查负载均衡策略。如果是 ip_hash ，且所有测试请求来自同一客户端IP，那就会落到同一节点。改为 round_robin 或 least_connections 测试。
2. 查看 OllamaR 日志，确认请求是否被分发到不同后端。

6.2 运维技巧与心得

  1. 灰度发布与模型更新 ：当需要更新后端某个Ollama实例的模型时，可以先将该节点从 ollama.db 配置中移除（或标记为禁用），然后进行更新操作。更新验证无误后，再将其重新加入集群。这样可以实现不中断服务的模型更新。

  2. 配置版本化管理 ：将 ollama.db 配置文件纳入Git等版本控制系统。任何后端节点的增减、权重的调整，都通过提交更改、然后触发 OllamaR 配置热重载（或优雅重启）来完成，确保变更可追溯、可回滚。

  3. 结合容器化部署 ：如果你使用Docker或Kubernetes，可以将每个Ollama实例及其模型打包成一个容器。 OllamaR 也可以容器化。在K8s中，你可以使用Service和Endpoint来自动发现Ollama Pod，但 OllamaR 的静态文件配置方式可能更简单直接。考虑使用ConfigMap来管理 ollama.db 。

  4. 监控告警 ：除了基础的QPS和延迟，要重点关注后端节点的GPU内存使用率。如果某个节点的GPU内存持续占满，可能意味着分配给它的负载过重，需要考虑增加节点或调整权重。可以设置告警，当节点健康检查连续失败时，及时通知运维人员。

  5. 压力测试 ：在上线前，使用工具（如 wrk , locust ）模拟高并发聊天请求，对 OllamaR 集群进行压力测试。观察在持续高负载下，负载是否均衡，系统资源是否出现瓶颈，以及错误率如何。这能帮助你确定当前集群的容量上限。

OllamaR 这个项目为Ollama的规模化应用提供了一个轻量级、高安全性的解决方案。它可能不像一些企业级负载均衡器（如Nginx Plus, HAProxy）功能那么全面，但其对Ollama API特性的深度理解和安全裁剪，让它在这个细分领域非常实用。对于中小型团队或个人开发者，想要快速构建一个稳定、可扩展的本地AI服务网关，从 OllamaR 开始入手，是一个性价比极高的选择。

# Ollama # 负载均衡
Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

AI Agent编排：复杂工作流的自动化实现

在深入探讨Agent编排之前，我们首先需要明确什么是AI Agent。AI Agent是一个能够感知环境、做出决策并采取行动的自主实体。感知模块：接收和处理环境信息推理/决策模块：基于感知信息进行思考和决策行动模块：执行具体的操作（如调用工具、生成文本）记忆模块：存储历史信息和知识通信模块：与其他Agent或系统进行交互Agent编排（Agent Orchestration）是指对多个Agent的

avatar AI Agent技术社区

AI Agent的多轮对话状态管理

在深入探讨之前，让我们首先明确几个核心概念：AI Agent：一种能够感知环境、做出决策并执行行动的智能实体。在对话系统中，AI Agent通常指能够理解用户意图、保持对话上下文并生成有意义响应的系统。多轮对话：不同于单轮问答，多轮对话是指用户与系统之间进行的连续、有上下文关联的交互序列。对话状态管理(Dialogue State Tracking, DST)：是多轮对话系统中的核心组件，负责在对

avatar AI Agent技术社区
cover

阶跃星辰 StepAudio 3：五款语音模型一次放出，全双工对话拿下两个全球第一

avatar AI Agent技术社区