1. 为什么我要系统梳理 AI Infra 这张知识地图过去两年我身边不少做后端、做算法、做数据平台的朋友都在往同一个方向靠——AI Infra。有人是从传统微服务转过来的有人是从大数据平台转过来的也有人本来就是做训练框架的。大家遇到的问题出奇地一致知识点太散今天看分布式训练明天看推理加速后天又被拉去搞 GPU 调度学了一圈发现脑子里全是碎片串不成一条线。我自己也踩过这个坑。最开始我以为 AI Infra 就是“会配环境、会跑训练脚本”后来真正参与到几个模拟项目里才发现这个领域本质上是一套完整的工程体系它要解决的是“如何让算力高效、稳定、低成本地服务于模型的全生命周期”。从数据准备、训练、微调、压缩、部署到线上推理每一段都有独立的工程挑战而它们之间又强耦合。你只懂其中一块遇到跨层问题就会卡住。所以这篇笔记不是某一项技术的教程而是我给自己画的一张“AI Infra 知识全景图”。我会把整个领域拆成几个核心板块讲清楚每个板块在解决什么问题、关键技术点是什么、它们之间怎么衔接以及我在实际动手时总结出来的经验和坑。适合谁看如果你是刚转入这个方向的工程师它能帮你快速建立全局认知避免东一榔头西一棒子如果你已经做了一段时间它能帮你查漏补缺看看哪块能力还有短板。全文我会尽量说人话复杂的地方用类比和实际场景来解释能抄作业的地方我直接给方法和参数。2. AI Infra 的整体版图与分层逻辑2.1 一张图看懂 AI Infra 到底包含什么我习惯把 AI Infra 分成五层来看从下往上依次是硬件与驱动层、集群与资源调度层、训练与微调框架层、推理与服务平台层、可观测与运维层。这五层不是严格隔离的而是层层依赖、互相影响。硬件与驱动层是最底层的物理基础包括 GPU、NPU、高速互联比如 NVLink、RDMA、存储和网络。这一层决定了算力的上限也决定了很多上层优化的边界。集群与资源调度层负责把成百上千张卡组织起来做任务排队、资源分配、故障隔离典型的就是各种调度系统和容器编排。训练与微调框架层是算法工程师最常打交道的部分涵盖数据并行、张量并行、流水并行、混合精度、梯度累积等。推理与服务平台层关注的是模型上线后的吞吐、延迟和成本涉及量化、蒸馏、批处理、KV Cache 管理等。可观测与运维层则是贯穿始终的“眼睛”负责监控、日志、追踪和告警。为什么我要强调这个分层因为很多初学者一上来就扎进训练框架的细节结果遇到显存不够、通信瓶颈、任务排队慢的问题时根本不知道问题出在哪一层。有了分层视角你就能快速定位是硬件带宽不够还是调度策略不合理还是框架配置有问题。2.2 各层之间的依赖关系与常见误区这五层之间存在明显的“木桶效应”。我见过一个很典型的例子某团队花大价钱买了高带宽互联的机器训练框架也用了最先进的并行策略但实际吞吐始终上不去。排查后发现是数据加载层成了瓶颈——存储的读取速度跟不上 GPU 的消费速度GPU 大量时间在等数据。这就是典型的“上层优化被下层拖累”。另一个常见误区是只关注单机性能忽略集群规模下的通信开销。单机八卡跑得好好的配置扩展到几十台机器后通信占比可能从 5% 飙升到 40% 以上。这时候如果还用原来的并行策略效率会断崖式下跌。所以我在做任何方案设计时都会先问三个问题数据从哪来、算力怎么组织、结果怎么出去。这三个问题分别对应数据链路、调度链路和服务链路任何一条断了整体就废了。提示不要孤立地学某一层技术。每学一个知识点都问自己“它在整个链路里的位置是什么、上下游是谁”这样知识才能连成网。3. 训练侧核心知识拆解与实操要点3.1 分布式训练并行策略怎么选才不踩坑分布式训练是 AI Infra 里最硬核也最容易出问题的部分。核心的并行策略有三种数据并行DP、张量并行TP、流水并行PP再加上近年流行的专家并行EP和序列并行SP。它们解决的是不同维度的问题。数据并行是把同一个模型复制到多张卡上每张卡处理不同的数据批次然后同步梯度。它实现简单适合模型能单卡放下、但数据量大的场景。缺点是每步都要做梯度全量通信卡越多通信开销越大。张量并行是把单个算子比如矩阵乘切分到多张卡上适合单层参数就很大的模型。它的通信发生在层内频率高、对带宽要求极高通常只在单机内做。流水并行是把模型按层切成若干段不同段放在不同卡上像流水线一样处理微批次。它能跨机扩展但会引入“气泡”bubble即部分卡在等待利用率下降。实际项目中几乎不会只用一种并行而是组合使用。我常用的一个经验法则是单机内优先用张量并行跨机用流水并行最外层套数据并行。比如一个百亿参数模型可以配置成“单机 8 卡张量并行 4 台机器流水并行 若干组数据并行”。这个组合不是拍脑袋来的而是根据模型参数量、单卡显存、互联带宽三个约束反推出来的。具体怎么算假设模型有 P 亿参数用混合精度训练每个参数约占 16 字节含梯度、优化器状态会更多这里简化。单卡显存为 M GB除去激活值和临时缓冲能放模型的空间大约是 0.6M。那么单卡能承载的参数量上限约为 0.6M / 16 字节。如果 P 超过这个值就必须切分。切分时优先考虑张量并行因为它的通信在机内最快如果单机切完还不够再上流水并行。3.2 混合精度与显存优化省显存的几个实用手段显存是训练中最稀缺的资源。除了并行切分还有几个立竿见影的优化手段。混合精度训练是最基础的前向和反向用 FP16 或 BF16 计算主权重用 FP32 保存。这样显存占用能降到纯 FP32 的一半左右速度也更快。BF16 比 FP16 动态范围更大不容易溢出现在更推荐。梯度检查点Gradient Checkpointing是另一个神器。它牺牲计算换显存前向时不保存所有中间激活值只保存部分检查点反向时重新计算缺失的激活。实测下来显存能省 50% 到 70%代价是训练速度慢 20% 到 30%。对于显存吃紧但算力有余的场景非常划算。ZeRO 系列优化Zero Redundancy Optimizer则是从优化器状态、梯度、参数三个层面做分片把原本每张卡都存一份的数据分散到各卡上。ZeRO-1 只分片优化器状态ZeRO-2 加上梯度ZeRO-3 连参数也分片。级别越高省得越多但通信也越多。我的经验是中小规模集群用 ZeRO-2 性价比最高超大模型才上 ZeRO-3。注意开启梯度检查点后如果模型里有随机性操作如 Dropout要确保反向重计算时随机种子一致否则梯度会出错。这个坑我踩过一次loss 一直不收敛排查了很久才发现是随机性没对齐。3.3 数据管道被低估的性能杀手很多人把注意力全放在模型和并行上忽略了数据管道。实际上数据加载慢是训练吞吐上不去的头号原因之一。一个高效的数据管道要做到预取、并行读取、在线增强、格式友好。预取是指当前批次在计算时后台已经在准备下一批数据。并行读取是用多个工作进程同时从存储读数据。在线增强是在 CPU 上做图像裁剪、翻转等操作不占用 GPU。格式友好是指把原始数据转成顺序读取效率高的格式比如把大量小文件打包成大文件或者用列式存储。我做过一个对比测试同样的模型和硬件数据管道优化前后GPU 利用率从 55% 提升到 92%训练时间缩短了近 40%。所以如果你发现 GPU 利用率长期低于 80%第一件事就是查数据管道。4. 推理与服务侧的关键技术4.1 推理加速量化、蒸馏与批处理模型训练完只是第一步怎么高效地服务线上请求才是真正的考验。推理侧的核心指标是吞吐量、延迟和成本三者往往互相制约。量化是把模型权重和激活从高精度降到低精度比如 INT8 或 INT4。它直接减少显存占用和计算量速度提升明显。但量化会带来精度损失需要做校准。我通常的做法是先做训练后量化PTQ用一小批代表性数据校准如果精度掉得太多再考虑量化感知训练QAT。知识蒸馏是用大模型教小模型让小模型学到接近大模型的效果。它适合对延迟极敏感的场景比如移动端或高并发接口。蒸馏的关键是设计好损失函数通常结合软标签损失和硬标签损失。批处理Batching是提升吞吐最直接的手段。把多个请求攒成一批一起推理能充分利用 GPU 的并行能力。但批太大会增加延迟需要根据业务容忍度找平衡点。动态批处理是常见方案设定一个最大等待时间攒够或超时就走。4.2 KV Cache 管理与长上下文优化大模型推理有个特殊问题自回归生成时每生成一个 token 都要用到之前所有 token 的 Key 和 Value这就是 KV Cache。上下文越长KV Cache 越大显存压力越大。优化 KV Cache 有几个方向。分页管理借鉴操作系统的虚拟内存思想把 KV Cache 切成固定大小的块按需分配减少碎片。量化 KV Cache把缓存也降到 INT8省一半显存。稀疏化是只保留重要的 KV 对丢弃不重要的。前缀共享是多个请求如果有相同的前缀比如相同的系统提示词可以共享这部分 KV Cache。长上下文场景下这些优化能带来数倍的吞吐提升。我在一个模拟项目里把 KV Cache 做分页加 INT8 量化后同样显存能支持的并发请求数翻了近三倍。4.3 服务编排从单模型到多模型流水线真实业务往往不是单个模型而是多个模型串成流水线。比如一个问答系统可能先过意图识别模型再过检索模型最后过大模型生成。这就涉及服务编排怎么调度这些模型、怎么传递中间结果、怎么保证整体延迟可控。我常用的方案是用一个轻量级的编排层把每个模型封装成独立服务通过消息队列或 RPC 串联。编排层负责超时控制、重试、降级。关键是要做异步化能并行的步骤并行能流式返回的流式返回避免用户干等。5. 资源调度与集群运维实战5.1 GPU 调度如何提高利用率GPU 很贵利用率上不去就是烧钱。提高利用率的核心是减少空闲和碎片。空闲通常来自任务排队、数据等待、故障恢复。碎片来自不同任务对资源的需求不一致导致大块资源被切碎后无法满足大任务。我的做法是分级队列 抢占 弹性伸缩。把任务按优先级分队列高优先级可以抢占低优先级的资源。弹性伸缩是根据负载动态增减节点。另外把训练任务和推理任务混部也能提升整体利用率因为训练对延迟不敏感可以填推理的低谷。5.2 故障处理训练中断了怎么办大规模训练跑几天几夜硬件故障是常态。关键是要做到快速检测、自动恢复、断点续训。检测靠心跳和健康检查恢复靠重启任务并加载最近的检查点断点续训要求检查点保存足够频繁且完整。我一般会设置每 30 分钟保存一次检查点同时保留最近三个防止检查点本身损坏。恢复时先做一次完整性校验再继续训练。这个机制能把手动干预降到最低。5.3 成本控制算力预算怎么花在刀刃上成本控制不是一味省钱而是让每一分算力都产生价值。几个实用手段用竞价实例跑容错任务、按需伸缩、模型压缩减少推理成本、缓存高频请求结果。我还会定期做算力审计看哪些任务长期低效该优化优化该下线下线。6. 常见问题与排查技巧实录6.1 训练不收敛的排查思路训练不收敛是最让人头疼的问题。我的排查顺序是先看数据有没有脏数据、标签错位再看学习率和优化器配置再看并行策略有没有引入 bug最后看数值精度有没有溢出。梯度检查点、混合精度、张量并行都可能是元凶。6.2 推理延迟高的定位方法推理延迟高先分段计时预处理、模型前向、后处理各占多少。如果前向占大头再看是计算瓶颈还是显存瓶颈。计算瓶颈就上量化或蒸馏显存瓶颈就优化 KV Cache 或减小批大小。6.3 常见问题速查表问题现象可能原因排查方向GPU 利用率低数据管道慢检查预取和并行读取训练 loss 震荡学习率过大调小学习率或加 warmup显存 OOM批太大或激活值多开梯度检查点或减批推理延迟高KV Cache 大分页管理或量化任务排队久调度策略不合理调优先级或加节点通信占比高并行策略不当调整 TP/PP 比例提示排查问题时一定要有数据支撑不要凭感觉。先加监控再定位最后优化。7. 我在这条路上踩过的坑和几点体会说实话AI Infra 这个方向最大的特点就是“广而深”没有人能一开始就全懂。我自己的路径是先打通一条最小闭环——用单机跑通训练到推理的全流程然后再逐层深入。每深入一层就回头看看它对上下游的影响。我踩过最深的坑是过早优化。刚开始总想着一步到位用最先进的并行策略结果配置复杂、bug 多、调不动。后来我改成先用最简单能跑通的方案测出瓶颈后再针对性优化效率反而高得多。另一个体会是监控和日志的投入永远不亏。很多问题如果有完善的监控几分钟就能定位没有监控可能要查一天。这个领域变化很快新框架、新硬件、新优化层出不穷。但底层的逻辑是稳定的算力、通信、存储、调度这几条主线不会变。把主线吃透再学新东西就是往上挂叶子不会乱。后续我还会继续补充微调、多模态、Agent 工程化这些方向的内容这张地图会一直更新下去。