Ollama 私有化与团队部署
一台带显卡的服务器，可以成为整个团队的共享模型服务：容器化编排、内网共享、反向代理、模型分发，本篇把这些拼成一套完整的团队部署方案。
核心认知先建立：Ollama 自身没有鉴权机制，安全边界要靠反向代理和网络策略来搭。
团队部署拓扑总览
推荐的标准拓扑是三段式：成员流量先到反向代理，代理完成鉴权后转发给只听本机回环的 Ollama 服务。
这个结构的关键设计是 Ollama 只监听 127.0.0.1，所有外部访问必须经过代理，鉴权入口因此唯一且可控。
Docker 与 Compose 编排
服务器部署首选 Docker，团队场景用 Compose 固化配置：
# 文件路径：docker-compose.yml
services:
ollama:
image: ollama/ollama # AMD 显卡改用 ollama/ollama:rocm
container_name: ollama
restart: unless-stopped
volumes:
- ollama:/root/.ollama # 模型持久化，升级镜像不丢模型
ports:
- "127.0.0.1:11434:11434" # 只暴露给本机，交给 Nginx 对外
# NVIDIA GPU 直通（需要先装好 NVIDIA Container Toolkit）
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
volumes:
ollama:docker 相关命令：
# 启动 / 查看日志 / 升级
docker compose up -d
docker compose logs -f ollama
docker compose pull && docker compose up -d注意 ports 映射写的是 127.0.0.1:11434:11434 而不是 11434:11434：前者把端口限制在本机回环，外部只能经 Nginx 访问；后者等于把无鉴权服务直接暴露到网卡上，是最常见的团队安全事故来源。
局域网共享一台模型服务器
小团队不想搭代理时，最低成本的共享方式是让 Ollama 直接监听内网：
# 服务器端：监听所有网卡
OLLAMA_HOST=0.0.0.0:11434 ollama serve成员机器上把 OLLAMA_HOST 指向服务器，本地的 ollama 命令就会操作远程服务：
# 成员电脑：CLI 与 SDK 都认这个变量
export OLLAMA_HOST=http://192.168.1.100:11434
# 之后所有命令都作用在服务器上
ollama run qwen3.5多人共享的容量规划直接引用配置章节的公式：并发请求数乘以上下文长度决定显存占用，10 人团队不建议把 NUM_PARALLEL 开到 10，排队往往比挤爆显存更体面。
反向代理与隧道
Nginx 反向代理（推荐）
# 文件路径：/etc/nginx/conf.d/ollama.conf
server {
listen 80;
server_name model.example.com; # 换成你的域名或内网 IP
location / {
proxy_pass http://localhost:11434;
proxy_set_header Host localhost:11434;
# Ollama 流式响应为 NDJSON，建议关闭缓冲避免"卡顿"
proxy_buffering off;
}
}临时隧道：ngrok 与 Cloudflare Tunnel
演示、远程联调场景可以用隧道把本地服务临时暴露到公网：
# ngrok
ngrok http 11434 --host-header="localhost:11434"
# Cloudflare Tunnel
cloudflared tunnel --url http://localhost:11434 --http-host-header="localhost:11434"隧道等于把无鉴权服务开到了公网，仅建议短期演示使用，用完即关；长期外部访问请走带鉴权的 Nginx 方案。
鉴权：自己动手补上安全边界
Ollama 没有内建账号体系，团队部署必须自建鉴权，常见三条路：
| 方案 | 做法 | 适用 |
|---|---|---|
| Nginx Basic Auth | htpasswd 生成密码文件，代理层统一校验 | 小团队，十分钟落地 |
| API 网关 | Kong、APISIX 等网关做 API Key 签发、限流与审计 | 多团队共享、需要计量 |
| 网络隔离 | Ollama 只进内网或 VPN 网段，不暴露公网 | 有企业网络管控的环境 |
以最常用的 Nginx Basic Auth 为例：
# 生成密码文件
sudo htpasswd -c /etc/nginx/.htpasswd zhangsan
# Nginx location 块中追加两行：
# auth_basic "Ollama API";
# auth_basic_user_file /etc/nginx/.htpasswd;以上鉴权方案来自社区通行实践而非 Ollama 官方功能，选择时按团队现有基础设施走，原则只有一条：不要让 11434 直接暴露在不受信网络中。
私有模型的分发与版本管理
团队定制的好模型需要一套分发机制，Ollama 的方案是命名空间加推送。
流程分四步：注册 ollama.com 账号；在官网设置页绑定本机公钥（~/.ollama/id_ed25519.pub）；把模型复制成带用户名的名字；推送。
# 复制成带命名空间的名字，用 tag 标版本
ollama cp runoob-helper myteam/runoob-helper:v1
# 推送到 ollama.com
ollama push myteam/runoob-helper:v1
# 成员拉取使用（私有模型需登录授权账号）
ollama run myteam/runoob-helper:v1版本管理用 tag 表达：v1、v2 各自独立，回退就是改回旧 tag。
完全离线的内网替代方案也存在：把定制的 Modelfile 和权重文件放进内部代码库或文件服务，成员在本地 create 构建。Ollama 官方目前没有提供自建私有仓库的服务端，跨网分发以这两种形态为主。
监控与运维
自建服务的日常运维围绕三件事：服务活着、资源够用、错误可查。
官方提供的抓手是 ollama ps（模型加载与显存）、日志（位置见配置章节汇总表）和 API 的 usage 字段（token 级耗时统计）。
社区方案补齐了指标化监控：开源的 Ollama exporter 可以把请求数、token 吞吐等指标暴露给 Prometheus，用 Grafana 出大盘。需求简单时，一个定时轮询 /api/ps 与日志关键字告警的脚本也够用。
监控方案多为社区维护，选型前确认其支持的 Ollama 版本；本文不锁定具体项目名，以"指标暴露 - 时序库 - 看板"三件套的思路自建亦可。
Kubernetes 部署简介
已有 K8s 基础设施的团队，可以用 Deployment 把 Ollama 跑进集群，要点有三：模型数据用 PVC 持久化、GPU 节点用资源调度声明、服务暴露走集群内 Service。
# 骨架示意：Deployment + GPU 资源声明
apiVersion: apps/v1
kind: Deployment
metadata:
name: ollama
spec:
replicas: 1
template:
spec:
containers:
- name: ollama
image: ollama/ollama
ports:
- containerPort: 11434
volumeMounts:
- name: models # 模型持久化，避免 Pod 重建重新拉取
mountPath: /root/.ollama
resources:
limits:
nvidia.com/gpu: 1 # 声明 GPU，配合集群 GPU 调度
volumes:
- name: models
persistentVolumeClaim:
claimName: ollama-modelsOllama 官方没有发布 Helm Chart，集群部署多依赖社区 Chart 或自研清单；上 K8s 的收益主要在调度与自愈，如果只有一台 GPU 服务器，Docker Compose 通常是更省心的选择。
AI 思考中...