做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，结果OOM（Out 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的知识全景很大，但框架搭好之后，后续的学习就只是往各个细分方向继续填充细节。希望这份笔记能帮你省掉一些摸索的时间，把时间花在真正有价值的事情上。
