做 AI 越久越觉得算法只是冰山一角。以前我写模型最关心的是结构设计和指标刷分后来真正跑训练、做部署才发现模型代码只是中间很小的一环。数据要喂进来算力要调度起来分布式训练要稳定跑几天不崩推理服务要扛得住请求波动一整套承载这些能力的基础设施圈里现在统称 AI Infra。这份学习笔记不打算堆名词而是想把我自己从“只会写模型”到“能搭起一套可用的 AI 基础设施”过程中真正搞懂的那些知识点、踩过的坑、反复确认过的判断依据重新串一遍。适合刚接触 AI 工程化、准备转做机器学习平台或算法工程的读者也适合那些已经在搞训练和推理、但一直觉得知识很零散的人。看完之后你至少能画出自己的 AI Infra 全景图知道每一层在解决什么问题出了问题该往哪一层去找原因。1. AI Infra 到底在解决什么问题1.1 从算法到可用服务之间的“最后一公里”很多人在学习阶段都跑过模型。笔记本上加载一个小网络喂一批数据看着 loss 下降觉得训练不过如此。等你真的把一个像样规模的模型放进真实环境问题立刻不一样了数据放在远端存储里每次读取都慢得离谱显卡看着很贵实际利用率不到三成训练到一半节点挂了几天的进度白费好不容易训完线上推理请求一上来延迟直接飙到不可接受。这些问题的共同点是它们都不在模型代码本身而在于模型周围的支撑系统。我用一个厨房的类比来理解这件事算法是菜谱写清楚了多少食材、什么步骤、多少火候AI Infra 则是厨房里的基础设施——水源、电力、锅具、食材供应链、传菜通道。菜谱再高级厨房跟不上端出来的菜照样砸招牌。放到实际场景里AI Infra 解决的就是两个核心问题一是让训练过程在有限资源下稳定高效地跑完二是让训练好的模型能以可接受的延迟和成本对外提供服务。前者对应训练基础设施后者对应推理基础设施中间还夹着数据、存储、调度和可观测性哪一环掉链子整条链路都受影响。1.2 知识全景图应该怎么画我自己的学习过程里画过很多版本的知识地图后来发现最稳妥的方式是按层次拆底层是硬件资源中间是系统软件上面是平台与工具再往上是具体的 AI 应用服务。层次核心内容我重点关注什么硬件资源层加速卡、CPU、内存、网络设备、存储系统算力、显存、带宽、IO 能力是否匹配系统软件层驱动、运行时、分布式框架、调度器、推理引擎资源抽象、任务编排、训练/推理效率平台工具层实验管理、模型仓库、CI/CD、监控告警从“能跑”到“稳定可重复地跑”应用服务层模型服务、在线推理、AIGC 应用延迟、吞吐、成本、稳定性这个分层并不是严格隔离的。实际排查问题的时候你会发现性能瓶颈经常跨越多个层次。比如某次训练吞吐上不去起初怀疑显卡不够查到最后发现是存储端的元数据读取太慢数据根本喂不进来。又比如推理接口偶发超时表象是模型服务不够快实际是上游排队策略没做好再加上网络超时设置太短。所以画全景图最大的价值不是背下每个组件名字而是建立一种“全链路视野”当某个指标异常时你能意识到这和数据、计算、通信、存储、调度都可能有关系而不是一头扎进最直观的那一层。2. 硬件层算力、网络、存储的三角关系2.1 算力单元怎么选别只看“浮点峰值”一个数硬件层最容易让人犯的错是只看加速卡的浮点算力规格。真实场景里“纸面参数”和“实际跑到多少”往往是两回事。我在学习时给自己列了一个选型检查清单包含五个关键指标峰值算力、显存容量、显存带宽、卡间互联能力、软件生态成熟度。峰值算力要看具体精度。训练大模型时通常关注 BF16/FP16 下的算力推理场景则经常用 INT8 甚至更低的精度来换吞吐。显存容量决定了一个模型能不能塞进单卡也决定了 batch size 能开多大显存不够很多时候不是换卡能解决的而是要考虑模型并行或量化。显存带宽容易被新手忽略通俗讲就是显存和计算单元之间“搬数据”的速度。很多算子看起来计算量不大但瓶颈就卡在数据搬运上带宽不足会导致 GPU 空转等数据。卡间互联能力决定了多卡协同的效率训练类负载尤其敏感如果卡间带宽低数据并行做到后期反而会越跑越慢。软件生态则决定了你用起来顺不顺手框架支持、算子覆盖、调试工具、驱动稳定性都算在里面调优困难带来的隐性成本比硬件差价贵得多。训练和推理选型思路还有明显差异。训练追求“把大模型装进显存 尽快算完”所以通常优先考虑大显存和互联带宽推理追求“稳定的低延迟 高吞吐 可控成本”所以往往愿意牺牲一点精度换取更小的显存占用和更低的单请求成本。我见过不少团队把训练卡直接拿去做推理结果吞吐提不上去成本还高得吓人。正确做法是按工作负载分开评估哪怕初期共用资源也要在设计阶段就想清楚隔离策略。2.2 网络从一台机器到一群机器的分水岭如果说单卡训练是开一辆车那分布式训练就是组织一支车队。车队能不能跑起来看的不是每辆车多快而是车队之间通信是否顺畅。AI Infra 里的网络主要管的就是节点和节点、卡和卡之间怎么交换数据。分布式训练里最常见的通信场景是梯度同步每个卡算完自己那一批数据后需要把梯度汇总起来更新模型参数。想想看如果模型有 10 亿个参数每个参数用 2 字节表示一次梯度同步就有约 2GB 数据在集群里流动。网速不够训练就变成了“大部分时间在等数据搬完”。这也是为什么现在高性能 AI 集群都很看重 RDMA 这类低延迟网络技术——它绕过了传统协议栈的大量软件开销让数据可以更快地从一张卡的显存搬到另一张卡的显存。跨机通信还会涉及拓扑结构比如机架内和跨机架的带宽往往差好几倍分布式算法的设计如果没考虑拓扑通信效率就会大打折扣。我给自己的判断原则很朴素做单机多卡可以先不纠结网络一旦计划上多机分布式网络方案的预算和精力投入必须跟上否则买了再贵的卡集群也跑不出线性扩展的效果。这不是危言耸听我见过有团队把几十张卡堆在一起训练吞吐不仅没翻倍反而因为通信开销和资源竞争变得更慢最后定位到的问题就是网络拥塞和拓扑设计不合理。2.3 存储给数据一个合理的分层“仓库”数据也是硬件基础设施里的大头。很多模型跑不好不是算力不够而是数据加载管线把整个训练拖住了。AI 数据通常要分温冷热来存放最热的数据是当前训练频繁读取的样本最好放在本地高速盘或内存缓存里温数据是规模很大的训练集适合放在能高并发读的并行文件系统中冷数据则是历史数据、备份和归档放到容量大、成本低的对象存储里就够用了。我学到的一个重要经验是数据加载优化永远应该发生在扩大模型规模之前。先用性能分析工具看一眼训练循环里数据等待的占比。如果 GPU 经常闲着等数据那么不管换多快的卡都没用。常见的优化手段包括数据预取、IO 直通、格式统一化以及用分布式缓存缓解热点数据的高频读取。还有一个容易被忽略的点是大模型的 checkpoint 存储。多机训练时每过一段时间就要保存一次模型状态如果存储写入速度太慢checkpoint 过程会阻塞整个训练更夸张的是集群规模大的时候checkpoint 存储本身就可能成为性能瓶颈。对这些场景简单把 checkpoint 丢到普通盘上是不行的需要专门规划高带宽的存储空间和写入策略比如异步保存、分片写入、只保存可恢复的最小状态集。3. 软件层调度、框架、推理引擎3.1 训练侧分布式训练的基本功与选型逻辑深入学习 AI Infra绕不开分布式训练。我在学习时把它分成三个台阶数据并行、模型并行、混合并行。数据并行最容易理解每张卡上都放一份完整的模型训练数据切分成多份每张卡分别算自己的梯度最后汇总更新。它的优点是简单缺点是模型大到一张卡放不下时就直接失效。模型并行则是把模型的不同部分切到不同卡上每张卡只负责一部分适合解决“显存放不下”的问题。张量并行是一种模型并行把某一层的矩阵运算切到多卡上协同完成流水线并行是另一种把网络按层划分成段不同段在不同卡上执行数据像流水线一样流过各段。实际工程里很少只用一种并行策略而是组合起来用比如先张量并行再数据并行甚至多层嵌套。选型逻辑我总结成一句话能数据并行尽量数据并行显存放不下再考虑模型并行模型并行优先考虑通信代价小的方案。因为模型并行往往意味着更多的通信同步如果卡间互联不行训练速度会很难看。另外一个很实用的概念是混合精度训练。简单说就是用 FP16/BF16 做大部分计算用 FP32 做部分敏感操作既省显存又快。初学者常常忽略精度溢出问题直接开混合精度训练导致训练不稳定然后怪框架不行。实际上大多数情况下只要做好梯度缩放和关键层精度保持混合精度是既能提速度又省显存的高收益操作。3.2 推理侧模型部署本质上是个“排队系统”训练和推理的思维模式很不一样。训练关心的是吞吐和收敛速度推理关心的是延迟、吞吐、成本和稳定性。把模型部署上线后它就是一个实时服务系统请求随时会来延迟必须可控。这让我意识到推理优化本质上是在和一个排队系统打交道。推理的核心指标是 P99 延迟也就是 99% 的请求在多少毫秒内完成。很多人只看平均延迟结果线上偶尔抖动一下平均延迟没变用户体验却已经崩了。为了降低 P99你需要关注几个关键点一是排队环节如果请求在服务入口堆积后续优化模型速度都没用二是推理本身的算子效率比如有没有做图优化、算子融合、推理专用内核三是显存带宽推理阶段大量操作是“读权重 算注意力”很多时候带宽比算力更稀缺四是动态批处理把同时到的多个请求攒成一批处理可以大幅提升吞吐但要注意不能让某个请求等太久需要设计合理的最大等待时间。量化也是推理优化里常见的手段。把模型权重从 FP16 压到 INT8 或更低模型体积变小、推理更快代价是精度损失。我自己的经验是动手量化之前先建立好评测集和可量化的指标否则你根本说不清精度损失到底能不能接受。此外大模型推理中有一个很关键的概念是 KV Cache也就是缓存历史 token 对应的中间状态避免每生成一个 token 都把整段历史重新算一遍。KV Cache 非常吃显存也是很多大模型服务显存爆掉的重要原因理解它就理解了大模型部署的核心成本结构。3.3 资源调度与编排把算力变成“可分配的公共资源”单机跑模型不需要调度多用户共用集群就必须有调度。为什么需要容器和容器编排系统因为不同任务对算力、内存、网络、存储的需求都不一样而且环境依赖容易冲突。容器把环境隔离问题解决了编排系统则负责“谁跑在哪些资源上、什么时候跑、资源不够时怎么排队”。AI 场景和普通微服务场景对调度的要求还有差异。普通服务追求快速扩容AI 训练往往需要一整组 GPU 同时到位才能启动如果只分到一半任务就只能干等。这在大集群里是个常见低效点明明 GPU 够多但因为调度策略不合理部分任务占着资源等配对整体利用率上不去。所以现在很多平台会做 GPU 共享、虚拟化、细粒度切分把一张卡的算力分给多个小需求减少碎片化浪费。同时还会设计优先级和抢占策略让高优任务能及时拿到资源同时避免低优任务一直饿死。如果把这部分抽象成配置其实核心就是资源声明和调度策略。比如下面这段描述就是让任务声明自己需要多少算力资源调度器据此分配resources: requests: cpu: 8 memory: 64Gi gpu: 4 limits: gpu: 4看起来简单实际难点在于怎么让“请求的资源”和“真实负载特征”匹配上。不少团队在调度层做了定制根据任务预估时长、显存需求、网络拓扑偏好等因素决定放置位置。学习这部分时最好带着一个场景去理解如果给你 100 张卡、三个团队、几十个任务你怎么制定一套分配规则让整体利用率最高、等待时间最短。这个思考过程比记住任何配置项都有价值。4. 数据与工具链容易被忽视的另一半4.1 数据管线为什么训练老是“卡”在读取上模型训练里一个常见怪现象显卡利用率低但 CPU 居高不下。十有八九是数据管线没做好。数据管线是从存储系统读取原始数据、做解码、预处理、增强、打包成 batch再送到 GPU 的一整套流程。任何一个环节慢GPU 都会饿肚子。很多新人踩过小文件地狱的坑几百万张小图片每张单独一个文件存在磁盘上每次读取都要经过一次元数据操作速度极慢。解决的思路通常是两大方向一是把大量小文件打包成少量大文件让读取方式更适配存储系统二是做多级缓存让高频数据尽量留在内存或本地高速盘里。另一个常见问题是数据增强算得太慢预处理阶段成了瓶颈这时候一般会把预处理放到独立进程里并行执行提前把增强后的数据准备好训练时候直接从队列里取。我的建议是任何一次大数据集训练先做一次简单的数据加载基准测试。单独跑一遍数据迭代看看每秒能产出多少个 batch。如果数据迭代速度远低于训练时间先解决数据再上大规模训练否则后面 Debug 会让你怀疑人生。这个过程花几个小时但能省下几天的浪费时间。4.2 MLOps 工具链让实验“可复现、可追踪、可回滚”当模型开始迭代训练不再是一次性任务而是一条流水线。实验管理负责记录每次训练的超参、代码版本、数据版本和指标结果模型仓库负责管理训练好的模型包和版本CI/CD 负责把代码变更自动变成训练任务或部署任务监控告警则负责持续观察线上服务的健康状态。我踩过的一个大坑是不重视实验记录。曾经有一段时期我改了好几个版本的数据预处理逻辑却只改了代码没有记录数据版本结果模型指标提升后完全说不清是数据变了还是模型结构变了。后来我痛苦地养成一个习惯每个实验运行前先把代码 commit 号、数据快照、关键超参全部打成一个固定的实验环境跑完后强制登记结果。这个习惯看起来很笨但它是做任何严肃 ML 工程的起点。工具链不需要一步到位。我建议的最小闭环是实验管理 模型版本管理 基础监控。先把“跑出来的结果可追踪”这件事做到位再逐步加自动化训练流水线和弹性发布策略。工具多了反而容易变成摆设关键是把数据流动串起来代码变更产生实验实验产生模型版本模型版本发布成服务服务产生监控指标指标再反馈到下一轮实验。5. 学习路线与实操建议5.1 从单机到集群按五个阶段走学习 AI Infra 最容易劝退的是想一步到位上来就搭一个平台级的东西。我的建议是按阶段走每个阶段都设定一个“验收标准”过了再往下走。阶段一是单卡训练跑通一个小模型。注意不只是训练完成还要学会看资源利用率和性能数据。阶段二是数据管线优化。把一个真实数据集在小模型上跑熟观察数据读取和 GPU 等待的比例尝试不同预处理策略并量化前后差异。阶段三是分布式训练。先把数据并行跑通再逐步接触模型并行和混合并行重点关注扩展效率。阶段四是推理部署。训练好模型后设计一个 HTTP 服务接口测延迟和吞吐尝试批处理和量化等优化。阶段五是调度和平台化。把多个训练任务和推理服务放进同一个资源池设计排队和优先级策略思考利用率与公平性之间的平衡。这个顺序背后的逻辑是层层递进的不先理解单卡训练的过程就没法判断分布式训练中哪些开销是正常的不理解数据管线的瓶颈就很容易把存储问题误判成算力问题不理解训练就不可能做好推理部署。每一步的核心都是建立“用数据判断问题”而不是“凭感觉猜问题”的习惯。5.2 预算有限时练什么最有性价比不是人人都有一整机柜的 GPU。我练手时用的是能租到的单机多卡或小规模集群哪怕只有两张卡也能把很多核心概念跑明白。单机双卡可以练的东西很多跑一个需要大显存的模型试出数据并行和模型并行的显存差异观察两张卡的通信流量理解梯度同步的开销把推理服务部署起来用压测工具打满它看 P99 延迟的变化还可以模拟一个任务排队场景体会调度器的行为。如果连 GPU 都没有也不是不能学。资源调度、存储分层、MLOps 工具链、推理服务的部分内容都可以用纯 CPU 环境或几台普通云主机来练。关键是不要停留在“看书”的层面AI Infra 是一门实践性很强的领域很多经验必须亲手操作过才知道。哪怕只有一个很简陋的实验环境只要有测量、有对比、有反思学到的东西比看一百篇文章都管用。5.3 进阶方向往哪走才算真的“通了”基础链路跑通之后有几个方向值得深入。一个是异构调度管理混合架构的计算资源让任务能聪明地选择最合适的硬件。另一个是自动并行让框架根据模型结构和集群拓扑自动决定采用哪种并行策略减少人工参数调整。还有一个是大规模集群的稳定性工程包括故障恢复、容灾、自动扩缩容和成本控制。以及模型服务的高性能优化比如更优的批处理策略、推测解码、结构化输出等方向。进阶阶段我开始特别关注“全链路可观测性”。以前学 AI Infra总以为每个组件单独看都没问题整体就没问题。后来发现分布式系统里的故障和性能问题经常是跨组件、跨层次的。没有统一的指标、日志、链路追踪体系排查问题就像在黑屋子里找一根掉落的针。可观测性是连接所有基础设施层的“仪表盘”也是判断你系统健康度的第一依赖。6. 常见问题与排查技巧实录6.1 训练阶段最常见的四个问题我在学习和带项目过程中反复遇到四类问题几乎适用于所有训练任务。显存爆炸是最容易遇到的。报错说 OOM第一反应不该是去买更多显存而是先检查 batch size、模型并行设置、混合精度开关。很多显存问题通过降精度、换梯度策略、开显存优化就能解决。训练吞吐低是第二类问题。我排查的一贯顺序是先看 GPU 利用率再看数据加载是否有阻塞再看通信占比。如果 GPU 利用率低多半是数据没跟上如果利用率还可以但训练速度仍慢就要怀疑计算效率和通信效率。第三类是训练不稳定loss 突然变成 NaN 或大幅抖动常见原因是学习率过大、数据存在异常样本、混合精度溢出。第四类是训练中断节点故障或网络抖动导致任务失败。处理思路是断点续训、定时 checkpoint、以及保证存储写入的可靠性。现象可能原因第一步排查常见解法显存 OOMbatch 太大 / 模型并行缺失 / 精度浪费查看当前显存分配占比减小 batch、开启混合精度、切分模型吞吐低数据加载慢 / 通信开销大分别观察 GPU 利用率和 CPU 等待预取数据、优化网络、调整并行策略loss 异常学习率过高 / 精度溢出 / 脏数据检查训练日志里的 loss 曲线和数值降低学习率、开启梯度缩放、清洗数据训练中断节点故障 / 网络抖动查看任务日志和硬件告警定时保存 checkpoint、做节点自动替换6.2 推理延迟高的排查顺序推理接口变慢先别急着改模型。我的排查顺序是第一步排除“请求根本没到服务”的可能比如网络、DNS、负载均衡第二步看服务的排队情况请求是不是在队列里堆积了如果是说明容量不够或并发控制不合理第三步看单次推理耗时借助监控拆解 prefill 和生成阶段分别花了多久第四步再去看是不是模型本身太重该量化还是该剪枝。有一次我负责的服务 P99 一直下不来直觉以为是模型太大、推理太慢。后来拆开看发现单次推理很快但请求排队时间占了总延迟的绝大部分。问题出在入口线程池太小很多请求就是在排队等线程。我不改任何模型逻辑只调整了并发和队列策略P99 直接降了一截。这类经验说明一个道理在 AI Infra 里很多瓶颈不在 AI 本身而在基础设施的细节里。6.3 我总结的六个避坑习惯首先是不要只看平均值。训练看平均吞吐、推理看平均延迟都会掩盖大量问题。要习惯看分布和长尾。第二是不要跳过监控直接调优。没有监控就跑优化等于蒙眼开车。第三是不要一上来就做大改动每次只改一个变量记录前后差异。第四是不要把 GPU 利用率当成唯一指标。利用率高也可能是在低效地在计算。第五是不要忽略存储和网络它们常常才是隐藏瓶颈。第六是永远给故障留预案。训练跑三天不出问题不代表第四天不会出checkpoint 要勤发布要能回滚。这些习惯听起来很基础但每一条背后都有真实教训。我是在一次次把线上问题折腾到凌晨之后才真正把它们刻进脑子里的。最后分享一个很受用的心态AI Infra 不像算法那样有一个“改结构就能刷点”的即时反馈它的反馈周期很长而且很多优化只有到大规模场景下才能体现价值。刚开始学的时候你可能做了很多事却看不到什么明显收益这种时候别急着怀疑方向。把基础链路一步步跑扎实把数据和指标体系建起来等规模上来之后你会发现自己前期积累的判断力比任何单一技巧都值钱。
