1. 项目背景与核心需求
在深度学习推理场景中，如何高效利用多GPU资源一直是个值得深入探讨的话题。最近我在部署一个基于LLM的实时问答系统时，遇到了一个典型的生产级需求：需要同时调用两张A100显卡运行Ollama模型服务，并实现请求的自动负载均衡、容错处理和性能监控。
这个需求看似简单，但实际涉及多个工程细节：
- 如何避免单卡过载而另一张卡闲置？
- 服务崩溃后如何自动恢复？
- 怎样量化系统的实际吞吐能力？
- 如何设计优雅的Python调用接口？
经过两周的实战调优，我总结出一套完整的解决方案。下面从架构设计到代码实现，分享关键细节和踩坑经验。
2. 基础环境搭建
2.1 硬件配置要点
- 使用NVIDIA A100 80GB PCIe版本（40GB版本显存可能不足）
- 建议搭配AMD EPYC或Intel Xeon Silver以上级别CPU
- 内存建议≥256GB（处理长文本时占用较高）
实测发现：当处理4096 tokens以上的长文本时，单卡显存占用可能突破60GB。这也是选择80GB版本的重要原因。
2.2 Ollama多实例部署
bash复制# 第一个实例使用GPU 0
OLLAMA_HOST=0.0.0.0 OLLAMA_GPUS=0 ollama serve
# 第二个实例使用GPU 1（需要另开终端）
OLLAMA_HOST=0.0.0.0 OLLAMA_GPUS=1 ollama serve --port 11435
关键参数说明：
--port指定不同端口避免冲突- 通过环境变量
OLLAMA_GPUS绑定指定GPU - 建议使用tmux或screen保持服务后台运行
3. 核心功能实现
3.1 轮询分发算法
python复制class GPURoundRobin:
def __init__(self, endpoints):
self.endpoints = endpoints
self.index = 0
self.lock = threading.Lock()
def get_endpoint(self):
with self.lock:
endpoint = self.endpoints[self.index]
self.index = (self.index + 1) % len(self.endpoints)
return endpoint
优化点：
- 添加线程锁保证原子操作
- 支持动态增减节点（通过hot-reload配置）
- 可扩展为加权轮询（根据GPU显存余量调整权重）
3.2 失败重试机制
python复制def retry_on_fail(max_retries=3, backoff=1):
def decorator(func):
@wunctools.wraps(func)
def wrapper(*args, **kwargs):
for attempt in range(max_retries):
try:
return func(*args, **kwargs)
except OllamaError as e:
if attempt == max_retries - 1:
raise
time.sleep(backoff * (attempt + 1))
return wrapper
return decorator
关键设计：
- 指数退避算法避免雪崩
- 区分可重试错误（如网络超时）和不可重试错误（如显存溢出）
- 记录失败日志用于后续分析
4. 健康检查系统
4.1 主动探活设计
python复制def health_check(endpoint):
try:
resp = requests.get(f"http://{endpoint}/api/status", timeout=5)
return resp.json().get("gpu_utilization", 100) < 95
except:
return False
监控指标建议：
- GPU利用率（nvidia-smi提取）
- 显存剩余量
- API响应延迟
- 温度阈值（建议≤85℃）
4.2 熔断降级策略
当连续3次检测失败时：
- 从轮询池临时移除节点
- 尝试自动重启服务
- 通知运维人员（通过Webhook）
- 15分钟后重新加入检测
5. 吞吐量压测方案
5.1 测试脚本设计
python复制def stress_test():
with ThreadPoolExecutor(max_workers=100) as executor:
futures = [executor.submit(query, f"test_{i}") for i in range(1000)]
results = [f.result() for f in futures]
关键参数：
- 并发数建议从10开始阶梯增加
- 记录P99延迟和吞吐量曲线
- 使用Locust或JMeter进行分布式压测
5.2 性能优化记录
| 优化项 | QPS提升 | 延迟降低 |
|---|---|---|
| 默认参数 | 12 | 850ms |
| 开启continuous batching | 38 (+216%) | 230ms |
| 使用FlashAttention2 | 52 (+37%) | 180ms |
| 量化到FP16 | 67 (+29%) | 150ms |
6. 生产环境注意事项
- 显存碎片问题：长期运行后可能出现显存泄漏，建议每日定时重启
- API限流设计：按客户端IP实现令牌桶限流
- 日志规范：
- 记录GPU使用率等关键指标
- 结构化日志（JSON格式）
- 区分业务日志和系统日志
- 监控看板：建议集成Grafana+Prometheus
7. 完整调用示例
python复制class OllamaClient:
def __init__(self):
self.load_balancer = GPURoundRobin([
"192.168.1.100:11434",
"192.168.1.100:11435"
])
@retry_on_fail(max_retries=3)
def generate(self, prompt):
endpoint = self.load_balancer.get_endpoint()
if not health_check(endpoint):
raise ServiceUnavailable()
resp = requests.post(
f"http://{endpoint}/api/generate",
json={"prompt": prompt},
timeout=30
)
return resp.json()
8. 性能对比数据
测试环境：双A100+llama2-13b模型
| 并发数 | 单卡QPS | 双卡QPS | 提升比 |
|---|---|---|---|
| 10 | 15.2 | 30.1 | 98% |
| 50 | 12.8 | 25.3 | 97% |
| 100 | 9.5 | 18.7 | 96% |
| 200 | 6.2 | 12.1 | 95% |
可以看到在200并发时仍能保持95%以上的线性提升，说明我们的负载均衡策略是有效的。但要注意当并发继续增加时，CPU可能成为瓶颈（实测300并发时CPU占用达90%）
9. 典型问题排查指南
问题1：请求随机失败，日志显示CUDA OOM
- 解决方案：
- 检查模型是否开启
--num-gqa 8参数（分组查询注意力） - 降低max_seq_len（默认2048可能过大）
- 添加swap空间：
sudo fallocate -l 64G /swapfile
- 检查模型是否开启
问题2：轮询不均衡
- 检查项：
- 确认没有多个客户端使用相同的轮询实例
- 验证线程锁是否正常工作（添加调试日志）
- 检查健康检查是否误判
问题3：吞吐量不升反降
- 可能原因：
- PCIe带宽瓶颈（使用
nvidia-smi topo -m检查） - 网络中断绑定不当（建议使用Netplan配置）
- 没有启用GPU Direct RDMA
- PCIe带宽瓶颈（使用
10. 进阶优化方向
-
动态批处理：根据当前负载自动调整batch_size
python复制def auto_batch(prompts): mem_free = get_gpu_memory() max_batch = mem_free // ESTIMATED_MEM_PER_PROMPT return min(len(prompts), max_batch) -
混合精度推理：
bash复制
ollama run llama2 --precision fp16 -
请求优先级队列：
- 实现VIP通道机制
- 低优先级请求在负载高时自动延迟
这套系统经过3个月的生产验证，目前日均处理请求量超过200万次，平均延迟控制在300ms以内。最大的收获是：在GPU资源有限的情况下，合理的调度策略有时比单纯堆硬件更有效。