作者 | AICon 全球人工智能开发与应用大会 策划 | 罗燕珊 编辑 | 宇琪 Infra 虽然是看不见的“底座”，但它却承担着支撑整个大模型系统运行的重量。那么，Infra 工程师在日常工作中会遇到哪些真实需求与故障类型？开源 Infra 和国产卡适配训练推进过程中，又会遇到哪些难点和挑战呢？ 近日 InfoQ《极客有约》X AICon 直播栏目特别邀请了华为昇腾技术专家 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）错误。此时，需要熟悉社区代码的工程师与一线部署人员深入沟通，精确定位问题代码行，分析是哪个配置参数设置不当，进而找到解决方案以消除部署时的运行时错误。 第二方面是性能问题。用户在部署时，即使使用相同的硬件卡和部署策略，也可能发现其性能无法匹配我们官方的测试报告，进而质疑报告数据的真实性或怀疑我们进行了选择性测试（cherry pick）。实际上，用户复现结果与官方数据存在差异的原因是多方面的。常见原因包括配置问题、软件版本差异，以及测试数据集未能完全一致地迁移到用户环境所导致的数据偏差。 此外，线上推理流程的各个环节出现问题也可能导致性能不符合预期。从接收请求（request）、首次预填充（prefill）到每个解码（decode）步骤，任一阶段的异常都可能引起延迟（latency）偏高。同样，分配给 KV cache 的内存（GPU memory）分配不足也会导致推理的批次（batch size）降低从而吞吐量（throughput）未达预期。解决这类问题，需要深入代码层面，具体分析问题环节，进行点对点的优化或配置修正。综合来看，性能问题和运行时错误确实是用户反馈中最常提及的两类紧急问题。 ZOMI： 我个人更关注训练环节。在昇腾工作期间，主要聚焦于服务大客户的推理集群。遇到的问题首先是如何应对训练任务中断。在万卡甚至十万卡级别的集群中，硬件故障不可避免，特别是在持续训练两个月的大型模型任务中。其次是如何处理损失函数异常飙升。这需要判断是不同硬件差异、算法本身缺陷、客户代码错误，还是分布式并行处理时出现了问题。因此，解决这些问题往往需要 Infra 团队与算法团队进行更紧密的合作。 ZOMI：如果把大模型的工程流程当作一条流水线，你们觉得哪一段最容易出问题？是资源调度、作业调优，还是并行策略不兼容？ 尹良升： 针对并行策略不兼容的问题，我以 SGLang 社区上个月复现 DeepSeek Blog 的实践为例。我们采用了名为“Multi Token Prediction”（MTP，推测解码）的策略来有效降低 token 输出延迟。然而，在初始实现中，MTP 与包括“Data-Parallel Attention”（数据并行注意力机制）在内的多个功能存在兼容性问题。这种不兼容性通常并非源于策略设计本身，而是代码实现过程中的兼容性与解耦不足所致：为快速交付新功能，可能暂时忽略了与现有功能的兼容性。 实际部署中，往往需要同时启用 MTP、DP Attention、大规模张量并行（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 的 xprof timer 等性能剖析工具，但定位卡死的根本原因比检测现象更困难。若有强大的底层基础设施团队能快速识别并驱逐故障机，问题较易解决；否则需综合日志、metrics 和性能剖析数据进行深度诊断。 类似问题还包括“straggler”场景：训练步耗时逐渐增加。监测到该现象相对简单，但定位根因（硬件、网络、数据集或切分策略问题）则需复杂的综合判断逻辑。 综上，高效的工程化实践离不开强大的性能剖析和监控系统支持，仅靠人工排查效率低下。常用工具包括 PyTorch Profiler、GPU 监控系统、各公司自研监控组件，以及 DLRover 的 xprof timer 等。其核心是记录底层 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 框架，通过 Overlap Scheduling，延迟 token 调度完全隐藏了 CPU 开销。这些都是提升资源利用率、压榨 GPU 推理性能的关键创新点。 第三点核心在于优化调度开销。传统流程（调度批次 ->启动内核 ->执行计算）中，调度和启动内核作为 CPU 密集型任务易阻塞后续流程。SGLang 中的 Overlap Scheduling 重新设计工作流，允许 GPU 执行当前批次时，CPU 并行准备下一批次，消除 CPU 准备阶段的 GPU 闲置。虽然这提升了 GPU 利用效率，但也面临兼容性挑战，如与 MTP 的整合，这正是功能迭代中不可避免的“阵痛期”。 马介悦： 我想从硬件角度再谈一点：英伟达 GPU 的领先很大程度上得益于其 NVLink/NVSwitch 机制，它极大提升了单机节点内的 GPU 通信效率。相比之下，跨节点通信，无论使用 InfiniBand 还是 RoCE，其性能较 NVSwitch 存在约一个数量级的差距。 因此，提升性价比的关键在于：将大量节点整合到大型机柜内。这不仅能节省交换机等模块的成本（虽然 GPU 仍是训练集群的主要成本，但网络成本占比已不容忽视），更重要的是，通过 NVLink 的“拉远”互联技术，能够将跨节点通信带宽提升至接近节点内水平。传统架构中，节点内走高速 NVLink，节点间走相对低速的 InfiniBand/RoCE，存在性能降级。大型机柜方案则通过统一的总线级互联技术消除这一断层，显著提升整体并行性能。我们的实践也验证了这一点：仅更换为类似 Cloud Matrix 的硬件架构，实测性能提升便非常可观。 所以，成本优化不仅关乎价格，更需关注性价比，即同等模型 MFU 下的单位成本。大型集成硬件初期投入可能更高，但如果能大幅提升 MFU，其长期效益仍是显著的。 开源项目背后的挑战： 写代码之外的难题 ZOMI：两位都是在做 Infra 开源项目，你们觉得除了写代码之外，最难的是什么？ 是社区运营？用户反馈？还是版本节奏管理？ 马介悦：DLRover 自 2023 年开源以来，我们的目标是将其发展为更庞大的社区，吸引更多伙伴参与。就个人体会而言，这需要平衡公司繁重工作与社区投入，唯有对开源的热爱才能兼顾二者。 DLRover 最初定位为容错系统，在 PyTorch 生态基础上强化了对作业任务管理、资源调度、容错及弹性优化能力。后续我们进一步集成了更多训练框架相关组件，包括自研的训练框架抽象层，以及基于 CUDA 算子与 Python 构建的性能剖析工具。 当前主要挑战在于项目刚加入基金会，如何有效运营技术监督委员会，并在国内外提升影响力。这需要从零开始，投入大量精力进行线上线下推广及交流活动。随着社区日益活跃、参与者增多，我们将把舞台让给新加入的成员，使其在项目中发挥作用，而我们则转向幕后提供支持。总结而言，运营开源社区是辛苦的工作，唯有依靠对开源的热爱方能持续投入。 尹良升： 开源的本质是“众人拾柴火焰高”，开源项目的核心在于其开放性：代码应被更多人使用，同时我们应始终欢迎潜在开发者贡献力量，共同改进代码。以 SGLang 社区为例，其从开源起步，如今已成为全球部署规模最大的推理引擎。最关键的挑战在于：如何在项目维护者与社区用户之间构建良性循环——用户信任社区并提供反馈，社区则吸纳更多构建者，驱动版本迭代与项目进化。这种良性互动超越了纯粹的工程能力，是开源项目可持续发展的核心难点，也是其保持活力、长盛不衰的基础。 ZOMI： 在华为负责 Mind 系列开源组件的经历让我深有感触。起初仅开源了 MindSpore Core，但面临一个普遍认知：华为开源项目仅支持昇腾硬件，且易用性不足。打造一个如 SGLang 或 vLLM 般成功的开源项目极具挑战，其难度远超代码本身，涉及社区运营、用户反馈机制等复杂因素。 观众：现在有很多 GPU 共享和虚拟化方案，这块的技术趋势是怎样的呢？ 马介悦： 关于 GPU 虚拟化，我只能浅谈一二，因其高度依赖厂商支持。例如英伟达的 MIG（Multi-Instance GPU）技术需要其官方提供。在 MIG 出现前，GPU 虚拟化相当繁琐，存在多种实现层面。最基础的是软件层面虚拟化：通过 Hook CUDA 调用，追踪 kernel 发起速率、执行时间等信息，并基于此实现简单的复用策略。此类方案通常需对接 CUDA Forward-Compatibility Runtime。 但软件虚拟化与 CPU 硬件辅助虚拟化（如 Intel VT-x/AMD-V）的成熟度尚有差距。硬件层面的支持更深入，AMD 早期在云渲染时代已提供相关虚拟化能力（主要服务于虚拟机场景），但当前大模型训练领域采用 AMD GPU 的案例极少，故暂不展开讨论。 在英伟达生态中，MIG 是较成熟的方案。它基于 SR-IOV（Single Root I/O Virtualization）技术实现设备级虚拟化，本质是将物理 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 显存前缀共享（prefix share）”为核心进行优化，再到后续实现的“零开销调度器（Zero Overhead Scheduler）”。这些独特设计使我们在特定场景下可能具备性能优势。同时，我们社区的开发风格是笃定解决用户的核心痛点——例如近期版本支持 DeepSeek 的大规模张量并行，目标直指降低用户部署的过高成本。 用户的选择自由毋庸置疑，但如果需要给出一个选择 SGLang 的理由，可能是我们在某些方面能提供更低的部署成本或更友好的上手体验。这本质上是用户与开源社区建立信任的过程。我们也鼓励大家尝试不同引擎，积极反馈使用体验，这将帮助我们持续交付新功能，共同推动推理成本优化。