Andrej Karpathy 说现在在大公司维护计算集群的时候，随着规模扩大,集群管理更像是生物学而非工程学。
Andrej Karpathy 说现在在大公司维护计算集群的时候，随着规模扩大,集群管理更像是生物学而非工程学。
工程师需要像"保姆"一样密切监控训练过程,关注关键指标,一旦出现问题要及时排查,否则会浪费大量计算资源。
训练常常因为各种未知原因失败,需要重启尝试。训练大模型考验整个计算系统的容错能力,因此除了考虑性能和成本,还要评估整体服务质量和团队效率。
原文翻译：
这篇文章精彩地讨论了一个鲜为人知的话题：训练大语言模型（LLM）的难点。在成熟的公司里，有专门的团队负责维护这些计算集群。当规模扩大时，这些集群的管理从传统的工程学转变成更接近生物学的领域，这也是为什么会有专门负责“硬件健康”的团队的原因。
训练大型模型的日常可能充满挑战。作为工程师，你需要像“保姆”一样密切监控训练过程。这包括关注运行的关键指标：损失函数的突然升高、数值问题、处理速度、梯度的规范性、策略的熵值等。一旦训练过程出现退化或停滞这种情况经常发生你就得迅速查找错误原因。如果处理不及时，可能导致成千上万的GPU资源闲置。
来源：
你经常会遇到一些新的、陌生的、令人畏惧的错误，需要紧急求助于同事。最糟糕的情况往往发生在凌晨4点。有时候，问题无法解决，你只能选择停用一些异常的节点，尝试重新开始训练。有时候，训练失败仅仅是因为运气不佳，这时你可能会在启动命令中加入一个while True:循环以期望运气好转。
这些问题可能涉及多种原因，从GPU过热导致计算错误，到路由器故障降低网络文件系统的输入输出速度，甚至是数据中心内部因未通报的维护工作而导致的物理连接中断。有时候，问题的根源可能永远成谜。
这里还需要特别提到一个重要的参考资料：OPT-175B的日志本。希望未来能有更多类似的资料能够公开。（详见git仓库中的chronicles/OPT175B_Logbook.pdf）
总之，大语言模型的训练过程实质上是对一个庞大计算系统整体容错能力的极端考验，这个系统在某种程度上像一个生物实体。因此，在选择计算资源时，除了考虑浮点运算性能（FLOPs）和成本外，还要全面考虑从硬件到软件的整体服务，包括存储、网络和计算能力。更重要的是，考虑维护这些系统的团队是否像《复仇者联盟》那样高效，并思考你是否能与他们建立良好的合作关系。
