1. 从一张白纸到体系化认知我为什么要啃下AI Infra这块硬骨头第一次听到“AI Infra”这个词的时候我正蹲在一个模型训练任务的日志前面盯着GPU利用率曲线像心电图一样忽高忽低。那时候我以为搞AI就是调参、炼丹、看loss直到有人问我一句“你这个模型从数据加载到梯度同步中间到底经过了哪些环节”我愣住了。那一刻我才意识到自己一直在用黑盒的方式做事情而对支撑整个AI系统运转的基础设施层几乎一无所知。AI Infra直译过来就是“人工智能基础设施”。它不是某一个具体的框架或者工具而是一整套让AI模型能够被高效训练、部署和运行的底层支撑体系。你可以把它理解成AI世界里的“水电煤”——没有它再漂亮的算法也只是纸面上的公式。它涵盖的范围非常广从最底层的芯片和驱动到中间的通信库、训练框架、推理引擎再到上层的资源调度、监控运维每一层都有大量的技术细节和工程取舍。我写这份学习笔记的初衷很简单市面上讲AI Infra的资料要么太散要么太浅要么一上来就堆术语把人劝退。我希望把自己从零开始摸索的过程记录下来形成一个有逻辑、有层次、能落地的知识全景。不管你是刚入行的算法工程师还是想往Infra方向转型的后端开发者或者只是对“模型到底怎么跑起来的”感到好奇的技术爱好者这份笔记都能给你一条清晰的路径。接下来的内容我会按照“计算底座—训练基础设施—推理与部署—资源调度与运维”这条主线展开每一块都会讲清楚它解决什么问题、核心技术点是什么、实际工程中怎么选型和避坑。这些都是我在实际项目中踩过坑、翻过文档、跟同行交流之后沉淀下来的东西不是教科书式的罗列。2. 计算底座GPU、显存与算力单位的那些事2.1 为什么AI Infra绕不开GPU聊AI Infra第一个绕不开的就是GPU。很多人知道GPU比CPU适合做深度学习但说不清楚为什么。简单来说CPU像是一个数学教授什么题都会做但一次只能做几道GPU像是一万个中学生每个人只会做简单的加减乘除但一万人同时动手总量就非常可观。深度学习里的矩阵乘法、卷积运算本质上就是大量简单计算的堆叠所以GPU的并行架构天然适合。但这里有个容易被忽略的点GPU并不是越贵越好关键要看你的任务是什么类型。训练大模型需要高显存带宽和大的显存容量因为模型参数、梯度、优化器状态都要放在显存里而推理任务更看重吞吐量和延迟对显存的要求相对低一些。我见过有人拿消费级显卡去训大模型结果batch size只能设成1训练速度慢到怀疑人生。这不是显卡不好是场景不匹配。2.2 显存到底被谁吃掉了显存是AI Infra里最稀缺的资源之一。很多人第一次训练模型时都会遇到“CUDA out of memory”的报错然后一脸茫然我模型才几百兆怎么24G显存就不够了这里我列一下显存的主要消耗方模型参数这是最直观的比如一个7B参数的模型如果用FP16存储大约需要14GB。梯度训练时每个参数都要存对应的梯度大小和参数一样又是14GB。优化器状态如果用Adam每个参数要存一阶矩和二阶矩又是两倍参数大小FP32下就是56GB。激活值前向传播过程中每一层的输出都要存下来供反向传播使用这部分和batch size、序列长度强相关。临时缓冲区通信、算子计算过程中的临时空间。所以一个7B模型用Adam全量微调光模型相关的状态就要80GB以上还没算激活值。这就是为什么大模型训练要用分布式、要用ZeRO、要用混合精度。理解显存的去向是做好AI Infra的第一步。2.3 算力单位的换算与实测差异买卡的时候销售会跟你说“这张卡多少TFLOPS”但实际跑起来你会发现根本达不到。这里有几个概念需要厘清精度类型说明典型用途FP32单精度浮点传统训练、科学计算FP16半精度浮点混合精度训练BF16脑浮点大模型训练首选INT88位整数推理量化INT44位整数极致推理压缩TFLOPS标称值通常是在理想条件下测出来的实际利用率受限于显存带宽、通信开销、算子效率等因素。我在实际项目中观察到训练任务能达到标称算力的30%到50%就已经算不错了。所以做容量规划的时候不要按标称值算打个对折甚至更低才靠谱。注意不同精度下的算力不能直接比较。一张卡FP16算力是FP32的几倍但如果你用FP32跑就只能享受FP32的算力。选卡之前先确定你的训练精度策略。3. 训练基础设施从单卡到千卡集群的跨越3.1 数据并行、模型并行与流水线并行当你只有一张卡的时候训练很简单把数据喂进去算梯度更新参数。但当模型大到一张卡放不下或者数据多到一张卡算不完的时候就需要分布式训练。主流的并行策略有三种数据并行是最直观的每张卡复制一份完整的模型把数据切分给不同的卡各自算梯度然后同步梯度。这种方式实现简单但要求单卡能放下整个模型。PyTorch的DDP就是典型的数据并行。模型并行是把模型本身切开放到不同的卡上。比如Transformer的每一层放到不同的卡或者把一个大矩阵乘法拆开。这种方式能训更大的模型但通信开销大实现复杂。流水线并行是模型并行的一种优化把模型按层切成多个阶段不同阶段放在不同卡上数据像流水线一样依次经过各个阶段。关键是做好微批次划分让各阶段尽量不空闲。实际训练大模型时通常是三种并行混合使用业界叫“3D并行”。我刚开始接触的时候觉得这套东西太复杂后来发现核心思想就一句话在显存、计算、通信三者之间找平衡。显存不够就切模型计算不够就加数据并行通信瓶颈就调整切分策略。3.2 通信原语AllReduce、AllGather与ReduceScatter分布式训练里卡和卡之间要交换信息这些交换操作叫通信原语。最核心的三个是AllReduce每张卡都有一份数据汇总后每张卡都得到全局结果。数据并行的梯度同步就用这个。AllGather每张卡有一份数据收集后每张卡都得到所有卡的数据拼接。ReduceScatter每张卡有一份数据汇总后把结果切分给各卡。这三个原语看起来简单但组合起来能实现各种并行策略。比如ZeRO的核心思想就是用AllGather和ReduceScatter替代AllReduce把优化器状态、梯度、参数分片存储从而大幅降低单卡显存占用。通信的瓶颈通常不在带宽而在延迟和同步。我踩过的一个坑是在跨节点通信时如果网络拓扑没配好AllReduce的时间会暴涨。后来查资料才知道NCCL会根据拓扑自动选择ring或者tree算法但如果网卡和GPU的亲和性没设置好数据绕远路性能就下来了。3.3 混合精度训练省显存还能提速混合精度训练是现在大模型训练的标配。核心思路是前向和反向用FP16或BF16计算参数更新用FP32。这样既能利用低精度的高算力又能保持数值稳定性。但混合精度不是简单地把数据类型一改就完事。有几个关键点损失缩放FP16的表示范围窄梯度太小会变成0。所以要在损失上乘一个缩放因子反向传播后再除回来。主权重副本优化器里要保留一份FP32的参数副本更新时用FP32前向时转成FP16。算子兼容性不是所有算子都支持FP16有些必须用FP32框架会自动处理但你要知道哪些地方可能成为瓶颈。BF16比FP16更好用因为它的表示范围和FP32一样不需要损失缩放数值稳定性更好。现在新出的卡基本都支持BF16如果条件允许我建议优先用BF16。3.4 Checkpoint与容错训练中断了怎么办大模型训练动辄几天甚至几周中间难免遇到硬件故障、网络抖动、任务被抢占。如果没有Checkpoint机制一次中断就前功尽弃。Checkpoint的设计有几个考量频率太频繁影响训练速度太稀疏中断后损失大。通常按时间间隔或者步数间隔来设。内容至少要存模型参数、优化器状态、当前步数、数据加载器的状态。少存一样恢复后结果就可能不对。存储大模型Checkpoint动辄几百GB存到本地盘不现实一般要存到分布式文件系统或对象存储。异步保存保存Checkpoint时如果阻塞训练会浪费算力。好的框架支持异步保存先把状态拷到CPU内存再慢慢写盘。我遇到过最坑的情况是Checkpoint存了但恢复后loss对不上。排查半天发现是数据加载器的随机种子没存导致恢复后数据顺序变了。这种细节在文档里往往不会写只有踩过才知道。4. 推理与部署模型上线后的真实战场4.1 推理和训练到底差在哪很多人觉得推理比训练简单其实不然。训练关注的是吞吐量和收敛速度推理关注的是延迟、吞吐、成本三者的平衡。训练可以容忍偶尔的失败重试推理要求7x24稳定服务。训练可以用大batch提高利用率推理的请求是实时到来的batch大了延迟就高。推理场景大致分两类在线推理要求低延迟比如对话系统、推荐排序离线推理追求高吞吐比如批量图片处理、数据标注。这两类的优化方向完全不同。4.2 推理引擎的核心优化手段现在主流的推理引擎有TensorRT、ONNX Runtime、Triton等它们做的事情大同小异算子融合是把多个小算子合并成一个大算子减少kernel启动开销和显存读写。比如把卷积、偏置、激活融合成一个。这个优化在GPU上效果特别明显因为kernel启动本身就有开销。量化是把FP16或FP32的权重和激活值转成INT8甚至INT4减少显存占用和计算量。量化分训练后量化和量化感知训练前者简单但精度损失大后者需要在训练时模拟量化误差精度更好但麻烦。动态批处理是把多个请求攒成一个batch一起算提高GPU利用率。但攒多久是个问题攒太久延迟高攒太少吞吐低。通常设一个最大等待时间超时就发。KV Cache优化是针对自回归生成模型的。生成每个token时前面token的Key和Value可以缓存下来不用重复计算。但KV Cache会占显存序列越长占得越多。现在有PagedAttention之类的技术把KV Cache分页管理减少碎片。4.3 部署形态从单机到服务化小规模部署可能就是一个Python脚本加载模型起个Flask服务。但生产环境要考虑的东西多得多模型版本管理新模型上线要能灰度、能回滚。自动扩缩容流量高峰自动加实例低谷自动减。健康检查实例挂了要能自动摘除。监控告警延迟、吞吐、错误率、GPU利用率都要盯着。这些需求催生了模型服务化平台比如Triton Inference Server、TorchServe等。它们提供了统一的接口、多模型管理、动态批处理、指标暴露等功能。用这些平台能省不少事但也要理解它们的限制比如对自定义算子的支持、对特殊输入格式的处理。提示推理部署最容易忽略的是预处理和后处理。模型本身可能只占端到端延迟的30%剩下70%都在数据搬运、格式转换、业务逻辑上。优化推理之前先用profiler看清楚时间花在哪。5. 资源调度与集群运维让算力不浪费5.1 调度系统的核心挑战一个GPU集群少则几十张卡多则上千张。怎么把训练任务、推理服务、开发调试等不同需求合理地分配到这些卡上就是调度系统要解决的问题。核心挑战有几个碎片化一个任务要8张卡但集群里只有7张空闲就得等。等多久不知道可能几分钟可能几小时。亲和性有些任务需要卡在同一个节点内因为跨节点通信慢。有些任务需要特定的卡型号。优先级紧急任务要能插队低优先级任务要能被抢占。公平性多个团队共享集群时不能让一个团队占满所有资源。Kubernetes是目前最流行的调度底座但原生K8s对GPU的支持比较基础。所以有了各种扩展比如通过Device Plugin暴露GPU资源通过调度器扩展实现gang scheduling一组Pod要么都调度要么都不调度。5.2 利用率提升的常见手段GPU很贵闲置就是浪费。提升利用率的手段包括分时复用多个任务共享一张卡按时间片切换。适合开发调试场景不适合生产训练。显存超分把多个小模型塞到一张卡上各自跑各自的。推理场景常用。弹性训练任务能动态增减卡数集群有空闲就加有高优先级任务就减。这需要训练框架支持动态扩缩容。混部把推理和训练混在一起推理用不满的卡给训练用。但要注意资源隔离别互相影响。我在实际运维中发现利用率低往往不是技术问题而是流程问题。比如团队申请了卡但一直不用或者任务排队策略不合理导致大任务饿死。技术手段能解决一部分但制度和流程的优化同样重要。5.3 监控体系看得见才能管得住AI集群的监控比普通服务复杂因为要监控的层次多监控层次关键指标常用工具硬件层GPU温度、功耗、显存、利用率DCGM、nvidia-smi通信层带宽、延迟、重传率NCCL日志、IB监控框架层训练速度、loss曲线、梯度范数TensorBoard、WandB服务层请求延迟、QPS、错误率Prometheus、Grafana业务层模型效果、转化率自定义埋点监控的目的不只是发现问题还要能定位问题。比如训练变慢了是数据加载慢、通信慢、还是计算慢没有细粒度的监控就只能靠猜。6. 我踩过的那些坑与总结的经验6.1 环境配置版本兼容性是万恶之源AI Infra最烦人的事情之一就是环境配置。CUDA版本、驱动版本、框架版本、通信库版本任何一个不匹配都可能出问题。我遇到过CUDA版本和PyTorch不匹配导致无法使用GPU也遇到过NCCL版本和驱动不兼容导致多卡训练hang住。我的经验是用容器别在裸机上折腾。Docker加上NVIDIA Container Toolkit可以把环境固化下来。但容器也不是银弹GPU直通、共享内存、网络模式都有坑。最好是用官方维护的镜像作为基础别自己从零搭。6.2 性能调优先测量再优化性能问题最忌讳拍脑袋。我见过有人一上来就改batch size、改学习率结果越调越差。正确的做法是先用profiler测量找到真正的瓶颈。PyTorch有torch.profilerNVIDIA有Nsight Systems这些都是好工具。测量之后你会发现瓶颈往往不在你以为的地方。比如训练慢可能不是GPU算得慢而是数据加载的IO慢或者CPU预处理慢。6.3 故障排查从日志和指标入手分布式训练的故障排查是最考验人的。任务挂了日志可能几千行关键信息就一两行。我的习惯是先看有没有明显的报错比如OOM、NCCL timeout。看各节点的GPU利用率如果有的卡忙有的卡闲可能是负载不均。看通信日志NCCL会打印ring的建立过程如果卡在建ring可能是网络问题。看Checkpoint恢复是否正常有时候是恢复逻辑有bug。还有一个经验保留现场。任务挂了别急着重启先把日志、nvidia-smi输出、网络状态都存下来。重启之后现场就没了再想排查就难了。6.4 学习路径建议如果你刚开始接触AI Infra我建议按这个顺序来先跑通单卡训练理解模型训练的基本流程。再跑通单机多卡理解数据并行和通信。然后尝试多机多卡理解分布式训练的复杂性。接着学推理部署把训练好的模型服务化。最后学调度和运维理解集群级别的管理。每一步都要动手做光看文档是学不会的。遇到问题先自己排查实在搞不定再查资料或问人。排查的过程本身就是最好的学习。这个领域变化很快新硬件、新框架、新优化手段层出不穷。但底层的东西变化没那么快计算、存储、通信、调度这些核心问题十年二十年都不会过时。把基础打牢上层的东西学起来就快。最后分享一个我自己的习惯我会维护一个“坑本”每次遇到问题解决了就记下来包括现象、排查过程、根因、解决方案。下次再遇到类似问题翻一下坑本就能快速定位。这个习惯帮我省了大量时间也让我对系统的理解越来越深。 AI Infra学习笔记：从GPU显存到分布式训练与推理部署的体系化认知
1. 从一张白纸到体系化认知我为什么要啃下AI Infra这块硬骨头第一次听到“AI Infra”这个词的时候我正蹲在一个模型训练任务的日志前面盯着GPU利用率曲线像心电图一样忽高忽低。那时候我以为搞AI就是调参、炼丹、看loss直到有人问我一句“你这个模型从数据加载到梯度同步中间到底经过了哪些环节”我愣住了。那一刻我才意识到自己一直在用黑盒的方式做事情而对支撑整个AI系统运转的基础设施层几乎一无所知。AI Infra直译过来就是“人工智能基础设施”。它不是某一个具体的框架或者工具而是一整套让AI模型能够被高效训练、部署和运行的底层支撑体系。你可以把它理解成AI世界里的“水电煤”——没有它再漂亮的算法也只是纸面上的公式。它涵盖的范围非常广从最底层的芯片和驱动到中间的通信库、训练框架、推理引擎再到上层的资源调度、监控运维每一层都有大量的技术细节和工程取舍。我写这份学习笔记的初衷很简单市面上讲AI Infra的资料要么太散要么太浅要么一上来就堆术语把人劝退。我希望把自己从零开始摸索的过程记录下来形成一个有逻辑、有层次、能落地的知识全景。不管你是刚入行的算法工程师还是想往Infra方向转型的后端开发者或者只是对“模型到底怎么跑起来的”感到好奇的技术爱好者这份笔记都能给你一条清晰的路径。接下来的内容我会按照“计算底座—训练基础设施—推理与部署—资源调度与运维”这条主线展开每一块都会讲清楚它解决什么问题、核心技术点是什么、实际工程中怎么选型和避坑。这些都是我在实际项目中踩过坑、翻过文档、跟同行交流之后沉淀下来的东西不是教科书式的罗列。2. 计算底座GPU、显存与算力单位的那些事2.1 为什么AI Infra绕不开GPU聊AI Infra第一个绕不开的就是GPU。很多人知道GPU比CPU适合做深度学习但说不清楚为什么。简单来说CPU像是一个数学教授什么题都会做但一次只能做几道GPU像是一万个中学生每个人只会做简单的加减乘除但一万人同时动手总量就非常可观。深度学习里的矩阵乘法、卷积运算本质上就是大量简单计算的堆叠所以GPU的并行架构天然适合。但这里有个容易被忽略的点GPU并不是越贵越好关键要看你的任务是什么类型。训练大模型需要高显存带宽和大的显存容量因为模型参数、梯度、优化器状态都要放在显存里而推理任务更看重吞吐量和延迟对显存的要求相对低一些。我见过有人拿消费级显卡去训大模型结果batch size只能设成1训练速度慢到怀疑人生。这不是显卡不好是场景不匹配。2.2 显存到底被谁吃掉了显存是AI Infra里最稀缺的资源之一。很多人第一次训练模型时都会遇到“CUDA out of memory”的报错然后一脸茫然我模型才几百兆怎么24G显存就不够了这里我列一下显存的主要消耗方模型参数这是最直观的比如一个7B参数的模型如果用FP16存储大约需要14GB。梯度训练时每个参数都要存对应的梯度大小和参数一样又是14GB。优化器状态如果用Adam每个参数要存一阶矩和二阶矩又是两倍参数大小FP32下就是56GB。激活值前向传播过程中每一层的输出都要存下来供反向传播使用这部分和batch size、序列长度强相关。临时缓冲区通信、算子计算过程中的临时空间。所以一个7B模型用Adam全量微调光模型相关的状态就要80GB以上还没算激活值。这就是为什么大模型训练要用分布式、要用ZeRO、要用混合精度。理解显存的去向是做好AI Infra的第一步。2.3 算力单位的换算与实测差异买卡的时候销售会跟你说“这张卡多少TFLOPS”但实际跑起来你会发现根本达不到。这里有几个概念需要厘清精度类型说明典型用途FP32单精度浮点传统训练、科学计算FP16半精度浮点混合精度训练BF16脑浮点大模型训练首选INT88位整数推理量化INT44位整数极致推理压缩TFLOPS标称值通常是在理想条件下测出来的实际利用率受限于显存带宽、通信开销、算子效率等因素。我在实际项目中观察到训练任务能达到标称算力的30%到50%就已经算不错了。所以做容量规划的时候不要按标称值算打个对折甚至更低才靠谱。注意不同精度下的算力不能直接比较。一张卡FP16算力是FP32的几倍但如果你用FP32跑就只能享受FP32的算力。选卡之前先确定你的训练精度策略。3. 训练基础设施从单卡到千卡集群的跨越3.1 数据并行、模型并行与流水线并行当你只有一张卡的时候训练很简单把数据喂进去算梯度更新参数。但当模型大到一张卡放不下或者数据多到一张卡算不完的时候就需要分布式训练。主流的并行策略有三种数据并行是最直观的每张卡复制一份完整的模型把数据切分给不同的卡各自算梯度然后同步梯度。这种方式实现简单但要求单卡能放下整个模型。PyTorch的DDP就是典型的数据并行。模型并行是把模型本身切开放到不同的卡上。比如Transformer的每一层放到不同的卡或者把一个大矩阵乘法拆开。这种方式能训更大的模型但通信开销大实现复杂。流水线并行是模型并行的一种优化把模型按层切成多个阶段不同阶段放在不同卡上数据像流水线一样依次经过各个阶段。关键是做好微批次划分让各阶段尽量不空闲。实际训练大模型时通常是三种并行混合使用业界叫“3D并行”。我刚开始接触的时候觉得这套东西太复杂后来发现核心思想就一句话在显存、计算、通信三者之间找平衡。显存不够就切模型计算不够就加数据并行通信瓶颈就调整切分策略。3.2 通信原语AllReduce、AllGather与ReduceScatter分布式训练里卡和卡之间要交换信息这些交换操作叫通信原语。最核心的三个是AllReduce每张卡都有一份数据汇总后每张卡都得到全局结果。数据并行的梯度同步就用这个。AllGather每张卡有一份数据收集后每张卡都得到所有卡的数据拼接。ReduceScatter每张卡有一份数据汇总后把结果切分给各卡。这三个原语看起来简单但组合起来能实现各种并行策略。比如ZeRO的核心思想就是用AllGather和ReduceScatter替代AllReduce把优化器状态、梯度、参数分片存储从而大幅降低单卡显存占用。通信的瓶颈通常不在带宽而在延迟和同步。我踩过的一个坑是在跨节点通信时如果网络拓扑没配好AllReduce的时间会暴涨。后来查资料才知道NCCL会根据拓扑自动选择ring或者tree算法但如果网卡和GPU的亲和性没设置好数据绕远路性能就下来了。3.3 混合精度训练省显存还能提速混合精度训练是现在大模型训练的标配。核心思路是前向和反向用FP16或BF16计算参数更新用FP32。这样既能利用低精度的高算力又能保持数值稳定性。但混合精度不是简单地把数据类型一改就完事。有几个关键点损失缩放FP16的表示范围窄梯度太小会变成0。所以要在损失上乘一个缩放因子反向传播后再除回来。主权重副本优化器里要保留一份FP32的参数副本更新时用FP32前向时转成FP16。算子兼容性不是所有算子都支持FP16有些必须用FP32框架会自动处理但你要知道哪些地方可能成为瓶颈。BF16比FP16更好用因为它的表示范围和FP32一样不需要损失缩放数值稳定性更好。现在新出的卡基本都支持BF16如果条件允许我建议优先用BF16。3.4 Checkpoint与容错训练中断了怎么办大模型训练动辄几天甚至几周中间难免遇到硬件故障、网络抖动、任务被抢占。如果没有Checkpoint机制一次中断就前功尽弃。Checkpoint的设计有几个考量频率太频繁影响训练速度太稀疏中断后损失大。通常按时间间隔或者步数间隔来设。内容至少要存模型参数、优化器状态、当前步数、数据加载器的状态。少存一样恢复后结果就可能不对。存储大模型Checkpoint动辄几百GB存到本地盘不现实一般要存到分布式文件系统或对象存储。异步保存保存Checkpoint时如果阻塞训练会浪费算力。好的框架支持异步保存先把状态拷到CPU内存再慢慢写盘。我遇到过最坑的情况是Checkpoint存了但恢复后loss对不上。排查半天发现是数据加载器的随机种子没存导致恢复后数据顺序变了。这种细节在文档里往往不会写只有踩过才知道。4. 推理与部署模型上线后的真实战场4.1 推理和训练到底差在哪很多人觉得推理比训练简单其实不然。训练关注的是吞吐量和收敛速度推理关注的是延迟、吞吐、成本三者的平衡。训练可以容忍偶尔的失败重试推理要求7x24稳定服务。训练可以用大batch提高利用率推理的请求是实时到来的batch大了延迟就高。推理场景大致分两类在线推理要求低延迟比如对话系统、推荐排序离线推理追求高吞吐比如批量图片处理、数据标注。这两类的优化方向完全不同。4.2 推理引擎的核心优化手段现在主流的推理引擎有TensorRT、ONNX Runtime、Triton等它们做的事情大同小异算子融合是把多个小算子合并成一个大算子减少kernel启动开销和显存读写。比如把卷积、偏置、激活融合成一个。这个优化在GPU上效果特别明显因为kernel启动本身就有开销。量化是把FP16或FP32的权重和激活值转成INT8甚至INT4减少显存占用和计算量。量化分训练后量化和量化感知训练前者简单但精度损失大后者需要在训练时模拟量化误差精度更好但麻烦。动态批处理是把多个请求攒成一个batch一起算提高GPU利用率。但攒多久是个问题攒太久延迟高攒太少吞吐低。通常设一个最大等待时间超时就发。KV Cache优化是针对自回归生成模型的。生成每个token时前面token的Key和Value可以缓存下来不用重复计算。但KV Cache会占显存序列越长占得越多。现在有PagedAttention之类的技术把KV Cache分页管理减少碎片。4.3 部署形态从单机到服务化小规模部署可能就是一个Python脚本加载模型起个Flask服务。但生产环境要考虑的东西多得多模型版本管理新模型上线要能灰度、能回滚。自动扩缩容流量高峰自动加实例低谷自动减。健康检查实例挂了要能自动摘除。监控告警延迟、吞吐、错误率、GPU利用率都要盯着。这些需求催生了模型服务化平台比如Triton Inference Server、TorchServe等。它们提供了统一的接口、多模型管理、动态批处理、指标暴露等功能。用这些平台能省不少事但也要理解它们的限制比如对自定义算子的支持、对特殊输入格式的处理。提示推理部署最容易忽略的是预处理和后处理。模型本身可能只占端到端延迟的30%剩下70%都在数据搬运、格式转换、业务逻辑上。优化推理之前先用profiler看清楚时间花在哪。5. 资源调度与集群运维让算力不浪费5.1 调度系统的核心挑战一个GPU集群少则几十张卡多则上千张。怎么把训练任务、推理服务、开发调试等不同需求合理地分配到这些卡上就是调度系统要解决的问题。核心挑战有几个碎片化一个任务要8张卡但集群里只有7张空闲就得等。等多久不知道可能几分钟可能几小时。亲和性有些任务需要卡在同一个节点内因为跨节点通信慢。有些任务需要特定的卡型号。优先级紧急任务要能插队低优先级任务要能被抢占。公平性多个团队共享集群时不能让一个团队占满所有资源。Kubernetes是目前最流行的调度底座但原生K8s对GPU的支持比较基础。所以有了各种扩展比如通过Device Plugin暴露GPU资源通过调度器扩展实现gang scheduling一组Pod要么都调度要么都不调度。5.2 利用率提升的常见手段GPU很贵闲置就是浪费。提升利用率的手段包括分时复用多个任务共享一张卡按时间片切换。适合开发调试场景不适合生产训练。显存超分把多个小模型塞到一张卡上各自跑各自的。推理场景常用。弹性训练任务能动态增减卡数集群有空闲就加有高优先级任务就减。这需要训练框架支持动态扩缩容。混部把推理和训练混在一起推理用不满的卡给训练用。但要注意资源隔离别互相影响。我在实际运维中发现利用率低往往不是技术问题而是流程问题。比如团队申请了卡但一直不用或者任务排队策略不合理导致大任务饿死。技术手段能解决一部分但制度和流程的优化同样重要。5.3 监控体系看得见才能管得住AI集群的监控比普通服务复杂因为要监控的层次多监控层次关键指标常用工具硬件层GPU温度、功耗、显存、利用率DCGM、nvidia-smi通信层带宽、延迟、重传率NCCL日志、IB监控框架层训练速度、loss曲线、梯度范数TensorBoard、WandB服务层请求延迟、QPS、错误率Prometheus、Grafana业务层模型效果、转化率自定义埋点监控的目的不只是发现问题还要能定位问题。比如训练变慢了是数据加载慢、通信慢、还是计算慢没有细粒度的监控就只能靠猜。6. 我踩过的那些坑与总结的经验6.1 环境配置版本兼容性是万恶之源AI Infra最烦人的事情之一就是环境配置。CUDA版本、驱动版本、框架版本、通信库版本任何一个不匹配都可能出问题。我遇到过CUDA版本和PyTorch不匹配导致无法使用GPU也遇到过NCCL版本和驱动不兼容导致多卡训练hang住。我的经验是用容器别在裸机上折腾。Docker加上NVIDIA Container Toolkit可以把环境固化下来。但容器也不是银弹GPU直通、共享内存、网络模式都有坑。最好是用官方维护的镜像作为基础别自己从零搭。6.2 性能调优先测量再优化性能问题最忌讳拍脑袋。我见过有人一上来就改batch size、改学习率结果越调越差。正确的做法是先用profiler测量找到真正的瓶颈。PyTorch有torch.profilerNVIDIA有Nsight Systems这些都是好工具。测量之后你会发现瓶颈往往不在你以为的地方。比如训练慢可能不是GPU算得慢而是数据加载的IO慢或者CPU预处理慢。6.3 故障排查从日志和指标入手分布式训练的故障排查是最考验人的。任务挂了日志可能几千行关键信息就一两行。我的习惯是先看有没有明显的报错比如OOM、NCCL timeout。看各节点的GPU利用率如果有的卡忙有的卡闲可能是负载不均。看通信日志NCCL会打印ring的建立过程如果卡在建ring可能是网络问题。看Checkpoint恢复是否正常有时候是恢复逻辑有bug。还有一个经验保留现场。任务挂了别急着重启先把日志、nvidia-smi输出、网络状态都存下来。重启之后现场就没了再想排查就难了。6.4 学习路径建议如果你刚开始接触AI Infra我建议按这个顺序来先跑通单卡训练理解模型训练的基本流程。再跑通单机多卡理解数据并行和通信。然后尝试多机多卡理解分布式训练的复杂性。接着学推理部署把训练好的模型服务化。最后学调度和运维理解集群级别的管理。每一步都要动手做光看文档是学不会的。遇到问题先自己排查实在搞不定再查资料或问人。排查的过程本身就是最好的学习。这个领域变化很快新硬件、新框架、新优化手段层出不穷。但底层的东西变化没那么快计算、存储、通信、调度这些核心问题十年二十年都不会过时。把基础打牢上层的东西学起来就快。最后分享一个我自己的习惯我会维护一个“坑本”每次遇到问题解决了就记下来包括现象、排查过程、根因、解决方案。下次再遇到类似问题翻一下坑本就能快速定位。这个习惯帮我省了大量时间也让我对系统的理解越来越深。