Pith. sign in

REVIEW 6 cited by

Understanding Stragglers in Large Model Training Using What-if Analysis

Not yet reviewed by Pith; the record is open.

This paper has not been read by Pith yet. Machine review is queued; the pith claim, tier, and objections will appear here once it completes.

SPECIMEN: schema-true, not a live event

T0 review · schema-true

One-sentence machine reading of the paper's core claim.

pith:XXXXXXXX · record.json · timestamp

arxiv 2505.05713 v2 pith:UHFQFZGH submitted 2025-05-09 cs.DC cs.LG

Understanding Stragglers in Large Model Training Using What-if Analysis

classification cs.DC cs.LG
keywords stragglerstraininganalysisbytedancelargemodeloftenwhat
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved
0 comments
read the original abstract

Large language model (LLM) training is one of the most demanding distributed computations today, often requiring thousands of GPUs with frequent synchronization across machines. Such a workload pattern makes it susceptible to stragglers, where the training can be stalled by few slow workers. At ByteDance we find stragglers are not trivially always caused by hardware failures, but can arise from multiple complex factors. This work aims to present a comprehensive study on the straggler issues in LLM training, using a five-month trace collected from our ByteDance LLM training cluster. The core methodology is what-if analysis that simulates the scenario without any stragglers and contrasts with the actual case. We use this method to study the following questions: (1) how often do stragglers affect training jobs, and what effect do they have on job performance; (2) do stragglers exhibit temporal or spatial patterns; and (3) what are the potential root causes for stragglers?

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 6 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. From Detection to Recovery: Operational Analysis on LLM Pre-training with 504 GPUs

    cs.DC 2026-05 unverdicted novelty 7.0

    Production logs from a 504-GPU LLM training cluster show 100% failure detection via multi-metric analysis, NFS saturation limiting bandwidth to 1.4-10.4% of link speed, and auto-retry achieving 33.3% success versus 12...

  2. GhostServe: A Lightweight Checkpointing System in the Shadow for Fault-Tolerant LLM Serving

    cs.DC 2026-03 unverdicted novelty 7.0

    GhostServe applies erasure coding to KV cache in host memory for fast recovery from failures in LLM serving, cutting checkpointing latency up to 2.7x and recovery latency 2.1x versus prior methods.

  3. SLOTH: Lightweight Detection and Localization of On-Chip Fail-Slow Failures for DNN Accelerators

    cs.AR 2025-10 conditional novelty 6.0

    A simulation-based framework using compiler-inserted probes, a two-stage sketch, and a PageRank-style ranking detects on-chip fail-slow cores/links at ~86.8% accuracy with ~116x trace compression.

  4. From Detection to Recovery: Operational Analysis on LLM Pre-training with 504 GPUs

    cs.DC 2026-05 unverdicted novelty 5.0

    Production-scale empirical study of a 63-node 504-GPU cluster reports multi-signal failure detection needs, low checkpoint bandwidth utilization, heavy-tailed node exclusions, and 2.7x higher success for auto-retry chains.

  5. ResiHP: Taming LLM Training Failures with Dynamic Hybrid Parallelism

    cs.DC 2026-05 unverdicted novelty 5.0

    ResiHP improves LLM training throughput by 1.04-4.39x under hardware failures by using a workload-aware execution time predictor to avoid false failure detections and a scheduler that dynamically changes parallelism g...

  6. ResiHP: Taming LLM Training Failures with Dynamic Hybrid Parallelism

    cs.DC 2026-05 unverdicted novelty 4.0

    ResiHP introduces a workload-aware failure detector and dynamic scheduler for hybrid-parallel LLM training that achieves 1.04-4.39x higher throughput than prior resilient systems under failures on a 256-GPU cluster.