1. AI-Infra是什么先别急着学框架把这句话读懂我第一次听到AI-Infra这个词是在一次内部技术分享会上当时隔壁组的大佬在台上讲GPU利用率优化台下坐了二十几个做推荐、搜索、CV的算法工程师。他放了一张图图上是某大模型训练任务里GPU的实时利用率曲线——乍一看一片黄绿色绿得发慌但细看时间线每隔一两个小时就有一段明显的低谷蓝色占比骤降。大佬说这些低谷全是存储瓶颈、网络同步、数据预处理卡顿造成的不是GPU不够而是Infra没跟上。那会儿我就意识到大家天天追着新模型、新Loss、新榜单跑但真正让模型能跑起来、跑得快的其实是底下这套看不见的地基——AI-Infra。所谓AI-Infra全称是Artificial Intelligence Infrastructure直译是AI基础设施但这个词的实际含义比字面大得多。它不是一个单独的软件、一个框架或一台机器而是支撑AI系统全生命周期的一套组合能力从GPU等算力硬件选型、集群网络组网到资源调度与编排平台再到数据存储与预处理管道再往上还有分布式训练框架、模型推理引擎、模型服务化平台以及贯穿全程的监控、告警、日志和成本治理。一句话算法工程师负责让模型想得聪明AI-Infra工程师负责让模型跑得动、跑得快、跑得省。这个领域为什么这两年突然火起来因为大模型把算力和复杂度推到了临界点。单卡已经塞不下模型单机也无法完成训练分布式训练、模型并行、算子融合、推理加速这些技术不再是论文里的概念而是每天都要面对的生产问题。一个推理服务需要支撑几十路并发响应时间还不能超过两秒——网络抖动、显存碎片、调度排队、量化误差随便哪个环节出问题体验都会崩。所以越来越多团队开始设专门的AI-Infra岗位要求你懂Linux、懂K8s、懂GPU、懂CUDA还得懂一点模型结构和训练框架。这条路刚走的人不多但确实值得走。这篇就当第一章我根据自己的实践把AI-Infra的地图先铺开讲清楚里面有哪些模块、各自解决什么问题再给一条可落地的入门路径最后聊几个我已经踩过的坑。2. 一张图拆解AI-Infra的六大核心板块很多第一次接触AI-Infra的人会以为这就是装显卡驱动、配环境、写个Dockerfile其实那只是最外围的皮毛。真正干活的时候你面对的是下面这六个彼此咬合的部分。2.1 硬件与网络层GPU不只是算力更是显存带宽的组合这一层最容易理解但最容易被低估。做AI-Infra不要求你能焊电路板但你必须清楚几类硬件参数对性能的影响。GPU的核心指标不只看FLOPS还有显存容量、显存带宽、卡间互联带宽。举个例子NVIDIA A100的显存带宽是2TB/s级别H100更高而消费级RTX 4090虽然FP16算力不差但显存带宽只有1TB/s左右NVLink也没有。如果你要跑大模型训练4090在多卡通信时就会成为瓶颈——不是说不能跑而是每过一个通信点整体效率都往下掉。网络层面多机训练时必须了解IBInfiniBand和RoCE的区别。IB是专用网络协议延迟低、可靠性高但贵RoCE是以太网上的RDMA方案性价比高但对网络的丢包率极其敏感。组网时如果交换机缓冲不足一旦发生微突发丢包NCCL的AllReduce效率会断崖式下跌。我见过一个场景训练任务隔几个小时就出现一次NCCL timeout排查到最后发现是网卡firmware版本不一致。还有存储。GPU训练的数据读取是高速并发数据如果放在机械盘上很容易出现GPU在等数据的尴尬状态。现代训练集群的存储方案普遍是NVMe SSD加高性能并行文件系统比如Lustre、GPFS或者云上的高性能ESSD缓存热点数据尽量让数据读取速度大于GPU消化速度。2.2 资源调度层排队比榨干每一块显卡更重要有了硬件资源接下来是调度。很多小团队一开始的做法是谁要用卡直接上去占但不出一周就会出现问题有人占着8卡跑一个单卡任务好几天有人排队等卡等到心态爆炸还有人不小心把训练进程跑到了登录节点上直接把整个集群搞卡。生产环境的调度核心是两套主流方案Slurm和KubernetesK8s。Slurm是HPC领域的元老在传统科学计算和超算中心里用得非常多。它的优势是成熟、稳定作业管理语义清晰适合长时运行的大规模训练任务。你在国内很多智算中心里看到的基本都是这类方案。K8s则更偏向云原生适合需要弹性伸缩、混合部署多种应用的团队。K8s里跑GPU任务通常需要配合NVIDIA Device Plugin、Node Feature Discovery这些组件让调度器感知GPU资源。更专业的做法是部署Volcano、Kueue这类支持队列和优先级的高级调度器它们懂得把8卡任务作为一个整体来调度而不是拆成8台机器上的单个容器分别调度。但这里有一个认知很关键的转变调度系统的目标是让全局资源利用率维持在合理区间而不是把每张卡都榨到100%。因为训练任务对资源是整块需求如果把8卡任务拆到两台各4卡的机器上跨机通信带来的开销可能让任务变慢20%单位产出反而更差。一个设计良好的调度策略有时候宁可让部分资源空闲也要保证流转任务的性能一致性。2.3 数据管道层GPU一分钟吃掉的数据够CPU处理一小时数据管道是AI-Infra里最容易被忽视、但最影响效率的环节之一。原因很简单模型训练是GPU高速消化数据它一秒钟能处理成千上万张图片或几十万token如果上游数据管道太小水管GPU就只能干等。数据管道通常包含三个环节采集/存储、预处理、加载。预处理环节最容易出问题的是数据解压和格式转换。比如原始数据是压缩的TFRecord或WebDataset如果直接在训练进程里做解码每张图都要解压、缩放、增广CPU负担会非常重。合理的做法是启动多个独立的DataLoader Worker进程让它们并行地做解码和预处理把处理好后的数据直接送到GPU显存里。更高级一点的做法是使用缓存层。实践中常用两种本地缓存训练机的SSD上划出一块空间存放频繁读取的数据集切片避免每次都走网络存储。内存缓存把热点数据集直接映射到Page Cache里尤其适合反复迭代的小数据集。再往上层的框架是数据编排工具例如TF Data、PyTorch DataLoader与WebDataset的组合使用。PyTorch 2.0之后的DataLoader支持了更细粒度的数据集切分、worker动态调整等能力可以直接通过参数配置。想优化数据管道建议先用nvidia-smi或DCGM观测GPU的利用率曲线如果GPU利用率在低峰和高峰之间剧烈波动大概率是数据加载跟不上。2.4 分布式训练框架层从单卡到千卡的跨越现在很多工程师入门AI-Infra都是从分布式训练框架开始的这也是最程序员友好的一层。单卡训练好理解模型加载到显存数据一批批算梯度更新参数。多卡训练就有四种基本并行策略数据并行DP/DDD每张卡都放一个完整模型副本喂不同批次的数据定期同步梯度。简单但显存占用大。张量并行TP把层内部的矩阵运算切成多份分给多张卡适合超大单层。流水线并行PP把模型按层切开每张卡负责若干层数据像流水线一样流过各卡。ZeRO优化把优化器状态、梯度、参数分片配合通信让显存需求接近数据并行但容量要求大幅降低。实际工程里Megatron-LM、DeepSpeed、PyTorch FSDP这几套方案都已经相当成熟。选型的核心是显存够不够通信快不快代码改造大不大。DeepSpeed的ZeRO-3技术在预训练大模型时几乎是标配它会在多个GPU之间对参数、梯度和优化器状态做动态分片。Hugging Face的Transformer库也提供Trainer接口底层默认支持FSDP开发效率很高适合快速验证。但框架不是万能的训练跑得不快很多时候是框架参数没调对。比如梯度累积步数、混合精度的fp16/bf16选择、通信后端NCCL还是GLOO、checkpointing策略等都会直接影响吞吐。这些参数的具体意义我后面在实操部分展开讲。2.5 推理与服务化层性能瓶颈从跑得动变成响应快训练做得再好模型最终要上线对外提供服务这就是推理与服务化。推理和训练的技术挑战完全不同。训练追求总吞吐量推理追求低延迟高并发。你能让一张卡每秒训练几万样本但上线后可能只敢让一个模型同时服务几十个请求因为每个请求都要求几秒内返回。现代推理服务的核心是三块模型优化量化INT8、INT4、剪枝、蒸馏、算子融合。常用的工具有TensorRT、ONNX Runtime、OpenVINO。大模型推理里还有KV Cache量化、连续批处理Continuous Batching这些技巧。推理引擎当下最火的是vLLM、TensorRT-LLM它们都支持PagedAttention和Continuous Batching机制大幅提高GPU利用率。服务框架Triton Inference Server在工业界是事实标准支持多模型管理、动态batch、并发调度还能混合跑PyTorch、TensorRT、ONNX等不同后端。推理路径上还有一个关键概念是SLA也就是服务等级协议通常包含P50/P99延迟指标。你的服务器性能是否达标不是看平均延迟而是看P99延迟也就是99%请求的响应时间这是用户体验的真实感受。2.6 可观测与运维层没有监控的集群就像没有仪表盘的飞机最后一层是贯穿前面所有层的基础设施基础设施——可观测性。AI集群的监控和传统Web服务不大一样。除了常规的CPU、内存、网络你还得盯GPU的细粒度指标SM占用率指示GPU计算核心被利用的比例数据加载慢会导致这个值偏低。显存占用量与显存带宽。GPU温度和功耗影响降频风险。NVLink/PCIe/网络通信量。NVIDIA官方提供的DCGMData Center GPU Manager几乎是标配它配合Prometheus和Grafana可以搭建一套完整的GPU监控看板。更进一步还有专门面向训练任务的监控系统可以分析各卡之间的同步等待时间定位最慢的卡。这一层还有成本治理。大模型时代的算力账单是非常惊人的没有预算监控和配额管理月底财务报表会非常难看。3. 一线工程师的AI-Infra入门实操从零搭建一套可用的GPU开发环境前两节讲的是地图这一节开始讲走路——怎么真正上手。我以最典型、也是新手最需要的场景为例本地或者单机多卡环境下搭建一套可用的GPU AI开发环境先把模型跑起来再逐步走向集群。3.1 动手之前先检查硬件、驱动和容器运行时很多新手拿到一台GPU服务器上来就pip install torch结果跑模型报错说CUDA不可用然后陷入重装驱动-重启-再报错的循环。这个坑我在早期踩得很惨现在每次拿到新机器都会先走一遍固定检查流程。第一步查看GPU硬件是否被系统识别。lspci | grep -i nvidia nvidia-smi如果nvidia-smi命令找不到说明驱动没装好或者内核模块没加载。如果lspci能看到GPU但nvidia-smi看不到建议先检查/proc/driver/nvidia/version是否存在再检查dkms status确认驱动是否成功编译进当前内核。第二步确认CUDA版本与GPU架构的匹配关系。这里有一个常见误区大家总以为要装最新的CUDA其实更重要的是CUDA版本和驱动版本兼容和你将要安装的PyTorch版本兼容。PyTorch的每个版本都对应一个编译时的CUDA版本比如cu118代表CUDA 11.8cu121代表CUDA 12.1。如果你用PyTorch 2.1默认带CUDA 12.1却装了个只支持CUDA 11.x的驱动大概率会有兼容性报错。最稳妥的办法是先选定PyTorch版本根据PyTorch官方说明确定需要的CUDA版本再查NVIDIA官方驱动兼容表用对应版本的驱动。这套顺序能避免90%的环境装好但跑不了问题。第三步确认容器运行时。生产环境几乎都基于Docker跑GPU任务而Docker默认不能直通GPU设备。需要安装NVIDIA Container Toolkit并配置Docker使用nvidia作为默认运行时。这样容器内外GPU环境不一致的问题会大幅度减少。# 安装nvidia-container-toolkit之后确认Docker配置 docker info | grep -i runtime3.2 用Docker构建可复现的训练开发环境环境搭建的终极目标是可复现——同一个镜像在任何机器上跑出来的环境完全一致。实践中我通常基于NVIDIA官方镜像做二次封装。我经常用的基础镜像是nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04然后在此之上装Python 3.10、PyTorch、以及项目依赖。FROM nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04 ENV DEBIAN_FRONTENDnoninteractive \ TZAsia/Shanghai RUN apt-get update apt-get install -y \ python3.10 python3-pip git vim curl tmux \ ln -s /usr/bin/python3.10 /usr/bin/python RUN pip install --no-cache-dir torch2.1.0 --index-url https://download.pytorch.org/whl/cu121 RUN pip install --no-cache-dir \ transformers datasets accelerate deepspeed sentencepiece WORKDIR /workspace这里有个经验不要把大量数据文件放进镜像镜像只负责环境数据用Volume挂载进去。构建完成后运行容器docker run --gpus all -it --rm \ --shm-size32g \ -v /mnt/data:/data \ -v $(pwd):/workspace \ my-ai-image:latest bash注意--shm-size参数PyTorch DataLoader的多进程通信依赖系统的/dev/shm共享内存如果这个空间太小加载数据时会报Bus error或File descriptor limit的错误。Docker默认shm大小只有64MB这几乎是新手必踩的坑之一。3.3 跑起第一个分布式训练脚本环境通了我们来做一个最小可行的分布式训练实验用PyTorch的DistributedDataParallelDDP实现一个简单的图像分类训练。先确认你的集群能跑多卡。python -c import torch; print(torch.cuda.device_count(), torch.cuda.get_device_name(0))如果输出了GPU数量和型号说明环境OK。下面是一个基础的单机多卡训练脚本模板重点看两处初始化进程组、切分数据集。# train_ddp.py import os import torch import torch.distributed as dist import torch.nn as nn from torch.nn.parallel import DistributedDataParallel as DDP from torch.utils.data import DataLoader, DistributedSampler def init_process_group(): dist.init_process_group( backendnccl, # GPU训练使用NCCLCPU则用GLOO init_methodenv://, # 从环境变量读取MASTER_ADDR和RANK ) def main(): # 这里的rank/gpu_id由训练启动器传入 local_rank int(os.environ[LOCAL_RANK]) global_rank int(os.environ[RANK]) torch.cuda.set_device(local_rank) init_process_group() device torch.device(cuda, local_rank) model nn.Linear(1024, 1024).to(device) ddp_model DDP(model, device_ids[local_rank]) dataset torch.randn(20000, 1024) # 模拟数据集实际换成你的数据 sampler DistributedSampler(dataset, shuffleTrue) loader DataLoader(dataset, samplersampler, batch_size256, num_workers4) optimizer torch.optim.SGD(ddp_model.parameters(), lr0.01) criterion nn.MSELoss() for epoch in range(5): sampler.set_epoch(epoch) # 每个epoch重新打乱数据 for x, y in loader: x x.to(device) y (x * 0.3).to(device) optimizer.zero_grad() loss criterion(ddp_model(x), y) loss.backward() optimizer.step() if global_rank 0: print(fepoch {epoch} loss {loss.item():.4f}) dist.destroy_process_group() if __name__ __main__: main()启动方式是使用PyTorch自带的torchruntorchrun --nnodes1 --nproc_per_node4 --rdzv_endpointlocalhost:29500 train_ddp.py稍微解释一下几个关键点。LOCAL_RANK是当前进程在本机内的编号0到3它决定进程使用哪张卡。RANK是全局编号单机时和LOCAL_RANK一致多机时每台机器上的RANK不重复。DistributedSampler的作用是让每个进程拿到数据集的不同切片避免所有卡在每一轮都训练同一批数据。backendnccl是GPU训练几乎唯一的选择因为NCCL在英伟达GPU间通信做了大量底层优化GLOO的跨机性能和它没法比。如果你发现多卡训练比单卡还慢大概率就是以下三类问题数据加载是瓶颈DataLoader的num_workers设置过低GPU在等数据。把num_workers调到8~16或者用prefetch_factor4试试。模型太小通信开销大于计算收益DDP每轮结束都会做梯度同步如果计算量很小而通信频繁多卡效率反而不如单卡。这种情况要加大batch size让每次同步的信息价值更高。跨机网络慢经常发生在没有IB网络的环境里。可以用通信效率测试工具去验证比如NCCL的all_reduce_perf工具。3.4 从单机脚本到K8s集群调度跑通了DDP脚本算是拿到了第一块拼图。真正到了生产环境你很快会发现直接在物理机上跑不符合工程化需求没法弹性扩容、没有故障恢复、没有监控告警。K8s集群里跑分布式训练核心思路是一个训练任务是一个Job每个GPU进程是一个Pod。当你有4张卡就启动4个Pod它们通过环境变量互相发现并建立通信。为了让K8s感知GPU资源需要部署NVIDIA Device Plugin它把GPU资源暴露为可调度的扩展资源nvidia.com/gpu。然后在Pod声明中申请GPUapiVersion: v1 kind: Pod metadata: name: gpu-training spec: restartPolicy: OnFailure containers: - name: trainer image: my-ai-image:latest command: [torchrun, --nnodes1, --nproc_per_node4, train_ddp.py] resources: limits: nvidia.com/gpu: 1但这只是最朴素的写法。生产级方案会用Volcano或Kueue这类支持队列、优先级、公平调度的调度器配合K8s的抢占机制和PodGroup概念把一组Pod看成一个任务整体调度而不是逐个Pod碰运气。实际上现在国内不少智算平台提供的是裸金属Slurm方案K8s主要用于弹性推理服务。两条技术栈都有市场入门阶段先把K8s的基础搞懂再根据团队实际选型补第二步。4. AI-Infra工具选型训练、推理、调度、监控逐个怎么选AI-Infra工具生态更新快经常有人问我现在到底用什么。我按照功能域给一张选型对照表并写出我的取舍逻辑。4.1 分布式训练框架选型对照方案适用场景优势注意点PyTorch DDP中小模型单机/多机数据并行简单成熟代码侵入小显存占用高超大模型放不下DeepSpeed ZeRO大模型预训练/微调显存效率高支持ZeRO-3/Offload代码改造多调试复杂PyTorch FSDP大模型微调/预训练官方支持与Hugging Face集成好ZeRO动态切分调度有开销Megatron-LM超大模型训练千亿)TP/PP/DP全支持NVIDIA优化强上手难度高适合少数专项团队我的建议第一套环境用PyTorch DDP跑通流程然后转FSDP或DeepSpeed。上来直接挑战Megatron不太适合入门因为你连DDP踩坑经验都没有会同时遇到环境、通信、模型结构多维度问题很难定位。4.2 推理引擎与服务框架选型方案优势适合场景vLLM吞吐高支持PagedAttention、Continuous BatchingLLM在线服务首选方案TensorRT-LLM极致性能NVIDIA深度优化对延迟要求极高的生产环境ONNX Runtime生态好CPU/GPU通吃中小模型的跨平台部署Triton Inference Server多模型管理、动态Batch、多后端统一企业级服务平台必学项单看推理引擎vLLM是当前最主流的选择。它兼容Hugging Face模型权重OpenAI协议接口部署大模型几乎是零改造完成。但如果你的服务容器里除了推理还要做很多业务逻辑例如请求过滤、多租户管理、灰度发布这时候建议把vLLM嵌到Triton后面让Triton做流量调度和模型生命周期管理。4.3 调度与监控选型调度方面如果你的集群以HPC训练为主Slurm更直接——作业排队、资源分配都是现成的。如果团队已经全面拥抱云原生K8s Volcano是当前国内事实标准Kueue也在快速崛起它轻量、原生支持队列和弹性配额。监控方面我的建议是Prometheus Grafana DCGM-Exporter三件套。DCGM-Exporter把GPU的关键指标暴露成Prometheus格式Grafana里可以直接导入NVIDIA官方提供的Dashboard模板10分钟就能看到完整的GPU监控视图。在此基础上再加一层日志系统EFK或Loki和链路追踪如果你跑推理服务。训练任务排查问题日志是刚需分布式任务日志分散在各个Pod里搞一个统一的日志采集如Filebeat/Fluentd发到ES或Loki能省下无数时间。5. 一线踩坑实录这些问题文档里不会写做AI-Infra这行踩坑才是成长的加速器。这一节我把最典型的五个问题的排查过程写出来读者如果遇到类似现象可以直接按路径查。5.1 显存看起来够用但训练直接OOM现象nvidia-smi看显存占用每个进程只占一小部分总占用也没满但PyTorch训练到中途直接报CUDA out of memory。排查思路先弄清显存分配机制。PyTorch有缓存分配器Caching Allocator为了减少分配开销它会一次性预留一大块显存即使当前实际只用了一部分。看torch.cuda.memory_summary()能知道真实分配情况。如果某个中间Variable在反向传播时被保留比如把loss的中间结果存到列表里显存就会逐步累积。解决阶梯排查是先把batch size调小看是否还OOM如果小了还会OOM检查是否有张量被意外地保留引用。也可以打开显存快照工具torch.cuda.memory_profile去细查。另外建议在训练脚本中设置os.environ[PYTORCH_CUDA_ALLOC_CONF]expandable_segments:True这个参数可以让PyTorch按需扩展显存块减少碎片化。5.2 GPU利用率很低但看起来CPU也没满现象GPU利用率曲线长期低于30%但用top看CPU占用也不高似乎一切正常。排查方向这个问题最常见的原因是数据管道串行化。具体来说就是DataLoader的num_workers设置太低或者数据读取过程中有锁竞争。另外一个隐蔽原因是CPU内存和GPU显存之间的H2D拷贝阻塞也就是每批数据在从CPU传到GPU时传输时间比计算时间长。我曾经遇到过一个离谱的案例数据是几千个小文件存放在NFS共享存储上。每次取一个batch要跨网络打开几百个文件延迟极高。后来把数据打成WebDataset格式顺序读取再配合num_workers提升GPU利用率直接从20%跳到90%。5.3 多机训练卡在NCCL timeout现象多机训练一开始工作正常但运行几个小时后某个节点上所有卡报NCCL通信超时任务直接崩溃。排查步骤用nvidia-smi topo -m查看GPU拓扑确认每张卡之间的通信路径是否走NVLink/PCIe Switch。用ibstatus或者ethtool -S检查网络接口的健康状态重点关注丢包率和重传率。检查NCCL环境变量是否合理。NCCL_IB_DISABLE、NCCL_SOCKET_IFNAME这些变量如果设置错误会导致NCCL走了TCP回退通信效率暴跌。如果确认为网络偶发拥塞可以在训练启动命令里加上NCCL_IB_TIMEOUT22、NCCL_IB_RETRY_CNT7这组参数让NCCL对临时故障有更高的容忍度。但这个问题的根治方案是网络架构层面解决——设置合理的拥塞控制算法、保证交换机无损网络配置、IB模式下检查子网管理器是否正常。5.4 K8s里申请GPUPod一直Pending现象在K8s集群中创建Pod请求GPU资源它一直处于Pending状态kubectl describe pod显示0/8 nodes available: insufficient nvidia.com/gpu。排查流程先看集群节点是否安装了NVIDIA Device Pluginkubectl -n kube-system get pods | grep nvidia如果没有就部署官方DaemonSet。再检查节点的可分配GPU数量kubectl describe node node-name看nvidia.com/gpu的Allocatable是否大于0。检查Device Plugin是否误以为GPU健康检查失败。有时候卡被MIG切分或处于错误状态Device Plugin不会向调度器上报该GPU。如果你用的是Volcano/Kueue这类自定义调度器Pod的排队信息不会显示在普通Pod的describe里要去对应调度器的日志里查。这类问题的高频原因是驱动版本太旧导致DCGM健康检查超时升级驱动和container-toolkit版本后大多能恢复。5.5 推理服务吞吐低延迟却不稳定现象用vLLM部署一个LLM服务压测时发现P99延迟很高但P50很低。原因大概率是长尾效应——个别超大请求超长的输入序列会阻塞continuous batching的调度。模型在做Prefill阶段处理输入token时计算量和输入长度成正比如果混入一个超长输入它会在GPU上占据大块时间后面的短请求就得排队等。优化思路在服务层做请求长度过滤超过阈值的请求走单独的异步队列。调整max_num_batched_tokens和max_model_len的配置限制单次batch的token总量。使用vLLM的--enable-prefix-caching特性对系统提示词这类固定前缀做缓存大幅缩短重复输入的Prefill时间。如果P99依然难压下去考虑用小batch、低并发的专用算力池单独服务高SLA业务。6. 我的体会与入行建议AI-Infra这个方向技术上杂但杂有杂的好处——它逼着你从硬件到软件、从单机到集群、从开发到运维把整条链路摸一遍。我记得很清楚第一次在Grafana上看到自己搭的监控看板上GPU利用率稳定在90%以上、训练loss平稳下降的时候那种成就感不亚于跑通一个全新模型。给想入这行的朋友三个小建议。第一个先养成本地环境的肌肉记忆。把Docker、NVIDIA Container Toolkit、torchrun这些基础操作练熟能在无头服务器上直接部署训练环境这是后续一切工作的前提。第二个遇到性能问题永远从数据流角度排查——数据从存储到GPU分了几步每步的耗时是多少GPU到底在等什么这个排查框架能解决80%的疑难杂症。第三个尽早建立监控意识。刚入门时可以只在任务开始和结束时看一眼nvidia-smi但建议尽早接入DCGM Prometheus因为很多问题不是每次都能复现只有当数据积累到一定程度你才能看清规律。第一章就先写到这里后面我会结合一个完整项目从零开始部署一个可弹性伸缩的AI推理服务把这一章里提到的调度、推理、监控全部串起来。如果你想上AI-Infra这条路建议先把这篇里的概念和技能树自己动手过一遍有任何具体问题都欢迎在评论区聊我看到了都会尽量回。