做AI Infra这块最头疼的其实不是某个具体技术学不会而是知识太散。今天看了篇分布式训练的博客明天刷到个GPU调优的视频后天又碰到个数据管线的分享每样都似懂非懂真到自己搭环境、调性能的时候脑子里全是浆糊。这份笔记就是我把AI Infra整个版图重新梳理一遍之后沉淀下来的东西。它不是某个单一工具的教程而是一张完整的地图——从底层芯片、集群调度到数据存储、训练框架再到模型上线后的推理优化、成本治理每一层解决什么问题、关键指标是什么、常见的坑在哪里全串起来了。这份笔记适合几类人刚入行想建立整体认知的开发者已经在做算法但总被工程问题卡住的算法工程师还有那些需要拍板技术选型、但又不想被服务商牵着鼻子走的技术负责人。读完你未必能立刻成为某个细分方向的专家但至少别人聊起AI Infra的任何一个环节你都知道它在整个链路里的位置以及它为什么存在。1. AI Infra 全景版图从芯片到应用的七层拆解AI Infra全称是AI Infrastructure翻译过来就是AI基础设施。你可以把它理解成支撑所有AI应用跑起来的那套地基。没有这个地基再好的模型架构、再高质量的训练数据都只能是纸面上的想法。我习惯把AI Infra分成七个层次从上到下分别是算力层、网络层、存储层、平台层、框架层、工具链层、应用层。每一层都是独立的学问但层与层之间又紧密咬合。比如算力层决定了你能训多大的模型网络层决定了多卡训练时数据能不能喂得够快存储层决定了海量数据能不能高效加载平台层决定了这些资源怎么被调度和管理。任何一个环节掉链子整个训练任务都会跟着遭殃。这七个层次如果要按重要性排个序我得说算力层和平台层是当前最核心的两块。倒不是说其他层不重要而是这两层的技术壁垒最高、成本占比最大、踩坑空间也最多。很多团队花了大价钱买了GPU服务器结果利用率不到30%问题往往就出在平台层的调度和管理上。这也是为什么Kubernetes在AI Infra领域越来越重要——它解决的就是算力资源怎么被高效、灵活地分配给不同任务的问题。七层结构里还有一个经常被忽略的点网络层。单机单卡训练的时候网络层无关紧要但一旦进入多机多卡训练网络带宽和通信效率就成了决定训练速度的命门。业内常说“算力是骨架网络是血脉”一个万兆网卡和一个InfiniBand网络的训练效率差距可以达到数倍之多。这七层也就是AI Infra的全部吗严格来说还有一层更底层的东西——硬件架构本身比如最新的GPU芯片设计、存算一体芯片、光通信技术。这些属于芯片公司的范畴一般做AI应用的公司接触不到我就不展开讲了。但哪怕只是做上层应用了解一下这些硬件的演进方向也有好处至少能让你在选型的时候知道未来的趋势在哪里。一句话总结我对AI Infra全景的理解它是一个从硬件到软件的立体系统目标是让AI任务的开发、训练、部署、运维这件事变得标准化、自动化、可规模化。我在整理这份笔记时最大的感受是很多人觉得AI Infra就是“买卡跑模型”这其实是对它最大的误解。2. 核心矛盾与方案选型为什么没有一套标准答案2.1 性能与弹性的对决接触AI Infra越久我越发现这个领域最大的矛盾不是技术不够强而是需求太多样。同样一套基础设施A团队用它是为了训练千亿参数的大模型B团队用它是为了跑上百个中小规模的推理服务C团队用它是为了做数据清洗和特征工程。这三者的需求天差地别对Infra的要求自然也不可能一样。训练任务的核心诉求是极致性能。训练一个千亿参数模型GPU要满负荷运转显存要尽可能塞满通信要尽可能快这时候任何额外的开销都是不可接受的。推理任务的核心诉求则变成了弹性和成本。推理服务的流量是波动的白天高晚上低如果能做到按需伸缩钱就能省下不少。但弹性伸缩和性能极致往往是矛盾的——追求弹性就得容器化、微服务化这会带来额外的开销追求性能就得定制化、紧耦合这又牺牲了灵活性。我看到很多团队在做Infra选型时第一个犯的错误就是试图用一套方案解决所有问题。比如买了一套大规模容器集群管理平台用它来跑推理服务图的是它的弹性伸缩能力结果拿它去跑大规模分布式训练发现通信效率上不去训练速度大打折扣。反过来也有团队为了训练性能定制了一套紧密耦合的方案等到推理服务上线时发现根本无法快速扩容流量一涨就雪崩。我的建议是Infra架构从一开始就要区分训练和推理两条线各用各的方案中间通过统一的资源管理层做衔接。训练线追求性能极致推理线追求弹性灵活两者不要混在一起。这一个决策做对了后面能省掉无数麻烦。2.2 买卡还是租卡自建还是上云除了性能与弹性的矛盾还有一个所有团队都要面对的问题算力到底怎么来。是自建机房买GPU服务器还是直接租云上的GPU实例又或者是走算力租赁平台按需租卡自建的优势是成本可控。如果GPU利用率能常年保持在70%以上自建的长期成本大概率低于上云。但自建的代价是要养一个不小的运维团队从机房电力、散热到服务器硬件故障全都要自己管。还有个隐患是硬件迭代快两三年后GPU就要更新换代的这搁谁头上都是一笔不小的折旧。上云的优势是弹性好。今天需要100张卡明天只需要10张卡云上可以随时调整。对很多中小团队来说云GPU是前期最稳妥的选择。代价是单价高长期跑下来成本容易失控。而且真到了大规模训练的那一天云厂商对大规模多机训练的底层优化未必比得上自建方案。这个问题没有标准答案只有适合不适合。我的经验是小团队起步期无脑上云等业务量上来、GPU利用率稳定了再考虑混合或自建的方案。3. 实操环节一构建一套基础算力调度平台说完了选型层面的思考接下来进入实际操作。先说一条最核心的经验AI Infra最容易上手、也最能快速见效的落地方案就是用Kubernetes搭建一套算力调度平台把GPU资源池化让不同团队、不同任务可以共享这些资源。以前一个团队要用GPU得先申请服务器、装驱动、配环境一套流程走下来至少一两天。有了调度平台这个过程可以压缩到几分钟——提交一个任务平台自动分配GPU、拉起容器、运行代码结束之后资源自动释放。3.1 环境准备与资源池规划第一步是准备环境。你需要至少三台物理机或虚拟机一台作为控制节点其余作为计算节点。控制节点要求不高8核CPU、16G内存就够计算节点则要配上GPU。目前市面上主流的GPU驱动和容器支持已经很成熟NVIDIA的容器工具包装好后GPU就能被Kubernetes正常识别和调度。资源池规划阶段要做的第一件事是确定GPU型号和数量。这里有一个关键指标显存大小。一张40G显存的显卡大概能塞下一个7B参数的中等规模模型的全参数训练加上优化器状态之后显存基本占满如果是13B以上模型就要考虑多卡切分了。所以规划资源池的时候别光看GPU数量要看总显存和你要跑的模型规模是否匹配。另一个规划要点是把计算节点分成不同的资源池。比如训练池用大显存GPU推理池用小显存GPU数据预处理池甚至可以用纯CPU节点。不同池之间逻辑隔离避免训练任务把推理任务的资源抢光。这个设计和云厂商划分不同规格实例的逻辑是一样的只是你自己掌控更灵活。3.2 GPU调度与共享策略Kubernetes默认情况下是不认识GPU的需要安装NVIDIA的设备插件来让Kubernetes感知GPU资源。装好之后GPU就成了类似于CPU和内存的可调度资源你可以在提交任务时声明需要几张卡。但这里有个和传统场景不太一样的地方GPU是稀缺资源一张卡的计算能力非常强很多时候多个小任务根本用不完一张卡。如果简单粗暴地按“一张卡一个任务”来调度GPU利用率会非常难看。业内通用的解法是GPU共享——一张物理GPU切分成多个逻辑GPU分别分配给不同的任务。最常见的实现方式是通过显存隔离限制每个任务能使用的显存量但计算能力不做强隔离。GPU共享是个好功能但也要知道它的局限。计算能力不隔离意味着如果某个任务吃满了计算单元其他共享这张卡的任务性能就会受到影响。所以我的建议是生产环境的GPU共享要谨慎宁可把共享比例调低一点也不要因为共享导致关键任务性能抖动。测试环境可以放肆共享多跑几个任务没关系。3.3 任务编排与队列管理平台搭起来之后接下来的核心环节是任务编排。你需要回答一个问题当多个团队同时提交训练任务时谁先跑谁排队这里要用到Kubernetes的队列和优先级机制。你可以为不同团队配置不同的资源配额比如A团队最多占用50%的GPU资源B团队最多占用30%剩下的留给临时任务。还可以设置任务优先级定时训练任务比如每天凌晨跑的数据更新优先级可以设低一点实时性要求高的推理任务优先级设高一点。遇到资源竞争时调度器会优先保证高优先级的任务。实际操作中我踩过的坑是队列配置得太宽松导致某个团队的任务把资源全占了另一个团队的关键任务排队排了几个小时。后来加了优先级和抢占机制才把这个问题解决。所以任务编排这块宁可一开始就把策略定得严一点也不要等出问题了再补救。4. 实操环节二打造一条高效的数据管线算力调度平台解决的是“算力怎么分”的问题接下来的核心问题是“数据怎么喂”。做AI的人都知道模型训练本质上就是不断地把数据喂给模型让它从数据中学习规律。如果数据管线效率低GPU就只能空转等待数据利用率自然高不起来。4.1 数据仓库与特征平台设计传统的数据处理流程是原始数据先存到数据仓库里然后经过清洗、转换、特征工程最后生成训练样本供模型使用。这个流程本身不复杂但在AI场景下有一个新问题训练特征和模型推理时用的特征必须保持一致。否则训练出来的模型到了线上推理时发现特征对不上效果就会大打折扣。为了解决这个问题业内提出了特征平台的概念。简单说就是把特征的计算、存储、分发统一管理起来训练和推理都从同一个特征平台取数保证两边特征口径完全一致。国内外的开源社区都有比较成熟的方案自建的话核心思路是一样的训练特征和线上推理特征共用同一套特征计算逻辑特征的元数据集中管理特征值的更新和版本管理都要有迹可循。我在实践中的一个体会是特征平台的建设要尽量前置。等项目上线了再补特征平台往往要重构很多代码痛苦程度远超想象。如果能在项目初期就把特征管线的规范定下来后期省心很多。4.2 分布式文件系统与缓存加速训练样本和模型文件一般存放在分布式文件系统上。训练任务跑起来之后计算节点需要从文件系统读取数据如果文件系统性能不够数据读取就会成为瓶颈。这里有一个关键的权衡文件系统的性能越强成本越高。不是所有数据都需要高性能存储也不是所有数据都能忍受低性能存储。我的建议是按数据访问频率分级存储热数据频繁读取的训练集放到高性能存储上冷数据不常用的历史数据放到低成本大容量存储上。这个思路和传统IT领域的冷热数据分层是一样的在AI场景下尤其适用——因为训练数据集动辄几百GB甚至上TB全部放高性能存储的成本太高了。除了存储本身的性能还有一个容易被忽视的瓶颈数据读取的并行度。当100个计算节点同时读取同一个大文件时如果文件系统不支持高效的随机读取就会造成严重的IO争抢。解决这个问题常用的手段是样本级或文件级的数据切分让每个节点只读取自己所需要的那部分数据而不是都去抢同一个文件。4.3 数据版本管理与回溯数据版本管理是AI Infra里特别容易被忽视、但特别重要的一个环节。一次模型训练的结果是数据和代码共同决定的。代码有版本管理工具比如Git数据也一样需要版本管理。否则当你发现某个模型的效果特别好想复盘一下它到底用了哪份数据版本时会发现根本追溯不回去。业界常用做法是用数据湖或数据仓库的托管功能来实现数据版本管理。每一次数据发布都打上版本标签记录数据的生成时间、来源、变更信息。后续训练任务里明确记录使用的数据版本号这样每次训练都可以复现。我把这个实践形容成“给数据拍照存档”——做一次训练就把对应数据的状态拍一张快照存起来。这个习惯在模型出问题需要回溯的时候能救你于水火。5. 实操环节三分布式训练的执行与调优数据和算力都准备就绪之后迎来真正的重头戏分布式训练。这是AI Infra里最深的坑区也是优化空间最大的地方。5.1 并行训练的核心策略当模型太大单张GPU放不下的时候就要做分布式训练了。主流的并行策略有数据并行、模型并行、流水线并行这三种实际训练中经常混合使用。数据并行是最容易理解的并行方式每个GPU放一份完整的模型副本把数据切成多份分给不同的GPU并行计算通过梯度同步来保持模型状态一致。数据并行的优点是实现简单缺点是模型太大放不进单卡时这种方式就行不通了。模型并行解决的是模型太大放不进单卡的问题把模型的不同层切分到不同GPU上输入数据依次经过各层计算。它的缺点是层与层之间有依赖关系计算过程是串行居多GPU利用率不高。流水线并行是对模型并行的改进把数据也切成多个小批次让前面的GPU在处理第一批数据时后面的GPU可以同时处理上一批数据形成流水线效应提升整体吞吐。它的调度复杂度更高但综合效率远优于普通模型并行。实际训练的做法是先做模型并行让模型能够放下再做数据并行提升训练吞吐。业界成熟的框架已经把这三者的组合自动化了你只需要通过配置指定并行策略即可。5.2 显存估算与Batch Size选择一个新手最容易犯的错误是对显存需求没有概念盲设Batch Size结果OOMOut of Memory显存溢出报错。我在这里给一个直观的估算公式模型本身参数占用的显存 优化器状态占用的显存 前向计算产生的激活值占用的显存 ≈ 总显存需求。其中优化器状态这块用Adam优化器的情况下显存占用是模型参数的2-3倍。也就是说一个10G参数量的模型光模型参数和优化器状态就需要40G左右的显存这还没算激活值。Batch Size的选择要综合考虑显存和训练效果。显存够用的情况下Batch Size适当加大能让梯度的估计更准确训练曲线更平稳但如果Batch Size太大模型收敛效果反而会变差。实操中有个经典的口诀是“Little Batch, Big Learning Rate”——小批次配合大学习率很多任务上效果反而更好。但具体数值还是得靠实验调参。一个偷懒但有效的做法初始Batch Size设为模型参数量开根号的量级比如7B模型可以试试128这个量级然后看显存占用调整。当然最终取值还是要跑个小规模实验验证。5.3 训练监控与性能调优训练跑起来之后不能干瞪眼看日志。你需要实时监控几个关键指标GPU利用率、显存占用率、数据加载耗时、通信耗时。在前面讲的并行策略下GPU利用率达到85%以上算健康80%以下就说明有瓶颈需要排查了。如果发现GPU利用率不高常见的排查路径是先看数据加载是不是瓶颈表现是GPU一会儿干活一会儿空转周期性很明显。如果是数据加载慢了就加大数据加载的预取和缓存或者检查前面讲的数据管线。如果数据加载没问题那就是通信瓶颈了——节点间的梯度同步在大型集群上可能比计算还要耗时。这个阶段优化的空间不算大基本靠网络硬件和通信库的配置调优。我自己见过最多的场景是训练任务堆了很多GPU但利用率只有百分之三四十。排查到最后发现是数据管线的IO设计有问题。解决之后利用率立刻翻倍。所以遇到性能问题先别急着怀疑硬件按“数据 - 通信 - 计算”的优先级逐层排查大概率能找到根因。6. 推理服务与弹性扩缩容模型训练完之后要上线提供服务。很多人觉得推理服务比训练简单其实不是这样。推理服务对延迟、成本、稳定性的要求同样严格而且面向线上流量踩坑的后果更严重。6.1 推理服务化架构选型推理服务化面临的第一道选择题是用什么方式对外提供模型服务。如果是内部使用内部小组自建一个简单的接口也可以如果是面向外部的高并发场景就要用专门的推理服务框架了。目前业界的标准做法是封装成标准的HTTP接口或GRPC接口放在容器化平台上运行由Kubernetes负责自动扩缩容。对外推理服务框架负责模型加载、请求排队、批处理优化、结果返回对内它需要和前面讲的GPU调度平台无缝集成——服务扩缩容时能自动申请和释放GPU资源。我建议推理服务框架选那些原生支持动态批处理和GPU利用率优化的方案。因为推理服务是典型的IO密集加计算密集混合场景大量单条请求如果逐个处理GPU利用率极低动态批处理可以把多个请求攒起来一起推理成倍提升吞吐。这类优化做得好同样的GPU数量可以支撑数倍的并发量。6.2 延迟与吞吐的平衡艺术推理服务的两个核心性能指标是响应延迟和请求吞吐。在硬件资源固定的情况下这两个指标其实是矛盾的——吞吐上去了单请求延迟必然会变高延迟压低了吞吐就上不去。实际的业务场景里你不可能两个都要最优而是要根据业务诉求做取舍。比如在线支付风控的推理请求延迟要求极高超时就要风控降级这时候你的目标就是最小化延迟哪怕牺牲一些吞吐而离线批量推理任务比如商品推荐结果加工它不要求毫秒级响应更看重单位时间处理的请求量这时候就可以追求吞吐最大化。这个取舍最终落实在配置上就会发现无论是调整动态批处理的最大批次大小还是限制模型推理的并发数其实都是在延迟和吞吐之间划一条你能接受的线。我给你一个经验值参考一般在线推理服务P99延迟即99%的请求都在这个延迟以内控制在200毫秒以内中间的耗时分布比较稳定就算健康的了。如果P99超过500毫秒多半要优化了而不是继续调参。6.3 弹性扩缩容与优雅下线推理服务另一个核心需求是根据流量动态扩缩容。白天流量高峰晚上流量低谷资源开销完全不同。如果在低谷时段还维持和高峰一样的资源成本会浪费很多。Kubernetes生态原生的HorizontalPodAutoscaler就能完成基本的按指标扩缩容比如根据CPU使用率或请求量进行扩缩。但在AI推理场景里我更推荐根据自定义的业务指标做扩缩容——比如GPU利用率超过70%就扩容低于30%就缩容。因为推理服务的性能和GPU利用率强相关CPU指标反而不太能反映真正的负载。这里要特别提醒一个容易出问题的点优雅下线。当缩容发生时正在处理的推理请求不能被强行中断否则线上会有大量超时报错。正确做法是设置缩容的优雅时间让服务先把正在处理的请求处理完再销毁实例。这个细节看起来不起眼但没做好缩容的时候分分钟给你整出线上事故。7. AI Infra的运维体系与成本治理最后讲一个所有Infra逃不开的话题运维和成本。甚至在AI场景下这个话题比传统运维要复杂得多。7.1 全链路监控与告警AI任务的监控比传统应用复杂的地方在于它需要监控的维度更多。传统应用监控CPU、内存、磁盘、网络这四大件就够了AI任务还要额外关注GPU利用率、显存占用、GPU温度、数据加载耗时、通信耗时、训练Loss值等一大堆指标。我的建议是分两层建设监控体系。第一层是基础设施监控包含GPU节点层面的各种指标通过主流的Prometheus Grafana这套方案解决。第二层是训练任务监控包含Loss曲线、训练速度、每轮迭代耗时等业务层面指标这些需要在训练框架里接入日志和指标上报能力。告警规则要避免两条极端一是告警太多天天被无关告警轰炸到最后麻木二是告警太少出了问题没人发现。我比较认可的做法是只对“影响交付”的关键指标设置告警比如训练作业崩溃、GPU利用率持续低于某阈值、推理服务P99延迟突增。而像GPU温度偶发升高这类指标记录日志即可不需要告警。7.2 资源预算与配额管理AI的算力开销都不小如果完全没有成本治理意识月底账单出来真的会让人怀疑人生。治理的核心思路是两点预算和配额。预算是指从财务角度规定某个团队或者某个项目在算力和存储上的花费上限。做到预算层级需要有准确的计量能力能够把每一块GPU每一小时的使用成本归属到具体团队和具体任务上。很多云平台自带成本分析功能自建平台就需要在调度系统里做资源计费逻辑。配额是从资源角度做的限制前面在调度平台一部分其实已经提过。这里想补充的一点是配额消耗掉之后怎么办。是直接停掉任务还是允许任务继续跑但标记为超额直接停任务太粗暴影响业务允许超额又让配额形同虚设。业内的经验是通过“软配额 硬配额”机制解决软配额允许任务超额运行但会产生告警提醒负责人关注成本硬配额则是不能突破的红线突破就停。这个机制既可以做成本控制又不会因为一点配额问题就把业务停了。7.3 成本优化的经典手段成本治理里最实际的一块是优化资源开销。业界最经典的手段就是利用时间差让非实时任务在低谷时段运行。GPU的价格不分时段其实成本一样但资源竞争程度分时段——白天大家都在跑任务晚上资源空闲多。把非实时的数据预计算任务、模型评测任务放到夜间执行既不影响业务体验又能让平台的资源利用率波峰波谷被拉平。更省钱的做法是对非实时任务使用可被抢占的“低优先级实例”资源。当高优先级任务需要资源时低优先级任务可以被中间暂停释放出资源来。作为交换它的价格可以做得非常低。对很多非核心的分析任务来说这种“随时可能被抢占但便宜很多”的资源其实非常香。8. 个人学习路径与踩坑心得聊到最后一部分分享一下我自己从零搭建这套AI Infra体系时的学习路径和踩过的坑。8.1 推荐的学习顺序如果让我重新学一遍AI Infra我会按照这个顺序来先学Linux基础操作和容器化Docker/Kubernetes这是整个体系的地基然后学GPU的基础知识包括显存、计算单元、驱动程序这些概念接着做一个小型实验在一台GPU服务器上把训练任务容器化跑起来然后再逐步扩展到多机多卡、分布式训练。每一步都动手实践光看不练肯定学不会。这里有个很重要的学习方法带着问题去学。我看到太多人的学习方式是“从入门到放弃”——买一本很厚的Kubernetes书从头看到尾看到一半就崩溃了。我的建议是直接从一个目标出发比如“我要把一个训练任务在Kubernetes上跑起来”然后边做边查资料。遇到问题解决问题在这个过程中知识自然就积累起来了。8.2 避坑经验总结最后把我这几年踩过的坑整理成清单供各位参考第一个坑也是最常见的坑GPU驱动版本和容器运行时不匹配导致GPU无法被识别。这个问题排查起来非常费劲建议在搭建环境时就选好一套经过验证的版本组合然后固定下来不要随便升级。第二个坑模型训练时的数据加载没有做预取和缓存。训练速度忽快忽慢特别不稳定。这个问题在数据管线部分已经提过这里再强调一次数据加载的预取和缓存是训练性能调优的第一优先级。第三个坑跨团队共享GPU资源时没有提前约定好资源配额。结果某个团队的任务把资源全占了其他团队的任务排队排到怀疑人生。资源配额和优先级一定要提前定好并且随着业务变化定期调整。第四个坑推理服务的优雅下线没有配置好。每次缩容都会报出一堆超时错误。那个印象太深刻了从那以后我每次配置缩容策略都会反复确认优雅下线逻辑这个点太容易决定任务成败了。AI Infra的知识全景很大但框架搭好之后后续的学习就只是往各个细分方向继续填充细节。希望这份笔记能帮你省掉一些摸索的时间把时间花在真正有价值的事情上。