科技资讯

Ollama 生产环境部署完全指南：从容器部署到性能调优

Ollama 生产环境部署完全指南：从容器部…

Ollama 生产环境部署完全指南：从容器部署到性能调优

如果觉得 Ollama 装好就能直接跑、调几个参数就能稳，那大概率离踩坑不远了。上个月那篇本地 AI 实验室的文章发出去后，后台收到最多的留言不是问架构的，而是问具体某个服务的——“Ollama 跑着跑着就卡死了怎么办”、”显存明明够怎么还 OOM”、”多节点怎么共享模型”。

这些问题我全踩过，所以写这篇把 Ollama 从部署到底层调优一次性说透。不管你是在单机上跑着玩，还是准备上多节点集群，这份清单都能直接抄。

一、先说结论：Ollama 的坑在哪

Ollama 的优势就是开箱即用，劣势也是开箱即用——默认配置不是为生产环境准备的。

几个最容易出事的点：

| 坑 | 默认行为 | 后果 |

|—–|———|——|

| 无 CORS 限制 | 只监听 localhost | 跨节点调用直接拒绝 |

| 并发不设限 | 有多少请求接多少 | 显存爆、OOM |

| 模型不卸载 | 加载后常驻 | 切换模型显存不释放 |

| 日志不轮转 | stdout 无限制 | 跑一个月日志吃掉几十 GB |

| 无健康检查 | 没内置探针 | Docker 编排不知服务状态 |

下面每一步都是在修这些默认行为。不做这五件事，Ollama 在线上去就是定时炸弹。

二、Docker 部署：必须改的参数

建议用 Docker Compose 而非裸机安装。裸机装省事一时，后续升级、回滚、隔离全要命。

标准 docker-compose.yml

version: '3.8'

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - ./models:/root/.ollama
      - ./logs:/var/log/ollama
    environment:
      # 生产环境必配参数
      - OLLAMA_HOST=0.0.0.0:11434
      - OLLAMA_ORIGINS=*
      - OLLAMA_NUM_PARALLEL=2
      - OLLAMA_MAX_LOADED_MODELS=1
      - OLLAMA_KEEP_ALIVE=5m
      # 显存与并发控制
      - OLLAMA_FLASH_ATTENTION=1
      - OLLAMA_LLM_LIBRARY=auto
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              capabilities: [gpu]
              count: 1
        limits:
          memory: "32G"
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:11434/api/tags"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

每个环境变量的作用，一个都不能省：

– OLLAMA_HOST=0.0.0.0:11434：默认只绑 127.0.0.1，不改的话跨节点根本调不通

– OLLAMA_ORIGINS=*：跨域，WebUI 如果部署在别的节点必须开

– OLLAMA_NUM_PARALLEL=2：并发上限，24GB 显存跑 7B 模型时最多并行 2 个请求，超了必炸

– OLLAMA_MAX_LOADED_MODELS=1：一次只加载一个模型，换模型自动卸载上一个

– OLLAMA_KEEP_ALIVE=5m：模型空闲 5 分钟后自动卸载释放显存。不设的话模型常驻，切换模型时显存越占越多

– OLLAMA_FLASH_ATTENTION=1：Flash Attention 2，推理速度提升 15-30%，显存占用降低 10-15%

启动前确认 GPU 可用

# 检查 nvidia 驱动
nvidia-smi

# 确认 Docker 能访问 GPU
docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi

如果第二步报错，说明 NVIDIA Container Toolkit 没装：

# Ubuntu/Debian
sudo apt-get install -y nvidia-container-toolkit
sudo systemctl restart docker

三、模型管理：别把硬盘当显存用

这是最常见的低级错误——看到 HuggingFace 上有模型就下，结果一个 70B 模型就 40GB，硬盘一周满，显存更不够。

理性选模型的黄金公式

所需显存 ≈ 参数量(亿) × 1.8 ÷ 量化位数 × 1.1(上下文开销)

举个例子：Qwen2.5-7B，Q4_K_M 量化（4.5bit），上下文 8192 tokens：

7 × 1.8 ÷ 4.5 × 1.1 ≈ 3.1GB ← 这是模型本身
额外上下文开销 ≈ 1-2GB
总计 ≈ 4-5GB

如果你只有 8GB 显存，最大能跑 7B 量化模型，14B 强行加载会自动切到 CPU 推理，速度慢 10 倍。

我的模型组合推荐（24GB 显存场景）

| 场景 | 模型 | 大小 | 显存占用 |

|——|——|——|———|

| 日常对话/问答 | Qwen2.5-7B-Q4_K_M | 4.5GB | ~5GB |

| 代码/逻辑推理 | DeepSeek-Coder-V2-Lite-Q4 | 6GB | ~7GB |

| 长上下文文档分析 | Qwen2.5-14B-Q4_K_M | 8.5GB | ~10GB |

| 轻量快速回复 | Llama-3.2-3B-Q4 | 2GB | ~2.5GB |

关键原则：选模型时显存占用不超过总显存的 80%，留出余量给上下文。

模型下载加速

国内从 Ollama 官方库拉模型经常断流：

# 方案一：配置镜像源
export OLLAMA_MIRROR=https://docker.1ms.run

# 方案二：手动从 HuggingFace 下载后导入
# 下载 GGUF 文件到 models/ 目录
# 创建 Modelfile
cat > Modelfile << 'EOF'
FROM ./qwen2.5-7b-instruct-q4_k_m.gguf
EOF

# 导入到 Ollama
ollama create qwen2.5-7b -f Modelfile

实测：手动导入比在线拉取快 3-5 倍，尤其在晚高峰时段。

四、性能调优：同一块显卡，快慢差 3 倍

同样的硬件，配置对了快一倍不止。

1. 必开 Flash Attention

export OLLAMA_FLASH_ATTENTION=1

Flash Attention 2 通过分块计算注意力机制，24GB 显存跑 14B 模型时，TTFT（首 token 延迟）从 3.2s 降到 1.8s，这是我亲测的数据。

2. 上下文长度控制

# 不是所有场景都需要 32K 上下文
# 在 API 调用时指定
{
  "model": "qwen2.5-7b",
  "messages": [...],
  "options": {
    "num_ctx": 4096   # 日常场景 4K 足够
  }
}

上下文长度每翻一倍，KV Cache 显存占用也翻一倍。4096 tokens 的 KV Cache 约占用 0.5-1GB，32K 则占 4-8GB。 非必要不上长上下文。

3. 批处理调优

# 批量推理时提升吞吐
export OLLAMA_NUM_PARALLEL=2
# 批量大小
export OLLAMA_BATCH_SIZE=512

注意：OLLAMA_NUM_PARALLEL 不是越大越好。24GB 显存跑 7B 模型，并行数设为 4 以上时显存直接爆。2 是最佳值，吞吐和稳定性取得平衡。

4. 显存碎片化清理

连续推理多轮后，显存碎片化会导致新请求分配失败：

# 监控显存使用
watch -n 1 nvidia-smi

# 模型卸载释放显存
ollama stop qwen2.5-7b

# 极端情况：重置 GPU（会杀掉所有 GPU 进程）
# sudo nvidia-smi --gpu-reset

更优雅的做法：在 Open WebUI 里设置会话超时自动释放。

五、多节点场景：模型共享与远程调用

如果你有两台或更多机器，想在一台部署模型、另一台调用，需要打通网络层。

方案一：局域网直接暴露（最简）

# 节点 A（部署模型）
export OLLAMA_HOST=0.0.0.0:11434

# 节点 B（调用）
export OLLAMA_HOST=http://192.168.1.100:11434
ollama run qwen2.5-7b

风险：OLLAMA_ORIGINS 如果设成 *，局域网内任何设备都能调用你的推理接口。内网也不建议裸奔，至少加个 Nginx 反向代理做 IP 白名单：

server {
    listen 11435;
    location / {
        proxy_pass http://127.0.0.1:11434;
        # 只允许特定内网 IP
        allow 192.168.1.0/24;
        allow 100.64.0.0/10;  # Tailscale 网段
        deny all;
    }
}

方案二：Tailscale/Headscale（推荐）

# 两个节点都加入同一个 Tailnet
tailscale up --login-server=https://hs.yourdomain.com

# 节点 A 启动 Ollama（监听所有接口）
docker compose up -d

# 节点 B 通过 Tailscale IP 访问
export OLLAMA_HOST=http://100.64.0.2:11434

这样两台机器之间的流量走端到端加密，不经过公网。

方案三：模型存储共享（NFS）

如果不希望每个节点都下载一遍模型，把模型目录挂到 NAS 上：

volumes:
  # 用 NFS 共享模型目录
  - /mnt/nas/ollama-models:/root/.ollama/models:ro

注意：模型加载时 NFS 延迟必须低于 5ms，否则加载时间会翻倍。建议本地节点至少缓存常用模型。

六、监控告警：别等崩了才发现

没有监控的线上服务，等死。最少要做这三件事：

1. Docker 健康检查

上面的 compose 文件里已经配了 healthcheck。用以下命令看状态：

docker ps --filter "name=ollama" --format "{{.Names}} {{.Status}}"

2. 关键指标抓取

#!/bin/bash
# /opt/scripts/ollama-monitor.sh

# GPU 显存使用
MEM_USED=$(nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits)
MEM_TOTAL=$(nvidia-smi --query-gpu=memory.total --format=csv,noheader,nounits)
MEM_PCT=$((MEM_USED * 100 / MEM_TOTAL))

# 显存超过 85% 告警
if [ $MEM_PCT -gt 85 ]; then
    echo "[ALERT] GPU memory at ${MEM_PCT}% on $(hostname)" | \
        mail -s "Ollama 显存告警" your@email.com
fi

# 模型加载列表
curl -s http://localhost:11434/api/tags | python3 -c "
import sys, json
data = json.load(sys.stdin)
for m in data.get('models', []):
    print(f\"  {m['name']}: {m.get('size', 0)/1e9:.1f}GB\")
"

3. 最简单的一体化方案：netdata

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

装完直接看 GPU 温度、显存使用率、CPU 负载、网络 IO，一个面板全搞定。

七、故障排除：高频问题实录

Q1：Ollama 跑着跑着突然卡死

典型特征：API 没响应，nvidia-smi 看到显存已满，但进程还在。

原因：请求并发超过了显存容量。排查方法：

# 看有多少活跃请求
curl http://localhost:11434/api/tags
docker logs ollama --tail 50 | grep "error\|OOM\|killed"

根治：调低 OLLAMA_NUM_PARALLEL，如果当前设的是 4，降到 2 试试。

Q2：Open WebUI 连不上 Ollama

三步定位法，哪步不通问题就在哪层：

# 1. 容器内能通吗？
docker exec open-webui curl http://ollama:11434/api/tags

# 2. 宿主机能通吗？
curl http://localhost:11434/api/tags

# 3. 跨节点能通吗？
curl http://100.64.0.2:11434/api/tags

最常见的答案：Docker 网络没配对。ollama 和 open-webui 必须在同一个 Docker network 里。

Q3：模型回答质量突然变差

大概率是上下文污染。连续对话时，历史上下文越长，注意力越分散。做两件事：

# 1. 限制上下文长度
# 在 Open WebUI 里设 max_tokens=2048

# 2. 定期清理会话缓存
ollama stop qwen2.5-7b
ollama run qwen2.5-7b  # 重新加载

Q4：拉模型下载到一半断了

# 看已下载的 layer
ls ~/.ollama/models/blobs/ | wc -l

# 重新拉会断点续传
ollama pull qwen2.5-7b

Ollama 的下载是分 layer 的，支持断点续传，重新拉就行。

写在最后

写完这篇，我自己回头看了下之前的部署，发现至少有三处配置是错的——没设 num_parallel、没用 Flash Attention、没做日志轮转。改了之后，同一台机器，同样跑 Qwen2.5-14B，TTFT 从 3.2s 降到了 1.8s，吞吐从 12 tokens/s 提到了 28 tokens/s。

Ollama 本身不复杂，复杂的在于你愿不愿意花半小时把配置吃透。 默认配置只是能跑，生产配置才是稳跑。

如果你也有踩坑经历，或者有不锈钢的优化方案，评论区见。下篇准备写 ComfyUI 的生产部署调优，有需要的评论区扣 1。

类似文章

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注