3、基础设施监控：GPU/CPU资源监控、内存与显存监控、网络延迟与带宽监控、磁盘I/O监控
聊完了模型安全和数据安全，咱们得把目光往下移一移。
落到最底层的基础设施上。
你想想看，AI系统跑在什么上面？不就是CPU、GPU、内存、网络和磁盘这些硬件吗？
这些家伙要是出了岔子，上层再安全的模型也是白搭。我见过太多团队，模型算法写得天花乱坠，结果一上线，GPU温度直接飙到90度，训练任务全挂了。
嗯，今天我们就来聊聊，怎么把这些基础设施盯紧了。
GPU/CPU资源监控
先说GPU。搞AI的，GPU就是命根子。
我个人习惯，监控GPU主要看三个指标：利用率、温度和显存带宽。
利用率不是越高越好。我曾经踩过一个坑：有次模型训练特别慢，一看GPU利用率100%，我还挺高兴，觉得资源用满了。后来仔细一查，发现是数据加载太慢，GPU一直在空转等待数据，利用率虚高。说白了，它是在「假装忙碌」。
所以，我建议你同时监控GPU计算利用率和内存拷贝利用率。如果计算利用率低，但内存拷贝利用率高，那八成是I/O瓶颈。
核心监控指标：
- GPU计算利用率（nvmlComputeRunningTime）
- GPU内存利用率（nvmlMemoryUsed）
- GPU温度（通常不超过85°C）
- GPU显存带宽利用率
- CPU整体使用率（user + system）
- CPU每核使用率（避免单核打满）
- CPU上下文切换次数（过高说明锁竞争严重）
CPU监控相对简单，但有个细节容易被忽略——CPU亲和性。我遇到过一个问题：多进程推理时，操作系统把进程在不同CPU核心间来回调度，导致缓存频繁失效，性能下降30%。后来我强制绑定了CPU核心，问题就解决了。
实用命令：
# GPU监控
nvidia-smi --query-gpu=index,timestamp,utilization.gpu,memory.used,temperature.gpu --format=csv -l 5
# CPU监控
mpstat -P ALL 5
top -b -n 1 | grep "Cpu(s)"内存与显存监控
内存泄漏，是AI系统的隐形杀手。
我记得有一次，一个推理服务跑了三天后突然OOM了。查了半天，发现是Python的某个库在每次推理时都会申请一块显存，但释放不及时。日积月累，显存就爆了。
所以，我建议你监控内存/显存的增长趋势，而不是只看当前值。如果发现内存使用量随时间线性增长，那基本可以断定有泄漏。
| 监控项 | 告警阈值 | 说明 |
|---|---|---|
| 系统内存使用率 | > 90% | 触发OOM killer风险高 |
| Swap使用率 | > 10% | 说明物理内存不足，性能会急剧下降 |
| GPU显存使用率 | > 95% | 容易导致CUDA Out of Memory |
| 显存碎片率 | > 30% | 即使显存总量够，也可能分配失败 |
这里有个小技巧：监控显存碎片率。你想想看，显存就像一块大蛋糕，切来切去就碎成小块了。即使总剩余空间很大，但连续的大块空间可能已经没了。这时候申请大显存就会失败。
避坑指南：
我曾经在监控系统里只设置了「显存使用率>95%」告警，结果有次显存使用率才80%，服务就报OOM了。后来才发现是显存碎片化严重。所以，一定要加上碎片率监控。
网络延迟与带宽监控
分布式训练和推理，网络就是血管。
网络延迟高了，梯度同步就慢，训练效率直线下降。带宽不够，数据传输就卡脖子。
我个人习惯，监控网络主要看P99延迟和吞吐量。平均延迟有时候会骗人，但P99不会。如果P99延迟突然飙升，说明网络出现了抖动或拥塞。
关键监控点：
- 节点间通信延迟（ping RTT）
- 网卡带宽使用率（进/出方向）
- TCP重传率（>1%就要警惕）
- 连接数（避免端口耗尽）
- 丢包率（>0.1%会影响训练收敛）
嗯，这里要特别提一下TCP重传率。我遇到过一个问题：分布式训练时，某个节点的loss死活不下降。查了三天，发现是那个节点的网卡有问题，TCP包一直在重传，导致梯度更新滞后。换了网卡就好了。
监控命令：
# 网络延迟
ping -c 10 目标IP | tail -1 | awk '{print $4}' | cut -d '/' -f 2
# 带宽和重传
sar -n DEV 5
netstat -s | grep "retransmitted"磁盘I/O监控
磁盘I/O，往往是AI系统中最容易被低估的瓶颈。
你想想看，数据加载、模型保存、日志写入，哪个离得开磁盘？
我见过一个案例：团队花大价钱买了A100 GPU，结果训练速度还不如V100。一查，发现他们把训练数据放在机械硬盘上，I/O延迟高达100ms，GPU一直在等数据。换了NVMe SSD后，训练速度直接翻倍。
| 监控指标 | 正常范围 | 告警阈值 |
|---|---|---|
| 磁盘读写延迟 | < 10ms | > 50ms |
| 磁盘IOPS | 取决于磁盘类型 | 接近磁盘上限 |
| 磁盘使用率 | < 80% | > 90% |
| inode使用率 | < 80% | > 90% |
这里有个容易被忽略的点——inode使用率。磁盘空间还有，但inode用完了，你就没法创建新文件了。我遇到过训练过程中突然报错「No space left on device」，查了半天发现是inode满了，全是小文件占的。
避坑指南：
我曾经在日志系统里没做日志轮转，结果一个训练任务跑了三天，生成了上百万个小日志文件，直接把inode耗尽了。从那以后，我所有日志系统都强制配置了日志轮转和压缩。
最后，总结一下我的监控哲学：不要等出了问题再查，要在问题发生前就预警。
把GPU温度、内存增长趋势、网络重传率这些指标都配上趋势告警，一旦偏离基线就自动通知。这样，你就能在系统崩溃前，从容地处理问题。
嗯，基础设施监控就聊到这儿。下一章，我们聊聊更上层的应用监控。