Ollama部署本地大模型生产就绪：ChatGLM3-6B-128K健康检查与自动扩缩容-开发者社区

Ollama部署本地大模型生产就绪：ChatGLM3-6B-128K健康检查与自动扩缩容

想用ChatGLM3-6B-128K处理长文档，但担心部署后服务不稳定？好不容易把模型跑起来了，却不知道它到底健不健康，能不能扛住真实用户的访问压力？

很多朋友在用Ollama部署完模型后，就停留在“能跑起来”的阶段。但要把一个本地大模型真正用到生产环境，比如做个内部知识库问答或者文档分析工具，光能跑起来是远远不够的。服务会不会突然挂掉？并发高了会不会卡死？这些才是决定项目成败的关键。

今天，我们就来解决这个问题。我会带你一步步为Ollama部署的ChatGLM3-6B-128K服务，搭建一套生产级的健康检查与自动扩缩容方案。这套方案能让你实时掌握服务状态，并在流量高峰时自动扩容，低谷时自动缩容，既保证服务稳定，又节省资源。

1. 为什么需要生产就绪的部署？

你可能已经用Ollama成功拉取并运行了ChatGLM3-6B-128K模型，通过简单的curl命令或者Web界面就能进行对话。这很棒，但这只是第一步。

想象一下这几个场景：

凌晨三点，你的自动化文档处理脚本在调用模型，但模型服务因为内存泄漏悄悄崩溃了，直到第二天早上你才发现任务失败。
市场部门突然要做一次大规模的客户反馈分析，短时间内发起上百个并发请求，你的单实例模型服务直接“罢工”，请求全部超时。
你无法准确知道模型服务当前的负载、内存使用情况，以及每次推理的耗时，优化和排障全靠猜。

“生产就绪”的核心，就是把一个脆弱的、手动维护的玩具服务，变成一个健壮的、可观测的、能自动应对变化的工业级服务。对于ChatGLM3-6B-128K这种擅长处理长文本的模型来说，其应用场景（如长文档摘要、法律合同分析、代码库理解）往往伴随着突发和持续的负载，生产化部署的需求更加迫切。

接下来的内容，我们将围绕两个核心目标展开：

健康检查：给服务装上“仪表盘”和“心跳监测”，随时知道它是否活着、是否健康。
自动扩缩容：给服务赋予“弹性”，忙时加人，闲时减员，从容应对流量波动。

2. 基础环境与模型部署回顾

在添加高级功能之前，我们先确保基础是牢固的。这里快速回顾一下使用Ollama部署ChatGLM3-6B-128K的关键步骤。

2.1 部署ChatGLM3-6B-128K

如果你还没有部署，可以通过以下命令完成。Ollama的魅力就在于其简洁性。

# 拉取并运行ChatGLM3-6B-128K模型 ollama run chatglm3:6b-128k

运行后，Ollama会在本地启动一个API服务（默认在11434端口）。你可以通过REST API与它交互：

# 测试模型是否正常工作 curl http://localhost:11434/api/generate -d '{ "model": "chatglm3:6b-128k", "prompt": "请用一句话介绍你自己。", "stream": false }'

如果看到返回了JSON格式的生成结果，说明基础服务部署成功。但此时的服务是“裸奔”的，缺乏监控和管理能力。

2.2 理解Ollama的API端点

要实现健康检查，我们需要知道Ollama提供了哪些“探头接口”。除了常用的/api/generate（生成）和/api/chat（对话）外，Ollama还有一个非常有用的管理接口：

# 查看服务器状态和已加载的模型 curl http://localhost:11434/api/tags

这个接口返回的响应速度很快，非常适合作为健康检查的“存活探针”。我们后续会用到它。

3. 实施健康检查方案

健康检查是系统的“听诊器”。我们将其分为两层：存活检查和就绪检查。

3.1 存活检查：服务是否在运行？

存活检查最简单，只关心Ollama的进程是否存在。我们可以写一个简单的Shell脚本，定期调用一个轻量级API。

创建一个文件health_check.sh：

#!/bin/bash # 存活检查脚本 OLLAMA_HOST="localhost:11434" # 使用 /api/tags 端点，它轻量且快速 response=$(curl -s -o /dev/null -w "%{http_code}" http://$OLLAMA_HOST/api/tags --max-time 5) if [ "$response" = "200" ]; then echo "$(date): Ollama 服务存活正常。" exit 0 else echo "$(date): 错误！无法连接到Ollama服务，HTTP状态码: $response" exit 1 fi

给脚本添加执行权限：chmod +x health_check.sh。你可以使用Linux的cron定时任务来每分钟执行一次这个脚本，并将错误日志发送给你。

但这种方式比较原始。在生产环境中，我们通常使用更专业的工具来管理和调度容器，比如Docker和Kubernetes。它们内置了强大的健康检查机制。

3.2 使用Docker Compose实现健康检查

如果我们用Docker来运行Ollama，健康检查的配置会变得非常优雅。下面是一个docker-compose.yml示例：

version: '3.8' services: ollama-chatglm: image: ollama/ollama:latest container_name: chatglm3-128k-server ports: - "11434:11434" volumes: - ollama_data:/root/.ollama # 部署后自动拉取模型 command: > sh -c "ollama pull chatglm3:6b-128k && ollama run chatglm3:6b-128k" healthcheck: test: ["CMD", "curl", "-f", "http://localhost:11434/api/tags"] interval: 30s timeout: 10s retries: 3 start_period: 60s deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] volumes: ollama_data:

在这个配置里，healthcheck部分就是关键。Docker引擎会每30秒执行一次curl -f http://localhost:11434/api/tags命令。如果连续失败3次，容器状态会被标记为unhealthy。start_period给了容器60秒的启动宽限期，避免因模型加载慢而导致启动失败。

使用docker-compose up -d启动后，可以通过docker ps查看容器的健康状态。

3.3 就绪检查：模型是否真的可用？

存活检查通过，只代表Ollama进程在，但模型可能还没加载完，或者GPU内存不足导致推理失败。我们需要更深入的“就绪检查”。

就绪检查可以尝试执行一个非常小的推理任务。创建一个readiness_check.py脚本：

import requests import json import sys def readiness_check(): url = "http://localhost:11434/api/generate" payload = { "model": "chatglm3:6b-128k", "prompt": "OK", # 极简的提示词，快速验证 "stream": False, "options": { "num_predict": 2 # 只生成2个token，速度极快 } } try: response = requests.post(url, json=payload, timeout=15) if response.status_code == 200: print("就绪检查通过：模型推理功能正常。") return True else: print(f"就绪检查失败：API返回状态码 {response.status_code}") return False except requests.exceptions.RequestException as e: print(f"就绪检查失败：请求异常 - {e}") return False if __name__ == "__main__": if readiness_check(): sys.exit(0) else: sys.exit(1)

这个脚本会请求模型生成两个token，能有效验证从API接入到模型推理的完整链路是否通畅。你可以将它集成到Kubernetes的readinessProbe中，或者由外部监控系统（如Prometheus）定期调用。

4. 构建自动扩缩容能力

当健康检查告诉我们服务负载过高时，手动去启动新实例太慢了。我们需要自动扩缩容。

4.1 基于自定义指标的扩缩容思路

自动扩缩容的核心是依据指标。对于大模型服务，关键指标包括：

请求速率：每秒/每分钟的请求数。
请求延迟：P95或P99响应时间。
GPU内存利用率：对于ChatGLM3-6B-128K这类模型，这是关键瓶颈。
队列长度：等待处理的请求数。

我们可以在Ollama的API前面部署一个反向代理（如Nginx），并在代理层收集请求速率和延迟指标。同时，使用nvidia-smi命令或cAdvisor等工具收集GPU指标。

4.2 使用Prometheus和Grafana监控

这是一个经典的监控组合。

部署Prometheus：抓取并存储指标。我们需要为Ollama和Nginx配置对应的Exporter（指标导出器）。
- 对于Nginx，可以使用nginx-prometheus-exporter。
- 对于Ollama，社区有开源的ollama-exporter，或者我们可以自己写一个简单的Exporter，调用Ollama的API来获取状态信息（虽然Ollama原生Prometheus支持还在完善中）。
部署Grafana：将Prometheus中的指标绘制成直观的仪表盘。
定义告警规则：在Prometheus中设置规则，例如“当平均请求延迟超过5秒持续2分钟时”触发告警。

4.3 实现基于Kubernetes的HPA

如果你在Kubernetes中运行Ollama（例如，将Ollama封装在Deployment中），那么实现自动扩缩容最直接的方式就是使用Horizontal Pod Autoscaler。

首先，你需要确保有指标源。可以安装Prometheus Adapter，它将Prometheus中的自定义指标（如我们的ollama_request_duration_seconds）转换成Kubernetes HPA能识别的格式。

然后，创建一个HPA资源清单hpa.yaml：

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: ollama-chatglm-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: ollama-deployment # 你的Ollama Deployment名称 minReplicas: 1 maxReplicas: 5 metrics: - type: Pods pods: metric: name: avg_request_latency_seconds target: type: AverageValue averageValue: 3 # 目标：平均延迟控制在3秒以内

这个HPA会根据名为avg_request_latency_seconds的指标（需要由Prometheus Adapter提供）来调整Pod副本数，目标是让平均延迟低于3秒。当延迟超标，Kubernetes会自动增加Pod实例来分摊压力。

重要提示：大模型服务扩容涉及GPU资源，你需要确保Kubernetes集群有足够的GPU节点，并正确配置了GPU资源调度（如使用NVIDIA Device Plugin）。

4.4 一个简化的脚本扩缩容示例

如果暂时没有使用Kubernetes，也可以用一个“土法炼钢”的脚本实现简单的扩缩容。这个脚本定期检查指标，并通过调用Docker API或系统命令来启动/停止Ollama容器实例。

# simple_scaler.py (概念示例，非生产完整代码) import requests import time import subprocess def get_current_latency(): # 这里模拟从监控系统获取最近1分钟的平均延迟 # 实际应调用Prometheus API try: # 示例：假设我们有一个端点返回延迟 resp = requests.get("http://monitor:9090/api/v1/query?query=avg_over_time(ollama_request_duration_seconds[1m])") data = resp.json() latency = float(data['data']['result'][0]['value'][1]) return latency except: return None def scale_out(): print("触发扩容：启动一个新的Ollama实例...") # 使用docker-compose scale或启动新的容器 subprocess.run(["docker", "run", "-d", "--gpus", "all", "--name", "ollama-instance-2", "ollama/ollama", "run", "chatglm3:6b-128k"]) def scale_in(instance_name): print(f"触发缩容：停止实例 {instance_name}...") subprocess.run(["docker", "stop", instance_name]) subprocess.run(["docker", "rm", instance_name]) def main(): scale_up_threshold = 5.0 # 延迟超过5秒扩容 scale_down_threshold = 1.0 # 延迟低于1秒缩容 check_interval = 60 # 每60秒检查一次 while True: latency = get_current_latency() if latency is None: print("无法获取指标，跳过本次检查。") time.sleep(check_interval) continue print(f"当前平均延迟: {latency:.2f}秒") # 这里需要维护一个实例列表，并实现更复杂的逻辑 # 例如：获取当前运行实例数，判断是否达到上限等 # 以下仅为最简化的逻辑演示 if latency > scale_up_threshold: scale_out() elif latency < scale_down_threshold: # 假设我们总能找到一个非主实例来缩容 scale_in("ollama-instance-2") time.sleep(check_interval) if __name__ == "__main__": main()

请注意：这个脚本示例非常简化，真实生产环境需要考虑实例发现、负载均衡、状态同步等复杂问题。使用Kubernetes等成熟平台是更可靠的选择。