AI Infra 工程师们如何应对大模型流水线里的“暗涌”?
仅用于站内搜索,没有排版格式,具体信息请跳转上方微信公众号内链接
作者|AICon全球人工智能开发与应用大会
策划|罗燕珊
编辑|宇琪
Infra虽然是看不见的“底座”,但它却承担着支撑整个大模型系统运行的重量。那么,Infra工程师在日常工作中会遇到哪些真实需求与故障类型?开源Infra和国产卡适配训练推进过程中,又会遇到哪些难点和挑战呢?
近日InfoQ《极客有约》XAICon直播栏目特别邀请了华为昇腾技术专家ZOMI酱、蚂蚁集团高级专家马介悦和SGLang核心开发者尹良升一起,在AICon全球人工智能开发与应用大会2025北京站即将召开之际,共同探讨大模型Infra工程师的实战日常。
部分精彩观点如下:
并行策略兼容性体现的是代码实现的耦合度挑战,而工程流水线管理则关乎功能开发全周期的资源分配与风险控制。
高效的工程化实践离不开强大的性能剖析和监控系统支持,仅靠人工排查效率低下。
充分利用异构硬件特性、实现跨类型资源的智能调度与混部,已成为AI基础设施演进的重要方向。
在6月27-28日将于北京举办的AICon全球人工智能开发与应用大会上,我们特别设置了【AI基础设施与生态构建】专题。该专题将聚焦AI软硬件及生态系统的建设,讨论如何打造高效的AI开发与应用环境。查看大会日程解锁更多精彩内容:https ://aicon. infoq.cn/2025/beijing/schedule
以下内容基于直播速记整理,经InfoQ删减。
完整直播回放可查看:https ://www. infoq.cn/video/kx2h235pHrE7fENMaxlH
大模型工程中的高频问题
ZOMI:你们应该都经常接到“线上告急”吧——比如训练挂了、推理跑不动……最近你们最常遇到的用户需求,或者说大家最常抱怨的问题是什么?有没有一些“听得最多”的关键词?
马介悦:根据我的经验,线上训练过程中会遇到各种问题,包括稳定性问题、业务算法或程序本身的缺陷,或者训练框架本身的问题。例如训练任务中断(“跑挂”)就很常见,特别是在千卡或万卡级别的大规模集群上。GPU本身存在一定的错误率,对于一个万卡集群来说,每天出现不同的GPU故障几乎是必然的。
训练是一个同步过程,任何单卡故障都可能导致整个训练停滞或失败,因此这种现象很普遍。我近期专注于解决这类稳定性问题,早期遇到此类问题时,若缺乏自动化运维系统,只能依赖人工响应报警,由运维工程师手动重启相关任务。然而我们发现,即使重启任务,也常常会再次中断。这可能是硬件本身存在问题,或者由于集群涉及环节众多。
从宏观角度看,问题可能源自底层网络系统、交换机、光模块、计算节点本身,节点上的每块GPU都是一个潜在故障点,此外还包括内存、CPU宕机等风险。例如,GPU经常出现ECC错误,导致CUDA报错、进程退出。如果运维工程师无法准确定位故障机器,任务重启后运行一段时间很可能再次中断,这种情况令人非常困扰。
早期尝试过使用二分法等运维手段,或通过错误日志、带外管理(out-of-band)方法来定位故障机器,但当时的准确率不高。这可能导致误判,错误更换机器后任务重启仍会失败,问题非常棘手,以上主要涉及硬件或底层基础设施问题。
此外,对于“跑飞”,我理解为loss异常飙升,其成因更为复杂,可能源于算法本身缺陷、并行框架问题或数据错误等,排查需要Infra工程师与业务工程师协作,难度较大。还有其他类型的问题,例如任务启动后无法完成第一个训练步,这通常与业务代码相关。作为Infra工程师,我们也需要协助客户排查此类问题。常见原因包括Python使用不当、库引用错误、软件包版本冲突、环境配置问题或CUDA驱动故障等。
尹良升:我们主要面向合作公司或科研机构提供代码和开源更新,协助他们实现最佳性能和最佳的可用性,而非直接接触真实的线上推理环境部署。因此,当高校、科研机构或公司在进行模型部署或大规模线下推理的工作流出现问题时,我们往往是首先接到反馈的一方。这种情况下,我听到最多的关键词主要来自两个方面。
第一方面是运行时错误。这类错误可能源于我们代码中未发现的bug,也可能是用户在部署过程中的配置错误所致。例如,某些用户错误调整了GPU显存分配参数,便可能导致显存分配溢出(OOM)错误。此时,需要熟悉社区代码的工程师与一线部署人员深入沟通,精确定位问题代码行,分析是哪个配置参数设置不当,进而找到解决方案以消除部署时的运行时错误。
第二方面是性能问题。用户在部署时,即使使用相同的硬件卡和部署策略,也可能发现其性能无法匹配我们官方的测试报告,进而质疑报告数据的真实性或怀疑我们进行了选择性测试(cherrypick)。实际上,用户复现结果与官方数据存在差异的原因是多方面的。常见原因包括配置问题、软件版本差异,以及测试数据集未能完全一致地迁移到用户环境所导致的数据偏差。
此外,线上推理流程的各个环节出现问题也可能导致性能不符合预期。从接收请求(request)、首次预填充(prefill)到每个解码(decode)步骤,任一阶段的异常都可能引起延迟(latency)偏高。同样,分配给KVcache的内存(GPUmemory)分配不足也会导致推理的批次(batchsize)降低从而吞吐量(throughput)未达预期。解决这类问题,需要深入代码层面,具体分析问题环节,进行点对点的优化或配置修正。综合来看,性能问题和运行时错误确实是用户反馈中最常提及的两类紧急问题。
ZOMI:我个人更关注训练环节。在昇腾工作期间,主要聚焦于服务大客户的推理集群。遇到的问题首先是如何应对训练任务中断。在万卡甚至十万卡级别的集群中,硬件故障不可避免,特别是在持续训练两个月的大型模型任务中。其次是如何处理损失函数异常飙升。这需要判断是不同硬件差异、算法本身缺陷、客户代码错误,还是分布式并行处理时出现了问题。因此,解决这些问题往往需要Infra团队与算法团队进行更紧密的合作。
ZOMI:如果把大模型的工程流程当作一条流水线,你们觉得哪一段最容易出问题?是资源调度、作业调优,还是并行策略不兼容?
尹良升:针对并行策略不兼容的问题,我以SGLang社区上个月复现DeepSeekBlog的实践为例。我们采用了名为“MultiTokenPrediction”(MTP,推测解码)的策略来有效降低token输出延迟。然而,在初始实现中,MTP与包括“Data-ParallelAttention”(数据并行注意力机制)在内的多个功能存在兼容性问题。这种不兼容性通常并非源于策略设计本身,而是代码实现过程中的兼容性与解耦不足所致:为快速交付新功能,可能暂时忽略了与现有功能的兼容性。
实际部署中,往往需要同时启用MTP、DPAttention、大规模张量并行(EP)等多项功能才能达到“满血版”最优性能。但实现功能间的完全兼容需经历代码重构与解耦过程,从初步实现到最终兼容存在较长的阵痛期。这既不可避免,也高度考验工程师的代码能力与全局设计观。
若从工程流水线角度讨论资源调度与作业调优,此处我理解为推理引擎的功能开发流程而非训练资源调度,核心在于新功能开发的科学管理。开发关键功能需经过充分调研与实验验证,一个功能最终合并到主分支往往涉及大量代码和严格测试。若验证表明功能未达预期效果,前期投入可能付诸东流。因此,流水线中需重点关注功能的前期可行性验证、开发阶段的合理规划以及最终测试策略的设计,这些环节是保障效率与质量的关键,也容易产生问题。并行策略兼容性体现的是代码实现的耦合度挑战,而工程流水线管理则关乎功能开发全周期的资源分配与风险控制。
ZOMI:在版本迭代过程中,当Roadmap规划的新特性因算法演进需求必须上线时,常会遇到其与旧有算法或并行策略不兼容的情况。然而,新特性无法放弃,旧特性也不能直接移除。因此,确实需要经历多个版本的持续迭代与磨合,逐步排查和解决其中的细节问题与分支冲突,仅依赖CI流水线持续集成进行保障可能不够充分。我们的处理方式通常是:将冲突特性暂时分置于不同版本或允许独立启用,并在后续版本中进行整合维护。请问你们也是采用类似策略吗?
尹良升:是的。这里可分为两种开发逻辑:一种是敏捷交付优先:确保每个新特性快速交付,同时保证不影响现有功能的正常启用。另一种是渐进式重构:若新功能并非紧急需求,且强行集成可能对现有代码造成较大破坏,则选择将该功能拆解为多个PR,分步骤进行重构。确保每个中间步骤都保持代码库的完整可用状态,最终通过最后一个PR实现新功能与旧特性的完全兼容。具体采用哪种方式,需根据功能需求的紧迫性以及不同方案的实现难度综合评估。
马介悦:工程化可分为研发流程与部署上线两方面。研发环节,如代码开发、功能交付与传统系统软件开发差异不大,都依赖严格的代码审查、门禁(gatekeeping)、自动化测试和用例覆盖。核心在于门禁流水线的设计,例如每个PR合并前必须通过完整的门禁流水线测试。但关键挑战在于性能“门禁”常受资源限制:线上可能使用万卡规模训练,但CI流水线通常仅能在8卡或更小规模运行,导致许多大规模问题在PR阶段无法暴露。对此,目前尚无完美解决方案,只能在问题于线上大规模复现后由工程师介入处理。
另一个研发痛点是:若单次版本更新包含过多新功能,一旦导致机器浮点运算利用率(MFU)下降,难以定位具体是哪个PR引入的问题。目前主要依赖二分法或逐版本回退测试来排查,工程师间的代码审查在此环节至关重要。此外,研发和线上环节都需重视性能剖析(profiling)——即便小规模无法复现问题,也应记录火焰图和时间线,为后续分析MFU退化提供依据,帮助诊断并行切分是否合理。
关于部署上线,其流程基于云原生:首先通过Kubernetes以Pod形式分配资源;随后由DLRover启动训练,并在训练前执行预检和组网检测,确保硬件无故障、环境无异常、通信(如NCCL)连接正常。预检通过后,训练主导权移交至框架。训练中核心监控指标是MFU,它反映集群算力利用率。MFU下降通常意味着并行切分(如TP/EP/PP/DP)策略存在问题,导致计算流中出现等待“bubble”,这需在研发阶段通过大量实验优化模型切分策略。
MFU下降也可能由稳定性问题引发,例如训练卡死(hang)。卡死成因复杂,硬件、算法、框架均可能,且硬件问题有时不会触发进程报错退出,仅表现为指标异常。虽然业界已有多种检测卡死的方法,如通过业务指标、metrics或DLRover的xproftimer等性能剖析工具,但定位卡死的根本原因比检测现象更困难。若有强大的底层基础设施团队能快速识别并驱逐故障机,问题较易解决;否则需综合日志、metrics和性能剖析数据进行深度诊断。
类似问题还包括“straggler”场景:训练步耗时逐渐增加。监测到该现象相对简单,但定位根因(硬件、网络、数据集或切分策略问题)则需复杂的综合判断逻辑。
综上,高效的工程化实践离不开强大的性能剖析和监控系统支持,仅靠人工排查效率低下。常用工具包括PyTorchProfiler、GPU监控系统、各公司自研监控组件,以及DLRover的xproftimer等。其核心是记录底层CUDA算子执行时间、Python进程调用栈等信息,生成时间线和火焰图,为SRE和研发人员提供关键的排障依据。
推理部署如何
“压榨每一分显存”?
ZOMI:现在大家都在卷“大模型低成本”,你们觉得在哪些环节最有“优化价值”?是推理时的缓存策略?训练时的容错调度?
尹良升:我认为当前降低大模型成本是行业共识。从推理部署角度看,随着大模型普及,其使用量将激增,最终会像可随时调用的API一样融入生活。因此,将大模型的推理成本压至最低至关重要。
从推理角度降低大模型成本,我认为主要有三个方面。首先,今年3月DeepSeek官方博客展示了其通过大规模卡群部署及PD分离节点策略,成功将API价格压至前所未有的低点。这启示我们,从系统层面看,特定的部署方式能有效降低成本。例如,采用稀疏MoE架构时,每次推理仅激活少量参数。若使用大量专家并行,等效于单卡承载的模型权重显著减少。这带来一个直观优势:模型权重在卡间分布更稀疏且未大量复制,因此占用显存减少,释放出的显存便可容纳更大的KV缓存,是大模型推理降成本的核心直觉之一。
它引出的关键点在于:模型架构设计需与最终上线部署进行联合设计。在模型设计或训练阶段就需考虑未来推理性能,例如设计更多专家数并利用其架构特性,如MoE天然适合数据并行,因其不同专家的权重可直接存于不同GPU上。这种前期与后期的协同设计,可能是实现大模型成本持续下降最重要且基础的一步。
其次,在推理时的缓存策略方面,当前普遍做法是将每轮对话后的KV缓存转储至CPU内存或文件系统,因为非GPU内存相对廉价且可视为资源富余。因此,如何高效加载KV缓存、设计显存到内存间KV缓存的驱逐策略,涉及内存管理与多级缓存管理策略,仍有优化空间。在多轮对话场景下,用户可能间隔数十秒才复用KV缓存;但在Agent工作流中,触发由既定逻辑或者工作流控制,其KV缓存的驱逐策略便截然不同。针对特定工作流定制调度策略,包括KV缓存的驱逐与重加载,是当前热门研究方向,也是降低推理成本的重要途径。
第三点涉及如何提高GPU的极限利用率。当前主要依赖GPU计算,若CPU资源管理不当,会阻塞GPU运行,导致GPU出现空闲,无法时刻满载。这源于推理流设计或实现上的缺陷,引入了不必要的同步。解决此问题需要工程与算法的协同优化,例如DeepSeek采用“双批次重叠”策略,将计算与通信阶段错开以掩盖通信开销并提升GPU利用率。又如SGLang框架,通过OverlapScheduling,延迟token调度完全隐藏了CPU开销。这些都是提升资源利用率、压榨GPU推理性能的关键创新点。
第三点核心在于优化调度开销。传统流程(调度批次->启动内核->执行计算)中,调度和启动内核作为CPU密集型任务易阻塞后续流程。SGLang中的OverlapScheduling重新设计工作流,允许GPU执行当前批次时,CPU并行准备下一批次,消除CPU准备阶段的GPU闲置。虽然这提升了GPU利用效率,但也面临兼容性挑战,如与MTP的整合,这正是功能迭代中不可避免的“阵痛期”。
马介悦:我想从硬件角度再谈一点:英伟达GPU的领先很大程度上得益于其NVLink/NVSwitch机制,它极大提升了单机节点内的GPU通信效率。相比之下,跨节点通信,无论使用InfiniBand还是RoCE,其性能较NVSwitch存在约一个数量级的差距。
因此,提升性价比的关键在于:将大量节点整合到大型机柜内。这不仅能节省交换机等模块的成本(虽然GPU仍是训练集群的主要成本,但网络成本占比已不容忽视),更重要的是,通过NVLink的“拉远”互联技术,能够将跨节点通信带宽提升至接近节点内水平。传统架构中,节点内走高速NVLink,节点间走相对低速的InfiniBand/RoCE,存在性能降级。大型机柜方案则通过统一的总线级互联技术消除这一断层,显著提升整体并行性能。我们的实践也验证了这一点:仅更换为类似CloudMatrix的硬件架构,实测性能提升便非常可观。
所以,成本优化不仅关乎价格,更需关注性价比,即同等模型MFU下的单位成本。大型集成硬件初期投入可能更高,但如果能大幅提升MFU,其长期效益仍是显著的。
开源项目背后的挑战:
写代码之外的难题
ZOMI:两位都是在做Infra开源项目,你们觉得除了写代码之外,最难的是什么?是社区运营?用户反馈?还是版本节奏管理?
马介悦:DLRover自2023年开源以来,我们的目标是将其发展为更庞大的社区,吸引更多伙伴参与。就个人体会而言,这需要平衡公司繁重工作与社区投入,唯有对开源的热爱才能兼顾二者。
DLRover最初定位为容错系统,在PyTorch生态基础上强化了对作业任务管理、资源调度、容错及弹性优化能力。后续我们进一步集成了更多训练框架相关组件,包括自研的训练框架抽象层,以及基于CUDA算子与Python构建的性能剖析工具。
当前主要挑战在于项目刚加入基金会,如何有效运营技术监督委员会,并在国内外提升影响力。这需要从零开始,投入大量精力进行线上线下推广及交流活动。随着社区日益活跃、参与者增多,我们将把舞台让给新加入的成员,使其在项目中发挥作用,而我们则转向幕后提供支持。总结而言,运营开源社区是辛苦的工作,唯有依靠对开源的热爱方能持续投入。
尹良升:开源的本质是“众人拾柴火焰高”,开源项目的核心在于其开放性:代码应被更多人使用,同时我们应始终欢迎潜在开发者贡献力量,共同改进代码。以SGLang社区为例,其从开源起步,如今已成为全球部署规模最大的推理引擎。最关键的挑战在于:如何在项目维护者与社区用户之间构建良性循环——用户信任社区并提供反馈,社区则吸纳更多构建者,驱动版本迭代与项目进化。这种良性互动超越了纯粹的工程能力,是开源项目可持续发展的核心难点,也是其保持活力、长盛不衰的基础。
ZOMI:在华为负责Mind系列开源组件的经历让我深有感触。起初仅开源了MindSporeCore,但面临一个普遍认知:华为开源项目仅支持昇腾硬件,且易用性不足。打造一个如SGLang或vLLM般成功的开源项目极具挑战,其难度远超代码本身,涉及社区运营、用户反馈机制等复杂因素。
观众:现在有很多GPU共享和虚拟化方案,这块的技术趋势是怎样的呢?
马介悦:关于GPU虚拟化,我只能浅谈一二,因其高度依赖厂商支持。例如英伟达的MIG(Multi-InstanceGPU)技术需要其官方提供。在MIG出现前,GPU虚拟化相当繁琐,存在多种实现层面。最基础的是软件层面虚拟化:通过HookCUDA调用,追踪kernel发起速率、执行时间等信息,并基于此实现简单的复用策略。此类方案通常需对接CUDAForward-CompatibilityRuntime。
但软件虚拟化与CPU硬件辅助虚拟化(如IntelVT-x/AMD-V)的成熟度尚有差距。硬件层面的支持更深入,AMD早期在云渲染时代已提供相关虚拟化能力(主要服务于虚拟机场景),但当前大模型训练领域采用AMDGPU的案例极少,故暂不展开讨论。
在英伟达生态中,MIG是较成熟的方案。它基于SR-IOV(SingleRootI/OVirtualization)技术实现设备级虚拟化,本质是将物理GPU划分为多个虚拟实例(呈现为独立的PCIe设备),可同时供给容器或虚拟机使用。虚拟化的核心价值(性能、隔离性、安全性)在SR-IOV这一成熟技术框架下均可较好实现,只要厂商遵循规范支持即可。用户更关心的可能是具体配置细节,例如每块MIG实例可分配的SM算力比例等资源配额——这与网卡等设备的虚拟化配置思路类似,期待厂商提供更灵活的管控能力。
ZOMI:早期,不同厂商的GPU集群通常独立部署,实现异构融合极具挑战性,众多国家级项目也面临困难。然而,随着技术演进,特别是推理环节预填充与解码分离架构的成熟,异构部署的可行性显著提升。计算需求的分化是关键:预填充阶段依赖高算力芯片,而解码阶段更看重显存容量与高效的KV缓存管理能力,这使得为不同阶段匹配最优硬件成为可能。这一趋势正加速渗透至微调、后训练乃至训练环节。例如在增量学习场景中,高频次推理任务与单次训练任务对资源的差异化需求,为高效的资源共享与分割创造了条件。此外,CPU与GPU的混合部署技术也日益成熟。综合来看,充分利用异构硬件特性、实现跨类型资源的智能调度与混部,已成为AI基础设施演进的重要方向。
观众:尹老师选择SGLang而非vLLM的原因是什么?
尹良升:因为当前开源社区热度较高的推理引擎,除了半开源的TensorRT,便是SGLang和vLLM。首先,开源项目的进步离不开竞争与相互学习,这种良性互动带来危机感,推动整个社区共同前进。TensorRT、SGLang、vLLM以及lmdeploy等社区目前正处于协同并进的状态。
至于用户选择SGLang而非vLLM的理由,这更多是见仁见智的问题。从SGLang的0. 1到最近的0.4版本,我们与vLLM在功能交付上各有侧重。我们的设计理念存在根本差异:例如,从初始版本至今,SGLang始终围绕“GPU显存前缀共享(prefixshare)”为核心进行优化,再到后续实现的“零开销调度器(ZeroOverheadScheduler)”。这些独特设计使我们在特定场景下可能具备性能优势。同时,我们社区的开发风格是笃定解决用户的核心痛点——例如近期版本支持DeepSeek的大规模张量并行,目标直指降低用户部署的过高成本。
用户的选择自由毋庸置疑,但如果需要给出一个选择SGLang的理由,可能是我们在某些方面能提供更低的部署成本或更友好的上手体验。这本质上是用户与开源社区建立信任的过程。我们也鼓励大家尝试不同引擎,积极反馈使用体验,这将帮助我们持续交付新功能,共同推动推理成本优化。
活动推荐
6月27~28日的AICon北京站将继续聚焦AI技术的前沿突破与产业落地,围绕AIAgent构建、多模态应用、大模型推理性能优化、数据智能实践、AI产品创新等热门议题,深入探讨技术与应用融合的最新趋势。欢迎持续关注,和我们一起探索AI应用的无限可能!
今日荐文
成立5年最高估值超百亿,摩尔线程之后,又一家AI芯片独角兽争当“国产GPU第一股”
谷歌将A2A捐赠给Linux基金会,但代码实现还得靠开发者自己?!
印裔1号位删Karpathy团队90%代码、算力暴涨50倍!马斯克Robotaxi10年终上线,30元乘车体验刷屏
字节张一鸣重回一线?消息人士:不存在;MiniMax被曝将赴港IPO;Ilya拒绝扎克伯格公司收购后其CEO被挖走|AI周报
AI编码工具双雄也开始商业互捧了?Cursor×Claude最新对谈:两年后,几乎100%代码都将由AI生成!
你也「在看」吗?👇