Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

LocalBackend/Unsloth: gradient_accumulation_steps > 1 hangs the trainer (producer waits for one result per sequence)

Đang mở
  • Có gì không ổn?
#1,121 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
15/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
machine-learning

Hướng nghiên cứu

The hang is in the producer loop of run_unsloth_rl_training in art/unsloth/train.py, which pairs each inputs_queue put with a results_queue get, and in _async_prepare_inputs. Read how gradient_accumulation_steps reaches the trainer through TrainerArgs, then reproduce with gradient_accumulation_steps=2 to confirm the deadlock. Done means either the step runs to completion or a clear error is raised up front, and the loss weighting question in loss.py has a maintainer decision.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Versions: openpipe-art 0.5.20 (LocalBackend, Unsloth service), unsloth 2026.3.3, ART's managed vLLM runtime 0.25.1, one GPU.

What happens: with trainer_args=art.dev.TrainerArgs(per_device_train_batch_size=1, gradient_accumulation_steps=2) the first backend.train(...) call never returns. The GPU is idle; py-spy shows the trainer thread waiting for its next input in _async_prepare_inputs (inputs_queue.get()), while run_unsloth_rl_training waits for a result.

Why (as far as I can tell from art/unsloth/train.py): run_unsloth_rl_training puts one packed sequence into inputs_queue and then awaits one item from results_queue before it puts the next sequence. A result is only produced after an optimizer step. With gradient_accumulation_steps=k > 1 the Hugging Face trainer needs k inputs before it steps, so after the first input both sides wait for each other.

So gradient_accumulation_steps is accepted through TrainerArgs but cannot work with this producer loop. If it is not meant to be supported, a clear error would help.

Why it matters for long rollouts: with agent rollouts of 10-25K tokens, every trajectory fills its own packed row, and with per_device_train_batch_size=1 (memory) every trajectory becomes its own optimizer step: 32 Adam updates per train() call for 4 groups x 8 rollouts, each seeing a single trajectory with a positive or negative advantage, instead of one update over the group.

A possible fix: in run_unsloth_rl_training, put gradient_accumulation_steps sequences into the queue before awaiting one result, and pad the last batch of a step with zero-weight rows (or raise if the row count is not a multiple).

Related observation: the loss multiplies each token by weights = 1 / (trained tokens of its trajectory) and then divides by assistant_mask.sum() of the row (loss.py, policy_loss * weights * assistant_mask, then / denominator). With several trajectories per row this gives every trajectory equal weight, but with one trajectory per row its loss is effectively divided by its length twice, so long trajectories get smaller gradients than short ones. Not necessarily a bug, but it surprised me.

Happy to send a PR for the producer loop if that is the direction you prefer.

Ngôn ngữ chính
Python
Star
10.8k
Fork
1k
Merge trung bình
16 giờ 14 phút
Pull request đã merge (30 ngày)
148

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của OpenPipe/ART

Tất cả issue của OpenPipe/ART

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.