/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
导读：算力中心运维工程师岗位普遍要求"3年以上Linux系统运维经验 + GPU服务器/算力平台/大模型推理服务运维能力"。本文从传统Linux运维视角出发，梳理向AI算力集群运维迁移时必须补齐的四类技能栈：驱动与算力环境、推理服务部署、分布式集群编排、算力可观测性。
一、GPU/NPU驱动与算力环境管理：版本矩阵是第一道坎
传统Linux运维装Nginx，yum install 一条命令搞定；GPU环境下，装一次NVIDIA驱动要同时核对CUDA版本、cuDNN版本、PyTorch版本与内核版本，四者必须严丝合缝。版本错位最常见的症状是：驱动装好了，但训练任务启动即报错，日志指向不兼容的CUDA runtime。
实操建议：先用 nvidia-smi 确认驱动与CUDA能力，再用 nvcc –version 核对runtime CUDA，PyTorch侧用 torch.version.cuda 交叉验证；昇腾NPU场景对应 npu-smi 与 CANN 工具链，原理一致。把版本组合固化成环境清单（requirements + Dockerfile），是降低排查成本的关键动作。
二、显存与推理调优：OOM不再靠"加内存"解决
传统运维内存不够就扩容，GPU显存是有限的，OOM（Out of Memory）处理思路完全不同：调小batch size、降精度（FP16/BF16）、量化（INT8、GPTQ、AWQ）、开启梯度检查点，都是常用手段。推理侧则要处理KV cache与显存上限的关系——vLLM 里通过 –gpu-memory-utilization、–max-model-len 控制显存水位，动态批次（continuous batching）直接决定吞吐与排队时延。
核心思路是把"显存"当资源池来做容量规划：压测脚本（如使用 OpenAI 兼容 API 的 load 工具）分别打不同并发，记录 TTFT/TBT 与显存峰值，反推合理 batch 与实例数，这是推理服务稳定性的基本功。
三、分布式训练与推理集群：网络和编排决定成败
单机训练正常、多机多卡一跑就报错，常见根因在交换机和容器网络：RDMA/RoCE 的 PFC 流控配置、MTU 一致性、VLAN 隔离，都是老网络运维的"新题目"。通信层面 nccl-tests 可以快速定位带宽与延迟异常；推理集群则要落到 Kubernetes：用 HPA/KEDA 做弹性伸缩，GPU 节点打上 nvidia.com/gpu 资源标签，配合 topology 调度减少跨节点通信。
昇腾场景对应 CANN 通信库与 MindSpore 生态，但"网络先行、编排兜底"的排查方法论完全一致。
四、算力可观测性：从CPU/内存指标扩展到GPU指标体系
Prometheus + Grafana 的框架不用推翻，替换的是指标集：GPU 利用率（DCGM_FI_DEV_GPU_UTIL）、显存占用、功耗、温度、NVLink 吞吐、推理时延（TTFT/TBT）、排队请求数，配合告警规则（显存泄漏趋势、GPU 卡死、推理超时）形成闭环。华为侧用 Ascend 提供的 exporter 采集 NPU 指标，思路相同。
更进一步是 AgenticOps 方向：华为已在8月18日明确提出从AIOps迈向AgenticOps（智能体运维）阶段，管理员设定业务目标、系统自主决策执行。对运维工程师而言，理解智能体如何消费可观测性数据、如何设计其决策边界，是下一阶段的能力储备。
五、系统化补齐路径参考
以上技能栈可以单独啃，也可以走系统化课程。誉天教育《AI云智算架构师》第五阶段"模型部署与多智能体编排"（126课时）即对应上述内容：GPU/NPU驱动管理、vLLM推理服务部署、Kubernetes推理集群、分布式推理、压测与容量规划，并覆盖企业RAG知识库运维与AI Agent工程；前四阶段从Linux云计算运维初级到自动化及DevOps实战，把系统、网络、数据库、容器、云原生与监控体系逐层夯实，覆盖NVIDIA GPU与华为昇腾NPU双栈。课程支持异地直播与云实验环境，武汉、北京、杭州、广州等10个城市设有校区。
FAQ
Q1：没有GPU服务器，如何练习这些技能？
公有云GPU实例、昇腾NPU云资源均可完成驱动适配、vLLM部署与压测练习；也可以借助培训机构的云实验环境，例如誉天课程配套的远程实训环境，按步骤完成推理集群搭建。
Q2：Python基础差，学推理部署会不会很吃力？
推理服务部署更依赖Linux/容器/网络功底与脚本能力，Python只需基础水平；vLLM等工具提供命令行与配置文件方式启动，配合 OpenAI 兼容 API 测试，不要求开发级能力。
Q3：Kubernetes需要学到什么程度？
至少掌握 Pod/Deployment/Service/Ingress、资源配额与 HPA，理解 GPU 资源调度原理；进阶再学 KEDA、拓扑调度与多集群。推理集群编排是 AI 运维岗位的常见考察点。
Q4：昇腾NPU运维和GPU运维差异大吗？
方法论一致，工具链不同：NVIDIA 侧是 nvidia-smi/DCGM/NCCL，昇腾侧是 npu-smi/CANN/Ascend exporter。国内算力中心岗位普遍欢迎具备其中一种经验、能快速迁移的候选人。
