如果说之前的部署是“把房子盖起来”，那么AI 智算运维（AIOps for MLOps）就是“让这座大楼自动驾驶、自我修复、并且能效比最优”。
针对私有化部署的 AI 智能体/大模型集群，运维的进阶核心在于：从“救火”转向“预测”，从“人工调参”转向“系统自治”，从“只看 CPU/内存”转向“全栈 GPU 可观测性”。
以下是为你整理的 AI 智算运维进阶实战手册，分为五个层级：
第一层：GPU 可观测性 —— 透视“黑盒”
核心痛点：GPU 到底在忙什么？为什么慢？
1. 超越 nvidia-smi：DCGM 精细化监控
nvidia-smi只能看瞬时值，生产环境必须部署 NVIDIA DCGM (Data Center GPU Manager) + DCGM Exporter。
你需要重点盯住这 4 个“黄金指标”：
|
指标 |
含义 |
运维决策 |
|---|---|---|
|
GPU Utilization |
计算单元活跃度 |
长期 <40%：说明是 IO 密集型或调度问题，需优化数据加载；>95%：满负荷，需扩容。 |
|
Memory Utilization |
显存带宽使用率 |
高带宽意味着频繁的数据搬运（如 KV Cache 换入换出），可能需要更大的显存或优化模型。 |
|
SM Clock / Memory Clock |
频率 |
如果突然掉频，检查散热（Thermal Throttle）或电源功率限制（Power Capping）。 |
|
PCIe Rx/Tx Bytes |
数据传输量 |
判断是否存在“卡等数据”的情况，指导是否需要升级 NVLink 或优化网络。 |
2. 推理服务内部指标（vLLM/TGI）
不要只看系统层面，要看框架层面：
-
KV Cache Usage：这是大模型推理的命门。如果命中率低，说明上下文复用少，或者缓存被频繁踢出（显存不够）。
-
Request Queue Time：请求在队列里等了多久？如果很长，说明并发数超过了处理能力，需要限流或扩容。
-
Generation Throughput (tokens/sec)：吞吐量是否随着 Batch Size 增加而线性增长？如果不增长，说明存在串行瓶颈。
第二层：调度与弹性伸缩 —— 榨干每一滴算力
核心痛点：白天忙死，晚上闲死；大卡跑小任务浪费。
1. 分时复用与优先级抢占
在生产环境中，通常有两种流量：
-
在线服务（Online Serving）：用户对话，要求低延迟，高优先级。
-
离线任务（Offline Batch）：知识库更新、模型微调、数据清洗，允许慢一点，低优先级。
进阶策略：
-
使用 K8s + Volcano / YARN 调度器。
-
配置 Gang Scheduling（组调度），防止大模型分布式训练卡在“缺一块卡”的状态。
-
设置 Preemption（抢占）：凌晨 2 点允许离线任务占满所有 GPU；早上 9 点在线流量进来时，强制驱逐离线任务释放资源。
2. 显存超售（GPU Overcommit）
这是一个高阶技巧。
-
很多 Agent 应用在“思考”（Tool Calling）时，GPU 是空闲的，但显存被占着。
-
使用 MPS (Multi-Process Service) 或 MIG (Multi-Instance GPU) 技术，将一张大卡切成多个小实例，分别跑不同的 Agent 容器，提高整体利用率。
第三层：故障自愈与混沌工程
核心痛点：半夜三点模型崩了，运维爬起来重启。
1. 构建“GPU 医生”脚本（Watchdog Pro）
之前的脚本只是重启，进阶版需要诊断：
# 伪代码逻辑
if GPU_Util == 0 and GPU_Mem > 80%:
# 显存泄漏特征
log "Suspected VRAM Leak"
dump_stack_trace() # 导出堆栈
restart_container()
elif NVLink_Error_Count > 0:
# 硬件链路错误
alert_admin("Hardware Failure")
drain_node() # 将节点标记为不可调度，等待人工介入
elif Temperature > 95:
# 过热
throttle_gpu_clock()
send_critical_alert()
2. 主动故障注入（Chaos Mesh）
不要等故障来了才处理，要主动制造故障：
-
模拟 GPU 掉卡：随机 kill 掉一个推理 Pod，验证 LB 是否能无缝切换。
-
模拟网络延迟：在 Agent 调用 RAG 时增加 500ms 延迟，验证超时重试机制是否生效。
-
模拟显存碎片：注入大量不规则大小的内存分配请求，验证 vLLM 的 Block Manager 是否健壮。
第四层：成本治理与能效优化
核心痛点：老板问“这几十张卡到底产生了多少价值？”
1. 建立 GPU 成本分摊模型 (Showback)
不要只算电费，要算 Token 成本。
-
在 API 网关层记录：
User A调用了多少次，Input Tokens多少，Output Tokens多少。 -
结合 GPU 折旧、电费、运维人力，算出 每千 Token 的成本。
-
输出报表给业务部门，倒逼业务优化 Prompt（例如：减少不必要的长上下文）。
2. 动态功耗管理 (Green Computing)
-
DVFS (Dynamic Voltage and Frequency Scaling)：在深夜低峰期，通过
nvidia-smi -pl降低 GPU 的功耗上限（例如从 400W 降到 250W），牺牲一点点性能换取大幅电费节省。 -
Spot Instance（竞价实例）：如果是混合云架构，将非核心的 Embedding 计算、模型评测任务放到云上的竞价实例上跑。
第五层：自动化流水线 (LLMOps)
核心痛点：模型更新一次，手动折腾半天，还容易出错。
1. 模型 CI/CD 流水线
-
Model Registry：统一管理模型版本（MLflow、Dify 内置）。
-
金丝雀发布 (Canary Release)：新模型上线时，只给 5% 的流量，观察 TTFT 和错误率，没问题再全量。
-
自动回滚：如果新模型导致 GPU 显存溢出率超过阈值，自动切回上一个版本。
2. 数据集与 RAG 生命周期管理
-
Embedding 版本锁定：知识库更新时，必须保证 Embedding 模型和向量库的版本一致，否则会出现“搜得到但读不懂”的诡异 Bug。
-
索引预热：新索引上线后，预先加载热点数据到内存缓存（Redis/Memcached）。
进阶运维 Checklist（可直接发给团队执行）
|
维度 |
检查项 |
工具/命令 |
|---|---|---|
|
监控 |
是否采集 GPU SM 利用率和显存带宽？ |
DCGM Exporter |
|
调度 |
是否区分在线/离线任务优先级？ |
K8s PriorityClass |
|
故障 |
是否有显存泄漏自动重启机制？ |
Watchdog Script |
|
成本 |
是否统计各部门 Token 消耗量？ |
Prometheus + Grafana |
|
安全 |
容器是否以非 Root 运行？ |
Docker Security Scan |
|
效能 |
是否开启 KV Cache 复用？ |
vLLM |
总结一句话：
初级运维管“死活”，中级运维管“快慢”，高级智算运维管“性价比”和“SLA 自治”。