[feat] Make the CPU reservation of the controller and SimpleStorageUnit configurable

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#207 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ó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
78/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
performance

Hướng nghiên cứu

Hai vị trí gọi định nghĩa các actors: transfer_queue/controller.py khoảng dòng 1107 và transfer_queue/storage/simple_storage.py khoảng dòng 900, cả hai hiện đang là @ray.remote(num_cpus=1). Đọc chúng cùng với TransferQueueLockManager, thứ đã dùng num_cpus=0, sau đó đọc hai biến môi trường và truyền giá trị qua .options(num_cpus=...) trên các lời gọi .remote(), mặc định là 1 khi chưa được đặt. Hoàn thành trông giống như một bài kiểm tra tạo các actors và khẳng định num_cpus được yêu cầu của chúng, cộng với không thay đổi hành vi khi các biến vắng mặt.

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

Mô tả

Problem

TransferQueueController and SimpleStorageUnit are declared with @ray.remote(num_cpus=1) (controller.py#L1107, simple_storage.py#L900), so each one reserves a full CPU for as long as it lives. A framework that starts a controller and several storage units per job reserves that many CPUs per job before any training work runs. verl's v1 trainer starts one controller and 8 storage units by default, so 9 CPUs per job (see verl#7398, where a 16-CPU Ray cluster was left with 7 CPUs after the units came up). When jobs queue for a GPU, their TransferQueue actors already hold CPUs and can keep the jobs ahead of them from being scheduled; #164 is the same pressure showing up as a startup hang.

The reservation is far above the usage. One local Ray 2.57.0 run (torch 2.13.0, Python 3.12) with 8 storage units, 126 kv_put calls per second of two small fields plus a kv_list per batch, for 30 seconds, measured through psutil CPU times of the actor processes:

controller    0.148 cores (average)
8 units       0.012 cores each (average)

TransferQueueLockManager is already num_cpus=0, so a zero reservation for these actors is not a new pattern here.

Proposal

Read the CPU request from environment variables, TQ_CONTROLLER_NUM_CPUS and TQ_STORAGE_UNIT_NUM_CPUS, and pass it through .options(num_cpus=...) where the actors are created. Keep the default at 1 so nothing changes for existing users. I can send a PR with a test that checks the requested resources of the created actors.

Not covered

The numbers above come from a small local loop, not from a training run, so they show the order of magnitude and not the load of a real job.

Ngôn ngữ chính
Python
Star
169
Fork
56
Merge trung bình
1 ngày 17 giờ
Pull request đã merge (30 ngày)
15

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

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

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 Ascend/TransferQueue

Tất cả issue của Ascend/TransferQueue

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.