FlagEmbedding项目训练过程中的信号中断问题分析与解决方案

问题现象

在使用FlagEmbedding项目进行模型微调训练时，用户遇到了一个随机出现的错误：torch.distributed.elastic.multiprocessing.api.SignalException: Process 792735 got signal: 1。这个错误会导致训练过程中断，影响模型训练的正常进行。

错误背景

该错误通常出现在使用nohup命令配合torchrun启动分布式训练时。从错误日志中可以看到，系统收到了SIGHUP信号（信号编号1），这是导致进程终止的直接原因。SIGHUP信号通常与终端会话的断开有关，当用户退出终端或网络连接中断时，系统会向相关进程发送该信号。

技术分析

1. 信号机制：在Linux系统中，信号是进程间通信的一种方式。SIGHUP信号原本设计用于通知进程其控制终端已断开连接。现代系统中，它常被用于指示守护进程重新读取配置文件。

2. nohup的局限性：虽然nohup命令设计用于忽略SIGHUP信号，但在某些情况下（特别是与复杂的分布式训练框架结合使用时），信号处理可能不完全可靠。

3. 分布式训练的特殊性：torch.distributed.elastic是PyTorch提供的弹性分布式训练框架，它对进程管理和信号处理有特殊要求，可能与nohup的信号处理机制产生冲突。

解决方案

1. 使用tmux替代nohup：

   • tmux是一个终端复用器，可以创建持久会话
   • 使用方法：

     tmux new -s session_name
     # 在tmux会话中运行训练命令
     torchrun --nproc_per_node 1 -m FlagEmbedding.baai_general_embedding.finetune.run ...
     # 按Ctrl+B然后按D分离会话
     

   • 优点：完全避免了信号中断问题，会话持久稳定

2. 调整训练参数：

   • 将temperature参数从0.3调整为≤0.05
   • 这个参数控制对比损失的"温度"，值过大会导致模型难以学习有区分度的表示

3. 直接使用torchrun：

   • 如果环境允许，可以直接在前台运行训练命令
   • 避免使用任何会话管理工具，减少信号干扰的可能性

训练监控建议

1. loss曲线分析：

   • 初始loss值较低可能是正常现象，特别是当query和positive样本相似度较高时
   • 应关注loss的下降趋势而非绝对值大小
   • 如果loss下降过快或波动异常，可能需要检查数据质量或调整学习率

2. 资源监控：

   • 虽然用户确认资源充足，但仍建议定期检查GPU显存、CPU和内存使用情况
   • 可以使用nvidia-smi和htop等工具进行监控

总结

FlagEmbedding项目在分布式训练环境下对信号处理较为敏感，特别是在使用nohup等传统后台运行方式时容易出现中断问题。推荐使用tmux等现代终端管理工具来维持训练会话的稳定性，同时合理设置训练参数以获得最佳效果。对于loss曲线的异常表现，应结合具体数据特性进行分析，必要时调整模型超参数。