# Experiment B Performance Tuning

## 背景

本文档基于 `2026-03-31` 对实验 B 当前正式训练的实时观测整理，目标是回答：

1. 当前系统资源到底卡在哪里
2. 哪些参数最值得优先调整
3. 怎样在不破坏现有可跑性的前提下，尽量提升训练速度

当前训练实例：

- 训练日志：`runs/logs/tomato-exp-b-attr_20260331-192847.log`
- 输出目录：`runs/mid/qwen3_5_35b_a3b_exp_b_attr/v1-20260331-192847`
- 当前启动时的关键降载参数：
  - `DATASET_NUM_PROC=1`
  - `DATALOADER_NUM_WORKERS=2`

说明：

- 这两个参数不是为了提速，而是为了绕过上一轮实验 B 在数据映射阶段被 `SIGKILL` 的问题。
- 当前这轮已经成功越过上一轮失败位置，并进入正式 `Train` 阶段。

## 实时观测

### 1. GPU

观测时刻的 `nvidia-smi`：

- GPU 显存占用约 `33.9 GiB ~ 35.1 GiB / 49.1 GiB`
- GPU 利用率约 `19% ~ 27%`
- 功耗约 `95W ~ 115W`

补充观测：

- `nvidia-smi dmon` 连续采样期间，显存保持高占用，但 `sm` 利用率瞬时值很低。
- 这说明模型已经装载完成，但算力并没有持续吃满。

结论：

- 当前不是“显存不够”，而是“显存还有余量，但计算吞吐没有被充分压满”。
- 对 RTX 6000 Ada 来说，当前功耗和利用率都偏保守，明显还有提速空间。

### 2. CPU

观测时刻的系统级 CPU：

- `112` 核机器整体 `idle` 大约 `90%`
- `iowait` 约 `1%`

训练相关进程：

- 4 个主要训练 worker 的单进程 CPU 大约都在 `96%` 左右

结论：

- 机器总 CPU 资源非常充足。
- 当前不是整机 CPU 不够，而是训练进程只吃到了少量核，整体 CPU 远未成为上限。

### 3. 内存与 Swap

观测时刻：

- 物理内存总量约 `1.0 TiB`
- `available` 约 `867 GiB`
- swap `15 GiB` 已满

结论：

- 内存容量本身完全不是问题。
- 但 swap 已满说明机器历史上发生过明显的内存换出，这对训练稳定性是个风险信号。
- 上一轮实验 B 在数据映射阶段被 `SIGKILL`，与预处理阶段资源压力过高是吻合的。

### 4. 磁盘 I/O

`iostat` 观测结果：

- CPU `iowait` 很低
- NVMe 利用率很低，吞吐量也不高

结论：

- 当前不是磁盘带宽瓶颈。
- 训练速度慢，主要不是因为数据文件读不动。

### 5. 训练阶段特征

从日志看，实验 B 的时间主要消耗在两段：

1. 数据映射 / tokenization 阶段很长
2. 进入训练后，GPU 利用率仍偏低

同时，日志里还能看到两个重要事实：

- 当前使用的是 `--attention_backend unfused`
- 参数对象里实际 `sequence_parallel=False`

这意味着：

- 训练吞吐已经天然比更激进的 fused/flash 路线慢
- 不能把当前性能预期建立在“高级并行优化已生效”的假设上

## 主要瓶颈判断

基于当前观测，实验 B 的性能问题优先级大致如下：

1. 预处理阶段过慢，且并发一高就有稳定性风险
2. 训练阶段 GPU 显存占用中等，但算力利用率偏低
3. 当前批大小和重计算策略偏保守，更像“先保跑通”，不是“先榨吞吐”
4. 现有 `unfused` attention backend 本身限制了吞吐上限

不是主要瓶颈的项：

- 机器总内存容量
- 磁盘 I/O
- 整机 CPU 总量

## 提速建议

以下建议按优先级排序。

### P0：先把“稳定跑通”和“性能调优”分成两套参数

当前这轮参数适合保命，不适合作为长期最快配置。

建议保留两套启动配置：

- `safe` 配置
  - `DATASET_NUM_PROC=1`
  - `DATALOADER_NUM_WORKERS=2`
- `fast` 配置
  - 从 `DATASET_NUM_PROC=2`
  - `DATALOADER_NUM_WORKERS=4`
  - 开始逐步压测

理由：

- 现在最清楚的事实是：预处理并发拉高后，实验 B 曾经直接被系统杀掉。
- 但一味维持 `1/2` 组合，会显著拖慢数据准备。

推荐做法：

1. 先用 `safe` 配置跑通一次完整训练
2. 再单独开小样本性能压测，把 `dataset_num_proc` 和 `dataloader_num_workers` 逐步抬高
3. 只要出现明显 swap 抖动或再次 `SIGKILL`，立即回退

### P1：把数据缓存预构建为独立步骤

当前训练把“数据准备”和“正式训练”绑在同一次进程里，这会让每次重试都重复走长时间 `Map`。

建议：

- 增加一个独立的“数据缓存预构建”步骤
- 在正式训练前先把 train/val 数据的 tokenization 和缓存文件准备好
- 正式训练只消费缓存

价值：

- 可以把最不稳定、最容易触发 `SIGKILL` 的阶段前置
- 训练重试时不必重复长时间 `Map`
- 这通常是当前最容易拿到的真实提速项

### P2：优先尝试增大 `MICRO_BATCH_SIZE`

当前 GPU 显存大约只占到了 `34~35 GiB / 49 GiB`，每卡仍有十几 GiB 余量。

建议从小步试探：

- 先试 `MICRO_BATCH_SIZE=5`
- 再试 `MICRO_BATCH_SIZE=6`
- 同步调整 `GLOBAL_BATCH_SIZE`

推荐原则：

- 维持梯度累积逻辑清晰
- 每次只改一个量
- 观察显存、step time、是否出现 OOM

理由：

- 当前显存没打满
- 但 GPU 算力利用率偏低
- 典型原因之一就是每步喂给 GPU 的活太小

这是最可能直接提升训练吞吐的参数。

### P3：减少重计算强度

当前配置：

- `--recompute_granularity full`
- `--recompute_method uniform`
- `--recompute_num_layers 1`

在显存还有余量的前提下，建议做对照试验：

- 降低 `recompute` 范围
- 或直接尝试关闭部分重计算

理由：

- 重计算本质上是“用时间换显存”
- 现在更像是时间更紧，而不是显存更紧

建议：

- 先保留当前配置跑通一版
- 之后做一组短跑 benchmark，比对 step time 和显存峰值

### P4：检查 `attention backend`

当前是：

- `--attention_backend unfused`

这通常意味着：

- 兼容性更稳
- 吞吐更差

建议：

- 在不影响稳定性的前提下，继续修复 / 验证更快的 attention backend
- 如果后续能恢复到更高效的 fused/flash 路线，训练速度会有明显提升

这项的潜在收益很大，但风险也高，所以优先级放在批大小和重计算之后。

### P5：重新评估 `expert_model_parallel_size`

当前配置：

- `expert_model_parallel_size=4`
- `tensor_model_parallel_size=1`
- `pipeline_model_parallel_size=1`

这说明当前主要是 EP 路线。

建议：

- 对 `expert_model_parallel_size=4` 和更保守配置做小样本性能对照
- 重点观察 step time、GPU util 和通信开销

原因：

- 当前 GPU 利用率不高，可能有一部分时间耗在 MoE 路由和通信上
- 这类瓶颈通常不能只靠加 dataloader 解决

这项不建议直接在正式训练上改，先做 benchmark。

### P6：处理 swap 已满的问题

虽然当前物理内存还很多，但 swap 已满不是健康信号。

建议：

- 正式训练前确认没有残留的大进程长期占内存
- 定期清理历史残留的训练/推理进程
- 把“预处理高并发压测”与“正式训练”分开，避免训练时叠加系统脏状态

如果后续还出现：

- 数据映射阶段突然变慢
- 训练被 `SIGKILL`

应优先排查内存换出和宿主机资源保护，而不是先怀疑模型参数。

## 推荐调优顺序

建议按下面顺序做，不要一次改太多：

1. 先用当前 `safe` 配置完整跑通实验 B
2. 抽离数据缓存预构建步骤
3. 压测 `MICRO_BATCH_SIZE=5/6`
4. 压测较轻的 `recompute` 配置
5. 压测更激进的 dataloader / dataset 并发
6. 再评估 `attention backend` 和 `expert_model_parallel_size`

## 最值得先做的三件事

如果只做最有收益的三项，优先建议：

1. 把数据缓存预构建独立出来，避免每次重试都重复长时间 `Map`
2. 增大 `MICRO_BATCH_SIZE`，把剩余显存换成吞吐
3. 在稳定跑通后，降低重计算强度，减少“用时间换显存”

## 一句话结论

当前实验 B 的主要问题不是机器不够强，而是训练配置仍偏“保守保命型”。

这台机器的瓶颈不在磁盘和总内存，当前最值得利用的性能空间主要在：

- 更合理的数据缓存策略
- 更大的 batch
- 更少的重计算
- 更高效的 attention backend