1. 为什么一线工程师都在聊AI-Infra这两年技术圈有个很明显的现象做业务开发的工程师开始往底层走做运维的工程师开始往AI方向靠而原本做算法的那批人反而在补系统工程这门课。三条线交汇的地方就是AI-Infra也就是人工智能基础设施。我在一线做系统相关的工作有些年头了最近一年明显感觉到身边越来越多的同行在讨论显存怎么分、训练任务怎么排队、推理服务怎么把延迟压下去。这不是赶时髦而是真实的工程需求倒逼出来的。先说清楚AI-Infra到底是个什么东西。你可以把它理解成让AI模型能跑起来、跑得快、跑得稳的那一整套工程体系。它不负责设计模型结构也不负责调参炼丹它负责的是算力怎么组织、数据怎么喂进去、任务怎么调度、服务怎么稳定对外。打个比方算法工程师是造车的AI-Infra工程师是修路、建加油站、搞交通调度的。车再好路不通、油供不上照样跑不起来。那为什么是一线工程师在聊这个因为AI-Infra最大的特点就是离真实环境特别近。你在实验室里跑通一个demo和你在生产环境里让几百张卡同时干活完全是两码事。显存会碎片化、网络会抖动、磁盘IO会成为瓶颈、任务会莫名其妙卡住。这些问题不会写在论文里只会出现在凌晨三点的告警群里。所以真正有价值的AI-Infra经验往往来自那些亲手踩过坑的一线人员。这篇内容适合谁看如果你是刚接触AI工程的后端或运维工程师想搞清楚这个方向到底要学什么那这篇能帮你建立整体认知。如果你已经在做相关的工作但总觉得知识是零散的那这篇能帮你把碎片串成线。如果你纯粹是好奇想知道那些大模型背后到底靠什么撑着那也能看个明白。我会尽量少用黑话多用类比把每个关键选择背后的为什么讲清楚。需要提前说明的是AI-Infra这个领域非常宽一篇文章不可能讲完。这一章我聚焦在最核心的几块算力资源怎么管、训练任务怎么跑、推理服务怎么部署以及贯穿始终的性能与稳定性问题。这些都是无论你用什么框架、什么硬件都绕不开的基本功。后面如果继续写会再深入到具体的调度系统、通信优化、存储方案这些更细的层面。2. AI-Infra的核心版图与能力拆解2.1 一张图看懂AI-Infra的四个层次我习惯把AI-Infra分成四层来看从下往上分别是硬件资源层、集群调度层、任务运行层、服务接入层。这个分法不是教科书上的标准答案而是我在实际工作中觉得最好理解、最好定位问题的一种切法。硬件资源层就是最底下的物理设备包括GPU、CPU、内存、网卡、存储。这一层的关键词是异构和稀缺。异构是说设备种类多、型号杂不同代的卡混在一起是常态稀缺是说好的算力永远不够用怎么把有限的资源榨干是永恒的话题。集群调度层负责把任务分配到具体的机器和卡上。这一层要解决的核心矛盾是多个团队、多个任务抢同一批资源怎么分才公平又高效。常见的做法有排队、抢占、配额、优先级等等。这一层做得好不好直接决定了整个集群的利用率。任务运行层是任务真正执行的地方包括训练任务和推理任务。训练任务关注的是吞吐和收敛推理任务关注的是延迟和并发。两者的优化方向经常是相反的所以运行环境的设计也要区别对待。服务接入层是对外提供能力的地方包括API网关、负载均衡、限流熔断这些。这一层更接近传统后端服务的范畴但因为AI服务的特殊性比如单次请求耗时长、显存占用大又有很多不一样的地方。提示分层不是为了把问题割裂而是为了定位问题。当一个任务跑不起来时你可以从下往上逐层排查资源够不够、调度到没到、运行环境对不对、服务入口通不通。这个思路能帮你省下大量瞎猜的时间。2.2 为什么资源管理是绕不开的第一课很多人刚入行时觉得资源管理很无聊不就是分配机器吗但真正做过之后会发现资源管理是AI-Infra里性价比最高的一环。原因很简单算力太贵了。一张高端加速卡动辄几万块一个集群几百张卡就是几千万的投入。如果利用率只有百分之三四十那浪费的钱是实打实的。资源管理的核心目标可以概括成三个词高利用率、高公平性、低碎片化。这三个目标经常互相打架。追求高利用率就可能让某些任务一直排队公平性受损追求公平性搞平均分配又容易造成资源闲置想减少碎片就得做更复杂的装箱和迁移又增加了系统复杂度。我见过不少团队一开始用最简单的方式谁先来谁先用用完释放。这在人少任务少的时候没问题一旦规模上来就乱套了。有人占着卡不干活有人急任务排不上队最后只能靠人工协调效率极低。所以只要集群规模超过一个临界点我的经验是超过二三十张卡就必须上调度系统。调度策略的选择要看你的实际场景。如果是固定团队、任务类型单一简单的队列加优先级就够了。如果是多团队共享、任务类型混杂那就需要更细的配额管理和抢占机制。这里没有银弹关键是先想清楚你的核心矛盾是什么是利用率不够还是公平性不够还是响应速度不够。想清楚了这个选型就不会跑偏。2.3 训练与推理两种截然不同的工程思路训练和推理虽然都用同一批硬件但工程上的关注点差别很大我把它们比作盖楼和开店。训练是盖楼周期长、投入大、过程中可以容忍一些波动目标是最终把楼盖好推理是开店每天都要营业客人来了就得马上服务稳定性和响应速度是第一位的。训练任务的特点是长时间运行、资源占用大、对中断敏感。一个训练任务可能跑几天甚至几周中间如果因为机器故障中断了得能从检查点恢复。所以训练环境要重点考虑检查点怎么存、故障怎么检测、任务怎么自动重启。另外训练还涉及多机多卡通信网络带宽和延迟会直接影响训练速度这也是为什么训练集群通常要用高速互联。推理任务的特点是请求频繁、单次计算量相对小、对延迟极其敏感。用户发一个请求过来你不可能让他等几秒。所以推理环境要重点考虑怎么把模型加载得又快又省显存、怎么批量处理请求提高吞吐、怎么在流量高峰时自动扩容。推理还有个特点是模型更新频繁怎么做到不中断服务地更新模型也是个专门的课题。把这两类任务混在同一套环境里跑往往会互相干扰。训练任务把网络和显存占满了推理任务就卡了推理任务频繁启停又影响训练任务的稳定性。所以有条件的话训练和推理最好做物理或逻辑上的隔离。资源紧张没法隔离时至少要在调度层面做区分给推理任务更高的优先级和更严格的资源上限。3. 从零搭建AI-Infra的关键实操要点3.1 环境准备别急着装框架先把地基打牢新手最容易犯的错就是一上来就装各种AI框架结果环境冲突、驱动不匹配、版本对不上折腾几天都跑不起来。我的建议是先把基础环境理清楚再往上装东西。基础环境包括操作系统、显卡驱动、通信库、容器运行时。这四样东西的版本兼容性是后面一切工作的前提。操作系统层面主流选择是某个长期支持版本的Linux发行版。选它的理由不是因为它多先进而是因为生态最全、踩坑的人最多、遇到问题最容易搜到答案。显卡驱动要和硬件型号匹配这里有个经验不要盲目追最新版驱动。新驱动可能修了老bug但也可能引入新bug生产环境优先选经过验证的稳定版本。通信库这块如果是多机多卡训练会用到集合通信库。它的版本要和驱动、框架都对得上否则会出现通信超时、卡死这类很难排查的问题。我建议在搭建环境时把驱动版本、通信库版本、框架版本这三个信息记在一个文档里后面出问题时对照着看能省很多事。容器运行时现在基本是标配了。用容器最大的好处是环境隔离和可复现。你可以把整套环境打包成镜像换台机器直接跑不用重新配。但容器也有坑默认情况下容器看不到宿主机的显卡设备需要额外配置容器内的共享内存默认很小跑训练容易崩需要手动调大。这些都是我实际踩过的写在这里让你少走弯路。注意环境搭建阶段最忌讳能跑就行。这时候偷的懒会在后面调试性能问题时加倍还回来。花半天时间把版本关系理清楚比后面花三天排查一个玄学bug划算得多。3.2 资源池化把散落的算力聚成一股绳环境搭好之后下一步是把所有机器的算力统一管理起来。这一步的核心是资源池化也就是让上层任务不用关心自己跑在哪台机器上只需要说我要几张卡系统自动分配。资源池化要解决几个具体问题。第一是设备发现系统怎么知道集群里有哪些机器、每台机器有几张卡、卡的健康状态如何。这通常靠一个常驻的代理程序来上报。第二是资源抽象把物理卡抽象成可分配的逻辑资源同时记录每张卡的占用情况。第三是分配策略来了一个任务从哪些机器上凑出它需要的卡。这里有个容易被忽略的点卡和卡之间不是等价的。同一台机器内的卡通过高速总线互联通信快跨机器的卡通过网络互联通信慢。所以分配时尽量把需要频繁通信的任务放在同一台机器内这个原则叫亲和性调度。如果不管这个把一个大任务拆到好几台机器上通信开销可能比计算本身还大。还有一个实践中的细节显存碎片。一张卡的显存被反复分配释放后会变得零碎导致明明总量够却分配不出一块连续的大显存。解决办法一是尽量让任务独占整卡二是定期做资源整理。独占整卡虽然看起来浪费但省去了碎片管理的麻烦在卡数量不是特别紧张时我倾向于独占。资源池化做到位之后你会明显感觉到变化以前要人工协调这台机器空了你去用现在任务提交上去自动就跑了以前利用率靠感觉现在能看到实实在在的数字。这种从手工到自动的转变是AI-Infra建设里最有成就感的一步。3.3 任务编排让训练任务自己管好自己资源池化解决了卡从哪来的问题任务编排解决的是任务怎么跑好的问题。一个训练任务从提交到完成中间要经历排队、分配、启动、运行、检查点、结束这一系列阶段每个阶段都有讲究。排队阶段的关键是优先级和配额。不是所有任务都一样重要紧急的任务应该能插队但插队又不能把低优先级任务饿死。常见的做法是给每个团队分配配额配额内按优先级排超出配额的部分排队等。这样既保证了公平又留了灵活性。启动阶段的关键是环境注入。任务启动时要把正确的环境变量、挂载目录、网络配置都准备好。这里最容易出问题的是多机任务的网络配置机器之间要能互相通信还要知道彼此的地址。我见过不少任务卡在启动阶段最后发现是某台机器的防火墙规则没配对。运行阶段的关键是健康监控和故障恢复。训练任务跑着跑着可能某张卡出错了或者某台机器掉线了。系统要能检测到这些异常并决定是重启任务还是从检查点恢复。检查点的频率是个权衡存太勤IO压力大、训练变慢存太稀故障时丢的进度多。我的经验是根据任务总时长来定总时长几小时的任务半小时存一次比较合适。结束阶段的关键是资源回收和日志归档。任务结束后要确保资源被干净地释放不然会出现任务没了但卡还被占着的情况。日志要归档保存方便后面复盘。这些收尾工作看起来琐碎但做不好会积累成大的运维负担。3.4 推理服务把模型变成稳定可用的接口训练出来的模型最终要变成能对外服务的接口这一步就是推理服务部署。和训练相比推理服务更接近传统的后端服务但因为AI的特性又有不少特殊之处。第一个特殊之处是模型加载。一个大模型加载到显存里可能要几十秒甚至几分钟这期间服务是不可用的。解决办法是预热服务启动时先把模型加载好再开始接收请求。如果是多副本部署还要考虑滚动更新保证更新过程中始终有副本在服务。第二个特殊之处是批处理。单个推理请求可能用不满一张卡把多个请求攒成一批一起算能大幅提高吞吐。但攒批会引入等待时间增加延迟。所以批大小和等待时间要权衡。我的经验是对延迟敏感的场景批大小设小一点、等待时间设短一点对吞吐敏感的场景可以反过来。第三个特殊之处是显存管理。推理服务的显存占用是刚性的模型本身占一块中间计算结果占一块多个并发请求还会叠加。显存不够时要么拒绝请求要么排队。所以推理服务必须做限流控制并发数不能让请求无限堆积把服务压垮。第四个特殊之处是弹性伸缩。流量有高峰有低谷高峰时多开副本低谷时少开副本能省不少成本。但AI服务的扩容不像普通服务那么快因为加载模型要时间。所以扩容策略要提前不能等流量已经涨上来了才扩。通常的做法是根据历史流量预测提前扩容再配合实时监控做微调。4. 性能与稳定性一线最常踩的坑4.1 性能问题的排查思路性能问题最让人头疼的地方在于它往往不是单一原因造成的而是多个因素叠加。我总结了一套排查思路从粗到细逐层缩小范围。第一步是确认瓶颈在哪。是计算慢、通信慢、还是IO慢最简单的办法是看资源监控如果卡的计算利用率一直很高那是计算瓶颈如果利用率不高但任务就是慢那可能是通信或IO卡住了。这一步能排除掉一大半的错误方向。第二步是看时间花在哪。训练任务可以打点记录每个阶段数据加载、前向、反向、通信的耗时推理任务可以记录每个请求的处理时间。有了这些数据就知道该优化哪里。我见过有人一上来就优化模型计算结果发现时间全花在数据加载上白忙一场。第三步是做对比实验。改一个变量看性能变化。比如把批大小翻倍看吞吐是不是也翻倍把通信库换个版本看是不是变快。对比实验要注意一次只改一个变量不然分不清是哪个改动起的作用。第四步是看底层指标。如果上层看不出来就往下钻看网络带宽有没有跑满、看磁盘IO有没有打满、看显存有没有频繁换入换出。这些底层指标往往能揭示真正的原因。提示性能优化最忌讳我觉得。所有判断都要有数据支撑。养成看监控、打日志的习惯比凭经验猜要靠谱得多。4.2 稳定性问题的常见类型稳定性问题比性能问题更棘手因为它往往偶发、难复现。我把常见的稳定性问题分成几类每类的应对思路不一样。第一类是资源泄漏。任务跑着跑着显存或内存慢慢涨上去最后撑爆。这类问题通常是代码里有没释放的资源或者缓存没清理。排查方法是长时间监控资源曲线看是不是单调上升。解决方法是加资源上限超了就重启同时定位泄漏点。第二类是通信超时。多机任务里某台机器响应慢了其他机器等它最后集体超时。这类问题可能是网络抖动、也可能是某台机器负载太高。排查方法是看各机器的日志找出是哪台先出问题。解决方法是设置合理的超时时间并做好重试。第三类是死锁和卡死。任务不动了也不报错就是卡在那。这类问题最难查因为没有任何错误信息。常见原因是通信库的某个操作没配对或者某个进程挂了导致其他进程一直等。排查方法是抓取各进程的调用栈看卡在哪个函数。解决方法是升级通信库版本或者调整任务配置。第四类是数据问题。训练突然崩了发现是某条数据格式不对推理结果异常发现是输入没做校验。这类问题的根源在数据管道解决方法是加强数据校验和清洗把问题挡在入口。4.3 一份实用的排查速查表为了让你在遇到问题时能快速定位我整理了一份速查表。这张表是我自己工作中总结的覆盖了最常见的几类问题。现象可能原因排查方向应对措施任务启动即失败环境变量缺失、驱动不匹配看启动日志、核对版本补齐环境变量、统一版本训练速度远低于预期数据加载慢、通信瓶颈打点各阶段耗时优化数据管道、检查网络显存不足报错批太大、碎片、泄漏看显存曲线减小批、独占整卡、查泄漏多机任务卡死通信超时、某机故障看各机日志、抓调用栈设超时、重试、隔离故障机推理延迟忽高忽低批处理波动、资源争抢看请求分布、看资源占用调批策略、做资源隔离服务突然不可用显存爆、进程崩、被限流看服务日志、看监控加限流、加健康检查、自动重启这张表不是万能的但能覆盖大部分日常问题。遇到表里没有的情况就回到上一节的排查思路从粗到细逐层分析。4.4 那些文档里不会写的经验最后分享几条我在实际工作中总结的经验这些在官方文档里基本看不到但特别实用。第一条给每个任务设资源上限。不管是训练还是推理都要设显存和内存的上限。不设上限的任务一旦出问题就会拖垮整台机器影响其他任务。设了上限最坏情况也只是这个任务自己挂掉。第二条日志要分级、要集中。任务多起来之后日志散落在各台机器上查问题要一台台登效率极低。把日志集中收集起来按级别分类能大幅提升排查效率。错误日志要能触发告警别等用户反馈了才知道出问题。第三条变更要可回滚。不管是升级驱动、换框架版本、还是改调度策略都要有回滚方案。我见过太多因为一次变更导致整个集群不可用的事故有回滚方案的话几分钟就能恢复。第四条定期做故障演练。故意拔掉一张卡、故意断掉一台机器看系统能不能自动恢复。这种演练能暴露很多平时发现不了的问题。演练时要在非高峰时段做做好数据备份。第五条别忽视小问题。偶尔一次任务失败、偶尔一次延迟升高看起来不影响大局但可能是大故障的前兆。养成记录和分析这些小问题的习惯能帮你提前发现隐患。AI-Infra这个方向说到底是一门实践的手艺。看再多文章不如亲手搭一次环境、跑一次任务、排一次故障。我个人的体会是每解决一个真实问题对这个领域的理解就深一层。那些看起来高大上的调度算法、通信优化最终都要落到让任务跑得更快更稳这个朴素的目標上。这条路没有捷径但每一步都算数。 
长河君 · 2026/10/14 22:27:17 · 阅读 1.2k AI-Infra一线实战：从资源管理到推理服务的核心工程指南
1. 为什么一线工程师都在聊AI-Infra这两年技术圈有个很明显的现象做业务开发的工程师开始往底层走做运维的工程师开始往AI方向靠而原本做算法的那批人反而在补系统工程这门课。三条线交汇的地方就是AI-Infra也就是人工智能基础设施。我在一线做系统相关的工作有些年头了最近一年明显感觉到身边越来越多的同行在讨论显存怎么分、训练任务怎么排队、推理服务怎么把延迟压下去。这不是赶时髦而是真实的工程需求倒逼出来的。先说清楚AI-Infra到底是个什么东西。你可以把它理解成让AI模型能跑起来、跑得快、跑得稳的那一整套工程体系。它不负责设计模型结构也不负责调参炼丹它负责的是算力怎么组织、数据怎么喂进去、任务怎么调度、服务怎么稳定对外。打个比方算法工程师是造车的AI-Infra工程师是修路、建加油站、搞交通调度的。车再好路不通、油供不上照样跑不起来。那为什么是一线工程师在聊这个因为AI-Infra最大的特点就是离真实环境特别近。你在实验室里跑通一个demo和你在生产环境里让几百张卡同时干活完全是两码事。显存会碎片化、网络会抖动、磁盘IO会成为瓶颈、任务会莫名其妙卡住。这些问题不会写在论文里只会出现在凌晨三点的告警群里。所以真正有价值的AI-Infra经验往往来自那些亲手踩过坑的一线人员。这篇内容适合谁看如果你是刚接触AI工程的后端或运维工程师想搞清楚这个方向到底要学什么那这篇能帮你建立整体认知。如果你已经在做相关的工作但总觉得知识是零散的那这篇能帮你把碎片串成线。如果你纯粹是好奇想知道那些大模型背后到底靠什么撑着那也能看个明白。我会尽量少用黑话多用类比把每个关键选择背后的为什么讲清楚。需要提前说明的是AI-Infra这个领域非常宽一篇文章不可能讲完。这一章我聚焦在最核心的几块算力资源怎么管、训练任务怎么跑、推理服务怎么部署以及贯穿始终的性能与稳定性问题。这些都是无论你用什么框架、什么硬件都绕不开的基本功。后面如果继续写会再深入到具体的调度系统、通信优化、存储方案这些更细的层面。2. AI-Infra的核心版图与能力拆解2.1 一张图看懂AI-Infra的四个层次我习惯把AI-Infra分成四层来看从下往上分别是硬件资源层、集群调度层、任务运行层、服务接入层。这个分法不是教科书上的标准答案而是我在实际工作中觉得最好理解、最好定位问题的一种切法。硬件资源层就是最底下的物理设备包括GPU、CPU、内存、网卡、存储。这一层的关键词是异构和稀缺。异构是说设备种类多、型号杂不同代的卡混在一起是常态稀缺是说好的算力永远不够用怎么把有限的资源榨干是永恒的话题。集群调度层负责把任务分配到具体的机器和卡上。这一层要解决的核心矛盾是多个团队、多个任务抢同一批资源怎么分才公平又高效。常见的做法有排队、抢占、配额、优先级等等。这一层做得好不好直接决定了整个集群的利用率。任务运行层是任务真正执行的地方包括训练任务和推理任务。训练任务关注的是吞吐和收敛推理任务关注的是延迟和并发。两者的优化方向经常是相反的所以运行环境的设计也要区别对待。服务接入层是对外提供能力的地方包括API网关、负载均衡、限流熔断这些。这一层更接近传统后端服务的范畴但因为AI服务的特殊性比如单次请求耗时长、显存占用大又有很多不一样的地方。提示分层不是为了把问题割裂而是为了定位问题。当一个任务跑不起来时你可以从下往上逐层排查资源够不够、调度到没到、运行环境对不对、服务入口通不通。这个思路能帮你省下大量瞎猜的时间。2.2 为什么资源管理是绕不开的第一课很多人刚入行时觉得资源管理很无聊不就是分配机器吗但真正做过之后会发现资源管理是AI-Infra里性价比最高的一环。原因很简单算力太贵了。一张高端加速卡动辄几万块一个集群几百张卡就是几千万的投入。如果利用率只有百分之三四十那浪费的钱是实打实的。资源管理的核心目标可以概括成三个词高利用率、高公平性、低碎片化。这三个目标经常互相打架。追求高利用率就可能让某些任务一直排队公平性受损追求公平性搞平均分配又容易造成资源闲置想减少碎片就得做更复杂的装箱和迁移又增加了系统复杂度。我见过不少团队一开始用最简单的方式谁先来谁先用用完释放。这在人少任务少的时候没问题一旦规模上来就乱套了。有人占着卡不干活有人急任务排不上队最后只能靠人工协调效率极低。所以只要集群规模超过一个临界点我的经验是超过二三十张卡就必须上调度系统。调度策略的选择要看你的实际场景。如果是固定团队、任务类型单一简单的队列加优先级就够了。如果是多团队共享、任务类型混杂那就需要更细的配额管理和抢占机制。这里没有银弹关键是先想清楚你的核心矛盾是什么是利用率不够还是公平性不够还是响应速度不够。想清楚了这个选型就不会跑偏。2.3 训练与推理两种截然不同的工程思路训练和推理虽然都用同一批硬件但工程上的关注点差别很大我把它们比作盖楼和开店。训练是盖楼周期长、投入大、过程中可以容忍一些波动目标是最终把楼盖好推理是开店每天都要营业客人来了就得马上服务稳定性和响应速度是第一位的。训练任务的特点是长时间运行、资源占用大、对中断敏感。一个训练任务可能跑几天甚至几周中间如果因为机器故障中断了得能从检查点恢复。所以训练环境要重点考虑检查点怎么存、故障怎么检测、任务怎么自动重启。另外训练还涉及多机多卡通信网络带宽和延迟会直接影响训练速度这也是为什么训练集群通常要用高速互联。推理任务的特点是请求频繁、单次计算量相对小、对延迟极其敏感。用户发一个请求过来你不可能让他等几秒。所以推理环境要重点考虑怎么把模型加载得又快又省显存、怎么批量处理请求提高吞吐、怎么在流量高峰时自动扩容。推理还有个特点是模型更新频繁怎么做到不中断服务地更新模型也是个专门的课题。把这两类任务混在同一套环境里跑往往会互相干扰。训练任务把网络和显存占满了推理任务就卡了推理任务频繁启停又影响训练任务的稳定性。所以有条件的话训练和推理最好做物理或逻辑上的隔离。资源紧张没法隔离时至少要在调度层面做区分给推理任务更高的优先级和更严格的资源上限。3. 从零搭建AI-Infra的关键实操要点3.1 环境准备别急着装框架先把地基打牢新手最容易犯的错就是一上来就装各种AI框架结果环境冲突、驱动不匹配、版本对不上折腾几天都跑不起来。我的建议是先把基础环境理清楚再往上装东西。基础环境包括操作系统、显卡驱动、通信库、容器运行时。这四样东西的版本兼容性是后面一切工作的前提。操作系统层面主流选择是某个长期支持版本的Linux发行版。选它的理由不是因为它多先进而是因为生态最全、踩坑的人最多、遇到问题最容易搜到答案。显卡驱动要和硬件型号匹配这里有个经验不要盲目追最新版驱动。新驱动可能修了老bug但也可能引入新bug生产环境优先选经过验证的稳定版本。通信库这块如果是多机多卡训练会用到集合通信库。它的版本要和驱动、框架都对得上否则会出现通信超时、卡死这类很难排查的问题。我建议在搭建环境时把驱动版本、通信库版本、框架版本这三个信息记在一个文档里后面出问题时对照着看能省很多事。容器运行时现在基本是标配了。用容器最大的好处是环境隔离和可复现。你可以把整套环境打包成镜像换台机器直接跑不用重新配。但容器也有坑默认情况下容器看不到宿主机的显卡设备需要额外配置容器内的共享内存默认很小跑训练容易崩需要手动调大。这些都是我实际踩过的写在这里让你少走弯路。注意环境搭建阶段最忌讳能跑就行。这时候偷的懒会在后面调试性能问题时加倍还回来。花半天时间把版本关系理清楚比后面花三天排查一个玄学bug划算得多。3.2 资源池化把散落的算力聚成一股绳环境搭好之后下一步是把所有机器的算力统一管理起来。这一步的核心是资源池化也就是让上层任务不用关心自己跑在哪台机器上只需要说我要几张卡系统自动分配。资源池化要解决几个具体问题。第一是设备发现系统怎么知道集群里有哪些机器、每台机器有几张卡、卡的健康状态如何。这通常靠一个常驻的代理程序来上报。第二是资源抽象把物理卡抽象成可分配的逻辑资源同时记录每张卡的占用情况。第三是分配策略来了一个任务从哪些机器上凑出它需要的卡。这里有个容易被忽略的点卡和卡之间不是等价的。同一台机器内的卡通过高速总线互联通信快跨机器的卡通过网络互联通信慢。所以分配时尽量把需要频繁通信的任务放在同一台机器内这个原则叫亲和性调度。如果不管这个把一个大任务拆到好几台机器上通信开销可能比计算本身还大。还有一个实践中的细节显存碎片。一张卡的显存被反复分配释放后会变得零碎导致明明总量够却分配不出一块连续的大显存。解决办法一是尽量让任务独占整卡二是定期做资源整理。独占整卡虽然看起来浪费但省去了碎片管理的麻烦在卡数量不是特别紧张时我倾向于独占。资源池化做到位之后你会明显感觉到变化以前要人工协调这台机器空了你去用现在任务提交上去自动就跑了以前利用率靠感觉现在能看到实实在在的数字。这种从手工到自动的转变是AI-Infra建设里最有成就感的一步。3.3 任务编排让训练任务自己管好自己资源池化解决了卡从哪来的问题任务编排解决的是任务怎么跑好的问题。一个训练任务从提交到完成中间要经历排队、分配、启动、运行、检查点、结束这一系列阶段每个阶段都有讲究。排队阶段的关键是优先级和配额。不是所有任务都一样重要紧急的任务应该能插队但插队又不能把低优先级任务饿死。常见的做法是给每个团队分配配额配额内按优先级排超出配额的部分排队等。这样既保证了公平又留了灵活性。启动阶段的关键是环境注入。任务启动时要把正确的环境变量、挂载目录、网络配置都准备好。这里最容易出问题的是多机任务的网络配置机器之间要能互相通信还要知道彼此的地址。我见过不少任务卡在启动阶段最后发现是某台机器的防火墙规则没配对。运行阶段的关键是健康监控和故障恢复。训练任务跑着跑着可能某张卡出错了或者某台机器掉线了。系统要能检测到这些异常并决定是重启任务还是从检查点恢复。检查点的频率是个权衡存太勤IO压力大、训练变慢存太稀故障时丢的进度多。我的经验是根据任务总时长来定总时长几小时的任务半小时存一次比较合适。结束阶段的关键是资源回收和日志归档。任务结束后要确保资源被干净地释放不然会出现任务没了但卡还被占着的情况。日志要归档保存方便后面复盘。这些收尾工作看起来琐碎但做不好会积累成大的运维负担。3.4 推理服务把模型变成稳定可用的接口训练出来的模型最终要变成能对外服务的接口这一步就是推理服务部署。和训练相比推理服务更接近传统的后端服务但因为AI的特性又有不少特殊之处。第一个特殊之处是模型加载。一个大模型加载到显存里可能要几十秒甚至几分钟这期间服务是不可用的。解决办法是预热服务启动时先把模型加载好再开始接收请求。如果是多副本部署还要考虑滚动更新保证更新过程中始终有副本在服务。第二个特殊之处是批处理。单个推理请求可能用不满一张卡把多个请求攒成一批一起算能大幅提高吞吐。但攒批会引入等待时间增加延迟。所以批大小和等待时间要权衡。我的经验是对延迟敏感的场景批大小设小一点、等待时间设短一点对吞吐敏感的场景可以反过来。第三个特殊之处是显存管理。推理服务的显存占用是刚性的模型本身占一块中间计算结果占一块多个并发请求还会叠加。显存不够时要么拒绝请求要么排队。所以推理服务必须做限流控制并发数不能让请求无限堆积把服务压垮。第四个特殊之处是弹性伸缩。流量有高峰有低谷高峰时多开副本低谷时少开副本能省不少成本。但AI服务的扩容不像普通服务那么快因为加载模型要时间。所以扩容策略要提前不能等流量已经涨上来了才扩。通常的做法是根据历史流量预测提前扩容再配合实时监控做微调。4. 性能与稳定性一线最常踩的坑4.1 性能问题的排查思路性能问题最让人头疼的地方在于它往往不是单一原因造成的而是多个因素叠加。我总结了一套排查思路从粗到细逐层缩小范围。第一步是确认瓶颈在哪。是计算慢、通信慢、还是IO慢最简单的办法是看资源监控如果卡的计算利用率一直很高那是计算瓶颈如果利用率不高但任务就是慢那可能是通信或IO卡住了。这一步能排除掉一大半的错误方向。第二步是看时间花在哪。训练任务可以打点记录每个阶段数据加载、前向、反向、通信的耗时推理任务可以记录每个请求的处理时间。有了这些数据就知道该优化哪里。我见过有人一上来就优化模型计算结果发现时间全花在数据加载上白忙一场。第三步是做对比实验。改一个变量看性能变化。比如把批大小翻倍看吞吐是不是也翻倍把通信库换个版本看是不是变快。对比实验要注意一次只改一个变量不然分不清是哪个改动起的作用。第四步是看底层指标。如果上层看不出来就往下钻看网络带宽有没有跑满、看磁盘IO有没有打满、看显存有没有频繁换入换出。这些底层指标往往能揭示真正的原因。提示性能优化最忌讳我觉得。所有判断都要有数据支撑。养成看监控、打日志的习惯比凭经验猜要靠谱得多。4.2 稳定性问题的常见类型稳定性问题比性能问题更棘手因为它往往偶发、难复现。我把常见的稳定性问题分成几类每类的应对思路不一样。第一类是资源泄漏。任务跑着跑着显存或内存慢慢涨上去最后撑爆。这类问题通常是代码里有没释放的资源或者缓存没清理。排查方法是长时间监控资源曲线看是不是单调上升。解决方法是加资源上限超了就重启同时定位泄漏点。第二类是通信超时。多机任务里某台机器响应慢了其他机器等它最后集体超时。这类问题可能是网络抖动、也可能是某台机器负载太高。排查方法是看各机器的日志找出是哪台先出问题。解决方法是设置合理的超时时间并做好重试。第三类是死锁和卡死。任务不动了也不报错就是卡在那。这类问题最难查因为没有任何错误信息。常见原因是通信库的某个操作没配对或者某个进程挂了导致其他进程一直等。排查方法是抓取各进程的调用栈看卡在哪个函数。解决方法是升级通信库版本或者调整任务配置。第四类是数据问题。训练突然崩了发现是某条数据格式不对推理结果异常发现是输入没做校验。这类问题的根源在数据管道解决方法是加强数据校验和清洗把问题挡在入口。4.3 一份实用的排查速查表为了让你在遇到问题时能快速定位我整理了一份速查表。这张表是我自己工作中总结的覆盖了最常见的几类问题。现象可能原因排查方向应对措施任务启动即失败环境变量缺失、驱动不匹配看启动日志、核对版本补齐环境变量、统一版本训练速度远低于预期数据加载慢、通信瓶颈打点各阶段耗时优化数据管道、检查网络显存不足报错批太大、碎片、泄漏看显存曲线减小批、独占整卡、查泄漏多机任务卡死通信超时、某机故障看各机日志、抓调用栈设超时、重试、隔离故障机推理延迟忽高忽低批处理波动、资源争抢看请求分布、看资源占用调批策略、做资源隔离服务突然不可用显存爆、进程崩、被限流看服务日志、看监控加限流、加健康检查、自动重启这张表不是万能的但能覆盖大部分日常问题。遇到表里没有的情况就回到上一节的排查思路从粗到细逐层分析。4.4 那些文档里不会写的经验最后分享几条我在实际工作中总结的经验这些在官方文档里基本看不到但特别实用。第一条给每个任务设资源上限。不管是训练还是推理都要设显存和内存的上限。不设上限的任务一旦出问题就会拖垮整台机器影响其他任务。设了上限最坏情况也只是这个任务自己挂掉。第二条日志要分级、要集中。任务多起来之后日志散落在各台机器上查问题要一台台登效率极低。把日志集中收集起来按级别分类能大幅提升排查效率。错误日志要能触发告警别等用户反馈了才知道出问题。第三条变更要可回滚。不管是升级驱动、换框架版本、还是改调度策略都要有回滚方案。我见过太多因为一次变更导致整个集群不可用的事故有回滚方案的话几分钟就能恢复。第四条定期做故障演练。故意拔掉一张卡、故意断掉一台机器看系统能不能自动恢复。这种演练能暴露很多平时发现不了的问题。演练时要在非高峰时段做做好数据备份。第五条别忽视小问题。偶尔一次任务失败、偶尔一次延迟升高看起来不影响大局但可能是大故障的前兆。养成记录和分析这些小问题的习惯能帮你提前发现隐患。AI-Infra这个方向说到底是一门实践的手艺。看再多文章不如亲手搭一次环境、跑一次任务、排一次故障。我个人的体会是每解决一个真实问题对这个领域的理解就深一层。那些看起来高大上的调度算法、通信优化最终都要落到让任务跑得更快更稳这个朴素的目標上。这条路没有捷径但每一步都算数。