你是不是也遇到过这种情况？模型跑得好好的，突然有一天服务就停了，一看日志，C盘空间满了。或者，明明GPU看着还有余量，但推理速度越来越慢，最后直接报错“内存不足”。

FireRedASR-AED-L这类语音识别模型，一旦部署上线长期运行，就像一台需要定期保养的汽车。它会在后台默默产生日志、缓存文件，持续占用着GPU显存和系统内存。如果不加管理，这些“垃圾”会逐渐堆积，最终拖垮整个服务。

今天这篇教程，我就来手把手教你，如何给长期运行的FireRedASR-AED-L模型做一次彻底的“大扫除”和“健康检查”。我们会从最实际的C盘空间清理开始，讲到日志怎么管理，再到如何用简单工具实时监控GPU和内存，最后设置预警，让你在问题发生前就能收到警报。目标很简单：让你的模型服务跑得又稳又快，告别半夜被报警电话吵醒的日子。

模型长期运行，会产生好几类你看不见但占地方的“垃圾”。我们先来当一回“侦探”，找到它们藏在哪里。

1.1 找到那些占地方的“元凶”

首先，我们得知道去哪里找。对于部署在星图GPU平台或类似环境下的FireRedASR-AED-L服务，重点关注以下几个目录：

• 日志文件目录：这是最典型的“空间杀手”。模型框架（如TensorFlow、PyTorch）自身的日志、你应用程序的日志，如果没有设置轮转或清理，很快就会积累成几个GB甚至更大的文件。它们通常位于你的项目根目录下的 logs 文件夹，或者系统指定的日志路径（如 /var/log/ 下的相关目录）。
• 模型缓存与临时文件：推理过程中，模型可能会下载或生成一些缓存文件，用于加速后续加载。此外，一些预处理、后处理的中间结果也会以临时文件形式存在。这些文件有时不会自动删除。
• 检查点文件：如果你在服务运行期间进行了模型的微调或继续训练，那么生成的检查点文件（checkpoints）会占用大量空间。虽然对纯推理服务不常见，但也要留意。
• Docker/容器相关：如果使用容器化部署，要注意容器内产生的日志和缓存，以及宿主机上Docker的镜像、容器层缓存，这些都可能占用C盘空间。

怎么快速定位是哪个文件夹最占空间呢？这里给你一个在Linux服务器上超级好用的命令：

# 进入你怀疑的目录，比如项目根目录或日志目录
cd /path/to/your/project_or_log_dir

# 使用du命令，按大小排序，显示当前目录下各子目录的大小
du -sh * | sort -rh | head -20

这个命令会列出当前目录下最大的20个文件夹和文件，一眼就能看出谁是“罪魁祸首”。

1.2 动手清理：安全又有效的方法

找到目标后，清理要讲究方法，别把重要的配置文件或模型本体给删了。

1. 清理旧日志文件： 不要直接用 rm -rf logs/*，这可能会误删正在写入的日志。更安全的做法是使用日志轮转工具（如logrotate），或者按时间删除。例如，删除7天前的所有 .log 文件：

find /path/to/logs -name "*.log" -type f -mtime +7 -delete

2. 清理模型缓存： 缓存目录通常有明确的命名，如 cache、.cache、transformers（对于Hugging Face模型库）。在清理前，最好先停止服务，然后删除整个缓存目录。模型下次启动时会自动重建必要的缓存。

# 示例：清理Hugging Face的模型缓存（通常位于 ~/.cache/huggingface）
# 请确保服务已停止
rm -rf ~/.cache/huggingface/hub

3. 编写一个一键清理脚本： 把上述清理动作整合到一个脚本里，方便定期执行（比如通过cron定时任务）。下面是一个简单的示例脚本 cleanup.sh：

#!/bin/bash

echo "开始清理FireRedASR-AED-L服务相关文件..."

# 1. 清理7天前的应用日志
LOG_DIR="/opt/firered_asr/logs"
if [ -d "$LOG_DIR" ]; then
    find "$LOG_DIR" -name "*.log" -type f -mtime +7 -delete
    echo "已清理旧日志。"
fi

# 2. 清理临时文件目录（假设是/tmp下的特定前缀文件）
find /tmp -name "firered_asr_*" -type f -mtime +1 -delete 2>/dev/null
echo "已清理临时文件。"

# 3. 可选：清理Docker无用资源（如果使用Docker）
# docker system prune -f --filter "until=24h"
# echo "已清理Docker旧资源。"

echo "清理完成！"

记得给脚本执行权限：chmod +x cleanup.sh。然后你可以设置一个每周自动运行的计划任务。

与其等日志文件大了再清理，不如从一开始就管好它。日志轮转（Log Rotation）就是这个“紧箍咒”，它能自动把大的日志文件分割、压缩、归档，并删除太旧的。

2.1 使用 logrotate 配置自动管理

大多数Linux系统都自带 logrotate 工具。我们为FireRedASR-AED-L的日志创建一个配置文件，比如 /etc/logrotate.d/firered-asr。

# /etc/logrotate.d/firered-asr
/opt/firered_asr/logs/*.log 

配置好后，logrotate 通常由系统定时任务（如cron.daily）自动执行。你也可以手动测试配置：logrotate -d /etc/logrotate.d/firered-asr（-d 是调试模式，不实际执行）。

2.2 在应用代码中实现轮转

如果你的应用使用Python的 logging 模块，也可以直接集成轮转功能：

import logging
from logging.handlers import RotatingFileHandler

# 创建RotatingFileHandler，单个文件最大100MB，最多保留5个备份文件
handler = RotatingFileHandler(
    '/opt/firered_asr/logs/app.log',
    maxBytes=100*1024*1024,  # 100 MB
    backupCount=5
)
handler.setFormatter(logging.Formatter('%(asctime)s - %(levelname)s - %(message)s'))

logger = logging.getLogger('FireRedASR')
logger.setLevel(logging.INFO)
logger.addHandler(handler)

# 使用logger记录日志
logger.info("模型服务启动成功。")

这样，当 app.log 文件超过100MB时，它会自动被重命名为 app.log.1，并创建一个新的 app.log，最多保留 app.log.1 到 app.log.5 五个备份文件。

清理是“治已病”，监控则是“防未病”。我们需要一套简单的方法，实时了解模型的资源消耗。

3.1 命令行工具：快速巡检

• GPU监控：nvidia-smi 是你的第一选择。运行 nvidia-smi -l 5 可以每5秒刷新一次信息，重点关注 GPU-Util（利用率）和 Memory-Usage（显存使用）。
• 系统内存监控：free -h 命令可以快速查看系统内存和交换空间的使用情况。top 或 htop 命令则能更详细地查看每个进程的内存占用（RES列）。

3.2 使用轻量级监控工具：Prometheus + Grafana（可选但推荐）

对于需要长期、可视化监控的场景，可以搭建一套简单的Prometheus和Grafana。

1. Node Exporter：部署在服务器上，收集系统指标（CPU、内存、磁盘、网络）。
2. NVIDIA GPU Exporter：专门收集GPU指标。
3. Prometheus：定时抓取上述Exporter的数据并存储。
4. Grafana：连接Prometheus，绘制漂亮的监控图表。

部署这些组件在星图GPU平台或有Docker的环境下非常方便。你可以设置仪表盘，实时显示：

• C盘可用空间趋势图
• GPU显存使用率和温度
• 系统内存使用量
• 模型推理请求的QPS（每秒查询率）和延迟

当这些指标出现异常波动时，你就能第一时间发现。

3.3 在代码中嵌入资源检查

你还可以在模型服务的健康检查接口或定时任务中，加入资源检查逻辑：

import psutil
import subprocess
import json

def check_system_resources():
    """检查系统资源状态"""
    status = {
        "disk_free_gb": round(psutil.disk_usage('/').free / (1024**3), 2),
        "memory_percent": psutil.virtual_memory().percent,
        "cpu_percent": psutil.cpu_percent(interval=1)
    }

    # 检查GPU（如果可用）
    try:
        result = subprocess.run(['nvidia-smi', '--query-gpu=utilization.gpu,memory.used,memory.total', '--format=csv,noheader,nounits'],
                                capture_output=True, text=True, check=True)
        gpu_info = result.stdout.strip().split(', ')
        status["gpu_util_percent"] = float(gpu_info[0])
        status["gpu_mem_used_gb"] = round(float(gpu_info[1]) / 1024, 2)
        status["gpu_mem_total_gb"] = round(float(gpu_info[2]) / 1024, 2)
    except Exception as e:
        status["gpu_error"] = str(e)

    return status

# 可以在一个API端点返回这个状态，或者打印到日志
resources = check_system_resources()
print(json.dumps(resources, indent=2))

监控看到了问题，但如果人不在电脑前怎么办？设置警报，让系统主动通知你。

4.1 基于脚本的简单磁盘告警

我们可以改进之前的清理脚本，加入检查逻辑，当磁盘空间低于某个阈值时发送告警（例如发送邮件或调用企业微信/钉钉机器人）。

#!/bin/bash
# disk_alert.sh

THRESHOLD=10 # 磁盘使用率阈值，单位是百分比
CURRENT_USE=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')

if [ "$CURRENT_USE" -gt "$THRESHOLD" ]; then
    MESSAGE="警告：服务器根目录磁盘使用率已达 ${CURRENT_USE}%，超过阈值 ${THRESHOLD}%。请立即清理！"
    echo "$MESSAGE"
    # 在这里添加你的告警发送逻辑，例如：
    # 1. 发送邮件
    # echo "$MESSAGE" | mail -s "磁盘空间告警" admin@example.com
    # 2. 使用curl调用Webhook（需替换URL和消息格式）
    # curl -X POST -H "Content-Type: application/json" -d "{"msgtype":"text","text":{"content":"$MESSAGE"}}" YOUR_WEBHOOK_URL
fi

然后将这个脚本也加入cron定时任务，每小时运行一次。

4.2 利用监控系统的告警功能

如果你使用了Prometheus，那么它的告警管理器（Alertmanager）功能更强大。你可以配置类似这样的告警规则：

# prometheus_alerts.yml
groups:
- name: firered_asr_alerts
  rules:
  - alert: DiskSpaceLow
    expr: (node_filesystem_free_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100) < 10
    for: 5m # 持续5分钟低于阈值才触发
    labels:
      severity: warning
    annotations:
      summary: "实例 {{ $labels.instance }} 根目录磁盘空间不足10%"
      description: "{{ $labels.instance }} 的根目录磁盘可用空间仅剩 {{ $value }}%。"

  - alert: GPUMemoryHigh
    expr: (nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes * 100) > 90
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "GPU显存使用率过高"
      description: "GPU {{ $labels.gpu }} 显存使用率已达 {{ $value }}%。"

配置好后，当触发告警时，Alertmanager可以通过邮件、Slack、钉钉等多种渠道通知你。

给FireRedASR-AED-L这类模型做长期维护，其实就是一个养成好习惯的过程。定期清理C盘的日志和缓存，给日志文件套上自动轮转的“枷锁”，再用监控工具像看仪表盘一样随时掌握GPU和内存的“健康状况”，最后设置好警报当好“先知”。

这一套组合拳打下来，你的模型服务稳定性会大大提升。从我自己的经验来看，花一点时间设置好这些自动化策略，远比事后半夜爬起来处理故障要划算得多。尤其是磁盘空间告警，真的能避免很多低级但致命的问题。

如果你刚开始部署，建议先把清理脚本和基础命令行监控用起来，这是最快见效的。等业务稳定了，再考虑搭建更完善的Prometheus+Grafana监控体系。记住，稳定的服务才是业务发展的基石。

---

获取更多AI镜像

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