AI Infra 全景学习笔记：从 GPU 服务器选型到推理服务化

这篇内容既不是通俗科普也不属于死磕算法的学习笔记得先说清楚边界。我这两年一直在做 AI InfraAI 基础设施方向带过小团队也帮不少甲方从零搭过训练和推理环境。经常有人拿着一张 GPU 服务器报价单来问我是不是买了就能跑大模型每次我都要花很长时间从底层存储讲到网络拓扑再讲到调度器最后对方还是一脸懵。这种碎片化认知的问题太普遍了所以我把自己的知识体系和踩坑记录整理成一份全景学习笔记希望能帮想进入 AI Infra 领域的人建立一个完整的地图。这套笔记覆盖的东西比较杂从 GPU 服务器硬件选型、分布式训练框架、数据存储与缓存到推理服务化、资源调度和成本治理。它的目标不是让所有人都成为精通每一层的专家而是帮你搞清楚AI 系统运行起来到底依赖哪些基础设施组件它们之间怎么协同出问题时该往哪个方向排查。我自己从应用开发转过来时最痛苦的就是这类知识散落在各种文档和代码里没人告诉你全貌是什么样。这篇文章适合以下几类人想往 AI Infra 方向转的后端工程师、刚上手管理 GPU 集群的平台开发同学、在大模型团队里负责跑实验但经常被资源问题卡住的算法工程师、以及需要跟技术团队对齐需求的架构决策者。我的经验是这类知识很难从书本上体系化地学到更多要靠实战中不断踩坑再复盘所以我尽量把关键链路讲透也把我踩过的坑和验证过的做法写在里面。1. AI Infra 到底在解决什么问题先说个类比。你把大模型训练想象成盖一栋楼算法工程师是设计师他们出图纸模型结构和装修方案训练配置而 AI Infra 工程师是施工方要管钢筋水泥服务器硬件、施工道路网络、材料仓库存储系统还要保证几百个工人GPU卡不窝工、不冲突、按时完工。但 AI 的施工比普通盖楼复杂得多。一个典型的大模型训练任务要持续几周甚至几个月用到几百到几千张 GPU 卡这些卡需要保持极高的利用率任何一张卡掉线或者网络抖动都可能让整个训练任务中断重来一次的代价是几十万元的电费和人力成本。所以 AI Infra 的核心目标很简单让大规模算力稳定、高效、低成本地跑起来。具体拆开来看AI Infra 要解决三类问题资源供给问题硬件够不够、类型对不对、能不能快速交付给业务团队。这涉及服务器采购、机房部署、资源虚拟化与隔离。运行效率问题训练任务能不能充分利用硬件算力数据喂得够不够快网络通信有没有瓶颈GPU 利用率是不是达标。稳定性问题几千张卡跑一个月不出故障不现实但如何做到故障自动恢复、任务自动续跑、瓶颈自动定位让单点故障不影响整体交付。这三个问题对应着 AI Infra 的三大支柱算力层、数据层、平台层。理解了这三层关系后面所有技术点都能串起来。我见过太多人一上来就扎进某个具体工具的源码里比如去抠某个分布式框架的通信原语结果越学越迷茫因为他不知道这个工具在整个系统里的位置。2. 算力与硬件层GPU 服务器的选型与组网2.1 单机选型的关键点别只盯着显卡型号很多人选型时最关心 GPU 型号比如用最新旗舰卡还是上一代卡。这当然重要但单机的整机配置往往会成为瓶颈。我实际调过的案例里出现过 GPU 计算能力很强但 CPU 太弱导致数据预处理速度跟不上、网络带宽不够导致分布式训练通信时间占比过高、内存不足导致大模型参数交换时出现 swap 抖动的情况。选型时我会按这个优先级去权衡GPU 显存容量与该卡的训练特性。显存决定了单卡能装多大的模型、多大的 batch size对推理场景还决定了能同时处理多少并发请求。CPU 核心数和主频。训练框架的数据加载和预处理部分大量依赖 CPUGPU 越强需要的 CPU 配套越强。我常用的经验比例是单张 GPU 至少配 8 个物理核心以上否则数据管线容易成为瓶颈。内存容量。建议至少是显存总量的 2 倍以上。处理大模型时的中间激活值、临时缓冲都可能存在 CPU 内存里。PCIe 通道数和卡间互联方式。多卡通信如果走 PCIe 带宽不足会严重制约并行训练效果。网卡带宽。单机多卡时至少要配 25GbE 或更高速率的网卡这决定了跨机通信的上限。网络互联是很容易被忽略但影响巨大的点。以我现在常用的多卡服务器为例卡间通信如果走 PCIe Switch带宽远不如专用的高速互联通道。这也是为什么很多大厂的训练集群要采用专门设计的服务器而不是拿普通工作站去堆 GPU。具体到组网服务器内部的关键看到底是主流的全互联拓扑还是某些厂商自定义的交换拓扑直接决定了多卡通信的对等性和延迟表现。2.2 集群组网租户隔离与带宽规划单机解决不了大模型训练因为一张卡最多装一个几十亿参数的小模型而千亿级参数必须靠几十甚至上百张卡配合还涉及跨服务器的通信。集群组网的核心任务是把几百台服务器连接成一张低延迟、无阻塞的高速网络。常见的组网方式核心是胖树拓扑Fat-Tree。这种架构通过多级交换机的冗余连接确保任意两台服务器之间的通信带宽都能达到网卡线速。听起来美好但在实际落地时有两个问题会直接拖垮训练效率网络收敛比过高。有些预算有限的团队会用收敛比 1:4 甚至更低的方案即上联带宽小于下联带宽。这会导致通信峰值发生时数据在交换机出口排队训练任务出现周期性性能抖动。广播流量与大流量通信相互干扰。分布式训练中梯度同步会产生大量的集合通信流量实际上有专门的术语叫 AllReduce这类流量急性子、来势汹汹对网络缓冲和拥塞控制算法很敏感。如果网络设备不支持显式拥塞通知或高级 QoS 队列很容易出现 TCP 丢包重传训练速度断崖式下降。因此做集群组网规划时我的建议是训练集群必须用无收敛或低收敛比架构且网卡速率和交换机端口速率要匹配中间不能有速率转换的瓶颈。同时必须为监控流量和管理流量规划独立的带外网络避免后台监控占用训练带宽。2.3 算力调度的背后逻辑硬件到位之后真正的核心难题是怎么把算力分出去。这个模块属于平台层但和硬件强相关。业界比较成熟的思路是使用资源调度框架比如 Kubernetes 搭配 GPU 调度插件或者一些专用集群调度系统。调度器本质上要解决两个问题把任务放在哪些节点上运行以及如何保证资源分配公平高效。我常用的资源抽象维度是三个GPU 卡数、显存大小、GPU 显存带宽。有些业务只需要几张卡做推理有些训练任务则需要整机独占。如果调度器只按卡数分配而忽视了显存就可能出现一张卡被多个任务共享显存导致 OOM 的现象如果忽视了卡间的通信拓扑分布式训练任务被分配到跨交换机的节点上性能会明显下降。这里有个实操技巧大型训练任务尽量让调度器分配同交换机域内的节点并且优先占满单机再扩展跨机。因为单机内部的通信带宽和延迟远优于跨机网络。我见过有些团队为了让任务平均分布而把同一任务的节点散落在不同机柜结果训练速度反而大幅下降这就是忽视了通信拓扑的代价。3. 数据与存储层喂饱 GPU 是一门学问3.1 数据管道的几个瓶颈很多刚开始接触 AI Infra 的人对存储的认知停留在把数据放到硬盘里给程序读就行。但到了大规模训练场景数据读取的速度会直接决定 GPU 能不能吃饱。我有一次调一个训练任务GPU 利用率死活上不了 60%查了半天才发现是数据读取阶段卡在瓶颈上——数据集太大训练脚本每次生成一批数据都要从远端存储拉取网络成了瓶颈。数据管道的完整链路是数据集存储 - 缓存节点 - 训练数据加载器 - GPU 显存。每一步都可能成为瓶颈。实践中有几个关键设计原则训练数据尽量放在本地 NVMe SSD 或高速并行文件系统上避免每次 epoch 都从远端拉取。可以采用数据缓存或预取机制把常用数据集预先缓存到计算节点的本地盘。数据打包格式要讲究。大量小文件比如几万张 500KB 的图片在分布式文件系统上读取时元数据压力和随机 I/O 开销非常大。建议用 TFRecord、WebDataset 这类格式把数据打包成大文件顺序读取或者转换成一个大的二进制数据文件能明显提升吞吐。数据预处理与训练解耦。把图像解码、数据增强、tokenization 这些操作放到独立的数据处理 worker 上而不是让 GPU 等待 CPU 预处理完成。3.2 分布式文件系统的选择AI 训练场景下文件系统需要支撑高并发写入和读取多节点同时访问同一批数据。业界常用的方案主要有三类基于 HDFS 的大数据生态适合海量小文件离线处理但在 AI 训练的高带宽小文件随机读场景下表现一般。并行文件系统如 Lustre、BeeGFS为高性能计算设计支持大规模并发访问吞吐非常高但是运维复杂度也高需要专门的团队维护。对象存储缓存加速把数据集放到对象存储计算节点上用本地缓存层做加速。这是云原生时代比较流行的方案弹性好、成本低但需要缓存命中率足够高。从我实际落地看中小团队从成本和技术门槛考虑更适合对象存储本地缓存方案。先把数据集预热到缓存训练过程中缓存命中率可以达到 95% 以上吞吐基本能达到本地文件系统的水平。而大型团队如果有专门的运维人力并行文件系统的性能上限确实更高尤其是多个训练任务同时读取同一份数据集的时候。3.3 特征存储与样本管理的隐患数据层还有一个容易被忽视但容易出现线上事故的模块特征与样本版本管理。训练一个模型时你可能用到了 3 个数据源原始样本文件、离线特征表、实时特征接口。这三份数据如果不在逻辑上对齐同一个版本训练出来模型的效果会有偏差而且一旦上线排查难度极大。我踩过的一个典型坑是离线训练特征与在线推理特征口径不一致。比如某个特征在离线数据里是用 T-1 的数据计算出来的但在线上实时环境里变成了当天实时值模型离线指标很好上线后表现却一塌糊涂。要解决这类问题必须有样本日志和特征快照机制把每次训练使用到的数据版本固化下来。这个机制做得好不好直接影响整个机器学习流程的可复用性。4. 训练与平台层框架选型到任务编排4.1 分布式训练框架怎么选目前主流的分布式训练框架分层大致是这样底层是通信库用于跨节点梯度同步中层是训练框架提供并行策略和数据流水线上层是各种模型库和训练 API。不要一上来就问该用哪个框架而是先想清楚你的并行需求属于哪种。训练并行有几种常见模式数据并行每张卡一份模型副本分不同的数据训练然后同步梯度、模型并行模型太大把不同层切到不同卡上、流水线并行按层切分且数据流像流水线一样依次经过各层以及混合并行以上几种混合。不同的并行模式对通信需求差异很大数据并行需要频繁的全量梯度同步模型并行和流水线并行需要相邻节点之间的大量激活值传输。所以框架选择的逻辑是如果你的模型比较小单卡或数据并行就能解决优先考虑主流通用框架如果模型超大、层数极深或者结构特殊用混合并行能力强的平台化框架。我在实践中还会关注几个能力故障断点续训的成熟度、混合并行策略的自动化程度、以及自定义算子或自定义梯度的灵活性。实际上框架本身不是最重要的上层建筑因为很多训练细节你最终都要自己控制。4.2 实验管理不仅是一张记录表训练平台除了要把任务跑起来还得管理好运行过程。这里包含三件核心的事情超参数与代码版本追踪、训练指标可视化、模型产物管理。我见过很多团队的实验管理处于非常原始的阶段用 Excel 记录参数模型文件按日期乱存。这在实验数量少的时候没事但大模型迭代速度极快一旦缺少系统化管理你会面临几个问题不知道上一个效果好的模型用的什么参数组合想复现一个实验却找不到当时的代码版本和数据集版本对比不同实验组时找不到关键指标变化曲线。管理工具的基本要求是每次训练任务的启动都自动记录代码 commit、数据集版本、超参数、启动命令、环境依赖并且能把这些信息和训练指标、日志关联起来。这看起来不难但我发现很多团队都没做到主要原因是早期觉得太麻烦等要追问题的时候才后悔。另一点容易被忽略的是模型本身的标准化管理包括模型命名规范、线上模型与训练产物的溯源关系、模型热更新回滚机制。训练平台的演进方向越来越像一个软件交付平台而不是一个任务提交入口。4.3 任务编排与资源配额当团队里有多个项目同时要跑训练任务就出现编排问题谁的优先级高谁的资源能保证抢占的时候会不会误伤别人的实验这一块在算法团队小的时候可以靠口头协调但超过 5 个人并行做实验就必须要做资源配额和优先级机制。我给团队的常用做法是按项目维度划分资源池池内再做队列和优先级配置。训练任务分为高优在线任务比如和线上服务有关的模型更新和低优离线任务比如研究性实验低优任务可以被高优任务抢占但被抢占前要有优雅停止机制最好能自动将中间状态保存成 checkpoint被抢占后能自动续跑。配额管理的好处是可以把成本控制到人但坏处是资源碎片化——每个项目都要预留一堆资源整体利用率上不去。所以还要配一套资源聚合机制允许低谷期的空闲资源被其他项目借调提高整体 GPU 利用率。我实测下来这套机制做得好可以让集群整体利用率提升 20% 到 30%在硬件不变的情况下相当于省了真金白银。5. 推理与服务化从模型到线上服务的最后一公里5.1 推理引擎的选型逻辑训练只是模型生命周期的一部分真正要产生价值的是线上推理服务。推理侧的核心挑战和训练完全不同训练追求吞吐最大化怎么快怎么来推理追求延迟稳定、并发可控、成本最优化。推理引擎的选型我会看四个指标延迟的 P99 值不是平均值因为线上用户感知的是尾部延迟、吞吐量每秒处理多少请求、显存占用决定了单机能承载多少路并发以及动态批处理的能力。所谓的动态批处理是推理服务在运行过程中把多个请求动态组合成一个 batch 输入给 GPU从而提升吞吐。这个机制做得好吞吐能提升数倍。不同场景下推理引擎的配置策略差异很大高并发在线服务要小 batch、低延迟每个请求的推理时间要极短延迟波动要小。离线批量推理一次性跑大量数据可以大 batch追求整体吞吐最大化延迟的要求放宽。大模型生成式服务涉及到自回归解码每一次只产生一个 token并且需要维护 KV Cache显存占用随上下文长度线性增长。对这类场景需要专门的优化方案而不是通用推理引擎。5.2 服务编排灰度、弹性与容灾推理服务的架构并不复杂但稳定性要求极高。一个在线模型服务挂了影响的是核心业务所以服务编排上要下功夫。核心要素包括多副本部署和负载均衡同一模型部署多个副本流量分发要均匀且要支持按 GPU 显存和推理延迟动态调整权重。灰度发布机制新版本模型上线时先切一小部分流量观察指标和线上效果再逐步放量。这个过程要能被平台自动化而不是靠运维同学熬夜盯着。弹性伸缩根据请求量自动伸缩副本数。这里有个坑模型加载到显存通常要几十秒如果扩容触发条件设得太晚流量高峰来的时候根本来不及拉起新副本。要提前做好预扩容策略比如根据过往流量规律在高峰前提前扩容。容灾调度某个节点故障时调度器要把副本调度到其他健康节点并且要保证剩余副本能承担流量必要时做降级。5.3 推理成本治理推理成本是大模型应用最大的一块支出常被称为每一块钱都花在 Token 上。控制推理成本有很多手段我梳理几个行之有效的方法蒸馏与量化模型用小模型模仿大模型的能力或者把模型权重从高精度压缩到低精度。这能大幅降低显存占用和推理耗时。当然精度损失需要做充分的评估和测试。请求级别优化对生成式模型可以调整解码参数比如跳过不必要的内容生成、设置停止条件、做输入压缩来减少生成 token 数量。成本直接和生成长度挂钩这一点在选型时就要考虑进去。显存复用推理服务通常有模型副本常驻显存多个小模型可以按需加载和释放或者把显存利用不充分的模型做成冷热分层。在实际应用中显存复用做得好坏对成本影响非常大。6. 可观测性与运维稳定性的最后防线6.1 监控指标的四个维度没有监控的系统就像蒙着眼睛开车。AI 基础设施的监控体系我认为要覆盖四个维度硬件层GPU 利用率、显存占用率、温度、功耗、NVLink 状态、网卡收发速率、丢包率。这一层的问题通常直接指向硬件故障或环境异常。容器与任务层每个训练或推理任务的状态、资源申请与使用、重启次数、启动失败原因。这一层能帮助你快速定位是调度问题还是镜像问题。训练过程层loss 曲线、梯度范数、数据加载吞吐、通信时间占比、各节点训练进度。这一层是算法工程师最关心的也是判断训练是否健康的关键。业务服务层推理请求 QPS、延迟分位数、错误率、token 消耗速率。这一层直接关联线上服务质量。我特别强调一个容易被忽视的指标数据加载吞吐和 GPU 利用率的对照关系。如果你发现 GPU 利用率波动很大同时数据加载吞吐呈周期性低谷那基本可以断定是数据管道瓶颈。这种问题用普通的监控工具很难一眼看出来需要把数据链路指标也纳入同一张观测视图。6.2 故障排查的实战流程我在一线处理过很多次线上训练故障时间长了总结出一套排查方法论按层次从下往上走先查硬件层看 GPU 是否异常掉卡、网络链路是否正常、温度有没有过高降频。硬件问题排查成本最高因为可能涉及现场操作。再查系统层看磁盘空间、内存占用、文件句柄数是否耗尽内核日志里有没有 OOM 或锁死。再查应用层看训练日志、错误堆栈、库版本兼容性。最后查算法层如果任务还在跑但 loss 异常那是算法问题不是基建问题。这套从下往上的排查思路帮我避免了很多弯路。有一次某团队报告训练速度慢我直接跳到了通信库配置上检查半天最后才发现是一块 SSD 盘温度过高触发了降速属于硬件层问题。从那以后我严格执行这套排查流程速度和准确性都上来了。6.3 告警体系的构建监控没有告警等于白搭。但告警也不是越多越好告警疲劳会让真正重要的告警被淹没。我在搭建告警体系时的原则是少而准只对直接影响业务的事件产生告警比如 GPU 利用率长期为 0、节点掉线、分布式训练卡住超过一定时间、推理错误率超过阈值。设置合理的阈值和持续时间避免瞬时抖动触发大量告警。比如 GPU 利用率低要持续 10 分钟以上才告警而不是 1 分钟就告警。告警信息必须包含可操作的排查线索比如实例 ID、最近事件日志、相关监控链接让接收人可以直接开始排查而不是收到一条不知所云的告警。我还特别重视告警升级机制。一线值班的人处理后没响应或处理不了会自动升级给二线负责具体模块的资深工程师。这样做的好处是多数小问题在一线直接消化不会动不动就拉全组人进群。7. 给新人的学习路径与常见误区7.1 从一条链路串起知识很多新人学 AI Infra 失败是因为知识点是散的今天看了一个 GPU 监控的博客明天看了分布式训练的论文后天学了一下容器网络但脑子里就是串不成一张网。我建议的学习路径是找一个真实任务沿着一条链路从头走到尾先自己部署一台带 GPU 的服务器装好驱动和容器环境手动启动一个小模型训练观察 GPU 利用率然后把训练数据搬到分布式存储上看看本地和远端读取的性能差异接着把单机训练改成多机分布式训练调通信和网络参数感受一下瓶颈在哪再部署一个推理服务压测它的延迟和吞吐尝试优化推理引擎。这个过程走一遍下来比看十本书都管用。因为每一个环节你都会踩坑每一个坑都会逼你去理解背后那块技术设计的原因。这种由问题驱动建立的认知才是真正牢固的。7.2 常见的学习误区过度关注某个框架的 API 细节而忽略底层原理。框架迭代很快今天学的 API 明天可能就变了但分布式通信、数据并行、调度器设计这些底层的逻辑是相对稳定的。我一直主张原理驱动 API弄明白一个机制为什么存在再去看它在具体框架里怎么体现。轻视运维和稳定性。很多转过来的工程师只对搭建新系统感兴趣对保障系统长期稳定运行没耐心。但 AI Infra 的价值恰恰体现在日复一日的稳定运行中。试图一次性搞明白所有技术。AI Infra 涉及领域太广合理的方式是按需学习先掌握和当前项目相关的那一块再逐步扩展。我在带人时第一课就是让他们划清必须知道和等遇到了再学的边界。忽略成本意识。技术方案没有绝对的好只有适不适合你这个业务的成本模型。一个方案性能再高如果运维成本高不可攀就不是好方案。7.3 我自己的一点体会做了这么久 AI Infra最有成就感的一刻往往不是把某个性能指标优化了几个百分点而是看着一个跑了几周的千卡级训练任务全程零故障顺利结束。这种稳定背后是无数个细节的积累选型时多算了一笔网络收敛比、写监控时多配了一个数据加载吞吐指标、排查问题时忍住冲动先看了硬件层日志。这些经验很难通过逛社区刷帖子学到需要在真实环境里一次一次试错。所以读完这篇文章之后我建议你别急着背概念而是动手做点小实验踩出自己的第一个坑在解决它的过程中你才真正开始理解 AI Infra 这门学问。