1. 问题来了：多GPU训练时那个恼人的Bus error

最近在折腾大模型微调的朋友，估计不少人都用过LLaMA-Factory这个神器。它把Hugging Face生态里那些繁琐的流程封装得明明白白，让你用几行命令就能启动一个LoRA或者全量微调任务，特别省心。我自己在给一个ChatGLM3-6B模型做指令微调时，也顺理成章地选择了它，想着用上deepspeed，把我手头的4块V100显卡的性能榨干，加快训练速度。

命令敲下去，看着日志开始滚动，心里正美呢，结果没跑几步，程序突然就崩了，终端里赫然留下一行刺眼的错误信息：Caught signal 7 (Bus error: nonexistent physical address)。翻译过来就是“总线错误：不存在的物理地址”。这感觉就像你开车上了高速，油门刚踩下去，就被告知前方道路不存在，直接给你整懵了。

我当时的第一反应是：是不是我的deepspeed配置文件ds_config.json写错了？毕竟多GPU并行训练，配置复杂。我反复检查了从LLaMA-Factory官方仓库里抄来的默认配置，stage2、stage3都试了，问题依旧。然后又怀疑是CUDA版本、PyTorch版本或者显卡驱动不兼容，一通降级升级操作，忙活了大半天，错误信息纹丝不动。这个Bus error在Linux系统里，通常意味着进程试图访问一块它无权访问或者根本不存在的内存区域，但在深度学习训练这种场景下，它往往指向一个更具体、也更容易被忽略的“基础设施”问题——共享内存。

2. 挖出根因：被忽视的/dev/shm内存瓶颈

在经历了各种无效尝试后，我决定静下心来仔细看看错误发生的上下文。Bus error后面跟着的nonexistent physical address这个描述，强烈暗示了内存映射出了问题。这时候，一个在Docker容器内进行高性能计算时经常被提及的名词跳进了我的脑子：/dev/shm。

/dev/shm是什么？你可以把它理解成Linux系统的一块“临时白板”。它不是普通的硬盘空间，而是一块基于内存的临时文件系统（tmpfs）。程序可以把一些需要快速读写、频繁交换的临时数据放在这里，因为内存的读写速度比磁盘快几个数量级。在PyTorch、TensorFlow这些深度学习框架底层，尤其是进行多进程数据加载（DataLoader的num_workers > 0）或者使用deepspeed这类涉及多GPU间大量数据通信的库时，会频繁使用共享内存来进行进程间通信（IPC），/dev/shm就是这块通信用的“共享白板”。

问题就出在Docker容器默认对这块“白板”的大小限制上。为了安全和防止某个容器耗尽主机内存，Docker默认给每个容器的/dev/shm大小只有64MB。这个大小对于日常的小型应用可能够了，但对于动辄加载几十GB参数、需要同时在多个GPU之间同步梯度、优化器状态的大模型训练任务来说，简直是杯水车薪。当多个进程同时试图往这块小小的共享内存里写入数据时，瞬间就会把它撑爆，导致内存分配失败，操作系统内核只好发送一个SIGBUS信号（也就是Signal 7）给进程，说：“你访问的地址出错了”，训练进程因此崩溃。

验证这一点非常简单。你只需要在运行训练命令的Docker容器内，执行一个简单的命令：

df -h /dev/shm

输出很可能会显示类似这样的信息：

Filesystem      Size  Used Avail Use% Mounted on
tmpfs            64M     0   64M   0% /dev/shm

看，Size那一栏明明白白写着64M。这就是罪魁祸首。当你用nvidia-docker或者--gpus all参数把GPU挂载进容器时，大家往往只关注显卡资源，却忘了这个不起眼但至关重要的内存文件系统限制。

3. 解决方案：给Docker容器“扩容”共享内存

原因找到了，解决起来就有的放矢了。既然问题是Docker默认的/dev/shm太小，那我们就在启动容器的时候，手动给它指定一个更大的尺寸。这正是Docker设计灵活的地方，它提供了--shm-size这个参数来满足这种特定需求。

核心解决方案就是修改你的docker run命令。假设你原来的启动命令是这样的：

docker run -it --gpus all -v /your/data:/data your_training_image:tag /bin/bash

为了修复Bus error，你需要把它改成：

docker run -it --gpus all --shm-size 8G -v /your/data:/data your_training_image:tag /bin/bash

关键就在于添加了--shm-size 8G这个参数。这行指令告诉Docker引擎：“请为这个容器分配一块大小为8GB的共享内存（/dev/shm）”。这里的8G是一个示例值，具体设多大取决于你的任务规模。

那么，--shm-size到底该设置多大？ 这里没有一个放之四海而皆准的公式，但可以参考以下经验：

1. 基础保障：对于大多数单卡或双卡的中等规模模型微调，设置2G到4G 通常是一个安全的起点，能解决绝大部分因默认值太小导致的问题。
2. 多GPU与大数据集：如果你像我一样使用4块或更多GPU，并且使用了DataLoader并设置了较多的num_workers（例如4个或以上），或者你的模型非常大，那么建议设置8G甚至更高。deepspeed在ZeRO Stage 2或3模式下，会在GPU之间分区优化器状态、梯度和参数，通信量巨大，对共享内存的需求也水涨船高。
3. 观察与调整：一个实用的方法是，先设置一个较大的值（如8G）确保能运行。然后，在训练稳定后，可以通过容器内的命令监控/dev/shm的实际使用量：

   watch -n 1 'df -h /dev/shm'
   

   这个命令会每秒刷新一次共享内存的使用情况。观察Use%一栏，看看在训练高峰期使用了多少。下次你就可以根据这个峰值使用量，再预留一点余量（比如峰值是5G，就设6G或7G）来设置--shm-size，更精确地利用主机资源。

重要提醒：--shm-size设置的大小，是从宿主机的物理内存中划出来的。如果你把它设置得过大（比如在只有32G内存的机器上设了16G），可能会挤占其他进程或容器所需的内存，甚至可能触发系统OOM（内存耗尽）。请根据你的主机总内存量力而行。

4. 深入实践：LLaMA-Factory与deepspeed的完整避坑指南

解决了/dev/shm这个核心问题，我们的多GPU训练之旅才刚刚开始顺畅。结合LLaMA-Factory和deepspeed的使用，这里有一份更详细的实践指南，帮你避开其他可能遇到的坑。

4.1 训练命令与配置的再审视

首先，回顾一下我最初出错的训练命令。为了清晰，我把它格式化如下：

deepspeed --num_gpus 4 --master_port=9901 src/train_bash.py \
    --deepspeed ds_config.json \
    --stage sft \
    --model_name_or_path ./models/chatglm3-6b \
    --do_train \
    --dataset my_data1,my_data2 \
    --template chatglm3 \
    --finetuning_type lora \
    --lora_target query_key_value \
    --output_dir ./output/my_lora_model/ \
    --overwrite_cache \
    --per_device_train_batch_size 4 \
    --gradient_accumulation_steps 4 \
    --lr_scheduler_type cosine \
    --logging_steps 10 \
    --save_steps 200 \
    --learning_rate 5e-5 \
    --num_train_epochs 200 \
    --plot_loss \
    --overwrite_output_dir True \
    --fp16

在确保/dev/shm足够大之后，这条命令应该能顺利跑起来了。但有几个参数值得特别关注，它们直接影响内存和显存的使用：

• --per_device_train_batch_size 4：这是每张GPU上的批次大小。4块GPU，总批次大小就是4 * 4 = 16。如果遇到CUDA out of memory (OOM)错误，首先降低这个值。
• --gradient_accumulation_steps 4：梯度累积步数。它通过多次前向传播累积梯度后再做一次反向更新，来模拟更大的总批次大小。这里实际的总有效批次大小是 16 * 4 = 64。如果你显存紧张但想保持较大的有效批次，可以尝试进一步增大这个值，同时减小per_device_train_batch_size。
• --fp16：使用半精度（float16）训练。这是节省显存和加快训练速度的关键。对于大多数支持FP16的模型（如ChatGLM3），务必开启。

4.2 Deepspeed配置文件（ds_config.json）的选择与微调

LLaMA-Factory在项目里提供了一些deepspeed的配置文件样例，比如ds_config.json、ds_config_zero2.json、ds_config_zero3.json。它们对应了deepspeed ZeRO的不同阶段。

• ZeRO Stage 1：仅对优化器状态进行分区。节省内存较少，但通信开销最小。
• ZeRO Stage 2：对优化器状态和梯度进行分区。这是最常用的折中方案，能显著节省内存，同时通信开销可控。
• ZeRO Stage 3：对优化器状态、梯度和模型参数都进行分区。节省内存最多，可以训练非常大的模型，但通信开销也最大，可能会降低训练速度。

对于4卡V100训练一个6B参数的模型，通常从ZeRO Stage 2开始尝试就足够了。你可以直接使用LLaMA-Factory提供的ds_config_zero2.json。它的核心部分类似于：

{
  "train_batch_size": "auto",
  "train_micro_batch_size_per_gpu": "auto",
  "gradient_accumulation_steps": "auto",
  "zero_optimization": {
    "stage": 2,
    "offload_optimizer": {
      "device": "cpu",
      "pin_memory": true
    },
    "allgather_partitions": true,
    "allgather_bucket_size": 2e8,
    "overlap_comm": true,
    "reduce_scatter": true,
    "reduce_bucket_size": 2e8,
    "contiguous_gradients": true
  },
  "fp16": {
    "enabled": "auto",
    "loss_scale": 0,
    "loss_scale_window": 1000,
    "initial_scale_power": 16,
    "hysteresis": 2,
    "min_loss_scale": 1
  },
  "gradient_clipping": "auto",
  "steps_per_print": 2000,
  "wall_clock_breakdown": false
}

注意其中的"offload_optimizer"部分，它配置了将优化器状态卸载到CPU内存，这能进一步节省GPU显存。如果你的CPU内存足够大，强烈建议保持"device": "cpu"启用。allgather_bucket_size和reduce_bucket_size这两个参数（默认200MB）控制了通信缓冲区的大小。在极端情况下，如果/dev/shm已经足够大但仍有通信问题，可以尝试小幅降低这两个值（例如设为5e7，即50MB），但这可能会略微影响性能。

4.3 其他潜在的内存与显存优化技巧

解决了Bus error，训练过程中可能还会遇到显存不足（OOM）的问题。这里有几个额外的技巧：

1. 启用梯度检查点（Gradient Checkpointing）：这是一个用计算时间换显存空间的技术。它在前向传播时不保存所有中间激活值，而是在反向传播时重新计算一部分。对于显存极其紧张的情况非常有效。在LLaMA-Factory中，你可以在命令中添加 --gradient_checkpointing 参数来启用它。注意，这会使训练速度变慢大约20%-30%。
2. 调整DataLoader的num_workers：在训练脚本的参数中，通常可以设置--dataloader_num_workers。更多的worker可以加快数据加载速度，但每个worker都会占用额外的内存和/dev/shm空间。如果设置得过高，可能再次引发内存问题。如果遇到问题，可以尝试将其设置为0（禁用多进程加载）或一个较小的值（如2）进行测试。
3. 监控你的资源：在训练运行时，打开另一个终端，使用nvidia-smi监控GPU显存使用情况，使用htop或free -h监控系统内存和交换分区（swap）使用情况。这能帮你直观了解资源瓶颈在哪。

5. 总结与经验之谈

踩过Bus error这个坑之后，我养成了一个习惯：每次在Docker里启动任何涉及多进程通信或高性能计算的任务前，都会下意识地加上--shm-size参数。这就像上车系安全带一样，成了一个条件反射式的操作。

回顾整个过程，这个问题的隐蔽性在于，错误信息Caught signal 7 (Bus error)非常底层和笼统，它不会直接告诉你“共享内存不足”，而是指向一个模糊的“物理地址错误”，很容易让人误入歧途，去排查代码、模型结构、CUDA环境这些更复杂的方向。而解决方案却又异常简单，仅仅是在docker run命令中添加一个参数。

所以，如果你在使用LLaMA-Factory、deepspeed、或者任何其他需要在多GPU/多进程环境下进行大规模数据处理的框架时，遇到了类似的、难以捉摸的崩溃信号，不妨第一时间执行df -h /dev/shm看看。很可能，你只是需要给容器里的这块“共享白板”换一张更大号的。

深度学习工程化就是这样，很多时候挑战不在于算法本身有多深奥，而在于如何让庞大的计算流程在复杂的基础设施上稳定地跑起来。每一个踩过的坑，都是让整个系统更稳健的一块基石。希望我的这次踩坑经历，能帮你节省下那几个小时的调试时间，让GPU的算力真正用在模型的迭代上，而不是在环境调试中空转。