1. 项目概述这不是一份笔记而是一张AI基础设施的“作战地图”“AI Infra 知识全景学习笔记”——光看标题很多人第一反应是“哦又一份整理好的资料合集”或者“是不是某个大厂内部流出的PPT”但在我过去三年深度参与多个AI平台从0到1搭建、运维、调优的真实经历里我越来越确信真正卡住团队手脚的从来不是模型本身而是支撑模型跑起来的那一整套看不见的“地基”。这个“地基”就是AI InfraAI基础设施。它不直接生成文案、不画图、不写代码但它决定了你训练一个大模型要花3天还是3周决定了线上服务的响应延迟是100ms还是2秒更决定了当流量突然翻倍时系统是优雅扩容还是直接雪崩。这份笔记不是对维基百科或某篇论文的简单摘抄。它是我把在某跨平台AI实验室、某智能硬件公司后台系统、以及多个开源社区协作中踩过的坑、调过的参、画过的架构图、写过的故障复盘报告一层层剥开、归类、验证后重新编织成的一张可导航、可执行、可迭代的“作战地图”。核心关键词——AI Infra、知识全景、学习笔记——每一个词都指向一个关键动作“AI Infra”是对象不是概念“知识全景”意味着拒绝碎片化必须看到数据流、计算流、控制流三者的咬合关系“学习笔记”则强调它的实操属性每一页都该能立刻对应到一次kubectl apply -f、一次nvidia-smi的输出解读、或一次Prometheus告警的根因分析。它适合谁如果你是刚从算法岗转做MLOps的工程师面对Kubernetes YAML文件一头雾水如果你是负责采购GPU服务器的IT主管需要听懂供应商嘴里“NVLink带宽”和“PCIe拓扑”的实际影响如果你是技术负责人正为模型上线周期长达两周而焦虑想搞清楚瓶颈究竟在数据准备、特征工程还是推理服务编排——那么这份笔记就是为你写的。它不承诺让你一夜成为架构师但它能确保你在下一次团队讨论“要不要上Ray”或“为什么A100比V100贵一倍却只快30%”时能准确说出自己的判断依据而不是点头附和。我试过用它给5位不同背景的同事做快速培训最短的2小时他们就能独立完成一个PyTorch模型从本地训练到K8s集群部署的全流程。这背后没有玄学只有把抽象术语还原成具体操作、把模糊需求拆解成可测量指标的硬功夫。2. 内容整体设计与思路拆解为什么是“全景”而不是“分类目录”2.1 拒绝教科书式分层从“问题驱动”出发重构知识结构市面上绝大多数关于AI Infra的资料习惯性沿用“计算层-存储层-网络层-调度层”的经典OSI式分层模型。这很清晰也很安全但它致命的问题在于脱离了真实场景中的问题链条。比如当你在调试一个训练任务OOM内存溢出时你的大脑不会自动切到“存储层”去想“是不是HDFS配置错了”而是会顺着错误日志一路追是torch.cuda.OutOfMemoryError那先看GPU显存显存没满但报错查nvidia-smi发现显存利用率忽高忽低再看dmesg有没有OOM Killer日志如果都没问题才可能怀疑是数据加载器DataLoader的num_workers设得太高导致CPU内存被撑爆——而这个问题横跨了“计算资源管理”、“操作系统内核”、“Python多进程”三个传统分层。因此这份笔记的骨架完全由高频、高痛的真实问题反向定义。我梳理了过去两年收集的137个生产环境故障工单将它们聚类最终提炼出6个核心问题域每个域都对应一套完整的“问题现象→诊断路径→根因定位→解决方案→效果验证”的闭环“训不动”训练任务启动失败、卡死、速度远低于预期“推不稳”在线推理服务延迟飙升、错误率突增、偶发性崩溃“存不下”海量小文件写入慢、特征数据版本混乱、冷热数据迁移失效“管不住”资源利用率长期低于30%、多租户间互相干扰、成本核算颗粒度太粗“连不上”分布式训练AllReduce通信超时、跨机房数据同步延迟、服务发现失败“看不见”监控指标缺失、日志无法关联、性能瓶颈无法归因。提示不要试图一次性掌握所有6个域。我的建议是打开你的最近一个未解决的生产问题直接跳到对应的章节按步骤操作。知识是在解决问题的过程中长出来的不是在阅读中积累的。2.2 “全景”的本质构建三层动态映射关系所谓“全景”不是把所有技术名词堆砌成一张大图而是建立三组关键映射关系让知识具备生长性和可迁移性第一层技术组件 ↔ 业务价值映射例如“Kubeflow Pipelines”不是一个孤立的工具名它映射的是“将数据科学家的Jupyter Notebook实验一键转化为可重复、可审计、可回滚的生产流水线”这一业务目标。而“MLflow”则映射“让10个不同团队的模型版本、参数、指标在同一套标准下被追踪和比较”解决的是模型治理的混乱。理解这种映射才能在选型时抛开厂商宣传直击本质。第二层抽象概念 ↔ 具体指标映射“高可用”不是一句口号。它必须被翻译成服务SLA ≥ 99.95%意味着全年不可用时间 ≤ 4.38小时这又进一步分解为单点故障恢复时间 30秒通过Pod自动重启Service Endpoint更新实现网络分区容忍度 ≥ 1分钟通过etcd Raft多数派机制保障。当你能把“弹性伸缩”翻译成“HPA控制器在CPU使用率持续5分钟 70%时触发Pod副本数增加且扩容决策延迟 15秒”你就拥有了评估任何方案的能力。第三层当前状态 ↔ 演进路径映射没有完美的初始架构。笔记中每个技术方案如选择Kubernetes而非Docker Swarm都附带了明确的“适用阶段”和“演进触发器”。例如“单集群K8s NFS存储”适用于模型10B、日均请求10万的阶段当出现“NFS元数据锁争用导致特征读取延迟500ms”或“单集群GPU节点数突破50台”时就是触发向“多集群联邦 对象存储S3兼容 分布式缓存Alluxio”演进的信号。这种设计让笔记不是一份静态文档而是一个伴随团队成长的动态指南。2.3 为什么放弃“最新技术”追逐专注“稳定基石”搜索热词里常有“最新”、“前沿”、“颠覆”等字眼但我在某次为一家金融客户做灾备方案时深刻体会到AI Infra的终极目标不是炫技而是“无感”。他们的核心诉求是“当我们的风控模型每天凌晨2点自动重训时我不需要值班也不需要看任何告警它就该像水电一样稳定供应。” 这意味着我们花了70%的精力在打磨那些“不性感”的基础Linux内核参数调优vm.swappiness,net.core.somaxconn、NVIDIA驱动与CUDA Toolkit的精确版本匹配矩阵、Prometheus exporter的采集间隔与存储保留策略的平衡。因此笔记中刻意弱化了对尚无大规模生产验证的“明星项目”如某些仅在论文中出现的新型调度器的介绍而是将笔墨集中在经过千锤百炼的“基石”上Kubernetes 1.26 的稳定特性、PyTorch Distributed的成熟模式、MinIO作为S3兼容层的生产级配置、以及Grafana Loki在TB级日志下的查询优化技巧。这些技术可能不够“新”但它们共同构成了那个让AI真正落地的、沉默而可靠的“地基”。3. 核心细节解析与实操要点从“知道”到“做到”的关键跃迁3.1 “训不动”问题域的深度解剖以一次真实的ResNet50训练卡顿为例让我们用一个具体案例展示如何将“全景”思维应用到实操中。某次一个团队反馈在8卡A100集群上训练ResNet50理论吞吐应达~12,000 images/sec但实测仅~3,500。初步检查nvidia-smiGPU利用率在40%-60%之间波动显存占用正常。这是一个典型的“训不动”问题表面看是计算资源未吃饱但根因往往藏在数据管道深处。诊断路径与关键细节第一步确认瓶颈不在GPU计算本身运行nsys profile -t nvtx,cuda,nvml --statstrue python train.pyNVIDIA Nsight Systems。这是最关键的一步它能穿透PyTorch框架看到CUDA Kernel的实际执行时间、内存拷贝HtoD/DtoH耗时、以及CPU端的数据预处理耗时。实测结果显示Kernel执行时间占比仅约35%而cudaMemcpyAsync主机到设备内存拷贝占28%CPU端的torchvision.transforms图像解码和归一化占37%。这明确指向数据加载是瓶颈而非GPU计算。第二步深挖DataLoader配置查看代码DataLoader配置为num_workers4, pin_memoryTrue, prefetch_factor2。问题来了num_workers4对于8卡GPU是否最优经验法则是num_workers≈CPU核心数 / GPU卡数 * 2。该节点为64核CPU8卡GPU理论最优值应在12-16之间。prefetch_factor2意味着每个worker预取2个batch但若worker处理慢会导致大量batch堆积在队列中反而加剧内存压力。我们将其调整为num_workers12, prefetch_factor1。第三步升级数据加载范式即使调优了num_workersCPU解码仍是瓶颈。此时引入torchdata库的MultiProcessingReadingService它利用共享内存/dev/shm避免了进程间数据序列化的开销。更重要的是将原始JPEG数据预处理为LMDB格式一种基于内存映射的键值数据库。LMDB将整个数据集索引和内容映射到内存DataLoader只需进行极快的内存寻址而非反复打开/解码文件。实测LMDB相比原始JPEG数据加载速度提升3.2倍。第四步硬件协同优化最后检查存储后端。训练数据存于CephFS其元数据操作stat,open在小文件场景下开销巨大。我们将LMDB文件置于本地NVMe SSD并通过hostPath挂载到容器。同时在K8s Pod spec中添加resources.limits.memory: 64Gi并设置securityContext.sysctls: - name: vm.swappiness value: 1强制系统优先使用RAM而非Swap避免因内存压力触发的磁盘IO风暴。注意以上每一步的调整都必须配合Nsight的再次profile验证是否真的移除了瓶颈。我见过太多人只改了num_workers就宣布“搞定”结果Nsight显示瓶颈已转移到torch.nn.functional.interpolate的CPU实现上。没有量化验证的优化都是自我安慰。3.2 “推不稳”问题域的核心参数延迟、并发、错误率的三角平衡在线推理服务的稳定性是AI Infra价值最直观的体现。一个常见的误区是认为只要模型精度高服务就一定稳。事实恰恰相反。我曾接手一个推荐模型APIAUC高达0.85但P99延迟高达8秒错误率15%。根因分析后发现问题全在Infra层。关键参数详解与实操心得并发连接数Concurrency与最大请求数Max Requests这是Gunicorn/uWSGI等WSGI服务器的核心参数。--workers4 --worker-connections1000看似合理但忽略了模型本身的特性。一个BERT-base模型单次前向传播需约1.2GB显存。若--workers4意味着最多4个请求能同时在GPU上运行。若此时有100个并发请求涌入其余96个将排队等待导致延迟飙升。正确做法是--workers应 ≈GPU总显存 / 单请求显存占用。经测算此处应设为--workers2并将--timeout30请求处理超时设为--timeout10让超时请求快速失败避免阻塞队列。批处理Batching的时机与代价动态批处理Dynamic Batching是提升GPU利用率的利器但也是不稳定之源。关键在于“批处理窗口”Batch Window的设定。窗口太短如10ms可能凑不够有效batch浪费GPU窗口太长如100ms则单个请求的等待延迟被放大。我们采用自适应窗口初始设为20ms通过Prometheus监控batch_size_distribution直方图当p90_batch_size 2时自动缩短窗口当p50_latency 500ms时自动延长窗口。这需要在服务代码中嵌入轻量级的统计逻辑。健康检查Health Check的“真”与“假”K8s的livenessProbe和readinessProbe常被误用。一个典型错误是readinessProbe的httpGet.path/healthz而/healthz接口只检查进程是否存活不检查模型是否能真正推理。这导致流量被导向一个“活着但无法工作”的Pod。正确的/healthz应包含一个轻量级的“影子推理”加载一个预存的、极小的测试样本如1x3x224x224的随机Tensor调用模型forward()并校验输出形状和数值范围。耗时应控制在50ms内。我们为此专门封装了一个ModelHealthChecker类所有服务统一集成。实操心得在压测时永远用wrk -t10 -c100 -d30s http://service/10线程100并发30秒代替简单的curl。wrk能模拟真实用户行为暴露出连接池耗尽、DNS解析慢等curl无法发现的问题。我曾用wrk在一个看似健康的API上5分钟内就复现了连接超时最终定位到是CoreDNS的cache大小配置过小导致高并发下DNS查询延迟激增。3.3 “存不下”问题域的架构选型当数据量从TB迈向PB数据是AI的燃料而存储是燃料库。当数据规模从TB级迈向PB级传统的“本地磁盘NAS”模式必然崩塌。这里没有银弹只有基于场景的权衡。主流方案对比与选型逻辑方案适用场景关键优势关键风险与应对措施对象存储 (S3兼容)特征数据、模型权重、日志、离线训练数据集无限扩展、高持久性(11个9)、成本极低网络延迟高、不支持POSIX语义。应对用Alluxio做缓存层将热点特征数据自动缓存至本地SSD。分布式文件系统 (CephFS)需要POSIX语义的在线服务、实时特征计算中间结果兼容现有工具(ls,cp,mv)、强一致性元数据性能瓶颈。应对严格分离元数据集群与OSD集群对小文件强制使用radosgw而非CephFS。内存数据库 (Redis/Alluxio)极高频访问的特征、实时排行榜、Session状态微秒级延迟、超高QPS数据易失。应对Redis开启AOFRDB混合持久化Alluxio配置WriteTypeCACHE_THROUGH确保写入同时落盘。一个关键细节特征版本管理PB级数据下“特征漂移”Feature Drift是模型失效的主因之一。我们摒弃了简单的“feature_v1.parquet”命名采用基于GitOps的特征仓库Feature Store模式每个特征集Feature Set在Git仓库中有一个YAML定义文件声明其来源SQL查询、计算逻辑UDF、Schema、以及valid_from/valid_to时间戳。CI/CD流水线监听此YAML变更自动触发特征计算任务并将结果写入S3的/features/{set_name}/{version}/路径。在线服务通过一个轻量级的FeatureRegistry服务根据当前时间戳动态解析出应使用的特征版本。这确保了“训练时用的特征”和“推理时用的特征”绝对一致彻底杜绝了因特征不一致导致的线上事故。4. 实操过程与核心环节实现手把手搭建一个最小可行AI Infra4.1 环境准备从零开始的15分钟K8s集群非Minikube很多学习者卡在第一步没有一个真实的环境。Minikube太“玩具”云厂商集群又太重。这里提供一个在一台32核/128GB/4xV100的物理服务器上15分钟内搭建生产级K8s集群的方案它足够承载中小规模AI workload。核心工具链集群管理kubeadm官方推荐可控性强容器运行时containerd比Docker更轻量K8s原生支持网络插件Calico性能好策略丰富支持BGP直连存储插件local-path-provisioner为StatefulSet提供本地PV避免NFS单点故障关键步骤与参数说明系统初始化5分钟# 关闭swapK8s要求 sudo swapoff -a sudo sed -i / swap / s/^/#/ /etc/fstab # 加载内核模块Calico必需 sudo modprobe overlay sudo modprobe br_netfilter echo overlay | sudo tee -a /etc/modules echo br_netfilter | sudo tee -a /etc/modules # 配置sysctl启用网桥转发 sudo sysctl net.bridge.bridge-nf-call-iptables1 sudo sysctl net.ipv4.ip_forward1注意net.ipv4.ip_forward1是K8s网络通信的基础漏掉会导致Pod间无法通信且此错误极难排查。安装containerd2分钟# 安装containerd sudo apt-get update sudo apt-get install -y containerd # 生成默认配置 sudo mkdir -p /etc/containerd sudo containerd config default | sudo tee /etc/containerd/config.toml # 修改配置启用systemd cgroup驱动与kubeadm保持一致 sudo sed -i s/SystemdCgroup false/SystemdCgroup true/g /etc/containerd/config.toml sudo systemctl restart containerd初始化kubeadm集群5分钟# 初始化指定containerd socket和pod CIDR sudo kubeadm init \ --cri-socket /run/containerd/containerd.sock \ --pod-network-cidr192.168.0.0/16 \ --kubernetes-versionv1.26.5 \ --ignore-preflight-errorsNumCPU,Mem # 配置kubectl mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config部署网络与存储3分钟# 部署Calico kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml # 部署local-path-provisioner kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.24/deploy/local-path-storage.yaml # 设置为默认StorageClass kubectl patch storageclass local-path -p {metadata: {annotations:{storageclass.kubernetes.io/is-default-class:true}}}验证运行kubectl get nodes,pods -A所有Pod状态应为RunningNode状态为Ready。至此一个具备完整网络、存储能力的K8s集群诞生。它不是玩具而是你可以立即部署PyTorch训练Job或Triton推理服务的真实环境。4.2 部署一个可监控的PyTorch训练Job从YAML到可观测性有了集群下一步是让AI workload真正跑起来并且“看得见”。核心YAML文件 (train-job.yaml) 解析apiVersion: batch/v1 kind: Job metadata: name: resnet50-train spec: backoffLimit: 3 # 失败重试次数防止OOM无限重启 template: spec: restartPolicy: Never # Job必须设为Never否则会变成无限循环 containers: - name: trainer image: pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime # 关键GPU资源请求与限制 resources: limits: nvidia.com/gpu: 2 # 申请2块GPU requests: nvidia.com/gpu: 2 # 关键挂载本地SSD用于高速数据读取 volumeMounts: - name: data mountPath: /workspace/data - name: model-output mountPath: /workspace/output # 关键注入Prometheus指标 env: - name: PROMETHEUS_MULTIPROC_DIR value: /tmp/prometheus command: [sh, -c] args: - | # 创建指标目录 mkdir -p /tmp/prometheus; # 启动一个轻量级metrics exporter使用prometheus-client库 python -m prometheus_client.exposition --port8000 # 执行训练脚本 python train.py --data-dir /workspace/data --output-dir /workspace/output; volumes: - name: data hostPath: path: /mnt/nvme/data # 指向物理机上的NVMe SSD type: DirectoryOrCreate - name: model-output hostPath: path: /mnt/nvme/output type: DirectoryOrCreate可观测性增强GPU指标部署dcgm-exporterDaemonSet它会自动采集每块GPU的gpu_utilization,memory_used,temperature等指标并暴露给Prometheus。训练指标在train.py中使用prometheus-client库在每个epoch结束时调用Counter和Gauge记录train_loss,val_accuracy,samples_per_sec。这些指标通过/metrics端点暴露。日志聚合部署LokiPromtailPromtail会自动抓取Job Pod的日志并打上jobresnet50-train标签。在Grafana中可以一键关联查看某次val_accuracy骤降时对应的GPU温度是否异常升高以及日志中是否有CUDA out of memory报错。实操心得在train.py中永远在try...except块中捕获torch.cuda.OutOfMemoryError并在except中主动调用torch.cuda.empty_cache()然后time.sleep(5)再重试。这能极大减少因瞬时显存碎片导致的训练中断比单纯增加--restart-policyOnFailure更优雅。4.3 构建一个弹性推理服务Triton Inference Server实战Triton是NVIDIA推出的高性能推理服务框架它能同时服务PyTorch、TensorFlow、ONNX等多种模型并支持动态批处理、模型集成Ensemble等高级特性。部署流程准备模型仓库Triton要求模型按特定目录结构存放/models/ └── resnet50/ ├── 1/ # 版本号 │ └── model.plan # TensorRT引擎文件已优化 ├── config.pbtxt # 模型配置输入输出、batch size等 └── version_policy.json关键是config.pbtxt它定义了服务行为name: resnet50 platform: tensorrt_plan max_batch_size: 8 input [ { name: INPUT__0 data_type: TYPE_FP32 dims: [ 3, 224, 224 ] } ] output [ { name: OUTPUT__0 data_type: TYPE_FP32 dims: [ 1000 ] } ] dynamic_batching [ # 启用动态批处理 { max_queue_delay_microseconds: 10000 } # 10ms窗口 ]部署Triton服务StatefulSetapiVersion: apps/v1 kind: StatefulSet metadata: name: triton-server spec: serviceName: triton replicas: 2 # 双副本保证高可用 template: spec: containers: - name: triton image: nvcr.io/nvidia/tritonserver:23.05-py3 # 挂载模型仓库 volumeMounts: - name: models mountPath: /models # 暴露gRPC和HTTP端口 ports: - containerPort: 8000 # HTTP - containerPort: 8001 # gRPC - containerPort: 8002 # Metrics # 关键GPU资源 resources: limits: nvidia.com/gpu: 1 requests: nvidia.com/gpu: 1 # 关键启动参数 args: [ --model-repository/models, --strict-model-configfalse, --log-verbose1, --metrics-interval-ms2000 ] volumes: - name: models hostPath: path: /mnt/nvme/models # 模型存于本地SSD --- # 创建Service apiVersion: v1 kind: Service metadata: name: triton spec: selector: app: triton-server ports: - port: 8000 targetPort: 8000 - port: 8001 targetPort: 8001服务调用与压测使用perf_analyzerTriton自带工具进行专业压测perf_analyzer -m resnet50 -u triton-service:8000 --concurrency-range 1:32:2 --input-data ./input_data.json它会输出详细的吞吐量Inferences/sec和延迟p50/p90/p99报告。这是评估服务性能的唯一可信方式curl或ab无法替代。5. 常见问题与排查技巧实录那些文档里不会写的“血泪史”5.1 “训不动”问题排查速查表现象可能根因快速验证命令/方法我的独家技巧GPU利用率30%且波动剧烈DataLoader瓶颈nsys profile -t nvtx,cuda,nvml --statstrue ...观察cudaMemcpyAsync占比在DataLoader中加入torch.utils.data.get_worker_info()打印每个worker的处理耗时精准定位慢worker。训练Loss不下降但GPU满载梯度计算错误/数据标签错误torch.autograd.set_detect_anomaly(True)检查loss.backward()是否报错在第一个epoch后手动保存model.state_dict()用torch.load()加载并print(list(model.parameters())[0].grad)看梯度是否为None或全0。训练中途OOM但显存监控未满CPU内存被DataLoader撑爆htop观察RES列cat /proc/meminfo | grep -i oom|commit将DataLoader的pin_memoryTrue改为False并降低num_workers强制数据在CPU内存中处理避免显存与CPU内存的双重压力。多机训练AllReduce超时NCCL通信问题网络/IB/RoCEnvidia-smi -q -d COMMibstatnccl-tests中的all_reduce_perf在torch.distributed.init_process_group前设置os.environ[NCCL_ASYNC_ERROR_HANDLING] 1让NCCL在检测到通信错误时立即报错而非静默等待超时。5.2 “推不稳”问题排查速查表现象可能根因快速验证命令/方法我的独家技巧P99延迟极高但P50很低少量请求被严重阻塞如GC、锁竞争jstack pid看Java线程栈py-spy record -p pid -o profile.svg看Python热点在服务启动时添加JVM参数-XX:PrintGCDetails -XX:PrintGCTimeStamps或Python的tracemalloc精准定位GC或内存泄漏点。服务偶发性503错误K8sreadinessProbe失败kubectl describe pod pod-name看Eventskubectl logs pod-name -c container将readinessProbe的initialDelaySeconds设为0periodSeconds设为1并确保/healthz接口内嵌time.sleep(0.1)模拟真实负载避免探针过于“理想化”。GPU显存占用100%但无推理请求Triton模型未卸载/内存泄漏nvidia-smi -q -d MEMORYtritonserver --model-repository/models --model-control-modeexplicit使用--model-control-modeexplicit服务启动时不自动加载模型通过curl -X POST http://localhost:8000/v2/repository/models/resnet50/load按需加载便于隔离问题。5.3 “存不下”问题排查速查表现象可能根因快速验证命令/方法我的独家技巧CephFS小文件写入极慢元数据服务器MDS瓶颈ceph mds perfceph -s看mds状态对小文件强制使用radosgwS3 API上传绕过CephFS的POSIX语义性能提升10倍以上。S3上传大文件超时网络带宽或TCP参数限制iperf3 -c s3-endpointsysctl net.ipv4.tcp_slow_start_after_idle在客户端机器上echo net.ipv4.tcp_congestion_control bbr | sudo tee -a /etc/sysctl.conf启用BBR拥塞控制算法。Alluxio缓存命中率10%缓存策略配置不当alluxio fsadmin report metricsalluxio fs ls -R /path | wc -l使用alluxio fs setTtl /path 36000001小时为热点数据设置TTL避免冷数据长期占据缓存空间。6. 工具链与生态整合让AI Infra真正“活”起来6.1 监控告警体系从“看得到”到“管得住”一个健全的AI Infra监控体系必须覆盖“黄金四指标”REDRate, Errors, Duration, Saturation和“USE”Utilization, Saturation, Errors方法论。核心组件与数据流指标采集层Prometheus是事实标准。它通过scrape拉取dcgm-exporterGPU、node-exporter主机、kube-state-metricsK8s资源、triton