Composer 不提供分布式任务调度能力，仅支持单任务内多卡数据并行（DDP/FSDP），跨机器调度需依赖 Slurm、Kubernetes 等外部调度器；常见误区是混淆“单任务多卡并行”与“多任务并行调度”。
Composer 本身不提供分布式调度能力，它依赖外部调度器（如 Slurm、Kubernetes、或自建脚本）来分发训练任务；它只负责单个训练进程内的多卡并行（DDP/FSDP），不跨机器拆任务、不管理节点生命周期、不处理任务排队与重试。
Composer 的“分布式”仅指单任务内多 GPU/多节点数据并行
很多人看到 composer -n8 my_script.py 就以为 Composer 自带任务调度，其实不是。这个命令只是调用 torch.distributed.launch 或 torchrun 启动一个训练任务，并在 8 张卡上用 DDP/FSDP 做数据并行——所有卡跑的是同一份模型、同一份训练逻辑，只是数据被切片喂入。
- 它不把“训练 100 个不同超参组合”拆成 100 个独立 job 分发到集群；
- 它不感知其他正在运行的 Composer 任务，也不会抢占或排队；
- 如果你要跑多个实验，得自己用 shell 脚本、Slurm array 或 Airflow 来启动多个
composer进程。
真要分散计算负载，得靠外层调度器 + Composer 组合
比如你有一批 50 个 hyperparameter 配置需要评估，目标是压满 10 台 8 卡机器（共 80 卡），这时：
- 用 Slurm：写一个
sbatch --array=1-50脚本，每个子任务执行composer -n8 train.py --config config_${SLURM_ARRAY_TASK_ID}.yaml； - 用 Kubernetes：用
Job模板生成 50 个 Pod，每个 Pod 运行composer -n8并挂载对应配置； - 用自研调度器：把参数配置序列化为任务队列（如 Redis list），worker 从队列取一个 config，然后本地执行
composer -n8。
关键点在于：调度器负责「谁在哪台机器上跑哪个 config」，Composer 只负责「这台机器上的 8 张卡怎么协作训好这一个 config」。
容易踩的坑：混淆“并行训练”和“并行任务”
常见错误现象：
- 误以为
composer -n8能自动把 8 个不同模型分到 8 台机器上——实际它只会在一台机器的 8 卡上训 1 个模型； - 没关掉
WANDB_MODE=disabled或COMPOSER_LOG_LEVEL=WARNING，导致 50 个并发 job 抢写同一个 WANDB project，日志混乱甚至 API 限流； - 检查点路径写死为相对路径（如
./checkpoints），多个 job 同时写会覆盖或报错；必须用唯一标识（如config_id或SLURM_JOB_ID）隔离目录； - 忘记设置
MASTER_PORT或MASTER_ADDR，当多个composer -n8在同一台机器上启动时，端口冲突直接失败。
真正需要调度粒度控制的地方，不在 Composer 内部，而在你怎么组织 composer 命令的调用方式、配置注入方式和结果收集路径。别指望框架替你做任务编排——它连 job 名字都不认识。
