🚀 背景与痛点
最近在部署一台拥有 8 张 NVIDIA RTX 4090 的高性能服务器时，我遇到了一个典型的“算力浪费”问题。
场景复现：
使用 Ollama 运行 Gemma 27B 模型。一张 4090 (24GB 显存) 绰绰有余。然而，当大量并发请求涌入时，通过 nvidia-smi或gpustat -i 观察发现了一个尴尬的现象：
“一核有难，七核围观” —— 只有 GPU 0 显存爆满、拼命工作，而 GPU 1 到 GPU 7 却全程空闲，FPS（每秒生成token数）惨不忍睹。
🧐 原因深度分析
这是由 Ollama（基于 llama.cpp）默认的调度策略决定的：
- 优先单卡加载：如果单张显卡能装下模型，Ollama 为了减少 PCIe 通信延迟，会优先将模型完整加载到一张卡上，而不是拆分。
- 缺乏自动数据并行：Ollama 原生不支持“检测到高并发，自动在空闲显卡上启动副本”。它擅长 模型并行（大模型切分到多卡），而不支持 数据并行（多卡跑多份副本）。
结论：为了让 8 张卡同时处理请求，我们需要手动构建 “多实例 + 负载均衡” 架构。
🛠️ 解决方案架构
我们采用 Nginx + 多 Ollama 实例 的方案，架构逻辑如下：
- 后端层：启动 8 个独立的 Ollama 进程，分别绑定 GPU 0 - 7，监听 11534 - 11541 端口。
- 网关层：使用 Nginx 作为统一反向代理，负责鉴权（IP 白名单）和智能负载均衡。
- 优化层：配置显存自动释放策略，并解决 Root 权限下的路径映射问题。
第一步：编写集群启动脚本
我们需要一个脚本来批量启动 8 个进程，并注入显卡隔离、模型路径等环境变量。
创建脚本 start_cluster.sh：
#!/bin/bash
# ================= ⚙️ 配置区域 =================
# 1. 模型存储路径 (关键)
# 官方安装的 Ollama 模型通常在系统目录，而非 Root 目录。
# 必须显式指定，否则会报 "model not found"。
MODEL_PATH="/usr/share/ollama/.ollama/models"
# 2. 起始端口 (避开默认的 11434)
BASE_PORT=11534
# 3. 显存驻留策略
# "15s" 表示无请求 15秒后自动释放显存 (默认是5分钟)
# 既能应对突发并发，又能让显卡在空闲时降温节能
KEEP_ALIVE="15s"
# ===========================================
echo "🚀 正在启动 Ollama 多卡负载均衡集群..."
echo "📂 模型路径: $MODEL_PATH"
echo "⏱️ 显存策略: $KEEP_ALIVE"
# 循环启动 8 个实例 (对应 GPU 0-7)
for i in {0..7}; do
CURRENT_PORT=$((BASE_PORT + i))
# 核心原理：
# CUDA_VISIBLE_DEVICES=$i : 显卡隔离，让该进程只能看到第 i 张卡
# OLLAMA_MODELS=$MODEL_PATH : 强制指向系统公共模型库
# OLLAMA_HOST=127.0.0.1:... : 绑定本地回环，拒绝外部直连
CUDA_VISIBLE_DEVICES=$i \
OLLAMA_MODELS=$MODEL_PATH \
OLLAMA_HOST=127.0.0.1:$CURRENT_PORT \
OLLAMA_KEEP_ALIVE=$KEEP_ALIVE \
nohup ollama serve > ollama_gpu_$i.log 2>&1 &
echo " ✅ 实例 $i (GPU $i) 已启动 | 端口: $CURRENT_PORT"
done
echo "🎉 集群启动完毕！"
⚠️ 避坑指南：如果你以
root身份运行脚本，Ollama 默认会去/root/.ollama找模型。如果你之前是用普通用户或官方脚本安装的，模型其实在/usr/share/ollama。如果不加OLLAMA_MODELS变量，百分百报错。
第二步：配置 Nginx 负载均衡
Nginx 的作用不仅仅是分发，关键在于 流式输出支持 和 智能调度。
修改 Nginx 配置文件（通常位于 /etc/nginx/nginx.conf 或 conf.d/ 下）：
http {
# 1. 定义负载均衡组 (Upstream)
upstream ollama_gpu_cluster {
# 🔥 核心策略：最少连接 (least_conn)
# 相比轮询(Round Robin)，它能将新请求发给当前"最闲"的显卡。
# 避免将新请求硬塞给正在生成长文的忙碌显卡。
least_conn;
server 127.0.0.1:11534;
server 127.0.0.1:11535;
server 127.0.0.1:11536;
server 127.0.0.1:11537;
server 127.0.0.1:11538;
server 127.0.0.1:11539;
server 127.0.0.1:11540;
server 127.0.0.1:11541;
}
server {
listen 8080; # 对外服务端口
# 2. 安全控制：IP 白名单
allow 127.0.0.1;
allow 192.168.1.0/24; # 仅允许内网段
deny all; # 拒绝其他人
location / {
proxy_pass http://ollama_gpu_cluster;
# 3. ⚡️ 关键优化：关闭缓存
# 必须关闭！否则 LLM 的流式吐字(Streaming)会卡顿，
# 变成等生成完了才一次性显示。
proxy_buffering off;
# 4. 防止长文生成中断
proxy_read_timeout 600s;
# 5. 透传真实 IP
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
}
第三步：部署与验证
1. 清理环境
在启动前，务必清理可能残留的旧进程（保留默认的 11434 全局服务）：
ps -ef | grep "ollama serve" | grep -v "11434" | awk '{print $2}' | xargs kill -9
2. 启动集群
bash start_cluster.sh
3. 压测验证
发起并发请求，观察 nvidia-smi或gpustat -i：
# 模拟请求
curl http://localhost:8080/api/generate -d '{"model": "gemma:27b", "prompt": "你好"}'
效果立竿见影：当你发起 8 个并发请求时，8 张 RTX 4090 全线飘红，算力拉满，并发吞吐量（TPS）直接翻了 8 倍！
🎁 进阶：配置开机自启 (Systemd)
手动跑脚本重启就没了，生产环境必须上 Systemd 服务。
- 新建服务文件：
/etc/systemd/system/ollama-cluster.service - 写入以下内容：
[Unit]
Description=Ollama 8-GPU Cluster Service
After=network.target ollama.service
[Service]
Type=forking
# 指向你的脚本路径
ExecStart=/bin/bash /path/to/your/start_cluster.sh
RemainAfterExit=yes
User=root
Restart=always
[Install]
WantedBy=multi-user.target
- 启用服务：
systemctl daemon-reload
systemctl enable ollama-cluster
systemctl start ollama-cluster
这样，你的 8 卡推理集群就变成了一个稳健的系统服务，开机即用！
📝 总结
对于 27B 这种单卡能吃下的中型模型，“多实例 + Nginx 负载均衡” 是目前性价比最高的并发提升方案。
- 优点：零代码修改、兼容原生 API、支持权限控制、极低延迟。
- 缺点：显存占用翻倍（Data Parallelism 的必然代价）。
希望这篇指南能帮你的 4090 集群火力全开！
版权属于：soarli
本文链接：https://blog.soarli.top/archives/788.html
转载时须注明出处及本声明。
