Page 223 - 《软件学报》2026年第1期
P. 223

220                                                        软件学报  2026  年第  37  卷第  1  期


                 划分为静态分析和动态分析两种方式.
                  3.4.1.1    静态分析
                    静态分析是一种在不运行程序的情况下, 通过将程序作为输入来分析其非功能属性或进行程序验证的方法.
                 这种方法可以有效检测类型缺陷、显存溢出、资源消耗等问题. 以类型缺陷为例, Gao                          等人  [94] 将模型类型缺陷形
                 式化为约束满足问题, 并通过类型检测和             SMT Solver 进行验证. 另外, Gao  等人  [95] 和  Mei 等人  [96] 通过分析代价模
                 型或图神经网络模型, 对模型显存消耗或计算代价进行建模, 从而能够预测模型的内存消耗、浮点运算量、GPU
                 利用率、模型尺寸等. 通过提前对提交的待执行模型进行验证, 可以在大语言模型训练过程中进行优化. 虽然在大
                 语言模型训练中, 由于单次迭代训练代价较大, 模型结构较为稳定, 且缺少自动化机器学习中的搜索空间假设, 但
                 仍然可能遇到同类型的缺陷问题, 这些问题可能会导致更大的资源浪费和性能下降. 因此, 静态分析仍然是解决这
                 些缺陷问题的一种有效手段.
                  3.4.1.2    动态分析
                    (1) 动态程序分析. 动态分析需要执行程序并捕获程序运行过程中的日志或中间执行结果, 然后进行分析. 通
                 过这种方式可以规避静态分析缺少上下文、对控制流和动态性的分析局限性等问题, 但要确保动态工具对性能的
                 影响控制在可接受范围内. Zhu        等人  [97] 通过构建执行痕迹图, 对作业的执行开销进行回放模拟, 从而预测作业在不
                 同优化和硬件拓扑下的性能, 为系统优化和部署提供指导. Le Scao                 等人  [5] 通过观察执行中的    Loss、GNorm  等信
                 息来判断是否出现不收敛、数值缺陷等问题, 进而终止、调试或重启实验, 以加速模型的收敛. MegaScale 在大规
                 模语言模型训练过程中发现不同任务之间存在性能不一致性. 为了不影响训练性能, 该研究通过记录                                CUDA  事件,
                 构建性能检测工具, 以诊断运行时训练程序的性能问题.
                    除了对作业的分析, 对平台服务和硬件进行检测与分析对保障平台质量也至关重要. 从开源大语言模型训练
                 的编年史和平台质量分析中可以看出, 平台侧需要构建节点健康检测, 以快速定位和剔除不健康节点, 从而减少作
                 业失效或挂起. OpenAI   [98] 和  MegaScale 披露了其在大规模集群中依靠自动化检测并剔除行为异常节点的做法. 随
                 着时间的推移, 工业界针对人工智能平台建立了许多健康检查系统, 分为两类: 被动性检查和主动性检查.
                    (2) 被动性检查. OpenAI 披露其平台中的某些健康检查是被动的, 始终在所有节点上运行. 这些检查监视基本
                 系统资源, 例如网络可达性、磁盘损坏或已满, 以及               GPU  错误. NVIDIA  的数据中心   GPU  管理器  (DCGM) 工具可
                 以查询这些错误以及其他许多           Xid  错误. 此外, NVML  设备查询   API 还公开了有关     GPU  运行状况和操作的更多
                 详细信息. 一旦检测到错误, 通常可以通过重置              GPU  或系统来修复它们. 在某些情况下, 可能需要物理更换底层
                 GPU. 另一种被动形式的健康检查是跟踪来自上游云提供商的维护事件. 云提供商通常公开一种了解当前虚拟机
                 是否即将发生维护事件的方法, 该事件最终可能导致中断. 虚拟机可能需要重新启动, 以便应用底层虚拟机管理程
                 序的补丁或将物理节点更换为其他硬件. 这些被动运行状况检查在所有节点的后台持续运行. 如果运行状况检查
                 开始失败, 该节点将自动封锁, 因此不会在该节点上调度新的作业进程. 对于更严重的运行状况检查失败, 还将尝
                 试将进程逐出, 以请求所有当前正在运行的进程立即停止运行. 是否允许这种驱逐仍由进程本身决定, 可通过
                 Kubernetes Pod  中断预算进行配置.
                    (3) 主动性检查. 并非所有      GPU  问题都会表现为通过       DCGM  可见的错误代码. 为此, OpenAI 建立了测试库,
                 用于测试    GPU  并捕获其他问题, 以确保硬件和驱动程序按预期运行. 这些测试无法在后台运行, 它们需要独占
                 GPU  几秒钟或几分钟才能完成. 首先, 在系统启动时, 节点上会运行这些测试, 该过程被称为“预检”. 所有节点在加
                 入集群时都会应用“预检”标记. 此标记将阻止在节点上调度正常的                     Kubernetes Pod. 之后, 预检程序在带有此标签
                 的所有节点上运行预检测试. 成功完成测试后, 测试程序将删除标记, 该节点即可供使用. 此后, 还会在节点生命周
                 期内定期运行这些测试, 以确保可用节点顺利部署到集群中. 虽然测试哪些节点具有一定的随机性且不受控制, 但
                 随着时间的推移, 这种方法可以提供足够的覆盖范围, 同时将干扰降至最低. 微软还开源了人工智能硬件测试工
                 具  SuperBench [99] , 包含深度学习基准测试作业, 用于定期测试面向深度学习的新硬件的质量和稳定性. MegaScale
                 在万卡规模的大规模语言模型训练过程中, 也会主动进行节点内和节点间的网络测试, 以主动检测网卡质量问题,
                 尽早发现硬件层和软件层的通信问题并进行迁移.
   218   219   220   221   222   223   224   225   226   227   228