feat: add tensor-parallel entropy loss benchmark
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
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- python
- Lĩnh vực
- devtools, performance
Hướng nghiên cứu
Start with tools/benchmark/bench_entropy_loss.py to see the existing single-GPU variants, then read tools/benchmark/runner.py and main.py to understand the current single-process flow. The issue leaves open whether to add a new tools/benchmark/run_tp.py (Option A) or extend main.py with a --tp flag (Option B), so settle that with a maintainer first. Done means the three TP variants run across the five (vocab, tp_size) shapes with synchronized timing and OOM reported for pytorch_gather.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Motivation
The Triton entropy loss kernel supports tensor-parallel training natively via its group parameter: each rank holds vocab / tp_size logits, all-reduces two scalars per row (max and sum-exp), then computes loss and grad locally. This avoids materializing the full logits on any rank.
The PyTorch alternative requires an all-gather of the full logit tensor first — O(tokens × vocab) communication. At realistic scale this is prohibitive:
- Llama 3.1 405B: vocab=128K, tokens=8K, TP=8 → 16 GB all-gather per step
The Triton path is not just faster; it is the only feasible approach at large vocab × TP. The current single-GPU benchmark does not demonstrate this. This issue tracks building a multi-GPU benchmark that makes it concrete.
Variants to benchmark
Three qualitatively different approaches:
-
triton_tp— existingtriton_entropy_loss_forward_backward(..., group=group). Shards vocab across ranks, all-reduces two scalars per row. O(tokens) communication. -
pytorch_tp_manual— same algorithm in PyTorch without Triton:local_max = logits.max(-1)→all_reduce(MAX)→local_sum = (logits − max).exp().sum(-1)→all_reduce(SUM)→ loss. Tests whether Triton fusion still wins when both paths use the same O(tokens) communication pattern. -
pytorch_gather— all-gather logits to full vocab on each rank, thenF.cross_entropy. O(tokens × vocab) communication. Included as a reference to show where the naive approach becomes infeasible; expected to OOM at large vocab × TP.
Shapes
Fix tokens=4096. Sweep (vocab, tp_size) pairs:
| vocab | tp_size | shard / rank |
|---|---|---|
| 32768 | 2 | 16384 |
| 32768 | 4 | 8192 |
| 65536 | 4 | 16384 |
| 131072 | 4 | 32768 |
| 131072 | 8 | 16384 |
Infrastructure changes
Multi-process runner
The current runner.py is single-process. Two options:
Option A — new tools/benchmark/run_tp.py entry point using torch.multiprocessing.spawn(worker, nprocs=tp_size). Each worker: initializes dist.init_process_group, creates a TP process group, runs benchmark variants with group=group, rank 0 collects and prints results.
Option B — extend __main__.py to detect a --tp N flag and re-launch itself via torchrun --nproc_per_node=N.
Option A is simpler to implement. Option B integrates more cleanly with the existing CLI.
Timing
dist.barrier()+torch.cuda.synchronize()before and after each timed region so all ranks agree on wall time.- Report max latency across ranks (rank 0 collects via
dist.all_reduce(MAX)). - Communication time is included automatically since the all-reduce is inside the kernel call.
OOM guard for pytorch_gather
Wrap in try/except and report OOM in the table instead of a time. This makes the table show exactly where the naive approach becomes infeasible.
Expected outcome
At vocab=131072, TP=8:
| variant | result |
|---|---|
triton_tp |
fast (~O(tokens) communication) |
pytorch_tp_manual |
slightly slower (no kernel fusion, same communication) |
pytorch_gather |
OOM or ~10–20× slower (16 GB all-gather dominates) |
Files
- New:
tools/benchmark/run_tp.py(or extend__main__.py) - Modified:
tools/benchmark/bench_entropy_loss.py— add TP variants alongside existing single-GPU variants
- Ngôn ngữ chính
- Python
- Star
- 337
- Fork
- 52
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của ServiceNow/Fast-LLM
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
ServiceNow/Fast-LLM#556 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
ServiceNow/Fast-LLM#538 ·
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 12/100
ServiceNow/Fast-LLM#533 ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
ServiceNow/Fast-LLM#510 · 1 bình luận ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 12/100
ServiceNow/Fast-LLM#507 ·
Tất cả issue của ServiceNow/Fast-LLM
Issue tương tự
-
enhancement help wanted
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Git-Hospital/githealthcheck#61 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
changelog investigate
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
ramnes/notion-sdk-py#433 ·
-
Partial method descriptors raise on class accessCó thể đã có người làm @Gambit-Checkmate đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 19 ngày
-
docs pkg:core
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 84/100
pydantic/pydantic-ai#11929 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
intake/intake-esm#789 ·