【AI-Infra】AI Infra 工程实践：资源编排、框架引擎与训推平台（框架、算子、编译器、运行时与通信库）

【AI-Infra】 AI Infra 工程实践资源编排、框架引擎与训推平台框架、算子、编译器、运行时与通信库文章目录【AI-Infra】 AI Infra 工程实践资源编排、框架引擎与训推平台框架、算子、编译器、运行时与通信库一、资源基础设施提供算力、网络与存储硬件层/IAAS二、集群资源管理与编排决定任务何时运行、落在哪里调度层/K8S三、计算与执行软件把模型变成硬件上的有效工作引擎层/训练与推理3.1 框架表达模型、管理张量并计算梯度3.2 算子与 kernel把具体计算做得高效3.3 编译器优化一组计算的执行方式3.4 运行时提交计算协调内存与执行顺序3.5 通信库让多张卡交换计算所需的数据3.6 训练引擎与分布式训练系统组织训练计算和状态3.7 推理引擎组织模型执行、请求与缓存3.8 这些软件怎样配合工程师怎样找到优化点四、工作流与模型服务平台把分散能力变成可交付服务平台层/产品功能4.1 模型生命周期从数据和代码到线上服务4.2 控制面与数据面管理意图和处理请求分开4.3 工作流编排把步骤、依赖和产物连成闭环4.4 服务运营多租户、可观测、可靠性与成本常见问题五、参考资料与材料留档AI InfraAI InfrastructureAI 基础设施支撑模型研发、训练、评测和推理服务。它把算力、网络、存储和软件能力组织起来让模型在质量要求下高效、稳定地运行并使资源与成本可控。本文按系统职责介绍四类能力资源基础设施、集群资源管理与编排、计算与执行软件、工作流与模型服务平台。其中重点展开计算与执行软件解释框架、算子、编译器、运行时、通信库及训练与推理引擎的关系。这一划分参考 CNCF 白皮书、Google AI Hypercomputer 等公开架构是便于理解的归纳不是统一的行业四层标准。训练与推理是这些能力服务的任务一个软件项目也可能跨越多类职责。先从常见的生产问题看这几类能力各自负责什么现象可能的根因优先检查的能力GPU 有空闲训练数据跟不上文件系统、数据预处理或数据加载无法持续供数存储、网络、数据管道与资源基础设施任务长期排队或 GPU 分配不均配额、队列、准入、放置和优先级策略不合适集群资源管理与编排GPU 已分配单步计算仍慢算子、内存读写、编译路径、通信或同步存在瓶颈计算与执行软件训练和服务依赖人工串联实验、评测、制品、发布和回滚缺少生命周期管理工作流与模型服务平台这些现象可能同时出现。表格用于确定排查起点不表示问题只会落在某一层。一、资源基础设施提供算力、网络与存储硬件层/IAAS资源基础设施不只是 GPU 卡。一个训练或推理集群还包括主机 CPU 与内存、GPU/NPU 及其 HBM、单机内互联、跨节点网络、本地高速盘和共享存储。资源管理要回答的核心问题是需要什么资源、资源在哪里、不同资源之间的数据能否及时流动以及故障时能否恢复。资源主要约束不足时的典型表现加速器计算能力算力、支持的数据类型、设备代际计算 kernel 饱和单位任务耗时高HBM 显存容量、带宽、可用空间模型放不下、并发低、缓存频繁驱逐或 OOM单机互联PCIe、NVLink/NVSwitch 的拓扑和带宽TP 跨卡同步慢设备间通信耗时上升节点间网络带宽、延迟、拥塞、RDMA 能力多机训练扩展效率差跨节点状态传输慢数据存储吞吐、IOPS、并发读取和数据局部性GPU 等待数据冷启动或加载时间过长主机资源CPU、DRAM、NUMA、容器共享内存数据预处理、分词、通信代理或输入管线成为瓶颈资源之间存在配比关系。增加 GPU 不会自动提高吞吐如果数据管线供不上更多 GPU 只会一起等待如果多卡通信走到拥塞的 PCIe 或网络路径扩容可能增加同步成本如果模型权重占满 HBM留给 KV Cache 和运行时的空间就会变少。因此容量规划要从完整工作负载出发不能只按参数量或 GPU 数量估算。资源层还要提供可观测和可恢复能力例如设备健康、温度与功耗、ECC/Xid 错误、网络链路状态、存储延迟以及故障节点隔离。硬件故障无法完全避免平台需要知道哪些任务可重试、哪些状态已持久化、替代资源在哪里。例如GPU 利用率周期性下降且训练步耗时抖动时应结合数据等待、CPU、存储和网络指标排查供数瓶颈单纯追加 GPU 只会增加闲置成本。二、集群资源管理与编排决定任务何时运行、落在哪里调度层/K8S集群调度关注的是任务级资源分配检查任务是否有资格运行、是否满足配额、何时进入运行状态、需要哪些节点和设备以及怎样在公平性、利用率和完成时间之间取舍。它管理设备与节点、队列、优先级、配额、抢占、拓扑放置、健康和扩缩容等机制。一项分布式训练任务通常不能只启动“当前能放下的几个 Pod”。如果任务需要 16 张 GPU而集群只能零散提供 12 张先启动一部分 Worker 可能导致它们占着资源等待其余 Worker。**Gang Scheduling成组调度**要求作业达到最低资源数后再整体启动避免不完整作业长期占用资源代价是作业可能需要等待凑齐资源。调度过程可以概括为提交作业 → 校验资源与配额 → 排队/准入 → 选择节点与拓扑 → 成组分配 GPU → 启动工作负载 → 监控、重试或释放资源几个常见项目承担的职责并不相同组件主要职责不能简单等同于Kubernetes Scheduler为待运行的 Pod 选择节点考虑资源请求、约束和亲和性完整的 AI 作业队列与 GPU 作业管理Kueue管理作业准入、队列和资源配额并与集群调度协作节点上的所有设备放置逻辑Volcano面向批处理/HPC 工作负载提供队列、作业和成组调度等能力Kubernetes 本身SlurmHPC 集群中的作业队列、资源分配和运行管理Kubernetes 调度器调度还有碎片与拓扑问题。集群总 GPU 数量足够不代表有一组可互联、可同时分配的 GPU多机训练可能需要同一高速网络域中的节点推理实例则可能要求特定型号显卡和显存容量。调度器需要在等待更合适拓扑、先运行小作业、抢占低优先级任务之间作出选择。自动扩缩容和调度也不是一回事扩缩容负责增加或回收节点/副本供给调度负责把具体作业放到可用资源上。新增 GPU 节点还要经过发现、健康检查和资源注册Pod 创建成功也不等于模型服务已经预热完成。例如某个 16-GPU 训练任务一直排队但集群监控显示“还剩 20 张 GPU”。这 20 张卡可能分散在不同节点、型号不同或者每个节点上的空闲卡数不足以满足拓扑要求。此时应检查配额、队列、Gang 阈值、节点标签和拓扑约束而不是只看集群空闲卡总数。这里的调度关注“任务拿到哪些资源、何时启动、放在哪里”。后文的训练/推理系统调度关注“资源已经分配后怎样组织计算步骤、批次与请求”。两者相互影响但属于不同决策层。三、计算与执行软件把模型变成硬件上的有效工作引擎层/训练与推理获得 GPU 后模型还需要被表达成计算转换为设备能够执行的操作并协调内存、通信与执行顺序。模型规模、数据形状、精度和负载不同合适的执行方式也会变化。这一类软件的核心作用是在正确性和模型质量要求下减少计算、数据读写、内存占用和等待的开销。组件主要回答的问题常见代表框架模型如何表达、执行和求导PyTorch、TensorFlow、JAX算子与 kernel一项具体计算怎样映射到硬件cuBLAS、FlashAttention、Triton kernel编译器一组计算如何融合、重排或生成目标代码torch.compile、TorchInductor运行时如何提交计算、管理内存和异步依赖CUDA Runtime、CUDA Graph通信库多设备间怎样交换张量或 tokenNCCL训练推理系统如何安排完整任务、并行策略或在线请求FSDP、DeepSpeed、Megatron Core、vLLM、SGLang下面按软件职责展开。它们是协作关系实际项目可能同时实现多个部分。3.1 框架表达模型、管理张量并计算梯度框架提供建立和执行模型的基础能力。PyTorch、TensorFlow以及 JAX 的数组计算与自动微分体系是常见例子它们的模型组织方式和编译路径有所不同。以 PyTorch 为例主要能力包括张量计算表示数据、参数和中间结果提供数学运算与设备支持。模型组织通过模块和参数管理组合模型结构。自动求导跟踪计算关系在训练中计算参数所需的梯度。数据与分布式基础能力提供数据加载、分布式通信接口等供训练程序和上层系统使用。例如开发者定义一个网络框架在前向计算中执行其中的算子并在需要时通过自动求导组织反向计算。具体算子会调用与设备、数据类型等匹配的实现。框架提供通用模型计算基础内部也可能包含编译、内存管理和分布式能力相关工程需要处理模型与硬件适配、算子接入和数值验证。3.2 算子与 kernel把具体计算做得高效算子描述一项计算例如矩阵乘法、Attention、归一化或激活函数。Kernel 是执行这项计算的底层实现尤其常用于指 GPU 上运行的计算程序。两者不是固定的一对一关系一个算子可能需要多个 kernel也可能将多个算子融合到一个 kernel 中执行。优化主要围绕计算组织怎样分块、分配并行工作适配硬件计算单元。数据读写怎样复用数据减少显存与片上存储之间的搬运。算子融合合并适合一起执行的操作减少中间结果反复落到显存。精度与形状适配为不同数据类型、矩阵尺寸和上下文长度选择合适实现。例如矩阵乘法、加偏置和激活函数分别执行时可能反复读取和写入中间结果合适的融合实现可以减少这些开销。FlashAttention 是重要例子它通过分块和重排 Attention 计算减少显存读写避免显式保存完整 Attention 中间矩阵。这类底层优化可以服务训练也可以服务推理。CUDA、Triton 等是开发工具cuBLAS 等数学库以及 FlashAttention 等项目提供可复用实现。这里的 Triton 指 GPU kernel 编程语言与编译器和 NVIDIA Triton Inference Server 是不同项目。3.3 编译器优化一组计算的执行方式模型通常包含许多算子。仅逐个优化算子还可能留下中间数据搬运、冗余计算和执行调度开销。编译器利用计算之间的关系尝试生成更高效的执行方式。常见过程包括捕获计算图分析依赖重排或融合操作选择已有实现或生成针对目标硬件的代码。具体优化取决于编译器和后端支持。PyTorch 的 torch.compile 是代表性入口TorchDynamo负责捕获 PyTorch 计算关系。TorchInductor作为默认后端生成优化代码或调用现有实现GPU 路径可以结合 Triton 等生成 kernel。训练场景还可结合AOT Autograd处理反向计算图因此编译优化可以同时用于前向和反向执行。相关工程工作包括图捕获、融合、代码生成、动态形状处理、算子覆盖以及编译结果的正确性和性能验证。收益需要实测图中断可能把计算拆成多段形状变化可能触发重新编译。首次编译成本、预热后性能和真实输入分布也应分别考虑。3.4 运行时提交计算协调内存与执行顺序这里主要讨论设备执行所需的运行时。它负责提交计算、协调设备资源以及处理异步工作之间的依赖。以 NVIDIA GPU 为例CUDA Runtime 与驱动提供设备、内存、kernel 启动和同步等基础接口。框架与引擎在这些接口之上还会实现自己的内存分配、缓存与执行管理。常见优化涉及内存复用减少频繁申请和释放改善容量使用与执行开销。Stream 与 Event表达异步执行和依赖在条件允许时重叠计算、拷贝或通信。减少不必要的同步避免 CPU 或 GPU 提前等待本可继续进行的工作。CUDA Graph记录并重复提交适合复用的设备执行序列减少 CPU 逐项发起操作的开销。CUDA Graph 与算子融合对应不同开销前者主要改善提交与执行组织后者主要合并计算并减少中间读写。它们可以配合使用。运行时工程关注执行依赖、内存生命周期、并发和错误处理。异步操作的顺序必须正确否则可能出现数据尚未就绪就被读取的问题。CUDA 本身覆盖编程模型、工具链、运行时和库是一个软件生态理解时需要具体到所讨论的组件。3.5 通信库让多张卡交换计算所需的数据多卡协作需要交换梯度、参数、激活或 token。物理网络提供传输资源通信库则组织数据交换处理通信算法与设备拓扑等问题。NCCL 是 NVIDIA GPU 间通信的代表性库。常见操作包括AllReduce合并各设备的数据并让参与设备获得结果常用于数据并行梯度同步。AllGather收集各设备的数据分片常用于分片参数的按需聚合。ReduceScatter进行规约后分发结果分片可用于分片梯度处理。AlltoAll 类通信在多个设备间交换不同数据常见于 MoE 的 token 分发等场景。框架或引擎决定何时需要这些操作以及使用哪些并行组通信库提供相应的高效交换能力。不同硬件和场景也可能使用其他通信库或专用组件。相关工程工作包括拓扑分析、通信分组、数据聚合、通信与计算重叠、负载均衡和故障诊断。例如各张 GPU 的局部计算都很快训练却没有随卡数增加而明显提速问题可能在同步、通信量或负载不均。通信库也不能弥补所有物理互联限制需要结合硬件与并行策略判断。3.6 训练引擎与分布式训练系统组织训练计算和状态训练需要前向计算、反向传播和参数更新还需要保存参数、梯度、优化器状态及中间激活。规模扩大后仅状态容量和协作方式就会影响模型能否训练、训练多久。框架提供基础能力训练系统进一步组合适合具体规模和模型的执行策略并行训练通过数据并行、张量并行、流水线并行等方式组织计算。状态分片减少设备之间重复保存参数、梯度和优化器状态的开销。激活重计算用额外计算换取更少的中间激活存储。混合精度与梯度累积结合质量、数值稳定性和资源条件组织训练。通信调度与恢复安排通信重叠管理恢复训练所需的 checkpoint 状态。几个代表性实现需要分别理解PyTorch FSDP是框架内的分片训练能力。它将参数、梯度和优化器状态分布到数据并行设备上在计算需要时聚合参数并处理梯度的规约与分片。这样可以降低状态占用同时引入相应通信。DeepSpeed组织分布式训练、精度、状态管理等优化机制。其中 ZeRO 按阶段对优化器状态、梯度和参数进行分片还可以结合卸载等策略。Megatron Core提供面向大规模 Transformer 训练的组件和并行能力Megatron-LM 则包含基于这些组件的参考训练实现。其并行、算子和执行组件可以供上层训练系统组合使用。它们的能力会重叠也可能组合。不能仅凭“框架”或“引擎”的名称判断每个项目的完整范围。这一方向的工程工作是在模型质量与收敛要求下减少显存需求、通信等待和故障重算改善训练时间、扩展效率与成本。3.7 推理引擎组织模型执行、请求与缓存推理通常不需要训练中的梯度和优化器更新但需要应对请求持续到达、长度变化、生成依赖以及响应延迟要求。对于常见的自回归大语言模型Prefill 处理输入Decode 迭代生成后续 token。引擎需要组织这两类工作管理 KV Cache并让不同请求合理共享执行容量。主要能力包括连续批处理、分块 Prefill、前缀复用、量化、推测解码以及多卡和多机执行。它们分别减少批次空闲、跨请求干扰、重复计算、存储与带宽需求或生成中的串行开销。代表项目包括vLLM组织模型执行、请求调度、缓存管理和分布式推理等。SGLang提供高性能运行时在前缀复用、调度、结构化生成等方面有代表性实现。TensorRT-LLM面向 NVIDIA 生态结合优化算子、精度、运行时与并行执行提供推理能力。引擎可以集成框架、编译器和算子也可能使用专门执行后端。它还可能包含服务接口、路由等能力具体范围以项目和版本为准。推理系统工程师需要适配模型与硬件、改善调度与状态管理并检查首 token 延迟、输出流畅度、有效吞吐和质量。生产部署、性能调优和这些引擎的详细比较可继续阅读同系列《大模型推理服务部署、性能调优与生产实践》。3.8 这些软件怎样配合工程师怎样找到优化点下面以模型执行为中心表示主要协作关系。箭头表达依赖与调用关系不代表每次执行都经过完全相同的固定流水线。训练任务 / 在线推理请求 ↓ 训练系统 / 推理引擎 —— 决定完整任务与并行策略 ↓ 模型框架 / 执行后端 —— 表达模型、张量与计算关系 ↙ ↘ 编译器 通信库多设备时 ↓ ↓ 算子库与 kernel ───→ 设备运行时与驱动 ↓ 加速器与互联硬件一次训练中训练系统安排批次和并行方式框架执行模型并组织求导算子或编译生成的代码通过运行时执行。多卡之间按策略交换参数、梯度或激活再进行参数更新。计算和通信可能交错、重叠系统还需要定期保存恢复状态。如果训练受显存限制可以检查状态分片或激活重计算如果大部分时间在等待同步就检查并行策略、通信和重叠如果局部算子占据主要耗时再考虑 kernel 或编译优化。一次推理中引擎把请求组织成批次安排输入处理与生成管理缓存再调用执行后端、算子和必要通信。长输入、短输出、大批量等不同负载可能产生不同瓶颈。如果延迟来自排队或批次安排优先检查调度如果重复处理相同前缀检查缓存复用如果模型计算或读写占主导则分析算子、精度、编译与运行时。案例增加 GPU 后训练速度没有明显提升。某训练任务从 8 张卡扩到 16 张卡GPU 数量翻倍但每轮耗时只小幅下降。排查时不要先假设通信库故障可以按一次迭代拆分时间若迭代开始前 GPU 长时间空闲检查数据加载、存储吞吐和 CPU 预处理。若 GPU 在计算 kernel 期间繁忙但算子耗时高用 profiler 找出热点再判断是否适合融合、编译或调整精度。若计算后大量时间等待同步检查 NCCL 通信时间、并行策略、通信拓扑和负载均衡并确认通信是否与计算重叠。改动后用相同数据、全局批量、精度和训练步数回归同时比较收敛质量、每步耗时和总训练成本。实际工作通常是建立代表性基线分解耗时与资源占用修改对应实现或配置再验证完整任务的数值与模型质量、吞吐与延迟、稳定性和成本。单看 GPU 利用率或某个 kernel 的加速都不足以证明完整训练提速。四、工作流与模型服务平台把分散能力变成可交付服务平台层/产品功能平台层的核心不是再造一个训练框架或推理引擎而是把底层资源和软件封装成团队能够申请、运行、追踪、评估和发布的标准流程。它要回答谁可以使用什么模型和资源产物如何追踪怎样从实验走到线上出问题后如何回滚与核算成本。4.1 模型生命周期从数据和代码到线上服务一个可运营的平台会为模型建立可追踪的生命周期而不是只保留一个权重目录阶段平台需要管理的对象关键校验研发与训练数据版本、代码提交、配置、运行环境、实验记录结果能否复现资源是否在配额内产物登记模型权重、Tokenizer、依赖、许可证、版本号文件完整性、来源与使用权限评测与准入质量集、安全评测、性能压测、兼容性报告是否达到质量、时延和安全门槛部署与发布Runtime、资源规格、服务版本、灰度比例健康检查、容量、回滚版本是否就绪线上运营请求、Token、延迟、错误、成本和用户反馈SLO 是否满足成本是否可控关键价值是把一次运行与其输入、代码、环境、配置和输出关联起来。否则出现质量回退时很难判断是数据、权重、Tokenizer、精度、引擎版本还是服务配置变化导致。4.2 控制面与数据面管理意图和处理请求分开模型平台通常可以拆为控制面和数据面。控制面管理模型目录、权限、配额、部署配置、版本和发布策略数据面承载实际训练任务或在线推理请求。控制面生成并下发期望状态Kubernetes、调度器和推理引擎负责把它落实为运行中的工作负载。控制面模型目录 / 权限与配额 / 工作流 / 评测 / 发布与回滚 ↓ 期望状态与策略 资源与编排队列 / 调度器 / Kubernetes Controller / GPU 节点 ↓ 已分配资源 执行数据面训练系统 / 推理引擎 / Gateway / 模型副本 ↓ 指标、日志、Trace、计量事件 运营治理SLO / 成本 / 审计 / 告警 / 容量规划这个边界有助于故障隔离控制台或控制服务短暂不可用时已经运行的数据面通常应继续使用最近一次有效配置服务策略更新则要有版本、验证和回滚机制。控制面不应同步参与每个 Token 的生成请求否则管理功能的抖动会直接进入在线链路。4.3 工作流编排把步骤、依赖和产物连成闭环工作流系统描述一组任务及其依赖关系例如数据准备、训练、评测、模型登记、部署和灰度。它需要处理任务状态、重试、超时、产物传递、人工审批和失败清理它通常调用底层队列和执行系统并不直接替代 GPU 调度器。以一次模型更新为例代码提交触发训练任务任务使用固定数据和环境运行完成后登记权重与配置摘要评测流水线比较质量、延迟和显存达标版本进入预发布灰度观测通过后放量如果错误率或质量指标恶化平台停止放量并回滚到上一版本。Kubeflow 的工作流组件可以组织这类 ML 流程但具体部署还需集成数据、存储、身份和集群资源系统。4.4 服务运营多租户、可观测、可靠性与成本平台上线后还要处理多团队共享资源带来的治理问题身份与隔离将用户、团队、项目和模型权限关联限制谁可以读写模型、申请 GPU 或调用服务。配额与公平性为不同团队设置并发、GPU 时长、Token 用量和优先级边界避免一个作业或租户耗尽共享容量。可观测与计量关联模型版本、请求 ID、延迟、错误、Token、资源占用和成本在线请求指标需避免使用用户 ID 等高基数字段直接作为时序标签。可靠性与发布提供健康检查、灰度、限流、熔断、回滚和容量保护并区分模型错误、节点故障与上游依赖故障。成本与容量按有效训练步、合格请求或输出 Token 核算成本同时观察闲置 GPU、缓存占用和预热时间。平台的价值不在于界面或 API 数量而在于把权限、资源、产物和运行结果连接起来让用户可以自助使用让平台团队能审计、排障和控制成本。Kubeflow 更常用于连接机器学习工作流与任务KServe 提供 Kubernetes 上的模型服务抽象AIBrix 面向 LLM 推理服务的网关、路由与集群管理。它们能力有交集但不是同一层的可互换产品具体组合取决于已有集群、模型类型和运维边界。四类职责不是互相独立的层工作流与模型服务依赖集群调度训练和推理也会跨越资源与执行软件。性能、可靠性、安全和成本治理贯穿全链路。常见问题Q1框架、训练引擎和推理引擎是互相替代的产品吗A通常不是。框架提供模型计算基础训练或推理系统组织完整执行和资源策略实际项目会包含重叠能力也可能调用对方提供的组件。Q2GPU 数量翻倍训练速度一定翻倍吗A不一定。数据供给、通信、同步和负载不均都会限制扩展效率。应比较每步时间、通信占比、模型收敛和单位训练成本。五、参考资料与材料留档CNCFCloud Native AI White PaperGoogle AI Hypercomputer系统组成与层次关系。Kubernetes SchedulerKueueOverview节点放置、作业准入和资源队列。VolcanoSlurm Overview批处理与 HPC 集群调度。PyTorchMain ComponentsTensorFlow 自动微分JAX 自动微分。FlashAttention 论文Triton 语言与编译器。PyTorchtorch.compiler图捕获、编译后端与前向、反向优化。CUDA Runtime APIStream 同步行为。NCCLOverviewGPU 间通信原语。PyTorchFSDP fully_shard状态分片与通信。DeepSpeedTrainingZeRO训练组织与分片机制。Megatron-LM 与 Megatron Core训练组件、并行能力与参考实现。vLLMSGLangTensorRT-LLM推理引擎。NVIDIA Triton Inference Server与 Triton kernel 编程项目不同的模型服务软件。KubeflowArchitectureKServeAIBrix工作流与模型服务平台能力。