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

Design resource-vector and provider-aware admission policies

Đang mở
  • Có gì không ổn?
#651 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ó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
python
Lĩnh vực
backend, distributed-systems

Hướng nghiên cứu

Bắt đầu với PR #658 và các tài liệu plans/645 được nêu trong issue, đặc biệt là task-admission.md, request-admission.md, capacity-model.md, observability.md, benchmark-plan.md và issue-map.md. Tạo một tài liệu thiết kế đã được chấp thuận hoặc bản cập nhật kế hoạch, ghi lại các câu hỏi còn bỏ ngỏ, các phương án thay thế bị loại bỏ, các issue triển khai tiếp theo và bằng chứng bắt buộc về liveness, fairness, telemetry và benchmark; không triển khai resource vectors.

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

Mô tả

plan spike task

Priority Level

Low

Epic: #645
Depends on: #641, #646, #644, #657, #649, #650
Related: #647, #648, #654
Target branch: epic/645-async-scheduling while the epic is active.

Source of Truth

Specification details live in PR #658 under plans/645/, especially task-admission.md, request-admission.md, capacity-model.md, observability.md, benchmark-plan.md, and issue-map.md. This issue tracks the design-spike slice and gates only.

Design Scope

Produce a decision-ready design for future resource-vector and provider-aware task-admission policies. This issue is design-only unless a follow-up implementation issue is explicitly created.

This issue owns:

  • deciding whether resource-vector internals stay scheduler-internal or require any public metadata additions beyond #641;
  • the minimal SchedulerResourceKey / SchedulerResourceRequest shape for a later implementation;
  • mapping resolved metadata from #641/#646 into scheduler resource requests without exposing scheduler internals as plugin API;
  • defining how task-stage provider/model awareness avoids duplicating request-stage AIMD admission from #657;
  • defining how the accepted #650 bounded-borrow policy should carry forward from coarse task-stage resources into provider/model/resource-vector resources, including strict share, bounded solo prefill, peer-pressure yielding, and borrow-debt repayment semantics;
  • defining per-generation-resource zero-inflight idle metrics for endpoint/GPU idleness evidence, including per-resource, total, max, and baseline-delta reporting;
  • liveness, release/accounting, cancellation/error, telemetry, and benchmark requirements for a later implementation;
  • recording rejected alternatives.

Quality Gates

  • No resource-vector implementation lands as part of this design issue.
  • The design preserves the task/request admission split and consumes request pressure only through read-only snapshots if needed.
  • The design keeps FairTaskQueue responsible for ready ordering, not resource ownership.
  • The design explains whether bounded-borrow semantics remain policy-compatible once resource identity becomes provider/model/resource-vector aware, or explicitly records any required policy revision.
  • The future implementation acceptance bar includes liveness, no permit leaks, multi-resource fairness tests, stale/retry/salvage behavior, correlated telemetry compatibility, and #649 benchmark evidence.
  • Benchmark matrix covers asymmetric provider/model capacities, different dominant resources, neutral single-resource workloads, heavy-root compatibility, and correlated scheduler/request traces.
  • Benchmark evidence must report per-generation-resource zero-inflight idle time: for each provider/model/resource, the total workflow wall time where that resource has no in-flight generation request while the workflow is still active. Reports should include per-resource idle, total idle, max idle, and deltas versus the named baseline.

Validation

Close with an accepted design document or plan update that cross-references plans/645, lists open questions, records rejected alternatives, and defines the exact follow-up implementation issue(s) and evidence gates.

Ngôn ngữ chính
Python
Star
2.4k
Fork
234
Merge trung bình
1 ngày 22 phút
Pull request đã merge (30 ngày)
83

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 NVIDIA-NeMo/DataDesigner

Tất cả issue của NVIDIA-NeMo/DataDesigner

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.