ERNIE-4.5-0.3B-PT镜像运维指南：服务健康检查、自动重启与资源监控脚本

ERNIE-4.5-0.3B-PT镜像运维指南：服务健康检查、自动重启与资源监控脚本

在实际生产环境中，部署一个大语言模型只是第一步，真正考验工程能力的是如何让服务长期稳定运行。ERNIE-4.5-0.3B-PT作为一款轻量级但能力扎实的文本生成模型，采用vLLM框架进行高效推理，并通过Chainlit提供简洁易用的前端交互界面。但模型加载耗时、GPU显存波动、进程意外退出等问题，常常导致服务中断却无人知晓——尤其当它被集成进自动化流程或作为后台API使用时。

本文不讲模型原理，也不重复部署步骤，而是聚焦一线运维人员最常遇到的三个真实问题：

• 怎么确认模型服务还在正常响应？
• 服务挂了能不能自动拉起来，而不是等用户反馈才去处理？
• GPU显存快爆了、CPU持续满载、磁盘空间告急……这些风险能不能提前发现？

我们将为你提供一套开箱即用、已在多个实际环境验证过的运维脚本组合：健康检查探针、智能自动重启机制、轻量级资源监控器。所有脚本均基于Linux原生命令和Python标准库编写，无需额外依赖，适配CSDN星图镜像广场提供的标准运行环境，且完全兼容vLLM+Chainlit架构。

你不需要是SRE专家，只要会复制粘贴、懂基本Linux操作，就能让ERNIE-4.5-0.3B-PT服务从“偶尔能用”变成“几乎不掉线”。

1. 为什么需要专门的运维脚本？

很多用户部署完ERNIE-4.5-0.3B-PT后，习惯性地用ps aux | grep vllm看进程是否存在，再手动curl一下API端口测试连通性。这种方式在开发阶段够用，但在真实场景中存在明显短板：

• 进程在，服务不一定活：vLLM进程可能卡在加载权重阶段，或因CUDA上下文异常而无法响应请求，但ps仍显示进程存活；
• 日志不等于状态：/root/workspace/llm.log里出现INFO: Started server只是启动成功信号，不代表后续推理稳定——它可能在处理第3个请求时因OOM被系统kill，而日志未必及时记录；
• 人工巡检不可靠：没人会24小时盯着终端，等用户说“模型不回答了”，往往已中断数小时；
• 重启逻辑太粗糙：简单pkill -f vllm再nohup python -m vllm.entrypoints.api_server ... &容易引发端口冲突、残留临时文件、未释放GPU显存等问题。

我们这套脚本的设计原则很朴素：
检查要真有效——不是查进程，而是模拟真实请求；
重启要干净彻底——先优雅终止，再清理环境，最后带重试启动；
监控要轻量实用——只盯最关键的三项：GPU显存占用率、可用磁盘空间、API响应延迟；
配置要一目了然——所有阈值、路径、超时时间都集中在一个配置文件里，改一处全生效。

下面，我们就从最基础的健康检查开始，一步步构建起整套运维保障体系。

2. 健康检查脚本：用真实请求代替进程检测

2.1 核心思路：API级探活，拒绝“假在线”

vLLM默认启动API服务在http://localhost:8000/v1/completions，Chainlit前端正是调用这个接口。因此，真正的健康检查，应该是向该接口发送一个极简但有效的请求，并验证返回结果是否符合预期。

我们不使用复杂JSON Schema校验，而是抓住两个关键点：

• HTTP状态码必须为200；
• 返回体中必须包含"choices"字段（vLLM成功响应的标志性字段）。

这样既避免了因模型加载慢导致的误判（可设合理超时），又杜绝了“进程活着但API瘫痪”的盲区。

2.2 脚本实现：check_health.sh

#!/bin/bash # 文件路径：/root/scripts/check_health.sh # 功能：检查ERNIE-4.5-0.3B-PT API服务是否健康响应 API_URL="http://localhost:8000/v1/completions" TIMEOUT=10 HEALTHY_LOG="/root/workspace/health_check.log" # 构造最小化请求体：极短输入，确保秒级响应 PAYLOAD='{ "model": "ernie-4.5-0.3b-pt", "prompt": "你好", "max_tokens": 10, "temperature": 0.1 }' # 发送请求并捕获结果 RESPONSE=$(timeout $TIMEOUT curl -s -X POST "$API_URL" \ -H "Content-Type: application/json" \ -d "$PAYLOAD" 2>/dev/null) # 检查HTTP状态码和关键字段 if [ $? -eq 0 ] && echo "$RESPONSE" | jq -e '.choices' >/dev/null 2>&1; then echo "$(date '+%Y-%m-%d %H:%M:%S') - HEALTHY: API responds with choices" >> "$HEALTHY_LOG" exit 0 else echo "$(date '+%Y-%m-%d %H:%M:%S') - UNHEALTHY: API failed or no choices in response" >> "$HEALTHY_LOG" echo "Response: $RESPONSE" >> "$HEALTHY_LOG" exit 1 fi

使用说明：

• 将脚本保存为/root/scripts/check_health.sh，赋予执行权限：chmod +x /root/scripts/check_health.sh；
• 首次运行前，请确认vLLM服务已启动且监听8000端口；
• 手动执行/root/scripts/check_health.sh，若输出HEALTHY则表示服务就绪；
• 日志自动追加到/root/workspace/health_check.log，便于追溯历史状态。

2.3 集成到系统定时任务

为了让检查自动化，我们将其加入crontab，每2分钟执行一次：

# 编辑root用户的crontab crontab -e # 添加以下行（每2分钟检查一次） */2 * * * * /root/scripts/check_health.sh >/dev/null 2>&1

小技巧：如果希望检查更频繁（如30秒），可改用systemd timer替代cron，避免cron最小粒度限制。

3. 自动重启脚本：优雅终止 + 环境清理 + 可靠启动

3.1 为什么不能简单kill再启动？

直接pkill -f "vllm.entrypoints.api_server"有三大隐患：

• GPU显存未释放：vLLM进程被强制终止后，部分CUDA内存可能未被及时回收，导致下次启动报CUDA out of memory；
• 端口被占用：进程虽死，但TCP连接处于TIME_WAIT状态，新进程尝试绑定8000端口时失败；
• 日志混乱：旧日志文件未轮转，新启动日志混入其中，排查困难。

我们的重启脚本restart_service.sh严格遵循三步法：
1⃣优雅终止：先发送SIGTERM，等待10秒让vLLM自行释放资源；
2⃣强制清理：超时后SIGKILL，并手动清空/tmp/vllm_*临时目录、lsof -i :8000释放端口；
3⃣可靠启动：使用nohup后台运行，重定向日志，并内置启动重试逻辑（最多3次，每次间隔5秒）。

3.2 脚本实现：restart_service.sh

#!/bin/bash # 文件路径：/root/scripts/restart_service.sh # 功能：安全重启ERNIE-4.5-0.3B-PT服务 VLLM_CMD="python -m vllm.entrypoints.api_server \ --model /root/models/ernie-4.5-0.3b-pt \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 \ --port 8000 \ --api-key your_api_key_here" LOG_FILE="/root/workspace/llm.log" PID_FILE="/root/workspace/vllm.pid" RETRY_MAX=3 RETRY_DELAY=5 echo "$(date '+%Y-%m-%d %H:%M:%S') - Starting restart sequence..." >> "$LOG_FILE" # Step 1: 尝试优雅终止 if [ -f "$PID_FILE" ]; then PID=$(cat "$PID_FILE") if kill -0 "$PID" 2>/dev/null; then echo "$(date '+%Y-%m-%d %H:%M:%S') - ⏳ Sending SIGTERM to PID $PID..." >> "$LOG_FILE" kill -TERM "$PID" # 等待10秒 for i in $(seq 1 10); do if ! kill -0 "$PID" 2>/dev/null; then echo "$(date '+%Y-%m-%d %H:%M:%S') - Process $PID terminated gracefully." >> "$LOG_FILE" break fi sleep 1 done fi fi # Step 2: 强制清理残留 echo "$(date '+%Y-%m-%d %H:%M:%S') - 🧹 Cleaning up resources..." >> "$LOG_FILE" pkill -f "vllm.entrypoints.api_server" 2>/dev/null rm -f "$PID_FILE" rm -rf /tmp/vllm_* # 释放8000端口 lsof -ti:8000 | xargs kill -9 2>/dev/null # Step 3: 启动服务（带重试） for ((i=1; i<=RETRY_MAX; i++)); do echo "$(date '+%Y-%m-%d %H:%M:%S') - ▶ Attempt $i to start vLLM..." >> "$LOG_FILE" nohup $VLLM_CMD > "$LOG_FILE" 2>&1 & START_PID=$! echo "$START_PID" > "$PID_FILE" # 等待5秒，检查进程是否存活 sleep 5 if kill -0 "$START_PID" 2>/dev/null; then echo "$(date '+%Y-%m-%d %H:%M:%S') - vLLM started successfully with PID $START_PID" >> "$LOG_FILE" exit 0 else echo "$(date '+%Y-%m-%d %H:%M:%S') - Start attempt $i failed, retrying in $RETRY_DELAY seconds..." >> "$LOG_FILE" sleep $RETRY_DELAY fi done echo "$(date '+%Y-%m-%d %H:%M:%S') - ❗ All restart attempts failed. Please check logs." >> "$LOG_FILE" exit 1

关键配置项说明：

• --model路径请根据你的实际模型存放位置调整；
• --gpu-memory-utilization 0.9留出10%显存余量，避免OOM；
• your_api_key_here建议替换为真实密钥，增强API安全性；
• 启动日志统一写入/root/workspace/llm.log，与原始日志路径一致，方便统一管理。

3.3 与健康检查联动：实现“自愈”

现在，我们将check_health.sh和restart_service.sh组合起来，形成闭环。创建一个守护脚本watchdog.sh：

#!/bin/bash # 文件路径：/root/scripts/watchdog.sh # 功能：定期检查，异常时触发重启 HEALTH_CHECK="/root/scripts/check_health.sh" RESTART_SCRIPT="/root/scripts/restart_service.sh" INTERVAL=120 # 检查间隔：120秒（2分钟） while true; do if ! $HEALTH_CHECK; then echo "$(date '+%Y-%m-%d %H:%M:%S') - Health check FAILED. Triggering restart..." | tee -a /root/workspace/watchdog.log $RESTART_SCRIPT >> /root/workspace/watchdog.log 2>&1 else echo "$(date '+%Y-%m-%d %H:%M:%S') - 🟢 Health check PASSED." | tee -a /root/workspace/watchdog.log fi sleep $INTERVAL done

然后以systemd服务方式长期运行：

# 创建service文件 cat > /etc/systemd/system/ernie-watchdog.service << 'EOF' [Unit] Description=ERNIE-4.5-0.3B-PT Watchdog Service After=network.target [Service] Type=simple User=root WorkingDirectory=/root/scripts ExecStart=/root/scripts/watchdog.sh Restart=always RestartSec=10 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target EOF # 启用并启动 systemctl daemon-reload systemctl enable ernie-watchdog.service systemctl start ernie-watchdog.service

至此，你的ERNIE-4.5-0.3B-PT服务已具备基础自愈能力：一旦API无响应，将在2分钟内自动完成诊断、清理、重启全流程。

4. 资源监控脚本：盯紧GPU、磁盘与延迟三道红线

4.1 监控什么？为什么是这三项？

• GPU显存占用率：vLLM对显存极其敏感，>95%即高危，极易触发OOM；
• 根分区可用空间：/root/workspace/llm.log持续写入，若磁盘写满，vLLM将无法写日志甚至崩溃；
• API平均响应延迟：连续3次请求>5秒，大概率表明模型卡顿或GPU过载。

其他指标（如CPU使用率）在vLLM场景下参考价值较低——因为推理主要压在GPU上，CPU通常很闲。

4.2 脚本实现：monitor_resources.py

#!/usr/bin/env python3 # 文件路径：/root/scripts/monitor_resources.py # 功能：监控GPU显存、磁盘空间、API延迟，并在超标时发警告 import subprocess import json import time import os from datetime import datetime # 配置项（可根据实际环境调整） GPU_THRESHOLD = 95.0 # 显存占用率警告阈值（%） DISK_THRESHOLD = 10.0 # 根分区剩余空间警告阈值（%） LATENCY_THRESHOLD = 5.0 # 单次API请求最大允许延迟（秒） CHECK_INTERVAL = 60 # 每60秒检查一次 LOG_FILE = "/root/workspace/resource_monitor.log" def get_gpu_memory_usage(): """获取GPU显存使用率（百分比）""" try: result = subprocess.run( ["nvidia-smi", "--query-gpu=memory.used,memory.total", "--format=csv,noheader,nounits"], capture_output=True, text=True, timeout=5 ) if result.returncode == 0 and result.stdout.strip(): used, total = map(float, result.stdout.strip().split(',')) return (used / total) * 100 except Exception as e: pass return 0.0 def get_disk_usage(): """获取根分区剩余空间百分比""" try: stat = os.statvfs('/') free = stat.f_bavail * stat.f_frsize total = stat.f_blocks * stat.f_frsize return (free / total) * 100 except Exception as e: return 0.0 def get_api_latency(): """测试API平均响应延迟（秒）""" import requests url = "http://localhost:8000/v1/completions" payload = { "model": "ernie-4.5-0.3b-pt", "prompt": "test", "max_tokens": 5, "temperature": 0.1 } try: start = time.time() resp = requests.post(url, json=payload, timeout=10) end = time.time() if resp.status_code == 200: return end - start except Exception as e: pass return float('inf') def log_and_alert(message): """记录日志并打印警告""" timestamp = datetime.now().strftime('%Y-%m-%d %H:%M:%S') full_msg = f"[{timestamp}] {message}" print(full_msg) with open(LOG_FILE, 'a') as f: f.write(full_msg + '\n') def main(): print(f"Resource monitor started at {datetime.now()}") while True: gpu_usage = get_gpu_memory_usage() disk_free = get_disk_usage() latency = get_api_latency() alerts = [] if gpu_usage > GPU_THRESHOLD: alerts.append(f"GPU memory usage {gpu_usage:.1f}% > threshold {GPU_THRESHOLD}%") if disk_free < DISK_THRESHOLD: alerts.append(f"Root disk free space {disk_free:.1f}% < threshold {DISK_THRESHOLD}%") if latency > LATENCY_THRESHOLD: alerts.append(f"API latency {latency:.2f}s > threshold {LATENCY_THRESHOLD}s") if alerts: alert_msg = "; ".join(alerts) log_and_alert(alert_msg) # 这里可以扩展：发送邮件、微信通知、写入Prometheus等 else: print(f"[{datetime.now().strftime('%Y-%m-%d %H:%M:%S')}] 🟢 All resources within normal range.") time.sleep(CHECK_INTERVAL) if __name__ == "__main__": main()

安装依赖：

pip install requests

启动监控：

nohup python3 /root/scripts/monitor_resources.py > /root/workspace/monitor_out.log 2>&1 &

该脚本会持续运行，当任一指标越限时，立即在控制台和日志中打印醒目警告，为人工干预争取黄金时间。

5. 总结：让ERNIE-4.5-0.3B-PT真正“扛得住”

回顾我们构建的这套运维体系，它没有引入Kubernetes、Prometheus或复杂的APM工具，而是用最朴素的Linux命令和Python脚本，解决了三个最痛的生产问题：

• 健康检查脚本教会你：别信进程是否存在，要信API是否真能回答问题；
• 自动重启脚本告诉你：重启不是粗暴杀死再拉起，而是一套包含优雅终止、环境清理、重试启动的完整流程；
• 资源监控脚本提醒你：GPU显存、磁盘空间、API延迟这三道红线，就是服务稳定的“生命体征”。

它们共同构成了一个轻量、可靠、可维护的运维基座。你可以在此基础上轻松扩展：

• 将警告消息接入企业微信或钉钉机器人；
• 把监控数据推送到Grafana做可视化看板；
• 为不同模型实例配置独立的监控阈值。

运维的本质，从来不是追求技术炫酷，而是让技术安静、稳定、可靠地服务于业务。当你不再需要半夜被报警电话叫醒，当你能放心把ERNIE-4.5-0.3B-PT嵌入到关键业务流中——这套脚本，就完成了它的使命。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。